OpenDolphin (前eDolphin）の設計及びオープンソース化


皆川和史
株式会社デジタルグローブ　

１．はじめに

ドルフィンプロジェクトで開発された電子カルテ eDolphin をさらに発展させるため、ソースコードを公開するとともに、名前をOpenDolphin に変更して新しいバージョンをリリースした。

２．ライセンス

ソースコードのライセンス形式は　GNU 一般公衆利用許諾契約書（GNU　GPL）である。OpenDolphinは商用を含めて自由に使用できるが、ソースコードを改変した場合は上記のライセンスにしたがってそれを公開しなければならない。

３．設計

３−１．基本のユーザインターフェイス

主となるGUIはカルテ画面とスタンプである。カルテ画面には紙と同じ2号用紙のメタファーを使用している。スタンプはよく使う語句や処方等の定型的な内容を持つGUI部品であり、これもまた実在のものを元にしている。（図１）


ユーザの入力方法は次の通りである。

（１）SOA部

基本的にはワープロの機能を使用する。よく使う語句はスタンプとして登録することができ、以降はこのスタンプをドラッグ＆ドロップするだけで同じ内容を記載することができる。この部分にはシェーマなどの画像もレイアウトすることができる。

（２）P（オーダ）部

スタンプをカルテにドラッグ＆ドロップする。紙にスタンプを押すのと同じ要領で処方等の内容がカルテ画面に記載される。

３−２．シームレスな地域連携

OpenDolphinはユーザに特別な操作を強いることなく、日常の診療を電子カルテで行なだけで地域連携に参加できるよう考慮されている。カルテを作成し保存する時点で、そのデータがＭＭＬ形式に変換されドルフィンのセンターサーバへ送信される。その時カルテの内容を、

（１）患者に開示するかどうか
（２）その患者がかかったことのある医療機関に開示するかどうか
を選択できる。（図２）


地域連携に参加せず病院内だけでの使用も可能である。その場合でもデータをセンターへ送信するかどうかを選択できる。センターへ送信するメリットとして患者への情報開示がある。

３−３．オブジェクトモデル
　OpenDolphin のUMLによるソフトウェアモデル1)を図３に示す。


  1. 日常の診療では、医師は患者単位にカルテ等の記録（以下、文書）を作成している。この関係は、患者は複数の文書を持ち、文書は医師が書くと表現できる。これが OpenDolphin のソフトウェアモデルの大枠であり、日常行なわれていることをそのままモデル化したものとなっている。
  2. 文書の具体例にはカルテ、傷病名歴、紹介状等がある。
  3. 文書の後利用を図るためには、その内容を構造化する必要がある。構造化の単位としてモジュールと呼ぶ情報のまとまりを考える。モジュールの具体例にはアレルギ、生活習慣、経過記録、処方、検査オーダ等がある。すなわち文書は一つ以上のモジュールから構成されていると考える。
  4. 文書は確定日や生成目的等を記述した文書情報を付けて保存する。この集合をデータベース化することで、患者に対する治療行為を記録した文書の履歴が得られる。
  5. 処方や検査等の情報は文書を構成するモジュールである。モジュールの集合を種類別にデータベース化することで、検査履歴や処方歴等が得られる。
  6. 文書履歴、処方歴、検査履歴等は、患者のメディカルヒストリの一つになっている。

このモデルは、医療現場における様々なニーズに対応するための手段を文書及びモジュールを開発する問題に帰着させている。個々の文書及びその構成単位であるモジュールはクラス階層に現せるので、ポリモーフィズムを利用することができ、それらの詳細に関知しないコンテナプログラム内で動かすことができる。そのため見通しのよい拡張やカスタマイズを行なうことができる。

３−４．拡張・カスタマイズの方針

GUIやデータ構造の拡張及びカスタマイズに対応するため、次の方針をとる。

  1. 機能は可能な限りプラグインとして実装する
    カルテ機能、受付リスト機能、スタンプボックス機能等、OpenDolphin の主要な機能は全てメインウインドウから起動されるプラグインとして実装されている。したがってこれらは置き換えが可能であり、目的に応じて異なる実装をとることができる。
    また各種のレポート機能等、現状の OpenDolphin にない機能もプラグインによって拡張できる。
  2. AbstractFactory パターンを利用する
    OpenDolphin は地域連携に対応できるだけでなく単独でも使用可能である。地域連携についても、同じMMLをベースとしながらも、はにわ・ひごメド・HOT・（MIKO）ではそれぞれ異なった振る舞いやGUIが求められる。こうしたプロジェクト間の違いを吸収するため AbstractFactory パターンを活用する。その結果、一つのプログラムで複数のプロジェクトに対応することが可能である。
  3. 種々の医療情報システムへ情報を伝達するため中間言語方式をとる
    電子カルテが実運用されてくると、レセコンやオーダリングシステムは勿論のこと、種々の業務系システムへデータを変換して送信することが求められてくる。
    OpenDolphin のデータはCLAIMとMMLに変換しているが、いったんデータを独自の中間言語（現状はDMLと呼ぶ）に変換し、それを MML/CLAIM に翻訳する方式をとっている。（図４）このアプローチはドメイン知識（医療現場における情報の実体）に他言語（MML/CLAIM, HL7, ベンダー固有の規格等）の体系を埋め込む必要がなく、保守や拡張が容易にかつ独自に行なえる利点を持っている。


４．開発者

MML/CLAIMの開発、プロジェクト推進、理想の電子カルテに至るまで

ドルフィンプロジェクトの実証実験でご使用し感想をお寄せいただいた先生方

実証実験のアポート及び機能についての評価、アドバイス

コーディング

５．サポート

OpenDolphin はMML による診療連携の機能は引き続きながら、スタンドアロンでの使用も可能としている。そのため全国的なサポートを行なうため、このバージョンから日医標準レセプト（通称 ORCA）とセットになった有償のサポートパッケージが用意されている。

参考文献

[1]皆川和史他: MML/CLAIMインターフェイスを装備したクリニック用JAVAベース電子カルテDolphinの開発 、第22回医療情報学連合大会論文集、2002