無症候性感染者が増えると感染爆発がおこるリスクが増大する

SNS でけっこう支持されたようなので、加筆・修正の上こちらにも転載。


感染症の数理モデルに興味持っている人意外に多いなと思ったんで、ちょっと書きます。(なお、私は感染症の専門家でもなんでもないです)

まず、感染症の数理モデルは既にいくつかあります。有名なのは SIR モデルや SEIR モデルでしょうか。https://ja.wikipedia.org/wiki/SIR%E3%83%A2%E3%83%87%E3%83%AB
あたりを参考に。


何やら、小難しそうですねw

でも、このように数学的に定式化することの利点はあって、それは計算機でシミュレーションできるということです。
ブラウザで使えるシミュレータも用意してあります。
よかったら
https://covid19-seir-model.netlify.app/
で遊んでみてください。

具体的な数値をどう入れていいかわからないって方は下図を参考にしてください。
現在の日本のコロナの感染状況を念頭において1億人の集団で、100万人感染者(緑)がいた場合に設定してます。

R=5.0
R=2.5

R をどう取るかが悩ましいのですが、ここではピークがどう変わるかわかりやすくするため R=2.5 と R=5.0 としました。(実際にはちょっと前-2020/12-で 1.1 。年明けの今はもうちょっと増えていると思います)
なお、ここでは簡便のため R=β/γ としてます。
γは定数(1/γ が平均感染期間)なので、β(感染率)を変化させることで R をコントロールしよう、というのが感染症コントロールの基本です。(私は感染症の専門家でもなんでもないので、日本の「専門家」とは説明の仕方が違うと思いますが、たぶん、数式的にはより忠実にモデルにそって説明していると思います)

ここまででも日本の感染症対策の問題点は幾つか出てくると思います。

・感染者を大雑把に100万人としたが、日本は検査絞り込んだおかげでこの推定が精度よくできない

・モデルとしてはβの方が本質的だが、一部の「専門家」がRtを重視しすぎたせいで、モデルに遡った考察ができにくくなっている

(R が固定値ではないのは理論に遡って考えると明らかでしょう。ウイルスが遺伝子レベルで変異をおこして感染力が変化した場合はもちろん感染のフェーズが変わっても後述するようにRは変化するはずです)
などなど。

一部のコロナ「専門家」と私が見解が異なるのは、「無症候性感染者が増えると、単純な接触制限しただけでは春先(第一波の時)ほど効果は出ない」という点です。

例えば、ある人が10人に接触したとして、そのうちの1人のみが感染者だったとする。その1人を検査で確定して隔離してしまえば、残りの9人といくら濃厚に接触しようが感染の拡大は起こりません(第一波の頃)。
ところが、9人のうち2人が実は「隠れ」感染者だった場合(現在これに近い状態になりつつあると私は思います)、今、注目している1人も感染する可能性が高くなります。もちろんこの場合は感染拡大は止まらないでしょう。

それはともかく、感染が急激に拡大しているときに過去データの延長(外挿)で Rt=1.1 として計算するのはちょっとおかしい・無理があるというのはご理解いただけるかなあと思います。

ついでで言っておくと、外国では年齢別・地域別にβなどを細かく設定して微分方程式に踏み込んでシミュレーションしてます。

駄文長文、失礼しました。

 

猪股弘明
医師:精神科(精神保健指定医)
HorliX, OpenDolphin-2.7m 開発者


? 参考
そもそも SEIR ってなんぞやって人は
感染症数理モデルの基本 SEIR をなるべく数式に頼らず直感的に理解する
をどうぞ。

? 質疑応答(某所ではこんな感じでした)
Q シミュレーションをどう活用したらいいか?

A シミュレーションってやりっ放しってわけにいはいかず、大抵の場合は検証作業が必要です。なのですが、現在、これはできにくい状況になってます。

例えば、今日(2021/1/14)の東京都の陽性者数は 1502人ですが、検査件数は(確定ではないが)3849 件。単純に陽性率計算すると 39%ほど(集計フローの混乱なのかちょっと高いですね)。検査件数が 10000件なら、3900人陽性者になる。

単純な SEIR シミュレーションで出てくる数値は、対象とした集団のなかでの暴露者数や感染者数だから、検証のためには「感染者数」の確定数値か無作為抽出に近い「陽性率」どちらかがわかっている必要があります。

