JP3832707B2 - レセプト点検方法および装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、保険者によるレセプト点検に用いられるレセプト点検システムに関するものである。
【０００２】
【従来の技術】
医療機関が発行する診療報酬明細書（以下、レセプトと言う）に対し、保険者は診療行為とその請求とが適切であるかどうかというレセプトの審査を行っている。そして、レセプトの審査は専門家によりもっぱら手によって行われる書面審査である。
レセプトは審査機関および保険者に紙で送られ、保険者は、レセプトを紙のまま保管すると共に電子化して保管する。
保険者内にある専門委員会が参考資料にもとづいて、毎月点検対象とする医療機関を決定し、その医療機関から請求されたレセプトを点検する。
点検対象となったレセプトは、保管先から検索する。電子化されたレセプトについては、検索キーを用いて検索し、点検に必要な情報を指定して出力する。出力されたレセプトは、医療機関単位にまとまっており、おのおののレセプトは傷病が異なっている。
点検員は、医療分野の専門家が多く、専門家により傷病に関して得意分野がある。これらさまざまな傷病のレセプトを点検員により目視で判断している。
不適当であると判断されたレセプトに対しては再審査請求書を作成する。保険者は、再審査請求となったレセプト情報を記録しており、再審査請求となったレセプトが審査機関にあるのか、審査機関から回答されたのか、経過を管理している。
【０００３】
【発明が解決しようとする課題】
従来の技術の場合、レセプトの内容点検は、特定した医療機関から請求されたレセプトを点検する方法や月をまたがって数ヶ月間継続的に点検する方法がとられている。
傷病名が各々異なったレセプトを一枚一枚めくりながら点検しており、傷病ごとに点検の着眼が違うため、限られた時間で点検できる数には限度がある。
また、レセプトを点検する点検員は、医療分野の専門家であることが多く、専門家により傷病に関して得意分野があるため、自分の得意分野である傷病のレセプトは入念に点検できるが、得意分野でない傷病のレセプトは、充分な点検が行われないことが考えられる。
傷病によっては高額になりやすいものや、治癒するまでに長期化するもの、季節ごとに発病の傾向が高いものなどがあり、傷病ごとに傷病に準じた点検の仕方もあると考えられる。
【０００４】
従来の技術では、レセプトは紙が大部分であるが、たとえレセプトが電子的になったとしても、異なった傷病名のレセプトを一件一件点検することにかわりはなく、点検員の負担は軽減されない。そのために、傷病名ごとにまとめてレセプトを出力し、ある傷病名のレセプトについては、その傷病を得意とする点検員が点検する必要がある。
点検の結果、不適当と判断されたレセプトは、審査機関に対して再審査請求を行なっており、従来の技術の場合、再審査請求となったレセプトが、審査機関にあるのか、審査機関から回答されたのか、経過を管理している。
再審査請求となったレセプトは毎月どのくらいあるのか、何の傷病の再審査請求が多いのかを知るには、必要な情報がどこにあるかを探さなければならない。また、探し出してからそれらの情報を加工したり集計したりする作業が発生する。したがって、再審査請求の多い傷病や季節ごとに再審査請求の傷病にどのような傾向があるのかを分析するには非常に手間がかかる。
従来のレセプト点検方法のほかに、傷病名によるレセプト点検を行うことにより、レセプトを網羅して点検することにある。
【０００５】
【課題を解決するための手段】
上記目的を達成するために、本発明は、
レセプト情報を入力し、蓄積し、管理し、出力する機能を有するレセプト点検システムにおけるレセプト点検方法であり、
レセプトの基本情報の項目である傷病名をキーにして、前記蓄積したレセプト情報から点検対象のレセプト情報を検索するようにしている。
また、レセプト情報を入力し、蓄積し、管理し、出力する機能を有するレセプト点検システムにおけるレセプト点検方法であり、
レセプトの記載事項が不適当と判断されたレセプトの情報を蓄積した情報から傷病名ごとに件数および点数を合計して再審査請求統計情報を生成し、該再審査請求統計情報に基づき再審査請求の多い傷病名を抽出し、抽出された再審査請求の多い傷病名をキーにして、前記蓄積したレセプト情報から点検対象のレセプト情報を検索するようにしている。
【０００６】
また、レセプト情報を入力し、蓄積し、管理し、出力する機能を有するレセプト点検システムであり、
レセプトの記載事項が不適当と判断されたレセプトの情報を蓄積した情報から傷病名ごとに件数および点数を合計して再審査請求統計情報を生成する手段と、検索条件である傷病名を指定するために、任意に選択された傷病名を入力する手段と、
検索条件である傷病名を指定するために、指定された抽出条件に基づき前記生成された再審査請求統計情報から再審査請求の多い傷病名を抽出し、該抽出した傷病名を入力する手段を有するようにしている。
さらに、前記指定された抽出条件に基づき前記生成された再審査請求統計情報から再審査請求の多い傷病名を抽出する際、該抽出条件に従い再審査請求統計一覧を表示するようにしている。
【０００７】
レセプト点検システムにおけるプログラムを記録したコンピュータ読み取り可能な記録媒体であり、
該プログラムは、レセプトの記載事項が不適当と判断された再審査請求のレセプトの情報を蓄積した情報と再審査請求結果を蓄積した情報とを組み合わせ再審査請求情報を生成するステップと、
該再審査請求情報に基づき各傷病名毎に統計を取り、統計結果を蓄積して再審査請求統計情報を生成するステップを有するようにしている。
また、レセプト点検システムにおけるプログラムを記録したコンピュータ読み取り可能な記録媒体であり、
該プログラムは、傷病名によりレセプトを検索する検索画面を表示するステップと、
該検索画面上で入力された抽出条件に基づき蓄積された再審査請求統計情報から抽出条件に該当する再審査請求統計情報を抽出するステップと、
抽出された再審査請求統計情報中の傷病名をレセプト検索キーとして検索画面上に入力するステップと、
該入力されたレセプト検索キーにより、蓄積されたレセプト情報から点検対象のレセプト情報を検索するステップを有するようにしている。
【０００８】
【発明の実施の形態】
以下にレセプト点検処理の実施を支援する一実施形態である傷病名によるレセプト点検システムおよび再審査請求統計を活用したレセプト点検システムについて説明する。
本実施例は、医療機関によるレセプト点検や月をまたがって数ヶ月間継続的に点検する方法のほかに傷病名によるレセプト点検を行なうことにより、レセプトを網羅して点検することを可能にし、また、レセプトを傷病ごとにまとめて出力することにより、その傷病の着眼を均一にし点検員の作業効率を上げることを可能にし、また、点検員が自分の得意とする傷病を点検することにより、充実した点検を行ない、点検効果を上げることを可能にし、さらに、再審査請求作業から傷病ごとに再審査請求統計を自動的に作成し、統計結果から再審査請求の多い傷病について重点的に点検を行なうことを可能にしようとするものである。
【０００９】
図１は、本発明の一実施例である傷病名によるレセプト点検システムおよび再審査請求統計を活用したレセプト点検システムのハードウェア構成である。
本システムは、サービス要求装置（以下、クライアントという）１２からの要求に対して基本情報ＤＢ１１４や画像ＤＢ１１６にある情報をプリンタ１４に送信したり、スキャナＯＣＲ１４からの情報を受信し基本情報ＤＢ１１４や画像ＤＢ１１６に格納処理を行うサービス提供装置（以下、サーバという）１１と、
サーバ１１に対してレセプトのイメージ画像の印刷要求を行ったり点検結果のデータを格納要求するクライアント１２と、
サーバ１１からの指示によりレセプト画像を印刷するプリンタ１３と、
レセプトのイメージ画像を読み込み、読み込んだイメージ画像に対して文字認識を行い、結果を基本情報ＤＢ１１４等に格納するスキャナＯＣＲ１４と、
これらのシステムを結ぶネットワークであるＬＡＮ（Local Area Network）１５と、
再審査請求結果が記録された外部記憶メディア１６からなる。
【００１０】
サーバ１１は、処理部１１０と、記憶部１１１と、表示部１１２と、入力部１１３と、基本情報ＤＢ１１４と、管理情報ＤＢ１１５と、画像ＤＢ１１６と、再審査請求ＤＢ１１７と、再審査請求統計ＤＢ１１８からなる。
処理部１１０は、クライアント１２からの検索等の要求処理や入力結果等の受信処理を行う。
記憶部１１１は、処理の結果などを一時的に記憶する。
表示部１１２は、各処理の経過や処理結果などを表示する。
入力部１１３は、サーバ１１の操作等を行う。
基本情報ＤＢ１１４は、レセプト点検の対象となるレセプトの医療機関コードや整理番号、傷病名等を蓄積する。
管理情報ＤＢ１１５は、点検の過程における処理状況や点検終了後の結果を記録する。
画像ＤＢ１１６は、レセプトのイメージ画像をレセプトの整理番号や登録した年月とともに蓄積する。
再審査請求ＤＢ１１７は、再審査請求となったレセプトの整理番号や傷病名等を蓄積する。
再審査請求統計ＤＢ１１８は、再審査請求ＤＢ１１７から同じ傷病名のデータをカウントし請求件数の多い傷病名ごとに件数等を蓄積する。
【００１１】
クライアント１２は、処理部１２０と、記憶部１２１と、表示部１２２と、入力部１２３から構成される。
処理部１２０は、サーバ１１に印刷の要求や検索条件の送信等を行う。
記憶部１２１は、各処理の処理結果などを一時的に記憶する。
表示部１２２は、各処理の経過や処理結果などを表示する。
入力部１２３は、検索条件や点検結果を入力する。
【００１２】
図２は、本実施形態の基本情報ＤＢ１１４の具体例を示す図である。
基本情報ＤＢ１１４はレセプトに書かれている項目の一部で、検索する際のキーとなりうる情報が蓄積されたＤＢである。
図２に示すように基本情報ＤＢ１１４は、レセプトを提出した医療機関の医療機関コード２１、医療機関においてレセプトが作成される診療が行われた診療年月２２、各レセプトの固有の番号であるレセプトの整理番号２３、レセプトを作成した医療機関がある都道府県名２４、レセプトの種類を示すレセプト種類２５、診療を施す原因となった傷病名２６、診療を受けた人の保険証番号２７、診療を受けた人の性別２８、診療を受けた人の生年月日２9、医療機関からレセプトにより請求された請求点数３０の情報が入っている。
例えば、整理番号２３が「１１１１１１１１」の場合、そのレセプトは、「神奈川」にありかつ医療機関コードが「０１２３４５６」の医療機関において、生年月日が「Ｈ１．１．２０」で、保険証番号が「神奈川２２２２２」の「女性」が、「Ｈ１１／５」に受けた診療に対して医療機関が保険者に請求点数「８０００」を要求したレセプトであることを意味する。
基本情報ＤＢ１１４の項目である医療機関コード２１、診療年月２２、整理番号２３、都道府県名２４、レセプト種類２５、傷病名２６、保険証番号２７、性別２８、生年月日２９、請求点数３０は、レセプトのスキャナＯＣＲ読み込み処理で登録が行われ処理が終了するまで更新されることはない。
【００１３】
図３は、本実施形態の管理情報ＤＢ１１５の具体例を示す図である。
管理情報ＤＢ１１５はレセプトの点検の経過や結果などの情報を管理するために必要となるＤＢである。
図３に示すように、現在点検を行っているレセプトの整理番号３１、現在の点検の状態コード３２、点検の状態を更新した日時の情報である状態更新日３３が入っている。管理情報ＤＢ１１５の項目である状態コード３２、状態更新日３３は、点検を行っていく過程で随時更新される。
例えば、整理番号「１１１１１１１１」のレセプトについては、状態コードが「再審査終了」で、その状態コードに更新された状態更新日は「Ｈ１１．７．６」であることを意味する。
【００１４】
図４は、本実施形態の画像ＤＢ１１６の具体例を示す図である。
画像ＤＢ１１６は医療機関から提出されたレセプトのイメージ画像を管理するために必要となるＤＢである。
図４に示すように、画像情報ＤＢ１１６は、レセプトの整理番号４１、レセプトのイメージ画像が登録された年月４２、レセプトのイメージ画像である画像ファイル４３を格納したＤＢである。例えば整理番号が「２２２２２２２２」の場合、登録年月が「Ｈ１１．７」、画像ファイルが「ＧＶ１２３４５」として格納されていることを意味する。
【００１５】
図５は、本実施形態の再審査請求ＤＢ１１７の具体例を示す図である。
再審査請求ＤＢ１１７は、再審査請求統計ＤＢ１１８を作成するための基礎になる情報を格納したＤＢである。
図５に示すように、再審査請求ＤＢ１１７は、レセプトの整理番号５１と、診療した年月５２と、傷病名５３と、診療を受けた人の性別５４と、診療を受けた人の生年月日５５と、医療機関からレセプトにより請求された点数５６と、点検により再審査請求となった審査機関へ再審査請求する点数５７と、再審査結果５８と、支払確定点数５９からなる。
例えば整理番号が「２２２２２２２２」のレセプトについて、診療年月が「Ｈ１１．６」、傷病名が「胃潰瘍」、性別が「男」、生年月日が「Ｓ３２．６．２」、請求点数が「７００００」、再審査請求点数が「６４０００」、再審査結果が「査定」、支払確定点数が「６５０００」として格納されていることを意味する。
なお、レセプトの整理番号５１と、診療した年月５２と、傷病名５３と、診療を受けた人の性別５４と、診療を受けた人の生年月日５５と、医療機関からレセプトにより請求された点数５６と、審査機関へ再審査請求する点数５７は、再審査請求となった時に再審査請求ＤＢ１１７に格納されるものであり、再審査結果が「査定」、支払確定点数が「６５０００」は、再審査請求結果が返ったときに追加して格納されるものである。
【００１６】
図６は、本実施形態の再審査請求統計ＤＢ１１８の具体例を示す図である。
再審査請求統計ＤＢ１１８は、再審査請求ＤＢ１１７から傷病名ごとに合計件数を計算し、件数の多かった傷病順に傷病名と件数、請求点数を蓄積するＤＢである。
さらに再審査請求結果が返ったときに、再審査請求ＤＢ１１７に格納された支払確定点数を傷病名ごとに合計計算し、結果を追加して格納するＤＢである。
図６に示すように、再審査請求統計ＤＢ１１８は、順位６１と、最新点検年月６２と、順位６１に対応した傷病名６３と、件数６４と、請求点数６５と、再審査請求結果登録後に追加して格納する確定点数６６からなる。
例えば、「H11．６」の再審査請求において、件数の一番多かった傷病名は「糖尿病」であり、件数が「１２０」、点数が「６０００００」であり、確定点数「５０００００」であることを意味する。
また、再審査請求統計ＤＢ１１８に格納される点検月数は、点検結果が格納された最新月からさかのぼって、点検月を含む１３ヶ月前までの月である。例えば、点検結果が格納された最新年月が「Ｈ１１．６」の場合、「Ｈ１０．６」が一番古い年月となる。
１３ヶ月分の点検結果を蓄積することにより、前年の同じ月の再審査請求状況を参考にすることができる。
なお、再審査請求統計ＤＢ１１８は、次の月の再審査請求登録を受け付けると、一番古い月の情報をクリアし、次の月の情報を最新の情報として格納する。
例えば、次の月「Ｈ１１．７」の情報を受け付けると、一番古い年月「Ｈ１０．６」の情報をクリアし、「Ｈ１１．７」の情報を最新年月の情報として格納することを意味する。
【００１７】
図７は、クライアント利用者が点検するレセプトを検索する時、どの傷病名のレセプトを検索するのか条件を指定する入力画面の一例である。
図７に示すように、傷病名を入力するためにクライアント１２の表示部１２２に表示する詳細条件による検索画面７００は、点検（診療）対象年月が自動的に表示される欄７０１と、レセプトの種類が表示される欄７０２と、傷病名を入力する欄７０３と、再審査請求統計ＤＢ１１８を参照して再審査請求件数の多かった傷病名あるいは請求点数が多かった傷病名を読み取り、その傷病名を自動的に入力設定する再審査請求統計参照７０４と、入力あるいは再審査請求統計ＤＢより自動設定した傷病名により検索する条件一覧を表示するデータリスト欄７１１と、システム全体の処理実行状況を表示する実行状況７１３からなる。
【００１８】
例えば、図７では点検（診療）年月は「平成１１年６月」で、レセプト種類「医科」であることを意味する。
再審査請求統計参照７０４は、再審査請求統計参照のキーを件数順とするか点数順とするかを選択するボタン７０５と、再審査請求統計ＤＢ１１８よりどの年月の再審査請求統計を参照するか参照年月を指定する参照年月７０６と、順位７０７と、選択および指定した条件で再審査請求統計状況を表示させるための一覧表示ボタン７０８からなる。一覧表示ボタン７０８を押すことにより、選択した条件の再審査請求統計状況をクライアント利用者に提供することができる。
例えば、図７の再審査請求統計参照７０４において、再審査請求統計参照のキーが「件数順」で、参照年月が「平成１０年６月〜平成１０年７月」で、順位が「３位」を参照条件とすること、すなわち、１位から３位までを参照条件とすることを意味する。
なお、本実施例では、再審査請求統計参照７０４に選択・指示が行われた場合、傷病名欄７０３は入力できないようにする。
傷病名入力欄７０３に傷病名を入力後あるいは再審査請求統計参照７０４の参照条件選択後、追加ボタン７０９が押されることにより、データリスト欄７１１にレセプト検索の条件が表示される。
なお、データリスト欄は、入力内容がわかるように簡略化した形式で表示を行う。
【００１９】
図７では、レセプト検索の条件２件がデータリスト欄に蓄積された状態であり、１件目の「Ｈ１１．６ 医 胃潰瘍 」は、点検年月「平成１１年６月」で、レセプト種類「医科」、傷病名「胃潰瘍」であることを意味する。
データリストに表示された検索条件のうち削除したい検索条件がある場合は、データリスト７１１にて削除したい案件を選択し、削除ボタン７１０を押す。
実行ボタン７１２は、データリスト欄に検索条件の表示が完了した時に、データリスト７１１にある情報と印刷実行指示をサーバ１１に送信するためのボタンである。
実行状況７１３は、処理の状況が表示される欄である。実行状況欄７１３は本システムに関する全てのジョブを開始、終了状況などを表示できるものとする。これにより、現在の進捗状況をクライアント利用者に通知することができる。
【００２０】
図８は、再審査請求統計参照一覧表示画面を具体的に示した画面の一例である。
再審査請求統計参照一覧表示画面８００は、図７の詳細条件による検索画面７００の再審査請求統計参照７０４において、件数順と、参照年月と、順位を指定した後に、一覧表示７０８を押すことにより表示される画面である。
図８に示すように、再審査請求統計参照一覧表示画面８００は、前出の参照年月７０６で指定した参照年月と同じ年月８０１と、前出の順位７０７で指定した順位８０２と、傷病名８０３と、件数８０４と、点数（Ａ）８０５と、確定点数（Ｂ）８０６と、確定点数を請求点数で割った査定率（Ｂ／Ａ）８０７からなる。
例えば、前出図7の再審査請求統計参照７０４で、再審査請求統計を参照するキーとして「件数順」を指定し、参照年月が「平成１０年６月〜平成１０年７月」で、順位が「３位」と指定し、一覧表示ボタン７０８を押すことにより、図８の再審査請求統計参照一覧表示画面８００では、前出の参照年月と同じ年月「平成１０年６月〜平成１０年７月」、順位「1位」は、傷病名が「糖尿病」、件数が「２００」、点数が「７０００００」、確定点数が「６９００００」、査定率が「９８．５」であることを意味する。
そして、戻るボタン８０８を押すことにより、図７の詳細条件による検索画面７００に戻る。
したがって、クライアント利用者に指定した条件による再審査請求統計情報を提供することにより、提供再審査請求統計を目視して、レセプト検索の条件として適切かを判断することができる。
【００２１】
図９は、再審査請求件数一覧表を具体的に示した図の一例である。
再審査請求件数一覧表９００は、順位９０１と、点検が実施された最新年月９０２と、順位９０１に対応した傷病名９０３と、件数９０４と、点数（A）９０５と、確定点数（B）９０６と、査定率（B/A）９０７からなる表と、
最新年月から半年前までの年月９０８と、順位９０１に対応した傷病名９０９、件数９１０と、点数（A）９１１と、確定点数（B）９１２と、査定率９１３（B/A）からなる表と、
さらに最新年月から1年前までの年月９１４と、順位９０１に対応した傷病名９１５、件数９１６と、点数９１７（A）と、確定点数（B）９１８と、査定率９１９（B/A）からなる表とからなる。
例えば、図９で示すように、順位が「１位」の場合、点検が実施された最新年月は「Ｈ１１．６」で、順位1位に対応した傷病名が「糖尿病」で、件数が「１２０」で、点数（A）が「６０００００」で、確定点数（B）が「５９００００」で、査定率（B/A）が「９８．３」であることを意味する。
さらに最新年月から半年前までの年月は「Ｈ１１．６〜Ｈ１１．１」で、順位1位に対応した傷病名が「糖尿病」で、件数が「３００」で、点数（A）が「９０００００」で、確定点数（B）が「８９００００」で、査定率（B/A）が「９８．９」であり、最新年月から１年前までの年月は「Ｈ１１．６〜Ｈ１０．７」で、順位1位に対応した傷病名が「心筋梗塞」で、件数が「５００」で、点数（A）が「１００００００」で、確定点数（B）が「９０００００」で、査定率（B/A）が「９０．０」であることを意味する。
再審査請求件数一覧表９００は、点検が実施された最新年月の再審査請求統計と最新年月から半年前までの再審査請求統計と最新年月から1年前までの再審査請求統計を表示させることにより、点検効果の確率の高い傷病名を絞り込むことができる。
【００２２】
図１０は、図１で示したレセプト点検システムにおける傷病名によるレセプト点検および再審査請求統計を活用したレセプト点検の処理を示す全体フローである。
ステップ１００１において、本システムの点検対象であるレセプトをＯＣＲスキャナにより読み込む。その際、レセプトのイメージ画像は全面を対象に読み込むが、文字認識は特定部分のみ行う。読み込んだレセプトのイメージ画像を画像ＤＢ１１６に格納し、文字認識された情報は基本情報ＤＢ１１４に格納する。
ステップ１００２、ステップ１００３、ステップ１００４、ステップ１００５は、点検するレセプトの検索条件である傷病名を指定する段階である。
傷病名を指定する方法によりステップ１００３とステップ１００４の２つに分岐する。ステップ１００２において、傷病名を指定する方法が選択される。指定方法として、キーボードの入力による任意指定方法と、再審査請求統計参照による指定方法がある。
キーボードの入力による任意指定方法が選択された場合、ステップ１００３において、図７の詳細条件による検索画面の傷病名欄７０３にクライアント１２のキーボードから傷病名が入力される。
再審査請求統計参照による指定方法が選択された場合、ステップ１００４において、図７の詳細条件による検索画面の再審査請求統計参照７０４で、クライアント１２から選択および入力が行なわれると、サーバ１１に指示が送られ、サーバ１１は再審査請求統計ＤＢ１１８を参照する。参照により取得した傷病名をクライアント１２に伝送する。
ステップ１００５において、サーバより伝送された傷病名はクライアント１２の記憶部１２１に記憶される。
ステップ１００６において、クライアント１２の傷病名指定により、サーバ１１はレセプトの検索を行い、その後、ステップ１００７において、検索したイメージ画像の印刷を行う。
次にステップ１００８において、印刷されたイメージ画像により点検員が目視により点検を行ない、クライアント１２より点検結果が順次入力される。
ステップ１００９において、サーバ１１はクライアント１２から全ての点検結果を受信し、管理情報ＤＢ１１４に登録する。
【００２３】
ステップ１０１０、ステップ１０１１、ステップ１０１２は、管理情報ＤＢ１１４において再審査請求となっているレセプト情報をもとに再審査請求統計ＤＢ１１７が作成される段階である。
ステップ１０１０において、管理情報ＤＢ１１４で再審査請求となっているレセプト情報があるかどうか判断する。再審査請求となっているレセプト情報がない場合は処理を終了し、ある場合は、ステップ１０１１において、再審査請求となっているレセプト情報を再審査請求ＤＢ１１７に格納し、ステップ１００７で入力された点検結果より再審査請求分のレセプトについて、審査機関に再審査請求する点数も追加する。
次に、ステップ１０１２において、傷病名ごとにまとめて合計件数を計算し、処理結果を再審査請求統計ＤＢ１１８に格納する。
【００２４】
ステップ１０１３、ステップ１０１４、ステップ１０１５は、外部記憶メディア１６に記録された再審査請求結果を読み込み、再審査請求ＤＢ１１７に再審査請求結果が追加され、さらに再審査請求統計ＤＢ１１８に再審査請求結果の計算結果が追加される段階である。
ステップ１０１３において、再審査請求結果を登録するかどうかを判断する。登録するを選択した場合、ステップ１０１４において、クライアント１２は外部記憶メディア１６に記録された再審査請求結果を読み込み、再審査請求ＤＢ１１７に再審査請求結果が追加される。さらにステップ１０１５において、再審査請求統計ＤＢ１１８にも再審査請求結果の計算結果が追加される。
ステップ１０１６において、図９の再審査請求統計一覧表９００が出力される。
ステップ１０１３において、登録しないを選択した場合、ステップ１０１６において、図９の再審査請求統計一覧表９００が出力される。
その後、レセプト点検処理が完了する。
【００２５】
図１１〜図１４は、図１０の全体フローチャートの詳細を示す詳細フローである。
図１１は、図１０のステップ１００１、ステップ１００２、ステップ１００３、ステップ１００４、ステップ１００５、ステップ１００６、ステップ１００７を詳細に示したフローチャートであり、点検対象となるレセプトの検索条件である傷病名を指定し、指定した条件によりレセプトを検索し、出力するまでの流れを示す。
まず、ステップ１１０１において、クライアントは、点検したいレセプトの検索条件指定するため、点検したい傷病名を任意に指定する方法か、再審査請求統計ＤＢ１１８を参照し、再審査請求の多かった傷病名を指定する方法かのどちらかを選択する。
点検したい傷病名を任意に指定する場合、ステップ１１０２において、クライアント１２は入力部１２３より図７の詳細条件による検索画面７００の傷病名入力欄７０３に傷病名を入力し、追加ボタン７０９を押す。これにより、ステップ１１０３において、該画面のデータリスト欄７１１に点検（診療）年月、レセプト区分、傷病名が表示される。
なお、傷病名指定に当たっては、図９の再審査請求件数一覧表９００を参照することができる。これにより、クライアントは、再審査請求件数一覧表より最近の再審査請求の傾向や過去半年間および過去１年間の再審査請求の傾向をみて、どの傷病名で検索すると、点検効果が高くなるかが判断できるので、点検作業が効率的に行なうことができ、また点検効果を上げることができる。
ステップ１１０４において、他の傷病名についても検索条件とするかを問う。他の傷病名について検索条件とする場合は、ステップ１１０２に戻り、同様の処理を行う。
他の傷病名について検索しない場合は、ステップ１１１２へ進む。
【００２６】
次は、ステップ１１０１において、再審査請求統計を参照して、再審査請求の多かった傷病名を検索条件として指定する方法の処理についての説明である。
ステップ１１０５において、クライアントは、該画面の再審査請求統計参照欄７０４の件数順あるいは点数順のボタン７０５を選択する。
次に、ステップ１１０６において、再審査請求統計ＤＢ１１８よりどの年月の統計を参照するかを指示する。
次に、ステップ１１０７において、再審査請求統計ＤＢ１１８より何位までの統計を参照するかを指定する。
再審査請求統計参照７０４において、件数順か点数順かの参照の基準キー７０５と、参照年月７０６と、順位７０７の指定が完了すると、ステップ１１０８において、クライアントより再審査請求統計ＤＢ１１８を参照する指示がサーバに出される。
この時、再審査請求統計ＤＢ１１８の参照指示を受信したサーバは、年月、順位、傷病名を図１５の検索テーブル９１に記憶する。サーバは、再審査請求統計ＤＢ１１８より年月、順位、傷病名、件数、点数、確定点数を読み込み、図１６の参照結果テーブル９２に記憶する。
なお、参照年月が複数になる場合には、傷病名ごとに件数の合計と、点数の合計と、確定点数の合計を計算し、確定点数を点数で徐して、査定率を計算し、順位ごとに計算結果を図１７の処理テーブル９３に記憶する。
参照年月が単月の場合は、傷病名、件数、点数、確定点数は、参照結果テーブル９２に記憶されている情報そのものと、確定点数を点数で徐して、査定率を計算した結果を処理テーブル９３に記憶する。
サーバは処理テーブル９３の情報をクライアントに送る。
【００２７】
次に、ステップ１１０９において、ステップ１１０５、ステップ１１０６、ステップ１１０７で指定した条件により再審査請求統計ＤＢ１１８の参照結果を一覧表示するかどうかを選択する。
ステップ１１０９において、「一覧表示する」を選択した場合、該画面の一覧表示７０８を押すことにより、図８の再審査請求統計参照一覧表示画面の表示例でクライアント１２の表示部１２２に表示される（ステップ１１１０）。
クライアントは、図８の内容を確認し、戻るボタン８０８を押すことにより、図７に戻る。これにより、再審査請求統計ＤＢを参照し、参照一覧を目視できることにある。つまり統計結果では順位の高い傷病名でも、下位の傷病名でも査定率が高い場合があり、統計情報に加えて、点検員の目視による判断が加わることで、点検効果の確率の高い傷病名を絞り込むことができる。
なお、「一覧表示する」を選択しない場合にはステップ１１１１に進む。
ステップ１１１１において、追加ボタン７０９を押すことにより、データリスト欄７１１に点検（診療）年月と、レセプト種類と、該画面の再審査請求統計参照７０４で指定した情報より参照結果として出た傷病名が表示される。順位を複数指定した場合、上位から順にデータリストに表示される。
例えば、処理テーブル９３の順位１位の傷病名「糖尿病」がデータリスト欄に表示され、順位２位の傷病名「胃潰瘍」が次に表示されることになる。また、データリスト欄に検索条件が表示されることにより、検索テーブル９１と、参照結果テーブル９２と、処理テーブル９３の情報はクリアになる。
【００２８】
データリスト欄７１１に検索条件が表示された後は、ステップ１１１２へ行く。
ステップ１１１２において、クライアントは、検索条件をキーに点検対象のレセプトを検索する。
次に、ステップ１１１３において、クライアントは検索したレセプトを印刷する指示をサーバに送り、サーバはクライアントから印刷指示を受け取り、プリンタよりレセプトの印刷処理を行う。
なお、ステップ１１０１において、入力による任意指定と再審査請求統計参照による指定のどちらを選択しても、ステップ１１１２以降の処理は同じになる。
【００２９】
図１１で示した通り、傷病名を任意に入力する方法と、再審査請求統計を参照して、これまでに再審査請求の多かった傷病名を読み取って、その傷病名を自動的に検索条件に指定する方法を選択することができる。
これにより、点検作業の効率があがる。点検する月の発病傾向や過去の再審査実績にもとづいた傷病名が検索条件となるので、点検実績が向上することになる。
傷病名を任意に入力する時には、図８の再審査請求統計一覧表を参考にして傷病名を決定することができる。また、再審査請求統計ＤＢを参照する時には、再審査請求統計一覧表示を表示させることにより、参照結果の傷病名で、件数の多かった傷病名は何か、査定率が高い傷病名は何かを目視した上で検索条件に指定できるので、点検作業の効率が上がり、点検効果が上がる。
【００３０】
図１２は、図１０で示したステップ１００８、ステップ１００９の詳細を示したフローチャートであり、レセプトの点検結果の入力により、再審査請求のレセプトについて管理情報DBに再審査請求と更新される処理を示すものである。
まず、ステップ１２０１において、点検後に「問題なし」か「再審査請求」か、クライアントより点検結果が入力される。再審査請求において、医療機関から請求された請求点数と保険者が点検により審査機関に再審査請求する点数に差がある場合には、再審査請求するレセプトの診療年月と、整理番号と、再審査請求点数を図１８の再審査請求点数テーブル９４に一時格納する。レセプトの点検が終ると、全ての点検結果をサーバに送り、クライアントより受信したサーバは、「再審査請求」のレセプトについて、管理情報ＤＢ１１５の状態コードを「再審査請求」と更新し、それ以外のレセプトは、管理情報ＤＢ１１５の状態コードを「問題なし」と更新する。
【００３１】
図１３は、図１０で示したステップ１０１０、ステップ１０１１、ステップ１０１２の詳細を示したフローチャートであり、再審査請求ＤＢより再審査請求統計ＤＢを作成する処理を示したものである。
ステップ１３０１において、サーバは、管理情報ＤＢ１１５で状態コードが「再審査請求」となっているレセプトを検索する。この時、サーバは検索により取得した整理番号を、図１９の一時記憶テーブル９５に順次格納する。
ステップ１３０２において、該当するレコードがある場合には、ステップ１３０３に行く。該当するレコードがない場合には、ステップ１３０４において、クライアント１２の表示部１２２に「該当なし」というメッセージを表示させ、処理は終了する。
次に、ステップ１３０３において、図１９の一時記憶テーブル９５の整理番号をキーに、基本情報ＤＢ１１４より診療年月２２、傷病名２３、性別２８、生年月日２９、請求点数３０を取得し、整理番号とともに再審査請求ＤＢ１１７に格納する。
再審査請求ＤＢ１１７に整理番号、診療年月、傷病名、性別、生年月日、請求点数が格納されると、一時記憶テーブル９５の情報はクリアされる。
【００３２】
さらに、ステップ１３０５において、前出の再審査請求点数テーブル９４の整理番号をキーにして、再審査請求ＤＢ１１７の再審査請求点数５７に、再審査請求点数テーブル９４の再審査請求点数を追加する。
再審査請求ＤＢに再審査請求点数が追加されると、再審査請求テーブル９４の情報は、クリアされる。
ステップ１３０６において、再審査請求ＤＢ１１７より最新診療年月の傷病名ごとに再審査請求件数合計と、請求点数合計を計算し、計算結果を図２０の合計テーブル９６に格納する。
ステップ１３０７において、合計テーブル９６で件数合計の多い順にデータの並べ替えを行い、並べ替えた結果を再審査請求統計ＤＢ１１８の最新年月欄６２に格納する。最新年月欄６２に合計テーブル９６の情報が格納されると、合計テーブル９６の情報はクリアされ、処理は終了する。
この処理により、レセプトの点検結果入力より再審査請求ＤＢ作成や再審査請求統計ＤＢ作成が自動化されるので、作業効率が上がる。
【００３３】
図１４は、図１０で示したステップ１０１４、ステップ１０１５、ステップ１０１６の詳細を示したフローチャートであり、審査機関より返った再審査請求結果を再審査請求ＤＢ１１７および再審査請求統計ＤＢ１１８に格納するものである。
まず、審査機関より再審査請求結果が記憶された外部記憶メディア１６が保険者に送付される。ステップ１４０１において、クライアント１２は、外部記憶メディア１６に記録された再審査請求結果を読み込み、読み込んだデータをサーバに転送し、サーバは該データを図２１の再審査結果テーブル９７に一時格納する。
ステップ１４０２において、プリンタより再審査請求結果を印刷し、内容を確認する。
次に、ステップ１４０３において、再審査結果テーブル９７の整理番号をキーにして、サーバは再審査請求ＤＢ１１７の再審査結果５８に再審査結果テーブル９７の再審査結果を追加する。
例えば、図５において、整理番号「４４４４４４４４」のレセプトに、再審査結果テーブル９７の再審査結果「原審」が、再審査結果欄５８に「原審」と追加されたことを意味する。
【００３４】
次に、再審査結果が原審どおりか査定か（ステップ１４０４）により、２つの処理に分岐する。「原審通り」のものは、ステップ１４０５の処理に行く。
ステップ１４０５において、再審査請求ＤＢ１１７の再審査請求点数５７と同じ点数が、該ＤＢの支払確定点数５９に格納される。
例えば、再審査結果テーブル９７において、整理番号「４４４４４４４４」のレセプトの増減点数が「０」なので、図５において、整理番号「４４４４４４４４」のレセプトの支払確定点数が「８０００」と追加されたことを意味する。
なお、再審査結果欄５８と支払確定点数５９に情報が格納されると、再審査結果テーブル９７の再審査結果情報は、クリアされる。
ステップ１４０４において、「査定」となったものは、ステップ１４０６の処理に行く。
ステップ１４０６において、サーバは、再審査結果テーブル９７より再審査結果が「査定となったレセプトの整理番号をもとに、再審査請求ＤＢ１１７の再審査請求点数５７と再審査結果テーブル９７の増減点数とで計算し、計算結果を図２２の結果テーブル９８に一時格納する。
ステップ１４０７において、再審査請求ＤＢ１１７の支払確定点数５９に結果テーブル９８の計算結果が追加される。
例えば、再審査結果テーブル９７において、整理番号「２２２２２２２２」のレセプトの増減点数が「１０００」なので、再審査請求ＤＢ１１７の整理番号「２２２２２２２２」の再審査請求点数５７「６４０００」に増減点数「１０００」を加え、結果テーブル９８の整理番号「２２２２２２２２」の計算結果「６５０００」を記憶し、再審査請求ＤＢ１１７の支払確定点数５９に「６５０００」を追加したことを意味する。
なお、再審査結果欄５８と支払確定点数５９に情報が格納されると、再審査結果テーブル９７において該当する再審査結果情報と、結果テーブル９８の情報は、クリアされる。
ステップ１４０５およびステップ１４０７の後は、ステップ１４０８へ行く。
【００３５】
ステップ１４０８において、再審査請求ＤＢ１１７において、傷病名ごとに支払確定点数の合計を計算し、計算結果を図２３の確定点数テーブル９９に格納する。
サーバは、確定点数テーブル９９の該当する傷病名の確定点数を再審査請求統計ＤＢ１１８の最新点検年月６２の確定点数欄６６に追加される。
例えば、確定点数テーブル９９で「糖尿病」「５０００００」の情報は、図６において、最新点検年月「Ｈ１１．６」の順位１位「糖尿病」の確定点数６６に「５０００００」として追加されることを意味する。
なお、再審査請求統計ＤＢ１１８の支払確定６６に、確定点数テーブル９９において該当する情報が追加されると、確定点数テーブル９９の情報は、クリアされる。
ステップ１４０９において、再審査結果テーブル９７のレセプトの整理番号をキーに、サーバは管理情報ＤＢ１１５において状態コードが「再審査請求」のレセプトを検索し、状態コードを「再審査終了」と更新し、処理は終了する。
なお、管理情報ＤＢ１１５で、状態コードが「再審査請求」から「再審査終了」と更新されると、再審査結果テーブル９７の情報は、クリアされる。
以上説明したように、本実施例は、レセプト点検処理において、傷病名によるレセプトを検索することができるので、新しい点検が可能となる。
また、傷病ごとにまとめて出力することにより、傷病の着眼を均一にし、点検員の作業効率を上げることができる。
また、点検員が自分の得意とする傷病を点検することにより、充実した点検を行ない、点検効果を上げることができる。
さらに再審査請求作業から傷病ごとに再審査請求統計を自動的に作成、統計結果から再審査請求の多い傷病について重点的に点検を行なうことにより、点検効果を上げることができる。
【００３６】
【発明の効果】
上述したように本発明によれば、レセプト点検処理において、傷病名によるレセプトを検索することができるので、新しい点検が可能となる。
【図面の簡単な説明】
【図１】レセプト点検システムのハードウェア構成及び接続関係を示す図である。
【図２】基本情報ＤＢの一例を示す図である。
【図３】管理情報ＤＢの一例を示す図である。
【図４】画像ＤＢの一例を示す図である。
【図５】再審査請求ＤＢの一例を示す図である。
【図６】再審査請求統計ＤＢの一例を示す図である。
【図７】検索条件を設定する場合、クライアント側が設定する画面の一例を示す図である。
【図８】検索条件を設定する場合、参考情報としてクライアント側に提供する画面の一例を示す図である。
【図９】再審査請求件数一覧表の一例を示す図である。
【図１０】傷病名によるレセプト点検および再審査請求統計ＤＢを活用したレセプト点検の処理の一例を示すフローチャートである。
【図１１】図１０におけるステップ１００１〜１００７を詳細に示したフローチャートである。
【図１２】図１０におけるステップ１００８〜１００９を詳細に示したフローチャートである。
【図１３】図１０におけるステップ１０１０〜１０１２を詳細に示したフローチャートである。
【図１４】図１０におけるステップ１０１４〜１０１６を詳細に示したフローチャートである。
【図１５】参照テーブルの一例を示す図である。
【図１６】参照結果テーブルの一例を示す図である。
【図１７】処理テーブルの一例を示す図である。
【図１８】再審査請求点数テーブルの一例を示す図である。
【図１９】一時記憶テーブルの一例を示す図である。
【図２０】合計テーブルの一例を示す図である。
【図２１】再審査結果テーブルの一例を示す図である。
【図２２】結果テーブルの一例を示す図である。
【図２３】確定点数テーブルの一例を示す図である。
【符号の説明】
１１ サーバ
１２ クライアント
１３ プリンタ
１４ スキャナＯＣＲ
１５ ＬＡＮ
１６ 外部記憶メディア
１１０ サーバ処理部
１１１ サーバ記憶部
１１２ サーバ表示部
１１３ サーバ入力部
１１４ 基本情報ＤＢ
１１５ 管理情報ＤＢ
１１６ 画像ＤＢ
１１７ 再審査請求ＤＢ
１１８ 再審査請求統計ＤＢ
１２０ クライアント処理部
１２１ クライアント記憶部
１２２ クライアント表示部
１２３ クライアント入力部

