先日、標準型電子カルテの技術作業班に出席してきた。

まだ、手探りの状況だなと感じたが、これまでのまとめなどを『医療DXと標準型電子カルテ』に書き綴っていますので、ご興味のある方はご一読のほどを。

猪股弘明

精神科医：精神保健指定医

HorliX のメンテナンス・発展形態もろもろについて考えてみたが、

・OpenGL -> Metal の完全移行が起こった場合、アプリそのものが使えなくなる

・UI が Xib 形式でこれも賞味期限切れになる可能性が高い

・現状でも、他人の書いたコードを読むのが苦痛になってきた

などなどあって、今すぐというわけではないが、将来的な移行を見据えて、試しに画像ビューアーのプロトタイプを作成した。

通常の非圧縮データに加え、JPEG2000 や JPEG-LS にも対応しているので、CR や大抵の CT （シリーズ）なら、ほぼほぼ描画できるはずだ。

詳細は『PHORLIX ベータテスト』をご覧ください。

以前に書いた記事で DICOM を取り扱うソフトは、データ構造として

Patient - Study - Series - Image(s)

になっていると書いたが、そうはなっていないものもある。

代表例は OsiriX の open source version で、少なくともデータベースの構造は

Alubum - Study - Series - Image(s)

という階層を採用している。

OsiriX と言っても商用版はもはやオープンソースではないので確かめてみようがないが、少なくとも Ver 5 あたりまでは、この構造になっている。

だから、オープンソース時代の OsiriX をベースに開発された Horos や HorliX も基本的には同じデータベース構造になっている。

上に掲げた図は、OsiriX 系の dicom viewer のデータベースのテーブル間の関係性をソースコードを基にまとめたものだ。
Album, Study, Series, Image が実際にデータベースとして使われている sqlite のテーブルに対応しており、Attribute がカラムに対応している。ただし、ソースコードをベースに機械的に図に起こしたものなので、現在では使われていないカラムも含まれている。例えば、Album の index はソースコード上では Int32 （符号付32ビット整数）で定義はされているが、実際には使われていない。

では、HorliX にスタディを一つだけ登録してみよう。

このとき、実際のデータベースの ZSTUDY テーブルは以下のようになっている。

ダイコムファイルを取り込んだ際などに患者 id を正しく設定してさえおけば、sqlite の patientid のカラムはその施設で使っている施設の患者 id と一致するはずだ。
patientuid は デフォルトの設定では'患者名-患者 id-患者birthday' になる。
この設定は、HorliX では menu -> HorliX -> 設定 -> データベース の以下のパネルで微調整はできる。

ただし、UID とは言っても多施設で使用した場合は、これは必ずしも Unique な ID にはならない。
施設 A にも 00003 さんはいるだろうし、施設 B にも 00003 さんはいる可能性があるからだ。
だから、多施設で使われることを前提にした電子カルテなどと連動させる場合には、この点には注意をする必要がある。

ところで、UI にも採用されている Album を階層の一番上に持ってきたのは、使いやすさを考慮してのことなのだろう。

だが、この構造を採用したことで、他の医療ソフトと連動させた時などに若干の影響は出ると思う。

通常であれば、単純には、トップの階層のテーブルにある患者の id 同士を照合させて欲しいデータをとってくればいいが、この構造では、いったん、一階層落ちて Study の patientid または patientuid で照合をさせる必要があるからだ。

猪股弘明
HorliX: 開発者
Horos: contributor, OsiriX(OpenSource Version): contributor

特にどれ（次世代 HorliX や DolphORCA など）に使うとは決めていないのだが、そろそろ画像周りも手をつけてみたい、ということで、指定したファイルを返却してくれる api を含むサーバープログラムを作成。

自分で言うのもなんですが、なかなか綺麗ですね。

ところで、カルテからダイコムなどの画像の類を自由に操作できるようにしたらいいのに、というような要望があったりするが、これはけっこう面倒。

最も簡単な構成は、患者データに画像データを従属させたり、カルテ自体にダイコムデータを持たせたりすることだが、ちょっと考えるとこの構成は冗長すぎて合理的でないというのがわかる。
カルテ自体は何度も書き換えられるが、このやり方だと原則その都度画像も保管されてしまう。
一般的に画像系のデータの方が「重い」ので、ストレージの有効活用という意味でこのやり方はまったく非効率的だ。

そこで、画像系のデータは PACS というサーバに別系統で保管しておきましょう、という話になるわけだが、長らく使われてきた DICOM 規格は、多施設で使われていることを前提にしていない。
現在は、どうなってるか詳しく調べていないが、基本的に

　Patient - Study - Series - Image(s)

という階層構造でデータを保管しておくことになっている。

一方、カルテ系はやや多施設を意識するようにはなってきているが、国民総背番号制みたいなのは導入されていないので、こちらは

　Facility（施設）- Patient - karte

という構造にせざるを得ない。
実際の医療事務処理がそうしているように、施設がまずあってそこに「患者を登録」するわけだ。
この処理が済んでからようやくカルテ記載ができるようになる。

ちょっと考えてみればわかるが、このとき登録された患者の以前の画像記録を他の施設から引っ張ってこようとすると、ここまでの枠組みでは原則「できない」。

ここら辺のデータ構造の差異に由来する両者のミスマッチを解消する方法の一つは、国民全員登録の PACS サーバを用意することだが、どんだけストレージ必要なんでしょう？

現状だととても無理ではないでしょうか。

猪股弘明

精神科医（精神保健指定医）

ここでも OpenDolphin の後継をどうするかあれこれ言っていたのだが、結局、DolphORCA というプロジェクトがそれに相当するものになりそう。

勤務医をやっていると電子カルテそのものを作成する必要性がないので、OpenOcean だとかなんだとか言って放置していたのだが、2022/10 頃から、OpenDolphin HTML/PDF Viewer をウェブサーバー化して、３層クラサバ構成にして、バックエンドサーバーをフリーで公開したら、コミュニティがいくらか活発化して、進行がいきなり加速した。

ちなみに比較的最近の Ver 1.5.1 では、カルテ閲覧画面は以下のようになっている。

まだまだ、作り込みが十分ではないが、基本機能（カルテ記載内容のデータベースへの読み出し・書き込みや ORCA などのソフトとの通信など）はかなり安定している。

