オープンソースの世界 〜残酷な自由さ〜

オープンソース開発方式は理想の開発形態の一つとして語られることも多いが、現場寄りの人はかなりリアルな見解を持っている。

開発者目線では…

例えば、以前評判になったこの記事。

筆者の megamouth さんによれば、contributor(ソースコードを提供した者)にも序列があるという。


OSSへのコントリビューターにもカーストがあって、ついでに書いておくと

カーネルメンテナ>言語メンテナ>カーネルコミッター>言語コミッター>有名ライブラリメンテナ>色々>ユーザーグループ主催者>ブログでアプリへの文句だけ書奴~

みたいな序列である。

ある程度名の通ったプロジェクトの contributor になるだけでもけっこう苦労するよ、という挿話が語られている。

曰く、


アホみたいな量のコードを読み下し、コーディングスタイルを真似し、単体テストケースを書き、開発者とコミュニケーションをとってまで、自分のコードをマージしてもらう。

プルリクエスト(Pull Request PR, 自分の改変したコードを取り込んでもらう修正依頼のこと)送るだけでも大変なのだ。

さらに、新機能の提案などになると・・・

新機能にしても、同じようなことは過去の誰かが考えているものだ。それらの機能が今存在しないのは、何らかの経緯で却下されたか無視されたことによることがほとんどである。
もし彼が「ぼくのかんがえたすごいしんきのう」を拙いCコードで表現することに成功したとしても、Google翻訳を駆使して、なんとか英語圏の人間に読めるプルリクを送れたとしても、忙しいメンテナが一瞥して言うことは「過去ログ嫁」である。

単に PR 送るより大変なのがわかる。

きっかけは個人的な欲求から始まる

ところで、私がオープンソースの世界に足を踏み入れ始めたのは、2018 年の春頃からだ。
きっかけは horos という医療用画像ビューアのプロジェクトの存在を知ったとき。
医療画像ビューアは一般に高額で、レントゲンや CT の画像を「ちょっと」確認する程度であれば、オープンソースのプロジェクトの公開されているソースコードを自力でビルドして使った方が金銭的な節約になる。
おまけに自分で改変もできる。ちょっと使いにくいというところがあれば、そこを自分で改変したっていいのだ。
私の場合、改変したいくつかの機能は、horos の本プロジェクトにも PR を送り、マージしてもらった。


そういう意味では、私は「医療用の OSS」 というニッチな分野では contributor なのだが、上で述べられたようにすごく苦労したかといえば、そんなことはない。
OSS のカースト的にみれば「アプリケーション」レベルだし、何よりも「医療」と名が付くと開発寄りの参加者は極端に減る傾向がある
慢性的な人手不足なのだ。この分野では一定水準のプログラミングスキルを持った人なら、新機能の提案・実装は、(カーネルなどへ contribution するのに比べたら)かなり楽だ。

ある程度慣れたきた段階で、自分でもプロジェクトを持つようになった。

だから、けっこう短期間の割には PR を送る側の経験も受け取る側の経験も両方したことになる。

ところで、ネットを見ていると「どうやったら PR をマージしてもらえるか?」みたいな記事は見つかるのだが、逆に「これやっちゃあかん!」というような記事はあまりない。
参考になるかどうかわからないが、一つ例示したいと思う。

マージされなかった Pull Request の例

以下は、私たちが OpenOcean という OpenDolphin 由来の電子カルテのプロジェクトで、クライアントバイナリを配布してきた時にもらった PR 。
公開するのもはばかれるような内容な気もするが、当人たちは open にしろしろと主張しているのでここで取り上げても問題ないでしょう。


一目でわかる通り、単純に特定行を delete したのみ(文頭の – は削除した印)。
この場合で言えば、public static int expired( ) という関数が関与する部分を削除しましたってだけの内容。

一般にコード書きが何かを実装する場合、たいてい、狙った機能というものがある。
上記のコードでは特定時刻と現在の時刻を比較し、現在時刻が特定時刻より先に進んでいた場合、そのプログラム自体を終了せよというのが狙った機能だ。
要するにこのアプリの使用期限を設定している。(この時点で元のプロジェクトにはれっきとした商用版が存在しており、こちらはちょっとした機能の提案をしたかっただけ。気合い入れて継続的に開発していく意思がなかったというのがその理由)

だから、これは bug (バグ)ではない。