Claims (3)

1. サーバ装置と、該サーバ装置に接続されたクライアント装置と、レセプトに書かれている項目の一部で検索する際の検索キーとなり得るレセプト情報をレセプト毎に蓄積した基本情報データベースと、再審査請求をしたレセプトに関する再審査請求情報を蓄積した再審査請求データベースを具備するレセプト点検システムにおけるレセプト点検方法であって、
   前記基本情報データベースに蓄積されたレセプト情報は少なくとも整理番号、診療年月日、傷病名、医療機関コードと請求点数を備え、
   再審査請求データベースに蓄積された再審査請求情報は少なくとも整理番号、診療年月日、傷病名、請求点数と支払確定点数を備え、
   前記サーバ装置は、再審査請求統計情報生成指示の入力がされたとき、前記再審査請求データベースから再審査請求情報を読み込み、傷病名ごとに、再審査請求情報の件数と再審査請求情報中の請求点数の合計と再審査請求情報中の支払確定点数の合計を求め、求めた傷病名ごとの件数と各合計情報からなる再審査請求統計情報を生成し、
   前記サーバ装置は、点検対象のレセプト情報の抽出指示の入力がされたとき、前記再審査請求統計情報から再審査請求の多い傷病名を抽出し、該抽出された再審査請求の多い傷病名をキーにして前記基本情報データベースから点検対象のレセプト情報を検索することを特徴とするレセプト点検方法。