ところで、DolphORCA では、3-tier client server system というアーキテクチャを採用しているが、この概略に関しては
『DolphORCA と三層クライアントサーバシステム』
で、コーディング時の留意点は
『DolphORCA』
で述べている。

Ver1.2 のバックエンドサーバーバイナリは
『DolphORCA Backend Server ダウンロードページ』
と
github: https://github.com/Hiroaki-Inomata/DolphORCA-back-binary
で配布している。

猪股弘明
精神科医（精神保健指定医）
OpenDolphin-2.7m, HorliX など開発

コロナ後遺症の精神症状（特に６ヶ月程度で消失するもの）について、「正直、これ、大半は単なるコロナ発症をきっかけとした心因反応でしょう」という趣旨の記事を

『コロナ後遺症の精神症状について』（biophysical psychiatry +）

に書きましたので、ご興味ある方はご一読ください。
ごく簡単なものですが、臨床に従事している先生方からは概ね好意的に受けとめられているようです。

しかし、

（患者さんの）自己申告で診断書書いている先生もおられるようですが...

もし、そうなら、それは医学でもなんでもないと思う。


猪股弘明
医師：精神科（精神保健指定医）

日本医師会が主導して開発を進めている ORCA （オルカ）というレセコンソフトは、クラウド化を目指しているそうだが、もともと無床診療所向けにローカルで稼働することを想定して設計されていたため、必ずしもうまくはいってないようだ。
そのような背景もあるのか、「ORCA に関して調べてもらえないか？」みたいな依頼がぱらぱらとあった。

ソースコードを読んだり、データベースの構造を調べたりで、ORCA に関しては自分なりには大雑把に評価できたかなとは思うんだが、その延長で現行の ORCA の足りない点を補うようなコンセプチュアルなモデルをいくつかつくってみた。
上のは、現行 ORCA に「被せる」ようなタイプ。

他にも色々な考え方はあるだろうし、実際、既に市販されている製品もある。

さらに、ついででこれに載るような電子カルテ風の UI を作成したら、周囲からの評判は割り合いよかった。

以前に、OpenDolphin-2.7m ベースの OpenOcean というのもあったのだが、機能的には OpenDolphin-2.7m と大差はなく、なんやかんやで現在は配布もソースコードの公開もしていない。

「作り直す」とは言っていたので、これはちょうど良いタイミングだったかもしれない。

今後は、こちらの方を便宜的に OpenOcean と呼ぶことにする。

→結局、DolphORCA プロジェクトに統合されました。

猪股弘明　医師：精神科：精神保健指定医

HorliX, OpenDolphin-2.7m 開発者

HorliX と薬機法

HorliX （という Horos / OsiriX ベースの画像ビューア）に関連して横浜市から薬機法ガラミで問い合わせ（正式な行政指導の類ではなく単なる問い合わせ）があったので、軽く返答。そのときの経緯みたいなものを『心電図アプリと薬機法と HorliX』に書いておきました。

そこでも書いてますが、現行 HorliX で薬機法認証/承認をとるつもりは積極的にはないです。「積極的にはない」というのは、たまにエラい先生から「きちんと取ったらどうだ」と諭されることがあるから。

いやあ、でもあのクラスのソフトを認可取れる水準でメンテしていくのは大変ですよ、とてもとても。
（→ある程度、技術に明るい人からすると元になった horos に「手抜き」アルゴリズムが散見される。手抜きといっても実用上はほとんど問題ないですが。でも、認証/承認を取る気ならばこれらを丹念に一つ一つ潰していけなければならず、かなりのコストがかかる→結局、PHORLIX プロジェクトへ）

なお、薬機法を取っていないデバイス・プログラムは、その使用にはある程度の制限がかかるのは、たいていの医師なら認識していることなので、ここで詳しく述べない。

『HorliX とは？』でも書いてますが、

HorliX 自体は薬機法認証/承認は取っていませんので、医療機関内で使用する場合には医師の自己責任でお使いください。ただし、院内システムの情報転送用など直接診断に関わらない目的での使用に関しては特に問題はないそうです（厚労省確認済み）。

というのが現行法規下での基本的な考え方でしょう。

原則的には、医療情報を単に記録・閲覧するソフトは「プログラム医療機器」には該当しないのだ。
また、医師と歯科医師が主体的に行う臨床研究にあっては薬機法の対象から除外される場合も多い。

最近では知り合いの臨床医の先生に『COVID-19 による肺炎CT画像！＜HorliXにて表示＞』で紹介してもらいましたが、そのことを踏まえた表現になっているかと思います。

一方、臨床経験のない自治体薬事担当者やクリニックレベルのシステム構築程度の仕事しかしてない業者あたりだと、経験や知識不足は否めず、ここらへんのニュアンスはなかなか伝わらないかもしれませんね。

厚労省もその点を考慮してか「医療機器（プログラム）に関しては、自治体独断で判断をくださないように」という趣旨の通達を出している。

なお、HorliX のソースコードは

 github: https://github.com/Hiroaki-Inomata/HorliX

 gitlab: https://gitlab.com/Hiroaki-Inomata/HorliX

で、公開しています。 

猪股弘明　　　　　　　　　　　

精神科：精神保健指定医　　　　
HorliX, OpenDolphin-2.7m 開発者

ごくごく仲間内で出していた電子書籍に

という kindle 本があるんですが、昨年末の増補改訂時に２章ほど私も寄稿させてもらいました。

全体的なコンセプトとしては、これから現場（病院内・在宅）に出ることが期待されている薬剤師さん向けに、現場に出るにあたって知っておいて欲しい臨床的な知識を読み物形式でまとめてあります。
私は、貼付剤と精神科の臨床実地問題を担当。

OpenDolphin-2.7m

問い合わせが今でもちらほらあるので書いておくと、オープンソースの電子カルテ OpenDolphin 2.7(m) のインストール・デプロイ方法は

に解説してあります。
（最近の Java 環境だと『OpenDolphin-2.7(m) を Mac OSX にインストールする』、特に M1(arm) Mac マシンへのインストール＆デプロイは『OpenDolphin-2.7m を M1 Mac にインストールする』あたりも参考になると思います）

