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

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



KOBAYASHIさん こんにちは

>  手探りでいろいろ進めてきましたが,あまりに解決すべき事項が多く疲れてき
> ました。Rubyのスクリプトに準拠していろいろやってはきましたが,どうも挙動
> がつかめないというのがこの半年の取り組みです。

DBSaccessor.java Ver 0.1.1はテストして見ましたが
こちらでも同じ現象でした。
その後の攻略は時間が無くて取り組んでいません。
詰まるところCLAIMの様にちゃんと動作しているものに
リソースを振り分けて(といっても単に開業医の道楽ですが−−。)
いるというところです。

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

この点もおっしゃることは良くわかります。
私も基本的には軽量電子カルテであってもトランザクションログが残る仕組みが
実装できれば良いなと思います。一方、私は本当のFileMakerユーザーでは
ありませんが使う人が増えているのでFileMakerユーザーにつきあって
ORCAとの溝を埋めている立場にすぎません。データの改変や
うっかり消去に対する対策は不可能では無いにしても、ファイル(テーブル)単位
で定期的にデータを別のDBへ自動でバックアップする等それなりに
手間がかかると感じています。使う人は、アプリケーションを作成した人間が
想像できないようなことを平気で行いますので、基本部分よりそういう
安全対策にもっとも手間がかかるでしょうね。

(2)の方法もずっと関心は持っていますが
なにせOPASが姿を見せませんのでなんとも評価が−−−。

中山小児科内科医院
中山裕雄