OpenDolphin HTML/PDF Viewer プロジェクト

 

はじめに

以前に Save the DolphinS というプロジェクトをやっていた。

OpenDolphin という電子カルテは、データ構造に癖があり、カルテ記載内容の抽出ですら、それなりに難しい。
そのため Save the DolphinS では、データベースに直接アクセスしてデータの抽出を行うソフトの作成を行なっていた。ソフトは -味も素っ気もない言い方だが-「データ移行ツール」と呼んでいた。

「データ移行ツール」は dolphin データベースに直接アクセスして、一応

・カルテ記載内容全履歴→プレーンテキスト(画像などの特殊タグ付き)+画像など

・カルテ記載内容全履歴→ rtf 形式ファイル(画像などの特殊タグ付き)+画像など

に抽出するところまではできていた。(どういうものだったかは『電子カルテからの患者データの吸い出し』あたりを参照してください)

OpenDolphin 本体はおろかアプリケーションサーバである WildFly がなくてもデータベースさえ活きていれば、このソフト単体で動作してデータ抽出が行えるのでそれなりに重宝していた。

ただ、これだと、データを他のシステムに移行する場合には便利でも、たとえば保管はしておきたいが閲覧だけでいいという場合、視認性の面で今ひとつの感は拭えない。

何かうまい解決方法はないかなと思っていたのだが、ひょんなことから移行ツールの出力を html 形式で書きだせばいいことに気がついて、ソースコードを改変して試してみたところ、まずまずうまく動いた。

細かいところでさらに修正したいところはあるのだが、例えば、以下のカルテ画面(↓)

を、html 形式で書き出すとこんな感じになる。

 

2号用紙風のレイアウトやフォントの属性、画像の添付位置までほぼ完全に再現されていると思う。

データ抽出というコンセプトは同じでも、(移行を考慮して)データをテキストと画像などに分離させて出力するのと(閲覧性を重視して)それらをを html にまとめるのは、使用目的の点で微妙に異なる。

また、この機能を移行ツール内に同居させておくのは、ソースコード管理の面でも何かと不便だ。

そこで、この機能を分離させ、単独のソフトとして独立させることにした。

今後はこちらを

OpenDolphin Viewer
OpenDolphin HTML Viewer
OpenDolphin HTML/PDF Viewer (PDF 出力にも対応したため改名)

と呼ぶことにする。

 

開発グループを代表して
猪股弘明

背景色を変更

実務的にはまるで意味がないのだが、白背景は味気ない気がするので背景色を OpenDolphin 特有の薄い緑( dolphin’s green というのだそうだ)に変更。

ドルフィン感が強くなった。

 

レスポンシブ対応

最近のウェブデザインは凝っていて、ブラウザの横幅を変更するとレイアウトを自動で調整してくれる。レスポンシブデザインなどというようだ。
この仕組みのおかげでPCのブラウザでもスマフォのブラウザでも、それなりに「見れる」レイアウトになっている。
これを狙って CSS を若干修正。

通常時がこうだとすると

ブラウザの横幅を縮小させるとある値(ブレークポイント)を境に右のいわゆる P 欄が左(SOA欄)の下に回り込む。

スマフォで閲覧することなどないかもしれないが。

 

P 欄(カルテ右半分)の検討

これまで、カルテの右半分(P 欄)は文字情報だけ抜いてきたが、実は処置・薬剤のレセ電コードも抜ける。

まだ、うまくまとめきれてないのだが、かなり雑にデータを書き出すとこんな具合になる。

赤枠で囲んだ部分が処置や薬剤の識別子(コード)で、その多くはレセ電コードと同一なはずだ。

実運用としては、ドルフィンから処置内容を ORCA に送った際に、この情報を受け取った ORCA はこれらコード番号に基づいて保険点数や窓口負担額を計算し、最終的にはレセプトに反映させている。

病院のシステムを入れ替えた際に、このコードが引き継げなくて処方内容を一から打ち込むことがよくある。とても負担だ。

