予定の検査なのに、オーダーを入力するのは前日
今、透析患者の「検査オーダーの履歴を集計する」という仕事に取り組んでいます。
予定のオーダーは入力しないのだから…。
透析患者さまは、ルーティンでいろいろな検査をします。
診療のことは私はよくわかりませんが、超音波(エコー)検査などでシャントの状態を、SPPやCABI等の検査で血管の状態を定期的に補足し、患者さまに問題が新たな問題が発生していないか、細心の注意を払っているようです。
これらの検査は、自覚症状がなくても、当院で定めたルーティンで、定期的に行われます。
今回、相談をいただいたのは、この「定期の検査の入力を簡略化したい」という案件です。
「簡略化したい」とはどういうことでしょう。おそらく、なにか面倒なことがあるのでしょう。
- 検査の種類ごとに、1年に1回、半年に1回、3ヶ月ごとに1回など、間隔が決まっている。
- 決められた間隔で検査をするにあたり、患者ごとに各検査を「いつしたか」をExcelで管理している。
- Excelに転記するため、患者ごとにカルテを開き、目的の検査の履歴を探すのが「面倒」。
なるほど。
当然ですが、電子カルテには、実施した検査の情報がデータとして蓄積されています。
これを加工すれば、患者さまが、それぞれの検査を、最後にしたのがいつか、を一覧にすることは、簡単なことです。
なんだったら、次の検査の予定を補足することだって、難しいことではありません。
これを加工すれば、患者さまが、それぞれの検査を、最後にしたのがいつか、を一覧にすることは、簡単なことです。
なんだったら、次の検査の予定を補足することだって、難しいことではありません。
履歴だけでいいんです
ところが、「次の検査はいいので、『前回の検査をいつやったか』だけわかれば…」と。
いやいや、「次の検査がいつなのかわかったら、もっと便利なのでは」と押してみるも、それは電子カルテの運用上、ムリなのだそうです。
いやいや、「次の検査がいつなのかわかったら、もっと便利なのでは」と押してみるも、それは電子カルテの運用上、ムリなのだそうです。
予定のオーダーは入力しないのだから…。
オーダー入力は前日
正確に言うと、オーダーを入力しないのではなく、オーダーを入力するのが「実施日の前日」なのだそうです。
なぜ、そんな面倒なことをしているかというと、数ヶ月前にオーダーを入力したところで、患者さまの透析の「曜日」が変わることがあるからなのだそうです。
透析患者さまは、多くの場合、週に3回の血液透析をします。2回/週や4回/週の患者さまもいるかもしれませんが、当院ではほとんど3回/週です。
すると、月・水・金で通われる方と、火・木・土で通われる方に分かれます。
前もって検査オーダーを入力するなら、月・水・金の患者さまは、月・水・金のどこかに検査を予約します。
ところが、何らかの事情で患者さまの透析日が火・木・土に変わると、入力してあった検査オーダーを変更しなければならないのです。
さらに、多くの透析施設では、1日のうち2~3回程度の透析を行います。これを「クール」と呼んでいます。
当院では、1クールが午前、2クールが午後、3クールが夕方から、となっています。
すでにおわかりだと思いますが、この「クール」が変わっても、検査の予定に影響が出てしまうのです。
臨時の検査にも対応
透析スケジュールの変更以外にも、検査の予定が変更になることがあります。
それは、臨時で検査をした場合です。
例えば、ある患者さまは、毎年1月にエコー検査を行っていたとします。その患者さまが具合が悪くなって、6月にエコー検査をしたとします。すると、次の検査は1年後、つまり翌年の6月になり、それ以降は毎年6月になっていきます。
こういった変更に対応しなければならないことも、オーダー入力を前日にする理由の一つだそうです。
こういった変更に対応しなければならないことも、オーダー入力を前日にする理由の一つだそうです。
一覧性を取るか、修正の手間を省くか
予定のオーダーを入力しておけば、つまりデータとして生成されていれば、最新の状態が共有できます。また、データさえあれば、閲覧方法はいかようにもできます。
一方で、それをしてしまうと変更があった時に、都度オーダーを修正しなければなりません。
一覧性を取るか、直前に入力することにより修正の手間を省くか、それは、「修正」がどのくらいの頻度で起きるかによります。
正直などところ、修正がそんなに多いのか、半信半疑です。想像するに、電子カルテを導入する前の、古い仕事のやり方を踏襲しているだけではないかと疑っています。が、現場の職員が言うのならそれには逆らえません。
もやもやとしておりますが、ここで、「なにが正しいか」を議論することは得策とは考えず、今は過去の検査の履歴だけ補足するように、SQLを組んでいます。
でも、楽しい...
集計する要素が、多数のテーブルに点在しており、今までに私がくみ上げたものとは、比較にならないほど複雑なクエリになりつつあります。
さらに、集計する要素が多い分、処理が重く、かなり時間がかかってしまいます。
今後、いろいろと試しながら、クエリのチューニングをしていかなければなりません。
とてもたいへんな仕事なのですが、いままで私がおもに手がけてきた「統計」の仕事に比べ、今回の仕事は完成すれば現場の負担を大幅に軽減できます。
統計の仕事はともすると「粗探し」になってしまいますが、今回の仕事は誰一人嫌な思いをすることはないので、やっていて気が楽というか、ハッキリ言って「楽しんで」います。
これが仕事をきっかけに、現場の仕事を助けるような案件を増やしていきたいものです。
コメント
コメントを投稿