Q 広島の取り組みについて、全否定されてるドクターがコメントされていました。PCR検査を確定診断するものであってスクリーニングするものではないと。

今後の検査ポリシーで何が正しいのかって難しいと思いますが、経路不明が過半数を超えた時点で、濃厚接触者中心の疫学的調査ってそれほど効果ないんですよ。

これダメなのは、分科会の「専門家」が「今は市中感染がメインとなってきたから、今後は◯◯の検査に切り替える」ってはっきり言わないことです。

Q なんとなくですが、市中感染が広がってるという事というのかクラスター潰しからの次の戦略への移行を分科会は認めたくないの?っていう印象を受けてるんですね。

A 認めたくないって言うのもあるだろうし、そもそも分科会のメンバーの能力を疑問視している医師は多いですよ。

例えば、上の SEIR でも大雑把な方針は見えてくるじゃないですか。上では単純に E としたけど、現実的には「潜在的な陽性者」あたりがこれに該当する。これがある程度数値的に評価できていないと次にどうなるって予測ができないし、政策への提言なんてのもできない。
「市中感染がこれくらい広がっているから、規制を強化しましょう」とか「緩和されてきたので、自粛対象を縮小しましょう」とかってのが、今、一番必要とされていることじゃないですか。
広島はそれを「特定地域の全数調査」で確かめようとしているし、厚労省の一部は「市街地での不特定多数への検査」で概数を掴もうとしている。やり方の良し悪しはともかく意図は明確です。
でも、これ、本来は分科会の専門家が率先して言わないといけないことですよね。

臨床現場だとなおさらそうですが、そういう想像力が働かないリーダーって無能扱いされるんですよ。

ネット上の「ヤバい人」再録

出身研究室の合同OB会があったときに出たネタを某院生がブログに書いていたくれたのだが、諸々の事情で非公開になっていた。
けっこう面白いと思ったので、関係者の許可を取ってこちらに転載。


GW 期間中の某日、恒例の OB・OG を交えての懇親会があったのだが、そのとき話題に昇った「ヤバい人」が本当にやばかった話をまとめる。

以前にもどこかで、医師にはマナーの悪い人もいるみたいなことを書いたが、それはお金に汚い、とか理工系関係者に対する態度が尊大だ、程度のことだ。この人は筋金入りだった。某先生いわく「治療が必要なレベル。発達障害と人格障害を足して2で割って、さらにサイコパス要素も加えたようなレベル」だそうだ。粘着な感じも相当で、だから、ここではこちらが特定されないように「ヤバい人」という呼称を使わせてもらう。

技術的におかしなことを挙げていくときりがないし、今回伝えたいことはそういうことではないので、こういう特徴を持った人がいたらまともにかかわっちゃだめだよ!的な感じでまとめたい (^^;)

・態度が身分不相応に尊大。現実的には、社会的評価や業績に圧倒的ともいえる差があるにもかかわらず、特定の意にそぐわない行動を取る人を攻撃対象としかみていない。

・反論が幼稚にもかかわらず、なぜか自信満々。それっぽい反論を「後で」出したりするのだが、いかんせん、ポイントがつかめていないせいか、その反論も反論になっていない。

・理屈では勝てないとわかるとネット上で誹謗中傷かきまくり

やばすぎる。他にも特徴はあると思うが、特にネット上では、即座に力量がわかるわけではないから、こういった傾向を持った人には注意しなければならないと思った。


面白いと思ったのは、ネット上にこういった人は確かに多いこと。
精神科的観点からあれこれコメントしてみたい。

ところで、このブログでも度々より上げてきたドルフィンプロジェクトだが歴史的評価の段階に入った感がある。
あのプロジェクト内部にも上で述べたような感じのちょっと困った感じの人がいたんではないか?みたいな記事が、最近(2024年2月)チラホラ目につくようになった。

Monster Pseudo-Developer in Dolphin』あたりをご参考に。

 

ANN2b

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

 

ORCA, OpenDolphin, OsiriX は三種の神器だったのか?

– ORCA, OpenDolphin, OsiriX は三種の神器だったのか?

ある時期まではそうだったと思う。具体的には 2010年代前半あたりまでは。