確かに、プログラムが複雑になってくると、深刻なバグがあるにもかかわらずそれがどこにあるかわからないといった場合はよくある。このような場合、それを特定するだけでも貴重な情報になる。
だが、これはそういった類のものではない。

だから、この PR はマージできない。

逆に、「残り XX 日で使用不能になります」といったアラートダイアログなどを表示させるようなコードの場合、おそらくコードの書き方が少々稚拙であってもこちらで手直ししてマージしたのではないかと思う(例え、この噂が本当であったとしても、だ)。

つまり、相手(レビュアーやメンテナー:PR を評価しリポジトリを管理する人たち)の意図を汲み取ってプロジェクトにとってプラスの価値を与えるようなプルリクには大概のメンテナーは寛容でありマージもされやすいが、単に自分の願望を押し付けるだけでは考慮もされないのだ。実際このときもそれが主な理由でマージはしなかった。

(付記)その他の理由 -著作権に対する配慮-

上で「主な理由」と書いたが、他にも気になった点はあった。
というのは、このとき PR 送ってきた相手の GitHub アカウントのアバターが、全世界でかなりの人気を誇るアニメのキャラだったから。漫画・アニメなどで人気のあるキャラの2次利用は、たいていの場合制限されている。
実際、このキャラクターは基本的には2次利用を許していない。
もしかすると、この人と著作権管理団体などで使用許諾の契約がなされているのかもしれないが、基本的には第三者にはそんなことはわからない。
そして、PR を送ってきた相手はまったく知らない人だ。信用できる人なのかどうかもわからない。
一応、名前や所属などは確認したが(京都大の小林慎治という人。現在は、保健医療科学院に所属)、ここらへんの権利関係に関してはまったく気にしていないようだった。
私が気になったのはこの点だ。
OpenOcean プロジェクトに関しては特に行動規範(CODE of CONDUCT)のようなものは定めてはいなかったが、やはり「知的財産権に関して一定の配慮ができる」というのが最低限の暗黙の前提になる。
どんなオープンソースのプロジェクトでもそうだが、ネット接続環境を持っていて、アカウントさえあれば、議論に参加するくらいのことはできる。有意義な議論になることもあれば、まったく不毛な質の低いものになることもある。ネットで不特定多数を相手にするというのはそういうことなのだ。そして、意味のある議論ができるかどうかは実社会のステータスとは相関しない場合が多い。主張している内容や実際に書いたコードでその人の能力を推し量るしかないのだ。(蛇足かもしれないが、それはオープンソースの可能性でもあるだろう。全く無名の人でも活躍できることに繋がるのだから。)
だから、何かをしたい・信用を勝ち得たいというならば、その資質を実践で示す必要がある。それ以外の基本的な部分でレビュアーやメンテナに不信感を持たせては、まず PR は拒否されるし、以降はまともには相手にしてもらえないだろう。

Fork の効用・意味

また、付け加えておくと、アプリケーションレベルのOSSでは、「エンドユーザーに近い」という特性ゆえ、異なるバージョンの開発が並行して進められるということはよくある(当たり前だがユーザーには「好み」があるから)。
特に、電子カルテのように施設毎でのカスタマイズが前提になる場合はその傾向が顕著になる。実際、元になったプロジェクト自体、施設毎での独自カスタマイズを奨励していた。自分で既存のプロジェクトにはない機能を付加したいというなら、元プロジェクトを fork して独自プロジェクトをおこせばいいだけだ。

まとめ? 残酷でもあるが自由でもある

既存のプロジェクトに自分の提案を受け入れて欲しいというなら、相手の意図にはある程度意識的になる必要がある。もし、それが叶わないというのなら、自分で独立してプロジェクトおこせ、ということになる。
タイトルに「残酷」と入れたが、ある意味、それはオープンソースの世界の自由さとも言える。

 

他にも面白い話もあるので、また続き書きます。

 

猪股弘明

オープンソースの世界

オープンソース(Open Source)ソフトウェアに関する軽めの話など。

まず、オープンソースって何ぞやって人は、『伽藍とバザール』あたりを読むと雰囲気掴めると思います。このエッセイ自体、お話として抜群に面白い。
筆者のエリックレイモンドさんが自身が開始したプロジェクトでオープンソース開発方式を意識的に選んだときの経験談やコードを書く際の箴言めいた教訓が語られています。