そこで出てくるMavenやNetbeansって何？という方は

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

をご参照ください。

これらをある程度読んだ上で質問などしてもらうと有り難いです。

なお、OpenDolphin-2.7m は、ソースコードが公開されていた LSC 開発時代の OpenDolphin-2.7.0b を直接 Fork したもので、これをベースに bugfix を施しいくつかの機能追加をしたバージョンです。

だからデータ構造などは 、本家と同一。これをさらに Fork したものが OpenOcean です。

小林慎治（当時、京都大。現在、国立保健医療科学院）という人が OpenOcean をどこかで「Fork の Fork の Fork」と紹介していたそうだが、上記の順番で Fork しているので、明らかに一つ多い。正確には「Fork の Fork」です 。
ソースコードを読んでいないか、読む能力がないのかはわからないが（なにしろ一面識もない）、最低限のファクトチェックはして欲しいものだ。
さらにうと、彼は私のリポジトリから本家の方へ修正依頼（PR）を送れといっていたのだが、仮に上の Fork 順が正しいとすると gihub の仕様上、PR は送れない。いっていることが実現不可能で矛盾している。こういう言動はやめてもらいたい。

※・・ところで、最近、小林慎治さんが所属している保健医療科学院というところから、「国家公務員法違反（守秘義務違反、信用失墜行為、政治的行為の制限違反）の疑いがあるので厳重注意した。不愉快な思いをさせてしまい、大変申し訳ありません」という主旨の謝罪のメールをいただきました。細かい経緯はよくわからないのですが、他のオープンソースのプロジェクトで行動規範を逸脱する言動があったとのことです。過去の SNS 上などでの表現にも不適切なものがあったということで、当方にもそれらの確認・照会がありました。明らかな事実誤認（上記の Fork 順や ライセンス変更に関するもの）などに関して軽く回答させていただきました。そういったいきさつの上でのメールです。

さらに、小林慎治の主張を何の検証もせずに無批判にSNSで拡散させようとしたオープンソース活動家？のような人（小山哲央。当時アーク情報システム所属）がいるのだが、このような行為もやめてほしいものだ。
特に Fork 順などはソースコードを比較すれば、比較的簡単に判明することなのに（『ソースコード嫁』参照）、それをせずにオープンソースやそのライセンスを云々するのはかなりナンセンスに見える。

また、フォーク元となった OpenDolphin-2.7.0b には oracle のサンプルコードや Junzo SATO 氏が作成したコードや funabashi 氏が作成したコードも含まれていたため、あらぬ誤解が生じないようこの点に配慮してソースコード「全体」を
GitHub https://github.com/Hiroaki-Inomata/OpenDolphin-2.7m 
GitLab https://gitlab.com/Hiroaki-Inomata/OpenDolphin-2-7m
に一般に公開している。
そのほか開発の経緯などは『OpenDolphin について』や『OpenDolphin と電子カルテの３要件とメドレー』に書いてあります。


最近では、商用開発元がライフサイエンスコンピューティング（LSC）からメドレーに移るということで、当方にもちらほら問い合わせがありました。
これは、移行に伴いクラウド版に強制移行になるのではないか？という懸念が生じ、その前にデータを外部に抽出しておきたいという意図が働いたためのようです。

カルテ記載内容などは、基本的にはリレーショナルデータベースに記録（永続化）してあります。だから、記録方法がある程度類推がつけば適当なプログラムを組むことで電子カルテを経由せずに内容物を外部に書き出すことはできます。

なのですが、関係者のお話では、ローカルで走るいわゆるオンプレミス版も開発は継続するとのことでした。
今回は問題になることはなかったようですが、電子カルテを用いる限り、この手の問題は必ずつきまとうものなので、何らかの形で準備はしておいた方がいいと思われます。
（『OpenDolphin と電子カルテの３要件とメドレー』や『OpenDolphin ソースコード解説』などもご覧ください）

なお、永続化の形式などについては『電子カルテ OpenDolphin 2.7 (系列) FAQ』に軽く解説してあります。
より詳しく知りたい方は『OpenDolphin コード解説 -FileBackUpSystem と電子カルテのデータ構造-』にデータベースレベルですが、どのようにカルテ記載内容が格納されているかを解説してあります。


自力でデータの移行ができないようでしたら、SNS などでお気軽に連絡をもらえればと思います。


今後の方向性などは、『医療「AI」ソフト』・『OpenOcean』などをご覧ください。
OpenDolphin 全般、特に GitHub がどのように使われてきたかは『OpenDolphin wiki 風解説』の特にこの項目を参考にしてください。

最近では、商用版もメンテ程度になってきたため、他電子カルテへの乗り換えを検討している商用ユーザーさんが増えているようです。
まあ、自力運用している施設は使っていくとは思いますが。
ここで頭を悩ますのはデータ移行・保管だと思います。
当方が提供しているデータ移行ツール（上記言及）は『Save the DolphinS』で案内してあります。

ただ、これは専らデータの移行を目的として開発したツールですので、閲覧には不向きです。
そこで、出力をブラウザで閲覧できる html 形式に対応させ独立したソフトとしました。
こちらは『OpenDolphin HTML Viewer』で案内してあります。

データ移行は必要ない、データの保管と閲覧だけできればよいという場合には、こちらの方が便利でしょう。
dolphin データベースに直接アクセスしてその情報を復号しているので、WildFly などのアプリケーションサーバーは不要です。 

なお、厚労省にも軽く問い合わせましたが、この程度までデータ抽出できていれば OK だそうです。
逆に途中経過版や修正履歴などが表示できないものは NG だそうです。
細かな基準に関しては現在検討中とのことでした。

JakartaEE 9.1, Java17 対応

OpenDolphin は、動作環境として長らく JavaEE をベースにしていたのだが、JavaEE が JaKartaEE へと進化したため、OpenDolphin 自体を JakartaEE に対応させました。

これに伴って

・Java17 対応

・画像処理周りの一部変更

・ウェブレイヤーの追加

などプロジェクトの構成自体も変更になっています。

『OpenDolphin Ver6』で軽く案内しています。

ORCA

OpenDolphin はレセコン ORCA（日医標準レセプトソフト） と連動して動くのだが、今までじっくりソースコードを読んだことはなかった。
なんとなく居心地が悪いので、最近、ちらちら読み始めました。

