OpenOcean→DolphORCA→標準型電子カルテ

次世代 OpenOcean

OpenOcean の方は、「全面的に作り直してほしい」という要望が多くて、検討してました。
「自分で使う電子カルテは自分でつくりたい」、「OpenDolphin 使っていたが、大幅にカスタマイズしたい」という医師の方が意外に多い。
作り直すなら参戦したい、協力したいという企業もちらほら。
今のところ

・データ構造は変えないでほしい
(ただし、画像の JPEG 保存は、医療記録としての性質上、変えた方がいい -というかこれに関する後付けの機能や素人が思いつきで手を加えたような設計はやめろ- という声が多いので、変更予定)

・UIは変えてほしい(これは dolphin の頃から言われてましたね)

・win でも Mac でも動くようにしてほしい

というような希望があるようです。

意思表示示してくれたところとは、コンタクトとってますし、少しだけですが、上記の要望に沿った形で手はつけてます。
まだまだ、アウトライン決めてるところですので、似たような希望を持たれている方がいたら、ご連絡のほどを。手は多い方がいいので。

最近だと BOOSTER TECHNOLOGY さんが、会社ブログ(https://www.booster-technology.com/blog/opendolphin)で「サーバーサイドはJavaである必要はなさそうなので、保守やカスタマイズを考えると、PHP等のスクリプト言語で作り直してもいいと思う」、「クライアントアプリケーションもJavaのデスクトップアプリである必要はなさそうなので、ブラウザで使える普通のWebシステムにし、iPadでも使えるようにすればよいと思う」という観点から、似たような考えを述べられてます。Web アプリ案件を数多く取り扱っているような会社だと割合自然な発想で「ブラウザ型に作り直し」は有力な選択肢になるかなあと思います。PHPということは Laravel あたりを考えているんでしょうか。十分ありだと思います。

あとは、これまで ORCA 連動型電子カルテの前提条件である ORCA の運営そのものにもある種の疑問が呈されるようになってきた、という事態があります。

そのような状況なので、とりあえず、公開は中止してます。

 

(追記)その後、dolphin のデータベースからデータ抜いてきて、ブラウザに表示させる簡単なコードを書いてみました。
こんな感じになります。

こっから、ブラウザタイプに改変して・・・といきたいところですが(OpenOcean はこんな感じで作ろうと思っていた)、それはそれで手間かかりますので、まあ試験的な試みです。

(追記2)さらに手入れ。

結局、WYSWYG エディタも独自実装。

(追記3)ORCA は WebORCA になって蘇りましたね。正直あのまま旧世代のデスクトップアプリの方向性で進んでいたら見捨てていたと思います。

DolphORCA へ

結局、dolphin のコードは全て捨て去り、上記の要望などを勘案し DolphORCA というプロジェクトが始まりました。

標準型電子カルテ

たまたまなんですが、標準型電子カルテの厚労班会議に出席する機会があったため、DolphORCA を念頭においたシステムを軽めに提案させていただきました。

OceanMini

しばらく DolphORCA 系列は放置していたのだが、生成 AI の手を借りてOceanMini というアプリを新規に作成公開。
専用ページvector にて無料で配布してますので、ご興味のある方はダウンロードしてみてください。

OpenDolphin のソースコード利用に関して

ところで、ソースコードが公開されている電子カルテのプロジェクトなんて dolphin くらいしかないので、2次利用したいという人はちらほらいる。

最近ではるまさんが OpenDolphinNext で再利用している。

その際のディスカッションはここ参照。

要するに「dolphin-dev の LICENSE 文書自体が改竄されているため、適切な著作権表示になっていないので、本格的に再利用する際にはメドレーへの確認が必要だろう」ということです。

 

 

 

開いたイルカ

いるかの棲む闇』コメント欄で唐突に主要な「イルカ」のステークホルダーが揃って質疑応答が始まった。

増田氏、opendolphin-m は公開されていると主張しているけど、

本人自体が HP 上で非公開にしていることを主張しているんだよね。

え?と思って確認したけど本日(2018/10/23)もしっかりアナウンスしている。

外部サイト保管: archive

公開しているのはあくまでバックポート用のものであり、別の(本来の) OpenDolphin-m があると私は認識していたのだが。

また、LSC の方が言っていたが、「増田ファクトとLSC 商用版 OpenDolphin にはデータベースの互換性はない」そうである(そうである、というのは現時点では、私は両ソフトとも持っておらず確認してみようもないから。あくまで LSC さんから聞いた伝聞です)。

いろいろ矛盾しているように思う。
ここらへん、なんでこんなわかりにくい主張するのか私もよくわからない。

(追記)

やはり、プライベートリポジトリに移行した OpenDolphin-m がある、ということでいいようです。

なお、このツィートに関して私の友人は「増田ファクト版を商品化したベンダーがいたとかで『オープンソースを営利化するのは好まない』とクローズドにした経緯があるとかなんとか。個人の好悪で公開したり引っ込めたりする人は,そもそもオープンソースプロジェクトには向かない人ですね。」と感想を漏らしてました。

私も、ほぼ同意見です。ソースをオープンにした時点で、たとえそれが自分が気に入らない人の手に渡ろうがしょうがないと諦めるしかないと思います。

PHAZOR 関係でいうと responsive-kifu なんてパクられまくってますが(この表現、私は嫌いなんですが)、それはもうしょうがないですよ。
それが嫌だったら、プロジェクトを最初からクローズドで開発すればいいわけだし。

表現が今ひとつどうかなと思うところはありますが、せっかく OpenDolphin の開発中期の貢献者としての評判はお持ちなのですから(ただし、最近の調べでは GitHub のシステムにはほとんどソースコードを提供した記録は残されていないそうですね、これは私も知りませんでした。メドレーに譲渡以降は、メドレーからは「開発者」認定はされていないようです、これはメドレー担当者から直接聞きました)、あまり他者を蔑むような表現1)はしない方がいいのでは思います。

 

