[orca-dev:00056] Re: 病名クラス

["中山裕雄" <hnaka@xxxxxxxxxxxxxxx>]

有家先生　orca-devの皆様　こんにちは

中山＠鳥取県です。

> レセプトチェックに関して
> 私の場合、チェックを必要とする場面の体験に欠けるので
> 今ひとつ、何をしたらよいのか見えにくいのですが
あれ？先生はレセプトには直接縁の無いお立場ですか？
私は開業医なのでチェックに関しては体験ありありです。

> dev-ML では、先生の言われた
>
>  1)「黄身」だけを切り出す方法
>  2) その料理の方法
>
> の二点について、種々の方法が、ある程度具体的に比較対照されれば
> ここを読まれたかたの inspiration を刺激するのではないかと考えます。
はいそうしたいのは山々なのですが、なんせＳＱＬというのはテーブル名
フィールド名がどんどん登場するので、その部分を架空のにしても
読んだ人はあまり面白くないかと−−。
むしろ実際のＯＲＣＡに実装することを想定して
診療データを入れて、結果はこうなりましたとやった方が
説得力があるので、いまはまだ比喩的な表現になってしまいます。

> データを dynamic に参照することには抵抗を感じますので、
> static に記録されたものを上記の方法で加工していくことになるでしょうか。
staticに、例えばcsvへ吐き出されたデータを加工するとどうしても
手間が増えます。電子カルテを使う立場からは診療が終了した直後にでも
チェックされ方が便利です。
ＤＢのデータをdynamicに”更新”することには細心の注意が必要ですが
”参照”ならdynamicでも問題ないと私は思っています。

> ともあれ
> ORCAを知るための最も有効かつ確実な方法は
> ------------
> ソースを読む
> ------------
> ことだと思います。実は私はまだ一度も読んでいません (..);
> この企画「ORCAのソースファイルを読もう」も、dev-ML の話題かなと思います。

ORCAのソースファイルは一部だけ読みましたが作業領域やパラメータが
非常に多く開発チームの様に人間の頭の中のメモリーに一度展開されている
人には問題なくても、私のような人間を遠ざけるバリヤの役割があるようです
のでちーと時間がかかりますよ。
COBOLそのものは単純な手続き型言語（もちろんオブジェクト指向に発展は
しているようですが。）ですが言語の問題よりＳＱＬデータベースに
入っているデータをどんなイベントで処理するのが良いかという
レセコンとしての設計が最終的には大きな議論になる部分ですね。

レセコンの構造や処理が電子カルテとの連携も考えたときに
どんなテーブルやフィールドが必要で、どんなキー設定を行うかを
気にするユーザーは少ないでしょうけど、実はＳＱＬデータベースでは
これが最も基本の出発点になります。（ＤＢスキーマ）
処理手続きの部分は必要に応じて付け足せば済みますが、
スキーマはいったん使い始めたら簡単には変えることができません。
にも関わらず種々の問題は結局はＤＢスキーマに戻ってきます。
自作でやっているうちは問題発生してスクラップアンドビルドが早い
サイクルで行えますが、ＯＲＣＡでこの部分がどうなるか気になるところです。

先生の提案の本論からそれてしまいましたね。
ソースに関しての議論も私は歓迎です。

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