イルカは言葉を覚えたか?

歴史的評価の段階に入ってきたせいか、「開いたいるか」ことオープンドルフィンに関して力の入った記事が散見されるようになった。

2.7m 系や HTML/PDF Viewer のメイン開発者の猪股先生なぞこれまでにも言いたいことは山ほどあったんじゃないかという気するが、実はリアルタイムではそれほど多くは語ってはいない。

私もこの記事を書いている最中にそういう気分になったのだが、「彼ら」と対話する気が起きなかったのではないかと推測する。
明らかな事実誤認は指摘しておく必要あるが、変なリアクションされても困るし・・・といった風に。

彼らの語る技術的な内容もそうなのだが、強調するポイントが予想の斜め上をいくことが多々あり、さらにそれが攻撃的な口調で語られるものだから、リアルタイムであったら、とてもまともに返せそうな気がしない。

キュイキュイと鳴く

技術的なことで目についたのは、例えばこれ(↓)。

「ある種の dolphin では、カルテ記載内容の保存に clob を使っていた」という事実に対するコメントなのだが、私はこの内容には違和感を感じる。

dolphin に関していえば、ある程度技術のある人ならば「永続化にあたっては特別な暗号化はされていない」という認識だと思う。

確かにドルフィンは、Java beans が保持している情報を

xml →バイナリ→ base64 文字列

という風に変換はするのだが、バイナリ変換は文字通り「変換」だし、base64 による変換も

暗号⇄復号(encrypt⇄decrypt)」

と捉えるより

符号⇄復号(encode⇄decode)」

と捉えるのが一般的だと思う。

暗号化(encrypt)と符号化(encode)は概念からして違う。
暗号を復号するには未知の手がかりを解く必要があるが、符号化された情報を復号するには、決まって手順に従えばいいだけだからだ。

だから、カルテ記載内容を varchar カラムに直で書こうが、変換して格納しようが、本質的にはそう大きな差はない。
ーーどちらにせよ本格的な暗号化はされていないのだから。

少なくとも私はそう考えているが、増田氏はその差を「欠点」と大袈裟に捉えているようだ。これでは、話は噛み合わないだろう。
後述するが、逆に「ドルフィンは真正性を満たしているか」といったより大きな問題には、これとは対照的に全くと言っていいほど語らない。

イルカたちの沈黙

そう、彼らは、予想外のことに実に多弁に語る一方で、重要なポイントになりそうなことは語らない。

よく「ドルフィンはリリース直後から真正性が満たせているか疑問の声が上がっていた」と評されているが、もちろん、リリース直後などは私のアンテナには引っかかっておらず、あくまで人聞きの伝聞情報だ。

この点に関しては、もやもやしていたのだが、周囲から、「例えばこれ」と見せられた資料が以下のもの。

あ、なるほど。

日付は2014。この頃でもこういった疑問は既に上がっていたのですね。

しかし、なぜ、@masudanaika は、この手の疑問に明快に答えてこなかったのだろうか?

@ktomii99 氏の提案

ところで、@ktomii99 さんの言っている内容は興味深いので若干コメントする。

医療現場に出てみればわかるが、各種医療機器からの出力がすべて dicom 規格に準拠しているわけではないし、電子化されているわけでもない。中には出力方式がいまだに感熱紙印字というものもある。
この場合、文字が読み取れるうちにスキャナで読み取り、システムに取り込む必要がある。

取り込みの際の条件は現在ではガイドラインで既に示されていて、タイムスタンプと電子署名が必須だとされている。(なお、私はこの条件には疑問を持っていたりするのだが、本稿の主旨とは関係ないのでここでは触れない)

だから、タイムスタンプと電子署名に言及した @tomii99 氏の指摘はかなりもっともなのだが、あくまでこの二つは取り込む際の条件であって、出力した情報の真正性を担保する条件ではない。

まず、1日分のカルテ記載内容をまとめてPDF一枚にして・・・というやり方は論外。医師が複数人いた場合、担当していない患者のカルテに別の人が署名することになってしまう。これでは何のために署名をしているかわからない。

だから、このやり方を若干修正して「カルテ記載毎にその記載をした医師が電子署名する」というのが最低条件になるのだが、実はこれでも不十分だ。