ORCA(オルカ) というのは、日本医師会が主体となって開発が進められたレセコンソフトで、その当時はこれ一台で診療所レベルならば会計から保険(電子)請求まで用が足りてしまった。ただし、操作性には若干の難があり、現実的にはオルカと連動する電子カルテと組み合わせて用いられることが多かったと思う。OpenDolphin (オープンドルフィン)は、その代表格で 2013 年前後はかなり導入されていたようだ。OsiriX (オザイリクス)は、ご存知、DICOM ビューアだ(簡易な PACS 機能もついている)。当時はかなり安価に入手できた。

当時は、どれもオープンソースでソースコード自体が「一般」公開されていたので、スキルとやる気さえあれば自前でインストールできて、よほど凝った使い方をしなければ、クリニックでの自力運用も可能だったように思う。レセコンソフトとそれに連動する電子カルテと画像ビューアがほぼ無償で手に入ったのだ。新規に開業する医師にとっては、非常に心強いものであったと思う。

これはそれ以前の状況と比較するとわかりやすいと思う。

ORCA 登場以前は、メーカー製レセコンや電子カルテは「5年で300万」くらいが相場で、クリニック経営上はかなりの負担になっていた。画像ビューアは、若干事情が違っていて、そもそも OsiriX あたりに相当する製品はなかったように思う。病院の放射線科で画像診断に使われるようなビューアとなると軽く100万は超える。小規模なクリニックだと、「外部で撮像された画像をチェックする」程度しか使わないので、そういうメーカー製ビューアは明らかにオーバースペックだ。

だから、ORCA-OpenDolphin-OsiriX というのは、それぞれが強力なツールだったし、三つあわせれば非常に「頼りになる」枠組みだったのだ。

では、現在ではどうだろう?

まず、OsiriX だが、現在でもオープンソース(OpenSource: OS)版は開発されているとはいえ、OS バージョンをそのままビルドしても商用版の OsiriX MD になるわけではない。だから、現在のプロジェクト自体を以前の OsiriX の延長と考えるのは無理があるだろう。実際、各国で医療機器としての承認/認証を受けていることからわかるように、「医療機関向けの医療用ソフト」にコンセプトを変えたと見る方が妥当だろう。
病院勤めの臨床医/研究医がお手軽に OsiriX で患者さんの画像をチェックするというような使い方はもうできないと思う。

次に OpenDolphin だが、いわゆる「本家」の開発元が2020年上半期に LSC(ライフサイエンスコンピューティング)から medley(メドレー)に移った。
メドレーは、
・クラウド版を重視
・オープンソースとしてのプロジェクトという認識が希薄
なようで、今後は dolphin-dev の github リポジトリのソースコードが更新されるというのはちょっと期待できない感じだ。実際、OpenDolphin は開発の経緯もあるためだろうかメドレー自体「オープンソースである」とは明言していない。
(→結局、LSC での販売も正式に終了し、メドレーも普及させる意図はないようなので、実質、この系列からの商用版の利用はできくなったと考えてよいでしょう)

最後に ORCA。これはオープンソースであるが、開発言語やミドルウエアなどが独特で、ソースコードからビルドして使っているという医療関係者はほぼいなかったと思う。そこにきて、オンプレミス版(クラウドタイプではなく、院内 LAN でローカルで走らせるタイプ)が一部有償化されてしまった。医療機関で新規導入をはかる際には有償契約がほぼ必須だろう。
やはり、これも「ちょっと使ってみる」といった使い方はできなくなったように思う。

だから、これらソフトは、現在としては 2010年代前半のように「これ使ってれば間違いはない」といったような、絶対的な存在ではなくなったように思う。
最初の問題提起に戻ると、ORCA-OpenDolphin-OsiriX という枠組みはもはや「三種の神器」とも言えるほど特別な存在ではなくなった、というのが私なりの感想めいた結論だ。

 

追記

現在(2024)になって、オープンソース離れはさらに加速しているようだ。

理由はいくつかあると思う。

ソースコードが公開されているからといって必ずしも理解できるとは限らない。特に日本の場合、医師などは高卒後いきなり医学部に入学する人がまだまだ多いため、この分野の基本的なスキルに欠けている。

オープンソースが素晴らしいと言ったところで、その内容が理解できなければ宝の持ち腐れだ。

他分野でもその傾向があるようだが、皆が使うカーネルや基本的ライブラリはオープンソース開発方式を維持、個別のアプリケーションは非公開で開発、という風潮があるようだ。

