OpenDolphin HTML/PDF Viewer プロジェクト

 

はじめに

以前に Save the DolphinS というプロジェクトをやっていた。

OpenDolphin という電子カルテは、データ構造に癖があり、カルテ記載内容の抽出ですら、それなりに難しい。
そのため Save the DolphinS では、データベースに直接アクセスしてデータの抽出を行うソフトの作成を行なっていた。ソフトは -味も素っ気もない言い方だが-「データ移行ツール」と呼んでいた。

「データ移行ツール」は dolphin データベースに直接アクセスして、一応

・カルテ記載内容全履歴→プレーンテキスト(画像などの特殊タグ付き)+画像など

・カルテ記載内容全履歴→ rtf 形式ファイル(画像などの特殊タグ付き)+画像など

に抽出するところまではできていた。(どういうものだったかは『電子カルテからの患者データの吸い出し』あたりを参照してください)

OpenDolphin 本体はおろかアプリケーションサーバである WildFly がなくてもデータベースさえ活きていれば、このソフト単体で動作してデータ抽出が行えるのでそれなりに重宝していた。

ただ、これだと、データを他のシステムに移行する場合には便利でも、たとえば保管はしておきたいが閲覧だけでいいという場合、視認性の面で今ひとつの感は拭えない。

何かうまい解決方法はないかなと思っていたのだが、ひょんなことから移行ツールの出力を html 形式で書きだせばいいことに気がついて、ソースコードを改変して試してみたところ、まずまずうまく動いた。

細かいところでさらに修正したいところはあるのだが、例えば、以下のカルテ画面(↓)

を、html 形式で書き出すとこんな感じになる。

 

2号用紙風のレイアウトやフォントの属性、画像の添付位置までほぼ完全に再現されていると思う。

データ抽出というコンセプトは同じでも、(移行を考慮して)データをテキストと画像などに分離させて出力するのと(閲覧性を重視して)それらをを html にまとめるのは、使用目的の点で微妙に異なる。

また、この機能を移行ツール内に同居させておくのは、ソースコード管理の面でも何かと不便だ。

そこで、この機能を分離させ、単独のソフトとして独立させることにした。

今後はこちらを

OpenDolphin Viewer
OpenDolphin HTML Viewer
OpenDolphin HTML/PDF Viewer (PDF 出力にも対応したため改名)

と呼ぶことにする。

 

開発グループを代表して
猪股弘明

背景色を変更

実務的にはまるで意味がないのだが、白背景は味気ない気がするので背景色を OpenDolphin 特有の薄い緑( dolphin’s green というのだそうだ)に変更。

ドルフィン感が強くなった。

 

レスポンシブ対応

最近のウェブデザインは凝っていて、ブラウザの横幅を変更するとレイアウトを自動で調整してくれる。レスポンシブデザインなどというようだ。
この仕組みのおかげでPCのブラウザでもスマフォのブラウザでも、それなりに「見れる」レイアウトになっている。
これを狙って CSS を若干修正。

通常時がこうだとすると

ブラウザの横幅を縮小させるとある値(ブレークポイント)を境に右のいわゆる P 欄が左(SOA欄)の下に回り込む。

スマフォで閲覧することなどないかもしれないが。

 

P 欄(カルテ右半分)の検討

これまで、カルテの右半分(P 欄)は文字情報だけ抜いてきたが、実は処置・薬剤のレセ電コードも抜ける。

まだ、うまくまとめきれてないのだが、かなり雑にデータを書き出すとこんな具合になる。

赤枠で囲んだ部分が処置や薬剤の識別子(コード)で、その多くはレセ電コードと同一なはずだ。

実運用としては、ドルフィンから処置内容を ORCA に送った際に、この情報を受け取った ORCA はこれらコード番号に基づいて保険点数や窓口負担額を計算し、最終的にはレセプトに反映させている。

病院のシステムを入れ替えた際に、よくこのコードが引き継げなくて処方内容を一から打ち込むことがよくある。とても負担だ。

本プロジェクトはデータの「閲覧」を強く意識しているが、上記の点に留意し P 欄に関しては若干レイアウトを崩してもこれらコードが表示できるようにしたいと考えている。

P 欄(カルテ右半分)の検討(続き)

通常 P 欄に記載される内容は、診断料や処方のほか各種検査のオーダーなどもある。
だから、まずドルフィン元カルテをこんな風にした。

カルテ左の SOA 領域よりも難しいのは、項目毎に処理を変えなくてはいけない点。

