【 ORCA 】日医標準レセプトソフト

......Xcodeって名前は出ないね。

Java版clientは２回ボタンを間違って押すと落ちます。αにもなっていない．．．

県医師会のお偉い方と最近名誉な事に会食した
まあ、大学からの長い友人と言えるが、いまでは田舎のヤブ医者と
県医師会＠長だ、選挙話しが多かったが
　雑談の末、オルカの話しになった、
　ORCAって素晴らしいソフトが出来ている完成していると確信していたよ
マジにだよ、彼良く知っているので表情で本気かどうかわかるよ
　我々末端の医師とは全然考えが違うな、
　一寸皮肉と　先生の病院では　お使いですかって聞いたら
　いずれは使います　でした、
　私は上手く行かないと嘆いたら、驚いた事に
　業者を入れなくては　とogoと同じ御返事でした、
　ガーカリ

>>954
そういう風に上から教育されているんだろうが、その先生は２００床
以下の病院か診療所の管理者なのかねぇ？

>954
>955

最近も、学内で話題になった際に、ORCAを使えるという先生は
1. 業者任せでのセットアップとメンテナンスが前提
2. 入力はセットメニュー以外は自分でしないクラス
3. 現執行部寄りの先生
でした。１でやるなら、ORCA以外を使っても、コスト変わらないか
高くつくぐらいなので、医師会費は無駄な投資に終わってると
判断すべきだと思うのだが、どうも認識が異なるようなのは確かだ。

>954さんところの先生は、どの先生を支援しているのかなぁと、
興味深々。

>>956
開業医になるまで、ORCAなんて名前も知らなかったし、興味も
なかったですね。勤務医さん達も興味あるのかしら？　one server
with UPS and RAIDなら使ってみようかなと思うことがあります
が、どうも開発が流動的になり始めているから、少し待ちかな。
Ver 3がどういう形になるか、それが知りたい。

>>954
業者を入れるのは賛成だがな（大藁）。
問題は、業者の価格が適正かだな。

業者はHDDを複製すれば良いわけで機械的に作れるのだよ。
従いハードプラスアルファだな。

お偉方には、業者のボッタクリの温床になっているとでもいうしか
ないのかな。

>サーバサイドJavaは比較的新しい概念。帯域の細さを補うためにクライ
だといっても既存アプリの代替で作られたものではないと思うが。
それにクライアントで動かすにせよ、サーバから最初はダウンロードする
という要素ははかったのか？そう考えないとアイデンティティを整理
できんのだが？

>バージョンに依存しないソフトウェアなど存在しない
これは少し違うな。
サードベンダーの馬の骨ソフトに依存するような商用アプリは
存在しない。
まともな商用アプリならば依存性のあるもの全てインストーラで
自動管理している。
他人のソフトのバージョンに依存するようなアプリは素人製品だよ。
また、自分自信のバージョンアップであれば上位互換機能は常識だな。

>957
one server with UPS and RAIDに、バックアップデバイスぐらいは
つけた方がいいと思いますよ。今ならテープドライブも安いですし。

学内＝医療情報部内、、だったりします。（藁
あまりの出来の悪さのために、評価を止めましたけどね。

ORCA導入で宣伝されている某大学さんところは、
何年も踏み台サイトになっているままなので、迷惑なんですけどね。
導入時に見直しもされなかったみたい。
そういえば、ORCA推進している医師会もだわな。
最近の個人情報流出Newsネタにならないことを願うばかり。
（なった方が、改善されるからいいという逆説的な話もあるが）

>>960
ORCAを評価している大学の医療情報部があるというだけでも、面白い
話ですね。

> ORCA導入で宣伝されている某大学さんところは、何年も踏み台サ
> イトになっているままなので、迷惑なんですけどね。
> 導入時に見直しもされなかったみたい。

ふーん、大学で導入しているところがあるんですか？　医療短大み
たいなところかな？　私なら外向けのserverは、FreeBSDにするなぁ。
Fire Wallの中はLinuxでいいと思うけれど。

マスターの更新の時だけつなげば大丈夫と、portをそのままにして
いたり、securityのupdateを行っていなかったりというサイトはある
でしょうね。

Ver 3が出れば本物だろうな。でなければ、単なる日医の浪費。

