OpenDolphin Ver 6
ちょっと手が空いたので、OpenDolphin-2.7m を JakartaEE 9.1, java17 環境に移行した。
軽くまとめ。
※ 以下の記事内でも書いてますが Ver6.3 & 6.4 は例外的に Ver2.7m 系列の単純な JDK アップデートバージョンです。
だから、データ構造なども 2.7m と同一。それゆえ使いにくい側面もあったりするのですが(この記事参照)、カスタマイズする場合、こちらをベースにした方がいいでしょう。
主な変更点
主な変更点は二つ。
・画像の取り扱いの変更
・ウェブレイヤーの追加
まず、画像に関して。
これまで、画像の取り扱いが jpeg/png に限定されていたのだが、この制約を取り払った。
ただし、従来のデータベースとの互換性を保つため、jpegByte あたりのコードには直接変更を加えず、新規に画像保管用のカラムを加えた。
これまで、データ構造は LSC 時代の 2.7 と全く同一にしていたのだが、この変更でこの原則は崩れた。
ただし、API にはある種の追加はしたが、これまでのものを削除することはしなかったので、以前のバージョンのデスクトップアプリを使えば、使用感は変わらないと思う。
一種の上位互換。
API の追加は、まだ進行中。煮詰まってない。
画像のフォーマットは山ほどある。どこまでサポートするかは現時点では決められない。
次に、ウェブレイヤーの追加に関して。
以前から、「クライアントは Java デスクトップアプリである必要はない」ということは言われていたのだが、ではどう構成するのか?という具体的な議論はなかった。
個人的には、3層クラサバ化がいいのではないかと思っていたので、今回、OpenDolphin HTML・PDF Viewer をウェブサーバー化して、フロントエンドサーバーとした。
諸々の機能は実装中。
サーバーサイド
フロントエンドサーバーを加えたので、単に「サーバー」と言った場合、従来のサーバーと混同してしまう。
そこで、従来のサーバーを BackendServer と名称変更した。
クライアントサイド
前述のように、クライアントは従来のデスクトップアプリと新規に作成したフロントエンドサーバー(ブラウザタイプ)に別れた。
デスクトップアプリ
今回のアップデートが最後でしょうか。
フロントエンドサーバー(ブラウザ)
以前に dolphorca と呼んでいたものがこれにあたる。
名称
これまでにも、ノーマル 2.7-m ベースのいくつかのカスタマイズバージョンがあった。
例えば、以前に書いたように(『聴診音クラファンからの・・・OpenDolphin』など参照)、研究支援用のプロトタイプバージョンなど。
ところで OpenDolphin のアプリケーションサーバーといえば、WildFly がデフォルトである。
が、若干修正することで GlassFish でもデプロイ程度はできる(正常動作はしないが)。
こういったバージョンも存在した。
このように非公開のいくつかのバージョンがあって、バージョン番号はいささか混乱していた。
そういった経緯で今回移行したプロジェクト群を総称して(数字的には 2.7 から一気に飛ぶが) Ver 6 とした。
Ver6.3
諸々の事情で Ver6.3 のみ単純な実行環境のアップデート版とした。
(だから、データベースは 2.7m と完全互換。その代わり、クライアント起動時に JVM に特別なオプションを渡す必要がある)
Java17, JakartaEE 9.1 環境で動作する。
バイナリは関係者のみに配布。
ソースコードは github: https://github.com/Hiroaki-Inomata/OpenDolphin-6.3 で開示。
(追記)バイナリを配布したバージョンは 6.3.1 とした。
元が GPL だったとはいえ、このソースコードを一般公開するのは、実務的にはかなり難しい。
公開する準備はしているが。
https://github.com/Hiroaki-Inomata/OpenDolphin-6.3.1
現在著作権は、メドレーが保有しているからだ。
迂闊に公開してしまうと著作権侵害ともとられかねない。
ドルフィンの権利関係はスッキリとはしておらず、こういった場合には「オープンソースのライセンスがあれば、なんだって許される」といった幼稚な考え方は捨てるべきだ。
保護中: OpenDolphin における Java 17 問題解決法および画像の新しい取り扱い方
保護中: sql, jdbc, hibernate による PotsgreSQL LOB の取り扱い【開発者向け】
OpenDolphin は『真正性』すら満たしていないかもしれない
以前にもサーバの API を通して偽造カルテをデータベースに入れ込む、みたいなことをやったのだが(この記事の『医療向けオープンソースソフトウェアのセキュリティに関する問題点』の項参照)、
今度はもうちょっと巧妙なカルテの改竄(対策)を考えてみる。
OpenDolphin では、hibernate というORMを使って、「カルテを修正したときは、元のバージョンは消去せず、必ず新しいバージョンを作る」ということで改竄を防止している。
なのだが、これは「データベースにアクセスするときは hibernate を使う」というのが大前提になっている。
実際のカルテ実体のデータは、データベースの blob 領域というところに保存されている。当たり前だが blob オブジェクトには hibernate を使わずともアクセスできる。
最も単純な例を考えてみよう。
id=11 のレコードに blob で test と書き込む。
ところが、このときの oid(lob への一種のポインタみたいなものです)は、データベースに直接問い合わせることで知ることができる。
このときは 47410。
この値を使って、blob を書き換えることは可能だ。
‘test’ は16進数表記だと 0x74657374 になるのだが、これを 0x74747474 に変更する。
hibernate を使って id=11 のレコードを再度復元すると該当する blob は ‘tttt’ (0x74747474)となっている。
実際は、blob を書き換えた時に oid も変更されてしまうので(47410 → 47412 に変化している)、よくできた管理者であれば、この異常に気がつくと思うが、そうでない人ならば、改竄されたところで気がつきもしないだろう。
OpenDolphin はソースコードが公開された時点では「データ構造が複雑なので、真正性は担保されている」みたいなことが言われていたが、データ構造が複雑だからといって、それは解読不能ということでも、想定していた方法以外での操作が不可能ということでもない。
思うのだが、データベースなどの何らかのストレージに医療記録を平文で「普通」に記録する方式はもうそろそろ限界なのかもしれない。
かといって、ブロックチェーンみたいな話をいきなりされてもなあ。。。という感じで、ここら辺は難しいところですね。
なお、紹介状などをスキャナで電子化して、システムに入れ込むような場合は、既にガイドラインは示されていて
・管理者の電子署名
・タイムスタンプ
を施すことでOKとされています。
逆にノーマルPDFを単にシステムに取り込んだだけでは、正式な医療記録とはみなされません。
政府の医療DXの各種政策を見るに、HPKI 基盤を使って真正性を担保するようなトレンドになっていくんでしょうか。
ところで先ほど openEHR というオープンソースの EHR のサイトを覗いてきたが、ここら辺は配慮がされているようで、記録は persistence layer という一種の抽象化されたレイヤーを通して行うようだ。
要するに永続化の手段まで具体的に決めてしまうと、そのセキュリティホールを突いて記録を改竄する輩が出てくるため、特定のストレージに限定しないということなのだろう。
ところで、openEHR はけっこう間違った情報が流れているみたいですね。よく PHP で書かれて、みたいな紹介のされ方しているが、普通に Java コードも確認できたけど?
猪股弘明