(1) 厚生労働省本省判断で医療広告のガイドラインに抵触したようで(おそらく「公序良俗に反する内容」ということで)、削除要請がなされたようですね。和歌山の保健所を通じて私にも確認のための連絡がありました。
同時に患者さんと思われる一般人の個人情報を SNS で流出させた形跡があるということでこれも確認させられました。どちらかといえば、こちらの方がまずいと思います。(→現在は増田内科は閉院しているようです。こういうクチコミもありますが、そんなに評判は悪くなかったようですが)

 

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

参考
OpenDolphin について
OpenDolphin と電子カルテの3要件とメドレー
いるかの都市伝説は本当だったか
ソースコード嫁
@masudanaika による個人情報流出ツィート
標準型電子カルテ・OpenDolphin・増田ファクトなど

 

 

にほんブログ村 病気ブログ 医者・医師へ

 

OpenOcean、海を渡る

なぜか、外国人にも人気の OpenOcean 。
某所で HorliX とも連携できますよ、とかアナウンスしたら、気にいってくれた人が出てきてくれた。

しかし、Ocean は ORCA と連動している。日本医師会が ORCA For US だの ORCA For China だのをつくってくれない限り、保険請求まではできないと思うのだが…。

(追記)保険請求を患者自らが行う国の場合、ORCA なしでもいけそうですね。だから fork したのか。ある程度、改造は必要ですが、可能だと思います。

 

にほんブログ村 病気ブログ 医者・医師へ

大人ベンチャー

幸いなことに DICOMViewer/PACS HorliX が好評なこともあり、それに引きづられるように OpenOcean も再評価されてきている。

まだぱらぱらと、という感じではあるが、医療ソフト関連企業からお誘いがかかるようになってきた。

先日、そのうちの一つの会社 A 社にお邪魔させてもらった。

A 社はこれまでゲーム業界で実績をつみ、その余力で電子カルテを独自開発、最近リリースした。他分野からの新規参入ということになる。

 

都内某所にあるオフィス。

もう、エントランスからしてこれまでの小規模電カルメーカーなんかとは違う。

 

なんでしょう、このお洒落な感じは?

内部には社員用のリラクシングルームなどもあったりして普通の人が想像するような「イマドキの IT 企業」である。

こういうところが電子カルテを作るようになったんだ。

 

私たちも OpenOcean というれっきとした電子カルテを持っているため競合勢力とみなされてもおかしくはないが、新規参入組は必死だ。私たちと組みたいという。