記載したカルテをどういう形式で出力してもいいが、例えば、ある人のカルテを 1/1(1月1日) に記載、さらに 1/3 に修正した場合、署名した出力文書は 2 つあり、確かにこの 2 ファイルの間では修正履歴は追跡できる。
ところが、同じ出力形式で 1/2 の文書ファイルを偽造、同様に署名した場合、このファイル群のみからでは、このカルテが本物か偽物かまでは判定できない。

惜しい線まではいっているのだが、出力産物がファイル単位となってしまうため、でっち上げたファイルを作成・追加することでこのシナリオも破綻する。

この問題に対して 2.7m 開発陣が示した解決策は、実に鮮やかなものだった。

あるカルテは、データベース上では古いバージョンも含めて全て保管されているのだから、これらを別のアプリを使って抽出・表示させればいいというものだ。

上図の例では、ある患者のカルテはクライアントからは3件しか見えないが、編集歴があるため、データベース上では11件記録されている。その全てを可視化している。

詳しくは『Save the DolphinS』を参照。

このアプリ単独でも、真正性は担保されていると考えるが、@tomiii99 氏が提案したシナリオもこれで救われる。
データベースと照合し、そこに登録されていないカルテは、後から追加したもの、つまり偽物だと判定できるようになるからだ。

イルカも鳴かずば・・・

冒頭で「彼ら」の言動に違和感を覚えると書いた。

今では、この原因についてある程度推測はされている。
スキルのばらばらの「中の人」が複数人いて、誰からのチェックも受けずにてんでばらばらに好き勝手なことを喋っていただけだったからと。

しかし、それは今だから推測できたことであって、リアルタイムであったら、そこまで見切るのはなかなか難しいだろう。

それは異世界の生物が突如として覚えたての人語を話すような状況に似ている。
言っていること自体は理解できるのだが、内容が奇異でコミュニケーションをとるところまでは至らないといったような。

そしてその中の人の一人が今どのような取り扱いになっているかは周知のことだろう。

「イルカも鳴かずば、撃たれまい」なのだ。

 

OpenDolphin -フリートーク-

しばしば「オープンソースの」と形容されることの多い OpenDolphin だが、幸いなことに『OpenDolphin -wikipedia 風解説-』がネット上でよく参照されているようだ。

ただ、それなりの分量になったせいか気軽にものを書くというノリではいられなくなった。

これでは息が詰まる。

そういうわけで、気がついたことなどはこちらで
→結局、Contre-Attaque というサイトに移動しました。

 

(適宜加筆修正)

 

JakartaEE と DolphORCA

おかげさまでネット上では『OpenDolphin -wikipedia 風解説-』がなぜか支持されているようだ。

元々は、ドルフィンのソースコードを眺めていた時に、(従来は)開発者認定されていない人の署名を見つけて、ちょっとびっくりしてそこらへんのことをまとめておいただけの記事だった。
が、その後も報告が断続的に集まり続け、その都度書き足していったら、現在の形態になったという経緯だ。

こういう斜めから入ったような記事でも、それなりに読まれたりするものなのですね。

意外な気もするが、納得できるところもある。

ところで、OpenDolphin の件で若い人から言われて印象に残っているのは、

現在の Java や JakartaEE の各仕様を使えば数行で処理できるところを、何でその十倍くらいのコードで(しかも)不自然に処理しているんですか?

という指摘だ。

正直、きっつ。。

まあ、一言で言えば、データ構造修正とコストとの兼ね合いの問題ですね(汗)。

データ構造の限界やその処理方法の古さは、われわれも認識はしていたが、ひとたび、データ構造に手を入れ始めると、それを内部的に処理している部分も変更せねばならず、そのコストが(修正した)利益に見合わないとみていた、というのが答えといえば答えになるでしょうか。

なんか、うまい説明になってないか。。。

ここら辺で興味深かったのは、某先生の判断と立ち回りだ。

ギリギリまで OpenDolphin 2.7 のデータ構造は維持し続け、変え時と見たら一気に変えてしまった。
(ここら辺の流れは、ここあたりから始まる一連のツィートを参照。)

この「変えて」しまったものが DolphORCA なんだが、設計の基本コンセプトからしてドルフィンとは大きく異なっている。

DolphORCA で採用された三層クラサバ構成に関しては『DolphORCA と三層クライアントサーバシステム』が良い案内になっている。

また、(直接、DolphORCA には触れられていないが)電子カルテ系と画像系のデータ構造の相性の悪さに関して

なぜ、全国統一カルテは無理筋なのか?
-カルテ系と画像系のデータ構造の本質的な相性の悪さ-
(EHR-DICOM data structure mismatch)』

という記事にかなりわかりやすく書かれている。
DolphORCA のデータ構造は、これらの考察を踏まえてかなりシンプルで使いやすいものになっている。
ここら辺の分野に興味のある方はぜひ一読をすすめる。

 

 

モヤっとしたことなど

ネット上を彷徨っていると、気になることやモヤっとすることも多い。

思いつくまま書き留めていく。

2022-2023 年越し

小山哲央(アーク情報システム所属)とかいう人のこれはさすがに不味いでしょ。

結構な人が指摘しているが、2019 にもなってこのツィートはないよなあ。

2019 といえば確か MIA も商用版をリリースしていて、MIA に至ってはソースコードの開示もしていない。LSC は明言していないが、実務的には GPL でもなんでもなくなっていた時期だ。もはや GPL でもなんでもなくなっているのに、「故意に」「GPL 違反」したってどういうこと?
そこらへんの事実確認もせず、悪意丸出しで出鱈目なツィートしたってこと?
誹謗中傷よりもタチが悪いし、人間性疑われるレベル。
FEM あたりを使って建築・土木系の構造解析(シミュレーション)やってるみたいなんだが、建築・土木系の FEM は、はっきりいってガチ FEM 勢から大して評価されてない。建築土木系の数学力が低いからだ。
さらに評判落としかねないようなことやってどうすんだ???
Python で FEM ねえ。悪いが、まったく興味持てない。

(追記)やはり、小山哲央のツィートは逆効果だったようです。「LSC からの依頼を契機にここら辺、コードを整理して、もう少しマシなコンバーターを作ろうという雰囲気はあった」そうなんですが、このツィートのせいでこの話はおじゃん。結果的に電子カルテの基準を満たせなくなったわけです。
なんとも皮肉な話ですね。

2022 夏頃

オープンソースの電子カルテに関する tweet

ここから始まる一連の tweet 。

そのときは「こういう意見もあるのか」と流していたのだが、いわゆる「大学人」のイヤらしさとかダメさ加減がそこはかとなく出ている感じなので、取り上げる。

まず、OpenDolphin がダメな理由が「現在の Java のバージョンより古い」としているところ。
間違いではないんだが、違和感ありまくり。

というのは、現行の Java 開発環境に対応させるための改変は大して難しくないし、改変して使っている人がけっこういるから。

実際、こんな動画も上がっている。

今、見直したが、サーバーの起動から実に丁寧に記録・提示されてますね。

こういう情報を(意図的に?)無視して「古い、古い」というのは、ちょっとおかしい。
というか、単純には「私には Java コードを改変できるだけの能力がない」というだけのことなので、本当に気になるようだったら、質問なり何なりすればいいだけの話。

 

で、持ち出してきたのが omcake というソフト。

紹介するのはけっこうだが、すかさず「ログイン認証の機能がないから電子カルテの要件を満たしていない」という突っ込みが入り、撃沈。

さらに某先生から「ログイン認証にはセッション使えばいいよ」とサジェスチョンされたにも関わらず、まるっきり反応できてない。

一体、何がやりたかったのか???

WebDolphORCA

逆になんか「得した」と思われる事柄。

omcake の時に、某先生がログイン機能を提示したのだが、ここから WebDophORCA に展開していく流れ。

ログイン認証の実装などは大して驚かなかったのだが、『OpenDolphin は「真正性」すら満たしていないかもしれない』という考察記事は興味深かった。

これ、ポイントは「OpenDolphin は記録の保存には hibernate を使って blob を操作しているが、hibernate を使っている限り、blob を直接操作してデータを書き換えると、OpenDolphin のシステム自体はデータ操作(改竄)されたことに気がつかない(=検知することすらできない)」というあたりです。

よくもまあこういうケースを思いつくもんだと。

現状での現実的な回避策も示唆しているので、こういったことに興味のある人は(難解かもしれないが)一読を勧める。