パスワードを忘れた? アカウント作成
47933 story

医師1000名がレセプトオンライン請求義務化に対して国を提訴 138

ストーリー by soara
これはそもそも憲法問題なのか? 部門より

tarbz2 曰く、

毎日新聞によれば、 医療機関の診療報酬明細書(レセプト)のオンライン請求義務化が憲法に反するということで、 医師約1000名が国を21日にも提訴するとのことだ。 レセプトとは、医療機関が保険組合等の支払い機関に診療報酬を請求するための明細書のことだが、 現状では紙媒体でも可のところを、原則として2011年3月末までにオンライン請求に切り替えるよう医療機関に義務付けられている。 つまり、日本全国の医療機関において、レセプトをオンラインで送るためのシステムを導入しなければいけなくなるわけだが、 今回の訴訟はそのレセプトのオンラインシステムの初期投資が、営業の自由を侵害し、また高額の初期費用負担に耐えられないという主張のようだ。

レセプト・システムと言えば、随分と昔になるが一時期話題になった 日本医師会のORCAプロジェクトによる日医標準レセプトソフトが、 オープンソースに近い形態で無償公開されている。通常のメーカー製レセプトは数百万から一千万程度するようだが、 ORCAのほうはDebian上で動作し、Linux PCと知識があればコストをかけないで済む。 サポートをする事業社もかなり存在するようだ。 それでも今回のような訴訟に発展するということは、日医標準レセプトソフトに問題があって使えないものなのか? そもそも医者の怠慢なのだろうか?

全国保険医団体連合会のプレスリリースでは、60歳以上の開業医の 3割が開業医を止める、としている。しかし、アンケート結果の詳細(PDF)をみると、アンケート収集期間が 1年半と長期間である、回答数の中には一部の府県では 60歳以上のみ対象としてある、など偏りがあるのではないかと編集子は感じた。

参考までに厚生労働省のレセプトオンラインについてのリンクを貼っておく。