2. サーバ装置と、該サーバ装置に接続されたクライアント装置と、レセプトに書かれている項目の一部で検索する際の検索キーとなり得るレセプト情報をレセプト毎に蓄積した基本情報データベースと、再審査請求をしたレセプトに関する再審査請求情報を蓄積した再審査請求データベースを具備するレセプト点検システムであって、
   前記基本情報データベースに蓄積されたレセプト情報は少なくとも整理番号、診療年月日、傷病名、医療機関コードと請求点数を備え、
   再審査請求データベースに蓄積された再審査請求情報は少なくとも整理番号、診療年月日、傷病名、請求点数と支払確定点数を備え、
   前記サーバ装置は、再審査請求統計情報生成指示の入力がされたとき、前記再審査請求データベースから再審査請求情報を読み込み、傷病名ごとに、再審査請求情報の件数と再審査請求情報中の請求点数の合計と再審査請求情報中の支払確定点数の合計を求め、求めた傷病名ごとの件数及び各合計情報からなる再審査請求統計情報を生成する手段と、点検対象のレセプト情報の抽出指示の入力がされたとき、前記再審査請求統計情報から再審査請求の多い傷病名を抽出する手段と、該抽出された再審査請求の多い傷病名をキーにして前記基本情報データベースから点検対象のレセプト情報を検索する手段を有することを特徴とするレセプト点検システム。
3. 請求項２記載のレセプト点検システムにおいて、
   前記サーバ装置は、抽出された再審査請求の多い傷病名に対応する少なくとも再審査請求情報の件数と再審査請求情報中の請求点数の合計を前記生成した再審査請求統計情報から抽出する手段と、前記傷病名と抽出した件数及び請求点数の合計を前記クライアント装置に転送する手段を有し、
   前記クライアント装置は転送された前記傷病名と抽出した件数及び請求点数の合計からなる一覧情報を表示する手段を有することを特徴とするレセプト点検システム。

Images