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 開発者)

 

UKEファイル OverView

この前のオンラインレセプト請求で問題が発生した。

公費の受給者番号が確定せず、月遅れ処理にしていたのだが、その分がエラーになってしまうという。
どこかで誤操作をやっていることが疑われたが、できれば今月中に請求したい。

結局、テキストエディターで エラー分のUKEファイルをつくってしまった。社保の支払基金のサイトでフォーマットが公開されているのだが、記述が細かすぎてわかりにくい。ざっくりと解説しよう。

(全体構造)


IR,,,,,,,,(医療機関の情報),,,,,,

RE,1,,,,(患者さんの情報),,,,,,,,,,
HO,,,,,(保険情報),,,,,,,,

KO,,,,,(公費の情報),,,,, ←(公費を使う場合必要)

SY,,,,,,,(傷病名),,,,,,,,

SI,,,,,,,,,(診療行為),,,,,,,

CO,,,,,,,,,(コメント文),,,,,,

RE,2,,,,(患者さんの情報),,,,,,,,,,

(以下、繰り返し)

GO,(保険者への件数),(合計保険点数),99

である。

基本的にはORCAが吐き出すUKEファイルは、完成度が高いが、月遅れや公費などで基金のASPにひっかかる場合がある。

このような場合、ORCAでがちゃがちゃやるよりは、テキストエディターでUKEファイルを自作して請求・確定した方が早いと思う。

 

猪股弘明( PHAZOR 合同会社

精神科:精神保健指定医

 

なお、.uke ファイルを医療関係者が見やすくしたものが「レセ電ビューア」というやつです。
ORCA だと Mac 版がないようですね。

windows 版ですが

https://bitbucket.org/ayamashita_kojosen/openreceiptviewer/src/master/

github: https://github.com/akihiro-yamashita/OpenReceiptViewer

にオープンソースで公開されているものがあります。