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

 

クリックclose