2015 年あたりから OpenDolphin (オープンドルフィン)という電子カルテのメンテを個人的に取り組んできたのだが、設計の古さが目立ち始め、結局、新規に作り直すことにした。
当初は OpenDolphin 2.7m の改変程度にしておこうと思って OpenOcean (2.0) などと呼んでいたのだが、やっていくうちに
・java の GUI コンポーネントの swing を使い続けるのは今後のことを考えるとリスクでしかない
・ドルフィンのデータ構造が(今の時代から見ると)無駄に複雑すぎる
などのアラが目について、時間があるときに適宜作成していったら、もう OpenDolphin とは全く別の何かになってしまった。
全体的な設計コンセプトを図示するとこんな感じなる。
最終的なクライアントはブラウザなので、使用しているだけならあまりこの点は気がつきにくいと思うのだが、サーバをバックエンドとフロントエンドに分けた。
いわゆる3層クライアント・サーバーシステムというやつだ。
手をつけた当初は、コーディング上の煩雑さ(なにしろサーバープログラムを二つ作る必要がある)に正直嫌気もさしていたのだが、形になっていくにつれ、この基本設計の良さがわかるようになっていった。
例えば、(これは今まであまり強調してなかったが)データベースをバックエンドとフロンエンドで二つ抱えられるので、素直に構成しただけで、データの冗長性が担保されている。
ブラウザで記載したカルテの情報は、
ブラウザ→フロンエンドサーバー→バックエンドサーバー
というふうに流れるが、「フロントで情報を受け取ったら、そのままバックエンドに転送すると同時にデータベースに記録」し、「バックエンドはフロントからの情報を受け取ったらまずはデータベースに記録する」と「素直に構成しただけ」で、同一のカルテ情報が2か所で保管されることになる。
現在、開業医向け電子カルテで主流となりつつあるクラウド型と比較したとき、この構成のメリットはより顕著になると思う。
クラウドのサーバーと医療機関との通信路に障害が起きてしまう、クラウドサーバー自体に障害が発生する、といった状況になると、原則、このシステムは全く機能しなくなる。
が、3層クラサバであれば、バックエンドとの通信を切ってしまい、フロントエンド-ブラウザ間のみのシステムとして稼働させてしまえば、通信障害が起こっても or バックエンドに障害が発生しても、支障なく臨床業務を継続することができる。
なお、データ構造を決めるにあたって留意した点などを
なぜ、全国統一カルテは無理筋なのか?
-カルテ系と画像系のデータ構造の本質的な相性の悪さ-
(EHR-DICOM data structure mismatch)
に書いておきましたので、興味のある方はご一読ください。
air-h-128k-il