具体的な案件や電子カルテと DICOMViewer/PACS との連携の仕方といった実務的な内容はもちろん、今後の業界の在り方などにも話は及んだ。

小一時間ほど話し込んだが、最終的には和やかな感じで協力の合意にたどり着いたと思う。

 

ところで、昔ながらのユーザー囲い込みではなく、顧客の要望に応じ該当組織が得意な分野を持ち寄ってシステムを組むみたいな在り方が出てきた。誰かが「大人のベンチャーはこうじゃなきゃいけない」というようなことを言った。

つまり、子供っぽく自らの(組織としての)エゴ・都合を一方的に主張するのではなく、あくまで顧客の要望を尊重し、その準備として「大人の余裕」で共有できるもの・協力しあえることはギブ&テイクしておきましょうということだ。

「大人ベンチャー」なかなか良い言葉ではないか。

 

にほんブログ村 病気ブログ 医者・医師へ

 

OpenOcean/OpenDolphin をカスタマイズするために知っておいた方がよいこと 2

1 に引き続いて、軽く解説的な内容を少々。今回は少しばかりプロジェクトに接近していきます。

 

jar と war … 通常のソースコード ***.java を javac コマンドでコンパイルするとできるのは ***.class です。実行するには、「java 環境でクラスを呼び出す」必要があるので、コマンドは

java ***

となります。「コンパイル済みのクラスを呼び出す」これが Java アプリ実行の原則です。

ところが、Ocean/Dolphin プロジェクトでは、クライアントは OpenOcean.jar 、サーバーは OpenOcean.war などという名称です。

これは、ある程度まとまった機能を提供するためには、クラスだけでは足りず、設定ファイルや画像などのリソースファイルが必要なため、それらをまとめたファイル形式が必要とされたからです。jar は、その一つで Java ARchive からきています。読み方は「ジャー」でいいと思います。

Java EE を用いる Web アプリの場合には Web application ARchive 通称 war (ウォー :戦争 war と同発音)となります。

 

 

git と github … github は先日マイクロソフトに買収され、それを日経新聞が「設計図共有サイト、8200 億で買収」と報じたため、そのネーミングセンスが話題になりました。

オープンソースのソースをインターネット上で公開しておくには、何らかの場所(リポジトリ)が必要で、その一つが、GitHub (ギットハブ。ネイティブっぽく発音するならギッ ハブでしょうか)です。他には sourceforge などもありますが、ドルフィン一族は、その多くが GitHub でソースを公開しています。

公開されたソース(リモート)を自分のマシン(ローカル)にクローンすることもできます(というかしないとビルドできない)。

ローカルやリモートのリポジトリの橋渡しをしたり、改変を記録しておくためのシステムが Git (ギット)です。
雰囲気掴みたい人は『お手軽にWin機で Git や GitHub を使う』など参照。

歴史的に見るとまず Linux カーネル構築のためのバージョン管理システムとして Git がリーナス・トーバルズの手によってつくられ、そのホスティングサービスとして GitHub ができたわけですが、実用的には上のような理解でいいと思います。

windows にはデフォルトで git コマンドが入っていないため(ですよね?)、自前で git が使える環境を構築する必要があります。私は随分前に構築したっきりなのですが、それなりに面倒だった記憶があります。たぶん、ここらへんで多くの人が嫌気をさすのではないかと思います。

ただ、ここらへんくらいまでの知識があれば、ビルド・デプロイはなんとかできるでしょうか。

Open Dolphin 2.7.0b を Win10 にインストールしてみた

や、外部サイトですが

OpenDolphin 2.7(m) を Mac OSX にインストールする
OpenDolphin-2.7m を M1 Mac にインストールする

あたりの記事をどうぞ。
ソースコードは

github https://github.com/Hiroaki-Inomata/OpenDolphin-2.7m

に置いてあります。

 

デザインパターン…迂闊なことをいうと本職の方々に怒られそうなので wiki から引用しておくと

 

ソフトウェア開発におけるデザインパターン(型紙(かたがみ)または設計パターン、英: design pattern)とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。

 

