ORCA, OpenDolphin, OsiriX は未だに話題になりますね

ORCA メーリングリストの話

ORCA ユーザーのメーリングリストで、大阪の八木高秀先生の

ORCAと連動した電子カルテをご使用中の方がおられましたら、
ご使用感を教えていただけないでしょうか。

という投稿をきっかけに医療用ソフトの議論が突如として活発化。
多少「あれ?」と思うようなところもありますが、現場で使っている先生方はこの手の問題に熱心ですね。熱意が伝わってきます。

OpenDolphin の話題も出ていたので、私もイントロ的な概要と現在注意しておいた方がいい点などをコメントしてきました。

カルテ記載内容のデータベースの永続化方法に関しては、ほぼほぼ解析できてまして、クライアントからではなく、別のツールを使って抽出もすることもできました。
『Save the DolphinS -OpenDolphin データ抽出ツール・プロジェクト-』
https://allnightnihon2b.net/blog-jp/?p=816
で案内しています。

データベースに直接アクセスして復号しているため、最終確定版だけでなく途中経過版も抜いてこれます。カルテに貼り付けた図版も別に画像ファイルとして抽出できます。

なんで、こんなものを作成したかといえば、opendolphin から他電子カルテへの乗り換えを考えた場合、途中経過版も含めて電子化して取り出さないと実質的にはデータ移行しにくいと考えたからです。

「データ移行」に関しては関心が高かったようですね。

また、ORCA に関しても気になっている点を挙げさせてもらいました。

ただ、現行の OpenDolphin を大幅に機能強化させるようなことは考えてません。以前は、手が空いたら着手しようかと考えていたのですが、某筋から「ORCA の技術的側面に関して調べてみては?」と提案されて、調べたところ、設計の古さが目についたからです。
この件に関しては以前このMLにも投稿しましたね。
例えば
『ptid のデータベース上での定義について』
https://ml.orca.med.or.jp/orca-users/msg14679.html
などの一連のやり取りをご覧ください。

今すぐということはないでしょうが、ORCA は将来的には再設計される可能性もあるわけで、その状況では、ORCA「だけ」に依存する上物には手を出しにくいかなあと思っています。

などなど。


ただ、取り扱いが微妙な問題も孕んでいるので、あくまであっさりとした解説です。
「取り扱いが微妙な問題」というのは(ここで細かい話をしてもしょうがないと思うので)

横から見た OpenDolphin-2.7m

保健医療科学院 小林慎治が国家公務員法違反疑いで厳重注意を受けた件について

HorliX -wikipedia 風解説- にまつわるあれこれ

あたりをご参照ください。


OpenDolphin マスタマイズの実際

ところで、この手の話をするときに、クライアントに実装した「いわゆる」ファイルバックアップシステムをまず取り上げ、次にデータ抽出ツールの説明をするようにしている。
そちらの方がわかりやすいと思いそうしているのだが、実は、実際の開発順序は違う

時系列的には、まず、データ抽出ツールを作成し、その次に(ツールの副産物として)ファイルバックアップシステムに関するコードをクライアントに付け加えたというのが本当のところです。

これはコード上にも反映されている。
OpenDolphin のカルテインスペクタの文字情報だけを取り出すのなら、gettext という関数を使えばすむのだが、これだとカルテ上の右半分(処方や処置などを記載する欄)もベタな文字情報のままになってしまう。

過去の直近の処方内容をチェックする程度であれば、(処置区分なしの)文字情報だけでもかまわないと思うのだが、もう一歩踏み込んで処置内容毎に区分して処理したいというような場合、これだと後処理が必要になってしまう。

ところがデータベース上では各処置(スタンプ)には、それがどの区分に属するかの情報も含まれている。
これを活用しない手はないと思い、区分を読み取って条件分岐させてから、文字情報を抜く、というロジックにした。

最終的なアウトプットは単純に文字情報だけを抜いたときと変わらないのだが、ちょっと凝った統計処理をしたいというような場合、コードの修正がしやすいと思いそのような実装にした。

ファイルバックアップシステムに関わるコードは100行にも満たないが、コードを書くときはこんな風にあれこれ考えながらやるものなんですよ。

ちょっとマニアックな話ですが、何かの参考になればと思い補足説明してみました。

HorliX に関しても言及

OsiriX や Horos の話題も出ていたので、年末の隙間時間をついて HorliX に関しても投稿してきました。
https://ml.orca.med.or.jp/orca-users/msg14953.html

当たり前のことを言ってもしょうがないので、気持ち開発寄りに振ってます。

