RPA

ホワイトカラーの間接業務を自動化するものとしてRPAがあり、デジタルワーフォース、デジタルレイバーなどの呼び名があるらしい。労働人口減少が超高齢化とともに問題視されている我が国で、にわかに注目され積極導入のための試行が始まっている。

従来であれば、人海戦術やワークシフト、アウトソーシングや業務システムのカスタマイズによって乗り切ってきた内容を、24時間稼働可能で人よりも数倍早いRPAで業務効率を高めて、人口減少を乗り切ろうとしている。

RPAにもマクロやODBC程度のものから、AIを使ったパターン認識や高度な判断も組み込んだ与信自動化装置までを同じ言葉で語るのは難しいだろう。ただ、実際に2019年時点でシェア一番の製品を観察すると、出来ることは複雑なマクロ程度で、アイコンの認識にパターン認識を組み込んではみたもの、パソコンの壁紙程度で認識率が落ちる程度のものである。従って判を押す場所を追記するだけ簡単に運用できる手書き帳票が横行する現場では、RPAに対応するため帳票を入力するというもっとも単純な作業を人間が行うという逆転さえ懸念される。

一方で電子カルテを中心にした医療情報システムは、相当な費用と労力をかけて、さらに時間あたりの患者数まで減らしてデジタル化したところである。まさにRPAを導入できる段階にきたにもかかわらず、有資格者が操作するシステムであるが故、責任の所在の曖昧な自動化に非積極的なベンダーが壁となり、未踏の地に近い。

医療者自ら単純作業を自動化、複数の部門システムの情報を収集するためにRPAの設定を行うことに関しては、薬機法に触れない。しかし、電子カルテにRPAが活用されている姿はあまり見ない。まさに、ここにチャンスがあるのではないだろうか。

投影された壁

電子カルテ更新を来年初頭に控え、クライアントのセットアップとソフトウェア環境の確認作業の真っ最中。これまでは、電子カルテ本体に何らかのアプリケーションを導入するということはお願いできず、ずっと我慢してきた。10年以上の説得と実績から、今回初めて小さなソフトを一つ導入することが出来た。

一つだけだが、EGMAIN-GXにhttpインタフェースを追加するもの。サーバーやクライアント上のブラウザから、EGMAIN-GXの機能を呼び出すことが出来るようになる。ブラウザで実現した診療支援ツールから、検査オーダーの起動やエディターへの挿入、グラフなどの貼り付けなど、電子カルテの強化を図れる。

電子カルテの各種ツールをブラウザから呼び出せる。最上位のエピペンはセット登録名。病院カルテの複雑さは細分化されたり大量に登録されたオーダーやプリセット群。階層構造にすることでクリック数が増え、一つのオーダーを選ぶのに最低でも5回程度のクリックが必要。支援システムは目的に応じて次のアクションを提案できても、改めて電子カルテ側で選択し直すという障壁があった。これをショートカットする切り札になる。電子カルテ側インターフェースのベースは「FileMaker対応モジュール」である。ユーザーメードが突破口になったのは確かだろう。

4年前に発注したソフトであるが、結果的に電子カルテ更新まで日の目を見ずやっと導入に至った。しかし、些細な問題も積み残したままだった。JAVAで製造された常駐ソフトであるが、サービス登録できるほどの機能は無く、立ち上げるとタスクバーにウインドウが残ってしまう。このウィンドウを消されてしまうと、電子カルテを再起動するまで機能しなくなってしまう。ウインドウ無しで起動したかったが「セキュリティのためにウインドウがどうしても出てくるのだろう」とあきらめていた。

担当SEからのメールで、このウィンドウを消して稼働すべきと指摘があり、出来ていないとメールする前に、もう一回調べてみた。結果vbsで起動用のbatをラッピングすることで、見事にバックグラウンドで起動したままにすることができた。

何年も漠然と、出来ないものだと決めつけて一歩踏み越える努力を怠っていたことに気づく。壁のなかには自分だけが勝手に作り上げた張りぼてもあるものだと、改めて思う。

電子カルテ1.0

現在の電子カルテの現状は「Death by thousand of clicks」というショッキングな題名の論文に代表されるのかもしれない。Obama政権ですすめられた電子カルテ化政策で、米国での2008年の普及率4%が2018年時点で96%まで急峻に推し進められた一方で、電子カルテが利用体験が悪く医療事故も起き、医師の負担も増えている。一回のER勤務で医師は4000回もマウスをクリックし、検査データが伝わらず医療事故の原因となっている。電子化された後でも90%の病院が連携接続しておらず、変わらず紙とFAXを継続している状況であるという。

さらに問題の根は深い。訴訟大国である米国では、電子カルテの不具合に対して、不具合の共有が守秘義務契約によって阻まれるという。また政府主導の急速な電子化ルテ化が未曾有の電子カルテベンダーの乱立という結果となり、利用者側の習得も難しいだけで無く、分断したシステム間の標準的通信規約がおろそかになり、カスタマイズに伴うコード変更一つで連携エラーを容易に起こすという。

誤警報も多く、一人の臨床医がICUで一日に最大7000件の警報を受ける状況のなか、実に85%〜99%が誤警報であるという報告もある。誤警報には訴訟を回避するだけとしか思えないものもある。例えば年齢を考慮せず性別だけから妊娠を考慮しているかどうかのアラート画面を、処方のたびに出すシステムは医師の疲弊を誘導しているとしている。医療システムへの訴訟リスクの高まりが、医師の負担に直結しているという皮肉な状況である。

翻って現在の電子カルテの現状を俯瞰した場合、それは電子的に清書された紙カルテに過ぎず、「真正性、見読性、保存性」を満たすが、データの二次利用、活用は人的労力でしかなしえず、機械処理に向いていない。すなわち電子カルテではなく「紙カルテ2.0」にとどまると指摘するものもいる。

京都大学の小林先生は真の電子カルテを、まだ見ないパーソナルコンピュータの理想像の一つであるダイナブックを例に示した。ダイナブックは「ダイナミックメディアを扱うことが出来る本のようなデバイス」であり、人間の思考能力を高め、子供でもプログラムが可能なものであるとされた。それを真似るなら、診療を支援し、医者がプログラム可能で、ガイドラインは自動で取り込まれ、医療機関横断的に情報を示すことが出来るように、データが患者の管理下にあるようなものが想定されるという。

電子カルテ1.0に至るマイルストーンとして、インターフェースをしっかりと解析できる基盤が必要であり、処理速度も高速でなくてはならない。治療ガイドラインを示す、関連文献を見せる、アドヒアランスを評価できるなどの機能が必要かもしれない。業務手順を最適化できる、プログラマブルな機能も必要だ。

そこを目指すには、ガイドラインは機械処理出来る形での提供が理想だし、単純な医療情報標準化を超えた次のレベルが必要ともしてきた。電子カルテのパッケージ化は、企業収益という意味では正しいが、利用者側からは正しくない。ただし機能改善とカスタマイズの切り分けも重要。電子カルテ1.0に向けた行動として、理想的で高度かつ明確な目標を立てることも重要だが、過去の多くの議論のなかにも既に多くのヒントがあるのだから、まず出来るところからしっかりと進めていくことも重要であるとした。