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 を巡るあれこれ

ORCA のメーリス

そういえば、昔、ORCAのML(メーリングリスト)にいくつか投稿したことがあったわ。

Re: ORCA と OsiriX の接続について

Re: ORCA と OsiriX の接続について その2

Re: ORCA と OsiriX の接続について その3

Re: ORCA と OsiriX の接続について その4

この時点では、その後、DICOM を本格的に触るようになるとは思ってもいなかった。

内容的に情報が古くなっている点もあるが、


一般のDICOMファイルの情報をすべて読み出し・管理するのは難しいが、特定のDICOMだけを操作するのは、それほど面倒ではないはずだ

というのは、今読み返しても「なるほどな」とは思う。

 

 

猪股弘明(精神科, HorliX 開発者)