例えば、Horos でROIを使うとき、使う毎にその描画色がくるくると変化すると
思いますが、その元になったコードは私が送ってます。
いわゆる ROI-color-rotation-UI というやつです。
このときの改変のやり取りは今でも残ってますね。
https://github.com/horosproject/horos/issues/342

ここら辺までは、Horos と協調していたんですが、当時(2018年)課題に
なっていた 64bit 対応がもたもたしていたことや彼らが若干「やりすぎ」て
しまうところが気になって、結局、独立してしまいました。

「やりすぎ」というのは、具体的には、ROI-color-rotation-UI でいうと
彼らは記録時のファーマットまで改変してしまってます。
ROI を XXXX.roi のようなファイルを書き出したとき、色情報まで入れ込んじゃっているので、互換性が崩れちゃってるんですよ。
上であげた github issues 上での議論を見てもらえればわかると思いますが、
元々は「ROI の描画色が単色だと視認性が良くないので、マルチカラーを扱える
ようにしたい」というかなりシンプルで(おそらく有用な)ユーザーさんからの
指摘から始まってます。
私も色が変わるのは便利だなと思いますが、記録するほどのことでもないと
思い、Horosの改変は取り込みませんでした。
「やりすぎ」と感じるのは、こういった点です。

ここら辺、そんなに説明したことはないので、興味を持ってもらえたらいいなあという気持ちがちょっとはいっています。

 

猪股弘明(ご連絡は twitter の DM や facebook の友達申請などでお願いします)
OpenDolphin-2.7m 開発者

 

 

オープンソースの世界

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

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

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

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

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

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

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

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

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

例を一つ。

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 に関しては私たちのグループはそれなりに評価されているようだ。
これまでにもファイルバックアップシステムやデータ移行ツールは、それなりに評価されていたと思うが、正直、それほど派手な機能ではなく、熱心なユーザーさんや独自カスタマイズを入れている医療機関(のSEさん)に支持されていた程度だと思う。

最近の OpenDolphin HTML/PDF ViewerWebDolphORCA は、まだプロトタイプ程度の完成度なのだが、それよりも評判がいい。

これに関して某氏が「この関係者のみでソースコードを共有する仕組みは、一般のオープンソース開発方式よりうまくいっているようで」(『OpenDolphin と商業GPL』)と面白いことを言っていた。

確かに、医療用ソフトでは上で述べたようにオープンソースプロジェクトが成立する条件(汎用的なプロダクツで透明性への要求が高い云々)は満たしにくい。
ただ、解決しなければいけない課題は、(OSのカーネルを構築するのに比べれば)遥かに限定的・具体的なため、その分野に明るいエンジニアが数名集まれば解決までの道程はかなり短縮できる。

この開発方式はなんていうんでしょうね?

たぶん、専門的な正式名称はありそうだが、個人的には「コンソーシアム開発方式」とでも呼びたい。(私が以前に在籍していた ERATO のプロジェクトはこれに近い方法論を取っていたし、拠点にしていたのは「つくば研究コンソーシアム(現つくばイノベーションベース)」というところであったから)

 

猪股弘明
医師(精神科医:精神保健指定医)
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 開発者

 

ORCA Plus というレセコンユーティリティソフトをつくっていて気がついたんだが

ORCA Plus

知り合いの病院(といっても100床程度だが)の理事長さんから

「レセコンとして ORCA を使っているが,

 会計で計算しにくい指標がある

 「閉塞」がおこりやすい

なんとかならないか?」

というような相談があって、手が空いたときにデータ構造などについて調べていた。
会計フローまではまた十分調べられていないのだが(一部、『ORCA の日計表と関連テーブル・内部フローなどについて』あたりで手をつけました)、とりあえず手をつけやすいのは外来の待合患者さんあたりのリストを一覧表示させることだ。
ORCA との通信というと CLAIM や(最近では)ORCA API が使われているが、けっこうな頻度で「閉塞」を起こすようだ。だからこの機能を無条件で信用するわけにもいかない。結局、ORCA のデータベースの該当テーブルを直接参照することにした。
適当なプログラムから非同期通信でデータベースに直接問い合わせれば、ORCA 自体には悪さは(まず)しないだろうという読みだ。

で、ブラウザ閲覧タイプのプログラム(これを ORCA Plus と呼んでいた)をささっと書いて、しっかり動いた。
ORCA も同時に動かしても、ORCA 本体にはなんの悪影響も出ていない。
患者受付するとこちらの画面にも反映される(今のところブラウザを「更新」してデータベース読みにいく仕様)。