ところで、上の記事自体、公開して4年も経っていないのだが、既に情報が古くなっている感があるので、訂正などを入れておく。

OsiriX もはや再びオープンソース化することは考えにくい。後継と期待されていた Horos もほぼ更新すらされていない。
われわれも HorliX というのを出していたが、最近はもっぱら PHORLIX の方に注力している。こちらはオープンソースではない。発足当初などソースコードも公開していたのだが、手伝ってくれる人や助言してくれる人はほぼ固定されていたため、公開するのをやめてしまった。

OpenDolphin そもそもこのプロジェクト自体の「オープンソース」性が疑わしい、という身も蓋もない状況になってしまっている。

ORCA WebORCA 時代に突入。データベースの定義などは公開されているもののプログラム自体は公開されていない。

 

猪股弘明(医師:精神科:精神保健指定医
OpenDolphin-2.7m, HorliX 開発者

⭐️ 参考
OsiriX Lite の現在
ORCA
OpenDolphin-2.7(m) と ORCA について
OpenDolphin について
OpenDolphin と電子カルテの3要件とメドレー
OpenDolphin -wiki 風解説-

ORCA, OpenDolphin, HorliX

所要とはいえ ORCA日本医師会がソースコードを公開、配布しているレセコンソフト)とOpenDolphin(電子カルテ。これもオープンソース) と準備してきたので、HorliXHoros/OsiriX ベースの画像ビューア。オープンソース) も起動。
特に深い意味はないんですが。

いや、しかし、壮観ですな。

一台の Mac の上で動いているってのにちょっと感動してます。


 

ところで、OpenDolphin・HorliX は、精神科医の猪股弘明先生の開発したバージョンを使ってます。

OpenDolphin

OpenDolphin は、オープンソースですから、当然、派生バージョンは色々とありますが、OpenDolphin-2.7m (今回、試したバージョン)は本家(dolphin-dev)に割合忠実です。これにはそれ相応の理由がありました。
OpenDolphin について』、『OpenDolphin と電子カルテの3要件とメドレー』あたりがわかりやすいでしょうか。開発者本人がその経緯を語っています。

私も今回 OpenDolphin に触れてあれこれ感想を持ちましたので、機会があったら何か書いてみたいと思います。

HorliX

画像ビューア HorliX に関する使い勝手などに関しては『COVID-19 による肺炎CT画像!<HorliXにて表示>』(精神科医高木希奈先生のアメブロ)に動画入りで紹介されていますので、そちらもご参照ください。

ところで、先生、最近、ブログで

HorliX と薬機法

という法律ガラミにしては?面白い記事を書いているので、こちらもよかったらどうぞ。

ORCA

ところで ORCA に期待(懸念?)されていることは、本当に今の設計のままで意味のあるクラウド化ができるのかってことですが、これも猪股先生、一つの提案をしてくれました。

将来的には医療情報の類はクラウドに上げて一元管理・ビッグデータとしての活用を図る・・云々みたいな話は、まあそうだろうなとは思うのですが、このとき医療機関側が欲しい情報を取ってこれる環境になっていないとデメリットの方が大きく、実際には誰も参加しないだろうなと思います。
(法的にも医療情報の管理責任は、現状だと医療機関側です。業者ではありません)
欲しい情報を効率よく取ってこれるかどうかは、データ構造の整合性に大きく依存するのではないでしょうか。
これを実現する割と有効な選択肢は現在だといわゆるウェブフレームワークの採用かなと思ったわけです。

オルカの職人芸的なデータベースの使い方も嫌いではありませんが(笑)、この後の展開を考えるとなるべくデータ間の「辻褄が合うように」整合性をはかっておく、モデル化しやすいように準備しておく、というのはあっていいのかなと思った次第です。

メーリス上で議論され、最終的には ORCA管理機構の人に「フレームワークの採用も検討してまいります」とまで言わせしめました。→結局、ORCA 管理機構、独自にウェブフレームワークを開発して、WebORCA をリリース。

また、最近では、ORCA のデータベース(PostrgreSQL)から直接データを抜いて、各種指標を加工する方法を提案しています。猪股先生ご自身が『ORCA の日計表と関連テーブル・内部会計フローなどについて』にまとめてくれています。

 

ANN2b