2009/01/17 11:49 追記 by soa: 「日本全国の診療所」と記載された部分を「日本全国の医療機関」と修正しました。Motohiko様ご指摘ありがとうございました。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 記事中の「診療所」は「病院・診療所」です。もしくは「医療機関」。ベッド数20以上が病院 [wikipedia.org]、それ未満乃至入院設備なしが診療所 [wikipedia.org]と使い分けられています。

    それはともかく、検索すると次の記事を見つけたのでリンクします。

    1. レセプトオンライン請求義務化問題を考える シリーズ1(愛知県保険医協会) [aichi-hkn.jp]
    2. レセプトオンライン請求義務化問題を考える シリーズ2(愛知県保険医協会) [aichi-hkn.jp]
    3. レセプトオンライン請求義務化問題を考える シリーズ3(愛知県保険医協会) [aichi-hkn.jp]
    4. レセプトオンライン請求義務化問題を考える シリーズ4(愛知県保険医協会) [aichi-hkn.jp]
    5. レセプトオンライン請求義務化問題を考える シリーズ5(最終回)(愛知県保険医協会) [aichi-hkn.jp]

    日本医師会がこの件についてのアンケートを行っています (概要 [med.or.jp]、報告書[PDF] [med.or.jp])。昨年春 (2008/3/17∼4/30) の時点でも実施している医療機関が2.0%、またこれを機に廃業を考えているのが8%以上あることが判ります。

    またアンケートを読み進めると、開設者 (院長?) の年齢が高いほど廃業を考えている割合が高いことが判ります (P9)。医療分野では「定年」が存在せず、高齢の医師が勤める医療機関が地方医療では大きな比重を支えていることが知られています。そもそも厚労省も高齢医師も戦力としてみているわけですし。こういう人たちがごそっと抜けるのは、単純な「競争」としては間違っていないのかもしれませんが、医療という生活に必要なものに当てはめていい考え方かは疑問があります。タレコミ人は『そもそも医者の怠慢なのだろうか?』(アレたま時点でこのような煽り文句があった) としていますが、単純な費用負担すらままならない状況ですので (一応初診料に「電子化加算」の3点が加わるそうです。ちなみに1点=10円)、「怠慢」呼ばわりはひどいんじゃないかなぁと。

    なお日本医師会、日本歯科医師会、日本薬剤師会が合同でオンライン請求の完全撤廃を求める共同声明 [med.or.jp]を行っています (2008/10/22)。

    • このまま行くと、レセコン導入してダイアルアップで請求を上げる形になりそうですね。
      # レセコンのリース料+カルテ入力のオペレータの人件費が問題。患者数の少ないとこは廃業ですね

      レセコン業者と役人が結託してるんじゃね~の?と、根拠のない邪推が湧くのを停められない…
      --
      notice : I ignore an anonymous contribution.
      親コメント
  • by patagon (1453) on 2009年01月17日 12時26分 (#1492921) 日記

    中学生の頃から通ってるかかりつけの開業の内科医がいます。そこは数年前からDoctor' Desk II [cmsnet.ne.jp]というのを利用しているのですが、それを導入して以来、診てもらってるというよりパソコンの片手間にこっちも見てるいうよで嫌~な感じです。カルテ入力するためにキーボードとディスプレイ置いてある机に向かっている時間が長い。昔は患者の方を診てくれていたのに。手書きのカルテの頃が良かったな。ちょっと不安になります。

    • 一番電子カルテ化が進んでないのは精神科、という噂を聞きました。「患者さんの話を聞くのが仕事」だからとか。
      電子カルテは他科の情報が瞬時に見えたり、過去の検査項目も自動的にグラフ化できたりとすごく便利ですが、それをふまえた上で患者さんの話を聞けるお医者さんになりたいなー、と思う次第です。

      --
      以上
      親コメント
  • 開業医を止めるなら (スコア:5, すばらしい洞察)

    by Technobose (6861) on 2009年01月17日 13時03分 (#1492949) 日記
    医師不足で窮地に陥っている公立病院で勤務医になってください、というのはありなんでしょうかね。
    医師の育成には、国の予算と患者の協力が結構かかっているとおもうんだけど・・・・。

    私の住んでいる地方都市の場合、ここ十年くらいで新規の開業医が随分と増えました。
    市立病院とか市内の大手総合病院で評判の良かった先生たちが、市内の各地で医院を開いてまして、
    医院と薬局が連なった病院通りみたいなところもできてます。
    で、そういう新規開業医のところは、ほぼ電子カルテが導入されているので、レセプトがオンライン化
    されても影響ないというか、手間が省けてメリットがあるでしょう。
    が、昔からの医院はレセプト・コンピュータも導入されておらず、医療事務のおばちゃん
    姉さんが手書きで書類作成という感じです。
    そういう昔からの先生にしてみたら、事務処理を機械化してもメリットが感じられないでしょう。電子カ
    ルテも導入すれば医院全体の事務作業量は減らせますが、オーダー入力は現状では医師しかできないこと
    になっているはずなので、医師からすれば負担が増えるようにみえます。
    おそらく医院単体でレセプト処理を機械化させるのでは反発が大きいだけです。
    千葉県の亀田総合病院みたいに地域の診療所を [kameda.com]
    ネットワーク化していくなどの取り組みを進めないと、医師にとってメリットは無いです。
    例えば地域の医師会で電子カルテを共同運用して、医療事務も共同化するなどの対策が考えられると思います。

    しかし、厚生労働省のやることを見ていて感じるのは、現場の実状とか考えない独善的な態度ですね。
    現場の医院などにとってもメリットを感じられる案を示して、地道に説得するというところが感じられません。
    「俺たちが決めたんだから、つべこべ言わず従え」という感じで、不合理なことも押し通すし、そういう
    ところを改善してほしいものです。
  • by metrics (25038) on 2009年01月17日 12時30分 (#1492924)
    費用だけが強調されているようですが、便益もあるでしょう。 これを出発点として一国民としては治療費の全体像を把握して ほしいものです。例えば、レセプトを一つの病歴エピソード ごとに繋げて、総額どれだけ費用がかかっているのか、ということ すら現状できません。このような総額を把握することにより 総額で請求されている金額を分析することが可能となり異常な 請求がみつけやすくなり、コスト削減につながると思います。 また、全体を把握されている、という意識自体が異常請求を 抑える効果をもつかもしれません。病院勤めの医者に比べて 街のお医者さまたちの所得が高いことは周知の事実です。この 高い所得のどれほどが正当なものかをチェックできる システムが今まで導入されて来なかったということ自体 おかしなことだと思います。 あとIT関連としては一つの医療機関での検査結果を簡単に他の医療機関 から取り寄せることができる仕組みを作ってもらいたいものです。 囲い込みを減らせるし、重複検査も減らせます。
    • 医師をやってます。ORCA日レセも少し理解しているつもりです。
      スラド読者の皆様としては病院待合室で待ち時間を過ごしつつ
      「ああこの時間も舞台裏ではオンライン請求に合わせる仕事のために
      事務員と医師が時間をかけてるんだな」と想像してみてください。
      患者側には待ち時間延長などデメリットが多いのです。
       医療費を統計把握してムダを調べれば国全体の医療費が
      減らせるだろうというのは厚労省の幻想です。
      日本はすでに医療費貧乏国ですから削る余地もありません。
      医療費対GDP比率は米国15% フランス11%ドイツ11%、日本8%.
      http://www2.ttcn.ne.jp/honkawa/1900.html
      日本の医療費を減らそうと無理するからまともに出産もできない惨状。
      イギリスのサッチャーが90年代に大失敗した医療費削減を
      (米国もまねて失敗)日本の厚労省が10年遅れでまねている現状です。
      http://www.pluto.dti.ne.jp/~mor97512/KOKU28.HTML
      誤解1。
      ORCA日レセという低維持費のレセプトソフトでそのまま
      オンライン請求ができるというのは誤解。ORCA日レセに加えて
      新たな回線契約や設備投資が必要です。
      誤解2。
      医師がIT得意ならオンライン請求が簡単だろうというのも誤解。
      IT得意か不得意かはオンライン請求ではささいな問題で、
      ほぼ「病名変更の事務手続き+導入費用+事務員教育期間」が問題です。
      もちろん舞台裏での「病名分類や操作に慣れるまでの半年程度」は
      患者側の待ち時間も確実に増えます。
      患者、医師、医療事務の3者が泣いて、厚労省が
      少し喜ぶのが診療報酬オンライン請求であろうと思います。
      (大規模な情報流出があったら国民大激怒、厚労省知らん顔)
      親コメント
    • by doctor_d (4392) on 2009年01月17日 12時57分 (#1492943) ホームページ

       保険者(国保、健保)の側からすれば、紙レセプトでは目視による確認しか行えず、請求内容を
      100%確認する事は出来ません。電子化されていれば、ある程度電算処理で誤請求や、明らかにおかしい請求を
      弾く事が出来ます。国や健保の立場からすれば、増大する医療費を何とか削減したので、レセプトの電子化を
      どんな名目でも推進したいのです。我々サラリーマンも健康保険料が増えていますので、大枠としては
      推進するべきと思います。

       実は医療機関側にもメリットがあり、誤請求が直ぐに判明するため当月に訂正したレセプトを提出すれば費用の
      請求が遅れる事がありません。(従来は入金が遅くなり、資金繰りの面で苦しくなります)

       なお、レセプトデータの提出は今回の「オンライン請求」以外にもFDやMOを使った提出が従来より可能です。
      また、小規模の診療所では紙レセプトでの提出が数年間許容されている筈(期限はあるが)です。

      親コメント
      • by doctor_d (4392) on 2009年01月17日 13時02分 (#1492948) ホームページ

         厚生労働省のwebに導入スケジュール [mhlw.go.jp]載っていました。(pdf)

         反対理由を未だ見ていないのですが、オンライン化100%を狙うよりも、小規模診療所にはORCAの様なレセコンを導入して頂きFDやMOでのデータ送付を認めるのが
        現実的な気がします。目標はレセプトデータの電子化なので。

        親コメント
      • by Anonymous Coward on 2009年01月17日 17時47分 (#1493103)
        上の人はそう考えたんだけどね。
        >保険者(国保、健保)の側からすれば、紙レセプトでは目視による確認しか行えず、請求内容を 100%確認する事は出来ません。
        現在、保険者(国保、健保)では、電子化されたレセプトも、画面に出してから、紙に打ち出して点検しています。だってやりにくいんだもの。もちろん、電子化している病院でも、紙に打ち出して点検します。モニターだけで、台数が足りません。
        >電子化されていれば、ある程度電算処理で誤請求や、明らかにおかしい請求を弾く事が出来ます。
        もちろん点検ツールが双方にあって、いわゆる明らかにおかしい請求ははじけますが、問題は、この基準がころころ変わることです。つまり、セキュリティーツールと同じく永遠に改定し続けなければいけません
        >我々サラリーマンも健康保険料が増えていますので、大枠としては 推進するべきと思います。
        ORCAプロジェクトによる日医標準レセプトソフトそのままでははっきりいって使いにくいため、事務員をもう一人雇う必要があります(年間200万以上)。電子カルテと連動にするとこちらは有償なので 導入時に2百万から5百万、毎年保守に百万、さらに2年に1回の改定時に百万かかります。
        これだけのお金があれば、新しい検査機器が数台買えます。正確な書類を書くためだけに、これだけの費用を掛けろというのは、まさに上の方の役人考えそのものだと思います。
        なお、病院は既に電子化は導入されており、今回問題なのは、医者一人、看護師1-2人といったところが中心の小規模診療所です。ここの平均年収は2千万ー2千五百万程度(もちろんもっと低い人がいます)です。開院時に借金をしている人は、そこから、年間5百万ー1千万程度借金を返します。人によっては死活問題だと思います。
        >レセプトデータの提出は今回の「オンライン請求」以外にもFDやMOを使った提出が従来より可能です。
        これが、認められなくなるのです。

        でも、私が一番心配なのは、ほんとに医療情報は、守られるの?ということです。 専門家のいない数人の従業員しかいない小規模診療所のコンピューターがインターネットとつながった状態では、(役所は、一応つなげるなといっているが、実際、OSのセキュリティーアップもしないといけないし無理)ウイルスの十匹やバックドアの3つくらい作られても、しようが無いのでは?
        親コメント
    • by Anonymous Coward on 2009年01月17日 15時26分 (#1493034)

      > 異常な請求がみつけやすくなり

      異常な請求って、どういうもののことをさすのでしょうか。
      確かに架空請求をする医者はいて時々捕まっていますが、
      過剰請求とされるもののほとんどは、健康保険給付基準の解釈の違いとか、
      正当な治療が厳密には保険適応でないとか、
      請求する側が病名をつけ忘れたとか、
      あるいは保険者側が支出を抑えるために機械的に一部を払い渋ったとか、そんなのばっかりです。

      # 過剰請求を0にする方法はあって、例えば「医療機関側が患者の納得のもとに10割請求→患者が自己負担分の7割を自分で保険者から直接給付してもらう」なら、間違いなく今の定義での過剰請求は0になります。医療費の総額と患者の負担は増えますけど。

      > 一つの医療機関での検査結果を簡単に他の医療機関から取り寄せることができる仕組みを作ってもらいたいものです。囲い込みを減らせるし、重複検査も減らせます。

      検査結果その他が簡単に送れて気軽に患者を紹介できるのは確かに便利ですから
      その仕組みの価値は高いとは思いますが、
      「囲い込み」とか「重複検査」とは何を指すのでしょう?
      医療費の無駄を省くためなら、紹介状も持たずにドクターショッピングを繰り返す行為は強く非難されるべきです。というか、仮にカルテ内容も送信可能だったとして、前医が年余にわたって記載したカルテや膨大な検査結果だけを読んで全体像を把握するのは不可能に近いです。サマリを作ってもらったり電話で確認するなら、紹介状をもらって転院なりセカンドオピニオン受診なりするという今のシステムと変わりません。

      日本は先進国で最も医療費が少ない国の一つなので、少々システムをいじったところで医療費がこれ以上下がることはないでしょう。医療の荒廃が加速するだけ。

      親コメント
  • by Anonymous Coward on 2009年01月17日 20時20分 (#1493175)
    医療現場や関連業に勤務してるわけではないのですけど、ORCAにちょっと興味があってインストールをしたことがあります。
    まずびっくりしたのが、COBOLで構築されているという点。プロジェクトが開始された頃を考えると、JavaやPHPなどの言語を選択しなかった理由はなんだろう…。
    ORCA以外の給官鳥などといったプロジェクトではJavaが使われています(でもあまり聞き慣れないDBを内包しているようです)。
    これはORCAもいずれJavaに?と勘ぐったりもしますがその予兆はさっぱり。

    それとUIの古さ。自分は古いオフコンのインタフェイスを知らないのですが、人に言わせればORCAのインタフェイスは古き良き時代のコンピュータで作られたインタフェイスをそのまま踏襲したようなモノだとかで。
    被保険者情報を入力する画面で情報を追加して保存→再編集の流れがよくわからずマニュアルとにらめっこしてようやく、という感じです。
    あとはDB設計かな。500カラムもあるテーブルがあった時は目を疑ったw ***1、***2、***3・・・・と延々続いてるのを見たときはもうちょっと何とか成らなかったのかとも。

    オープンソースのプロダクトとはいえ、こうした敷居の高い環境だと本当に詳しい人でないと導入〜運用ができないだろうし、サポートをする業者がメンテ費用で商売をしてる様子をみると、言い方は悪いのですが最初からこういう魂胆だったのではないかと思ったりします。
    • 一番の問題は診療報酬改定とそれに伴うデータベースの変更だったりします。
      ひどいときには計算式まで改定されるので、計算プログラムまでデータとして
      持ったりする羽目になります。Javaなど近代的な言語なら、クラスとして
      設計するのでしょうけど、COBOLだと***1、***2、***3とならざる
      得ないのでしょうね。

      未知のデータをマスタとして格納しなければならない時点で、
      制度をなんとかしろよと思うけどね。コンピューター化なんて
      全く意識していない制度体系で、それをそのままコンピュータ化
      しようとするから無理が起こるんだけどねぇ。
      親コメント
    • 人に言わせればORCAのインタフェイスは古き良き時代のコンピュータで作られた
      インタフェイスをそのまま踏襲したようなモノだとかで。

      案外それに違和感を抱かない開発者集団ってのを数年前に見ました。ってか一緒に仕事しました。
      Webだなんだっていう話が出ているシステムなのに、クライアントアプリの設計書には

      -1画面に表示は19行。
      -20行目は「次へ」の移動ボタンとする。

      なんてのがもうサンプル画面付きで書いてある。当然その辺はF10とかF9とかのショートカット
      でも操作可能で...って、「なんで広い画面に19行しか出さないのですか!?」とかみついた覚えが。

      あと、500カラムのテーブルなんてまだザラにありますよ。
      先日も、Oracle10gのカラム数上限が1000であることを調べるハメになる設計で仕事しました。

      「設計変更でカラム追加するとエラーがでるんですけど」

      1000超えていたという。

      親コメント
  • 介護保険導入時、そちらの方も多少強引にIT化を進めたわけです。
    介護度を決める前段階に、お年寄りを訪問し話したり現状見たりして、カルテのような資料を作るのですが、
    とある自治体はそこに携帯型端末を強引に導入しました。

    が、実際に携帯端末を訪問時に持っていくケアマネージャは皆無で、現場には用紙を持っていき手書きで記入、
    帰宅してから携帯型端末に一生懸命入れるという状態に。
    端末を操作しながらだと「冷たい感じがする」「真面目に見てないんじゃないか」と言うお年寄りが多かったこと、
    というのがあるみたいですね。

    電子カルテを強制すると結局同じような状態になるところが出てくるんじゃないかな。
    それを怠慢と見なすかどうか、というのはありますが。
  • by Anonymous Coward on 2009年01月17日 12時14分 (#1492909)

    >ORCAのほうはDebian上で動作し、Linux PCと知識があればコストをかけないで済む。
    誰がメンテするの??特に開業医の場合は。
    オープンソースでなんでも解決、みたいな書き方はやめろよ。

    • by Anonymous Coward on 2009年01月17日 23時08分 (#1493256)

      なぜこれがマイナスモデでフレームの元なんだろう?
      ORCAの導入を検討して調べてみたら、すぐにORCAを選択するメリットは殆ど無いって思うんですが。

      ORCAはシステム設計時にメンバーがヲタクな趣味に走りすぎた時点で失敗している。
      とにかくレセコンには大量の帳票がつきものなのに、そのプリンタ一つ繋ぐにもドライバ捜しから四苦八苦するようなものを出してこられても迷惑なだけです。
      結局、導入して運用するには本業そっちのけでPCをいじくり回すか、普通のレセコン並以上のお金を払って業者を雇うか‥‥既に医師会会費を経由して大金が流れているのにね。

      少なくともコスト的なメリットを期待するなら、ORCAを選ぶ理由はありません。

      親コメント
    • >誰がメンテするの??特に開業医の場合は。

      自分ができないことは人にやってもらう。
      サービスに対して対価を払う。
      当然のことだと思います。

      ただ外に出すときにはセキュリティ面で
      いろいろと考慮すべきことが多いのは分かります。

      --
      屍体メモ [windy.cx]
      親コメント
  • 結構保守的な分野だし。

    サーバ側のコストはかかるでしょうけど、クライアント側のコストは医療機器に比べれば
    安いので、費用うんぬんは同情出来ないです。

    紙のレセプトの処理は、いまだにアルバイトによる人力だったりする。それを置いといて、
    電子化されたとたんにセキュリティうんぬん言われてもなぁ。

    システム全体の善し悪しはソフトによるわけだけど、そのあたりはやってみないとわからない。
    最初は紙と併用するところが多いだろうから、余計な仕事が増えるだけといういつもの
    パターンか。
    • >紙のレセプトの処理は、いまだにアルバイトによる人力だったりする。

      困ったことに、現状でレセプトをPCで処理している(最終的に紙に出す)現場でも
      レセプト点検すらまともに出来ない。 酷いのはソフトウェアで警告表示されてるのにチェックしない連中も居ますからなぁ……。

      ところで紙媒体を使いたくないのであれば
      媒体(CDROMとか)で送れるわけですから何も問題ありません。
      そういう点でも疑問の声があることも忘れてもらいたくないです。

      --
      ==========================================
      投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
      親コメント
  • by Anonymous Coward on 2009年01月17日 15時20分 (#1493030)
    医者なら頭イイんだからLinuxくらい簡単だろ?
    ってのは
    Linux使いこなせるくらい頭イイんだから医師国家試験くらい簡単だろ?
    ってくらい無茶
  • by Anonymous Coward on 2009年01月17日 18時16分 (#1493112)

    医師の書くカルテは、個人にまつわる診療記録になります。
    なので、本来はこのカルテが電子化されればレセプト処理は簡略化されます。
    むしろそこから電子化しないと、いきなりレセプトの入力というのは難解なのです。

    しかしながら、紙からコンピュータへの移行において問題となるのは
    昔から変わらずUIの問題に帰着されます。
    費用というのは、移行をすればいくらかかかるものなので仕方がありません。
    コンピュータから紙に移行するのもコストはかかるのです。

    さて、UIというものは使い手のスキルに依存します。
    紙に文字を書くというスキルは、日本人ならだいたい誰でもできますし(障害を持っていなければ)
    医師となるには、カルテを「書く」スキルも当然持っているものです。

    突然カルテを「入力」するスキルを求められたのです。
    しかも、お世辞にも入力方式が整っている訳では無いのです。
    バイクの運転と、バスの運転くらいの違いがあるソフトを使いこなさなくてはいけないのです。
    なのに今、無免許で60歳を超えている。

    ちょっと厳しくないですかね?
    歩いて行く手段も残しておいてあげるべきだと思います。

    # 一定の基準を満たす人でないと駄目だと思いますけどね。
    # 開業医で、一定期間以上の実績があるとか。

  • このORCAって、なぜ利用環境をDebianに限定してしまったのでしょうか?
    レセプト・システムってソフトウェアとしてみると単なるデータベースアプリケーションなので、
    開発環境さえうまく選べば複数のプラットフォームで動作させるのに大きな障壁は無いような気がします。
    ORCAプロジェクトのサイトを見たりしましたが、Q&Aなどを見てもわかりませんでした。
    それともプロジェクトの開始時期の頃にはまだ難しい事情があったんでしょうか?

    # 訴訟については単に費用負担の問題だと思うので、憲法問題とか精神的苦痛とかを
    # 理由にして争うのは負ける原因を作っているようにしか見えません。

    • 3年ほど前ですが直接医療情報のえらい人に聞く機会がありました。
      言われたのが、
      1.Fedora(当時はCore)は回転が速くてサポート出来ない、一番安定していてサポートが長いのがちょうどDebianだった
      2.へたにWindowsで動かせたりして専門家による管理じゃない(つまり、かじった程度の院長がインストールして使った)状態で、ウィルス→レセプト漏れるとかするとプロジェクト自体が困る
      3.オープンソースだから、使いたい人は好きな状況で使ってくれる(実際Fedoraで動作させている人もいる)
      とのことでした。2が大きいんですかね。

      僕も実際にWindows(Cygwin)で動作させることを試してみましたが、実際にヘッダファイルを書き換えたり大変ではあるものの可能ではありました。
      とはいえDebianで使うときの楽さとはかなりの差でしたので、実際にこんなことしながら使ってる人は居ないだろうなー、と思う次第です。

      --
      以上
      親コメント
      • by Anonymous Coward on 2009年01月18日 12時26分 (#1493423)

        その1~3は単なる後付の言い訳ですよ。Linuxでも当時からサポートを重視するならRHELがあった訳ですし。
        そもそも2と3は矛盾した話だし、2の専門家サポートを必須とする囲い込みは普及させないための障壁として用意したといっている様なもんです。
        つーかですね、主治医意見書の方はWindowsで動いている訳ですが、レセデータより個人情報満載のっちはダダ漏れでOKなのか? とか、辻褄が合わなすぎるんですわ。
        実際には関係者がその時その時で趣味で選定をやっているとしか思えない訳です。

        親コメント
        • by Anonymous Coward on 2009年01月18日 14時37分 (#1493448)

          >Linuxでも当時からサポートを重視するならRHELがあった訳ですし。

          ORCAの公開された2002年2月当時、ギリギリRHELはまだありませんでしたよ。

          RedHat Linuxにも今から考えると長期間のサポートが提供されていましたが
          ドットコムバブル後の赤字企業の先行きを過剰に厳しく見積もったのでしょう。

          親コメント
  • 誰のサイフで? (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2009年01月18日 12時16分 (#1493418)
    基本的にレセプトのオンライン化(=電子化)には大賛成。
    今時紙ベースのレセプトを人海戦術でべらべらべらーってどんだけ前時代的なのかと。

    それで廃業する医院がある程度出るのは仕方がないのも判る(でももっと対策しろ!)

    でもこのプロジェクトの主眼は支払基金側の事務作業効率化(=人件費削減)だろ?
    それを何で他人(=医療機関)のサイフでやろうとすんのかってことなわけで。

    ただでさえ経営環境の厳しい昨今、殆ど自分にメリットのないことを多額のコスト払ってやんなさいって強制されてもねぇ。

    むしろ支払基金側が「このたびこういうシステムを開発しました。設置や回線費用、維持メンテはこちらでやりますのでどうか置いて頂けないでしょうか?」って頭下げてやってくるのが筋だろうよ。
    • by hiwork (35961) on 2009年01月18日 15時32分 (#1493459)
      医療機関がインフラ整備を押し付けられていることに同意。また、専用回線も「個人情報保護」の立場からは必須で、インターネット上にトンネル掘ってVPN作ったっていつかは解読されて大量の個人情報流出を招く恐れが高いことも問題です。厚生労働省や保健機構側で負担すべきことを上から頭ごなしに医療機関に押し付けている。電算化の期限までに、保健機構と政府がインフラ整備すべきでしょう。「医療崩壊」の一因になることは一目瞭然。
      親コメント
typodupeerror

最初のバージョンは常に打ち捨てられる。

読み込み中...