FileMakerからCP932の出力

ソケット通信用の固定長のデータをfileMakerで出力する目的でShift-JISで文字を外部テキストファイルとして生成する必要がある。ただし、オリジナルデータは基幹システム上にあってCP932で送付され、ミドルウェアでCP932 -> UTF-8 となっている。

とくに人名に含まれる「﨑」「彅」「髙」などの拡張文字がはいると、Shift-JISに変換するときにまったく出力できないという問題があった。

これまで、最後に改行を含まないデータを出力する場合、BaseElemntプラグインを使用し、BE_SetTextEncoding ()でshift-jisにしていた。これをCP932に設定しても動作せずオーバーヘッドを無視するなら、別にインストールしたiconvを使い、UTF-8で出力したファイルをCP932に変換するなど行う必要があった。

ファイルメーカー標準のフィールドのエキスポートには、文字コード設定がなく無理と決めつけていたが、オンラインのFileMaker勉強会で質問したところ、FileMaker 16から使えるTextEncode()を使うと良いのでは無いかと指摘された。

具体的にはグローバルオブジェクトフィールドにTextEncode($text,”shift_jis”,4)として一旦作成し、これをフィールドのエキスポートを使って出力し、上記の文字が問題なく変換されていることを確認した。ただし、変換できない文字は半角スペースになることから、正確にバイト長を合わせなければならない、固定バイト長ソケット電文を作成するには問題があった。

そこでさらに、JIS変換後に何バイトになるのかわかるカスタム関数を

GetContainerAttribute ( TextEncode ( w ; “shift_jis” ; 4 ) ; “fileSize” )

として用意して固定バイト長が破綻しないようにできた。非常に有用な知見であった。

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をラッピングすることで、見事にバックグラウンドで起動したままにすることができた。

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