本プロジェクトはデータの「閲覧」を強く意識しているが、上記の点に留意し P 欄に関しては若干レイアウトを崩してもこれらコードが表示できるようにしたいと考えている。

P 欄(カルテ右半分)の検討(続き)

通常 P 欄に記載される内容は、診断料や処方のほか各種検査のオーダーなどもある。
だから、まずドルフィン元カルテをこんな風にした。

カルテ左の SOA 領域よりも難しいのは、項目毎に処理を変えなくてはいけない点。

ここら辺、工夫してコードを修正。
現状だとこのようになっている。

プロトタイプとしては、十分な出来だろう。
なお、レセ電コードは、某所で聞いて見たところ「あったほうがいい」ということだったので、多少元カルテの表示と異なってくるが、表示させることにした。

また、この改変を機に元の OpenDolphin のコードは全て削ぎ落とした。
単純に表示させるだけなら、

dolphin データベース >> 読み込み >> オブジェクトの生成 >>
適当に修正して html 用に変換 >> 書き出し

とやった方が楽なのだが、P 欄に関してはレセ電コードを打ち出せるようには構成されていないので、結局、ここら辺のコードは全て廃棄した。
(SOA 欄は特殊タグを表示させる関係上、移行ツールの頃から使っていない)

html → PDF 変換

ところで、OpenDolphin の標準のカルテ画面の PDF 文書作成機能は、文字などもベクトルデータに変換していわば「画像」として PDF を生成しているようだ。
Mac の場合、フォントの関係(物理フォントと論理フォントというものがある)でデフォルトでは文字化けしてしまう。

そちらの修正はひとまずおいて、html → PDF 作成ができないか検討。

あれこれやっていたら、以下のように
フォント埋め込み形式の PDF が生成できた。

データ移行に関する厚労省の見解

実は、公式な文書はない。

ガイドラインの要請からして

・カルテ記載の文字情報や診断の根拠となったような画像の類

・処置内容の文字情報

・修正履歴や途中経過版

は最低でも移行しなければならないでしょう。

口頭でもそれっぽいことは言っていた。

現在、問い合わせ中です。→結局、明確な回答は得られず。

「最近、安全管理に関するガイドラインを公開したので、そちらを見ていただいて・・・」というような感じでお茶を濁そうとする。

「これだから、日本の医療 IT は」と思わないでもないが、文句を言っても始まらないので、ガイドラインに目を通す。

医療情報システムの安全管理に関するガイドライン 5.2 版』というのがそれのようだ。

んー、しかし、これ、(例の半田病院の件を受けてだろうが)従来の電子カルテの3要件などの基本的要件に加えて、さらにシステムには医療記録のバックアップの仕組みを付け加えなさいよ、と言っているだけのような?

本当に知りたいのはバックアップ時に書き出す情報の種類や質といったことなのだが。

ただ、以前に比べれば、要求は具体的にはなってきた。

ポイントとなりそうなところを抜き出しておく。

1.バックアップサーバ
システムが停止した場合でも、バックアップサーバと汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。

2.見読性確保のための外部出力
システムが停止した場合でも、見読目的に該当する患者の一連の診療録等を汎用のブラウザ等で見読ができるように、見読性を確保した形式で外部ファイルへ出力できるようにすること。

3.遠隔地のデータバックアップを使用した見読機能
大規模火災等の災害対策として、遠隔地に電子保存記録をバックアップするとともに、そのバックアップデータ等と汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。 

(p. 61)

今回の HTML/PDF Viewer に絡めて言えば、このソフトを使って定期的にデータベースからバックアップを取っておけば、上記の条件を満たしているのは自明だろう。
「汎用のブラウザを使って」とあるが、html を表示できないブラウザはあり得ないので、お釣りがくるくらい(なにしろ画像や処方薬の薬剤コードまで表示してくれる)条件をクリアしている。

一応、バックアップは取っておいた方がいいとは思うが、データベースさえ生きていれば、サーバが停止してもこの条件は満たしている。

