「医療情報の共有化」とはいうけれど

某所で書いた内容を転載。


国の上の方では「医療情報の共有化」は取り組み始めたようなんですが、業界の対応は立ち遅れていると思います。

私は、OpenDolphin というオープンソースであった電子カルテを開発してたりしますが、最近、諸々の事情でカルテデータの出力を試みてます。

具体的には、上図のようなカルテがあった場合、閲覧用に下図のような html (ブラウザで閲覧できるファイル形式)に出力します。

右半分が検討中です。

というのは、やっていて気が付きましたが、カルテのデータベースには薬剤・処置などのコード番号(これらはおそらく全国共通)が含まれていてこの表示をどうするか考え所と思ったからです。

例えば、デパス(0.5mg)錠のレセ電コード番号は 611170513 で上の赤枠でも同一です(同一でないと基金への保険請求時に困る)。

私は公立病院に勤めていたとき、何回かシステムの入れ替えに遭遇しましたが、その全てで処方内容が引き継げていませんでした。
過去カルテを参照しながら、新システムに一から打ち直しです。

でも、データベース上には保存されているはずで、なんでこれを引き継がずに現場医師に無用な負担を強いていたのだろうと今なら思います。

まだまだ、理念と現場が乖離しているし、それを埋めるような人材も日本には不足しているのだなと感じます。


 

猪股弘明

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 (系列。今回、説明したバージョン。他の派生物に関しては完全に把握しているわけではないが、おそらくない)

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

 

OpenOcean/OpenDolphin をカスタマイズするために知っておいた方がよいこと【改訂】

以前に OpenOcean というブログで

OpenOcean/OpenDolphin をカスタマイズするために知っておいた方がよいこと

OpenOcean/OpenDolphin をカスタマイズするために知っておいた方がよいこと 2

という記事を書いて、おかげさまでけっこう読まれた。

が、時間の関係で2回に分けてしまって(今となっては)ボリューム的にどうかってのと、とにかく急いで書く必要が(当時は)あり、いささか雑な部分も見え隠れするので、以前の内容に若干の加筆を加えて再構成。


オープンソース(Open Source Software : しばしば OSS などと略される)の電子カルテ OpenOcean/OpenDolphin は、ビルド・デプロイするだけでも出てくる役者が多いので、整理しておきましょう。

 

Java…Win, Mac, Unix などに仮想的なマシンを設定し、それを動かすための言語。したがって、Java で開発されたソフトは原理的には Win/Mac/Unix で動く。実際には windows と MacOS ではメニューの表示構成などが OS レベルで違うため、この部分は機種依存になります。他には内部の特殊文字が違う(例えばエスケープシーケンスやファイルセパレーターなど)ため、ここら辺はプログラムを組む際に工夫する必要があります。
仮想的なマシンで Java プログラムを動かすためには、当然、実行環境を提供するプログラム群が必要になってくる。Java 11 より前では、JRE という実行環境が用意されていた。Java 11 以降は、この方式は廃止され、各アプリ毎に実行環境を組み込む方式が推奨されるようになった。
Java プログラムを開発するためには JDK が必要。

 

Java EE…Java Enterprise Edition の略。とりあえずは、通常の Java アプリをクライアント-サーバシステムとして開発できるように拡張したもの、というような理解でいいと思います。
ただし、動的なサイトが作成可能な tomcat は、Java EE とは考えられていません(なお tomcat に Java EE の仕様のいくつかを実装した TomEE というプロジェクトがあります。日本語記事は少ないんですが『tomacat 魔改造 vs TomEE』あたりをご参照ください)。逆にウェブフレームワークとして認知されている Spring には Java EE の仕様の一つである JPA が標準で使えたりします。
これは、Java EE の機能が多彩で、単体でウェブアプリを問題なく動作させることができるアプリケーションサーバを構成するのが難しいためと思われます。
私も Java EE の仕様の全貌はまったくつかめてません。
現状だと「Java EE に対応したアプリケーションサーバは、WildFly・GlassFish・Payara・WebLogic 」と思っていいのではないでしょうか。
Java 自体 Oracle との絡み先行きは不安のようです。→ その後の経緯で Jave EE は Jakarta EE に引き継がれて開発も継続されていますが、どうも Spring 系の方が勢いがあるような。。

 

Jakarta EE…Jakarta Enterprise Edition の略。実質的に Java EE の後継。
Java EE で使われていたパッケージ群で javax という名称が(商標諸々の問題で)使えなくなったため、これを jakarta と改名し移行作業がなされました。
実務コーディング的には今まで

import javax.servlet.*;

などと書いていたところを

import jakarta.servlet.*;

とする必要があるわけです。
仕様の全体名も Jakarta EE となりました。

 

PostgreSQL…ご存知定番のデータベースソフト。いろんなところでお世話になってます。

 

NetBeans…Java でよく使われるIDE(統合開発環境)。Java 版 VisualStudio といった方がわかりやすいか。Java の IDE は、eclipse が有名ですが、ドルフィンプロジェクトではこちらを使っていたため、私もこちらの方に慣れちゃいました。ただ先行きは不安しかない。
最近では Visual Studio Code にプラグインを組み込んでコーディングする人も増えているようです。

 

Maven…「メイヴェン」と読むのが正しいようです。「マーベン」でも通じると思うけど(内輪だけ?)。Java 用プロジェクト管理ツール、と紹介されることが多い。実用的なソフトを構築する場合、自力で書いたソースの他にライブラリが必要になってくる。OpenDolphin/OpenOcean の pom.xml に