Linux コミュニティはむしろ、いろんな作業やアプローチが渦を巻く、でかい騒がしいバザールに似ているみたいだった(中略)。そしてそこから一貫した安定なシステムが出てくる なんて、奇跡がいくつも続かなければ不可能に思えた。
このバザール方式がどういうわけかまともに機能するらしく、しかもみごとな結果を生むなんて、衝撃以外の何物でもなかった。

よいソフトはすべて、開発者の個人的な悩み解決から始まる。

何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば(そして使い回せば)いいかわかってるのが、すごいプログラマ。

目玉の数さえ十分あれば、どんなバグも深刻ではない

賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。

ところで、OSI (Open Source Initiative) という団体が認めたライセンスに合致したソフトしか「オープンソース」としては言わないとかという面倒くさい主張もあるんですが、ここでは「ソースコードが公開されていて、改変・再配布などの自由も認められているソフト」程度の意味で使います。
特に後で出てくる OpenDolphin に関しては、当初は GPL という OSI お墨付きのライセンスが適用されていましたが、現在ではそうなってはいません。
この話は説明しだすと長いのでここでは詳しくは触れませんが、経過を追うと日本においてオープンソースのソフトが成立しにくいと言われる理由がよくわかると思います。

話が横道に逸れました。オープンソースそのものの定義とかという半ば宗教論争みたいな議論をここでしたいわけではありません。
ソースコードが公開されていること、それを自由に改変してもかまわないことという特徴からどんなメリットが生まれてくるのでしょうか。
ここでは、この点に注目します。
実際、ユーザー視点や運営視点に立つと、ライセンスがどーのこーのと難しく考えるより、ソースコードを自由にいじれるかどうかという視点でみた方がわかりやすかったりします。

例を一つ。

Dynamics(ダイナミクス)

医療用のソフトの領域で Dynamics(ダイナミクス)という電子カルテ&レセコンのソフトがあります。


画像はHPトップのものですが、”開業医が開発した診療所発のソフト” とあるように、メーカー製のソフトの使いにくさに嫌気がさした診療所の先生が独自に作成し発展してきたソフトです。

だから、コミュニティ運営的は診療所開業医の先生方の相互扶助的な面が重視されています。「データの囲い込み」などもちろん持ってのほか。
HPにはこんな記載もあります。

Dynamics はプログラム内容などをすべてオープンにしていますので、ちょっとしたプログラムの知識があれば、好きなように画面や文字をレイアウトしたり、データを抽出したり、ときにはオリジナルの機能なども追加することが可能です。
このウィッキッキサイトでは全国のダイナユーザーが作成した独自プログラムやノウハウが多数、掲載されております。Dynamics の機能にはなくても、このウィッキッキサイトで解決するようなプログラムもあるかもしれません。是非、ご活用ください。

ね。開業医さんの立場にたてば、活用してみたくなるでしょう?

このような経緯があるので、ダイナミクス自体は OSI 認定のライセンスではライセンスされていません。
あくまで商用ユーザーにソースコードを公開しているのみです。
ですが、ソースコードを自由に改変してもいいという特徴は十分に「オープンソース」的です。
そして、この特徴は対象となるユーザーを何か強く惹きつけるところがあるようです。

実際、このダイナミクスというソフト、数あるメーカー製のソフトに負けない人気があります。導入数ランキングや購入後満足度ランキングなどでは、例年、上位にきています。

1998 年頃より配布を開始して、現在は導入実績が 4000 超。
データベースが MicroSoft Access に依存しているため windows OS でしか動かなくて不便とか電子カルテ部が使いにくいといった声もありますが、立派なものです。

これは、OpenDolphin(オープンドルフィン)という電子カルテと比較した場合、顕著になるでしょうか。

OpenDolphin(オープンドルフィン)

OpenDolphin という電子カルテがどういうものなのかは見てもらった方が早いでしょうか。

使ったことのない人にうまく伝わるかわかりませんが、ダイナミクスより UI などは凝ってますし、医師目線でもかなり使いやすい電子カルテです。

ライセンス的な観点でいううと、一時期の OpenDolphin は、GPL でライセンスされていたオープンソースの ORCA 連動型電子カルテでした(ただし、現在ではこのプロジェクトが GPL として妥当であったかは疑問が呈されているし、運営している会社も何度か変わっていますが、変わるたびに、この点に関してはむしろ同様に否定的な見解を示しいています)。