ところで、なんで厚労省の役人がお茶を濁そうとしたのかわかるような気もする。
商用の電子カルテでも上記の条件を満たしているシステムは(現時点では)そうは多くないからだ。

病院の電カル・HIS の場合、半田病院や大阪急性期総合医療センターの件で明るみに出されたが、ガイドラインで推奨されている基準でバックアップシステムを稼働している施設はほとんどない。

開業医さん向けの電カルは、この点はかなり改善されてきて、

・CLIUS

・owel

などは、この機能が公式に提供されている。
いわゆる商用の電子カルテとは一線をかくすが、

・ダイナミクス

・OpenDolphin-2.7m (系列。今回、説明したバージョン。他の派生物に関しては完全に把握しているわけではないが、おそらくない)

も、こういった機能が充実している。

 

オープンソースと 生成 AI

タイトルはおっきめにつけたが、ネタは東大松尾研が生成 AI のプレスリリースで「オープンソース」というワードを使ったことに関するあれこれ。

実際に適用されたライセンスは CC BY NC 4.0 で、オープンであるが「商用利用不可」というもの。

これは「商用利用不可」という制限があるので OSI がいうところの「オープンソース」ではない。

そういったわけで、プレスリリースされた直後から、その点を指摘する声が多数あがった。

いつもの話と言われればそうなんだが、今回は世間的に注目を集めている研究室の生成 AI に絡んでいるという点で従来の諍いみたいなものと違っていたように思うので、その点を意識してあれこれ書く。

なお、顛末を先に書いておくと、松尾研がプレスリリースに訂正を入れるということで騒動は決着ついた。ただし、訂正後はデータ公開云々みたいな話はどこにも記載されておらず、この点も興味深かった。

今回の件がこれまでの論争と違っていたのは、「細かいこと(OSI の定義に従っているかどうか)にこだわる必要があるのか?」という正面切った反論が出てきたこと。

この件は宗教論争的側面が多いのでここではスルー。

興味深かったのは、これに伴ってよく出てくる「オープンソースという言葉は、オープンソースな人々が初めて使った言葉なので、OSI に従うべきだ」みたいな都市伝説的な言い分が完全に論破されたこと。

いかにも SNS 。例えば、このスレあたり参照。

元の記事にもあるように open source という言葉は、オープンソース教祖が特別な意味を付与する以前から普通に使われていた。

また、「オープンソースは商標が成立しているので、この言葉を使うときは OSI の定義に従うべきだ」というよくあるアレも完全に論破されている。

これなんぞ参照。

むしろ事実は逆で「オープンもソースも一般的なワードなので、ソフトウェアの分野で商標は成立し得ない」というのが正しいのだが、皮肉なことにこの著作権的な常識が強調された結果になったようだ。

まあ、今までがおかしかったんだけどね。

オープンソースはよく宗教や政治的信条(共産党とかさ)に喩えられるが、今回の騒動でその党派的で胡散臭い側面が白日の元に晒され、完全に否定されたようだ。
この点が従来の小競り合いとは違っていたように思う。

 

猪股弘明

爆縮

初出は facebook の某グループです。
突如、iPS の話題が出てくるのは、並行して人気のスレだったから。
深い意味はないです。


潜水艦タイタン号の破壊メカニズムは「爆縮」と推測されてますが、構造物が外圧で部分的に壊れていく「圧壊」とは物理プロセスが違います。

物理畑の人が「爆縮」で想起するのはプルトニウム型原子爆弾の起爆装置の原理となった「爆縮レンズ」でしょうか。

アナログな爆薬と電子制御で爆弾中心に設置されたプルトニウム塊に「高爆圧を」「周囲から同時に」「瞬間的に」かけるのがキモです。(こうしないと臨界状態にならない)

原子爆弾というとアインシュタインの E=mc^2 が有名ですが、これは単に基礎的な原理を表しているに過ぎず、実際にプロダクツ?をリリースするにはプルトニウムやウランの精製や起爆装置などの周辺技術も整備しないといけません。