『ORCA』、『Inside ORCA』、『ORCA のソースコードを取得する』、『レセコンソフト ORCA を巡るあれこれ』、『ORCA Plus というレセコンユーティリティソフトをつくっていて気がついたんだが』

あたりをご参考に。

ORCA データベース構造の検討

ORCA の意義は誰しもが認めることだと思うが、用途の拡大とそれに伴う機能拡張に若干の無理が生じてきているようで、公式MLにいくつか投稿しました。
これやこれやこれなど参照。
質疑応答の結果、ORCA 運営側より

猪股先生

ご指摘ごもっともです。
仰るとおりで、ぐうの音も出ません。
フレームワークの採用も検討してまいります。

という回答がありましたので、フレームワークを用いた改修は検討課題の一つにはなったようです。

→なお、現在（2022/4）では、上記の問題を改善するためか WebORCA というサービスがリリースされています。

公式サイトの説明だけだとわかりにくいですが、MLの方で上野さんがユーザーからの疑問に応える形でかなり明確に開発方針を明らかにしています。

ORCA管理機構の上野です

>webORCAと言う名前を見ました
>日レセクラウド版ともちがうのでしょう

WebORCAは、私どもで次世代のORCAと位置づけており、
従来のクラウド版（ginbee）を独自に開発した、Webアプリのフレームワークに移植したものです。
画面は同じまま、安定性や動作速度で大幅に優れています。

>オンブレミスは廃止の方向ですか？

ginbee についてはWebORCAへの移行を進めておりますが
オンプレミス版は継続の方向です。
ただし、現状のオンプレミス版は、近い将来、WebORCAのオンプレミス版（ブラウザで利用できる
ORCAのWebサーバ）としてリリースしたいと考えています。

オンプレとクラウドのWebORCAスキームへの統一には、メンテナンスコストを削減するという点以外に、
大規模な災害や障害に強いハイブリッドな環境を提供するという目標があります。

ウェブフレームワークの採用は私（猪股）も提案していましたが、とうとう本格採用となったようです。

ただし、2022/6 現時点でもユーザーの評価はほとんどなく、まともなベンチマーク比較も誰も行っておらず、ユーザー・取り扱い業者などからの関心は極めて薄いようです。
私も、（WebORCA は）
・オープンソースではない
・基本設計が多施設対応になっていない
・一社が開発したフレームワーク（しかも非公開）を採用しており、信頼性に欠ける

 などの理由で現時点では特に強い興味を持ってはいません。

ORCA のデータ加工・２次利用に関して

MLの質問に答える形でいくつかレスしたんですが、少々わかりにくかったと思い『ORCA の日計表と関連テーブル・内部会計フローについて』に解説入れてまとめておきました。

ご参考までに。

 

先日、標準型電子カルテの技術作業班に出席してきた。

まだ、手探りの状況だなと感じたが、これまでのまとめなどを『医療DXと標準型電子カルテ』に書き綴っていますので、ご興味のある方はご一読のほどを。

猪股弘明

精神科医：精神保健指定医

HorliX のメンテナンス・発展形態もろもろについて考えてみたが、

・OpenGL -> Metal の完全移行が起こった場合、アプリそのものが使えなくなる

・UI が Xib 形式でこれも賞味期限切れになる可能性が高い

・現状でも、他人の書いたコードを読むのが苦痛になってきた

などなどあって、今すぐというわけではないが、将来的な移行を見据えて、試しに画像ビューアーのプロトタイプを作成した。

通常の非圧縮データに加え、JPEG2000 や JPEG-LS にも対応しているので、CR や大抵の CT （シリーズ）なら、ほぼほぼ描画できるはずだ。

詳細は『PHORLIX ベータテスト』をご覧ください。

以前に書いた記事で DICOM を取り扱うソフトは、データ構造として

Patient - Study - Series - Image(s)

になっていると書いたが、そうはなっていないものもある。

代表例は OsiriX の open source version で、少なくともデータベースの構造は

Alubum - Study - Series - Image(s)

という階層を採用している。

OsiriX と言っても商用版はもはやオープンソースではないので確かめてみようがないが、少なくとも Ver 5 あたりまでは、この構造になっている。

だから、オープンソース時代の OsiriX をベースに開発された Horos や HorliX も基本的には同じデータベース構造になっている。

上に掲げた図は、OsiriX 系の dicom viewer のデータベースのテーブル間の関係性をソースコードを基にまとめたものだ。
Album, Study, Series, Image が実際にデータベースとして使われている sqlite のテーブルに対応しており、Attribute がカラムに対応している。ただし、ソースコードをベースに機械的に図に起こしたものなので、現在では使われていないカラムも含まれている。例えば、Album の index はソースコード上では Int32 （符号付32ビット整数）で定義はされているが、実際には使われていない。

では、HorliX にスタディを一つだけ登録してみよう。

このとき、実際のデータベースの ZSTUDY テーブルは以下のようになっている。

ダイコムファイルを取り込んだ際などに患者 id を正しく設定してさえおけば、sqlite の patientid のカラムはその施設で使っている施設の患者 id と一致するはずだ。
patientuid は デフォルトの設定では'患者名-患者 id-患者birthday' になる。
この設定は、HorliX では menu -> HorliX -> 設定 -> データベース の以下のパネルで微調整はできる。

ただし、UID とは言っても多施設で使用した場合は、これは必ずしも Unique な ID にはならない。
施設 A にも 00003 さんはいるだろうし、施設 B にも 00003 さんはいる可能性があるからだ。
だから、多施設で使われることを前提にした電子カルテなどと連動させる場合には、この点には注意をする必要がある。

ところで、UI にも採用されている Album を階層の一番上に持ってきたのは、使いやすさを考慮してのことなのだろう。

だが、この構造を採用したことで、他の医療ソフトと連動させた時などに若干の影響は出ると思う。

通常であれば、単純には、トップの階層のテーブルにある患者の id 同士を照合させて欲しいデータをとってくればいいが、この構造では、いったん、一階層落ちて Study の patientid または patientuid で照合をさせる必要があるからだ。

猪股弘明
HorliX: 開発者
Horos: contributor, OsiriX(OpenSource Version): contributor

