【アンチORCA】レセコンを作ろう

>>929
ttp://nakatani.mine.nu/pukiwiki/
と言う事で。

ただし、一応私は先に設計やってるのと、
ちょっとバックアップ用の外付けHDD人に貸してるんで、しばらく放置ってことですが。

>>930
まあ、話は聞くから、落ち着いてから動作検証してもいいですけどね。

>で。今回は、先の反省から、ある程度動くまで公開しない
>つもりなんですけど。

んー、実はこれをするために設計と言う作業が必要なんですよ。
設計をしておけば、その部分部分がこうできていればいいと決めておいて、
この部分は仕様道理にできてますよと公開していって全体で一つのものにできると。

薬価計算、点数計算、レセプトの書き方などややこしい&変更が大きい部分もあるから、
>>1さんも向こうのスレのレセコンさんもそこは人力だの身を前提にしていたようですね。
なんとなく「FMPならすぐにでもできる」と言う人がいたと言う事の意味が解って来ました。

後、老婆心ながら、プログラム初心者は余りあれこれ無理に機能を付けるより、
シンプルながらもまず、先に必要なものは何かをしっかりと決め、
きちんと動くものを目指して、後で拡張して行った方がいい気がします。
ええ、老婆心ながらも、、、、、、orz

>932
鯖立て乙です。
骨格部分の設計は重要ですよねぇ。
特に、後からモジュールの追加・入れ替えを
考えるなら「継ぎ目」の部分が大変そうな気がします。

まあ、時間ができたらブロックダイアグラムかＵＭＬを
うぷしていただければ幸いです。

>>932
乙です。
だけど、wikiに何を書くか、良く分かってなかったり・・・。

設計図とまで、まとめた物はありませんが。sql文とか
PHPスクリプトにコメントで動作や仕様の概況は
書いてるつもりなんですけどね。

>>933
いわゆるモジュール形式を考えています。というか、
そのための仕様も決めているつもりなんですが、
それで概ね動くかどうか、まず自分で試したいっす。

自分の慣れていないツールで、レセソフトぐらいの中規模のソフトを
作るのは大変だと思うけれど。印刷やデータ管理、入出力のノウハウ
の蓄積があるから、プロは開発ができるんだと思うけれどね。いちい
ちテストをしながら、作るのは大変じゃない？

>>935
それが楽しいんじゃない？

ノウハウなら、徐々に蓄積されてますよ。
PHPは、画面はHTMLだから誰でも分かるでしょ？
スクリプトだって強力で融通が利くのに分かりやすい。なにより、
いちいちコンパイルしなくてもイイってのがイイねぇ。データベース
への接続も、今となってはほとんどPHPLIBにおまかせ。自分でフォー
マットを決めてファイルに書き込むなんて、面倒な事やりたくない。

（開発チームで共通して）よっぽど極めたツールがあるならともかく、
そうでないなら、作る物に合わせたツールを選ぶのも方法だと思う。
例えば住所録とあて名書きに(L)APPは使わない、とかそういうこと。

>>936
ノウハウというか、LAPP関係の情報はInternet上にゴロゴロしているからね。
FMPで作るより情報が多い。PHPのMLは見ているだろうけれど、PHPLIBでの
transactionは確立したものではなさそうだよ。
住所録と宛名書きを、どの端末からでも行いたいのなら、PostgreSQL+ODBC+
Accessにするかな？　印刷関係の自由度が高い方が楽だし。

>>876
すみません、生きていますがprivate使用のマックがダウソしてしまい、どうせならと新しいやつを買いに逝ったのですが、
安さに目がくらんでWinのマシーンを購入してしまいますた。それでそれに慣れるのにかかりっきりでしばらく２ｃｈをご無沙汰
してますたｗ
また古いマックを復活させたらアップしますね

今、
入力した診療行為のコードを、
分解して、
過去の入力と比較して、
セットコードと比較して、
新しい内容なら登録して、
入力の足りない所は警告したり、
追加の入力を催促したり、
・・・
っつー所を書いているのだが。

めんどくせー （●｀ε´●）

でも、ここが要なので、
がっちりやらねば。

>>938
大体、知的で器用な医師なら、Macより、中身をいじれるWinの方が好きに
なると思うよ。プログラミングやハードの楽しみが増えるしね。

>>938
データ周りを出来合いのソフトに任せたんだから、残るのは
UIを作ることと、内部の計算しかないでしょう。UIの使い勝
手は、自分がベストと思っていても、他人には不満が残るの
よね。診療報酬の計算は、今後２年間で大きく変わるだろう
から融通の利くようにしていないと、短命に終わるかも。

>>940
浅いな。B級種か
ttp://www3.coara.or.jp/~tomoyaz/higa9711.html#971107