ここら辺、工夫してコードを修正。
現状だとこのようになっている。

プロトタイプとしては、十分な出来だろう。
なお、レセ電コードは、某所で聞いて見たところ「あったほうがいい」ということだったので、多少元カルテの表示と異なってくるが、表示させることにした。

また、この改変を機に元の OpenDolphin のコードは全て削ぎ落とした。
単純に表示させるだけなら、

dolphin データベース >> 読み込み >> オブジェクトの生成 >>
適当に修正して html 用に変換 >> 書き出し

とやった方が楽なのだが、P 欄に関してはレセ電コードを打ち出せるようには構成されていないので、結局、ここら辺のコードは全て廃棄した。
(SOA 欄は特殊タグを表示させる関係上、移行ツールの頃から使っていない)

html → PDF 変換

ところで、OpenDolphin の標準のカルテ画面の PDF 文書作成機能は、文字などもベクトルデータに変換していわば「画像」として PDF を生成しているようだ。
Mac の場合、フォントの関係(物理フォントと論理フォントというものがある)でデフォルトでは文字化けしてしまう。

そちらの修正はひとまずおいて、html → PDF 作成ができないか検討。

あれこれやっていたら、以下のように
フォント埋め込み形式の PDF が生成できた。

データ移行に関する厚労省の見解

実は、公式な文書はない。

ガイドラインの要請からして

・カルテ記載の文字情報や診断の根拠となったような画像の類

・処置内容の文字情報

・修正履歴や途中経過版

は最低でも移行しなければならないでしょう。

口頭でもそれっぽいことは言っていた。

現在、問い合わせ中です。→結局、明確な回答は得られず。

「最近、安全管理に関するガイドラインを公開したので、そちらを見ていただいて・・・」というような感じでお茶を濁そうとする。

「これだから、日本の医療 IT は」と思わないでもないが、文句を言っても始まらないので、ガイドラインに目を通す。

医療情報システムの安全管理に関するガイドライン 5.2 版』というのがそれのようだ。

んー、しかし、これ、(例の半田病院の件を受けてだろうが)従来の電子カルテの3要件などの基本的要件に加えて、さらにシステムには医療記録のバックアップの仕組みを付け加えなさいよ、と言っているだけのような?

本当に知りたいのはバックアップ時に書き出す情報の種類や質といったことなのだが。

ただ、以前に比べれば、要求は具体的にはなってきた。

ポイントとなりそうなところを抜き出しておく。

1.バックアップサーバ
システムが停止した場合でも、バックアップサーバと汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。

2.見読性確保のための外部出力
システムが停止した場合でも、見読目的に該当する患者の一連の診療録等を汎用のブラウザ等で見読ができるように、見読性を確保した形式で外部ファイルへ出力できるようにすること。

3.遠隔地のデータバックアップを使用した見読機能
大規模火災等の災害対策として、遠隔地に電子保存記録をバックアップするとともに、そのバックアップデータ等と汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。 

(p. 61)

今回の HTML/PDF Viewer に絡めて言えば、このソフトを使って定期的にデータベースからバックアップを取っておけば、上記の条件を満たしているのは自明だろう。
「汎用のブラウザを使って」とあるが、html を表示できないブラウザはあり得ないので、お釣りがくるくらい(なにしろ画像や処方薬の薬剤コードまで表示してくれる)条件をクリアしている。

一応、バックアップは取っておいた方がいいとは思うが、データベースさえ生きていれば、サーバが停止してもこの条件は満たしている。

ところで、なんで厚労省の役人がお茶を濁そうとしたのかわかるような気もする。
商用の電子カルテでも上記の条件を満たしているシステムは(現時点では)そうは多くないからだ。

病院の電カル・HIS の場合、半田病院や大阪急性期総合医療センターの件で明るみに出されたが、ガイドラインで推奨されている基準でバックアップシステムを稼働している施設はほとんどない。

開業医さん向けの電カルは、この点はかなり改善されてきて、

・CLIUS

・owel

などは、この機能が公式に提供されている。
いわゆる商用の電子カルテとは一線をかくすが、

・ダイナミクス

・OpenDolphin-2.7m (系列。今回、説明したバージョン。他の派生物に関しては完全に把握しているわけではないが、おそらくない)

も、こういった機能が充実している。

 

OpenDolphin Ver 6

ちょっと手が空いたので、OpenDolphin-2.7m を JakartaEE 9.1, java17 環境に移行した。