特にどれ（次世代 HorliX や DolphORCA など）に使うとは決めていないのだが、そろそろ画像周りも手をつけてみたい、ということで、指定したファイルを返却してくれる api を含むサーバープログラムを作成。

自分で言うのもなんですが、なかなか綺麗ですね。

ところで、カルテからダイコムなどの画像の類を自由に操作できるようにしたらいいのに、というような要望があったりするが、これはけっこう面倒。

最も簡単な構成は、患者データに画像データを従属させたり、カルテ自体にダイコムデータを持たせたりすることだが、ちょっと考えるとこの構成は冗長すぎて合理的でないというのがわかる。
カルテ自体は何度も書き換えられるが、このやり方だと原則その都度画像も保管されてしまう。
一般的に画像系のデータの方が「重い」ので、ストレージの有効活用という意味でこのやり方はまったく非効率的だ。

そこで、画像系のデータは PACS というサーバに別系統で保管しておきましょう、という話になるわけだが、長らく使われてきた DICOM 規格は、多施設で使われていることを前提にしていない。
現在は、どうなってるか詳しく調べていないが、基本的に

　Patient - Study - Series - Image(s)

という階層構造でデータを保管しておくことになっている。

一方、カルテ系はやや多施設を意識するようにはなってきているが、国民総背番号制みたいなのは導入されていないので、こちらは

　Facility（施設）- Patient - karte

という構造にせざるを得ない。
実際の医療事務処理がそうしているように、施設がまずあってそこに「患者を登録」するわけだ。
この処理が済んでからようやくカルテ記載ができるようになる。

ちょっと考えてみればわかるが、このとき登録された患者の以前の画像記録を他の施設から引っ張ってこようとすると、ここまでの枠組みでは原則「できない」。

ここら辺のデータ構造の差異に由来する両者のミスマッチを解消する方法の一つは、国民全員登録の PACS サーバを用意することだが、どんだけストレージ必要なんでしょう？

現状だととても無理ではないでしょうか。

猪股弘明

精神科医（精神保健指定医）

ここでも OpenDolphin の後継をどうするかあれこれ言っていたのだが、結局、DolphORCA というプロジェクトがそれに相当するものになりそう。

勤務医をやっていると電子カルテそのものを作成する必要性がないので、OpenOcean だとかなんだとか言って放置していたのだが、2022/10 頃から、OpenDolphin HTML/PDF Viewer をウェブサーバー化して、３層クラサバ構成にして、バックエンドサーバーをフリーで公開したら、コミュニティがいくらか活発化して、進行がいきなり加速した。

ちなみに比較的最近の Ver 1.5.1 では、カルテ閲覧画面は以下のようになっている。

まだまだ、作り込みが十分ではないが、基本機能（カルテ記載内容のデータベースへの読み出し・書き込みや ORCA などのソフトとの通信など）はかなり安定している。

ところで、DolphORCA では、3-tier client server system というアーキテクチャを採用しているが、この概略に関しては
『DolphORCA と三層クライアントサーバシステム』
で、コーディング時の留意点は
『DolphORCA』
で述べている。

Ver1.2 のバックエンドサーバーバイナリは
『DolphORCA Backend Server ダウンロードページ』
と
github: https://github.com/Hiroaki-Inomata/DolphORCA-back-binary
で配布している。

猪股弘明
精神科医（精神保健指定医）
OpenDolphin-2.7m, HorliX など開発

先日、標準型電子カルテの技術作業班に出席してきた。

まだ、手探りの状況だなと感じたが、これまでのまとめなどを『医療DXと標準型電子カルテ』に書き綴っていますので、ご興味のある方はご一読のほどを。

猪股弘明

精神科医：精神保健指定医

HorliX のメンテナンス・発展形態もろもろについて考えてみたが、

・OpenGL -> Metal の完全移行が起こった場合、アプリそのものが使えなくなる

・UI が Xib 形式でこれも賞味期限切れになる可能性が高い

・現状でも、他人の書いたコードを読むのが苦痛になってきた

などなどあって、今すぐというわけではないが、将来的な移行を見据えて、試しに画像ビューアーのプロトタイプを作成した。

通常の非圧縮データに加え、JPEG2000 や JPEG-LS にも対応しているので、CR や大抵の CT （シリーズ）なら、ほぼほぼ描画できるはずだ。

詳細は『PHORLIX ベータテスト』をご覧ください。

以前に書いた記事で DICOM を取り扱うソフトは、データ構造として

Patient - Study - Series - Image(s)

になっていると書いたが、そうはなっていないものもある。

代表例は OsiriX の open source version で、少なくともデータベースの構造は

Alubum - Study - Series - Image(s)

という階層を採用している。

OsiriX と言っても商用版はもはやオープンソースではないので確かめてみようがないが、少なくとも Ver 5 あたりまでは、この構造になっている。

だから、オープンソース時代の OsiriX をベースに開発された Horos や HorliX も基本的には同じデータベース構造になっている。

上に掲げた図は、OsiriX 系の dicom viewer のデータベースのテーブル間の関係性をソースコードを基にまとめたものだ。
Album, Study, Series, Image が実際にデータベースとして使われている sqlite のテーブルに対応しており、Attribute がカラムに対応している。ただし、ソースコードをベースに機械的に図に起こしたものなので、現在では使われていないカラムも含まれている。例えば、Album の index はソースコード上では Int32 （符号付32ビット整数）で定義はされているが、実際には使われていない。

では、HorliX にスタディを一つだけ登録してみよう。

このとき、実際のデータベースの ZSTUDY テーブルは以下のようになっている。

ダイコムファイルを取り込んだ際などに患者 id を正しく設定してさえおけば、sqlite の patientid のカラムはその施設で使っている施設の患者 id と一致するはずだ。
patientuid は デフォルトの設定では'患者名-患者 id-患者birthday' になる。
この設定は、HorliX では menu -> HorliX -> 設定 -> データベース の以下のパネルで微調整はできる。

ただし、UID とは言っても多施設で使用した場合は、これは必ずしも Unique な ID にはならない。
施設 A にも 00003 さんはいるだろうし、施設 B にも 00003 さんはいる可能性があるからだ。
だから、多施設で使われることを前提にした電子カルテなどと連動させる場合には、この点には注意をする必要がある。

