保護中: OpenDolphin における Java 17 問題解決法および画像の新しい取り扱い方
大阪急性期・総合医療センターへのサイバー攻撃とカルテのバックアップ
某所に投稿した内容、転載。
大阪急性期・総合医療センターへのサイバー攻撃の件で「バックアップは取ってあるが、使用できない」という？な報道の仕方がされました。
おそらく、これ、ガイドライン的にはバックアップになってないです。
医療情報システムの安全運用のガイドラインは今年の４月に厚労省から改訂版が出されています。
https://www.mhlw.go.jp/stf/shingi/0000516275_00002.html
そこでは
『1.バックアップサーバ
システムが停止した場合でも、バックアップサーバと汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。
2.見読性確保のための外部出力
システムが停止した場合でも、見読目的に該当する患者の一連の診療録等を汎用のブラウザ等で見読ができるように、見読性を確保した形式で外部ファイルへ出力できるようにすること。
3.遠隔地のデータバックアップを使用した見読機能
大規模火災等の災害対策として、遠隔地に電子保存記録をバックアップするとともに、そのバックアップデータ等と汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。』
などの手法を取って、本システムが停止しても診療業務が継続できるような対応が推奨されています。
大阪の件では、（個人的に推測するに）バックアップの「データ」は取ってあっても、それを表示するようなシステムになってなかったものと思われます。
日本の SIer のダメな点だと思うのですが、下請け丸投げ方式では、システムの仕様は決められても、データ構造の詳細な設計やミドルウェアを経由しないデータ抽出方法の提供ができないんでしょうね。
開業医さん向けの電カルでも、ここら辺まで手が回っているのは、CLIUS と私のやつぐらいなものだと思います。
システムをオープン系で組んだ場合、DBは大抵、PostgreSQL か MySQL を使うので、データ構造がわかってれば、ミドルウェア・（システムの）クライアントを経由せずともデータの復号は可能なんですよ。
猪股弘明
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 コードも確認できたけど？
猪股弘明
半田病院とオープンソースと OpenDolphin
半田病院
手が空いたので、例の半田病院の報告書をちょい詳しめに読んだのだが、ちょっと微妙。
ファイルの暗号化の話は触れられているのだが、肝心のデータベースはどうなったのか？という件はほとんど触れられていない。
半田病院のシステムがどうなっていたかは知る由はないのだが、通常、電カルの主要な情報は検索性高めるためにデータベースに格納する。
一般に、電カルのデータベースの置き場所を外部から特定して侵入するのは難易度高い。今回も周辺の設定ファイルなどを荒らしただけのような気がしないでもない。
なんで、これで業務全体がストップするのか、よくわからない。
オープンソース
半田病院の件の影響なのか「では、オープンソースの電子カルテはセキュリティの観点から安全なのか？」という話題が某所で上がった。
さて、どうなんでしょ？
OpenDolphin
私がある程度知っているオープンソースの電子カルテというと OpenDolphin なのだが、これに関していえばログイン認証などはクローズドで開発されたものに比べればやはり甘いと思う。
なにしろログイン認証の方式などセキュリティに関わる情報を教えているようなものなので、クラッキングする側から見れば「事前に問題をバラした筆記試験に挑む」ようなものだろう。
だが、それがそのまま弱点につながるかというと、そんなに単純なものでもないと思う。
半田病院の件で言えば、切れ切れに漏れてくる情報から察するに担当者がどの程度の被害なのかさえ把握できていなかった節がある。
これがもしオープンソースであり、担当者がシステムに対してある程度の知見を持っていたならば、状況はかなり違っていたものになっていたのではないかと思う。
（追記）この問題に関しては、WebDolphORCA のページなどで「３層クラサバ構成にする」というアイディアを出してます。
大阪急性期・総合医療センター病院との対比
大阪の病院でも似たような事件が起きた。
だが、こちらの方は早期に復旧した。
これは、この病院がバックアップデータを保管していて、そこから直接カルテ記載情報を復号することに成功したからだ。
半田病院はバックアップデータを取るのを怠っていたか、取っていても復号できなかったとしか考えようがなく、かなり初心者的なミスと考えられるだろう。
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 のデータベースに入れ込む。
改行処理が甘かったり、斜字やアンダーラインに対応してなかったりするのだが、まあまあといったところ。