ORCA メーリングリストの話
ORCA ユーザーのメーリングリストで、大阪の八木高秀先生の
ORCAと連動した電子カルテをご使用中の方がおられましたら、
ご使用感を教えていただけないでしょうか。
という投稿をきっかけに医療用ソフトの議論が突如として活発化。
多少「あれ？」と思うようなところもありますが、現場で使っている先生方はこの手の問題に熱心ですね。熱意が伝わってきます。
OpenDolphin の話題も出ていたので、私もイントロ的な概要と現在注意しておいた方がいい点などをコメントしてきました。
カルテ記載内容のデータベースの永続化方法に関しては、ほぼほぼ解析できてまして、クライアントからではなく、別のツールを使って抽出もすることもできました。
『Save the DolphinS -OpenDolphin データ抽出ツール・プロジェクト-』
https://allnightnihon2b.net/blog-jp/?p=816
で案内しています。
データベースに直接アクセスして復号しているため、最終確定版だけでなく途中経過版も抜いてこれます。カルテに貼り付けた図版も別に画像ファイルとして抽出できます。
なんで、こんなものを作成したかといえば、opendolphin から他電子カルテへの乗り換えを考えた場合、途中経過版も含めて電子化して取り出さないと実質的にはデータ移行しにくいと考えたからです。
「データ移行」に関しては関心が高かったようですね。
また、ORCA に関しても気になっている点を挙げさせてもらいました。
ただ、現行の OpenDolphin を大幅に機能強化させるようなことは考えてません。以前は、手が空いたら着手しようかと考えていたのですが、某筋から「ORCA の技術的側面に関して調べてみては？」と提案されて、調べたところ、設計の古さが目についたからです。
この件に関しては以前このMLにも投稿しましたね。
例えば
『ptid のデータベース上での定義について』
https://ml.orca.med.or.jp/orca-users/msg14679.html
などの一連のやり取りをご覧ください。
今すぐということはないでしょうが、ORCA は将来的には再設計される可能性もあるわけで、その状況では、ORCA「だけ」に依存する上物には手を出しにくいかなあと思っています。
などなど。
ただ、取り扱いが微妙な問題も孕んでいるので、あくまであっさりとした解説です。
「取り扱いが微妙な問題」というのは（ここで細かい話をしてもしょうがないと思うので）
『横から見た OpenDolphin-2.7m』
『保健医療科学院 小林慎治が国家公務員法違反疑いで厳重注意を受けた件について』
『HorliX -wikipedia 風解説- にまつわるあれこれ』
あたりをご参照ください。
OpenDolphin マスタマイズの実際
ところで、この手の話をするときに、クライアントに実装した「いわゆる」ファイルバックアップシステムをまず取り上げ、次にデータ抽出ツールの説明をするようにしている。
そちらの方がわかりやすいと思いそうしているのだが、実は、実際の開発順序は違う。
時系列的には、まず、データ抽出ツールを作成し、その次に（ツールの副産物として）ファイルバックアップシステムに関するコードをクライアントに付け加えたというのが本当のところです。
これはコード上にも反映されている。
OpenDolphin のカルテインスペクタの文字情報だけを取り出すのなら、gettext という関数を使えばすむのだが、これだとカルテ上の右半分（処方や処置などを記載する欄）もベタな文字情報のままになってしまう。
過去の直近の処方内容をチェックする程度であれば、（処置区分なしの）文字情報だけでもかまわないと思うのだが、もう一歩踏み込んで処置内容毎に区分して処理したいというような場合、これだと後処理が必要になってしまう。
ところがデータベース上では各処置（スタンプ）には、それがどの区分に属するかの情報も含まれている。
これを活用しない手はないと思い、区分を読み取って条件分岐させてから、文字情報を抜く、というロジックにした。
最終的なアウトプットは単純に文字情報だけを抜いたときと変わらないのだが、ちょっと凝った統計処理をしたいというような場合、コードの修正がしやすいと思いそのような実装にした。
ファイルバックアップシステムに関わるコードは１００行にも満たないが、コードを書くときはこんな風にあれこれ考えながらやるものなんですよ。
ちょっとマニアックな話ですが、何かの参考になればと思い補足説明してみました。
HorliX に関しても言及
OsiriX や Horos の話題も出ていたので、年末の隙間時間をついて HorliX に関しても投稿してきました。
https://ml.orca.med.or.jp/orca-users/msg14953.html
当たり前のことを言ってもしょうがないので、気持ち開発寄りに振ってます。
例えば、Horos でROIを使うとき、使う毎にその描画色がくるくると変化すると
思いますが、その元になったコードは私が送ってます。
いわゆる ROI-color-rotation-UI というやつです。
このときの改変のやり取りは今でも残ってますね。
https://github.com/horosproject/horos/issues/342
ここら辺までは、Horos と協調していたんですが、当時（2018年）課題に
なっていた 64bit 対応がもたもたしていたことや彼らが若干「やりすぎ」て
しまうところが気になって、結局、独立してしまいました。
「やりすぎ」というのは、具体的には、ROI-color-rotation-UI でいうと
彼らは記録時のファーマットまで改変してしまってます。
ROI を XXXX.roi のようなファイルを書き出したとき、色情報まで入れ込んじゃっているので、互換性が崩れちゃってるんですよ。
上であげた github issues 上での議論を見てもらえればわかると思いますが、
元々は「ROI の描画色が単色だと視認性が良くないので、マルチカラーを扱える
ようにしたい」というかなりシンプルで（おそらく有用な）ユーザーさんからの
指摘から始まってます。
私も色が変わるのは便利だなと思いますが、記録するほどのことでもないと
思い、Horosの改変は取り込みませんでした。
「やりすぎ」と感じるのは、こういった点です。
ここら辺、そんなに説明したことはないので、興味を持ってもらえたらいいなあという気持ちがちょっとはいっています。
猪股弘明（ご連絡は twitter の DM や facebook の友達申請などでお願いします）
OpenDolphin-2.7m 開発者