軽くまとめ。

主な変更点

主な変更点は二つ。

・画像の取り扱いの変更

・ウェブレイヤーの追加

まず、画像に関して。

これまで、画像の取り扱いが jpeg に限定されていたのだが、この制約を取り払った。

ただし、従来のデータベースとの互換性を保つため、jpegByte あたりのコードには直接変更を加えず、新規に画像保管用のカラムを加えた。

これまで、データ構造は LSC 時代の 2.7 と全く同一にしていたのだが、この変更でこの原則は崩れた。

ただし、API にはある種の追加はしたが、これまでのものを削除することはしなかったので、以前のバージョンのデスクトップアプリを使えば、使用感は変わらないと思う。

一種の上位互換。

API の追加は、まだ進行中。煮詰まってない。

画像のフォーマットは山ほどある。どこまでサポートするかは現時点では決められない。

次に、ウェブレイヤーの追加に関して。

以前から、「クライアントは Java デスクトップアプリである必要はない」ということは言われていたのだが、ではどう構成するのか?という具体的な議論はなかった。

個人的には、3層クラサバ化がいいのではないかと思っていたので、今回、OpenDolphin HTML・PDF Viewer をウェブサーバー化して、フロントエンドサーバーとした。

諸々の機能は実装中。

サーバーサイド

フロントエンドサーバーを加えたので、単に「サーバー」と言った場合、従来のサーバーと混同してしまう。

そこで、従来のサーバーを BackendServer と名称変更した。

クライアントサイド

前述のように、クライアントは従来のデスクトップアプリと新規に作成したフロントエンドサーバー(ブラウザタイプ)に別れた。

デスクトップアプリ

今回のアップデートが最後でしょうか。

フロントエンドサーバー(ブラウザ)

以前に dolphorca と呼んでいたものがこれにあたる。

名称

これまでにも、ノーマル 2.7-m ベースのいくつかのカスタマイズバージョンがあった。

例えば、以前に書いたように(『聴診音クラファンからの・・・OpenDolphin』など参照)、研究支援用のプロトタイプバージョンなど。

ところで OpenDolphin のアプリケーションサーバーといえば、WildFly がデフォルトである。
が、若干修正することで GlassFish でもデプロイ程度はできる(正常動作はしないが)。
こういったバージョンも存在した。

このように非公開のいくつかのバージョンがあって、バージョン番号はいささか混乱していた。

そういった経緯で今回移行したプロジェクト群を総称して(数字的には 2.7 から一気に飛ぶが) Ver 6 とした。

 

 

大阪急性期・総合医療センターへのサイバー攻撃とカルテのバックアップ

某所に投稿した内容、転載。


大阪急性期・総合医療センターへのサイバー攻撃の件で「バックアップは取ってあるが、使用できない」という?な報道の仕方がされました。

おそらく、これ、ガイドライン的にはバックアップになってないです。

医療情報システムの安全運用のガイドラインは今年の4月に厚労省から改訂版が出されています。
https://www.mhlw.go.jp/stf/shingi/0000516275_00002.html

そこでは
『1.バックアップサーバ
システムが停止した場合でも、バックアップサーバと汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。
2.見読性確保のための外部出力
システムが停止した場合でも、見読目的に該当する患者の一連の診療録等を汎用のブラウザ等で見読ができるように、見読性を確保した形式で外部ファイルへ出力できるようにすること。
3.遠隔地のデータバックアップを使用した見読機能
大規模火災等の災害対策として、遠隔地に電子保存記録をバックアップするとともに、そのバックアップデータ等と汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。』

などの手法を取って、本システムが停止しても診療業務が継続できるような対応が推奨されています。

大阪の件では、(個人的に推測するに)バックアップの「データ」は取ってあっても、それを表示するようなシステムになってなかったものと思われます。

日本の SIer のダメな点だと思うのですが、下請け丸投げ方式では、システムの仕様は決められても、データ構造の詳細な設計やミドルウェアを経由しないデータ抽出方法の提供ができないんでしょうね。

開業医さん向けの電カルでも、ここら辺まで手が回っているのは、CLIUS と私のやつぐらいなものだと思います。

OpenDolphin HTML/PDF Viewer プロジェクト


システムをオープン系で組んだ場合、DBは大抵、PostgreSQL か MySQL を使うので、データ構造がわかってれば、ミドルウェア・(システムの)クライアントを経由せずともデータの復号は可能なんですよ。

 

猪股弘明