図2
吉原博幸1、皆川和史2、田中久淳3
1 宮崎医科大学附属病院医療情報部、2 （株）ディジタル・グローブ、 3 （株）アボック西村
1.はじめに
地球上のどんな医療機関を受診しても、自分の病歴を全て見ることが出来たらどんなに便利で、医療上のメリットも大きいだろう。地球上に存在する医療機関が何らかの方法で結ばれ、地球規模で分散した病歴データを、あたかも一冊のカルテの様にひとつのまとまりとして見ることが出来る。これがカルテの電子化の最大のメリットであると思われる。これを実現するためのアプローチの一つとして、Web-cgi-SQLdatabaseの連携を用いる考え方があるが、複数の医療機関に分散された患者情報を、いかにしてまとまった病歴として見せることができるかという問題が生ずる。本論文では、分散化された情報の管理に関する考察を行う。
2.理論とシステム
2.1 分散管理のための前提
これまで、ICカード、光カード等のメディアに病歴情報を記録する方法の試みがあるが、病歴情報は膨大であり、おのずからこれらのメディアには容量の点で限界がある。超大型コンピュータを使って、医療情報センターの様な集中型のデータベースを運用する考えもあるが、検索要求の集中による検索のレスポンス低下など、多くの問題があり、やはり分散型管理が現実的な選択であろう。では、地球上に分散されたデータを「一つのカルテ」として見るためにはどうするか？これを解決するためには、以下の２つの前提が必要となる。
前提１：受診歴の管理。
患者が、これまでにどの医療機関を受診したかが判ること。これは、細かいレベルは必要でなく、病院単位で良い。いつ受診したかも必要ではない。したがって、普通の人が持つ情報としては、受診したことのある病院の数で、高々20レコード程度の情報である。この情報を受診歴データベース（以下GMHD: Global Medical History Database）に保持する（図1）。ICカードは、ネットワークトラフィックやサーバ負荷軽減のため、また、データバックアップの手段として用いることもできる。
前提２：システム間汎用インターフェイス
個々のHIS (Hospital Information System)が、システム間汎用インターフェイスを持つこと。つまり、他施設からの患者情報検索要求に対応出来るような共通のインターフェイスを装備する必要がある。具体的には、Web-cgi-SQLDBや、CORBA (Common Object Request Broker Architecture[1,2])そして医学マークアップ言語[3,4,5]などを使ったインターフェイスである。
2.2 病歴情報の階層化
病歴情報は階層化して考える。
1) 医療機関層
各医療機関で運用されるシステム（データベース）のアドレス
2) イベント層
データベース中の細かな情報の集まり。つまり、処方せん、検査結果通知書、各種報告書、プログレスノートなどである。
3) 実体情報層
さらに細かい情報、つまり、投薬内容、検査値、報告書の内容、プログレスノートの記述、画像データなどである。
これらの階層をうまく利用することで、データの保存／取り扱いが容易になる。
2.3 病歴情報検索のステップ
以下、患者が病院を受診した場合を想定して、情報の流れについて解説する（図1）。
1) 受診歴の検索
ICカードまたはGMHDから受診歴（受診医療機関のアドレス）を得る。患者が初めての医療機関を訪れた場合、もしICカードを持っていれば、その中には今まで受診した医療機関のアドレスが記録されているので、その情報を基に受診歴を検索出来る。ICカードを紛失または持参しなかった場合は、GMHDから検索する。医療機関では、必ず初診の際にICカードとGMHDに受診情報（病院情報システムのアドレス）を書き込むことが必須となる。この情報は医療機関単位の表現となる。Web-cgi-SQLDB風に書くと以下の例のようになるだろう。
例） http://host.domain/function=? pid=xxx
ちなみに、人が一生の間に受診する病院は高々20くらい。したがって、日本国民全ての情報をGMDSに集中しても25億レコード程度と考えてよいので、検索に対する負荷分散のため、ミラーサイトを複数置けば、単一のデータベースでも十分実用的である。
2) 診療歴（イベント）の検索
(1)で得られた医療機関の所在情報に基いて、各医療機関にイベント層データ（処方せん、検査結果通知書、各種報告書、プログレスノートなどドキュメント単位）を問い合わせ、そのリストを得る（表1）。このリストを時系列、種別、医療機関別などで適宜ソート／分類し、診療歴として表示する。この段階で、分散されていた病歴情報は、まとまった一つのカルテとして表示されることになり、ユーザは情報がどこに存在するかを意識する必要はない。
Table 1 The medical events retrieved from the GMHD using HTTP protocol.
| address (URL) | event | time | stamp | site |
| http://host.domain/... | document | 1996/03/12 | hospital | A |
| http://host.domain/... | drug order | 1996/03/13 | hospital | A |
| http://host.domain/... | exam order | 1996/03/13 | hospital | A |
| http://host.domain/... | exam order | 1996/03/13 | hospital | B |
| http://host.domain/... | exam order | 1995/12/23 | hospital | B |
| http://host.domain/... | exam order | 1995/12/24 | hospital | B |
| http://host.domain/... | exam order | 1995/12/24 | hospital | B |
CORBAを用いた場合
host.domain/.... event, time, site
の如く表わされ、
JDBCを用いた場合
jdbc:sub-protocol://host.domain/...event, time, site
の如く表わされる。
3) 実体情報の表示
選択された項目の詳細を表示する。例えば放射線レポートを選択すれば、その内容を見ることが出来る（図2）。ユーザは、情報の所在を意識することなく、あたかも一つにまとまったカルテのように閲覧、書き込みが可能になる。
図2
2.4 システム間汎用インターフェイス
これらのシステムを運用するためには、共通のシステム間汎用インターフェイスを持つことが必要である。特に、個々のシステムは、それぞれ独自のデータベース設計のもとに運用されているので、交換する情報の医学的意味を伝えるための標準的なデータ交換フォーマットを持つ必要がある。これについては医学マークアップ言語などの提案がすでに提出されており、詳しくは関係論文[3,4,5]を参照されたい。
3. システム実現へのアプローチ
3.1 GMHD エージェント
GMHD コンセプトを実現する方法は種々考えられるが、電子カルテシステム全体のことを考えて設計することが必要である。我々はイントラネットベースの電子カルテシステムを考えている。図１にその概要を示す。
このシステムでは、
これは大きなメリットであり、ドクターや看護婦はアプリケーションをインストールしたりメンテナンスする必要がなく、常に最新のバージョンを意識することなく使うことができる。懸念されるスピードは拡張機能を分散オブジェクトとして実装することにより、HTTP プロトコルを経由することなくアプレットと直接交信が可能になるようにすればよい。
しかしこのシステムには次の重要な制約もある。
これはアプレットに課せられたセキュリティー上の制約であり、このおかげで我々はインターネット上のサイトに安心してアクセスすることができる。しかしながら、クライントがGMHDのコンセプトにのとって他の病院の患者レコードを検索したいと思っても、直接他のサーバーにアクセスすることは不可能である。
この問題を回避する方法として、クライントの代理（Proxy）をイントラネットサーバー上に置くことが考えられる。この代理クライントをアプリケーションとして実装すれば、アプレットのような制約を受けることなく他のサイトのサーバーにアクセスすることができる。すなわちクライントの検索要求はいったん代理クライントに中継され、代理クライントがGMHDサーバーや他の病院の患者レコードを検索するわけである。我々はこの代理クライントをGMHDエージェントと名付けた。
3.2 エージェント間通信
ところでGMHDコンセプトは一つの病院で実現できるものではなく、多くの病院の参加が必要である。仮にその全ての病院がイントラネットベースになったと仮定すると、GMHDエージェントは各病院に存在することになる。この場合、他の病院の患者レコードを検索するのはGMHDエージェント同士の通信に任せたほうが自然であろう。すなわち図２のような構成によりGMHDコンセプトを実現するわけである。
この図においてクライントの要求は次のような経路で実行される。
3.3 MML Data の交換
以上のことからGMHDエージェントに求められる機能をまとめると次のようになる。
我々はこれに加えて次の機能を課した。
これはやりとりしているデータがまさしく異なる病院間の患者カルテデータであり、MMLをおいて他に適当な形式は見当たらないためである。尚、患者ヒストリーを検索する場合はMMLエンコードする必要はなく、GMHDサーバー上のエージェントにはこの機能はないものとする。
3.4 インターホスピタルレコード
さてエージェント間通信のプロトコルも種々のものが考えられるが、我々は全体をJavaベースで開発しているため、その中で最も有効と思われる方法を選んだ。それはソケット通信によってJavaのオブジェクトをリード・ライトするものである。これはJDK1.1で開発されたオブジェクトのシリアライズ技術に基づく新しい機能である。
従来ソケット通信と言えば複雑なプロトコルを開発する必要があったが、この方法はそうした事が全く不要であり、あたかもファイルからオブジェクトをリード・ライトするかのごとくソケット通信によってオブジェクトを交換することができる。図３にその概念を示す。
交換すべきオブジェクトはMMLデータであるが、我々はこれにも一考を加え、次のようなオブジェクトを交換することにした。
| 名 称 | Inter Hospital Record |
|---|---|
| インスタンス変数 | hospitalName 依頼者側の病院名 doctorName 依頼者側のドクター名 patientID 検索したい患者ID MML Data MMLエンコードされた患者データ |
| パブリックメソッド | GetHospitalName 依頼してきた病院名を取得する GetDoctorName 依頼してきたドクター名を取得する getPatientID 検索する患者IDを取得する setMMLData MMLエンコードデータをセットする getMMLData 返されたMMLデータを取得する |
インターホスピタルレコードの交換は、次のような手順で行われる。 （依頼者側） 検索したい患者ID（pID）、自分の名前（myName）、自分の病院(myHospital) からインターホスピタルレコードを生成する InterHospitalRecord ihr = new InterHospitalRecord (pId, myName, myHospital); ソケットを生成し問い合わせ先の病院（アドレス=url）にコネクションを張る Socket socket = new Socket (url); 張られたソケットからオブジェクトを書き出すための出力ストリームを生成する ObjectOutputStream out = new ObjectOutputStream (socket.getOutputStream ()); このストリームにインターホスピタルレコードを書き込む out.write (ihr); （受信側） コネクション要求が入るとソケットを生成する Socket client = server.accept (); 張られたソケットからオブジェクトを読み込むための入力ストリームを生成する ObjectInputStream in = new ObjectInputStream (client.getInputStream ()); このストリームからインターホスピタルレコードを読む InterHospitalRecord ihr = InterHospitalRecord) in.readObject (); レコードから依頼者の名前、病院名を取得し、認証等の処理をする ihr.getHospitalName (); ihr.getDoctorName (); ... レコードから検索する患者IDを取得する String pid = ihr.getPatientID (); ローカルサーバーを検索しMMLエンコードする result = SearchAndEncodeToMML (pid); 結果をレコードにセットする ihr.setMMLData (result); ソケットからオブジェクトを書き出すための出力ストリームを生成する ObjectOutputStream out = new ObjectOutputStream (client.getOutputStream ()); それにレコードを書き込む out.write (ihr); out.flush (); （再び依頼者側） ソケットからオブジェクト入力ストリームを生成する ObjectInputStream in = new ObjectInputStream (socket.getInputStream ()); そのストリームから返されたインターホスピタルレコードを読む ihr = in.readObject (); レコードからMMLデータを取得しデコードする String resultSet = DecodeMML (ihr.getMMLData ());
インターホスピタルレコードの構造はこれに限定されるものではない。ディジタルシグネチャーを追加して認証を確実にしたり、返されたレコードが途中で変更されていないかどうかのチェック機構を入れたりすることが考えられる。このオブジェクトは、病院間をつなぐデータと言う意味で、Inter Hospital Record と命名した。
3.5 GMHD エージェントの３つのInterface
GMHDエージェントはクライント、相手のエージェント、データベースサーバーとの通信が必要であり、それぞれの手段には次の方法を用いている。
3.6 分散オブジェクト
クライントとの関係は今後注目される分散オブジェクト技術を用いている。現在はJavaのRMI（Remote Method Invocation）を用いているがCORBAへの移行も検討している。将来はエージェント間通信もCORBAで行われる可能性がある。いずれにしても一旦サーバーからダウンロードされたクラインアントアプリケーションが、その後サーバーを経由することなくエージェントと交信できるため、システムのパフォーマンスが向上する。
3.7 ソケットサーバー
ソケット通信にはマスター・スレーブサーバー方式を用いている。すなわちマスターサーバーがエージェント用に決められたポートを監視し、コネクション要求が入るとスレーブサーバーを生成する。クライントとの交信はこのスレーブサーバーが担当する。マスターサーバーはスレッドであり、スレーブが処理中であっても新しいコネクションを受け付ける。スレーブもスレッドとして生成されるので複数のコネクション要求が並列に処理される。
3.8 JDBC
データベースサーバーとの交信はJDBCによっている。したがってデータベースソフトウェアとJDBCドライバを交換することで、ベンダーユニークにならない構成になっている。
3.9 ソフトウェア構成
GMHDエージェントは単独のソフトとして実装するのは困難であり、次の３つのソフトウェアから構成されている。
すなわちこれらのプログラムを総称してGMHDエージェントと呼んでいる。
Seagaia Meeting'97におけるデモの構成
まさにインターネットを使っている。
4. おわりに
地球規模の電子カルテシステム構築のためのアイデアについて述べた。病歴の電子化は、情報を広域的に使うことにその意義がある。今後、実稼働しているシステムでの実装実験を行い、その有用性を実証したいと考えている。ここで発明したエージェントにより、GMHDコンセプトに基づくグローバルな医療が受けられそうである。勿論セキュリティーの問題等、解決すべき点は多いが、これは優れた医療への第一歩である。
参考文献
1) Robert Refali: The Essential Distributed Objects Survival Guide, John Wiley & Sins, USA
2) 小野沢博文: 分散オブジェクト技術CORBA, ソフトリサーチセンター
3) 吉原博幸 et al:厚生省健康政策調査研究事業報告電子カルテシステムに関する(カルテ構造技術コアチーム報告), http://www.miyazaki-med.ac.jp/ medinfo/ SGmeeting/document/ health/ health_00.html
4) 高橋 究 et al: インターネットにおける診療情報流通のための共通フォーマットの検討, 1995年度医療情報学連合大会論文集, http://www.miyazaki-med.ac.jp /medinfo /SGmeeting /document/ 95JCMI/ 95MML_paper/ 95MML_paper.html
5) 吉原博幸 et al: 電子カルテの具体像, 1995年度医療情報学連合大会論文集, http://www.miyazaki-med.ac.jp /medinfo /SGmeeting /document /95JCMI /95elc_chrt_WS /95elc_chrt_WS.html