レセプト分析技術（査定防止サービス）
【課題】医療機関におけるレセプト点検の精度向上を支援する。
【解決手段】医療事務支援装置１４は、医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する査定事例ＤＢ２２と、医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける未審査レセプト受付部２８と、査定事例ＤＢ２２に保持された複数の査定事例のうち、患者への医療行為の内容が、未審査レセプトにおける記載内容と合致する査定事例を特定する検索部３２と、検索部３２により特定された査定事例の情報をユーザへ提供する査定事例提供部とを備える。
【解決手段】医療事務支援装置１４は、医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する査定事例ＤＢ２２と、医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける未審査レセプト受付部２８と、査定事例ＤＢ２２に保持された複数の査定事例のうち、患者への医療行為の内容が、未審査レセプトにおける記載内容と合致する査定事例を特定する検索部３２と、検索部３２により特定された査定事例の情報をユーザへ提供する査定事例提供部とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ処理技術に関し、特に、医療機関における事務作業を支援するための技術に関する。
【背景技術】
【０００２】
健康保険を利用して医療を受ける保険診療では、被保険者（患者）が保険者（健康保険組合等）から発行された被保険者証を医療機関へ提示する。この保険診療には、診療報酬が定められている。診療報酬の一部は保険診療を受ける被保険者により医療機関へ支払われ、残りの診療報酬は保険者から医療機関へ支払われる。
【０００３】
このとき、医療機関から保険者へ提出される書類をレセプトという。レセプトは、医療機関で保険診療を受けたときの被保険者の自己負担分外の料金を医療機関が保険者へ請求するための診療報酬明細書である。一般的にレセプトは１ヶ月単位で患者ごとの診療内容を入院や外来、医療保険別に分けて規定にフォーマットにとりまとめたものである。
【０００４】
レセプトの審査は、都道府県や診療科等の単位で予め定められた審査機関が実施する。この審査機関において、レセプトに記載された診療内容が妥当でないと判断された場合、レセプトの要求通りの診療報酬の支払が拒否されて、減点・減額される場合がある。このため、審査機関へレセプトを提出する前に、医療機関においてレセプトの記載内容を点検する必要がある。以下の特許文献１では、レセプトの点検作業にかかる負担を軽減するための技術が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−１９３１３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで審査機関においてレセプトを審査する審査者は医師等であり、レセプトの記載内容が許容されるか否かは、審査者の主観的判断に委ねられている面がある。したがって、予め定められた点検ロジックにもとづく機械的なレセプト点検では不十分な場合があると本発明者は考えた。
【０００７】
本発明は発明者の上記着想に鑑みてなされたものであり、その目的は、医療機関におけるレセプト点検の精度向上を支援する技術を提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明のある態様の医療事務支援装置は、医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する査定事例保持部と、医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける未審査レセプト受付部と、複数の査定事例のうち、患者への医療行為の内容が、未審査レセプトにおける記載内容と合致する査定事例を特定する検索部と、合致する査定事例の情報をユーザへ提供する査定事例提供部と、を備える。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、医療機関におけるレセプト点検の精度向上を支援することができる。
【図面の簡単な説明】
【００１１】
【図１】実施の形態の医療事務支援システムの構成を示す図である。
【図２】図１のＯＡ端末の機能構成を示すブロック図である。
【図３】レセプトに設定されるデータ項目を模式的に示す図である。
【図４】変換テーブルに格納されるデータ項目を模式的に示す図である。
【図５】匿名化されたレセプトのデータ項目を模式的に示す図である。
【図６】レセプト点検結果の表示例を示す図である。
【図７】再審査申出書のテンプレートを模式的に示すものである図である。
【図８】図１の医療事務支援装置の機能構成を示すブロック図である。
【図９】図１のＯＡ端末の動作を示すフローチャートである。
【図１０】図１のＯＡ端末の動作を示すフローチャートである。
【図１１】図１の医療事務支援装置の動作を示すフローチャートである。
【図１２】図１の医療事務支援装置の動作を示すフローチャートである。
【発明を実施するための形態】
【００１２】
図１は、実施の形態の医療事務支援システムの構成を示す。医療事務支援システム１００は、病院や診療所等の医療機関に設置されたＯＡ端末１２と、医療機関の外部に設置された医療事務支援装置１４を備える。ＯＡ端末１２は、ウェブブラウザや各種のオフィスソフトウェアがインストールされた一般的なＰＣであり、医療機関における医療事務の担当者（医師を含む）により操作される。医療事務支援装置１４は、複数の医療機関のそれぞれに設置されたＯＡ端末１２と接続され、レセプトのチェック作業を支援するための情報をＯＡ端末１２へ提供することにより、各医療機関における医療事務の効率化を支援する情報処理装置である。ＯＡ端末１２と医療事務支援装置１４は、ＬＡＮ・ＷＡＮ・インターネット等を含む通信網１６を介して接続される。
【００１３】
医療機関には、ＯＡ端末１２とともに、レセプトを管理するレセプトコンピュータ（以下、「レセコン１０」とも呼ぶ。）が設置される。医療機関で作成されたレセプトは、定期的に健康保険組合等のレセプトの審査機関へ送付される。そして、審査機関における審査においてレセプトでの要求通りの診療報酬の支払が拒否された場合、増減点並びに返戻通知書（以下、「査定通知書」とも呼ぶ。）が審査機関から医療機関へ送付される。
【００１４】
図２は、図１のＯＡ端末１２の機能構成を示すブロック図である。ＯＡ端末１２は、ロジックテーブル６０と、変換テーブル６２と、未審査レセプト取得部６４と、ロジック点検部６６と、匿名化部６８と、未審査レセプト送信部７０と、事例情報取得部７２と、顕名化部７４と、事例情報表示制御部７６と、拒絶レセプト取得部７８と、拒絶レセプト送信部８０と、申出書取得部８２と、申出書表示制御部８４を備える。
【００１５】
本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図２の各機能ブロックは、ソフトウェアとして記録媒体に格納され、ＯＡ端末１２のハードディスクにインストールされ、ＯＡ端末１２のメインメモリに適宜読み出されてＣＰＵにて実行されてもよい。後述の図８についても同様である。
【００１６】
未審査レセプト取得部６４は、医療機関から審査機関へ送付される前のレセプト、言い換えれば、審査機関の審査により承認されるかもしくは拒否されるかが未確定のレセプト（以下、「未審査レセプト」とも呼ぶ。）を取得する。本実施の形態では、医療事務の担当者がレセコン１０に保持された未審査レセプトのデータをＵＳＢメモリへ書き出し、そのＵＳＢメモリをＯＡ端末１２へ装着する。未審査レセプト取得部６４は、ＵＳＢメモリに格納された未審査レセプトを検出して、そのデータを読み込む。
【００１７】
図３は、レセプトに設定されるデータ項目を模式的に示す。実際のレセプトに設定されるデータ項目は多岐に亘るが、実施の形態では説明の簡明化のため、一部の項目のみを示すこととする。図３の（ａ）のデータ項目と図３の（ｂ）のデータ項目は実際には１レコードとして連結されており、保険診療を受けた患者単位に設定される。
【００１８】
図２に戻り、ロジックテーブル６０は、レセプトの各データ項目の設定値や、複数のデータ項目の設定値の組み合わせが妥当か否かを点検するための点検ロジックを保持する記憶領域である。例えば、点検ロジックには、レセプトの医薬品名フィールドに設定される医薬品の適正な用法・用量を示すデータが含まれる。また、医薬品名やその用法・用量が、患者の年齢や疾病との組み合わせにおいて適応と認められる可能性が高い組み合わせを示すデータが含まれる。
【００１９】
ロジック点検部６６は、ロジックテーブル６０に格納された点検ロジックにしたがって、未審査レセプトの各データ項目の設定値が妥当なものか否かを点検するロジック点検処理を実行する。ロジック点検部６６は、ロジック点検処理の結果として、レセプトの各項目の設定値が、不適応と認定される可能性があるか否かを示すメッセージを出力する。ロジック点検処理の結果の具体例は、図６に関連して後述する。
【００２０】
変換テーブル６２は、複数の医療機関に亘って未審査レセプトの各レコード（各患者の未審査レセプト）を一意に識別するための識別情報であるユニークＩＤと、各患者の個人情報とを対応付けて保持する記憶領域である。図４は、変換テーブル６２に格納されるデータ項目を模式的に示す。同図で示すように、図３の（ａ）で示したレセプトの各項目がユニークＩＤと対応づけられる。
【００２１】
図２に戻り、匿名化部６８は、未審査レセプトのデータの匿名化処理、言い換えれば、患者の特定を困難にするための、患者の個人情報を削除もしくは抽象化する処理を実行する。具体的には、まず、未審査レセプトにおける患者のレコードごとにユニークＩＤを採番する。そして、図３の（ａ）で示したレセプトの各項目とユニークＩＤとを対応づけて変換テーブル６２へ格納する。
【００２２】
続いて匿名化部６８は、レセプトのデータ項目のうち、被保険者証記号／番号と、カルテ番号と、氏名を削除する。また、医療機関番号における都道府県コード以外を削除して都道府県コードのみとし、生年月日における生年以外を削除して生年のみとする。そして、このように匿名化したレセプトのデータをユニークＩＤと対応づけて未審査レセプト送信部７０に渡す。
【００２３】
図５は、匿名化されたレセプトのデータ項目を模式的に示す。図５の（ａ）のデータ項目と図５の（ｂ）のデータ項目もまた実際には１レコードである。同図で示すように、匿名化されたレセプトの各データは、ユニークＩＤと対応づけられる。また、未審査レセプトに対するロジック点検部６６によるロジック点検の結果が付加されている。
【００２４】
図２に戻り、未審査レセプト送信部７０は、匿名化された未審査レセプトのデータを医療事務支援装置１４へ送信する。詳細は後述するが、本実施の形態の医療事務支援装置１４は、ＯＡ端末１２から受け付けた匿名化された未審査レセプトのデータをもとに、医療事務支援装置１４に蓄積された査定事例を検索する。その検索処理が完了すると、医療事務支援装置１４は、その完了の旨を記載した電子メールをＯＡ端末１２へ送信する。この電子メールには、査定事例の検索結果を表示するウェブページへのハイパーリンクが設定されていてもよく、電子メールを確認した医療事務の担当者がそのハイパーリンクを選択した場合に、事例情報取得部７２が、査定事例検索結果の取得要求を検出してもよい。
【００２５】
事例情報取得部７２は、査定事例検索結果の取得要求を医療事務担当者から受け付けると、その取得要求を医療事務支援装置１４へ送信する。この取得要求では、未審査レセプト送信部７０により医療事務支援装置１４へ送信された未審査レセプトにおいて指定されたユニークＩＤが指定されてもよい。続いて事例情報取得部７２は、査定事例の検索結果のデータを医療事務支援装置１４から取得する。ここでの取得データは、図５の（ａ）および（ｂ）のデータに、査定事例の検索結果が付加されたものとし、以下では「レセプト点検結果」とも呼ぶ。図６に関して後述するが、レセプト点検結果における査定事例の検索結果には、同一事例における査定件数と査定割合、類似事例における査定件数と査定割合を示す情報が含まれる。
【００２６】
顕名化部７４は、変換テーブル６２を参照して、レセプト点検結果のユニークＩＤと対応づけられたデータ（図４の被保険者証記号／番号〜生年月日、すなわち予め変換テーブル６２へ待避された患者の個人情報）を取得して、レセプト点検結果を顕名化する。例えば、ユニークＩＤと対応づけられた被保険者証記号／番号、医療機関コード、カルテ番号、氏名、生年月日をレセプト点検結果に付加し、もしくは抽象化された医療機関コードや生年と置き換える。
【００２７】
事例情報表示制御部７６は、顕名化部７４により顕名化されたレセプト点検結果をディスプレイに表示させる。なお、レセプト点検結果のデータがウェブページとして提供される場合、事例情報表示制御部７６はウェブブラウザへウェブページを提供して、ウェブブラウザにレセプト点検結果を表示させてもよい。
【００２８】
図６は、レセプト点検結果の表示例を示す。同図の第１エリア９０には、レセプトの情報が表示される。第２エリア９２には、ロジック点検部６６によるロジック点検の結果が表示される。第３エリア９４には、医療事務支援装置１４による査定事例検索の結果が表示される。本実施の形態では、査定事例検索の結果として、同一事例（すなわちレセプトの生年、疾病名、診療行為名、医薬品名の設定値が同一の査定事例）と、類似事例（上記の設定値が同一ではないものの、類似すると想定される査定事例）のそれぞれについて、全国／県内、全科／同科の組み合わせごとの査定事例件数が件数フィールド９６にて提示される。また、全未審査レセプト件数に占める査定事例件数の割合が、割合フィールド９８にて提示される。
【００２９】
図２に戻り、拒絶レセプト取得部７８は、医療事務担当者により入力された、査定通知書に記載された情報、および、査定の対象となったレセプト（以下、「拒絶レセプト」とも呼ぶ。）に記載された情報を受け付ける。以下、これらの情報を総称して「査定情報」とも呼ぶ。査定情報を入力する際に医療事務担当者は、再審査を申立予定のレセプトを指定し、拒絶レセプト取得部７８は、指定されたレセプトの査定情報に対して、再審査予定フラグを設定する。
【００３０】
なお拒絶レセプト取得部７８は、医療事務担当者からの査定情報の入力要求を受け付けて、査定情報の入力画面をディスプレイに表示させてもよい。そして、医療事務担当者が入力した査定情報および再審査申立の指定を、その入力画面を介して取得してもよい。
【００３１】
拒絶レセプト送信部８０は、再審査予定フラグが適宜設定された査定情報を医療事務支援装置１４へ送信する。医療事務支援装置１４は、再審査申出書のテンプレートを設定完了すると、その完了の旨を記載した電子メールをＯＡ端末１２へ送信する。この電子メールには、再審査申出書のテンプレートを取得するためのウェブページへのハイパーリンクが設定されていてもよく、電子メールを確認した医療事務の担当者がそのハイパーリンクを選択した場合に、申出書取得部８２が再審査申出書のテンプレートの取得要求を検出してもよい。
【００３２】
申出書取得部８２は、再審査申出書のテンプレートの取得要求を医療事務担当者から受け付けると、その取得要求を医療事務支援装置１４へ送信する。この取得要求では再審査申出書のキーとして医療機関番号が指定されることとする。申出書取得部８２は、再審査申出書のテンプレートのデータを医療事務支援装置１４から取得する。このテンプレートのデータは、例えば、所定のワープロソフトで定められたデータ形式であってもよい。申出書表示制御部８４は、申出書取得部８２により取得された再審査申出書のテンプレートのデータを編集可能な状態でディスプレイに表示させる。
【００３３】
図７は、再審査申出書のテンプレートを模式的に示すものである。再審査申出書における第１エリア２００には、各記入項目に予め対応づけられた査定通知書の記載内容や、拒絶レセプトの記載内容が自動で設定される。その一方で、再審申出書における第２エリア２０２（すなわち再審理由欄）には、拒絶レセプトに対する査定事例検索の結果が設定される。
【００３４】
図８は、図１の医療事務支援装置１４の機能構成を示すブロック図である。医療事務支援装置１４は、未審査レセプトＤＢ２０と、査定事例ＤＢ２２と、検索結果ＤＢ２４と、申出書ＤＢ２６と、未審査レセプト受付部２８と、拒絶レセプト受付部３０と、検索部３２と、統計処理部４０と、検索結果記録部４２と、事例情報提供部４６と、申出書記録部４８と、申出書提供部５０とを備える。
【００３５】
未審査レセプトＤＢ（データベース）２０は、未審査レセプトを保持する記憶領域である。未審査レセプトのデータ構成は、図５の（ａ）および（ｂ）にて既述したとおりである。査定事例ＤＢ２２は、査定通知書および拒絶レセプトの記載内容を含む査定情報を査定事例として、複数の査定事例を保持する記憶領域である。査定通知書のデータは査定理由等を含むものであり、拒絶レセプトのデータ構成は、図３の（ａ）および（ｂ）で既述したとおりである。検索結果ＤＢ２４は、検索部３２による事例検索結果のデータを保持する記憶領域である。申出書ＤＢ２６は、申出書記録部４８により設定された再審査申出書のデータを保持する記憶領域である。
【００３６】
未審査レセプト受付部２８は、医療機関のＯＡ端末１２から送信された未審査レセプトのデータを受け付けて未審査レセプトＤＢ２０へ格納する。拒絶レセプト受付部３０は、医療機関のＯＡ端末１２から送信された査定情報を受け付けて査定事例ＤＢ２２へ格納する。
【００３７】
検索部３２は、未審査レセプト受付部２８において未審査レセプトが受け付けられた場合、その未審査レセプトに記載された医療行為の内容を検索キーとして査定事例を検索する。また検索部３２は、拒絶レセプト受付部３０において査定情報が受け付けられて、その査定情報に再審査予定フラグが設定されている場合、その査定情報に記載された医療行為の内容を検索キーとして査定事例を検索する、検索部３２は、同一事例検索部３４と、類似条件テーブル３６と、類似事例検索部３８とを含む。以下では、事例検索の対象となる未審査レセプトおよび拒絶レセプトを適宜「検索条件レセプト」とも称する。
【００３８】
同一事例検索部３４は、査定事例ＤＢ２２に格納された査定事例のうち、検索条件レセプトに記載された患者の生年、性別、疾病名、診療行為名、医薬品名（用法、用量を含む）に合致する記載内容の査定事例を同一査定事例として特定する。変形例として、上記組み合わせの一部が合致する査定事例、例えば、疾病名、診療行為名、医薬品名の組み合わせが合致する査定事例を同一査定事例として特定してもよい。また同一事例検索部３４は、未審査レセプトＤＢ２０に格納された未審査レセプトのうち、記載内容（同一査定事例を特定する場合と同様の上記データ項目の内容）が検索条件レセプトと合致する未審査レセプトを同一未審査レセプトとして特定する。
【００３９】
類似条件テーブル３６は、検索条件レセプトの記載内容と査定事例の記載内容とが異なる場合であっても、双方の記載内容を類似するものとして判定すべき条件（以下、「類似判定条件」とも呼ぶ。）を保持する記憶領域である。この類似判定条件としては、類似したものとして予め想定される年齢の幅や、医薬品の用法・用量の幅が設定される。例えば、検索条件レセプトにおける生年が１９７５年の場合、生年１９７０年〜１９７４年、１９７６年〜１９８０年を類似範囲として設定されてもよい。また別の類似判定条件としては、先発医薬品（オリジナル薬、新薬とも呼ばれる）と後発医薬品（ジェネリック医薬品とも呼ばれる）との対応関係が設定される。
【００４０】
類似事例検索部３８は、医療行為の内容が検索条件レセプトと異なる査定事例のうち、類似条件テーブル３６に格納された類似判定条件に整合する査定事例を類似査定事例として特定する。例えば、検索条件レセプトの医薬品名フィールドに後発医薬品が記載されている場合、その後発医薬品に対応する先発医薬品が医薬品名フィールドに記載された査定事例を類似査定事例として特定する。その逆の場合も同様である。また類似事例検索部３８は、未審査レセプトＤＢ２０に格納された未審査レセプトのうち、医療行為の内容が検索条件レセプトと異なり、かつ、その差異が類似判定条件に整合する未審査レセプトを類似未審査レセプトとして特定する。
【００４１】
統計処理部４０は、同一事例検索部３４において特定された同一査定事例に対して、審査の属性を基準とした統計処理を実行する。本実施の形態では、都道府県および診療科ごとにレセプトの審査主体が異なることを前提として、審査主体の属性である都道府県および診療科ごとの同一査定事例件数を集計する。
【００４２】
具体的には、統計処理部４０は、同一査定事例の総数を全国・全科の同一査定事例件数として計数する。また、医療機関コードにおける都道府県コードが検索条件レセプトの記載内容と合致する同一査定事例の件数を、県内・全科の同一査定事例件数として計数する。また、診療科が検索条件レセプトの記載内容と合致する同一査定事例の件数を全国・同科の同一査定事例件数として計数する。また、医療機関コードにおける都道府県コードと診療科の両方が、検索条件レセプトの記載内容と合致する同一査定事例の件数を県内・同科の同一査定事例件数として計数する。
【００４３】
また統計処理部４０は、類似事例検索部３８において特定された類似査定事例に対しても、上記の同一査定事例の場合と同様に、審査の属性を基準とした統計処理を実行する。すなわち、類似査定事例の総数を全国・全科の類似査定事例件数として計数する。また、医療機関コードにおける都道府県コードが検索条件レセプトの記載内容と合致する類似査定事例の件数を、県内・全科の類似査定事例件数として計数する。また、診療科が検索条件レセプトの記載内容と合致する類似査定事例の件数を全国・同科の類似査定事例件数として計数する。また、医療機関コードにおける都道府県コードおよび診療科が、検索条件レセプトの記載内容と合致する類似査定事例の件数を県内・同科の類似査定事例件数として計数する。
【００４４】
また統計処理部４０は、同一事例検索部３４において特定された同一未審査レセプトに対して同一査定事例に対する統計処理と同様の統計処理を実行し、全国・全科の同一未審査レセプト件数、県内・全科の同一未審査レセプト件数、全国・同科の同一未審査レセプト件数、県内・同科の同一未審査レセプト件数のそれぞれを計数する。そして、全国・全科の同一未審査レセプト件数に占める全国・全科の同一査定事例件数の割合、県内・全科の同一未審査レセプト件数に占める県内・全科の同一査定事例件数の割合、全国・同科の同一未審査レセプト件数に占める全国・同科の同一査定事例件数の割合、県内・同科の同一未審査レセプト件数に占める県内・同科の同一査定事例件数の割合のそれぞれを計数する。
【００４５】
また統計処理部４０は、類似事例検索部３８において特定された類似未審査レセプトに対しても類似査定事例に対する統計処理と同様の統計処理を実行し、全国・全科の類似未審査レセプト件数、県内・全科の類似未審査レセプト件数、全国・同科の類似未審査レセプト件数、県内・同科の類似未審査レセプト件数のそれぞれを計数する。そして、全国・全科の類似未審査レセプト件数に占める全国・全科の類似査定事例件数の割合、県内・全科の類似未審査レセプト件数に占める県内・全科の類似査定事例件数の割合、全国・同科の類似未審査レセプト件数に占める全国・同科の類似査定事例件数の割合、県内・同科の類似未審査レセプト件数に占める県内・同科の類似査定事例件数の割合のそれぞれを計数する。
【００４６】
検索結果記録部４２は、未審査レセプト受付部２８において未審査レセプトが受け付けられ、検索部３２においてその未審査レセプトに対する事例検索処理が実行された場合、統計処理部４０における統計処理の結果を、その未審査レセプトのデータと対応づけて検索結果ＤＢ２４へ格納する。その際、検索結果記録部４２は、未審査レセプトの点検結果を参照可能（ダウンロード可能）である旨が記載された電子メールをＯＡ端末１２へ送信する。
【００４７】
事例情報提供部４６は、査定事例検索結果の取得要求をＯＡ端末１２から受け付ける。そして、その取得要求において指定されたユニークＩＤで特定される未審査レセプトのデータであり、統計処理部４０における統計処理の結果を含むデータを検索結果記録部４２から取得し、レセプト点検結果としてＯＡ端末１２へ送信する。すなわち、図６で示したレセプト点検結果の、第１エリア９０に表示させるべき未審査レセプトのデータ、第２エリア９２に表示させるべきロジック点検結果のデータ、第３エリア９４に表示させるべき査定事例検索結果のデータをＯＡ端末１２へ提供する。
【００４８】
申出書記録部４８は、拒絶レセプト受付部３０において査定情報が受け付けられ、検索部３２においてその査定情報に対する事例検索処理が実行された場合、統計処理部４０における統計処理の結果を含む再審査申出書の文書データを申出書ＤＢ２６へ格納する。その際、申出書記録部４８は、再審査申出書を参照可能（ダウンロード可能）である旨が記載された電子メールをＯＡ端末１２へ送信する。
【００４９】
具体的には、申出書記録部４８は、図７で示した再審査申出書における第１エリア２００の各記載項目と、査定情報に含まれる査定通知書および拒絶レセプトの各記載内容との対応関係を予め保持する。再審査申出書設定時にはその対応関係を参照して、第１エリア２００の各記載項目に対して、査定通知書および拒絶レセプトの各記載内容を設定する。
【００５０】
また申出書記録部４８は、再審者申出書における第２エリア２０２に対して、統計処理部４０における統計処理の結果を設定する。図７で示したように本実施の形態では、全国・全科の同一未審査レセプト件数、県内・全科の同一未審査レセプト件数、全国・同科の同一未審査レセプト件数、県内・同科の同一未審査レセプト件数と、それぞれに対応する同一査定事例件数を第２エリア２０２へ設定する。変形例として、査定事例検索結果と同様に、査定の割合を設定してもよいし、類似未審査レセプト件数および類似査定事例件数をさらに設定してもよい。
【００５１】
申出書提供部５０は、再審査申出書のテンプレートの取得要求をＯＡ端末１２から受け付ける。そして、その取得要求で指定された医療機関番号により特定される再審査申出書、言い換えれば、取得要求で指定された医療機関番号が設定された再審査申出書の文書データを申出書ＤＢ２６から取得し、再審査申出書のテンプレートとしてＯＡ端末１２へ送信する。
【００５２】
以上の構成による動作を以下説明する。
図９は、図１のＯＡ端末１２の動作を示すフローチャートである。ＯＡ端末１２の未審査レセプト取得部６４は、接続されたＵＳＢメモリ内に未審査レセプトが格納されていることを検出すると（Ｓ１０のＹ）、その未審査レセプトを読み込む。ロジック点検部６６は、未審査レセプトに対するロジック点検処理を実行する（Ｓ１２）。匿名化部６８は、未審査レセプトにおける患者の個人情報に関する所定のデータ項目に対して匿名化処理を実行する（Ｓ１４）。未審査レセプト送信部７０は、匿名化された未審査レセプトのデータを医療事務支援装置１４へアップロードする（Ｓ１６）。未審査レセプトが未検出であれば（Ｓ１０のＮ）、Ｓ１２〜Ｓ１６はスキップされる。
【００５３】
事例情報取得部７２は、医療事務担当者から入力された未審査レセプトの点検結果の表示要求を検出すると（Ｓ１８のＹ）、未審査レセプトの点検結果（ロジック点検結果および事例検索結果）を示すデータを医療事務支援装置１４から取得する（Ｓ２０）。顕名化部７４は、変換テーブル６２から患者の個人情報を読み出して、点検結果のデータの顕名化処理を実行する（Ｓ２２）。事例情報表示制御部７６は、顕名化された未審査レセプトの点検結果をディスプレイに表示させる（Ｓ２４）。未審査レセプトの点検結果の表示要求が未検出であれば（Ｓ１８のＮ）、Ｓ２０〜Ｓ２４はスキップされる。
【００５４】
図１０も、図１のＯＡ端末１２の動作を示すフローチャートである。ＯＡ端末１２の拒絶レセプト取得部７８は、医療事務担当者から入力された査定情報を検出し（Ｓ３０のＹ）、再審査の指定がなされた場合（Ｓ３２のＹ）、再審査予定フラグを査定情報のデータに設定する（Ｓ３４）。再審査の指定がなければ（Ｓ３２のＮ）、Ｓ３４はスキップされる。拒絶レセプト送信部８０は、査定情報を医療事務支援装置１４へ送信する（Ｓ３６）。査定情報の入力が未検出であれば（Ｓ３０のＮ）、Ｓ３２〜Ｓ３６はスキップされる。申出書取得部８２は、医療事務担当者から入力された再審査申出書の表示要求を検出すると（Ｓ３８のＹ）、申出書取得部８２は再審査申出書の文書データを医療事務支援装置１４から取得し（Ｓ４０）、申出書表示制御部８４はそのデータを、編集可能な再審査申出書のテンプレートとしてディスプレイに表示させる（Ｓ４２）。再審査申出書の表示要求が未検出であれば（Ｓ３８のＮ）、Ｓ４０およびＳ４２はスキップされる。
【００５５】
図１１は、図１の医療事務支援装置１４の動作を示すフローチャートである。医療事務支援装置１４の未審査レセプト受付部２８は、ＯＡ端末１２から未審査レセプトを受け付けると（Ｓ５０のＹ）、その未審査レセプトのデータを未審査レセプトＤＢ２０へ格納する（Ｓ５２）。検索部３２は、未審査レセプトに記載された患者への医療行為の内容を検索キーとして査定事例ＤＢ２２の査定事例を検索し、未審査レセプトの記載内容に対して合致もしくは類似する査定事例を特定する（Ｓ５４）。統計処理部４０は、査定事例検索の結果を審査属性単位（具体的には地域別および診療科別に）集計し（Ｓ５６）、検索結果記録部４２は、集計結果を検索結果ＤＢ２４へ格納する（Ｓ５８）。未審査レセプトを受け付けなければ（Ｓ５０のＮ）、Ｓ５２〜Ｓ５８はスキップされる。
【００５６】
続いて事例情報提供部４６は、未審査レセプトの点検結果の取得要求をＯＡ端末１２から受け付けると（Ｓ６０のＹ）、ロジック点検結果および事例検索結果を含む点検結果のデータを検索結果ＤＢ２４から取得してＯＡ端末１２へ送信する（Ｓ６２）。未審査レセプトの点検結果の取得要求を受け付けなければ（Ｓ６０のＮ）、Ｓ６２はスキップされる。
【００５７】
図１２も、図１の医療事務支援装置１４の動作を示すフローチャートである。医療事務支援装置１４の拒絶レセプト受付部３０は、ＯＡ端末１２から査定情報を受け付けると（Ｓ７０のＹ）、その査定情報を査定事例ＤＢ２２へ格納する（Ｓ７２）。査定情報に再審査予定フラグが設定されている場合（Ｓ７４のＹ）、検索部３２は、査定情報における拒絶レセプトに記載された患者への医療行為の内容を検索キーとして査定事例ＤＢ２２の査定事例を検索し、拒絶レセプトの記載内容に対して合致もしくは類似する査定事例を特定する（Ｓ７６）。統計処理部４０は、査定事例検索の結果を審査属性単位（具体的には地域別および診療科別に）集計する（Ｓ７８）。申出書記録部４８は、集計結果を再審理由欄に設定した再審査申出書の文書データを申出書ＤＢ２６へ格納する（Ｓ８０）。再審査予定フラグが未設定であれば（Ｓ７４のＮ）、Ｓ７６〜Ｓ８０はスキップされ、査定情報を受け付けなければ（Ｓ７０のＮ）、Ｓ７２〜Ｓ８０はスキップされる。
【００５８】
続いて申出書提供部５０は、再審査申出書の取得要求をＯＡ端末１２から受け付けると（Ｓ８２のＹ）、再審査申出書のデータを申出書ＤＢ２６から取得してＯＡ端末１２へ送信する（Ｓ８４）。再審査申出書の取得要求を受け付けなければ（Ｓ８２のＮ）、Ｓ８４はスキップされる。
【００５９】
本実施の形態の医療事務支援システム１００によれば、医療事務支援装置１４においてレセプトの査定事例を蓄積し、未審査レセプトと記載内容が同一・類似の査定事例について、その件数および未審査レセプト数に占める査定件数の割合を医療事務担当者へ提示する。これにより、現状のレセプトの記載が査定されやすいものか否かを示唆することができ、医療事務担当者は、未審査レセプトの記載内容が、審査により拒絶されるリスクの程度を過去の事例を踏まえて判断し、その内容を適宜修正することができる。レセプトの審査結果は、審査者の主観に左右されるものであるところ、医療事務支援システム１００によれば、点検ロジックによる静的なチェックだけでなく、合致もしくは類似する記載内容での査定状況を医療事務担当者に提示することで、未審査レセプトの点検作業における精度向上を支援することができる。
【００６０】
本実施の形態では、未審査レセプトと記載内容が同一のみならず類似の査定事例も検索して、その検索結果を提供することにより、未審査レセプトの点検作業における精度を一層向上させることができる。例えば、図６の検索結果の第２レコードは、同一査定事例は０件であるものの、類似査定事例は多数存在することを示しており、未審査レセプトの現在の記載内容は不適応と認定されてしまうリスクが高いことを医療事務担当者は把握できる。より具体的には、未審査レセプトにおいて後発医薬品名が記載されていた場合に、後発医薬品と同一視が可能な先発医薬品名が記載された査定事例を把握することができる。
【００６１】
また医療事務支援システム１００によれば、医療事務支援装置１４において検索条件レセプトの審査属性（地域や診療科）に合致する査定事例については他の査定事例と区別して集計して、査定件数や査定割合を医療事務担当者へ提示する。これにより、地域や診療科ごとの審査傾向を医療事務担当者が把握することを容易にし、その傾向に応じて適宜修正を行うことを支援できる。例えば、医療事務担当者は、図６のレセプト点検結果の第１レコードを確認した場合、レセプトの現在の記載は全国的には査定されてしまうリスクが高いが、県内では査定されるリスクが低いため、現状の記載を維持してよいと等の判断ができる。
【００６２】
また医療事務支援システム１００によれば、図７で示した再審査申出書における第１エリア２００の各項目には、各項目に対応づけられた査定通知書の記載内容や、拒絶レセプトの記載内容が自動で設定される。その一方で、再審申出書における第２エリア２０２、すなわち再審理由欄には、拒絶レセプトに対する査定事例検索の結果が設定される。例えば医師は、再審理由欄の査定事例件数を考慮して再審の有無を判断でき、また、再審理由の１つとして査定事例件数を容易に引用できる。また、第１エリア２００にて記載すべき項目の多くが自動で設定されるため、再審査申出書の作成の負担を低減することができる。
【００６３】
また医療事務支援システム１００によれば、未審査レセプトに記載された患者の個人情報はＯＡ端末１２内に保持されて、医療事務支援装置１４に渡される未審査レセプトは匿名化されたものとなる。これにより、患者の個人情報の拡散を回避し、また漏洩のリスクを低減することができる。
【００６４】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００６５】
第１の変形例を説明する。上記実施の形態では、未審査レセプトの点検結果の画面には同一査定事例の件数および類似査定事例の件数を表示させることとした。変形例としては、医療事務担当者が同一査定事例の表示欄に設けられた所定オブジェクト（件数の表示文字列でもよい）を選択した場合に、同一査定事例の内容をＯＡ端末１２のディスプレイに表示させてもよい。同様に、医療事務担当者が類似査定事例の表示欄に設けられた所定オブジェクトを選択した場合に、類似査定事例の内容をＯＡ端末１２のディスプレイに表示させてもよい。
【００６６】
ここでは、類似査定事例の記載内容を提示する場合の構成例を示すが、同一査定事例の記載内容を提示する場合も同様の構成にて実現できることはもちろんである。
医療事務支援装置１４の検索結果記録部４２は、統計処理部４０により集計された類似査定事例件数（地域・診療科別）を示す文字列に対して、集計対象となった類似査定事例のデータの識別情報（ＵＲＬ等）を指定したハイパーリンクを設定してもよい。医療事務担当者によりそのハイパーリンクが選択されたことを検出すると、事例情報提供部４６は、類似査定事例の識別情報を指定してその取得要求を医療事務支援装置１４へ送信することにより、類似査定事例の記載内容を示すデータを取得して表示させてもよい。
【００６７】
この変形例によると、同一査定事例や類似査定事例の実際の内容を医療事務担当者へ提示することができ、未審査レセプトの点検作業における精度向上を一層支援することができる。特に類似査定事例は、その記載内容が未審査レセプトと異なるものであるため、その記載内容を医療事務担当者へ提示することは好適な態様である。
【００６８】
第２の変形例を説明する。上記実施の形態では、類似判定条件として、レセプトの各データ項目の設定値の幅や、先発医薬品と後発医薬品との対応関係について言及した。変形例としては、査定（減点等）の要素が複数ある場合に、特に査定される確率と強い正の相関（例えば、相関係数＝０．７から１）を示す要素の組み合わせが類似判定条件として予め定められてもよい。
【００６９】
例えば、「この患者は６５歳と高齢なので、病名Ａに対して医薬品Ｂは不適応」という査定理由等、病名Ａと医薬品Ｂの組み合わせがレセプト内に存在すると査定される確率が高いという統計データがあるケースを考える。このケースにおいて医療事務支援装置１４の類似条件テーブル３６は、病名Ａと医薬品Ｂの組み合わせを類似判定条件として保持してもよい。類似事例検索部３８は、病名Ａと医薬品Ｂの組み合わせのある全てのレセプトを、他の記載内容の差異にかかわらず類似査定事例として特定してもよい。
【００７０】
第３の変形例を説明する。上記実施の形態では、ＯＡ端末１２は、所定の記録媒体（ＵＳＢメモリ）を介してレセコン１０における未審査レセプトのデータを読み込むこととしたが、レセコン１０とＯＡ端末１２とはオンラインで接続されてもよいことはもちろんである。また、医療機関から医療事務支援装置１４への査定情報の通知においては、査定通知書と拒絶レセプトの書類を、医療機関から医療事務支援装置１４の管理者（システム管理会社等）へ送付してもよい。この場合、管理者側では査定通知書と拒絶レセプトの内容をＯＣＲ（Optical Character Reader）装置にて読取り、その文字データを医療事務支援装置１４の拒絶レセプト受付部３０が受け付けてもよい。
【００７１】
第４の変形例を説明する。上記実施の形態では、未審査レセプトに対するロジック点検処理をＯＡ端末１２で実行することとしたが、このロジック点検処理が医療事務支援装置１４で実行されてもよいことはもちろんである。この場合、医療事務支援装置１４は、図２で説明したロジックテーブル６０およびロジック点検部６６をさらに備え、そのロジック点検部６６は事例検索の前もしくは後に、ＯＡ端末１２にて匿名化済の未審査レセプトに対するロジック点検処理を実行する。
【００７２】
第５の変形例を説明する。未審査レセプトに対する査定事例検索結果の精度を高めるために査定事例の蓄積は不可欠であるところ、未審査レセプトの点検は行いたいが、査定情報は提供したくないと考える医療機関もあると想定される。医療事務支援装置１４の査定事例検索結果の精度を低下させてしまうため望ましい状況ではない。そこで、上記実施の形態では言及していないが、査定情報を提供しない医療機関に対して、未審査レセプトの点検における一種の制限を課してもよい。具体的には、医療事務支援装置１４は、医療機関から査定情報が提供された年月（２０１１年１月、２月等）を保持し、検索部３２は、その提供年月以前の査定情報を検索対象の母集団としてもよい。この結果、査定情報の提供を停止した医療機関に対しては、新しい査定事例を反映しない査定事例検索結果が提供されることになり、積極的な査定事例の提供を医療機関に促すことができる。
【００７３】
上述した実施の形態、変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態、変形例それぞれの効果をあわせもつ。
【００７４】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【００７５】
なお、請求項３に記載の内容は以下のように具体化することもできる。すなわち、類似条件保持部は、先発医薬品と後発医薬品との対応関係を保持し、検索部は、複数の査定事例のうち、患者への医療行為の内容が前記未審査レセプトにおける記載内容と不一致であるものの、その不一致の内容が前記対応関係にて定められた先発医薬品と後発医薬品の違いである査定事例を類似事例として特定してもよい。
【符号の説明】
【００７６】
１０ レセコン、 １２ ＯＡ端末、 １４ 医療事務支援装置、 ２０ 未審査レセプトＤＢ、 ２２ 査定事例ＤＢ、 ２４ 検索結果ＤＢ、 ２６ 申出書ＤＢ、 ２８ 未審査レセプト受付部、 ３０ 拒絶レセプト受付部、 ３２ 検索部、 ３４ 同一事例検索部、 ３６ 類似条件テーブル、 ３８ 類似事例検索部、 ４０ 統計処理部、 ４２ 検索結果記録部、 ４６ 事例情報提供部、 ４８ 申出書記録部、 ５０ 申出書提供部、 １００ 医療事務支援システム。
【技術分野】
【０００１】
本発明はデータ処理技術に関し、特に、医療機関における事務作業を支援するための技術に関する。
【背景技術】
【０００２】
健康保険を利用して医療を受ける保険診療では、被保険者（患者）が保険者（健康保険組合等）から発行された被保険者証を医療機関へ提示する。この保険診療には、診療報酬が定められている。診療報酬の一部は保険診療を受ける被保険者により医療機関へ支払われ、残りの診療報酬は保険者から医療機関へ支払われる。
【０００３】
このとき、医療機関から保険者へ提出される書類をレセプトという。レセプトは、医療機関で保険診療を受けたときの被保険者の自己負担分外の料金を医療機関が保険者へ請求するための診療報酬明細書である。一般的にレセプトは１ヶ月単位で患者ごとの診療内容を入院や外来、医療保険別に分けて規定にフォーマットにとりまとめたものである。
【０００４】
レセプトの審査は、都道府県や診療科等の単位で予め定められた審査機関が実施する。この審査機関において、レセプトに記載された診療内容が妥当でないと判断された場合、レセプトの要求通りの診療報酬の支払が拒否されて、減点・減額される場合がある。このため、審査機関へレセプトを提出する前に、医療機関においてレセプトの記載内容を点検する必要がある。以下の特許文献１では、レセプトの点検作業にかかる負担を軽減するための技術が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−１９３１３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで審査機関においてレセプトを審査する審査者は医師等であり、レセプトの記載内容が許容されるか否かは、審査者の主観的判断に委ねられている面がある。したがって、予め定められた点検ロジックにもとづく機械的なレセプト点検では不十分な場合があると本発明者は考えた。
【０００７】
本発明は発明者の上記着想に鑑みてなされたものであり、その目的は、医療機関におけるレセプト点検の精度向上を支援する技術を提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明のある態様の医療事務支援装置は、医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する査定事例保持部と、医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける未審査レセプト受付部と、複数の査定事例のうち、患者への医療行為の内容が、未審査レセプトにおける記載内容と合致する査定事例を特定する検索部と、合致する査定事例の情報をユーザへ提供する査定事例提供部と、を備える。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、医療機関におけるレセプト点検の精度向上を支援することができる。
【図面の簡単な説明】
【００１１】
【図１】実施の形態の医療事務支援システムの構成を示す図である。
【図２】図１のＯＡ端末の機能構成を示すブロック図である。
【図３】レセプトに設定されるデータ項目を模式的に示す図である。
【図４】変換テーブルに格納されるデータ項目を模式的に示す図である。
【図５】匿名化されたレセプトのデータ項目を模式的に示す図である。
【図６】レセプト点検結果の表示例を示す図である。
【図７】再審査申出書のテンプレートを模式的に示すものである図である。
【図８】図１の医療事務支援装置の機能構成を示すブロック図である。
【図９】図１のＯＡ端末の動作を示すフローチャートである。
【図１０】図１のＯＡ端末の動作を示すフローチャートである。
【図１１】図１の医療事務支援装置の動作を示すフローチャートである。
【図１２】図１の医療事務支援装置の動作を示すフローチャートである。
【発明を実施するための形態】
【００１２】
図１は、実施の形態の医療事務支援システムの構成を示す。医療事務支援システム１００は、病院や診療所等の医療機関に設置されたＯＡ端末１２と、医療機関の外部に設置された医療事務支援装置１４を備える。ＯＡ端末１２は、ウェブブラウザや各種のオフィスソフトウェアがインストールされた一般的なＰＣであり、医療機関における医療事務の担当者（医師を含む）により操作される。医療事務支援装置１４は、複数の医療機関のそれぞれに設置されたＯＡ端末１２と接続され、レセプトのチェック作業を支援するための情報をＯＡ端末１２へ提供することにより、各医療機関における医療事務の効率化を支援する情報処理装置である。ＯＡ端末１２と医療事務支援装置１４は、ＬＡＮ・ＷＡＮ・インターネット等を含む通信網１６を介して接続される。
【００１３】
医療機関には、ＯＡ端末１２とともに、レセプトを管理するレセプトコンピュータ（以下、「レセコン１０」とも呼ぶ。）が設置される。医療機関で作成されたレセプトは、定期的に健康保険組合等のレセプトの審査機関へ送付される。そして、審査機関における審査においてレセプトでの要求通りの診療報酬の支払が拒否された場合、増減点並びに返戻通知書（以下、「査定通知書」とも呼ぶ。）が審査機関から医療機関へ送付される。
【００１４】
図２は、図１のＯＡ端末１２の機能構成を示すブロック図である。ＯＡ端末１２は、ロジックテーブル６０と、変換テーブル６２と、未審査レセプト取得部６４と、ロジック点検部６６と、匿名化部６８と、未審査レセプト送信部７０と、事例情報取得部７２と、顕名化部７４と、事例情報表示制御部７６と、拒絶レセプト取得部７８と、拒絶レセプト送信部８０と、申出書取得部８２と、申出書表示制御部８４を備える。
【００１５】
本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図２の各機能ブロックは、ソフトウェアとして記録媒体に格納され、ＯＡ端末１２のハードディスクにインストールされ、ＯＡ端末１２のメインメモリに適宜読み出されてＣＰＵにて実行されてもよい。後述の図８についても同様である。
【００１６】
未審査レセプト取得部６４は、医療機関から審査機関へ送付される前のレセプト、言い換えれば、審査機関の審査により承認されるかもしくは拒否されるかが未確定のレセプト（以下、「未審査レセプト」とも呼ぶ。）を取得する。本実施の形態では、医療事務の担当者がレセコン１０に保持された未審査レセプトのデータをＵＳＢメモリへ書き出し、そのＵＳＢメモリをＯＡ端末１２へ装着する。未審査レセプト取得部６４は、ＵＳＢメモリに格納された未審査レセプトを検出して、そのデータを読み込む。
【００１７】
図３は、レセプトに設定されるデータ項目を模式的に示す。実際のレセプトに設定されるデータ項目は多岐に亘るが、実施の形態では説明の簡明化のため、一部の項目のみを示すこととする。図３の（ａ）のデータ項目と図３の（ｂ）のデータ項目は実際には１レコードとして連結されており、保険診療を受けた患者単位に設定される。
【００１８】
図２に戻り、ロジックテーブル６０は、レセプトの各データ項目の設定値や、複数のデータ項目の設定値の組み合わせが妥当か否かを点検するための点検ロジックを保持する記憶領域である。例えば、点検ロジックには、レセプトの医薬品名フィールドに設定される医薬品の適正な用法・用量を示すデータが含まれる。また、医薬品名やその用法・用量が、患者の年齢や疾病との組み合わせにおいて適応と認められる可能性が高い組み合わせを示すデータが含まれる。
【００１９】
ロジック点検部６６は、ロジックテーブル６０に格納された点検ロジックにしたがって、未審査レセプトの各データ項目の設定値が妥当なものか否かを点検するロジック点検処理を実行する。ロジック点検部６６は、ロジック点検処理の結果として、レセプトの各項目の設定値が、不適応と認定される可能性があるか否かを示すメッセージを出力する。ロジック点検処理の結果の具体例は、図６に関連して後述する。
【００２０】
変換テーブル６２は、複数の医療機関に亘って未審査レセプトの各レコード（各患者の未審査レセプト）を一意に識別するための識別情報であるユニークＩＤと、各患者の個人情報とを対応付けて保持する記憶領域である。図４は、変換テーブル６２に格納されるデータ項目を模式的に示す。同図で示すように、図３の（ａ）で示したレセプトの各項目がユニークＩＤと対応づけられる。
【００２１】
図２に戻り、匿名化部６８は、未審査レセプトのデータの匿名化処理、言い換えれば、患者の特定を困難にするための、患者の個人情報を削除もしくは抽象化する処理を実行する。具体的には、まず、未審査レセプトにおける患者のレコードごとにユニークＩＤを採番する。そして、図３の（ａ）で示したレセプトの各項目とユニークＩＤとを対応づけて変換テーブル６２へ格納する。
【００２２】
続いて匿名化部６８は、レセプトのデータ項目のうち、被保険者証記号／番号と、カルテ番号と、氏名を削除する。また、医療機関番号における都道府県コード以外を削除して都道府県コードのみとし、生年月日における生年以外を削除して生年のみとする。そして、このように匿名化したレセプトのデータをユニークＩＤと対応づけて未審査レセプト送信部７０に渡す。
【００２３】
図５は、匿名化されたレセプトのデータ項目を模式的に示す。図５の（ａ）のデータ項目と図５の（ｂ）のデータ項目もまた実際には１レコードである。同図で示すように、匿名化されたレセプトの各データは、ユニークＩＤと対応づけられる。また、未審査レセプトに対するロジック点検部６６によるロジック点検の結果が付加されている。
【００２４】
図２に戻り、未審査レセプト送信部７０は、匿名化された未審査レセプトのデータを医療事務支援装置１４へ送信する。詳細は後述するが、本実施の形態の医療事務支援装置１４は、ＯＡ端末１２から受け付けた匿名化された未審査レセプトのデータをもとに、医療事務支援装置１４に蓄積された査定事例を検索する。その検索処理が完了すると、医療事務支援装置１４は、その完了の旨を記載した電子メールをＯＡ端末１２へ送信する。この電子メールには、査定事例の検索結果を表示するウェブページへのハイパーリンクが設定されていてもよく、電子メールを確認した医療事務の担当者がそのハイパーリンクを選択した場合に、事例情報取得部７２が、査定事例検索結果の取得要求を検出してもよい。
【００２５】
事例情報取得部７２は、査定事例検索結果の取得要求を医療事務担当者から受け付けると、その取得要求を医療事務支援装置１４へ送信する。この取得要求では、未審査レセプト送信部７０により医療事務支援装置１４へ送信された未審査レセプトにおいて指定されたユニークＩＤが指定されてもよい。続いて事例情報取得部７２は、査定事例の検索結果のデータを医療事務支援装置１４から取得する。ここでの取得データは、図５の（ａ）および（ｂ）のデータに、査定事例の検索結果が付加されたものとし、以下では「レセプト点検結果」とも呼ぶ。図６に関して後述するが、レセプト点検結果における査定事例の検索結果には、同一事例における査定件数と査定割合、類似事例における査定件数と査定割合を示す情報が含まれる。
【００２６】
顕名化部７４は、変換テーブル６２を参照して、レセプト点検結果のユニークＩＤと対応づけられたデータ（図４の被保険者証記号／番号〜生年月日、すなわち予め変換テーブル６２へ待避された患者の個人情報）を取得して、レセプト点検結果を顕名化する。例えば、ユニークＩＤと対応づけられた被保険者証記号／番号、医療機関コード、カルテ番号、氏名、生年月日をレセプト点検結果に付加し、もしくは抽象化された医療機関コードや生年と置き換える。
【００２７】
事例情報表示制御部７６は、顕名化部７４により顕名化されたレセプト点検結果をディスプレイに表示させる。なお、レセプト点検結果のデータがウェブページとして提供される場合、事例情報表示制御部７６はウェブブラウザへウェブページを提供して、ウェブブラウザにレセプト点検結果を表示させてもよい。
【００２８】
図６は、レセプト点検結果の表示例を示す。同図の第１エリア９０には、レセプトの情報が表示される。第２エリア９２には、ロジック点検部６６によるロジック点検の結果が表示される。第３エリア９４には、医療事務支援装置１４による査定事例検索の結果が表示される。本実施の形態では、査定事例検索の結果として、同一事例（すなわちレセプトの生年、疾病名、診療行為名、医薬品名の設定値が同一の査定事例）と、類似事例（上記の設定値が同一ではないものの、類似すると想定される査定事例）のそれぞれについて、全国／県内、全科／同科の組み合わせごとの査定事例件数が件数フィールド９６にて提示される。また、全未審査レセプト件数に占める査定事例件数の割合が、割合フィールド９８にて提示される。
【００２９】
図２に戻り、拒絶レセプト取得部７８は、医療事務担当者により入力された、査定通知書に記載された情報、および、査定の対象となったレセプト（以下、「拒絶レセプト」とも呼ぶ。）に記載された情報を受け付ける。以下、これらの情報を総称して「査定情報」とも呼ぶ。査定情報を入力する際に医療事務担当者は、再審査を申立予定のレセプトを指定し、拒絶レセプト取得部７８は、指定されたレセプトの査定情報に対して、再審査予定フラグを設定する。
【００３０】
なお拒絶レセプト取得部７８は、医療事務担当者からの査定情報の入力要求を受け付けて、査定情報の入力画面をディスプレイに表示させてもよい。そして、医療事務担当者が入力した査定情報および再審査申立の指定を、その入力画面を介して取得してもよい。
【００３１】
拒絶レセプト送信部８０は、再審査予定フラグが適宜設定された査定情報を医療事務支援装置１４へ送信する。医療事務支援装置１４は、再審査申出書のテンプレートを設定完了すると、その完了の旨を記載した電子メールをＯＡ端末１２へ送信する。この電子メールには、再審査申出書のテンプレートを取得するためのウェブページへのハイパーリンクが設定されていてもよく、電子メールを確認した医療事務の担当者がそのハイパーリンクを選択した場合に、申出書取得部８２が再審査申出書のテンプレートの取得要求を検出してもよい。
【００３２】
申出書取得部８２は、再審査申出書のテンプレートの取得要求を医療事務担当者から受け付けると、その取得要求を医療事務支援装置１４へ送信する。この取得要求では再審査申出書のキーとして医療機関番号が指定されることとする。申出書取得部８２は、再審査申出書のテンプレートのデータを医療事務支援装置１４から取得する。このテンプレートのデータは、例えば、所定のワープロソフトで定められたデータ形式であってもよい。申出書表示制御部８４は、申出書取得部８２により取得された再審査申出書のテンプレートのデータを編集可能な状態でディスプレイに表示させる。
【００３３】
図７は、再審査申出書のテンプレートを模式的に示すものである。再審査申出書における第１エリア２００には、各記入項目に予め対応づけられた査定通知書の記載内容や、拒絶レセプトの記載内容が自動で設定される。その一方で、再審申出書における第２エリア２０２（すなわち再審理由欄）には、拒絶レセプトに対する査定事例検索の結果が設定される。
【００３４】
図８は、図１の医療事務支援装置１４の機能構成を示すブロック図である。医療事務支援装置１４は、未審査レセプトＤＢ２０と、査定事例ＤＢ２２と、検索結果ＤＢ２４と、申出書ＤＢ２６と、未審査レセプト受付部２８と、拒絶レセプト受付部３０と、検索部３２と、統計処理部４０と、検索結果記録部４２と、事例情報提供部４６と、申出書記録部４８と、申出書提供部５０とを備える。
【００３５】
未審査レセプトＤＢ（データベース）２０は、未審査レセプトを保持する記憶領域である。未審査レセプトのデータ構成は、図５の（ａ）および（ｂ）にて既述したとおりである。査定事例ＤＢ２２は、査定通知書および拒絶レセプトの記載内容を含む査定情報を査定事例として、複数の査定事例を保持する記憶領域である。査定通知書のデータは査定理由等を含むものであり、拒絶レセプトのデータ構成は、図３の（ａ）および（ｂ）で既述したとおりである。検索結果ＤＢ２４は、検索部３２による事例検索結果のデータを保持する記憶領域である。申出書ＤＢ２６は、申出書記録部４８により設定された再審査申出書のデータを保持する記憶領域である。
【００３６】
未審査レセプト受付部２８は、医療機関のＯＡ端末１２から送信された未審査レセプトのデータを受け付けて未審査レセプトＤＢ２０へ格納する。拒絶レセプト受付部３０は、医療機関のＯＡ端末１２から送信された査定情報を受け付けて査定事例ＤＢ２２へ格納する。
【００３７】
検索部３２は、未審査レセプト受付部２８において未審査レセプトが受け付けられた場合、その未審査レセプトに記載された医療行為の内容を検索キーとして査定事例を検索する。また検索部３２は、拒絶レセプト受付部３０において査定情報が受け付けられて、その査定情報に再審査予定フラグが設定されている場合、その査定情報に記載された医療行為の内容を検索キーとして査定事例を検索する、検索部３２は、同一事例検索部３４と、類似条件テーブル３６と、類似事例検索部３８とを含む。以下では、事例検索の対象となる未審査レセプトおよび拒絶レセプトを適宜「検索条件レセプト」とも称する。
【００３８】
同一事例検索部３４は、査定事例ＤＢ２２に格納された査定事例のうち、検索条件レセプトに記載された患者の生年、性別、疾病名、診療行為名、医薬品名（用法、用量を含む）に合致する記載内容の査定事例を同一査定事例として特定する。変形例として、上記組み合わせの一部が合致する査定事例、例えば、疾病名、診療行為名、医薬品名の組み合わせが合致する査定事例を同一査定事例として特定してもよい。また同一事例検索部３４は、未審査レセプトＤＢ２０に格納された未審査レセプトのうち、記載内容（同一査定事例を特定する場合と同様の上記データ項目の内容）が検索条件レセプトと合致する未審査レセプトを同一未審査レセプトとして特定する。
【００３９】
類似条件テーブル３６は、検索条件レセプトの記載内容と査定事例の記載内容とが異なる場合であっても、双方の記載内容を類似するものとして判定すべき条件（以下、「類似判定条件」とも呼ぶ。）を保持する記憶領域である。この類似判定条件としては、類似したものとして予め想定される年齢の幅や、医薬品の用法・用量の幅が設定される。例えば、検索条件レセプトにおける生年が１９７５年の場合、生年１９７０年〜１９７４年、１９７６年〜１９８０年を類似範囲として設定されてもよい。また別の類似判定条件としては、先発医薬品（オリジナル薬、新薬とも呼ばれる）と後発医薬品（ジェネリック医薬品とも呼ばれる）との対応関係が設定される。
【００４０】
類似事例検索部３８は、医療行為の内容が検索条件レセプトと異なる査定事例のうち、類似条件テーブル３６に格納された類似判定条件に整合する査定事例を類似査定事例として特定する。例えば、検索条件レセプトの医薬品名フィールドに後発医薬品が記載されている場合、その後発医薬品に対応する先発医薬品が医薬品名フィールドに記載された査定事例を類似査定事例として特定する。その逆の場合も同様である。また類似事例検索部３８は、未審査レセプトＤＢ２０に格納された未審査レセプトのうち、医療行為の内容が検索条件レセプトと異なり、かつ、その差異が類似判定条件に整合する未審査レセプトを類似未審査レセプトとして特定する。
【００４１】
統計処理部４０は、同一事例検索部３４において特定された同一査定事例に対して、審査の属性を基準とした統計処理を実行する。本実施の形態では、都道府県および診療科ごとにレセプトの審査主体が異なることを前提として、審査主体の属性である都道府県および診療科ごとの同一査定事例件数を集計する。
【００４２】
具体的には、統計処理部４０は、同一査定事例の総数を全国・全科の同一査定事例件数として計数する。また、医療機関コードにおける都道府県コードが検索条件レセプトの記載内容と合致する同一査定事例の件数を、県内・全科の同一査定事例件数として計数する。また、診療科が検索条件レセプトの記載内容と合致する同一査定事例の件数を全国・同科の同一査定事例件数として計数する。また、医療機関コードにおける都道府県コードと診療科の両方が、検索条件レセプトの記載内容と合致する同一査定事例の件数を県内・同科の同一査定事例件数として計数する。
【００４３】
また統計処理部４０は、類似事例検索部３８において特定された類似査定事例に対しても、上記の同一査定事例の場合と同様に、審査の属性を基準とした統計処理を実行する。すなわち、類似査定事例の総数を全国・全科の類似査定事例件数として計数する。また、医療機関コードにおける都道府県コードが検索条件レセプトの記載内容と合致する類似査定事例の件数を、県内・全科の類似査定事例件数として計数する。また、診療科が検索条件レセプトの記載内容と合致する類似査定事例の件数を全国・同科の類似査定事例件数として計数する。また、医療機関コードにおける都道府県コードおよび診療科が、検索条件レセプトの記載内容と合致する類似査定事例の件数を県内・同科の類似査定事例件数として計数する。
【００４４】
また統計処理部４０は、同一事例検索部３４において特定された同一未審査レセプトに対して同一査定事例に対する統計処理と同様の統計処理を実行し、全国・全科の同一未審査レセプト件数、県内・全科の同一未審査レセプト件数、全国・同科の同一未審査レセプト件数、県内・同科の同一未審査レセプト件数のそれぞれを計数する。そして、全国・全科の同一未審査レセプト件数に占める全国・全科の同一査定事例件数の割合、県内・全科の同一未審査レセプト件数に占める県内・全科の同一査定事例件数の割合、全国・同科の同一未審査レセプト件数に占める全国・同科の同一査定事例件数の割合、県内・同科の同一未審査レセプト件数に占める県内・同科の同一査定事例件数の割合のそれぞれを計数する。
【００４５】
また統計処理部４０は、類似事例検索部３８において特定された類似未審査レセプトに対しても類似査定事例に対する統計処理と同様の統計処理を実行し、全国・全科の類似未審査レセプト件数、県内・全科の類似未審査レセプト件数、全国・同科の類似未審査レセプト件数、県内・同科の類似未審査レセプト件数のそれぞれを計数する。そして、全国・全科の類似未審査レセプト件数に占める全国・全科の類似査定事例件数の割合、県内・全科の類似未審査レセプト件数に占める県内・全科の類似査定事例件数の割合、全国・同科の類似未審査レセプト件数に占める全国・同科の類似査定事例件数の割合、県内・同科の類似未審査レセプト件数に占める県内・同科の類似査定事例件数の割合のそれぞれを計数する。
【００４６】
検索結果記録部４２は、未審査レセプト受付部２８において未審査レセプトが受け付けられ、検索部３２においてその未審査レセプトに対する事例検索処理が実行された場合、統計処理部４０における統計処理の結果を、その未審査レセプトのデータと対応づけて検索結果ＤＢ２４へ格納する。その際、検索結果記録部４２は、未審査レセプトの点検結果を参照可能（ダウンロード可能）である旨が記載された電子メールをＯＡ端末１２へ送信する。
【００４７】
事例情報提供部４６は、査定事例検索結果の取得要求をＯＡ端末１２から受け付ける。そして、その取得要求において指定されたユニークＩＤで特定される未審査レセプトのデータであり、統計処理部４０における統計処理の結果を含むデータを検索結果記録部４２から取得し、レセプト点検結果としてＯＡ端末１２へ送信する。すなわち、図６で示したレセプト点検結果の、第１エリア９０に表示させるべき未審査レセプトのデータ、第２エリア９２に表示させるべきロジック点検結果のデータ、第３エリア９４に表示させるべき査定事例検索結果のデータをＯＡ端末１２へ提供する。
【００４８】
申出書記録部４８は、拒絶レセプト受付部３０において査定情報が受け付けられ、検索部３２においてその査定情報に対する事例検索処理が実行された場合、統計処理部４０における統計処理の結果を含む再審査申出書の文書データを申出書ＤＢ２６へ格納する。その際、申出書記録部４８は、再審査申出書を参照可能（ダウンロード可能）である旨が記載された電子メールをＯＡ端末１２へ送信する。
【００４９】
具体的には、申出書記録部４８は、図７で示した再審査申出書における第１エリア２００の各記載項目と、査定情報に含まれる査定通知書および拒絶レセプトの各記載内容との対応関係を予め保持する。再審査申出書設定時にはその対応関係を参照して、第１エリア２００の各記載項目に対して、査定通知書および拒絶レセプトの各記載内容を設定する。
【００５０】
また申出書記録部４８は、再審者申出書における第２エリア２０２に対して、統計処理部４０における統計処理の結果を設定する。図７で示したように本実施の形態では、全国・全科の同一未審査レセプト件数、県内・全科の同一未審査レセプト件数、全国・同科の同一未審査レセプト件数、県内・同科の同一未審査レセプト件数と、それぞれに対応する同一査定事例件数を第２エリア２０２へ設定する。変形例として、査定事例検索結果と同様に、査定の割合を設定してもよいし、類似未審査レセプト件数および類似査定事例件数をさらに設定してもよい。
【００５１】
申出書提供部５０は、再審査申出書のテンプレートの取得要求をＯＡ端末１２から受け付ける。そして、その取得要求で指定された医療機関番号により特定される再審査申出書、言い換えれば、取得要求で指定された医療機関番号が設定された再審査申出書の文書データを申出書ＤＢ２６から取得し、再審査申出書のテンプレートとしてＯＡ端末１２へ送信する。
【００５２】
以上の構成による動作を以下説明する。
図９は、図１のＯＡ端末１２の動作を示すフローチャートである。ＯＡ端末１２の未審査レセプト取得部６４は、接続されたＵＳＢメモリ内に未審査レセプトが格納されていることを検出すると（Ｓ１０のＹ）、その未審査レセプトを読み込む。ロジック点検部６６は、未審査レセプトに対するロジック点検処理を実行する（Ｓ１２）。匿名化部６８は、未審査レセプトにおける患者の個人情報に関する所定のデータ項目に対して匿名化処理を実行する（Ｓ１４）。未審査レセプト送信部７０は、匿名化された未審査レセプトのデータを医療事務支援装置１４へアップロードする（Ｓ１６）。未審査レセプトが未検出であれば（Ｓ１０のＮ）、Ｓ１２〜Ｓ１６はスキップされる。
【００５３】
事例情報取得部７２は、医療事務担当者から入力された未審査レセプトの点検結果の表示要求を検出すると（Ｓ１８のＹ）、未審査レセプトの点検結果（ロジック点検結果および事例検索結果）を示すデータを医療事務支援装置１４から取得する（Ｓ２０）。顕名化部７４は、変換テーブル６２から患者の個人情報を読み出して、点検結果のデータの顕名化処理を実行する（Ｓ２２）。事例情報表示制御部７６は、顕名化された未審査レセプトの点検結果をディスプレイに表示させる（Ｓ２４）。未審査レセプトの点検結果の表示要求が未検出であれば（Ｓ１８のＮ）、Ｓ２０〜Ｓ２４はスキップされる。
【００５４】
図１０も、図１のＯＡ端末１２の動作を示すフローチャートである。ＯＡ端末１２の拒絶レセプト取得部７８は、医療事務担当者から入力された査定情報を検出し（Ｓ３０のＹ）、再審査の指定がなされた場合（Ｓ３２のＹ）、再審査予定フラグを査定情報のデータに設定する（Ｓ３４）。再審査の指定がなければ（Ｓ３２のＮ）、Ｓ３４はスキップされる。拒絶レセプト送信部８０は、査定情報を医療事務支援装置１４へ送信する（Ｓ３６）。査定情報の入力が未検出であれば（Ｓ３０のＮ）、Ｓ３２〜Ｓ３６はスキップされる。申出書取得部８２は、医療事務担当者から入力された再審査申出書の表示要求を検出すると（Ｓ３８のＹ）、申出書取得部８２は再審査申出書の文書データを医療事務支援装置１４から取得し（Ｓ４０）、申出書表示制御部８４はそのデータを、編集可能な再審査申出書のテンプレートとしてディスプレイに表示させる（Ｓ４２）。再審査申出書の表示要求が未検出であれば（Ｓ３８のＮ）、Ｓ４０およびＳ４２はスキップされる。
【００５５】
図１１は、図１の医療事務支援装置１４の動作を示すフローチャートである。医療事務支援装置１４の未審査レセプト受付部２８は、ＯＡ端末１２から未審査レセプトを受け付けると（Ｓ５０のＹ）、その未審査レセプトのデータを未審査レセプトＤＢ２０へ格納する（Ｓ５２）。検索部３２は、未審査レセプトに記載された患者への医療行為の内容を検索キーとして査定事例ＤＢ２２の査定事例を検索し、未審査レセプトの記載内容に対して合致もしくは類似する査定事例を特定する（Ｓ５４）。統計処理部４０は、査定事例検索の結果を審査属性単位（具体的には地域別および診療科別に）集計し（Ｓ５６）、検索結果記録部４２は、集計結果を検索結果ＤＢ２４へ格納する（Ｓ５８）。未審査レセプトを受け付けなければ（Ｓ５０のＮ）、Ｓ５２〜Ｓ５８はスキップされる。
【００５６】
続いて事例情報提供部４６は、未審査レセプトの点検結果の取得要求をＯＡ端末１２から受け付けると（Ｓ６０のＹ）、ロジック点検結果および事例検索結果を含む点検結果のデータを検索結果ＤＢ２４から取得してＯＡ端末１２へ送信する（Ｓ６２）。未審査レセプトの点検結果の取得要求を受け付けなければ（Ｓ６０のＮ）、Ｓ６２はスキップされる。
【００５７】
図１２も、図１の医療事務支援装置１４の動作を示すフローチャートである。医療事務支援装置１４の拒絶レセプト受付部３０は、ＯＡ端末１２から査定情報を受け付けると（Ｓ７０のＹ）、その査定情報を査定事例ＤＢ２２へ格納する（Ｓ７２）。査定情報に再審査予定フラグが設定されている場合（Ｓ７４のＹ）、検索部３２は、査定情報における拒絶レセプトに記載された患者への医療行為の内容を検索キーとして査定事例ＤＢ２２の査定事例を検索し、拒絶レセプトの記載内容に対して合致もしくは類似する査定事例を特定する（Ｓ７６）。統計処理部４０は、査定事例検索の結果を審査属性単位（具体的には地域別および診療科別に）集計する（Ｓ７８）。申出書記録部４８は、集計結果を再審理由欄に設定した再審査申出書の文書データを申出書ＤＢ２６へ格納する（Ｓ８０）。再審査予定フラグが未設定であれば（Ｓ７４のＮ）、Ｓ７６〜Ｓ８０はスキップされ、査定情報を受け付けなければ（Ｓ７０のＮ）、Ｓ７２〜Ｓ８０はスキップされる。
【００５８】
続いて申出書提供部５０は、再審査申出書の取得要求をＯＡ端末１２から受け付けると（Ｓ８２のＹ）、再審査申出書のデータを申出書ＤＢ２６から取得してＯＡ端末１２へ送信する（Ｓ８４）。再審査申出書の取得要求を受け付けなければ（Ｓ８２のＮ）、Ｓ８４はスキップされる。
【００５９】
本実施の形態の医療事務支援システム１００によれば、医療事務支援装置１４においてレセプトの査定事例を蓄積し、未審査レセプトと記載内容が同一・類似の査定事例について、その件数および未審査レセプト数に占める査定件数の割合を医療事務担当者へ提示する。これにより、現状のレセプトの記載が査定されやすいものか否かを示唆することができ、医療事務担当者は、未審査レセプトの記載内容が、審査により拒絶されるリスクの程度を過去の事例を踏まえて判断し、その内容を適宜修正することができる。レセプトの審査結果は、審査者の主観に左右されるものであるところ、医療事務支援システム１００によれば、点検ロジックによる静的なチェックだけでなく、合致もしくは類似する記載内容での査定状況を医療事務担当者に提示することで、未審査レセプトの点検作業における精度向上を支援することができる。
【００６０】
本実施の形態では、未審査レセプトと記載内容が同一のみならず類似の査定事例も検索して、その検索結果を提供することにより、未審査レセプトの点検作業における精度を一層向上させることができる。例えば、図６の検索結果の第２レコードは、同一査定事例は０件であるものの、類似査定事例は多数存在することを示しており、未審査レセプトの現在の記載内容は不適応と認定されてしまうリスクが高いことを医療事務担当者は把握できる。より具体的には、未審査レセプトにおいて後発医薬品名が記載されていた場合に、後発医薬品と同一視が可能な先発医薬品名が記載された査定事例を把握することができる。
【００６１】
また医療事務支援システム１００によれば、医療事務支援装置１４において検索条件レセプトの審査属性（地域や診療科）に合致する査定事例については他の査定事例と区別して集計して、査定件数や査定割合を医療事務担当者へ提示する。これにより、地域や診療科ごとの審査傾向を医療事務担当者が把握することを容易にし、その傾向に応じて適宜修正を行うことを支援できる。例えば、医療事務担当者は、図６のレセプト点検結果の第１レコードを確認した場合、レセプトの現在の記載は全国的には査定されてしまうリスクが高いが、県内では査定されるリスクが低いため、現状の記載を維持してよいと等の判断ができる。
【００６２】
また医療事務支援システム１００によれば、図７で示した再審査申出書における第１エリア２００の各項目には、各項目に対応づけられた査定通知書の記載内容や、拒絶レセプトの記載内容が自動で設定される。その一方で、再審申出書における第２エリア２０２、すなわち再審理由欄には、拒絶レセプトに対する査定事例検索の結果が設定される。例えば医師は、再審理由欄の査定事例件数を考慮して再審の有無を判断でき、また、再審理由の１つとして査定事例件数を容易に引用できる。また、第１エリア２００にて記載すべき項目の多くが自動で設定されるため、再審査申出書の作成の負担を低減することができる。
【００６３】
また医療事務支援システム１００によれば、未審査レセプトに記載された患者の個人情報はＯＡ端末１２内に保持されて、医療事務支援装置１４に渡される未審査レセプトは匿名化されたものとなる。これにより、患者の個人情報の拡散を回避し、また漏洩のリスクを低減することができる。
【００６４】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００６５】
第１の変形例を説明する。上記実施の形態では、未審査レセプトの点検結果の画面には同一査定事例の件数および類似査定事例の件数を表示させることとした。変形例としては、医療事務担当者が同一査定事例の表示欄に設けられた所定オブジェクト（件数の表示文字列でもよい）を選択した場合に、同一査定事例の内容をＯＡ端末１２のディスプレイに表示させてもよい。同様に、医療事務担当者が類似査定事例の表示欄に設けられた所定オブジェクトを選択した場合に、類似査定事例の内容をＯＡ端末１２のディスプレイに表示させてもよい。
【００６６】
ここでは、類似査定事例の記載内容を提示する場合の構成例を示すが、同一査定事例の記載内容を提示する場合も同様の構成にて実現できることはもちろんである。
医療事務支援装置１４の検索結果記録部４２は、統計処理部４０により集計された類似査定事例件数（地域・診療科別）を示す文字列に対して、集計対象となった類似査定事例のデータの識別情報（ＵＲＬ等）を指定したハイパーリンクを設定してもよい。医療事務担当者によりそのハイパーリンクが選択されたことを検出すると、事例情報提供部４６は、類似査定事例の識別情報を指定してその取得要求を医療事務支援装置１４へ送信することにより、類似査定事例の記載内容を示すデータを取得して表示させてもよい。
【００６７】
この変形例によると、同一査定事例や類似査定事例の実際の内容を医療事務担当者へ提示することができ、未審査レセプトの点検作業における精度向上を一層支援することができる。特に類似査定事例は、その記載内容が未審査レセプトと異なるものであるため、その記載内容を医療事務担当者へ提示することは好適な態様である。
【００６８】
第２の変形例を説明する。上記実施の形態では、類似判定条件として、レセプトの各データ項目の設定値の幅や、先発医薬品と後発医薬品との対応関係について言及した。変形例としては、査定（減点等）の要素が複数ある場合に、特に査定される確率と強い正の相関（例えば、相関係数＝０．７から１）を示す要素の組み合わせが類似判定条件として予め定められてもよい。
【００６９】
例えば、「この患者は６５歳と高齢なので、病名Ａに対して医薬品Ｂは不適応」という査定理由等、病名Ａと医薬品Ｂの組み合わせがレセプト内に存在すると査定される確率が高いという統計データがあるケースを考える。このケースにおいて医療事務支援装置１４の類似条件テーブル３６は、病名Ａと医薬品Ｂの組み合わせを類似判定条件として保持してもよい。類似事例検索部３８は、病名Ａと医薬品Ｂの組み合わせのある全てのレセプトを、他の記載内容の差異にかかわらず類似査定事例として特定してもよい。
【００７０】
第３の変形例を説明する。上記実施の形態では、ＯＡ端末１２は、所定の記録媒体（ＵＳＢメモリ）を介してレセコン１０における未審査レセプトのデータを読み込むこととしたが、レセコン１０とＯＡ端末１２とはオンラインで接続されてもよいことはもちろんである。また、医療機関から医療事務支援装置１４への査定情報の通知においては、査定通知書と拒絶レセプトの書類を、医療機関から医療事務支援装置１４の管理者（システム管理会社等）へ送付してもよい。この場合、管理者側では査定通知書と拒絶レセプトの内容をＯＣＲ（Optical Character Reader）装置にて読取り、その文字データを医療事務支援装置１４の拒絶レセプト受付部３０が受け付けてもよい。
【００７１】
第４の変形例を説明する。上記実施の形態では、未審査レセプトに対するロジック点検処理をＯＡ端末１２で実行することとしたが、このロジック点検処理が医療事務支援装置１４で実行されてもよいことはもちろんである。この場合、医療事務支援装置１４は、図２で説明したロジックテーブル６０およびロジック点検部６６をさらに備え、そのロジック点検部６６は事例検索の前もしくは後に、ＯＡ端末１２にて匿名化済の未審査レセプトに対するロジック点検処理を実行する。
【００７２】
第５の変形例を説明する。未審査レセプトに対する査定事例検索結果の精度を高めるために査定事例の蓄積は不可欠であるところ、未審査レセプトの点検は行いたいが、査定情報は提供したくないと考える医療機関もあると想定される。医療事務支援装置１４の査定事例検索結果の精度を低下させてしまうため望ましい状況ではない。そこで、上記実施の形態では言及していないが、査定情報を提供しない医療機関に対して、未審査レセプトの点検における一種の制限を課してもよい。具体的には、医療事務支援装置１４は、医療機関から査定情報が提供された年月（２０１１年１月、２月等）を保持し、検索部３２は、その提供年月以前の査定情報を検索対象の母集団としてもよい。この結果、査定情報の提供を停止した医療機関に対しては、新しい査定事例を反映しない査定事例検索結果が提供されることになり、積極的な査定事例の提供を医療機関に促すことができる。
【００７３】
上述した実施の形態、変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態、変形例それぞれの効果をあわせもつ。
【００７４】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【００７５】
なお、請求項３に記載の内容は以下のように具体化することもできる。すなわち、類似条件保持部は、先発医薬品と後発医薬品との対応関係を保持し、検索部は、複数の査定事例のうち、患者への医療行為の内容が前記未審査レセプトにおける記載内容と不一致であるものの、その不一致の内容が前記対応関係にて定められた先発医薬品と後発医薬品の違いである査定事例を類似事例として特定してもよい。
【符号の説明】
【００７６】
１０ レセコン、 １２ ＯＡ端末、 １４ 医療事務支援装置、 ２０ 未審査レセプトＤＢ、 ２２ 査定事例ＤＢ、 ２４ 検索結果ＤＢ、 ２６ 申出書ＤＢ、 ２８ 未審査レセプト受付部、 ３０ 拒絶レセプト受付部、 ３２ 検索部、 ３４ 同一事例検索部、 ３６ 類似条件テーブル、 ３８ 類似事例検索部、 ４０ 統計処理部、 ４２ 検索結果記録部、 ４６ 事例情報提供部、 ４８ 申出書記録部、 ５０ 申出書提供部、 １００ 医療事務支援システム。
【特許請求の範囲】
【請求項１】
医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する査定事例保持部と、
医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける未審査レセプト受付部と、
前記複数の査定事例のうち、患者への医療行為の内容が、前記未審査レセプトにおける記載内容と合致する査定事例を特定する検索部と、
前記合致する査定事例の情報をユーザへ提供する査定事例提供部と、
を備えることを特徴とする医療事務支援装置。
【請求項２】
前記複数の査定事例のそれぞれは、審査の属性を示す審査属性情報を含むものであり、
前記未審査レセプトも、前記審査属性情報を含むものであり、
前記検索部は、前記合致する査定事例のうち、前記未審査レセプトに記載された審査属性情報を含む査定事例をさらに特定し、
前記査定事例提供部は、前記合致する査定事例の情報をユーザへ提供する際、前記未審査レセプトに記載された審査属性情報を含む査定事例を識別可能な態様で提供することを特徴とする請求項１に記載の医療事務支援装置。
【請求項３】
前記未審査レセプトにおける記載内容と前記査定事例における記載内容とが異なる場合であっても類似するものとして判定すべき所定の条件を示す情報を保持する類似条件保持部をさらに備え、
前記検索部は、前記複数の査定事例のうち、患者への医療行為の内容が前記未審査レセプトにおける記載内容と不一致であるものの、その不一致の内容が前記条件と整合する査定事例を類似事例としてさらに特定し、
前記査定事例提供部は、前記類似事例の情報をユーザへさらに提供することを特徴とする請求項１または２に記載の医療事務支援装置。
【請求項４】
前記未審査レセプトの情報を蓄積して保持する未審査レセプト保持部をさらに備え、
前記検索部は、前記未審査レセプト受付部において新たな未審査レセプトが受け付けられた場合、前記未審査レセプト保持部に蓄積された未審査レセプトのうち、患者への医療行為の内容が、前記新たな未審査レセプトにおける記載内容と合致する未審査レセプトをさらに特定し、
前記査定事例提供部は、前記合致する未審査レセプトの件数に占める前記合致する査定事例の件数の割合を示す情報をユーザへさらに提供することを特徴とする請求項１から３のいずれかに記載の医療事務支援装置。
【請求項５】
前記審査機関により拒絶されたレセプトであって、かつ、再審査申立を行うべきレセプトの情報をユーザから受け付ける拒絶レセプト受付部と、
文書提供部と、
をさらに備え、
前記検索部は、前記複数の査定事例のうち、患者への医療行為の内容が、前記拒絶されたレセプトにおける記載内容と合致する査定事例を特定し、
前記文書提供部は、再審査申出書の文書データにおける再審理由の入力エリアに対して前記合致する査定事例の情報を設定した上で、その再審査申出書の文書データをユーザへ提供することを特徴とする請求項１から３のいずれかに記載の医療事務支援装置。
【請求項６】
医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する機能と、
医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける機能と、
前記複数の査定事例のうち、患者への医療行為の内容が、前記未審査レセプトにおける記載内容と合致する査定事例を特定する機能と、
前記合致する査定事例の情報をユーザへ提供する機能と、
をコンピュータに実現させるためのコンピュータプログラム。
【請求項１】
医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する査定事例保持部と、
医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける未審査レセプト受付部と、
前記複数の査定事例のうち、患者への医療行為の内容が、前記未審査レセプトにおける記載内容と合致する査定事例を特定する検索部と、
前記合致する査定事例の情報をユーザへ提供する査定事例提供部と、
を備えることを特徴とする医療事務支援装置。
【請求項２】
前記複数の査定事例のそれぞれは、審査の属性を示す審査属性情報を含むものであり、
前記未審査レセプトも、前記審査属性情報を含むものであり、
前記検索部は、前記合致する査定事例のうち、前記未審査レセプトに記載された審査属性情報を含む査定事例をさらに特定し、
前記査定事例提供部は、前記合致する査定事例の情報をユーザへ提供する際、前記未審査レセプトに記載された審査属性情報を含む査定事例を識別可能な態様で提供することを特徴とする請求項１に記載の医療事務支援装置。
【請求項３】
前記未審査レセプトにおける記載内容と前記査定事例における記載内容とが異なる場合であっても類似するものとして判定すべき所定の条件を示す情報を保持する類似条件保持部をさらに備え、
前記検索部は、前記複数の査定事例のうち、患者への医療行為の内容が前記未審査レセプトにおける記載内容と不一致であるものの、その不一致の内容が前記条件と整合する査定事例を類似事例としてさらに特定し、
前記査定事例提供部は、前記類似事例の情報をユーザへさらに提供することを特徴とする請求項１または２に記載の医療事務支援装置。
【請求項４】
前記未審査レセプトの情報を蓄積して保持する未審査レセプト保持部をさらに備え、
前記検索部は、前記未審査レセプト受付部において新たな未審査レセプトが受け付けられた場合、前記未審査レセプト保持部に蓄積された未審査レセプトのうち、患者への医療行為の内容が、前記新たな未審査レセプトにおける記載内容と合致する未審査レセプトをさらに特定し、
前記査定事例提供部は、前記合致する未審査レセプトの件数に占める前記合致する査定事例の件数の割合を示す情報をユーザへさらに提供することを特徴とする請求項１から３のいずれかに記載の医療事務支援装置。
【請求項５】
前記審査機関により拒絶されたレセプトであって、かつ、再審査申立を行うべきレセプトの情報をユーザから受け付ける拒絶レセプト受付部と、
文書提供部と、
をさらに備え、
前記検索部は、前記複数の査定事例のうち、患者への医療行為の内容が、前記拒絶されたレセプトにおける記載内容と合致する査定事例を特定し、
前記文書提供部は、再審査申出書の文書データにおける再審理由の入力エリアに対して前記合致する査定事例の情報を設定した上で、その再審査申出書の文書データをユーザへ提供することを特徴とする請求項１から３のいずれかに記載の医療事務支援装置。
【請求項６】
医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する機能と、
医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける機能と、
前記複数の査定事例のうち、患者への医療行為の内容が、前記未審査レセプトにおける記載内容と合致する査定事例を特定する機能と、
前記合致する査定事例の情報をユーザへ提供する機能と、
をコンピュータに実現させるためのコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１２−２３４３１４（Ｐ２０１２−２３４３１４Ａ）
【公開日】平成２４年１１月２９日（２０１２．１１．２９）
【国際特許分類】
【出願番号】特願２０１１−１０１７８１（Ｐ２０１１−１０１７８１）
【出願日】平成２３年４月２８日（２０１１．４．２８）
【出願人】（０００００５９７９）三菱商事株式会社 (56)
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【公開日】平成２４年１１月２９日（２０１２．１１．２９）
【国際特許分類】
【出願日】平成２３年４月２８日（２０１１．４．２８）
【出願人】（０００００５９７９）三菱商事株式会社 (56)
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
[ Back to top ]