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 はソースコードが公開された時点では「データ構造が複雑なので、真正性は担保されている」みたいなことが言われていたが、データ構造が複雑だからといって、それは解読不能ということでも、想定していた方法以外での操作が不可能ということでもない。

思うのだが、データベースなどの何らかのストレージに医療記録を平文で「普通」に記録する方式はもうそろそろ限界なのかもしれない。

かといって、ブロックチェーンみたいな話をいきなりされてもなあ。。。という感じで、ここら辺は難しいところですね。


ところで先ほど openEHR というオープンソースの EHR のサイトを覗いてきたが、ここら辺は配慮がされているようで、記録は persistence layer という一種の抽象化されたレイヤーを通して行うようだ。
要するに永続化の手段まで具体的に決めてしまうと、そのセキュリティホールを突いて記録を改竄する輩が出てくるため、特定のストレージに限定しないということなのだろう。

ところで、openEHR はけっこう間違った情報が流れているみたいですね。よく PHP で書かれて、みたいな紹介のされ方しているが、普通に Java コードも確認できたけど?

 

猪股弘明

 

半田病院とオープンソースと OpenDolphin

半田病院

手が空いたので、例の半田病院の報告書をちょい詳しめに読んだのだが、ちょっと微妙。

ファイルの暗号化の話は触れられているのだが、肝心のデータベースはどうなったのか?という件はほとんど触れられていない。

半田病院のシステムがどうなっていたかは知る由はないのだが、通常、電カルの主要な情報は検索性高めるためにデータベースに格納する。
一般に、電カルのデータベースの置き場所を外部から特定して侵入するのは難易度高い。今回も周辺の設定ファイルなどを荒らしただけのような気がしないでもない。

なんで、これで業務全体がストップするのか、よくわからない。

オープンソース

半田病院の件の影響なのか「では、オープンソースの電子カルテはセキュリティの観点から安全なのか?」という話題が某所で上がった。

さて、どうなんでしょ?

OpenDolphin

私がある程度知っているオープンソースの電子カルテというと OpenDolphin なのだが、これに関していえばログイン認証などはクローズドで開発されたものに比べればやはり甘いと思う。

なにしろログイン認証の方式などセキュリティに関わる情報を教えているようなものなので、クラッキングする側から見れば「事前に問題をバラした筆記試験に挑む」ようなものだろう。

だが、それがそのまま弱点につながるかというと、そんなに単純なものでもないと思う。

半田病院の件で言えば、切れ切れに漏れてくる情報から察するに担当者がどの程度の被害なのかさえ把握できていなかった節がある。

これがもしオープンソースであり、担当者がシステムに対してある程度の知見を持っていたならば、状況はかなり違っていたものになっていたのではないかと思う。

(追記)この問題に関しては、WebDolphORCA のページなどで「3層クラサバ構成にする」というアイディアを出してます。

 

猪股弘明

 

OpenDolphin HTML/PDF Viewer → WebDolphORCA

カルテ記載内容を html に打ち出せたらエディタを付けたくなるのが人情というものw

なお、エディタに関しては HTML5 の普及に伴い、それ以前のものが軒並み時代遅れになった感があるので、新規に作成した。→ YouTube 動画

 

データベース → 読み出し → html はできているのだから、基本的にはこの逆順の情報経路を確立すれば、ブラウザ型の電子カルテちっくな何かはひとまずできる。

まだ本気でやるかどうかも未定なのだが、(いつもの悪いクセが出て)とりあえずロゴを作成ww

先人に敬意を払って、いるかのフォルムとカラーリングにシャチの紋様にしたのだが、微妙に「コレジャナイ」感が漂っているwww


手っ取り早くは OpenDolphin にウェブレイヤーを被せる、というアプローチでいいんだろうな。
ログイン認証に関しては別件で作成済み。

この前に医療機関 ID の 1.3.1.6.9414.* 形式は撤廃してある。

OpenDolphin HTML/PDF Viewer もあることだし、ここらへん組み合わせてプロトタイプにする予定。

エディタも作成。

動画も含めて画像の類の取り扱いはけっこう面倒かも。


以前にこのエントリで

データベース → 読み出し → html はできているのだから、基本的にはこの逆順の情報経路を確立すれば、ブラウザ型の電子カルテちっくな何かはひとまずできる

と「逆順」、つまり

html → 書き出し → DB

のことを書いていたが、若干、着手。

本当はデータ形式も clob 使いたいんだが、互換性のことを考え、従来の dolphin のデータ形式に合わせる。

試しにテストコードを書いたが、まあまあ、動いた。

例えば、こんな html ファイルがあったとする。

これを dolphin のデータベースに入れ込む。

改行処理が甘かったり、斜字やアンダーラインに対応してなかったりするのだが、まあまあといったところ。

 

猪股弘明

 

OpenDolphin → OpenOcean → ?

ところで本ブログでたびたび言及されている電子カルテ OpenDolphin だが、作り直した方がいいという意見もある。

私は OpenOcean 2.0 とか呼んでいたし、ベンダーさんもこの種の提案をした人はいる。

OpenDolphin 自体は現在でも使えるし、(ブラウザ型が嫌いな人は特に)気に入ってくれている人は少なからずいるので、そういった人にとっては「作り直すというのは何で?」だろう。

というわけでその辺の解説。

 

(続く)

 

猪股弘明