だそうです。ソースと最終産物との間にある中間的な機能を設計する上での定型的なパターン、とでもいったらいいんでしょうか。
apple 系のOS のフレームワーク( cocoa と cocoa touch )で頻出の「xxxxdelegate」も典型的なデザインパターンの一つです。
ですが、プログラミングの初心者コースではまずは教えないと思うので、それなりに経験積んだ人でも知らない人は知らないんではないでしょうか。OpenOcean/OpenDolphin ではシングルトンやメニューファクトリーといったパターンが使われています。
これがある程度頭に入ってないと、ソースを追っていっても何やってるかわからなくなると思います。逆に C++ あたりで過去に一回でも経験しているとその類推で何とかなることも多いと思います。

 

 

実際に改変を試みようとするとここら辺から、難しくなってくるのかなと思います。

後は、主要なライブラリなどでしょうか。私もいまだに使い方がわかっていないライブラリは山ほどあります。

Java のライブラリとしては、ORM の Hibernate が有名ですね。ORM や Hibernate に関しては、他サイトですが

ORM に関して書くよ

をご参照ください。雰囲気掴めるかと思います。

? 参考
より詳細なソースコードレベルでの解説は
OpenDolphin ソースコード解説
を参考にしてください。

OpenOcean / HorliX 開発チーム

 

 

にほんブログ村 病気ブログ 医者・医師へ

PACS との連携機能など

HorliX の基本機能の整備もいいところにきた感じがあるので、次のフェイズ、例えば、Ocean との連携機能に関してそろそろ考えてみる。

お手本になりそうな情報を物色。

Panasonic: MedicomHR-3 と FujiFilm: C@RNAcore との連携の例

これはなかなか上手い連携の例だと思う。カスタマイズ料も高くつきそうだが。

オーダリング機能もちょっぴり入っているが、外来中心のクリニックならこういう構成の方が支持されるのかもしれない。

この手の連携機能は特定の機種間のみにした方が ー例えば HorliX と OpenOcean のみとかー 商売という面ではアドバンテージになるのかもしれないが、この時代にその手の「囲い込み」戦略は支持されない気がするので、組んで不都合のない相手とは組んでいきたいと思っている。

 

にほんブログ村 病気ブログ 医者・医師へ

OpenOcean クライアントと Docker 版 OpenDolphin サーバをつなげる

(注意)下記の記事では

機能追加や細部の改変はしてもデータ構造や通信様態は本家を尊重する

と言い切ってますが、画像が JPEG でしか保存できないのは、今の時代にあってないので、今後はここら辺は変更する予定です。
そもそも java17 では、画像処理周りの古いコードが原因でサーバープログラムを少々手直しした程度ではアプリケーションサーバ(WildFly)にデプロイすらできないと思います。


Docker 版 OpenDolphin サーバは人気が高いようなので、OpenOcean クライアントとつないでみました。

クライアントのダウンロードページはこちら

 

「機能追加や細部の改変はしてもデータ構造や通信様態は本家を尊重する」という方針なので、当初、「そんなに難しくない、何もしなくてもつながる」くらいに思っていたんですが、初試行では見事につながりませんでした。

ログイン情報が違ってます

の嫌なアラートが….。

しばらく、頭上に?浮かばせてましたが、Docker の Dolphin (WildFly)が吐き出してくれるログに手掛かりがありました。(Docker 版でも設定でログを表示させることができます)

 

hibernate (JavaORM)が走ったあとに

web context '/dolphin'

という見慣れぬ表記が。これ通常だと openDolphin なんですよね。

なのでソースの該当箇所を修正。Docker 版と商用版ではここがちがっていたわけですね。通りでつながらないわけだ。

修正後は、無事つながりましたが、当方の通信環境はそれほどよくなく(たぶんルータの性能がいまいち)一台のPC(win10)上に

  • クライアント Ocean クライアント   windows10 (ホスト)
  • サーバ       Dolphin サーバ(Docker)  Ubuntu14 (VMWare の仮想マシン)
  • ORCAサーバ     ORCA Ver5                     Ubuntu16 (VMWare の仮想マシン)

が混在するという二度とやりたくないような構成になりました。なりゆき上。

ただ、データ構造さえ同一に保っていれば、出自が異なっていたとしても接続は問題なくできるわけで(少々、苦労はしますが)、互換性という点でもオープンソースはメリットがあるなと思います。

 