>961
> ふーん、大学で導入しているところがあるんですか？　医療短大み
> たいなところかな？
http://www.jma-receipt.jp/example/us_kyoto_01.html
http://ordb.org/lookup/?host=202.243.220.14
まだsendmail 8.8.8、、信じられない。

>>963
サポート事業者の方が信じられないがね。
三流大学のための三流システムってことになるじゃない。
使っているとこっちまで三流と思われるかな。

942です。Visual C++ でレセコンソフトを作る事を開始したのは
C++の勉強をしたいからなのです。

６年前から　Visual Basic で作ったレセコンソフトを
使っています。
データベースは使っていません。６年前のＣＰは
ハードディスクやメモリーが小さかったので
１日分のデータを１本の文章にして、ファイルにしてます。　

帳票以外のカスタマイズについて、日医からガイドラインみたいなのってありましたっけ?
オープンソースはいいんだけど、カスタマイズするのにいきなりソース嫁、じゃあ工数かかり杉なんですが。。

>>966
カスタマイズするためのオープンソースじゃあないに一票。
あれだ、不具合あってもソース出してるから許せってコトだと思う。
Linuxでバイナリ配布だけってーのは逃げ道が無いからねぇ・・。

2.2.1までには、＜運用に支障を与える不具合＞ がある。
４月１日か４月２日までには2.2.2をリリースする目標だ。通告したぞ。
http://www.orca.med.or.jp/community/ml/ml-archive/orca-announce/msg00225.html

>968
2/20 2.1.0
2/25 2.1.1
3/25 2.2.0
3/25 2.2.1
4/1 2.2.2

ふ〜ん、すごいねぇ。テストしないで配布しているのが、ありありと判るなぁ。

>>969
月末になると、versionが上がる、サザエさん一家の夏休みの宿題みたいな
もんだ。一般ユーザーからの指摘で動いているんだろうな。ちゃんとした、
テスト用のシステムを作ればいいと思うのだが．．．

>>968
悲惨の一語だな。ORCAのご本尊であるMONTSUQIをいじり過ぎて、
収集がつかなくなっているようだね。診療報酬の改定の時期に
いっしょに書き換えようという横着をするからだよ。
Gnomeのさかなアプレットも呆れて今日はひっくり返っている。

＜運用に支障を与える不具合＞って、具体的には何なのでしょう。

ねえ。「レセコンを作ろう」ってスレはないの？

レセコン作るとき、レセプト印刷が最もむずかしい。

レセコンを作るスレを作るとしたら、
ビジネスsoft板かプログラム板だと
思うのだけれど、どっちも落ちてね？

>>974
マジに、csvファイルで保険請求するようになれば、レセの自作なんて、
敷居が下がると思わないか？　それこそ、Accessでも、FMPでも、VC++
でも好きなツールで作ればいい。

保険請求のcsvファイルの先頭の部分をちらっと見たことがあるけど。
情報を書き込む順番が、厳格に決められてたみたいでした。
初診・再診・指導料などの、書き込む位置、は変更がないとして・・・・。
薬剤料・一部負担金などの、突如出現しては消えていくやつは
どこに書くのか？？？？。
そのつど、厚生労働省が　csvファイル　の書式を
教えてくれれば、できそうだな。。

>>977
CSVファイルの仕様なら
http://www.ssk.or.jp/rezept/index.html
に書いてありますよ

>>974
トライ＆エラーで書式作れば、できちゃいますよ
うちはエクセルのワークシートで作って印刷している.
控えは全部PDF化してＣＤに保存しているので、何ヶ月
前のレセが返戻されてきても対応可能

自作レセコンだと、件数の少ないパターンのレセまで
完全自動で出来なくても使い物にはなる。
90%自動で出来れば、あとの10%はプログラム作るより
手書きの方が楽
レセ電算でフロッピー提出しようとするとこの部分のプログラム
も作らないといけないのでかなりしんどいのでは？

ふうむ。
この手のシステムは、アプリそのものより、データベース
の構築が大変という気がする。
もちろん、小規模で割り切ればデータベースはいらないかも
しれないね。

こないだ作ったemailの管理ソフトはデータをベタテキストで
保存した。だから５０００件以下が実用水準とみている。

