ORCA のインストールは、サーバで終わった感じになるが、WbORCA になってブラウザの方も少々手入れが必要だ。
(続く)
ようやく記事書ける
ORCA のインストールは、サーバで終わった感じになるが、WbORCA になってブラウザの方も少々手入れが必要だ。
(続く)
そういえば、ORCA をアンインストールしたい場合、どうするんだっけ?と調べたら、スカイエスエイチさんの Q&A のページに辿り着いた。
hasegawa@orca:~$ sudo /etc/init.d/jma-receipt stop
Stopping jma-receipt: glserver monitor glauth.hasegawa@orca:~$ sudo -u orca dropdb orca
DROP DATABASEhasegawa@orca:~$ sudo apt-get –purge remove jma-receipt postgresql
(省略)
Do you want to continue? [Y/n] y
(省略)
OK to remove these files and destroy the data? (y/n):yhasegawa@orca:~$ sudo reboot
一度再起動を行いプロセスを綺麗にします。
だそうです。
ところで、なんで ORCA に手を出しているかというと標準型電子カルテのレセコン呼び出しが ORCA API になることがほぼ確定したとわかったから。
しかし、ベンダーはまた微妙な感じになるだろうなあ・・・。
– 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(Horos/OsiriX ベースの画像ビューア。オープンソース) も起動。
特に深い意味はないんですが。
いや、しかし、壮観ですな。
一台の Mac の上で動いているってのにちょっと感動してます。
ところで、OpenDolphin・HorliX は、精神科医の猪股弘明先生の開発したバージョンを使ってます。
OpenDolphin は、オープンソースですから、当然、派生バージョンは色々とありますが、OpenDolphin-2.7m (今回、試したバージョン)は本家(dolphin-dev)に割合忠実です。これにはそれ相応の理由がありました。
『OpenDolphin について』、『OpenDolphin と電子カルテの3要件とメドレー』あたりがわかりやすいでしょうか。開発者本人がその経緯を語っています。
私も今回 OpenDolphin に触れてあれこれ感想を持ちましたので、機会があったら何か書いてみたいと思います。
画像ビューア HorliX に関する使い勝手などに関しては『COVID-19 による肺炎CT画像!<HorliXにて表示>』(精神科医高木希奈先生のアメブロ)に動画入りで紹介されていますので、そちらもご参照ください。
ところで、先生、最近、ブログで
という法律ガラミにしては?面白い記事を書いているので、こちらもよかったらどうぞ。
ところで ORCA に期待(懸念?)されていることは、本当に今の設計のままで意味のあるクラウド化ができるのかってことですが、これも猪股先生、一つの提案をしてくれました。
将来的には医療情報の類はクラウドに上げて一元管理・ビッグデータとしての活用を図る・・云々みたいな話は、まあそうだろうなとは思うのですが、このとき医療機関側が欲しい情報を取ってこれる環境になっていないとデメリットの方が大きく、実際には誰も参加しないだろうなと思います。
(法的にも医療情報の管理責任は、現状だと医療機関側です。業者ではありません)
欲しい情報を効率よく取ってこれるかどうかは、データ構造の整合性に大きく依存するのではないでしょうか。
これを実現する割と有効な選択肢は現在だといわゆるウェブフレームワークの採用かなと思ったわけです。オルカの職人芸的なデータベースの使い方も嫌いではありませんが(笑)、この後の展開を考えるとなるべくデータ間の「辻褄が合うように」整合性をはかっておく、モデル化しやすいように準備しておく、というのはあっていいのかなと思った次第です。
メーリス上で議論され、最終的には ORCA管理機構の人に「フレームワークの採用も検討してまいります」とまで言わせしめました。→結局、ORCA 管理機構、独自にウェブフレームワークを開発して、WebORCA をリリース。
また、最近では、ORCA のデータベース(PostrgreSQL)から直接データを抜いて、各種指標を加工する方法を提案しています。猪股先生ご自身が『ORCA の日計表と関連テーブル・内部会計フローなどについて』にまとめてくれています。
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
(技術協力 猪股弘明)