Instantly share code, notes, and snippets.

Embed
What would you like to do?
OpenDolphinの設計

オープンドルフィンの設計について

オープンドルフィン・ラボ 皆川 和史

OpenDolphinはGNU GPL Ver.3.0 の元にソースコードを公開している。この文書は設計の観点からOpenDolphinの概要を記述したもので、ソースコードを利用する際の一助になることを目的としている。

1.オブジェクトモデル

1−1.Top オブジェクト

図は日常の診療風景をUMLのアクターで表している。

top-model

  • 医師は患者を診察する。
  • 医師はカルテに記録する。
  • カルテは患者単位にある。

OpenDolphin は、トップレベルではこの日常の診療風景をそのままモデル化している。1)

1−2.エントリー
  • 医師は診察する度にカルテに記録を加えて行く。
  • この加えて行く単位を OpenDolphin ではエントリーと称する。
  • よってカルテはエントリーの時系列的な集まりである。
  • エントリーを、医学的にまとまった意味を持つ情報の固まりに分解する。
  • この固まり(情報単位)をOpenDolphinではモジュールと称する。
  • モジュールの具体例は、所見、処方、処置、検査、アレルギー、シェーマ画像…等々である。

entry

1−3.コンポジットデザインパターン
  • エントリーはコンテナ、モジュールはコンポーネントと考えることができる。
  • OpenDolphinは、コンテナもコンポーネントもオブジェクトとしては同等の性質を持つ、とするコンポジットデザインパターン 2)を採用している。
  • エントリーを基底クラスに昇格し、コンテナを加えたクラス図を示す。これがOpenDolphinの骨格である。

OpenDolphin-Model

図のDocumentが診察毎に記録される2号カルテを表す。これはコンテナでモジュールやシェーマをコンポーネントに持っている。これら全てはクライアントから見ればエントリーである。

実装は、多数の補助クラス、ターミノロジーの未熟さ等があり複雑に見える。しかし上記のクラス図を理解することで格段に見通しがよくなるはずである。

1−4.MML
  • カルテをモジュールに分解して扱うのは MML 3)を参考にしている。しかしMMLのモジュールとOpenDolphinのモジュールは、概念的には同じであるが設計上は異なる。MMLのモジュールはコンテナでもあるが、 OpenDolphinのモジュールはそうではない。これは実装をより簡単にするためである。
  • コンポジットデザインパターンの長所は、コンテナもコンポーネントも区別しないので、例えば文書履歴も処方履歴もエントリーに定義されている属性で検索できるなどにある。
1−5.ユーザーインターフェイスへのマッピング

OpenDolphinの特長はインターフェイスレベルでは2号カルテの画面にある。これは多くのユーザーから視認性がよいと指示されている。このインターフェイスと上記モデルとのマッピングを下に示す。

2-karte

  • Documentが2号カルテ画面に対応している
  • Moduleは診療行為の単位(所見、処方、処置、検査...等)でありDocumentを構成するコンポーネントである
  • プラン側(2号カルテの右側)に位置する*Moduleは全てORCAへ送信される

2号カルテ画面を視覚的に実現するため、Moduleには下記属性をつけている。

  • role: モジュールがSOA(左)側に位置するかP(右)側に位置するか
  • entity: モジュールが表す情報の実態(所見、処方、処置、検査、手術、指導...等)
  • number: モジュールがDocumentの何番目に出現するかの番号
1−6.オブジェクトモデルまとめ

MMLは医療のドメイン知識をモデル化したものであり、コンポジットデザインパターンはドメインには依存せず広く問題解決に役立つ情報処理上の手法である。両者とも科学的な指向に基づくものであり、 この二つを適用したのがOpenDolphinの基本設計である。ユーザーはインターフェイスを通して間接的にモデルに触れるとすれば、その評価からこれまでのところいい結果を生んでいるようである。 今後はopenEHR 4)等の世界標準をサポートし、国家レベルで構築が検討されているEHR基盤等への接続を計画している。

2.確定日について

OpenDolphinの確定日はカルテを保存した日(実際には時分秒も記録)である。したがって医学的なイベントが起きた日とは必ずしも一致しない。例えば次のケースを考える。

  • 9日の午前0時前に医学的なイベントが発生し、カルテの作成を開始する
  • 0時を過ぎてカルテを保存する

医学イベント発生-->カルテ作成開始-->午前0時-->カルテ保存

この場合、

  • イベントの発生日は 9日
  • 確定日は 10日

となる。このタイム差は意味があると考えておりシステム上変更はできない。

それはカルテは文書であり、書いて行くうちに当初の考えが変化する可能性があるし、あいまいであったものはまとまるからである。 システム的には保存した時点をカルテの有効開始日として管理し、それを表示上確定日としている。

このカルテが 11日になって変更された場合、

元のカルテの有効期間:  開始日(10日)---終了日(11日)
改訂版カルテの有効期間: 開始日(10日)---更新日(11日)---継続中

としている。

改訂版の有効開始日=元版の有効開始日であり、途中で更新されてもカルテとしての有効開始日は変わらないで存在している。

何らかの事由によりイベントの発生日とカルテの保存日が大きくずれた場合、そのことをカルテに記載する必要がある。

ただしレセプトへの記載は実際に処置を行った日、今の例でいえば9日にできる。特に月変わりの時など、経営上その方が望ましい場合があることを考慮している。

3.システムアーキテクチャー

3−1.JavaEE

OpenDolphinの配備面におけるアーキテクチャーは、

  • クライアント
  • JavaEEアプリケーションサーバー
  • データベース

から構成される典型的な JavaEE(Enterprise Edition)の3-tier システムである。

3−2.RESTFul Web Service

サーバーの機能は RESTFul Web Service として実装している。通信プロトコルは HTTP/HTTPS で、データはJSON形式である。クライアントからサーバーへのアクセスは次の通りである。

  • クライアントの要求は通信の詳細を隠蔽した Delegater オブジェクトへ委譲される。
  • DelegaterがアプリケーションサーバのRESTFul Web Service へ要求を送る。
  • Web Serviceは Session Bean から構成されており、Entity Beanを介してデータベースを検索する。
  • 得られたデータはWeb Service でJSONオブジェクトに変換され、Delegaterへ返される。
  • DelegaterはJSONオブジェクトをパースし、クライアントで利用できる形のオジェクトに変換する。

javaee-deploy

3−3.デザインパターン等
  • Web Service(Session Bean)は関連するビジネスロジックをまとめたファサードパターンを使用している。
  • 永続化インスタンスの識別子には、データベースで自動生成する物理キーを使用している(ビジネスキーは使用していない)。
  • 通信はステイトレスとしSession管理は行わない(シングルサインオン等、配備上の自由度を確保するため)。
3−4.アーキテクチャーまとめ

HTTP/JSONによる RESTFul Web Service としたため、オンプレミスとクラウドの両方へ対応できるシステムとなった。またこの形式はモバイルデバイスのサポートも容易であり、種々のアプリケーションが開発されている。

参考文献


  1. 皆川和史他: MML/CLAIMインターフェイスを装備したクリニック用JAVAベース電子カルテDolphinの開発 、第22回医療情報学連合大会論文集、2002
  2. James W. Cooper: Java実例プログラムによるデザインパターン入門講座、(株)ピアゾン・エデュケーション
  3. MedXMLコンソーシアム: MML Version 3.0.2規格書、2009
  4. 小林慎治: openEHR.jpから世界を展望する、Seag Gaia ミーティング、2009
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment