OpenDolphin -増田ファクト難民-

この頃、諸々あって OpenDolphin(オープンドルフィン) 関係を調べている。
→結局、『OpenDolphin -wikipedia 風解説-』にまとめました。

そこでいう OpenDolphin は OpenDolphin-2.7(m) 系列のことを指している。
というのは、現在(2020年年末)においてソースコードが公開されている最後のバージョンがそれだから。
ま、他にも理由はあったりするのだが、それは割愛。

それ以前は 2.3 系列や 2.5 系列がそれなりに普及していたようだ。

で、調べていたとき、「増田ファクト難民」という言葉を何回か耳にした。

「増田ファクト」というのは、和歌山の内科開業医(現在は閉院しているようですが)、増田茂 氏がフォーク(Fork ) したバージョンで、確かに以前はそれなりに普及していたようだ。

なのだが、私が調べた範囲では、使っている医師はまったくいなかった。
まあ、私の知り合いなんぞ東日本中心にかなり限られているけど。
(ちなみに、ほとんどは OpenDolphin-2.7 系列の自力運用。まあ、院内SE抱えていれば、運用はさほど難しくないでしょう。当然)

OpenDolphin-2.7m猪股先生も一時期は使っていたということで、それなりの質を維持していたんだと思う。
実際、猪股先生も

おそらくこういった「導入は増田ファクトで(当時としては、確かによくできた導入環境でした。ただし、導入手順書にしてももっぱら windows 前提で、Mac OSX へのインストールなどはまったく触れられていませんでした)。ある程度、様子がわかってきたら、さらにカスタマイズ。その後は、独自路線を突き進むなり本家に戻るなりして開発を継続」といったパターンは多かったと思います。

と『OpenDolphin について』の中で述べている。

 

で、「増田ファクト難民」ですよ。

なんでも、増田氏、ユーザーさんが何か気に入らないことをするとバッサリとアプリ(OpenDolphin-2.3m というらしい)の提供をやめていたとか。
また、電子カルテの乗り換え時に「増田ファクト」から他電子カルテに乗り換えるとき、データ移行の手段をまったく提供していなかったという(もちろん今はどうかは知らない)。

そういった「電子カルテはあれど、データが取り出せない」見捨てられたユーザーのことを隠語的に「増田ファクト難民」と言っていたらしい。

元商用開発元の方も「増田さんのバージョンからの乗り換え(データ移行)は何回か手伝ったことがある」と明言していたので、たぶん、そういった事情は本当にあったんだと思う。

もちろん増田さん自体はソフトを無償で提供していたので、このこと自体は咎められないと思うのだが(基本的には何か問題がおこったとしてもユーザーの自己責任)、問題はそのような運営状態にあるソフトを「電子カルテ」と呼んでいいのかってことなんだな。
ここらへんはややこしい問題も含んでいるので猪股先生が書いた『OpenDolphin と電子カルテの3要件とメドレー』を読んでみてください。ネット上ではかなり参照されている記事です。

 

そして、(これ書いていいか相当迷ったのだが)思い切って書いちゃうと、その後の増田さんの言動が周囲の評価を下げたと思う。

まず、猪股先生の OpenDolphin-2.7m がご自身の 2.3m のフォークだと主張した点。
これは完全に誤り。
OpenDolphin は、バージョンが上がるにつれテーブル数が増えていっている。
2.3 ベースのものと 2.7 ベースのものでは、そもそもテーブル数が違っている。
データベースを精査すればわかるが、OpenDolphin-2.7m は LSC 版 OpenDolphin-2.7 の直接フォークで、データベースの構造も 2.7 と何一つ変わっていない。
2.3 ベースの 2.3m からわざわざテーブルを増やして、2.7m に進化させるという手間のかかるアプローチを取る必然性はまったくないし、一般公開が中止された 2.3m をベースに 2.7 系に修正をはかるというのは不可能に近い。

次に、猪股先生版 OpenDolphinOpenDolphin-2.7m)のいわゆるファイルバックアップシステムを「役立たず」のように悪様に評価したこと。
どのような評価をしようが自由ではあるのだが、世間的に評価されているのはむしろこの機能だろう。
実際、ここまでデータ構造に関して理解している人はいないということで後期 LSC やメドレーからメンテナの打診があったのはよく知られた話だ。

開発者の猪股(弘明)先生が明らかにしているようにこの機能は元々はデータ抽出ツールが元になっている(参照:『ORCA, OpenDolphin, OsiriX は未だに話題になりますね』の「OpenDolphin カスタマイズの実際」の項)。
近年は、行政から電子カルテの修正履歴の開示まで求められるようになり、この手の機能はもはや必須といっていい。
一時的に普及した増田ファクトだが、次第に開業医からかえりみられなくなったのは、「クライアントに搭載されている(最終確定版の)PDF 印刷機能だけで十分。ファイルバックアップ機能は不要」といった開発ポリシーも一因にあげられるだろう。
現代では、データ操作機能が貧弱な増田ファクトでは電子カルテとしての実運用は難しいのだ。
これも私の個人的意見というより厚労省のガイドライン的な要請です。
このガイドラインでは

1.バックアップサーバ
システムが停止した場合でも、バックアップサーバと汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。
2.見読性確保のための外部出力
システムが停止した場合でも、見読目的に該当する患者の一連の診療録等を汎用のブラウザ等で見読ができるように、見読性を確保した形式で外部ファイルへ出力できるようにすること。

電子カルテ本体とは別系統でバックアップシステムを備えておくことが推奨されています。
増田ファクトはクライアント経由でしかカルテデータを抽出できませんから、この基準を全く満たしていません。
一方、猪股版 OpenDolphin は、HTML/PDF Viewer と組み合わせて使うことで、この基準を完全にクリアしています。
仮に増田ファクトが電子カルテだとしても、ガイドラインの基準を満たしてないソフトの担当者(増田茂)が、基準を満たしているソフトを何の根拠も示さずに「そうではない」と否定しているようなものです。だから、周囲はその主張を受け入れることはできません。というより、そのような無茶な主張をしている人の評価を下げることはあっても、上げることはないでしょう。

さらにダメを押したのが増田茂が「OpenOcean は著作権違反行為だ」と誹謗中傷をしたことだろう。
その論理で言うなら 2.3m には dcm4che のコードがそのままの形で含まれていたのだから、増田ファクトの方が GPL 違反をしていたことになる(そしてそのことを増田茂は、一言も言及していない)。

また、ここから疑惑が生まれたように思う。
本当に自分でコーディングしているなら、こういった間違いはまずしないからだ。
もちろん昔書いたコードなどそのロジックを忘れることはけっこうあるのだが(バグの温床になります、はいw)、新規に追加した機能などはソースコードを何遍か見直せばほぼほぼその意図は思い出す。
(『ソースコード嫁』参照)
猪股先生自身が「勘違いされてるんじゃないですか?」と指摘しても自分の主張を引っ込めなかったし、当時の商用開発元(私は後期 LSC とか呼んでますが)「増田ファクトと商用版とのデータ互換性はない」と明言しているにもかかわらずそのことを認めなかった。まあ、後者は「互換性」の定義にもよるのだけど。

実際、開発元が、後期 LSC 〜メドレーあたりになってから、増田さんは「開発者」としてはみなされていないそうです。
これもかなりおかしな話なんですよね。
過去のことであってもソースコードを提供したなら、contributor としての立場は変わらないはずなんですが、実務上はそういう取り扱いになってないようです。
経営陣が変わった途端、その立場を失うってのは商用ソフトならともかく(あ、商用ソフトでも本当はまずいかw)オープンソースの世界ではありえないはずなんですが。
GitHub でソースコードのやり取りしていれば、変に疑われることもなかったと思うんですが、その痕跡はまったくと言っていいほど残ってないし。
やっておけばよかったと思うんですけどね。

最後に付け加えると、メドレー的には「増田ファクトは危険」という認識らしいです。
OpenDolphin という名称は、特許庁による判断が下されてから、原則、他の団体が使っても問題なくなったんですが(air-h-128k-il 氏の『OpenDolphin と知財権に関するちょっと小難しい話』にかなり詳しい解説があります)、それはあくまで本家版との相違点が明示されている場合のみです。
「データ互換性がないのにあたかも互換性があるように広報するのは、容認し難い」そうです。
あ、これメドレーの言い分ですよ。
私じゃなくて(これ言っておかないと変に恨まれたりするんで)。
MIA も SOSO も猪股先生も、後期LSCとメドレーから許可取ってるんで、そうすればいいだけの話だと思うんですけどね。

(追記)長々と書いてましたが・・・

メドレーに開発元が移って状況はさらに変わりました。
メドレー自体が「OpenDolphin は GPL に従う必要はない」とかなりはっきり言うようになった。
増田さんの取り扱いに至っては(はっきりと言ったわけではないですが)「契約上、著作権者として取り扱っていただけ」のようです。
OpenDolphin について』より

あらら。
不自然なことは山ほどあったが、結局、そういうことだったわけですか。

(追記2)私なんぞドルフィンに手を出してからそんなに日が経ってないので遠慮してましたが、さすがにこれはダメでしょう。

現在(というか 2020 以来)、OpenDolphin という商標はメドレーが保持しているわけですから、配布などの際にはメドレーの名前をクレジットしないと(厳密には)商標権侵害にあたります。

また、こういう投稿もどうかと思う。

おそらく、OpenOcean 再設計を指して「そんなのできるわけない」という揶揄をこめての投稿なんだろうが、現在の IT 企業の新人社員研修あたりでも、永続化機能ありの Web API を持ったシステム(例えば簡易 EC サイト)は組ませるので、現行の技術水準の把握の仕方が何かおかしい気がする。この人や周囲の人々(ちなみに、@sci_sugi はシステムクラフト杉原利彦氏のアカウント)にとっては、新規のプロジェクトを起こすのは難易度が高いのかもしれないが、ある程度スキル・経験あるグループにとっては、そこまで難しいことではないし、できなければ、ほとんどの IT 企業は経営が成り立たない。
間接的に SIer などの新人教育係をディスってる感じになって、あまりいい印象を受けない。
(追記の追記)「ご自慢のデータコンバーター」という表現も今となっては滑稽。ガイドラインの改訂に伴って、大半の商用電子カルテシステムは、(内部的に)主系統のデータベースのカルテ記載内容をデータコンバートして別系統のシステムのデータベースに格納している。こういう構成にしておかないと、主系統のシステムがダウンした時、過去カルテが閲覧すらできなくなって、医療の提供が滞ってしまうからだ。
なぜに彼(「彼」と呼ぶのは、今となっては @masudanaika は現実の増田茂医師だけのアカウントとは考えにくくなっているから)がここまでデータ操作機能を軽視していたのか、ある程度推測はつくが、やはり謎。

(追記3)ところで、猪股先生を中心とする OpenDolphin-2.7m 開発コミュニティ、これまでもにも「設計が古い」と言われてきた OpenDolphin のアーキテクチャを大幅見直し。
諸々の理由で3層クライアントサーバ構成を採用。

フロントエンドサーバーにウェブサーバー機能を組み込んだ関係上、クライアントはブラウザになっている。

プロトタイプを YouTube で公開している。

ところで、ここまでくると増田茂の主張がほとんど見当外れもいいところなのは明らかではないでしょうか。

デスクトップアプリをどんなにこねくり回してもクライアントがブラウザになることはありません

このウェブレイヤー(dolphorca と呼んでいる)は、

OpenDolphin-2.7m → OpenDolphin HTML/PDF Viewerdolphorca

の順に発展してきています。
増田ファクトのクライアント(私が聞いた話では windows でしか動かないみたいなんですが???)が入り込む余地はありません。

(追記4)上で「増田ファクトは無償」と書いたが、現在では有償になっているようだ。
ただし、匿名垢だし、現在のガイドラインでは電子カルテの基準を満たさないアプリを「神」と呼称することから考えて、本当に投稿主が医師であるかどうかも疑わしいが。

(追記5)電子署名や電子カルテへの画像取り込みに関して、間違って理解している人がネット上にはいるようだ。

いわゆる「肉筆」をスキャナなどで画像として電子カルテに取り込んだとしても、それだけでは電子カルテの一部としては認められない。(上部の解説は wikipedia より。そこにもあるように画像など電子情報はコピペが容易であるため、証明力が弱いというのがその理由)

現在は真正性を担保するには公開鍵暗号方式のお世話になる必要がある。
その場合

・HPKI を利用した電子署名
・タイムスタンプ

の付与が必要とされている。

 

ANN2b