<dependency>
 <groupId>postgresql</groupId>
 <artifactId>postgresql</artifactId>
 <version>8.4-702.jdbc4</version>
</dependency>

などと書かれてあるのは、その指定のためです(この場合は、「postgresql を使いたいので jdbc ドライバをリポジトリから取ってきてね」という意味です。ver が 8.4 と最新ではないのは古い ORCA の postgres に対応するためだと思われます)。
他にもビルドの際の細かいルールを指定できる。例えば、ウェブアプリを作成する際、最終産物を jar や war (いずれも後述)の形式にしたいときがほとんどですが、設定で対応できます。

 

WildFly…Jakarta EE(Java EE) に準拠したアプリケーションサーバ。Jakarta EE(Java EE) は仕様しか決められていないため、Java で書かれた Web アプリ実運用のためにはサーバ実体が必要。このサーバ実体の一つがWildFly。 Redhat が開発し配布している。なお、この商用版が JBoss。
Jakarta EE(Java EE) 同様、機能が多彩すぎて、全体がつかみにくい。実稼働時には(アプリ名).war (後述)をWildFly 内に配置(デプロイ)する。
なお、現時点(2022/5)での WlidFly と対応する Jakarta(Java) EE の関係は以下の通りです。

公式サイトより

Jakarta EE 9, 10 あたりの実装が遅れているようです。

 

jar と war … 通常のソースコード ***.java を javac コマンドでコンパイルするとできるのは ***.class です。実行するには、「java 環境でクラスを呼び出す」必要があるので、コマンドは

java ***

となります。「コンパイル済みのクラスを呼び出す」これが Java アプリ実行の原則です。

ところが、Ocean/Dolphin プロジェクトでは、クライアントは OpenOcean.jar 、サーバーは OpenOcean.war などという名称です。

これは、ある程度まとまった機能を提供するためには、クラスだけでは足りず、設定ファイルや画像などのリソースファイルが必要なため、それらをまとめたファイル形式が必要とされたからです。jar は、その一つで Java ARchive からきています。読み方は「ジャー」でいいと思います。

Java EE を用いる Web アプリの場合には Web application ARchive 通称 war (ウォー :戦争 war と同発音)となります。

 

 

git と github … github は先日マイクロソフトに買収され、それを日経新聞が「設計図共有サイト、8200 億で買収」と報じたため、そのネーミングセンスが話題になりました。

オープンソースのソースをインターネット上で公開しておくには、何らかの場所(リポジトリ)が必要で、その一つが、GitHub (ギットハブ。ネイティブっぽく発音するならギッ ハブでしょうか)です。他には sourceforge や GitLab などもありますが、ドルフィン一族は、その多くが GitHub でソースを公開しています。

公開されたソース(リモート)を自分のマシン(ローカル)にクローンすることもできます(というかしないと自分のマシンではビルドできない)。

ローカルやリモートのリポジトリの橋渡しをしたり、改変を記録しておくためのシステムが Git (ギット)です。
雰囲気掴みたい人は『お手軽にWin機で Git や GitHub を使う』など参照。

歴史的に見るとまず Linux カーネル構築のためのバージョン管理システムとして Git がリーナス・トーバルズの手によってつくられ、そのホスティングサービスとして GitHub ができたわけですが、実用的には上のような理解でいいと思います。

 

windows にはデフォルトで git コマンドが入っていないため、自前で git が使える環境を構築する必要があります。私は随分前に構築したっきりなのですが、それなりに面倒だった記憶があります。たぶん、ここらへんで多くの人が嫌気をさすのではないかと思います。

ただ、ここらへんくらいまでの知識があれば、ビルド・デプロイはなんとかできるでしょうか。

Open Dolphin 2.7.0b を Win10 にインストールしてみた

OpenDolphin 2.7(m) を Mac OSX にインストールする

OpenDolphin-2.7m を M1 Mac にインストールする

あたりの記事をどうぞ。
ソースコードは

github https://github.com/Hiroaki-Inomata/OpenDolphin-2.7m

に置いてあります。

 

デザインパターン…迂闊なことをいうと本職の方々に怒られそうなので wiki から引用しておくと

 

ソフトウェア開発におけるデザインパターン(型紙(かたがみ)または設計パターン、英: design pattern)とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。

 

だそうです。ソースと最終産物との間にある中間的な機能を設計する上での定型的なパターン、とでもいったらいいんでしょうか。
apple 系のOS のフレームワーク( cocoa と cocoa touch )で頻出の「xxxxdelegate」も典型的なデザインパターンの一つです。
ですが、プログラミングの初心者コースではまずは教えないと思うので、それなりに経験積んだ人でも知らない人は知らないんではないでしょうか。
また、デザインパターンを「アンチパターン」として嫌う人もいます。
OpenOcean/OpenDolphin ではシングルトンやメニューファクトリーといったパターンが使われています。
これがある程度頭に入ってないと、ソースを追っていっても何やってるかわからなくなると思います。逆に C++ あたりで過去に一回でも経験しているとその類推で何とかなることも多いと思います。

 

 

実際に改変を試みようとするとここら辺から、難しくなってくるのかなと思います。

後は、主要なライブラリなどでしょうか。私もいまだに使い方がわかっていないライブラリは山ほどあります。

Java のライブラリとしては、ORM の Hibernate が有名ですね。ORM や Hibernate に関しては、他サイトですが

ORM に関して書くよ

をご参照ください。雰囲気掴めるかと思います。

? 参考
より詳細なソースコードレベルでの解説は
OpenDolphin ソースコード解説
を参考にしてください。

OpenOcean / HorliX 開発チーム