>>940
残念ながら痴的で奇酔うでげす

コードからマスターを判別して必要な情報
（点数とか、薬の正式名称とか、診療行為名とか）を
検索する部分を、関数じゃなくてクラスとして作ってみた。
しかし、マスター毎に欲しい情報って微妙に違うから、
まとめるのって難しい（っつーかやっぱり面倒）。
とりあえず、名前と点数だけ引き出せる形にしてみましょうか。

それが出来ると、次は処方番号の登録（と呼び出し）が
作れるはず。そうすると、機能的には基本部分は
固まる事になる。

それと並行して（気分転換がてら）窓口会計の画面を
作ると・・・それらしくなるかも。
領収書は、その画面を印刷すればいいんじゃないかなぁ。

尚、明細書の集計となると、まだまだ先。
（だけど、集計さえ出来れば、PDFの作成はそれほど
時間が掛からないはず）
入力内容のチェックルーチンは、適宜追加の方針。
（つまり、適宜追加が出来るように作る・・・はず）

息抜きに、モジュラス11の関数をphpで作った。
とはいえ、以前にAppleScriptで書いているので、
それを移しただけだが。

ところで。wikiって、便利ですねぇ。

あげ

タマにはあげとこ。
レセとかあって、制作休止中でした。
実際の所は、
元のコードの分解
→セットコードの分解
→マスターからのデータの呼び出し
→区分、内容、点数の抽出
というところで、面倒さ故に詰まってました。
ここが鬼門かぁ。

なんで詰まっているかと言うと。
感覚的な分かりやすさ（と、ORCAと共通性を持たせるため）
薬の数量と処方日数の指定に、いずれも"*"を使おうと考えて
いたのだが。そうすると、正規表現１発で分離するのが難しい。

例えば、
セルベ*3 ガスタ*3 *14
セルベ*3 *14
セルベ *14　←"*"の前に空白があるので、処方日数
+23*14　←処方番号に処方日数を追加する時は、"*"の前に空白なしの方が分かりやすいでしょ？
上記は処方日数１４日

セルベ*3 ガスタ*3
セルベ*3　←"*"の前に空白が無いので、数量
セルベ
+23
上記は処方日数１日とする

処方日数を示す"*"の前には必ず半角空白を入れる事にして、
（つまり、"+23 *14"と入力させる、って事）
" *"で分離する方法も考えたけど、なぜかうまく切り分けてくれない。
（ereg("^(.*)( \*)?([0-9]*)$",$ic,$regs) ）

仕方ないので、方針変更。
処方日数は"/"で区切る事にしようかと考え始めた。
セルベ*3 ガスタ*3/14
+23/14
セルベ*3 ガスタ*3
これなら、正規表現一発で切り分けられるかな？

ちなみに。
>948みたいな事を書いていると、
「コマンドラインでしか使えない？」と思うかもしれないが。
GUIフロントエンドを追加する方法は考えてある。
処理の順番の関係から、JavaScriptが必要になるけど。

コードを入力する時、決まり通りに分類して
入力してくれるのなら、処理は単純なのだが。

「もしも処置と病名のコードを一緒に入力
しやがったら、どうする？」みたいな事まで
考慮しようとすると、頭が痛い。

あと、区分の自動認識の順番とか。ORCAの
ように".数字"みたいな入力をさせれば、
それを見るだけで良いけど。
診療行為コードから引っ張ってくる方が自然
だし、そうしたいけど、不正な入力への対処が
面倒だし・・・。

一旦、中間ファイルに置いて、
整理してからＤＢに書くというのは？

保守

>>951
中間ファイルを作る方が面倒だと思う。
マスターの読み込みの所でファイルを扱ってるけど、
エラー処理に結構気を使う。
ファイルの代わりに、ガンガン配列やら変数を新しく
作って使ってしまっているのが、なんとなーく美しく
無いなぁと思っている。

やってる事は、ＤＢに書き込む前の整理なんだけど。
中間ファイルに書くのと、変数をバカスカ使うのと、
どっちがいいんだろうね？　（その前に、とりあえず
早く動く物を作れ、と言われそうだが）

セットコードの分解は、１段階ならできたんだが。
セットコードの中にセットコードが入っているような
多重のネスティングまで処理しようとすると・・・
再帰関数でやるのか？いや、そうすりゃいいんだが、
データベースアクセスが必要で、そのためには
セッション変数に登録されている物が必要だったり、
渡さないといけない情報が大杉なんだよねぇ。
これが、スマートにする方法があれば良いのだが。

一度に点数計算までやってしまおうとするから大変なのかな・・・
引数によってデータベースアクセスする関数でもつくりますか

それとも、セットマスターの設計を考え直すかでしょうか

追加