(一時時的だったとはいえ)OSI お墨付きのライセンスはあるし、ユーザーフレンドリーな設計だしで、普及しそうな要素はあったと思うんですが、残念ながらそうはなりませんでした。

2000 年代に開発が活発化し、一時期は商用開発元から 200 程度出ていましたが、現在は販売を終了しています。
いわゆるクラウド型では命脈は保っているのですが、2018 年頃よりライセンスは曖昧になったまま、それ以降のバージョンのソースコードは開示はされていません。

実際には、商用開発元を経由せずに使われている例が多かったと思いますが、プロジェクト自体の発展やコミュニティの熟成という意味では、上手くいったとは言い難いものがあるかなあと思います。
この理由に関しては、ここでは触れませんが、いづれどこかの機会にでも書きたいと思います。

(参考)
OpenDolphin -wikipedia 風開設-ANN2B Blog
OpenDolphin-2.7m のこれからPHAZOR.JP Blog

オープンソースプロジェクトが成功する条件

ところで、冒頭で「目玉の数さえ十分あれば、どんなバグも深刻ではない」という箴言を引用しましたが、この言葉は「目玉の数が不十分な場合、バグは深刻なものになりうる」とも取れるでしょう。

やはり、ユーザーの数や活発なコミュニティが重要なんですね。

オープンソースの成功例としてよくあげられる Linux カーネルの開発は、この条件をよく満たしていると思います。
これはソフト自体の特徴、つまり

・誰もが使う機会が多く、汎用的である

・システムの基本部分を受け持ち、透明性への要求が高い

ことから、この要求を満たしやすかったんでしょうね。

一方、医療系のソフトはなかなかこの条件を満たしにくいですね。
ORCA, OpenDolphin, OsiriX は三種の神器だったのか?』あたりも参考にしてください。
かつてはオープンソースであったがクローズドなプロジェクトになったもの、もはやその運営形態を維持できなくなったもの、などの具体例を解説しています。

 

猪股弘明
医師(精神科医:精神保健指定医)
OpenDolphin-2.7m : developer
HorliX : developer
Horos : contributor
OsiriX(open-source version) : contributor

ORCA の日計表と関連テーブル・内部会計フローなどについて

ORCA(オルカ)のMLに以下の投稿をしたんですが、
https://ml.orca.med.or.jp/orca-users/msg14690.html
画像が添付されないようでこちらに転載(若干、説明補います)。

ORCAは、窓口での収納の他にこれらのデータを基にして経営に役に立つような各種データを帳票という形で提示してくれる。
例えば、2020年10月22日に「秋場太郎」(デモ患者)さんが、インフルエンザ予防接種(これは自費扱いになる)と精神科の診察(保険診療)を受けたとする。
オルカが吐き出す「日計表」と呼ばれる帳票はこんな感じになる。

1日の売り上げを把握するのには便利だが、もうちょっと詳細に分析したい場合、例えば、保険分と自費分を分けて集計・比較したいという場合、これだと若干わかりにくい。

以下は「自費分」を除いて集計できないか?という質問に対する私のレスです。


投稿

●日計表について

精神科医の猪股弘明と申します。

あまり万人向けの方法ではないですが、orca データベースに sql 文を投げるといろいろな情報が取得できます。
先ほど手抜きですがちょっと試してみました。(ロジック間違ってたらご容赦)

例えば、20201022(2020年10月22日) の診療実績を知りたければ以下のようなsql文が考えられます。

SELECT tbl_sryacct_main.sryym,tbl_sryacct_main.day_22,tbl_hkncombi.syu_tanseidoname,tbl_sryacct_main.ptid,tbl_sryacct_main.srykbn,tbl_sryacct_main.zaiten
FROM public.tbl_sryacct_main
INNER JOIN public.tbl_hkncombi ON
tbl_sryacct_main.ptid = tbl_hkncombi.ptid AND tbl_sryacct_main.hkncombi = tbl_hkncombi.hkncombinum
WHERE tbl_sryacct_main.sryym='202010' and tbl_sryacct_main.day_22 >0;

私の環境だと結果は orca-sql-result-1.png のようになります。(添付できるんでしたっけ?)

「自費」を除外したければ、この文の最後に
and tbl_hkncombi.syu_tanseidoname !=’自費’
を付加した