で、このときに気になった点があったので、述べてみたい。

なお、患者さんはすべてデモ用の架空(ダミー)患者さんです。

ORCA データベースのカラム定義の不整合性

どういうことかというと、ORCA では同一と思われるカラムが、テーブルによって定義が違うってこと。
これは具体的に示すとわかりやすいと思う。

ptid はおそらくその施設での患者IDを示すカラム(列)の名前。なお、似たようなカラムに ptnum というのもあるが、こちらは表示用文字列
上図からわかるように

tbl_ptinfptid では bigint
(bigint は postgreSQL では8バイト整数)
tbl_uketukeptidnumeric(10,0)
(簡単にいえば 10 桁の整数

となっていて、数値の型が違う。

また型が違うせいなのか、tbl_uketuke の方で ptid が外部参照されていない(できない?)。
しかも、tbl_uketuke(受付情報入っていると思われるテーブル)では ptid が NULL でもかまわない。つまり、患者IDが入っていなくてもとりあえずは記録できる仕様になっている。

ORCA「閉塞」の一因?

ところで ORCA がけっこうの頻度で「閉塞」してしまうのは、これが一因だったのかもしれませんね。
要するに患者IDも付与されていない「外来」患者情報を他の機器に送信しようとしても、ORCA 自体がパニくってしまうか、受信する側の機器が送られてきたデータを受けつけないみたいな状態になっていたかもしれないってことです。

対応と課題

改善案もなくはないと思いますが、急に変更しようとすると無理が出るので、現在でも稼働中のシステムゆえ、とりあえずはこういった状況を把握した上で使っていくしかないかなあとは思います。

 

ORCA 管理機構側の対応

結局、ここらへんのことは ORCA の ML(メーリングリスト)にも投稿させてもらった。これとかこれとかこれ

この件に関しては ORCA 管理機構の上野さんに丁寧に対応していただいた。

上野さんの話によると、不整合が生じた原因は、以前のOpenCOBOL(今の GnuCOBOL)やミドルウエアが固定小数点「しか」扱えなかったことに由来するということらしい。その後、主だったテーブルでは integer 型に修正したのだが、マンパワーの関係で今でもいくつかのテーブルでは旧来の定義がそのまま使われているとのことでした。

ORCA 管理機構側からも

フレームワークの採用も検討してまいります

と一つの改善案を示していただきました。

 

ORCA は素晴らしいプロジェクトですが、時代に合わなくなってきた側面もあるかとは思います。無条件に肯定するのでも全否定するのでもなく、地道に評価して次世代の望ましい設計を模索いけばいいのではと思います。

 

 

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

 

Inside ORCA -オンライン資格確認対応?のためのビルド-

ちょっと思うところあって、ORCA という日本医師会御謹製のレセプトコンピュータソフトをソースからビルドした。
ORCA 単体のビルドはそれほど難しくない(ただし、サーバーのビルドはそれなりに難易度高いが、今回はそこまではやらない)。
ソースは一時期行方不明になっていたのだが、現在は公式サイトのここからダンロードできる。
Ubuntu マシンに落としてきたあと、解凍。「端末」よりautomake ツールなどを適当に使って Makefile というものをつくる。あとは

 make && sudo make install 

とすれば、所定の位置に各種ビルド産物をインストールしてくれる。

こうなっていれば成功。

 

「ちょっと思うところがあって」と書いたのは、いわゆる「オンライン資格確認等システム」を導入する場合、レセコンの改修が必要になるから。

「オンライン資格確認」については厚労省のページをご覧ください。

図は https://www.mhlw.go.jp/content/10200000/000575785.pdf より。一部改変。

無理にしなくてもいいようなのだが、ORCA プロジェクトがグダグダになって対応不能になった場合、代変案を持っていた方がいいと考えた。

早速、新しいデータベース orca2 というのをつくらせる。

 

患者さんのデータにオンライン資格で必要になってくる「枝番」を入れ込んでおく必要があるので、こっち(orca2 の方)につくっておけば、もし、ORCA が未対応に終わっても、こちらを稼働させればいいわけっすね。諸々調整は必要っすが。

なお、「枝番」やカードリーダーの細かな仕様はまだ調べてない。実際にやるとなるとオルカクライアントの改変も必要なので、やるかどうかは今のところ決めてない。

 

 

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

(参考)
ORCA(一般的な解説)
ORCA のソースコードを取得する
レセコンソフト ORCA を巡るあれこれ