ところで、UI にも採用されている Album を階層の一番上に持ってきたのは、使いやすさを考慮してのことなのだろう。

だが、この構造を採用したことで、他の医療ソフトと連動させた時などに若干の影響は出ると思う。

通常であれば、単純には、トップの階層のテーブルにある患者の id 同士を照合させて欲しいデータをとってくればいいが、この構造では、いったん、一階層落ちて Study の patientid または patientuid で照合をさせる必要があるからだ。

猪股弘明
HorliX: 開発者
Horos: contributor, OsiriX(OpenSource Version): contributor

特にどれ（次世代 HorliX や DolphORCA など）に使うとは決めていないのだが、そろそろ画像周りも手をつけてみたい、ということで、指定したファイルを返却してくれる api を含むサーバープログラムを作成。

自分で言うのもなんですが、なかなか綺麗ですね。

ところで、カルテからダイコムなどの画像の類を自由に操作できるようにしたらいいのに、というような要望があったりするが、これはけっこう面倒。

最も簡単な構成は、患者データに画像データを従属させたり、カルテ自体にダイコムデータを持たせたりすることだが、ちょっと考えるとこの構成は冗長すぎて合理的でないというのがわかる。
カルテ自体は何度も書き換えられるが、このやり方だと原則その都度画像も保管されてしまう。
一般的に画像系のデータの方が「重い」ので、ストレージの有効活用という意味でこのやり方はまったく非効率的だ。

そこで、画像系のデータは PACS というサーバに別系統で保管しておきましょう、という話になるわけだが、長らく使われてきた DICOM 規格は、多施設で使われていることを前提にしていない。
現在は、どうなってるか詳しく調べていないが、基本的に

　Patient - Study - Series - Image(s)

という階層構造でデータを保管しておくことになっている。

一方、カルテ系はやや多施設を意識するようにはなってきているが、国民総背番号制みたいなのは導入されていないので、こちらは

　Facility（施設）- Patient - karte

という構造にせざるを得ない。
実際の医療事務処理がそうしているように、施設がまずあってそこに「患者を登録」するわけだ。
この処理が済んでからようやくカルテ記載ができるようになる。

ちょっと考えてみればわかるが、このとき登録された患者の以前の画像記録を他の施設から引っ張ってこようとすると、ここまでの枠組みでは原則「できない」。

ここら辺のデータ構造の差異に由来する両者のミスマッチを解消する方法の一つは、国民全員登録の PACS サーバを用意することだが、どんだけストレージ必要なんでしょう？

現状だととても無理ではないでしょうか。

猪股弘明

精神科医（精神保健指定医）

ここでも OpenDolphin の後継をどうするかあれこれ言っていたのだが、結局、DolphORCA というプロジェクトがそれに相当するものになりそう。

勤務医をやっていると電子カルテそのものを作成する必要性がないので、OpenOcean だとかなんだとか言って放置していたのだが、2022/10 頃から、OpenDolphin HTML/PDF Viewer をウェブサーバー化して、３層クラサバ構成にして、バックエンドサーバーをフリーで公開したら、コミュニティがいくらか活発化して、進行がいきなり加速した。

ちなみに比較的最近の Ver 1.5.1 では、カルテ閲覧画面は以下のようになっている。

まだまだ、作り込みが十分ではないが、基本機能（カルテ記載内容のデータベースへの読み出し・書き込みや ORCA などのソフトとの通信など）はかなり安定している。

ところで、DolphORCA では、3-tier client server system というアーキテクチャを採用しているが、この概略に関しては
『DolphORCA と三層クライアントサーバシステム』
で、コーディング時の留意点は
『DolphORCA』
で述べている。

Ver1.2 のバックエンドサーバーバイナリは
『DolphORCA Backend Server ダウンロードページ』
と
github: https://github.com/Hiroaki-Inomata/DolphORCA-back-binary
で配布している。

猪股弘明
精神科医（精神保健指定医）
OpenDolphin-2.7m, HorliX など開発

コロナ後遺症の精神症状（特に６ヶ月程度で消失するもの）について、「正直、これ、大半は単なるコロナ発症をきっかけとした心因反応でしょう」という趣旨の記事を

『コロナ後遺症の精神症状について』（biophysical psychiatry +）

に書きましたので、ご興味ある方はご一読ください。
ごく簡単なものですが、臨床に従事している先生方からは概ね好意的に受けとめられているようです。

しかし、

（患者さんの）自己申告で診断書書いている先生もおられるようですが...

もし、そうなら、それは医学でもなんでもないと思う。


猪股弘明
医師：精神科（精神保健指定医）

日本医師会が主導して開発を進めている ORCA （オルカ）というレセコンソフトは、クラウド化を目指しているそうだが、もともと無床診療所向けにローカルで稼働することを想定して設計されていたため、必ずしもうまくはいってないようだ。
そのような背景もあるのか、「ORCA に関して調べてもらえないか？」みたいな依頼がぱらぱらとあった。

ソースコードを読んだり、データベースの構造を調べたりで、ORCA に関しては自分なりには大雑把に評価できたかなとは思うんだが、その延長で現行の ORCA の足りない点を補うようなコンセプチュアルなモデルをいくつかつくってみた。
上のは、現行 ORCA に「被せる」ようなタイプ。

他にも色々な考え方はあるだろうし、実際、既に市販されている製品もある。

さらに、ついででこれに載るような電子カルテ風の UI を作成したら、周囲からの評判は割り合いよかった。

以前に、OpenDolphin-2.7m ベースの OpenOcean というのもあったのだが、機能的には OpenDolphin-2.7m と大差はなく、なんやかんやで現在は配布もソースコードの公開もしていない。

「作り直す」とは言っていたので、これはちょうど良いタイミングだったかもしれない。

今後は、こちらの方を便宜的に OpenOcean と呼ぶことにする。

→結局、DolphORCA プロジェクトに統合されました。

猪股弘明　医師：精神科：精神保健指定医

HorliX, OpenDolphin-2.7m 開発者

HorliX と薬機法