SELECT tbl_sryacct_main.sryym,tbl_sryacct_main.day_22,tbl_hkncombi.syu_tanseidoname,tbl_sryacct_main.ptid,tbl_sryacct_main.srykbn,tbl_sryacct_main.zaiten
FROM public.tbl_sryacct_main
INNER JOIN public.tbl_hkncombi ON
tbl_sryacct_main.ptid = tbl_hkncombi.ptid AND tbl_sryacct_main.hkncombi = tbl_hkncombi.hkncombinum
WHERE tbl_sryacct_main.sryym='202010' AND tbl_sryacct_main.day_22 > 0
AND tbl_hkncombi.syu_tanseidoname !='自費';

というsql文を発行します。

結果は orca-sql-result2.png になります。

「自費」分が除外されているのがわかるかと思います。

20201022 固定が嫌なら、yyyymmdd として適当なプログラム言語からこの手のsqlを生成してorcaに投げればいいと思います。

あと、前にも言いましたが、
https://ml.orca.med.or.jp/orca-users/msg14678.html
やはりテーブル間にカラムの不整合がありますね。
今回は
tbl_sryacct_main.hkncombi = tbl_hkncombi.hkncombinum
と名前が違うような・・・。

 

猪股弘明
医師(精神科):精神保健指定医


pgAdmin4 のインストールと使い方

なお、上記の説明で出てくる画像は pgAdmin4 という PostgreSQL と連動して動くユーティリティソフトが表示したものをスクリーンショットで撮ったものだ。
sql文自体は、psql コマンドなどからも実行できるが、コマンドライン操作が苦手なようなら pgAdmin4 を使うとよいと思う。
なのだが Ubuntu 上に pgAdmin4 をインストールするのは若干面倒なので、普段使っている windows や Mac にインストールする方が楽だと思う。インストール方法は検索するといろいろ出てくる。

Mac でアプリで導入した場合、PgAdmin4 が起動しているとメニューに
←こんな象さんのアイコンが表示されているので、
クリックして「New pgAdmin4 window …」を選ぶ。

PostgreSQL を監視・操作するブラウザ画面が立ち上がるはずだ。

左ペーンで ORCA が動いているサーバを登録する。orca データベースをアクティブにしたまま、右上の「お重弁当+矢印」みたいなアイコンをクリックすると右のペーンがクエリ画面になる。
ここまできたら、準備は完了。
SQL文を書いて、「実行」すればなんらかの結果が出てくる。

一番簡単には、上であげた SQL 文をコピペして実行すればよい。

お疲れ様でした。

なお、慣れてくると

select a.sryym,a.day_22,b.syu_tanseidoname,a.ptid,a.srykbn,a.zaiten
from public.tbl_sryacct_main a 
inner join public.tbl_hkncombi b on a.ptid = b.ptid and a.hkncombi = b.hkncombinum 
where a.sryym='202010' and a.day_22 > 0; 

な感じでもうちょっと短く書けるようになる。

 


ORCA の会計フローと上記 SQL 文の意味

ポイントはここでしょう。
このあと、作成した SQL 文を基にプログラムを組むにしても、上記 SQL が何やっているかわかってないと目的にあった修正ができないと思う。

まず、基本ですが

SELECT カラム,カラム… FROM テーブル WHERE 条件;

は基本構文みたいなものなので、覚えて欲しい。最後の ; も忘れずに。
対象とする「テーブル」からある「条件」を満たす「カラム」を抽出する場合、この構文を使う。
今回の場合は、tbl_sryacct_main が各種集計の基本となるテーブルになりそうなので、まずは試しにこのテーブルの全カラムを sql から表示させてみる。

SELECT * FROM tbl_sryacct_main;

「条件」はないので WHERE は不要。これだけでいい。* は全てのカラムを意味する。実行結果は以下のようになる。

ここで特定の年月日のみを取り出したければ、WHERE 以下のその条件を書く。

上の文の最後に

WHERE tbl_sryacct_main.sryym=’202010′ and tbl_sryacct_main.day_22 > 0

を付加しよう。結果は以下のようになる。

これで、ある特定の日の診療行為の全ての情報が絞り込めたことになる。

なお、クエリ画面の上部の ⬇️ を押すとここまでの結果を CSV ファイルに書き出してくれる。