なお、ここらへんの機種間の API の差を埋める目的で HL7 (エイチエルセブン)という団体が FHIR という仕様を公開してます。

FHIR Ver3.0.1

一瞬、なるほど、と思ったのだが、これを採用しても、肝心かなめのデータの構造がやり取りする両者で同一でないと院内システムへは結局復号化できないまま終わってしまうような…。まあ、医療情報の「交換」規格というコンセプトが強いんでしょうね。
ユーロ圏内や北米などでは、圏内での人の移動や移民の問題などがあり、こういったシステムの構築は必要性が高いんでしょう。

 

にほんブログ村 病気ブログ 医者・医師へ

OpenOcean クライアントを Mac で動かす

OpenOcean クライアントバイナリを試験的に公開。

自分の Mac にもインターネット経由で落として使ってみる。(今まで win 機でコーディングしていたので Mac での確認はしてなかった)

まず、起動。

ログイン画面描画は問題なし。

ログインも問題なかったが、なぜか受付情報を受け取れない……。

閉塞」という嫌な文字が ORCA に表示されている。

必殺の wi-fi 切断-再接続を試みる。

当方の環境だとなぜかこれでつながり始める。一昔前のブラウン管チョップと感覚は似ている。

カルテの参照なども問題なし。やはり Mac は表示が綺麗。

しかーし、

  • 処方せん打ち出し機能が選べない
  • ホームフォルダにできてるはずのフォルダができてない

などの不具合あり。→マイナーチェンジで修正しました

と言ってたんですが、処方せん打ち出しはできますね。

という画面が現れて、「PDF 作成」を押下すると

というそれはそれは美しい処方せんが出現する。

Mac でも開発環境つくろうかな?

できた!

つか、以前に Dolphin ビルドしたときに Java 環境構築したの忘れてたわ。その時の流用。

これで HorliX との連携機能は組みやすくなるかな。

(追記)より最新の OpenDolphin 開発環境は
OpenDolphin-2.7(m) を Mac OS X にインストールする
をご参照ください。
M1 Mac へのインストール&デプロイは
OpenDolphin-2.7m を M1 Mac にインストールする
をお読みください。

 

 

 

にほんブログ村 病気ブログ 医者・医師へ

このアプローチは…

OpenDolphin から OpenOcean に改名したので、今までの仕事をまとめておこうと思い、サイトを新調した。
その際に、ネット上で情報収集をおこなったのだが、けっこう興味深かったのが、

ゼミの飛翔』というブログのこの記事

医療情報系の大学研究室のゼミの公開ブログのようなのだけど、題材として OpenDolphin が取り上げられている。将来的には Dolphin と繋がるオリジナルのスマホアプリをつくりたいらしい。それで、データ構造を把握するためにクライアント-サーバ 間で流れる通信パケットを WireShark でキャプチャして解析したという予備研究。

これはこれで SSL 通信の重要性を示すものとしてまあまあ意味はあると思うけど、目的に対するアプローチの仕方としてはどうなんだろう?

 

というのは…

サーバを走らせた場合、キャプチャしなくても通信内容は同様のものが得られる

というのがその理由の一つ。上記記事を再現してみると「嘔吐・下痢の症状が見られる」という所見を SOA 欄に書き込み、サーバに送信。

ドッカーでは無理だが、普通にサーバを走らせていた場合、Java の(というか Java のライブラリの)ロガーは優秀なので、Win だろうが Mac だろうが Ubuntu だろうが、こんなログを吐き出してくれる(今回は Win10)。

所見の平文対応文字列「PD…(略)…4K」は(当たり前だが)まったくいっしょ。

だから、サーバを走らせれば、キャプチャする意味は(ほぼ)ないのだ。

他にも別の unix 系のコマンドを使えば、通信内容の取得は可能です。

 

また、トライアンドエラーでサーバの応答をある程度まで求め、それにあわせてクライアントをつくったとしても、

LSC がサーバの仕様を変えてしまえば、そのアプリは使えなくなる

のではないかと思う。

 

そして、これは研究全体の方向性に対することだが、

改変不能なドッカー版サーバを使っている限り、クライアントの仕様はサーバに規定され、クライアントの設計の自由度が落ちるのではないか

