OpenDolphin Ver 6
ちょっと手が空いたので、OpenDolphin-2.7m を JakartaEE 9.1, java17 環境に移行した。
軽くまとめ。
主な変更点
主な変更点は二つ。
・画像の取り扱いの変更
・ウェブレイヤーの追加
まず、画像に関して。
これまで、画像の取り扱いが jpeg に限定されていたのだが、この制約を取り払った。
ただし、従来のデータベースとの互換性を保つため、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 とした。
保護中: OpenDolphin Ver 6 on JakartaEE 9.1, Java17 and WildFly26
保護中: OpenDolphin における Java 17 問題解決法および画像の新しい取り扱い方
大阪急性期・総合医療センターへのサイバー攻撃とカルテのバックアップ
某所に投稿した内容、転載。
大阪急性期・総合医療センターへのサイバー攻撃の件で「バックアップは取ってあるが、使用できない」という?な報道の仕方がされました。
おそらく、これ、ガイドライン的にはバックアップになってないです。
医療情報システムの安全運用のガイドラインは今年の4月に厚労省から改訂版が出されています。
https://www.mhlw.go.jp/stf/shingi/0000516275_00002.html
そこでは
『1.バックアップサーバ
システムが停止した場合でも、バックアップサーバと汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。
2.見読性確保のための外部出力
システムが停止した場合でも、見読目的に該当する患者の一連の診療録等を汎用のブラウザ等で見読ができるように、見読性を確保した形式で外部ファイルへ出力できるようにすること。
3.遠隔地のデータバックアップを使用した見読機能
大規模火災等の災害対策として、遠隔地に電子保存記録をバックアップするとともに、そのバックアップデータ等と汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。』
などの手法を取って、本システムが停止しても診療業務が継続できるような対応が推奨されています。
大阪の件では、(個人的に推測するに)バックアップの「データ」は取ってあっても、それを表示するようなシステムになってなかったものと思われます。
日本の SIer のダメな点だと思うのですが、下請け丸投げ方式では、システムの仕様は決められても、データ構造の詳細な設計やミドルウェアを経由しないデータ抽出方法の提供ができないんでしょうね。
開業医さん向けの電カルでも、ここら辺まで手が回っているのは、CLIUS と私のやつぐらいなものだと思います。
システムをオープン系で組んだ場合、DBは大抵、PostgreSQL か MySQL を使うので、データ構造がわかってれば、ミドルウェア・(システムの)クライアントを経由せずともデータの復号は可能なんですよ。
猪股弘明