月: 2019年10月

投稿日:

RPA

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

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

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

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

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

投稿日:

投影された壁

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

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

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

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

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

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

投稿日:

久しぶりの障害

FMS17にしてから、本当に安定していて再起動自体があまりない。安定していることはよいことなのだが、いざ障害が発生した特の手順やノウハウがあまりないというのも事実。昨日はまさにそんな瞬間だった。

原因は単純。連携用VMのハードディスク領域が一杯になった。ということで、復旧が大変なんですが対応は簡単。だったはず。でもそうじゃなかった。まず、受け取れていない大量のジャーナルがあるため、送り元にジャーナルの再送を依頼する必要がある。これは避けて通れないので、帰宅途中のSEにお願いした。

しかし、ハードディスク領域がそれほどまでに消失されたのは、実は数百件にもおよぶ電文が何千回もリトライしていたからである。さて、このリトライの原因がわからない。十数本あるJDBCのラインの一本が滞留し一個もデータが流れない。

よく観察すると、正常と思われる電文さえ流れずどんどん滞留してリトライしている。これはデータベース本体の損傷？を疑い、バックアップからデータベースをデプロイし直して試すもだめ。データベースサーバーの再起動（データベース再起動は、起動後２回目という珍しさ）までしたが、全く反応しない。

さらにログの解析をしつつ、データなしのデータベースをアップロードして試すも動かず。すると、一瞬xDBCインターフェースが起動するがすぐに落ちるというのが繰り返されていることも気付く。たった一つの電文がインターフェースをクラッシュさせ、それが復旧しても、最初のリトライで再びクラッシュ。延々と何千ものリトライが続く流れになっていた。その連続するクラッシュがさらなるエラーログを発生させ、半端ない性能のVMが大量のハードディスク領域を消費して、電文欠落が発生したと。

さらに、この原因電文が半年前の障害と同じ原因であることも判明。（FileMakerのxDBCにはSQL長の限界があるみたいで、それを超えるとクラッシュする）しかも、その対処用の新バージョンのミドルウェアの納品を受けているのに、それをアクティベートするプログラム側の更新を怠り、古いまま動き続けていたと。

とにかく自分の間抜けを思い知った一瞬である。なので、対応昨として失敗ブログにしてみた。

文章化することは、いろいろな意味で記憶の強化となる。たとえ失敗でも。