むかーし、この手の再帰コードを作った時
「おまえのはスタックの使い方がエレガントじゃない」と
文句言われたのを思い出しちゃいました

作りはじめて三ヶ月。もう、レセプト印刷に取り掛かって・・・・・

>>957
２年後の改訂の時も、３か月後にレセが印刷できるように．．．

がんばってください。

私。キリンビールの店頭宣伝で、オリンピック応援セールをしていたので。
くじを引いたら、銀賞（ぼうし）が当たりました。

貴方も、いいことあるよ・・・

>>958
銀賞ですか。
おめでとうございます。

私はクジ運が悪いほうですね。

誤爆に(ry

ああ。暑いな。

確かに暑い。

すっかり書き込みが減っちゃいましたね。

なんだかんだ言ってもORCAを導入したほうが安心なのかな。

読んではいるんだけどね。
さあ、本業のレセやらないと・・・。

個人的にはこのスレのレセソフトにも期待しているんだけどね。

さあ、みんなの期待に答えて、がんばろう。

ふむ。
今の方針で、印刷機能など基本的な所の障害はないのだが・・・
最大の問題は、コードが奇麗に整理されていないことかな。

procedure test(array k);
var array g;
begin
switch k
case a:
include a.inc;
break;
case b:
include b.inc;
end.

みたいな書き方になってる。で、a.inc, b.incの中では、
k,gをグローバル変数みたいに使っちゃってる。
しかも、a.inc, b.incの中でも、同様の事しちゃってる。

これ、機能まとまり毎にファイルに分けているので、
一見良さそうだったけど・・・、
実は、ながーいソースコードを細切れにしているだけ
なんだよねぇ。

cとwin32APIだけで原始的に作りたい。データベースも使わず。
受け付けで入力（患者情報のみ）＞診察室に送信。
診察室でカルテ入力、やったことを１患者１ファイルに保存＞支払い金額を受け付けへ送信。
毎日CDRに来た患者のファイルを焼く。ハードディスクには全て保存。
月1たまったファイルを元に電子レセ作る。
非常に素人的ですが、これなら自分しか使えないけど、
すごく軽快なソフトになりそうな気がします。マイナーなので、医療行為の幅が狭いため、
点数の改定があっても使う部分だけ少し変えるだけでいいんじゃないかと考えてます。
これでは決定的にここがだめだというところを教えてください。

同姓同名の人がいます。これにどう対処するのか。紙カルテがないと難しい。
送信するほどいそがしいのなら、大金を払って業者にまかせたほうが良い。
この二点が問題ですね。

>>969
すごくいいと思う。でも、自分がデータベースソフトを作ろうとしている
ことに気がついていないのが残念だ。

回答ありがとうございます。
やっぱりいろいろ難しいですね。
支払基金が磁気レセプトのコンピュータによる事務的
点検を行って審査員用にレセを印刷してるソフトを開業医に公開すれば、支払基金
の仕事も減って、無駄がないように思います。どうせ最終チェックがそれなら
最初にそれでチェックすればいいのにと思うんですが。そうならないもんでしょうか？
あんまり理想的にコンピュータ化が進むと事務職が食べれなくなるのでだめなのかな？　　

>>審査員用にレセを印刷してるソフトを開業医に公開すれば

そうです。印刷のソフトの公開は、ほとんど費用はかからないはずです。
これが手に入れば、無料の自作レセコンソフトが多数出回るでしょう。

>>972,973
いやー、そういう物があったとしても、
窓口の負担金を計算するレジ機能は
無いと思われる。

>>974　窓口の負担金を計算するレジ機能は無いと思われる

レジ機能を作るのは極めてかんたんです・

>レジ機能を作るのは極めてかんたんです・
患者負担金を求めるのは難しいよ（上限額とか色々あって複雑）

>>976
患者負担金の一発で出来る関数ないんですか？それさえあればファイルメーカでも、アクセスでもいや、エクセルでも出来たりして。

976
その求める式や思考過程はどこにのっていますか？

＞詳しい人
というか実務ができるレセコンを作る上で最低限必要な資料を列挙してください。
これだけ読みあされば完全に理解できるというものを。とりあえず
保険医療システムを完全把握しないと無理なので。

まず保険の組み合わせを理解して、ORCAのソース
ORCS01.CBL　ORCS02.CBL 当たりを見るべし。

>>976　　これだけ読みあされば完全に理解できるというもの

見たことないな。開業して医師会に入っても、そんなものもらわなかった。
特に、公的補助に関する情報は、全くない。

だから、公的補助に関する部分を、自動化するのは、やめたが良い。
各自が計算して、所定の場所に書きこむのが良い。

4 5 6 7月か、　指折り数えて出来上がるの待ってます。