爆縮レンズの担当はフォンノイマンだったらしく、彼の超人的な仕事ぶりが wiki あたりにも載っています。
https://ja.wikipedia.org/wiki/%E7%88%86%E7%B8%AE%E3%83%AC%E3%83%B3%E3%82%BA
(GIF も同ページより転載)

しかし、今から見てもマンハッタン計画はすごいですね。
リーダーをオッペンハイマー、理論や実験の実務をフェルミ、数値解析はフォンノイマン、派生的なテーマをファインマンあたりがやっていたという贅沢すぎる豪華人材の投入っぷり。

比較するのも可哀想な気もしますが、iPS は(原理は私もすごいと思いますが)すり寄ってきた人たちがダメすぎた気がします。

なお、なんでこのスレを立てたかと言えば、どこかで「乗員はどうなったんでしょうか?」というような投稿を見かけたから。
まず、探索時に衝撃音を観測したという報告があったので、「圧壊」ではなく「爆縮」であった可能性が高くなりました。
破壊メカニズムのあたりがつくと、理論を使って何が起こっているかの大雑把な見積もりができるようになります。
爆縮は瞬間的に起こりますが、これはミリ秒オーダーでおこったらしいです(ネット上で計算した人がいた)。ミリ秒オーダーだと、外界と熱交換している時間はほぼないため、断熱圧縮という現象がおこります。
この効果で乗員の体表温度は数千度に一気に上昇(おそらく黒ごけ)、ただし、生体の熱伝搬はそれほど早くないため、内部臓器はおそらく「レア」。続けて(現実のタイムスケールではほぼ同時に)圧力波と潜水艦構造物が乗員を襲います。身体各部位の損壊は相当激しかったと思われます。
このシナリオだとすると、恐怖を感じることなくほぼ即死でしょう。

 

MOSS というのは反社組織かなにかなのか???

最近、更新サボり気味なので、身の回りで起こったことなど。

OpenDolphin に関連して前々からおかしな情報(ほとんど誹謗中傷と言っていい)を垂れ流している小林慎治とかいう男がいるんだが、最近、こいつが書いた間違いだらけのブログ記事が見つけたので所属先に連絡して削除してもらった。

元のタイトルは『openoceanによるgpl違反事例について』というかなり物騒なもの。

論旨はいつものアレ。

OpenDolphin は GPL で、かれこれという著作権者がいる、にもかかわらず、air-h-128k-il (当時、もっぱら私が使っていたネット上でのハンドルネーム)は、 そういった権利関係を根こそぎ無視して自分の著作として公開しているから GPL 違反だ、というもの。

記事が書かれたのは 2018 らしく、この時点でよくもまあこれだけ、出鱈目なことをかけたものだと思う。

まず、大前提としてこれが書かれた時点では、OpenOcean に関しては LSC と連絡を取っていて、この形態で公開して OK という許可をもらっている。小林はこの事実関係を知りようがないわけだから、書かれている内容は推測の域を出ず、事実としても間違っている。内容に関してもほとんど妄想レベルの作話です。

私もけっこう記憶が曖昧になっているが、この時期、LSC は経営陣に変化があって、OpenDolphin に関してそれまで広報されていた内容と実態とが大きく食い違っていたため、LSC 自体が内部から開発や広報の方針などを大きく変えていた時期だ。

まず、OpenDolphin は医師が協力して・・・という宣伝文句だが、これは文字通りほとんど宣伝用のアナウンス。

文献的な調査からも明らかになりつつあるが、基本設計は e-Dolphin 時代のもの。

また、開発フローも

e-Dolphin 時代のコード→LSCによる新機能の企画・実装→下請けに発注

が基本という話で、このフローに README に記載されている医師の関与は「ほとんどない」そうだ。