HorliX （という Horos / OsiriX ベースの画像ビューア）に関連して横浜市から薬機法ガラミで問い合わせ（正式な行政指導の類ではなく単なる問い合わせ）があったので、軽く返答。そのときの経緯みたいなものを『心電図アプリと薬機法と HorliX』に書いておきました。

そこでも書いてますが、現行 HorliX で薬機法認証/承認をとるつもりは積極的にはないです。「積極的にはない」というのは、たまにエラい先生から「きちんと取ったらどうだ」と諭されることがあるから。

いやあ、でもあのクラスのソフトを認可取れる水準でメンテしていくのは大変ですよ、とてもとても。
（→ある程度、技術に明るい人からすると元になった horos に「手抜き」アルゴリズムが散見される。手抜きといっても実用上はほとんど問題ないですが。でも、認証/承認を取る気ならばこれらを丹念に一つ一つ潰していけなければならず、かなりのコストがかかる→結局、PHORLIX プロジェクトへ）

なお、薬機法を取っていないデバイス・プログラムは、その使用にはある程度の制限がかかるのは、たいていの医師なら認識していることなので、ここで詳しく述べない。

『HorliX とは？』でも書いてますが、

HorliX 自体は薬機法認証/承認は取っていませんので、医療機関内で使用する場合には医師の自己責任でお使いください。ただし、院内システムの情報転送用など直接診断に関わらない目的での使用に関しては特に問題はないそうです（厚労省確認済み）。

というのが現行法規下での基本的な考え方でしょう。

原則的には、医療情報を単に記録・閲覧するソフトは「プログラム医療機器」には該当しないのだ。
また、医師と歯科医師が主体的に行う臨床研究にあっては薬機法の対象から除外される場合も多い。

最近では知り合いの臨床医の先生に『COVID-19 による肺炎CT画像！＜HorliXにて表示＞』で紹介してもらいましたが、そのことを踏まえた表現になっているかと思います。

一方、臨床経験のない自治体薬事担当者やクリニックレベルのシステム構築程度の仕事しかしてない業者あたりだと、経験や知識不足は否めず、ここらへんのニュアンスはなかなか伝わらないかもしれませんね。

厚労省もその点を考慮してか「医療機器（プログラム）に関しては、自治体独断で判断をくださないように」という趣旨の通達を出している。

なお、HorliX のソースコードは

 github: https://github.com/Hiroaki-Inomata/HorliX

 gitlab: https://gitlab.com/Hiroaki-Inomata/HorliX

で、公開しています。 

猪股弘明　　　　　　　　　　　

精神科：精神保健指定医　　　　
HorliX, OpenDolphin-2.7m 開発者

ごくごく仲間内で出していた電子書籍に

という kindle 本があるんですが、昨年末の増補改訂時に２章ほど私も寄稿させてもらいました。

全体的なコンセプトとしては、これから現場（病院内・在宅）に出ることが期待されている薬剤師さん向けに、現場に出るにあたって知っておいて欲しい臨床的な知識を読み物形式でまとめてあります。
私は、貼付剤と精神科の臨床実地問題を担当。

OpenDolphin-2.7m

問い合わせが今でもちらほらあるので書いておくと、オープンソースの電子カルテ OpenDolphin 2.7(m) のインストール・デプロイ方法は

に解説してあります。
（最近の Java 環境だと『OpenDolphin-2.7(m) を Mac OSX にインストールする』、特に M1(arm) Mac マシンへのインストール＆デプロイは『OpenDolphin-2.7m を M1 Mac にインストールする』あたりも参考になると思います）

そこで出てくるMavenやNetbeansって何？という方は

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

をご参照ください。

これらをある程度読んだ上で質問などしてもらうと有り難いです。

なお、OpenDolphin-2.7m は、ソースコードが公開されていた LSC 開発時代の OpenDolphin-2.7.0b を直接 Fork したもので、これをベースに bugfix を施しいくつかの機能追加をしたバージョンです。

だからデータ構造などは 、本家と同一。これをさらに Fork したものが OpenOcean です。

小林慎治（当時、京都大。現在、国立保健医療科学院）という人が OpenOcean をどこかで「Fork の Fork の Fork」と紹介していたそうだが、上記の順番で Fork しているので、明らかに一つ多い。正確には「Fork の Fork」です 。
ソースコードを読んでいないか、読む能力がないのかはわからないが（なにしろ一面識もない）、最低限のファクトチェックはして欲しいものだ。
さらにうと、彼は私のリポジトリから本家の方へ修正依頼（PR）を送れといっていたのだが、仮に上の Fork 順が正しいとすると gihub の仕様上、PR は送れない。いっていることが実現不可能で矛盾している。こういう言動はやめてもらいたい。

※・・ところで、最近、小林慎治さんが所属している保健医療科学院というところから、「国家公務員法違反（守秘義務違反、信用失墜行為、政治的行為の制限違反）の疑いがあるので厳重注意した。不愉快な思いをさせてしまい、大変申し訳ありません」という主旨の謝罪のメールをいただきました。細かい経緯はよくわからないのですが、他のオープンソースのプロジェクトで行動規範を逸脱する言動があったとのことです。過去の SNS 上などでの表現にも不適切なものがあったということで、当方にもそれらの確認・照会がありました。明らかな事実誤認（上記の Fork 順や ライセンス変更に関するもの）などに関して軽く回答させていただきました。そういったいきさつの上でのメールです。

さらに、小林慎治の主張を何の検証もせずに無批判にSNSで拡散させようとしたオープンソース活動家？のような人（小山哲央。当時アーク情報システム所属）がいるのだが、このような行為もやめてほしいものだ。
特に Fork 順などはソースコードを比較すれば、比較的簡単に判明することなのに（『ソースコード嫁』参照）、それをせずにオープンソースやそのライセンスを云々するのはかなりナンセンスに見える。

また、フォーク元となった OpenDolphin-2.7.0b には oracle のサンプルコードや Junzo SATO 氏が作成したコードや funabashi 氏が作成したコードも含まれていたため、あらぬ誤解が生じないようこの点に配慮してソースコード「全体」を
GitHub https://github.com/Hiroaki-Inomata/OpenDolphin-2.7m 
GitLab https://gitlab.com/Hiroaki-Inomata/OpenDolphin-2-7m
に一般に公開している。
そのほか開発の経緯などは『OpenDolphin について』や『OpenDolphin と電子カルテの３要件とメドレー』に書いてあります。