という疑問が湧く。

最終的にどういうスマホアプリを目指されているか私程度のものが知る由もないが、個人的には、われわれのように実務家的なちまちまとした工夫を重ねるのではなく、大学には、大学の研究らしくもっと自由で大胆な発想をしてほしいと思う。

 

まあ、私のおすすめは、自由にスマホアプリをつくりたければ、サーバ・クライアントともに Java ソース読んだ方がいいでしょう、ということです。

せっかくソースを公開してくれているのだから。

OpenDolphin で実現されている REST API の仕組みなどはこの分野の基本といってよく、勉強しておいて損のないところだと思います。

 

(追記)…beanbytes の処理に関しては、元町皮膚科の松村先生のブログ記事にわかりやすい解説があったので、追記しておく。

 

HealthInsuranceModel,StampModel,ModuleModel には beanBytes というフィールドがあり,bean object を xml 変換して,さらにbyte 配列に変換したものが入って永続化されている。今回,REST化で json を使ったため,object が xml に変換されてさらに byte 配列に変換された beanBytes が json 化でさらに Base64 の文字列に変換されて流されるという,何だかたいそう複雑なことになってしまっていた。

 

引用元『beanBytes の処理:Rest(付録)

(追記2)なお、現在の開発元のメドレーによれば、松村哲理氏は contirbutor として認められていないので、念の為。

いわゆる「契約」問題の話はおいておいても・・・

beanBytes の説明自体は間違ってはいない(ただし、基本設計を考えるとこの通信形式はそんなにおかしくもない)。が、dolphin が画像を保存する際、jpeg に限定されてしまうのだが、ここらへんの不自然さに対する説明は一切なし。

シェーマエディタは、佐藤純三氏のコードの上に後付けで実装されたものなので、この機能を外してしまうと(外しても動作するし、外したバージョンの方が好評。たぶん、一部の診療科以外、この機能は不要なんでしょう)、彼の貢献はほぼなくなってしまう。

・・・といった理由からでしょうか。

そもそも、わざわざ実装した画像エディタの保存形式が(lossless でない) JPEG 限定とか、臨床に従事している医師の感覚ではちょっとあり得ない感じです。

実際、

公式資料から、「オープンソース化した時点で、(松村哲理が開発したとされている)シェーマエディタの原型は既に実装されていた」こと

少なくとも 2004 年時点ではスキーマエディタの原型は実装されており、その後にしか関われないはずの医師(松村哲理)が基本設計レベルの開発に関与できるわけがない、公式のアナウンスが資料と矛盾している、などの指摘がなされている。

・LSC リポジトリに松村哲理のソースコード提供の痕跡はまったく残されていないこと

がわかっており、事後的に(特にメドレー移管以降は)プロジェクトへの貢献の程度を判定するのが難しくなっているという事情があるためでしょう。

あと、増田茂とつるんでこういうツィートするような人なので基本的に信用していません。
OpenDolphin-2.7m のリポジトリ見ればわかるけど、コーダーとしてはかなりアヤしい人でもそっくりそのままクレジットしてますけどね。
なんで確認もせずに誹謗中傷まがいの発言するんだろう?
医師としての人格疑われるだけだと思うんだけど?

(追記3)私の周囲のユーザーさんは「医療画像を情報損失のある JPEG で保存するのは論外だし、その上にのっている機能も不要」という声が多数を占めているので、DolphORCA では、ここら辺は修正予定。

(追記4)いわゆる java17 問題で、画像周りの問題はさらに顕在化。
OpenDolphin では、swing GUI コンポーネント上に強引に表示させた画像を hibernate で永続化する、という手法をとっています。
が、これは今となってはかなり無理のある構成なので、公開されている opendolphin のソースコードを少々手直しした程度では、(今のところ)サーバープログラムはアプリケーションサーバにデプロイできません。

ライブラリなどの開発元が古い swing コンポーネントの対応をしてくれれば解決はするんですが、現状では実現されていません。

自力運用している施設では java のアップデートに合わせて松村哲理氏、増田茂氏がクライアントアプリに付加した機能を取り外す方向で検討しているところが多いようです。

 

にほんブログ村 病気ブログ 医者・医師へ