レセではどれくらいのデータが必要なのかねえ。

だいたい小規模な医院では、レセコンや電子カルテにデータベースなんていう
概念は不要と思う　点数料金計算機能＝レセコン付きワープロで十分

こんなことをいうと、医○情○学会では袋だたきに会うだろうな

レセコンにデータベースなんていう概念が必要になるのは、複数の診療科を
持つ病院以上なのでは

それとも個人医院でも、各項目ごと集計してコンビニ並に経営分析や在庫
管理している先生もいるのだろうか？

テスト

>>980
ある意味で正しいが、せっかく、おまけのDB engineがあるのに利用しないって
ことはないだろう。既にbussiness softwareのほとんどが、DB engine + Front
endでできていることを考えれば、そちらの方が開発効率がいい。

うちでも、支払基金は電子媒体によるレセプトの受付をやっている。問題は
国保だよ。国保連が、受け付けるようになれば、自作のソフトでもＯＫだろ。

>>978
cvsファイルの書き方？　テキストファイルで開いて、文字列で書き込んで、
コンマで区切ればいい。初歩の初歩じゃない？

>>979
確かに、今のレセソフトはオーバースペックなんだよ。
うちは診療所だから、開心術も、移植もやらない。でもレセのDB
には、その項目もあるんだよ。また、18,000種類の承認薬剤も使
うことはない。院内処方でも200種類以下だ。在庫管理、経理シス
テムといっしょにするには、今のレセは逆に不都合なんだがね。

>>985
興味深いね。
それならば、DBを持たずにただのベタファイルにデータ保存し
毎回検索かけたほうが良いね。
確かに１８０００種類の承認薬剤のマスタは便利だが、常時スタンバイ
ではなく、この中から良く使うものだけをベタファイルにピックアップ
するスタイルが相性良さそうだね。極論すると、日本語入力の辞書に
薬剤を入れておいてヨミで検索できるようにするなんて面白いね。

csvファイルで保険請求する自作ソフトを作るとき　問題になるのは、2点
１、基本になる厚生省コードが、むちゃくちゃ
　　（同じ物が2つあったり廃止されたものが残っていたり、番号が同じなのに　文字の方が変わっていたり）
２、本来決めるべき役人どもが、待ったか判っていなくて　親小泉の　F社が　決めたことが
標準になっしまうので、大手レセコン業者の寄り合いに　お金払って　参加しないと
だめ。
　　　結局、紙に印刷するほうが　自作には　有利です。

>987

でも、その寄り合いってあれだよね。一応上位７社会合が主のあれだよね？
（上位２社で６５％で抜きんでいるから、他はあまり権限無いようだけど）
違ったら、ごめん。

>ある意味で正しいが、せっかく、おまけのDB engineがあるのに利用しないって
>ことはないだろう。既にbussiness softwareのほとんどが、DB engine + Front

開発者のスキルとスタンスの問題もあるんではないか。
あるからといって、無理して使う事もあるまい。
片手間で処理したくて、間違うと泥沼に陥るかもしれない新技術に
抵抗を感じるのも事実。
それに、第三者の作ったエンジン使って被害はうけたいないよ。それが
ただでついてくるもの、つまりノーサポートだったらなおさらだね。
使い込んでいて信頼があれば使うべきだがね。

別のレセコンを作る話をここで続けるのもなんなので。
こんなスレ、立ててみました。

【アンチORCA】レセコンを作ろう
http://society.2ch.net/test/read.cgi/hosp/1080822441/l50

植松先生が医師会長就任。
これで今のORCAプロジェクトの方針見直しは確定かな？

DB engine を使って小さなプログラムを書いて、
さらのＰＣでテストを行ったら、うごかなかった。
DB engine を使わないと、うごきます。

どこ、間違ったんだろ。

>>992
何というDB?

> 　会長選挙の争点にもなった日医総研（日医のシンクタンク）の
> あり方については、「日医の政策を決定し、それを進めるのは執
> 行部の責任だ」として、その役割を関係資料の分析や調査などに
> 特化していく考えを強調した。
ORCAも終わったな。

次のスレを作る？

>>995
前執行部と共に葬るかぁ。

じゃあ．．．

青柳氏と共に．．．

お疲れ様、ORCA．．．

バイなら。

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。