特に増田茂に関しては「データ互換性のない同一名称プロダクツをあたかも互換性のあるかのように広報している」ということで、メドレーからは作者扱いはされておらず、むしろ監視・注意の対象となっていたほどだ。

要するに小林は、LSCが一時期(多分に宣伝目的のために発表した)広報内容をなんの検証もなく「これが事実だ事実だ」と盲目的に言い募っていただけなのだ。LSC自体が訂正入れているにもかかわらず、自分の主張の方が正しいって言い張る神経がよくわからない。

なお、タイトルに「反社」といれたのは、当方管理下のブログに小林から訴訟を仄めかす内容の投稿があったからだ。

 

(追記)MOSS(医療オープンソースソフトウェア協議会) というのは、法人格も何もない任意団体のようっすね。
厚労省本省の方も言っていたが、こんなしょうもない主張をわざわざそれっぽい団体名で権威づけしてまで発表しなければいいのにと思う。その時はいいかもしれないが、収束させるのに手間がかかることこの上ない。

(追記2)あまりにも出鱈目な内容が多いせいなのか、twitter に関しては鍵垢になったようですね。
アイコンのピカチュウは(おそらく)利用許可とってないでしょうから、相変わらず、著作権違反しまくってますね。

(追記3)まあ、国立保健医療科学院という組織自体、業者との癒着の温床になっているようですが。

(続く)

 

次世代型 HorliX

現行の HorliX を Mac AppStore からリリースしたのは、2018 年のことだから、かれこれ 5 年前のことになる。

売れ行きも評判も上々で気を良くしていたんだが、すぐに今も続く懸案事項が持ち上がる。

それは当時のアップルが打ち出した

OpenGL の廃止・Metal への移行

という方針だった。

HorliX に限らず、画像系のアプリはほとんど OpenGL に依存していたから、それなりの騒ぎになったことは覚えている。

幸い?すぐに廃止ということにはならなかったが(ちなみに、今でも OpenGL は使えている)、Metal が普及するにつれ、そのパフォーマンスの良さに「移行はやむなし」という雰囲気に変わってきたように思う。

私も、この方針が打ち出された直後、次期バージョンのことを思い浮かべた。

当初は、まずプラットフォームを Qt に移そうかと考えていた。
Qt はかなり早い段階から、Metal 対応を進めていたので、構想としては悪くなかったと思う。実際、試験的にプロトタイプも作成したりした。

ただ、どうしても本気になれなかったのは、HorliX を構成する膨大なライブラリ群もまとめて Qt で面倒をみなくてはならなくなることだった。

何か本質的でない気がした。

Metal への移行が思っていたより緩やかなことがわかってくると、アプリの Metal 対応は次第に考えなくなっていった。

ここ数年はそんな感じだった。

ところが、別件で画像処理関係で Metal を触ってみると、意外に扱いやすいことがわかってきて、HorliX 云々は別にしていくつか試験的なコードを書いてみた。

例えば、2D ビューア。

3D ビューア。

機能を豊富に盛っているわけではないが、最低限のラインはできているんじゃないかと思う。

当初は何かに使うという予定はなかったが、Metal による 2D や 3D 画像の取り扱いに慣れてくると、「これらを使って、次期 HorliX (PHORLIX と呼んでいる)できるのでは?」と思うようになった。

ここからの話は長くなりそうなので、いったん切ります。

 

Metal 関係覚書

たまにしか使わないので基本概念が抜けがち。

シェーダー

具体的には ***.metal ファイルがそれ。
頂点データと色の処理を決めているファイル。これだけだと有り難みがピンとこないが、実際にはこれが(並列処理可能な) GPU で処理される、というのがミソ。
このおかげで、頂点が増えれば増えるほど、効率的な処理ができるようになる。

なお、この時、使用される言語が MSL (Matal Shading Language)。

Metal は OpenGL とは違い、***.metal ファイルはビルド時にプリコンパイルされれる(.metallib というファイルが生成される)。OpenGL では実行時にコンパイルされるので、この点も高速化に貢献してそう。