最近では、商用開発元がライフサイエンスコンピューティング（LSC）からメドレーに移るということで、当方にもちらほら問い合わせがありました。
これは、移行に伴いクラウド版に強制移行になるのではないか？という懸念が生じ、その前にデータを外部に抽出しておきたいという意図が働いたためのようです。

カルテ記載内容などは、基本的にはリレーショナルデータベースに記録（永続化）してあります。だから、記録方法がある程度類推がつけば適当なプログラムを組むことで電子カルテを経由せずに内容物を外部に書き出すことはできます。

なのですが、関係者のお話では、ローカルで走るいわゆるオンプレミス版も開発は継続するとのことでした。
今回は問題になることはなかったようですが、電子カルテを用いる限り、この手の問題は必ずつきまとうものなので、何らかの形で準備はしておいた方がいいと思われます。
（『OpenDolphin と電子カルテの３要件とメドレー』や『OpenDolphin ソースコード解説』などもご覧ください）

なお、永続化の形式などについては『電子カルテ OpenDolphin 2.7 (系列) FAQ』に軽く解説してあります。
より詳しく知りたい方は『OpenDolphin コード解説 -FileBackUpSystem と電子カルテのデータ構造-』にデータベースレベルですが、どのようにカルテ記載内容が格納されているかを解説してあります。


自力でデータの移行ができないようでしたら、SNS などでお気軽に連絡をもらえればと思います。


今後の方向性などは、『医療「AI」ソフト』・『OpenOcean』などをご覧ください。
OpenDolphin 全般、特に GitHub がどのように使われてきたかは『OpenDolphin wiki 風解説』の特にこの項目を参考にしてください。

最近では、商用版もメンテ程度になってきたため、他電子カルテへの乗り換えを検討している商用ユーザーさんが増えているようです。
まあ、自力運用している施設は使っていくとは思いますが。
ここで頭を悩ますのはデータ移行・保管だと思います。
当方が提供しているデータ移行ツール（上記言及）は『Save the DolphinS』で案内してあります。

ただ、これは専らデータの移行を目的として開発したツールですので、閲覧には不向きです。
そこで、出力をブラウザで閲覧できる html 形式に対応させ独立したソフトとしました。
こちらは『OpenDolphin HTML Viewer』で案内してあります。

データ移行は必要ない、データの保管と閲覧だけできればよいという場合には、こちらの方が便利でしょう。
dolphin データベースに直接アクセスしてその情報を復号しているので、WildFly などのアプリケーションサーバーは不要です。 

なお、厚労省にも軽く問い合わせましたが、この程度までデータ抽出できていれば OK だそうです。
逆に途中経過版や修正履歴などが表示できないものは NG だそうです。
細かな基準に関しては現在検討中とのことでした。

JakartaEE 9.1, Java17 対応

OpenDolphin は、動作環境として長らく JavaEE をベースにしていたのだが、JavaEE が JaKartaEE へと進化したため、OpenDolphin 自体を JakartaEE に対応させました。

これに伴って

・Java17 対応

・画像処理周りの一部変更

・ウェブレイヤーの追加

などプロジェクトの構成自体も変更になっています。

『OpenDolphin Ver6』で軽く案内しています。

ORCA

OpenDolphin はレセコン ORCA（日医標準レセプトソフト） と連動して動くのだが、今までじっくりソースコードを読んだことはなかった。
なんとなく居心地が悪いので、最近、ちらちら読み始めました。

『ORCA』、『Inside ORCA』、『ORCA のソースコードを取得する』、『レセコンソフト ORCA を巡るあれこれ』、『ORCA Plus というレセコンユーティリティソフトをつくっていて気がついたんだが』

あたりをご参考に。

ORCA データベース構造の検討

ORCA の意義は誰しもが認めることだと思うが、用途の拡大とそれに伴う機能拡張に若干の無理が生じてきているようで、公式MLにいくつか投稿しました。
これやこれやこれなど参照。
質疑応答の結果、ORCA 運営側より

猪股先生

ご指摘ごもっともです。
仰るとおりで、ぐうの音も出ません。
フレームワークの採用も検討してまいります。

という回答がありましたので、フレームワークを用いた改修は検討課題の一つにはなったようです。

→なお、現在（2022/4）では、上記の問題を改善するためか WebORCA というサービスがリリースされています。

公式サイトの説明だけだとわかりにくいですが、MLの方で上野さんがユーザーからの疑問に応える形でかなり明確に開発方針を明らかにしています。

ORCA管理機構の上野です

>webORCAと言う名前を見ました
>日レセクラウド版ともちがうのでしょう

WebORCAは、私どもで次世代のORCAと位置づけており、
従来のクラウド版（ginbee）を独自に開発した、Webアプリのフレームワークに移植したものです。
画面は同じまま、安定性や動作速度で大幅に優れています。

>オンブレミスは廃止の方向ですか？

ginbee についてはWebORCAへの移行を進めておりますが
オンプレミス版は継続の方向です。
ただし、現状のオンプレミス版は、近い将来、WebORCAのオンプレミス版（ブラウザで利用できる
ORCAのWebサーバ）としてリリースしたいと考えています。

オンプレとクラウドのWebORCAスキームへの統一には、メンテナンスコストを削減するという点以外に、
大規模な災害や障害に強いハイブリッドな環境を提供するという目標があります。

ウェブフレームワークの採用は私（猪股）も提案していましたが、とうとう本格採用となったようです。

ただし、2022/6 現時点でもユーザーの評価はほとんどなく、まともなベンチマーク比較も誰も行っておらず、ユーザー・取り扱い業者などからの関心は極めて薄いようです。
私も、（WebORCA は）
・オープンソースではない
・基本設計が多施設対応になっていない
・一社が開発したフレームワーク（しかも非公開）を採用しており、信頼性に欠ける

 などの理由で現時点では特に強い興味を持ってはいません。

ORCA のデータ加工・２次利用に関して

MLの質問に答える形でいくつかレスしたんですが、少々わかりにくかったと思い『ORCA の日計表と関連テーブル・内部会計フローについて』に解説入れてまとめておきました。

ご参考までに。