[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[orca-dev:00492] ORCA関連ソフトウェアの開発に際して



現在,ORCA関連のソフトウェアを作成するとして情報をORCAから得られる手段は,
以下の3つのパターンです。
1)CLAIMインターフェース経由
2)HAKAMA(dbs)経由
3)JDBC-ODBC経由
 それぞれにメリットとデメリットがあります。以下私なりの解釈と評価です。
1)CLAIMインターフェース経由
メリット:
 すでに実績があり,公開されたソフトウェアもある。
デメリット:
 規定された運用を前提としているため,そこから離れた手順を反映させること
が困難。
 手順については以下のURLに示してあります。
http://www.medxml.net/claim21/commitment/manage.html
 これを見ると,orca-usersで流れていました,受付で処方箋が入力されること
を規定していませんし,入力された情報については「当日会計点数情報」として
電子カルテ側に送られても,処方箋の内容を送るように規定していません。以下
の点数金額モジュールをみても実施日時と請求点数,請求金額が電子カルテ側に
伝えられるだけです。
http://www.medxml.net/claim21/dtd.html
 また,入院会計の手順は一切規定していません。MML自体,煩雑なコーディン
グを要しますので,情報量が冗長すぎるように感じますのは,私の趣味の問題か
もしれません。
2)HAKAMA(dbs)経由
メリット:
 ORCA側のデータベースすべてにアクセスすることができる。
デメリット:
 orca-dev:00398からなる本MLの記事以外にあまりに資料が乏しいこと。たとえ
ば,dbsにアクセスするとExec:から始まる数字が返ってくるのですが,この数字
が何を意味するのか資料がないのでわからないなど。患者IDから患者情報をを取
得できるdbd,など公開されればまだ違うのでしょうけれども...どうにかなりま
せんか?
 手探りでいろいろ進めてきましたが,あまりに解決すべき事項が多く疲れてき
ました。Rubyのスクリプトに準拠していろいろやってはきましたが,どうも挙動
がつかめないというのがこの半年の取り組みです。
3)JDBC-ODBC接続
メリット:
 最も簡単。汎用のライブラリを使用できるためプログラムも作りやすく応用範
囲が広い。
デメリット:
 ORCAのミドルウェアを経由しないのでデータベース不整合を起こす危険性があ
る。読み込みはできても書き込みに関しては危険。

 ORCAに準拠した「軽量電子カルテ」は私も興味があります。2号用紙を電子化
することは人間の手間だけかかってコンピュータで得られることはそう多くあり
ません。しかし,紹介状や薬歴,病歴の管理,サマリーの管理,検査データの管
理は非常に有用です。電子カルテ側にデータベースを持つにしても管理をするの
は結構大変です。Filemakerはいいソフトですが,データのトランザクションジャー
ナルを残さないので,いつ誰がデータの更新を残したか。データの改変がいつ起
こって,不正なデータの変更に関しては変更前にデータを戻す。こういう機能が
ないと業務として使うには危険と私は考えます。今のFilemakerではレコードを
全部消すような事故は起こりえますが,それを元に戻すことはできません。
 できれば,ORCA側でデータの管理をするようにすれば結局は電子カルテ自体の
挙動も楽になると思って2)の方法を模索しています。orca-usersではCLAIMで
のアクセスについてちょっと言葉が過ぎましたことお許しください。

-- 
KOBAYASHI, Shinji <skoba@xxxxxxxxxxxxxxxxxxxxxxx>