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

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


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

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

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

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

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

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

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


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

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

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

(追記)歴史的評価といきたいところであったが、AI まとめが出鱈目記事書いているので、それ対策に追われた。
結果的に dolphin とライセンスと著作権関係がかなり整理されたと思う。

OpenOcean/Dolphin と職務著作と GPL
IT プロジェクトで避けて通れないのが職務著作というやつで、dolphin プロジェクトの歴史的発展に絡めてかなり平易に説明されてます。

OpenOcean 怪文書 -GPL 誤用による違法行為教唆-
職務著作などの概念がわかった上で、この記事↑読むと状況が頭に入ると思います。GPL 違反は海外の法的係争に至った案件で紹介されることもありますが、ああいうのは立派すぎて実感を伴わないものが多い。
実際に起こった事件を扱ったものではナンバーワンでしょう。


最近、やばい人、認定されたのは、この記事で取り上げられた人でしょう。
この人の場合は、日常生活では異常ではないと思う。
だが・・

たとえ通常時は常識的で善良な市民であっても、ひとたび「開発者」という名誉を独占するチャンスが見えた時、人は簡単に悪を働く、というのはオープンソース界隈で散々見てきた光景だ。2.7m 系のドキュメントを参考にしても、コードは 2.7 ベースにしておく、みたいなことはこれまでにも何度かあったのだ。  引用元

という事情はありそうですね。
OSS はよからぬ人を惹きつける魔力みたいなものはある。あるいは人間の中に潜むよからぬ部分を肥大化させると言ったらいいのか。

私がこの人に感じた違和感をメモしておく。

・PR が「無効になった」と主張するが、無効になってない。

・皆川和史の名前を削ぎ落とそうという意図が感じられるが、2003-2012 は Digital Globe が著作権を保有していたわけだから、そこは尊重しないと過剰編集になる。

・ビルドテストもできていない段階で権利を主張する。

・対話性がない。

・レビューされるのを恐れる。

などなど。

特に「レビューを恐れる」に関しては、流石にコメントしておく必要があるだろうか。
dolphin のコードは素を正せば e-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 は現実の増田茂医師だけのアカウントとは考えにくくなっているから)がここまでデータ操作機能を軽視していたのか、ある程度推測はつくが、やはり謎。
(追記の追記の追記)彼にとっては「アプリを新規に作成する」のは、不可能に近いことらしい。猪股先生たちは OceanMini とか普通に公開してるよね。
「データベースに API 全部新規開発」するのがそこまで難しいだろうか?
冗長になりがちな dolphin の Java コードをメンテするよりある意味楽。

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

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

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

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

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

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

OpenDolphin-2.7m → OpenDolphin HTML/PDF Viewerdolphorca

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

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

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

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

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

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

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

(追記6)本稿は、主に増田茂に焦点を当てたが、小林慎治という人もかなりトンデモな主張を繰り返していたようだ。
小林慎治氏の OpenOcean に関する事実誤認
などご一読ください。
個人的には「コミュニティ」といえば何言っても許されると思ってそうな態度が気に入らない。法理的にはこの態度はまったく正しくなく、著作権に関して申し立てができるのは原則著作権者に限られます。小林慎治は著作権者ではないわけですから、断定的に「違反」だのを指摘できる立場にはいないわけです。主張の内容も事実誤認が多く、誹謗中傷と言っていいでしょう。

(追記7)最近では X の @masudanaika アカウントは自分では「医師」とな名乗らなくなった。
でも、そうすると 2020 年くらいまでの医師アピールはなんだったの?という話になる。
非医師が医師を名乗っていたわけですから、医師法18条による医師法違反ですね。
また、医師でもないものが「つくった」と宣伝していたわけですから、前期 LSC の OpenDolphin に関する広報はほぼ全て虚偽広告になります。

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

 

ORCA クライアント monjiaj をソースよりビルド

ORCA シリーズ。

Mac 上で動く ORCA のクライアントを導入しようとしたら、公式サイトには JDK 14 用はあがったいなかった。
せっかく Java 開発環境を用意したので、Java 版の monjiaj をソースコードよりビルドした。たぶん、それほど難しくない。とりあえずテスト的に使うだけなので SSL 対応は無視した。ビルド産物をいろいろつくってくれるようだが、そのうちの一つを立ち上げる。

実際に ORCA サーバに繋いでみる。

以前に登録した秋「場」ちゃんを呼び出せてますね。よかったよかった。

これで、患者さんを登録するのにいちいち(Parallels の)Ubuntu のクライアントを使う必要はなくなった。

(追記)現在(2022)だとビルド途上で failure が出るのだが、out ディレクトリの方の jar を使えば問題なく ORCA サーバーと接続できる。

なお、プログラム自体に署名するときは以下のようなやり方でやるらしい。


署名の設定

pom.xml、maven-jarsigner-pluginプラグインのコメントを解除し編集する。


<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jarsigner-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>sign</id>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
<configuration>
<archiveDirectory>${project.build.directory}</archiveDirectory>
<includes>
<include>*.jar</include>
</includes>
<keystore>${project.basedir}/keystore</keystore>
<alias>alias</alias>
<storepass>storepass</storepass>
<keypass>keypass</keypass>
<tsaLocation>http://timestamp.globalsign.com/scripts/timstamp.dll</tsaLocation>
</configuration>
</plugin>

署名用のキーストアの設定を以下の項目で行う。

* keystore
* keystoreファイルのパスを入力する
* ${project.basedir}はpom.xmlのあるディレクトリに置換される
* keypass
* keystoreに格納されている秘密鍵のパスフレーズを入力する
* storepass
* keystoreのパスフレーズを入力する
* alias
* 証明書のaliasを指定する
* tsaLocation
* 証明書のTSAのURLを指定する


ANN2b
(技術協力 猪股弘明