実務的には、これくらいの段階でエクセルなどに取り込んで加工した方が事務処理的には「慣れ」という意味でいいのかもしれない。イマドキの事務員さんならこれからあとの処理はお手の物でしょう。

 

tbl_sryacct_main テーブルを眺めると、このテーブルが、特定の患者に対するある月の個々の診療行為や投与薬剤を日別に集計したものであることがわかる。
上の例で言えば

95000001 は「インフルエンザ予防接種」(ここは施設によって異なる)
1110000110 が初診料
180020410 が通院精神療法(初診時60分以上)

だ。day_22 というカラムにこれらを施行した回数(今回は「1」)が書き込まれている。施行しなければ「0」になっている。

だから、day_22 > 0 という「条件」を加えると「22日」に医療行為をしたレコードをすべて拾い上げられるという理屈だ。

このときの保険種類が知りたければ、tbl_sryacct_main.hkncombi を表示させればよい。(SQL では表示させたいカラムは SELECT 直後に指定する)

これだけでも最低限所定の目的は実現できていると思うが、
tbl_sryacct_main.hkncombi
は数字でコードされているのでわかりにくい。この数字は、tbl_hkncombi という別のテーブルにより詳しい情報が記載されている。

だから、より丁寧にやるならば、tbl_sryacct_main と tbl_hkncombi を適当な形で結合させればいい。
「結合」のさせ方はいろいろあると思うが、今回は INNER JOIN を用いた。

ここまで理解できれば最初の方であげた SQL 文が何をやっているかわかってくると思う。

SELECT
tbl_sryacct_main.sryym,tbl_sryacct_main.day_22,tbl_hkncombi.syu_tanseidoname,tbl_sryacct_main.ptid,tbl_sryacct_main.srykbn,tbl_sryacct_main.zaiten
FROM public.tbl_sryacct_main
INNER JOIN public.tbl_hkncombi ON
tbl_sryacct_main.ptid = tbl_hkncombi.ptid
and tbl_sryacct_main.hkncombi = tbl_hkncombi.hkncombinum
WHERE tbl_sryacct_main.sryym=’202010′ and tbl_sryacct_main.day_22 > 0
and tbl_hkncombi.syu_tanseidoname !=’自費’;

SELECT 〜 FROM 〜 WHERE の基本構文に INNER JOIN を組み合わせて目的とする情報を取ってきている。
すごく大雑把に言えば、「関連するテーブルを結合させて、そこから条件にあったレコードを抽出して適当なカラムを表示させている」わけです。

 

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

 

グッズw

HorliX や OpenOcean のアイコンなどを利用して、Tシャツなどのグッズをつくってみました。

https://suzuri.jp/PHAZOR

からどうぞ。

なお、HorliX のアイコンは「二つあるのか?」と聞かれることがあるんですが、その通り二つあります。

 

で使われているのが、初期の頃使っていたもので、タイの若いデザイナーさんの手によるものです。

 

の方は、MacAppStore からリリースするにあたり、「シリアスな雰囲気の方がいいのでは?」という声が上がり、大急ぎで元アイコンの背景を流用して作り直したものです。

HorliX.app を走らせると環境によってはドックに元の可愛い感じのアイコンが出現することがあります。これはサプライズでもなんでもなくて、Xcode のバグです。

 

猪股弘明(HorliX 開発者)

 

今日の HorliX (2019/03/07)

医療画像ビューア HorliX は、Mac AppStore で世界に配信されている。
個人情報の収集はまったくしていないが、各国プラットフォームでどの程度売れたかは報告があがってくる。
顔本内では、そのデータを見て仲間内で盛り上がっていたのだが、こちらでも。


日本での顧客を増やすべく、ちょっと前に頑張って販売価格を1万以下、つまり
¥11800 → ¥9800
にしたのだが(なってますよね?)、全然反応しない日本市場(笑)。

海外では、ポーランド・イタリア・韓国でしっかり反応が出る。未だにユーザーの過半数は海外だ。

 

韓国は、実は初上陸。これで販売実績国は37。

 

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


しかし、よく売れていたものです。
こことかこことかにも痕跡が(笑)。

それはそうと
フリーかつオープンソースな医療画像ビューア HorliX について
COVID-19 による肺炎CT画像! <HorliXにて表示>
DICOM Viewer の準備
某先生 tweet
など
ご紹介ありがとうございます。