レセプト分析技術(査定防止サービス)
【課題】医療機関におけるレセプト点検の精度向上を支援する。
【解決手段】医療事務支援装置14は、医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する査定事例DB22と、医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける未審査レセプト受付部28と、査定事例DB22に保持された複数の査定事例のうち、患者への医療行為の内容が、未審査レセプトにおける記載内容と合致する査定事例を特定する検索部32と、検索部32により特定された査定事例の情報をユーザへ提供する査定事例提供部とを備える。
【解決手段】医療事務支援装置14は、医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する査定事例DB22と、医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける未審査レセプト受付部28と、査定事例DB22に保持された複数の査定事例のうち、患者への医療行為の内容が、未審査レセプトにおける記載内容と合致する査定事例を特定する検索部32と、検索部32により特定された査定事例の情報をユーザへ提供する査定事例提供部とを備える。
【発明の詳細な説明】
【技術分野】
【0001】
本発明はデータ処理技術に関し、特に、医療機関における事務作業を支援するための技術に関する。
【背景技術】
【0002】
健康保険を利用して医療を受ける保険診療では、被保険者(患者)が保険者(健康保険組合等)から発行された被保険者証を医療機関へ提示する。この保険診療には、診療報酬が定められている。診療報酬の一部は保険診療を受ける被保険者により医療機関へ支払われ、残りの診療報酬は保険者から医療機関へ支払われる。
【0003】
このとき、医療機関から保険者へ提出される書類をレセプトという。レセプトは、医療機関で保険診療を受けたときの被保険者の自己負担分外の料金を医療機関が保険者へ請求するための診療報酬明細書である。一般的にレセプトは1ヶ月単位で患者ごとの診療内容を入院や外来、医療保険別に分けて規定にフォーマットにとりまとめたものである。
【0004】
レセプトの審査は、都道府県や診療科等の単位で予め定められた審査機関が実施する。この審査機関において、レセプトに記載された診療内容が妥当でないと判断された場合、レセプトの要求通りの診療報酬の支払が拒否されて、減点・減額される場合がある。このため、審査機関へレセプトを提出する前に、医療機関においてレセプトの記載内容を点検する必要がある。以下の特許文献1では、レセプトの点検作業にかかる負担を軽減するための技術が提案されている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2009−193133号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
ところで審査機関においてレセプトを審査する審査者は医師等であり、レセプトの記載内容が許容されるか否かは、審査者の主観的判断に委ねられている面がある。したがって、予め定められた点検ロジックにもとづく機械的なレセプト点検では不十分な場合があると本発明者は考えた。
【0007】
本発明は発明者の上記着想に鑑みてなされたものであり、その目的は、医療機関におけるレセプト点検の精度向上を支援する技術を提供することにある。
【課題を解決するための手段】
【0008】
上記課題を解決するために、本発明のある態様の医療事務支援装置は、医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する査定事例保持部と、医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける未審査レセプト受付部と、複数の査定事例のうち、患者への医療行為の内容が、未審査レセプトにおける記載内容と合致する査定事例を特定する検索部と、合致する査定事例の情報をユーザへ提供する査定事例提供部と、を備える。
【0009】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【0010】
本発明によれば、医療機関におけるレセプト点検の精度向上を支援することができる。
【図面の簡単な説明】
【0011】
【図1】実施の形態の医療事務支援システムの構成を示す図である。
【図2】図1のOA端末の機能構成を示すブロック図である。
【図3】レセプトに設定されるデータ項目を模式的に示す図である。
【図4】変換テーブルに格納されるデータ項目を模式的に示す図である。
【図5】匿名化されたレセプトのデータ項目を模式的に示す図である。
【図6】レセプト点検結果の表示例を示す図である。
【図7】再審査申出書のテンプレートを模式的に示すものである図である。
【図8】図1の医療事務支援装置の機能構成を示すブロック図である。
【図9】図1のOA端末の動作を示すフローチャートである。
【図10】図1のOA端末の動作を示すフローチャートである。
【図11】図1の医療事務支援装置の動作を示すフローチャートである。
【図12】図1の医療事務支援装置の動作を示すフローチャートである。
【発明を実施するための形態】
【0012】
図1は、実施の形態の医療事務支援システムの構成を示す。医療事務支援システム100は、病院や診療所等の医療機関に設置されたOA端末12と、医療機関の外部に設置された医療事務支援装置14を備える。OA端末12は、ウェブブラウザや各種のオフィスソフトウェアがインストールされた一般的なPCであり、医療機関における医療事務の担当者(医師を含む)により操作される。医療事務支援装置14は、複数の医療機関のそれぞれに設置されたOA端末12と接続され、レセプトのチェック作業を支援するための情報をOA端末12へ提供することにより、各医療機関における医療事務の効率化を支援する情報処理装置である。OA端末12と医療事務支援装置14は、LAN・WAN・インターネット等を含む通信網16を介して接続される。
【0013】
医療機関には、OA端末12とともに、レセプトを管理するレセプトコンピュータ(以下、「レセコン10」とも呼ぶ。)が設置される。医療機関で作成されたレセプトは、定期的に健康保険組合等のレセプトの審査機関へ送付される。そして、審査機関における審査においてレセプトでの要求通りの診療報酬の支払が拒否された場合、増減点並びに返戻通知書(以下、「査定通知書」とも呼ぶ。)が審査機関から医療機関へ送付される。
【0014】
図2は、図1のOA端末12の機能構成を示すブロック図である。OA端末12は、ロジックテーブル60と、変換テーブル62と、未審査レセプト取得部64と、ロジック点検部66と、匿名化部68と、未審査レセプト送信部70と、事例情報取得部72と、顕名化部74と、事例情報表示制御部76と、拒絶レセプト取得部78と、拒絶レセプト送信部80と、申出書取得部82と、申出書表示制御部84を備える。
【0015】
本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図2の各機能ブロックは、ソフトウェアとして記録媒体に格納され、OA端末12のハードディスクにインストールされ、OA端末12のメインメモリに適宜読み出されてCPUにて実行されてもよい。後述の図8についても同様である。
【0016】
未審査レセプト取得部64は、医療機関から審査機関へ送付される前のレセプト、言い換えれば、審査機関の審査により承認されるかもしくは拒否されるかが未確定のレセプト(以下、「未審査レセプト」とも呼ぶ。)を取得する。本実施の形態では、医療事務の担当者がレセコン10に保持された未審査レセプトのデータをUSBメモリへ書き出し、そのUSBメモリをOA端末12へ装着する。未審査レセプト取得部64は、USBメモリに格納された未審査レセプトを検出して、そのデータを読み込む。
【0017】
図3は、レセプトに設定されるデータ項目を模式的に示す。実際のレセプトに設定されるデータ項目は多岐に亘るが、実施の形態では説明の簡明化のため、一部の項目のみを示すこととする。図3の(a)のデータ項目と図3の(b)のデータ項目は実際には1レコードとして連結されており、保険診療を受けた患者単位に設定される。
【0018】
図2に戻り、ロジックテーブル60は、レセプトの各データ項目の設定値や、複数のデータ項目の設定値の組み合わせが妥当か否かを点検するための点検ロジックを保持する記憶領域である。例えば、点検ロジックには、レセプトの医薬品名フィールドに設定される医薬品の適正な用法・用量を示すデータが含まれる。また、医薬品名やその用法・用量が、患者の年齢や疾病との組み合わせにおいて適応と認められる可能性が高い組み合わせを示すデータが含まれる。
【0019】
ロジック点検部66は、ロジックテーブル60に格納された点検ロジックにしたがって、未審査レセプトの各データ項目の設定値が妥当なものか否かを点検するロジック点検処理を実行する。ロジック点検部66は、ロジック点検処理の結果として、レセプトの各項目の設定値が、不適応と認定される可能性があるか否かを示すメッセージを出力する。ロジック点検処理の結果の具体例は、図6に関連して後述する。
【0020】
変換テーブル62は、複数の医療機関に亘って未審査レセプトの各レコード(各患者の未審査レセプト)を一意に識別するための識別情報であるユニークIDと、各患者の個人情報とを対応付けて保持する記憶領域である。図4は、変換テーブル62に格納されるデータ項目を模式的に示す。同図で示すように、図3の(a)で示したレセプトの各項目がユニークIDと対応づけられる。
【0021】
図2に戻り、匿名化部68は、未審査レセプトのデータの匿名化処理、言い換えれば、患者の特定を困難にするための、患者の個人情報を削除もしくは抽象化する処理を実行する。具体的には、まず、未審査レセプトにおける患者のレコードごとにユニークIDを採番する。そして、図3の(a)で示したレセプトの各項目とユニークIDとを対応づけて変換テーブル62へ格納する。
【0022】
続いて匿名化部68は、レセプトのデータ項目のうち、被保険者証記号/番号と、カルテ番号と、氏名を削除する。また、医療機関番号における都道府県コード以外を削除して都道府県コードのみとし、生年月日における生年以外を削除して生年のみとする。そして、このように匿名化したレセプトのデータをユニークIDと対応づけて未審査レセプト送信部70に渡す。
【0023】
図5は、匿名化されたレセプトのデータ項目を模式的に示す。図5の(a)のデータ項目と図5の(b)のデータ項目もまた実際には1レコードである。同図で示すように、匿名化されたレセプトの各データは、ユニークIDと対応づけられる。また、未審査レセプトに対するロジック点検部66によるロジック点検の結果が付加されている。
【0024】
図2に戻り、未審査レセプト送信部70は、匿名化された未審査レセプトのデータを医療事務支援装置14へ送信する。詳細は後述するが、本実施の形態の医療事務支援装置14は、OA端末12から受け付けた匿名化された未審査レセプトのデータをもとに、医療事務支援装置14に蓄積された査定事例を検索する。その検索処理が完了すると、医療事務支援装置14は、その完了の旨を記載した電子メールをOA端末12へ送信する。この電子メールには、査定事例の検索結果を表示するウェブページへのハイパーリンクが設定されていてもよく、電子メールを確認した医療事務の担当者がそのハイパーリンクを選択した場合に、事例情報取得部72が、査定事例検索結果の取得要求を検出してもよい。
【0025】
事例情報取得部72は、査定事例検索結果の取得要求を医療事務担当者から受け付けると、その取得要求を医療事務支援装置14へ送信する。この取得要求では、未審査レセプト送信部70により医療事務支援装置14へ送信された未審査レセプトにおいて指定されたユニークIDが指定されてもよい。続いて事例情報取得部72は、査定事例の検索結果のデータを医療事務支援装置14から取得する。ここでの取得データは、図5の(a)および(b)のデータに、査定事例の検索結果が付加されたものとし、以下では「レセプト点検結果」とも呼ぶ。図6に関して後述するが、レセプト点検結果における査定事例の検索結果には、同一事例における査定件数と査定割合、類似事例における査定件数と査定割合を示す情報が含まれる。
【0026】
顕名化部74は、変換テーブル62を参照して、レセプト点検結果のユニークIDと対応づけられたデータ(図4の被保険者証記号/番号〜生年月日、すなわち予め変換テーブル62へ待避された患者の個人情報)を取得して、レセプト点検結果を顕名化する。例えば、ユニークIDと対応づけられた被保険者証記号/番号、医療機関コード、カルテ番号、氏名、生年月日をレセプト点検結果に付加し、もしくは抽象化された医療機関コードや生年と置き換える。
【0027】
事例情報表示制御部76は、顕名化部74により顕名化されたレセプト点検結果をディスプレイに表示させる。なお、レセプト点検結果のデータがウェブページとして提供される場合、事例情報表示制御部76はウェブブラウザへウェブページを提供して、ウェブブラウザにレセプト点検結果を表示させてもよい。
【0028】
図6は、レセプト点検結果の表示例を示す。同図の第1エリア90には、レセプトの情報が表示される。第2エリア92には、ロジック点検部66によるロジック点検の結果が表示される。第3エリア94には、医療事務支援装置14による査定事例検索の結果が表示される。本実施の形態では、査定事例検索の結果として、同一事例(すなわちレセプトの生年、疾病名、診療行為名、医薬品名の設定値が同一の査定事例)と、類似事例(上記の設定値が同一ではないものの、類似すると想定される査定事例)のそれぞれについて、全国/県内、全科/同科の組み合わせごとの査定事例件数が件数フィールド96にて提示される。また、全未審査レセプト件数に占める査定事例件数の割合が、割合フィールド98にて提示される。
【0029】
図2に戻り、拒絶レセプト取得部78は、医療事務担当者により入力された、査定通知書に記載された情報、および、査定の対象となったレセプト(以下、「拒絶レセプト」とも呼ぶ。)に記載された情報を受け付ける。以下、これらの情報を総称して「査定情報」とも呼ぶ。査定情報を入力する際に医療事務担当者は、再審査を申立予定のレセプトを指定し、拒絶レセプト取得部78は、指定されたレセプトの査定情報に対して、再審査予定フラグを設定する。
【0030】
なお拒絶レセプト取得部78は、医療事務担当者からの査定情報の入力要求を受け付けて、査定情報の入力画面をディスプレイに表示させてもよい。そして、医療事務担当者が入力した査定情報および再審査申立の指定を、その入力画面を介して取得してもよい。
【0031】
拒絶レセプト送信部80は、再審査予定フラグが適宜設定された査定情報を医療事務支援装置14へ送信する。医療事務支援装置14は、再審査申出書のテンプレートを設定完了すると、その完了の旨を記載した電子メールをOA端末12へ送信する。この電子メールには、再審査申出書のテンプレートを取得するためのウェブページへのハイパーリンクが設定されていてもよく、電子メールを確認した医療事務の担当者がそのハイパーリンクを選択した場合に、申出書取得部82が再審査申出書のテンプレートの取得要求を検出してもよい。
【0032】
申出書取得部82は、再審査申出書のテンプレートの取得要求を医療事務担当者から受け付けると、その取得要求を医療事務支援装置14へ送信する。この取得要求では再審査申出書のキーとして医療機関番号が指定されることとする。申出書取得部82は、再審査申出書のテンプレートのデータを医療事務支援装置14から取得する。このテンプレートのデータは、例えば、所定のワープロソフトで定められたデータ形式であってもよい。申出書表示制御部84は、申出書取得部82により取得された再審査申出書のテンプレートのデータを編集可能な状態でディスプレイに表示させる。
【0033】
図7は、再審査申出書のテンプレートを模式的に示すものである。再審査申出書における第1エリア200には、各記入項目に予め対応づけられた査定通知書の記載内容や、拒絶レセプトの記載内容が自動で設定される。その一方で、再審申出書における第2エリア202(すなわち再審理由欄)には、拒絶レセプトに対する査定事例検索の結果が設定される。
【0034】
図8は、図1の医療事務支援装置14の機能構成を示すブロック図である。医療事務支援装置14は、未審査レセプトDB20と、査定事例DB22と、検索結果DB24と、申出書DB26と、未審査レセプト受付部28と、拒絶レセプト受付部30と、検索部32と、統計処理部40と、検索結果記録部42と、事例情報提供部46と、申出書記録部48と、申出書提供部50とを備える。
【0035】
未審査レセプトDB(データベース)20は、未審査レセプトを保持する記憶領域である。未審査レセプトのデータ構成は、図5の(a)および(b)にて既述したとおりである。査定事例DB22は、査定通知書および拒絶レセプトの記載内容を含む査定情報を査定事例として、複数の査定事例を保持する記憶領域である。査定通知書のデータは査定理由等を含むものであり、拒絶レセプトのデータ構成は、図3の(a)および(b)で既述したとおりである。検索結果DB24は、検索部32による事例検索結果のデータを保持する記憶領域である。申出書DB26は、申出書記録部48により設定された再審査申出書のデータを保持する記憶領域である。
【0036】
未審査レセプト受付部28は、医療機関のOA端末12から送信された未審査レセプトのデータを受け付けて未審査レセプトDB20へ格納する。拒絶レセプト受付部30は、医療機関のOA端末12から送信された査定情報を受け付けて査定事例DB22へ格納する。
【0037】
検索部32は、未審査レセプト受付部28において未審査レセプトが受け付けられた場合、その未審査レセプトに記載された医療行為の内容を検索キーとして査定事例を検索する。また検索部32は、拒絶レセプト受付部30において査定情報が受け付けられて、その査定情報に再審査予定フラグが設定されている場合、その査定情報に記載された医療行為の内容を検索キーとして査定事例を検索する、検索部32は、同一事例検索部34と、類似条件テーブル36と、類似事例検索部38とを含む。以下では、事例検索の対象となる未審査レセプトおよび拒絶レセプトを適宜「検索条件レセプト」とも称する。
【0038】
同一事例検索部34は、査定事例DB22に格納された査定事例のうち、検索条件レセプトに記載された患者の生年、性別、疾病名、診療行為名、医薬品名(用法、用量を含む)に合致する記載内容の査定事例を同一査定事例として特定する。変形例として、上記組み合わせの一部が合致する査定事例、例えば、疾病名、診療行為名、医薬品名の組み合わせが合致する査定事例を同一査定事例として特定してもよい。また同一事例検索部34は、未審査レセプトDB20に格納された未審査レセプトのうち、記載内容(同一査定事例を特定する場合と同様の上記データ項目の内容)が検索条件レセプトと合致する未審査レセプトを同一未審査レセプトとして特定する。
【0039】
類似条件テーブル36は、検索条件レセプトの記載内容と査定事例の記載内容とが異なる場合であっても、双方の記載内容を類似するものとして判定すべき条件(以下、「類似判定条件」とも呼ぶ。)を保持する記憶領域である。この類似判定条件としては、類似したものとして予め想定される年齢の幅や、医薬品の用法・用量の幅が設定される。例えば、検索条件レセプトにおける生年が1975年の場合、生年1970年〜1974年、1976年〜1980年を類似範囲として設定されてもよい。また別の類似判定条件としては、先発医薬品(オリジナル薬、新薬とも呼ばれる)と後発医薬品(ジェネリック医薬品とも呼ばれる)との対応関係が設定される。
【0040】
類似事例検索部38は、医療行為の内容が検索条件レセプトと異なる査定事例のうち、類似条件テーブル36に格納された類似判定条件に整合する査定事例を類似査定事例として特定する。例えば、検索条件レセプトの医薬品名フィールドに後発医薬品が記載されている場合、その後発医薬品に対応する先発医薬品が医薬品名フィールドに記載された査定事例を類似査定事例として特定する。その逆の場合も同様である。また類似事例検索部38は、未審査レセプトDB20に格納された未審査レセプトのうち、医療行為の内容が検索条件レセプトと異なり、かつ、その差異が類似判定条件に整合する未審査レセプトを類似未審査レセプトとして特定する。
【0041】
統計処理部40は、同一事例検索部34において特定された同一査定事例に対して、審査の属性を基準とした統計処理を実行する。本実施の形態では、都道府県および診療科ごとにレセプトの審査主体が異なることを前提として、審査主体の属性である都道府県および診療科ごとの同一査定事例件数を集計する。
【0042】
具体的には、統計処理部40は、同一査定事例の総数を全国・全科の同一査定事例件数として計数する。また、医療機関コードにおける都道府県コードが検索条件レセプトの記載内容と合致する同一査定事例の件数を、県内・全科の同一査定事例件数として計数する。また、診療科が検索条件レセプトの記載内容と合致する同一査定事例の件数を全国・同科の同一査定事例件数として計数する。また、医療機関コードにおける都道府県コードと診療科の両方が、検索条件レセプトの記載内容と合致する同一査定事例の件数を県内・同科の同一査定事例件数として計数する。
【0043】
また統計処理部40は、類似事例検索部38において特定された類似査定事例に対しても、上記の同一査定事例の場合と同様に、審査の属性を基準とした統計処理を実行する。すなわち、類似査定事例の総数を全国・全科の類似査定事例件数として計数する。また、医療機関コードにおける都道府県コードが検索条件レセプトの記載内容と合致する類似査定事例の件数を、県内・全科の類似査定事例件数として計数する。また、診療科が検索条件レセプトの記載内容と合致する類似査定事例の件数を全国・同科の類似査定事例件数として計数する。また、医療機関コードにおける都道府県コードおよび診療科が、検索条件レセプトの記載内容と合致する類似査定事例の件数を県内・同科の類似査定事例件数として計数する。
【0044】
また統計処理部40は、同一事例検索部34において特定された同一未審査レセプトに対して同一査定事例に対する統計処理と同様の統計処理を実行し、全国・全科の同一未審査レセプト件数、県内・全科の同一未審査レセプト件数、全国・同科の同一未審査レセプト件数、県内・同科の同一未審査レセプト件数のそれぞれを計数する。そして、全国・全科の同一未審査レセプト件数に占める全国・全科の同一査定事例件数の割合、県内・全科の同一未審査レセプト件数に占める県内・全科の同一査定事例件数の割合、全国・同科の同一未審査レセプト件数に占める全国・同科の同一査定事例件数の割合、県内・同科の同一未審査レセプト件数に占める県内・同科の同一査定事例件数の割合のそれぞれを計数する。
【0045】
また統計処理部40は、類似事例検索部38において特定された類似未審査レセプトに対しても類似査定事例に対する統計処理と同様の統計処理を実行し、全国・全科の類似未審査レセプト件数、県内・全科の類似未審査レセプト件数、全国・同科の類似未審査レセプト件数、県内・同科の類似未審査レセプト件数のそれぞれを計数する。そして、全国・全科の類似未審査レセプト件数に占める全国・全科の類似査定事例件数の割合、県内・全科の類似未審査レセプト件数に占める県内・全科の類似査定事例件数の割合、全国・同科の類似未審査レセプト件数に占める全国・同科の類似査定事例件数の割合、県内・同科の類似未審査レセプト件数に占める県内・同科の類似査定事例件数の割合のそれぞれを計数する。
【0046】
検索結果記録部42は、未審査レセプト受付部28において未審査レセプトが受け付けられ、検索部32においてその未審査レセプトに対する事例検索処理が実行された場合、統計処理部40における統計処理の結果を、その未審査レセプトのデータと対応づけて検索結果DB24へ格納する。その際、検索結果記録部42は、未審査レセプトの点検結果を参照可能(ダウンロード可能)である旨が記載された電子メールをOA端末12へ送信する。
【0047】
事例情報提供部46は、査定事例検索結果の取得要求をOA端末12から受け付ける。そして、その取得要求において指定されたユニークIDで特定される未審査レセプトのデータであり、統計処理部40における統計処理の結果を含むデータを検索結果記録部42から取得し、レセプト点検結果としてOA端末12へ送信する。すなわち、図6で示したレセプト点検結果の、第1エリア90に表示させるべき未審査レセプトのデータ、第2エリア92に表示させるべきロジック点検結果のデータ、第3エリア94に表示させるべき査定事例検索結果のデータをOA端末12へ提供する。
【0048】
申出書記録部48は、拒絶レセプト受付部30において査定情報が受け付けられ、検索部32においてその査定情報に対する事例検索処理が実行された場合、統計処理部40における統計処理の結果を含む再審査申出書の文書データを申出書DB26へ格納する。その際、申出書記録部48は、再審査申出書を参照可能(ダウンロード可能)である旨が記載された電子メールをOA端末12へ送信する。
【0049】
具体的には、申出書記録部48は、図7で示した再審査申出書における第1エリア200の各記載項目と、査定情報に含まれる査定通知書および拒絶レセプトの各記載内容との対応関係を予め保持する。再審査申出書設定時にはその対応関係を参照して、第1エリア200の各記載項目に対して、査定通知書および拒絶レセプトの各記載内容を設定する。
【0050】
また申出書記録部48は、再審者申出書における第2エリア202に対して、統計処理部40における統計処理の結果を設定する。図7で示したように本実施の形態では、全国・全科の同一未審査レセプト件数、県内・全科の同一未審査レセプト件数、全国・同科の同一未審査レセプト件数、県内・同科の同一未審査レセプト件数と、それぞれに対応する同一査定事例件数を第2エリア202へ設定する。変形例として、査定事例検索結果と同様に、査定の割合を設定してもよいし、類似未審査レセプト件数および類似査定事例件数をさらに設定してもよい。
【0051】
申出書提供部50は、再審査申出書のテンプレートの取得要求をOA端末12から受け付ける。そして、その取得要求で指定された医療機関番号により特定される再審査申出書、言い換えれば、取得要求で指定された医療機関番号が設定された再審査申出書の文書データを申出書DB26から取得し、再審査申出書のテンプレートとしてOA端末12へ送信する。
【0052】
以上の構成による動作を以下説明する。
図9は、図1のOA端末12の動作を示すフローチャートである。OA端末12の未審査レセプト取得部64は、接続されたUSBメモリ内に未審査レセプトが格納されていることを検出すると(S10のY)、その未審査レセプトを読み込む。ロジック点検部66は、未審査レセプトに対するロジック点検処理を実行する(S12)。匿名化部68は、未審査レセプトにおける患者の個人情報に関する所定のデータ項目に対して匿名化処理を実行する(S14)。未審査レセプト送信部70は、匿名化された未審査レセプトのデータを医療事務支援装置14へアップロードする(S16)。未審査レセプトが未検出であれば(S10のN)、S12〜S16はスキップされる。
【0053】
事例情報取得部72は、医療事務担当者から入力された未審査レセプトの点検結果の表示要求を検出すると(S18のY)、未審査レセプトの点検結果(ロジック点検結果および事例検索結果)を示すデータを医療事務支援装置14から取得する(S20)。顕名化部74は、変換テーブル62から患者の個人情報を読み出して、点検結果のデータの顕名化処理を実行する(S22)。事例情報表示制御部76は、顕名化された未審査レセプトの点検結果をディスプレイに表示させる(S24)。未審査レセプトの点検結果の表示要求が未検出であれば(S18のN)、S20〜S24はスキップされる。
【0054】
図10も、図1のOA端末12の動作を示すフローチャートである。OA端末12の拒絶レセプト取得部78は、医療事務担当者から入力された査定情報を検出し(S30のY)、再審査の指定がなされた場合(S32のY)、再審査予定フラグを査定情報のデータに設定する(S34)。再審査の指定がなければ(S32のN)、S34はスキップされる。拒絶レセプト送信部80は、査定情報を医療事務支援装置14へ送信する(S36)。査定情報の入力が未検出であれば(S30のN)、S32〜S36はスキップされる。申出書取得部82は、医療事務担当者から入力された再審査申出書の表示要求を検出すると(S38のY)、申出書取得部82は再審査申出書の文書データを医療事務支援装置14から取得し(S40)、申出書表示制御部84はそのデータを、編集可能な再審査申出書のテンプレートとしてディスプレイに表示させる(S42)。再審査申出書の表示要求が未検出であれば(S38のN)、S40およびS42はスキップされる。
【0055】
図11は、図1の医療事務支援装置14の動作を示すフローチャートである。医療事務支援装置14の未審査レセプト受付部28は、OA端末12から未審査レセプトを受け付けると(S50のY)、その未審査レセプトのデータを未審査レセプトDB20へ格納する(S52)。検索部32は、未審査レセプトに記載された患者への医療行為の内容を検索キーとして査定事例DB22の査定事例を検索し、未審査レセプトの記載内容に対して合致もしくは類似する査定事例を特定する(S54)。統計処理部40は、査定事例検索の結果を審査属性単位(具体的には地域別および診療科別に)集計し(S56)、検索結果記録部42は、集計結果を検索結果DB24へ格納する(S58)。未審査レセプトを受け付けなければ(S50のN)、S52〜S58はスキップされる。
【0056】
続いて事例情報提供部46は、未審査レセプトの点検結果の取得要求をOA端末12から受け付けると(S60のY)、ロジック点検結果および事例検索結果を含む点検結果のデータを検索結果DB24から取得してOA端末12へ送信する(S62)。未審査レセプトの点検結果の取得要求を受け付けなければ(S60のN)、S62はスキップされる。
【0057】
図12も、図1の医療事務支援装置14の動作を示すフローチャートである。医療事務支援装置14の拒絶レセプト受付部30は、OA端末12から査定情報を受け付けると(S70のY)、その査定情報を査定事例DB22へ格納する(S72)。査定情報に再審査予定フラグが設定されている場合(S74のY)、検索部32は、査定情報における拒絶レセプトに記載された患者への医療行為の内容を検索キーとして査定事例DB22の査定事例を検索し、拒絶レセプトの記載内容に対して合致もしくは類似する査定事例を特定する(S76)。統計処理部40は、査定事例検索の結果を審査属性単位(具体的には地域別および診療科別に)集計する(S78)。申出書記録部48は、集計結果を再審理由欄に設定した再審査申出書の文書データを申出書DB26へ格納する(S80)。再審査予定フラグが未設定であれば(S74のN)、S76〜S80はスキップされ、査定情報を受け付けなければ(S70のN)、S72〜S80はスキップされる。
【0058】
続いて申出書提供部50は、再審査申出書の取得要求をOA端末12から受け付けると(S82のY)、再審査申出書のデータを申出書DB26から取得してOA端末12へ送信する(S84)。再審査申出書の取得要求を受け付けなければ(S82のN)、S84はスキップされる。
【0059】
本実施の形態の医療事務支援システム100によれば、医療事務支援装置14においてレセプトの査定事例を蓄積し、未審査レセプトと記載内容が同一・類似の査定事例について、その件数および未審査レセプト数に占める査定件数の割合を医療事務担当者へ提示する。これにより、現状のレセプトの記載が査定されやすいものか否かを示唆することができ、医療事務担当者は、未審査レセプトの記載内容が、審査により拒絶されるリスクの程度を過去の事例を踏まえて判断し、その内容を適宜修正することができる。レセプトの審査結果は、審査者の主観に左右されるものであるところ、医療事務支援システム100によれば、点検ロジックによる静的なチェックだけでなく、合致もしくは類似する記載内容での査定状況を医療事務担当者に提示することで、未審査レセプトの点検作業における精度向上を支援することができる。
【0060】
本実施の形態では、未審査レセプトと記載内容が同一のみならず類似の査定事例も検索して、その検索結果を提供することにより、未審査レセプトの点検作業における精度を一層向上させることができる。例えば、図6の検索結果の第2レコードは、同一査定事例は0件であるものの、類似査定事例は多数存在することを示しており、未審査レセプトの現在の記載内容は不適応と認定されてしまうリスクが高いことを医療事務担当者は把握できる。より具体的には、未審査レセプトにおいて後発医薬品名が記載されていた場合に、後発医薬品と同一視が可能な先発医薬品名が記載された査定事例を把握することができる。
【0061】
また医療事務支援システム100によれば、医療事務支援装置14において検索条件レセプトの審査属性(地域や診療科)に合致する査定事例については他の査定事例と区別して集計して、査定件数や査定割合を医療事務担当者へ提示する。これにより、地域や診療科ごとの審査傾向を医療事務担当者が把握することを容易にし、その傾向に応じて適宜修正を行うことを支援できる。例えば、医療事務担当者は、図6のレセプト点検結果の第1レコードを確認した場合、レセプトの現在の記載は全国的には査定されてしまうリスクが高いが、県内では査定されるリスクが低いため、現状の記載を維持してよいと等の判断ができる。
【0062】
また医療事務支援システム100によれば、図7で示した再審査申出書における第1エリア200の各項目には、各項目に対応づけられた査定通知書の記載内容や、拒絶レセプトの記載内容が自動で設定される。その一方で、再審申出書における第2エリア202、すなわち再審理由欄には、拒絶レセプトに対する査定事例検索の結果が設定される。例えば医師は、再審理由欄の査定事例件数を考慮して再審の有無を判断でき、また、再審理由の1つとして査定事例件数を容易に引用できる。また、第1エリア200にて記載すべき項目の多くが自動で設定されるため、再審査申出書の作成の負担を低減することができる。
【0063】
また医療事務支援システム100によれば、未審査レセプトに記載された患者の個人情報はOA端末12内に保持されて、医療事務支援装置14に渡される未審査レセプトは匿名化されたものとなる。これにより、患者の個人情報の拡散を回避し、また漏洩のリスクを低減することができる。
【0064】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【0065】
第1の変形例を説明する。上記実施の形態では、未審査レセプトの点検結果の画面には同一査定事例の件数および類似査定事例の件数を表示させることとした。変形例としては、医療事務担当者が同一査定事例の表示欄に設けられた所定オブジェクト(件数の表示文字列でもよい)を選択した場合に、同一査定事例の内容をOA端末12のディスプレイに表示させてもよい。同様に、医療事務担当者が類似査定事例の表示欄に設けられた所定オブジェクトを選択した場合に、類似査定事例の内容をOA端末12のディスプレイに表示させてもよい。
【0066】
ここでは、類似査定事例の記載内容を提示する場合の構成例を示すが、同一査定事例の記載内容を提示する場合も同様の構成にて実現できることはもちろんである。
医療事務支援装置14の検索結果記録部42は、統計処理部40により集計された類似査定事例件数(地域・診療科別)を示す文字列に対して、集計対象となった類似査定事例のデータの識別情報(URL等)を指定したハイパーリンクを設定してもよい。医療事務担当者によりそのハイパーリンクが選択されたことを検出すると、事例情報提供部46は、類似査定事例の識別情報を指定してその取得要求を医療事務支援装置14へ送信することにより、類似査定事例の記載内容を示すデータを取得して表示させてもよい。
【0067】
この変形例によると、同一査定事例や類似査定事例の実際の内容を医療事務担当者へ提示することができ、未審査レセプトの点検作業における精度向上を一層支援することができる。特に類似査定事例は、その記載内容が未審査レセプトと異なるものであるため、その記載内容を医療事務担当者へ提示することは好適な態様である。
【0068】
第2の変形例を説明する。上記実施の形態では、類似判定条件として、レセプトの各データ項目の設定値の幅や、先発医薬品と後発医薬品との対応関係について言及した。変形例としては、査定(減点等)の要素が複数ある場合に、特に査定される確率と強い正の相関(例えば、相関係数=0.7から1)を示す要素の組み合わせが類似判定条件として予め定められてもよい。
【0069】
例えば、「この患者は65歳と高齢なので、病名Aに対して医薬品Bは不適応」という査定理由等、病名Aと医薬品Bの組み合わせがレセプト内に存在すると査定される確率が高いという統計データがあるケースを考える。このケースにおいて医療事務支援装置14の類似条件テーブル36は、病名Aと医薬品Bの組み合わせを類似判定条件として保持してもよい。類似事例検索部38は、病名Aと医薬品Bの組み合わせのある全てのレセプトを、他の記載内容の差異にかかわらず類似査定事例として特定してもよい。
【0070】
第3の変形例を説明する。上記実施の形態では、OA端末12は、所定の記録媒体(USBメモリ)を介してレセコン10における未審査レセプトのデータを読み込むこととしたが、レセコン10とOA端末12とはオンラインで接続されてもよいことはもちろんである。また、医療機関から医療事務支援装置14への査定情報の通知においては、査定通知書と拒絶レセプトの書類を、医療機関から医療事務支援装置14の管理者(システム管理会社等)へ送付してもよい。この場合、管理者側では査定通知書と拒絶レセプトの内容をOCR(Optical Character Reader)装置にて読取り、その文字データを医療事務支援装置14の拒絶レセプト受付部30が受け付けてもよい。
【0071】
第4の変形例を説明する。上記実施の形態では、未審査レセプトに対するロジック点検処理をOA端末12で実行することとしたが、このロジック点検処理が医療事務支援装置14で実行されてもよいことはもちろんである。この場合、医療事務支援装置14は、図2で説明したロジックテーブル60およびロジック点検部66をさらに備え、そのロジック点検部66は事例検索の前もしくは後に、OA端末12にて匿名化済の未審査レセプトに対するロジック点検処理を実行する。
【0072】
第5の変形例を説明する。未審査レセプトに対する査定事例検索結果の精度を高めるために査定事例の蓄積は不可欠であるところ、未審査レセプトの点検は行いたいが、査定情報は提供したくないと考える医療機関もあると想定される。医療事務支援装置14の査定事例検索結果の精度を低下させてしまうため望ましい状況ではない。そこで、上記実施の形態では言及していないが、査定情報を提供しない医療機関に対して、未審査レセプトの点検における一種の制限を課してもよい。具体的には、医療事務支援装置14は、医療機関から査定情報が提供された年月(2011年1月、2月等)を保持し、検索部32は、その提供年月以前の査定情報を検索対象の母集団としてもよい。この結果、査定情報の提供を停止した医療機関に対しては、新しい査定事例を反映しない査定事例検索結果が提供されることになり、積極的な査定事例の提供を医療機関に促すことができる。
【0073】
上述した実施の形態、変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態、変形例それぞれの効果をあわせもつ。
【0074】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【0075】
なお、請求項3に記載の内容は以下のように具体化することもできる。すなわち、類似条件保持部は、先発医薬品と後発医薬品との対応関係を保持し、検索部は、複数の査定事例のうち、患者への医療行為の内容が前記未審査レセプトにおける記載内容と不一致であるものの、その不一致の内容が前記対応関係にて定められた先発医薬品と後発医薬品の違いである査定事例を類似事例として特定してもよい。
【符号の説明】
【0076】
10 レセコン、 12 OA端末、 14 医療事務支援装置、 20 未審査レセプトDB、 22 査定事例DB、 24 検索結果DB、 26 申出書DB、 28 未審査レセプト受付部、 30 拒絶レセプト受付部、 32 検索部、 34 同一事例検索部、 36 類似条件テーブル、 38 類似事例検索部、 40 統計処理部、 42 検索結果記録部、 46 事例情報提供部、 48 申出書記録部、 50 申出書提供部、 100 医療事務支援システム。
【技術分野】
【0001】
本発明はデータ処理技術に関し、特に、医療機関における事務作業を支援するための技術に関する。
【背景技術】
【0002】
健康保険を利用して医療を受ける保険診療では、被保険者(患者)が保険者(健康保険組合等)から発行された被保険者証を医療機関へ提示する。この保険診療には、診療報酬が定められている。診療報酬の一部は保険診療を受ける被保険者により医療機関へ支払われ、残りの診療報酬は保険者から医療機関へ支払われる。
【0003】
このとき、医療機関から保険者へ提出される書類をレセプトという。レセプトは、医療機関で保険診療を受けたときの被保険者の自己負担分外の料金を医療機関が保険者へ請求するための診療報酬明細書である。一般的にレセプトは1ヶ月単位で患者ごとの診療内容を入院や外来、医療保険別に分けて規定にフォーマットにとりまとめたものである。
【0004】
レセプトの審査は、都道府県や診療科等の単位で予め定められた審査機関が実施する。この審査機関において、レセプトに記載された診療内容が妥当でないと判断された場合、レセプトの要求通りの診療報酬の支払が拒否されて、減点・減額される場合がある。このため、審査機関へレセプトを提出する前に、医療機関においてレセプトの記載内容を点検する必要がある。以下の特許文献1では、レセプトの点検作業にかかる負担を軽減するための技術が提案されている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2009−193133号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
ところで審査機関においてレセプトを審査する審査者は医師等であり、レセプトの記載内容が許容されるか否かは、審査者の主観的判断に委ねられている面がある。したがって、予め定められた点検ロジックにもとづく機械的なレセプト点検では不十分な場合があると本発明者は考えた。
【0007】
本発明は発明者の上記着想に鑑みてなされたものであり、その目的は、医療機関におけるレセプト点検の精度向上を支援する技術を提供することにある。
【課題を解決するための手段】
【0008】
上記課題を解決するために、本発明のある態様の医療事務支援装置は、医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する査定事例保持部と、医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける未審査レセプト受付部と、複数の査定事例のうち、患者への医療行為の内容が、未審査レセプトにおける記載内容と合致する査定事例を特定する検索部と、合致する査定事例の情報をユーザへ提供する査定事例提供部と、を備える。
【0009】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【0010】
本発明によれば、医療機関におけるレセプト点検の精度向上を支援することができる。
【図面の簡単な説明】
【0011】
【図1】実施の形態の医療事務支援システムの構成を示す図である。
【図2】図1のOA端末の機能構成を示すブロック図である。
【図3】レセプトに設定されるデータ項目を模式的に示す図である。
【図4】変換テーブルに格納されるデータ項目を模式的に示す図である。
【図5】匿名化されたレセプトのデータ項目を模式的に示す図である。
【図6】レセプト点検結果の表示例を示す図である。
【図7】再審査申出書のテンプレートを模式的に示すものである図である。
【図8】図1の医療事務支援装置の機能構成を示すブロック図である。
【図9】図1のOA端末の動作を示すフローチャートである。
【図10】図1のOA端末の動作を示すフローチャートである。
【図11】図1の医療事務支援装置の動作を示すフローチャートである。
【図12】図1の医療事務支援装置の動作を示すフローチャートである。
【発明を実施するための形態】
【0012】
図1は、実施の形態の医療事務支援システムの構成を示す。医療事務支援システム100は、病院や診療所等の医療機関に設置されたOA端末12と、医療機関の外部に設置された医療事務支援装置14を備える。OA端末12は、ウェブブラウザや各種のオフィスソフトウェアがインストールされた一般的なPCであり、医療機関における医療事務の担当者(医師を含む)により操作される。医療事務支援装置14は、複数の医療機関のそれぞれに設置されたOA端末12と接続され、レセプトのチェック作業を支援するための情報をOA端末12へ提供することにより、各医療機関における医療事務の効率化を支援する情報処理装置である。OA端末12と医療事務支援装置14は、LAN・WAN・インターネット等を含む通信網16を介して接続される。
【0013】
医療機関には、OA端末12とともに、レセプトを管理するレセプトコンピュータ(以下、「レセコン10」とも呼ぶ。)が設置される。医療機関で作成されたレセプトは、定期的に健康保険組合等のレセプトの審査機関へ送付される。そして、審査機関における審査においてレセプトでの要求通りの診療報酬の支払が拒否された場合、増減点並びに返戻通知書(以下、「査定通知書」とも呼ぶ。)が審査機関から医療機関へ送付される。
【0014】
図2は、図1のOA端末12の機能構成を示すブロック図である。OA端末12は、ロジックテーブル60と、変換テーブル62と、未審査レセプト取得部64と、ロジック点検部66と、匿名化部68と、未審査レセプト送信部70と、事例情報取得部72と、顕名化部74と、事例情報表示制御部76と、拒絶レセプト取得部78と、拒絶レセプト送信部80と、申出書取得部82と、申出書表示制御部84を備える。
【0015】
本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図2の各機能ブロックは、ソフトウェアとして記録媒体に格納され、OA端末12のハードディスクにインストールされ、OA端末12のメインメモリに適宜読み出されてCPUにて実行されてもよい。後述の図8についても同様である。
【0016】
未審査レセプト取得部64は、医療機関から審査機関へ送付される前のレセプト、言い換えれば、審査機関の審査により承認されるかもしくは拒否されるかが未確定のレセプト(以下、「未審査レセプト」とも呼ぶ。)を取得する。本実施の形態では、医療事務の担当者がレセコン10に保持された未審査レセプトのデータをUSBメモリへ書き出し、そのUSBメモリをOA端末12へ装着する。未審査レセプト取得部64は、USBメモリに格納された未審査レセプトを検出して、そのデータを読み込む。
【0017】
図3は、レセプトに設定されるデータ項目を模式的に示す。実際のレセプトに設定されるデータ項目は多岐に亘るが、実施の形態では説明の簡明化のため、一部の項目のみを示すこととする。図3の(a)のデータ項目と図3の(b)のデータ項目は実際には1レコードとして連結されており、保険診療を受けた患者単位に設定される。
【0018】
図2に戻り、ロジックテーブル60は、レセプトの各データ項目の設定値や、複数のデータ項目の設定値の組み合わせが妥当か否かを点検するための点検ロジックを保持する記憶領域である。例えば、点検ロジックには、レセプトの医薬品名フィールドに設定される医薬品の適正な用法・用量を示すデータが含まれる。また、医薬品名やその用法・用量が、患者の年齢や疾病との組み合わせにおいて適応と認められる可能性が高い組み合わせを示すデータが含まれる。
【0019】
ロジック点検部66は、ロジックテーブル60に格納された点検ロジックにしたがって、未審査レセプトの各データ項目の設定値が妥当なものか否かを点検するロジック点検処理を実行する。ロジック点検部66は、ロジック点検処理の結果として、レセプトの各項目の設定値が、不適応と認定される可能性があるか否かを示すメッセージを出力する。ロジック点検処理の結果の具体例は、図6に関連して後述する。
【0020】
変換テーブル62は、複数の医療機関に亘って未審査レセプトの各レコード(各患者の未審査レセプト)を一意に識別するための識別情報であるユニークIDと、各患者の個人情報とを対応付けて保持する記憶領域である。図4は、変換テーブル62に格納されるデータ項目を模式的に示す。同図で示すように、図3の(a)で示したレセプトの各項目がユニークIDと対応づけられる。
【0021】
図2に戻り、匿名化部68は、未審査レセプトのデータの匿名化処理、言い換えれば、患者の特定を困難にするための、患者の個人情報を削除もしくは抽象化する処理を実行する。具体的には、まず、未審査レセプトにおける患者のレコードごとにユニークIDを採番する。そして、図3の(a)で示したレセプトの各項目とユニークIDとを対応づけて変換テーブル62へ格納する。
【0022】
続いて匿名化部68は、レセプトのデータ項目のうち、被保険者証記号/番号と、カルテ番号と、氏名を削除する。また、医療機関番号における都道府県コード以外を削除して都道府県コードのみとし、生年月日における生年以外を削除して生年のみとする。そして、このように匿名化したレセプトのデータをユニークIDと対応づけて未審査レセプト送信部70に渡す。
【0023】
図5は、匿名化されたレセプトのデータ項目を模式的に示す。図5の(a)のデータ項目と図5の(b)のデータ項目もまた実際には1レコードである。同図で示すように、匿名化されたレセプトの各データは、ユニークIDと対応づけられる。また、未審査レセプトに対するロジック点検部66によるロジック点検の結果が付加されている。
【0024】
図2に戻り、未審査レセプト送信部70は、匿名化された未審査レセプトのデータを医療事務支援装置14へ送信する。詳細は後述するが、本実施の形態の医療事務支援装置14は、OA端末12から受け付けた匿名化された未審査レセプトのデータをもとに、医療事務支援装置14に蓄積された査定事例を検索する。その検索処理が完了すると、医療事務支援装置14は、その完了の旨を記載した電子メールをOA端末12へ送信する。この電子メールには、査定事例の検索結果を表示するウェブページへのハイパーリンクが設定されていてもよく、電子メールを確認した医療事務の担当者がそのハイパーリンクを選択した場合に、事例情報取得部72が、査定事例検索結果の取得要求を検出してもよい。
【0025】
事例情報取得部72は、査定事例検索結果の取得要求を医療事務担当者から受け付けると、その取得要求を医療事務支援装置14へ送信する。この取得要求では、未審査レセプト送信部70により医療事務支援装置14へ送信された未審査レセプトにおいて指定されたユニークIDが指定されてもよい。続いて事例情報取得部72は、査定事例の検索結果のデータを医療事務支援装置14から取得する。ここでの取得データは、図5の(a)および(b)のデータに、査定事例の検索結果が付加されたものとし、以下では「レセプト点検結果」とも呼ぶ。図6に関して後述するが、レセプト点検結果における査定事例の検索結果には、同一事例における査定件数と査定割合、類似事例における査定件数と査定割合を示す情報が含まれる。
【0026】
顕名化部74は、変換テーブル62を参照して、レセプト点検結果のユニークIDと対応づけられたデータ(図4の被保険者証記号/番号〜生年月日、すなわち予め変換テーブル62へ待避された患者の個人情報)を取得して、レセプト点検結果を顕名化する。例えば、ユニークIDと対応づけられた被保険者証記号/番号、医療機関コード、カルテ番号、氏名、生年月日をレセプト点検結果に付加し、もしくは抽象化された医療機関コードや生年と置き換える。
【0027】
事例情報表示制御部76は、顕名化部74により顕名化されたレセプト点検結果をディスプレイに表示させる。なお、レセプト点検結果のデータがウェブページとして提供される場合、事例情報表示制御部76はウェブブラウザへウェブページを提供して、ウェブブラウザにレセプト点検結果を表示させてもよい。
【0028】
図6は、レセプト点検結果の表示例を示す。同図の第1エリア90には、レセプトの情報が表示される。第2エリア92には、ロジック点検部66によるロジック点検の結果が表示される。第3エリア94には、医療事務支援装置14による査定事例検索の結果が表示される。本実施の形態では、査定事例検索の結果として、同一事例(すなわちレセプトの生年、疾病名、診療行為名、医薬品名の設定値が同一の査定事例)と、類似事例(上記の設定値が同一ではないものの、類似すると想定される査定事例)のそれぞれについて、全国/県内、全科/同科の組み合わせごとの査定事例件数が件数フィールド96にて提示される。また、全未審査レセプト件数に占める査定事例件数の割合が、割合フィールド98にて提示される。
【0029】
図2に戻り、拒絶レセプト取得部78は、医療事務担当者により入力された、査定通知書に記載された情報、および、査定の対象となったレセプト(以下、「拒絶レセプト」とも呼ぶ。)に記載された情報を受け付ける。以下、これらの情報を総称して「査定情報」とも呼ぶ。査定情報を入力する際に医療事務担当者は、再審査を申立予定のレセプトを指定し、拒絶レセプト取得部78は、指定されたレセプトの査定情報に対して、再審査予定フラグを設定する。
【0030】
なお拒絶レセプト取得部78は、医療事務担当者からの査定情報の入力要求を受け付けて、査定情報の入力画面をディスプレイに表示させてもよい。そして、医療事務担当者が入力した査定情報および再審査申立の指定を、その入力画面を介して取得してもよい。
【0031】
拒絶レセプト送信部80は、再審査予定フラグが適宜設定された査定情報を医療事務支援装置14へ送信する。医療事務支援装置14は、再審査申出書のテンプレートを設定完了すると、その完了の旨を記載した電子メールをOA端末12へ送信する。この電子メールには、再審査申出書のテンプレートを取得するためのウェブページへのハイパーリンクが設定されていてもよく、電子メールを確認した医療事務の担当者がそのハイパーリンクを選択した場合に、申出書取得部82が再審査申出書のテンプレートの取得要求を検出してもよい。
【0032】
申出書取得部82は、再審査申出書のテンプレートの取得要求を医療事務担当者から受け付けると、その取得要求を医療事務支援装置14へ送信する。この取得要求では再審査申出書のキーとして医療機関番号が指定されることとする。申出書取得部82は、再審査申出書のテンプレートのデータを医療事務支援装置14から取得する。このテンプレートのデータは、例えば、所定のワープロソフトで定められたデータ形式であってもよい。申出書表示制御部84は、申出書取得部82により取得された再審査申出書のテンプレートのデータを編集可能な状態でディスプレイに表示させる。
【0033】
図7は、再審査申出書のテンプレートを模式的に示すものである。再審査申出書における第1エリア200には、各記入項目に予め対応づけられた査定通知書の記載内容や、拒絶レセプトの記載内容が自動で設定される。その一方で、再審申出書における第2エリア202(すなわち再審理由欄)には、拒絶レセプトに対する査定事例検索の結果が設定される。
【0034】
図8は、図1の医療事務支援装置14の機能構成を示すブロック図である。医療事務支援装置14は、未審査レセプトDB20と、査定事例DB22と、検索結果DB24と、申出書DB26と、未審査レセプト受付部28と、拒絶レセプト受付部30と、検索部32と、統計処理部40と、検索結果記録部42と、事例情報提供部46と、申出書記録部48と、申出書提供部50とを備える。
【0035】
未審査レセプトDB(データベース)20は、未審査レセプトを保持する記憶領域である。未審査レセプトのデータ構成は、図5の(a)および(b)にて既述したとおりである。査定事例DB22は、査定通知書および拒絶レセプトの記載内容を含む査定情報を査定事例として、複数の査定事例を保持する記憶領域である。査定通知書のデータは査定理由等を含むものであり、拒絶レセプトのデータ構成は、図3の(a)および(b)で既述したとおりである。検索結果DB24は、検索部32による事例検索結果のデータを保持する記憶領域である。申出書DB26は、申出書記録部48により設定された再審査申出書のデータを保持する記憶領域である。
【0036】
未審査レセプト受付部28は、医療機関のOA端末12から送信された未審査レセプトのデータを受け付けて未審査レセプトDB20へ格納する。拒絶レセプト受付部30は、医療機関のOA端末12から送信された査定情報を受け付けて査定事例DB22へ格納する。
【0037】
検索部32は、未審査レセプト受付部28において未審査レセプトが受け付けられた場合、その未審査レセプトに記載された医療行為の内容を検索キーとして査定事例を検索する。また検索部32は、拒絶レセプト受付部30において査定情報が受け付けられて、その査定情報に再審査予定フラグが設定されている場合、その査定情報に記載された医療行為の内容を検索キーとして査定事例を検索する、検索部32は、同一事例検索部34と、類似条件テーブル36と、類似事例検索部38とを含む。以下では、事例検索の対象となる未審査レセプトおよび拒絶レセプトを適宜「検索条件レセプト」とも称する。
【0038】
同一事例検索部34は、査定事例DB22に格納された査定事例のうち、検索条件レセプトに記載された患者の生年、性別、疾病名、診療行為名、医薬品名(用法、用量を含む)に合致する記載内容の査定事例を同一査定事例として特定する。変形例として、上記組み合わせの一部が合致する査定事例、例えば、疾病名、診療行為名、医薬品名の組み合わせが合致する査定事例を同一査定事例として特定してもよい。また同一事例検索部34は、未審査レセプトDB20に格納された未審査レセプトのうち、記載内容(同一査定事例を特定する場合と同様の上記データ項目の内容)が検索条件レセプトと合致する未審査レセプトを同一未審査レセプトとして特定する。
【0039】
類似条件テーブル36は、検索条件レセプトの記載内容と査定事例の記載内容とが異なる場合であっても、双方の記載内容を類似するものとして判定すべき条件(以下、「類似判定条件」とも呼ぶ。)を保持する記憶領域である。この類似判定条件としては、類似したものとして予め想定される年齢の幅や、医薬品の用法・用量の幅が設定される。例えば、検索条件レセプトにおける生年が1975年の場合、生年1970年〜1974年、1976年〜1980年を類似範囲として設定されてもよい。また別の類似判定条件としては、先発医薬品(オリジナル薬、新薬とも呼ばれる)と後発医薬品(ジェネリック医薬品とも呼ばれる)との対応関係が設定される。
【0040】
類似事例検索部38は、医療行為の内容が検索条件レセプトと異なる査定事例のうち、類似条件テーブル36に格納された類似判定条件に整合する査定事例を類似査定事例として特定する。例えば、検索条件レセプトの医薬品名フィールドに後発医薬品が記載されている場合、その後発医薬品に対応する先発医薬品が医薬品名フィールドに記載された査定事例を類似査定事例として特定する。その逆の場合も同様である。また類似事例検索部38は、未審査レセプトDB20に格納された未審査レセプトのうち、医療行為の内容が検索条件レセプトと異なり、かつ、その差異が類似判定条件に整合する未審査レセプトを類似未審査レセプトとして特定する。
【0041】
統計処理部40は、同一事例検索部34において特定された同一査定事例に対して、審査の属性を基準とした統計処理を実行する。本実施の形態では、都道府県および診療科ごとにレセプトの審査主体が異なることを前提として、審査主体の属性である都道府県および診療科ごとの同一査定事例件数を集計する。
【0042】
具体的には、統計処理部40は、同一査定事例の総数を全国・全科の同一査定事例件数として計数する。また、医療機関コードにおける都道府県コードが検索条件レセプトの記載内容と合致する同一査定事例の件数を、県内・全科の同一査定事例件数として計数する。また、診療科が検索条件レセプトの記載内容と合致する同一査定事例の件数を全国・同科の同一査定事例件数として計数する。また、医療機関コードにおける都道府県コードと診療科の両方が、検索条件レセプトの記載内容と合致する同一査定事例の件数を県内・同科の同一査定事例件数として計数する。
【0043】
また統計処理部40は、類似事例検索部38において特定された類似査定事例に対しても、上記の同一査定事例の場合と同様に、審査の属性を基準とした統計処理を実行する。すなわち、類似査定事例の総数を全国・全科の類似査定事例件数として計数する。また、医療機関コードにおける都道府県コードが検索条件レセプトの記載内容と合致する類似査定事例の件数を、県内・全科の類似査定事例件数として計数する。また、診療科が検索条件レセプトの記載内容と合致する類似査定事例の件数を全国・同科の類似査定事例件数として計数する。また、医療機関コードにおける都道府県コードおよび診療科が、検索条件レセプトの記載内容と合致する類似査定事例の件数を県内・同科の類似査定事例件数として計数する。
【0044】
また統計処理部40は、同一事例検索部34において特定された同一未審査レセプトに対して同一査定事例に対する統計処理と同様の統計処理を実行し、全国・全科の同一未審査レセプト件数、県内・全科の同一未審査レセプト件数、全国・同科の同一未審査レセプト件数、県内・同科の同一未審査レセプト件数のそれぞれを計数する。そして、全国・全科の同一未審査レセプト件数に占める全国・全科の同一査定事例件数の割合、県内・全科の同一未審査レセプト件数に占める県内・全科の同一査定事例件数の割合、全国・同科の同一未審査レセプト件数に占める全国・同科の同一査定事例件数の割合、県内・同科の同一未審査レセプト件数に占める県内・同科の同一査定事例件数の割合のそれぞれを計数する。
【0045】
また統計処理部40は、類似事例検索部38において特定された類似未審査レセプトに対しても類似査定事例に対する統計処理と同様の統計処理を実行し、全国・全科の類似未審査レセプト件数、県内・全科の類似未審査レセプト件数、全国・同科の類似未審査レセプト件数、県内・同科の類似未審査レセプト件数のそれぞれを計数する。そして、全国・全科の類似未審査レセプト件数に占める全国・全科の類似査定事例件数の割合、県内・全科の類似未審査レセプト件数に占める県内・全科の類似査定事例件数の割合、全国・同科の類似未審査レセプト件数に占める全国・同科の類似査定事例件数の割合、県内・同科の類似未審査レセプト件数に占める県内・同科の類似査定事例件数の割合のそれぞれを計数する。
【0046】
検索結果記録部42は、未審査レセプト受付部28において未審査レセプトが受け付けられ、検索部32においてその未審査レセプトに対する事例検索処理が実行された場合、統計処理部40における統計処理の結果を、その未審査レセプトのデータと対応づけて検索結果DB24へ格納する。その際、検索結果記録部42は、未審査レセプトの点検結果を参照可能(ダウンロード可能)である旨が記載された電子メールをOA端末12へ送信する。
【0047】
事例情報提供部46は、査定事例検索結果の取得要求をOA端末12から受け付ける。そして、その取得要求において指定されたユニークIDで特定される未審査レセプトのデータであり、統計処理部40における統計処理の結果を含むデータを検索結果記録部42から取得し、レセプト点検結果としてOA端末12へ送信する。すなわち、図6で示したレセプト点検結果の、第1エリア90に表示させるべき未審査レセプトのデータ、第2エリア92に表示させるべきロジック点検結果のデータ、第3エリア94に表示させるべき査定事例検索結果のデータをOA端末12へ提供する。
【0048】
申出書記録部48は、拒絶レセプト受付部30において査定情報が受け付けられ、検索部32においてその査定情報に対する事例検索処理が実行された場合、統計処理部40における統計処理の結果を含む再審査申出書の文書データを申出書DB26へ格納する。その際、申出書記録部48は、再審査申出書を参照可能(ダウンロード可能)である旨が記載された電子メールをOA端末12へ送信する。
【0049】
具体的には、申出書記録部48は、図7で示した再審査申出書における第1エリア200の各記載項目と、査定情報に含まれる査定通知書および拒絶レセプトの各記載内容との対応関係を予め保持する。再審査申出書設定時にはその対応関係を参照して、第1エリア200の各記載項目に対して、査定通知書および拒絶レセプトの各記載内容を設定する。
【0050】
また申出書記録部48は、再審者申出書における第2エリア202に対して、統計処理部40における統計処理の結果を設定する。図7で示したように本実施の形態では、全国・全科の同一未審査レセプト件数、県内・全科の同一未審査レセプト件数、全国・同科の同一未審査レセプト件数、県内・同科の同一未審査レセプト件数と、それぞれに対応する同一査定事例件数を第2エリア202へ設定する。変形例として、査定事例検索結果と同様に、査定の割合を設定してもよいし、類似未審査レセプト件数および類似査定事例件数をさらに設定してもよい。
【0051】
申出書提供部50は、再審査申出書のテンプレートの取得要求をOA端末12から受け付ける。そして、その取得要求で指定された医療機関番号により特定される再審査申出書、言い換えれば、取得要求で指定された医療機関番号が設定された再審査申出書の文書データを申出書DB26から取得し、再審査申出書のテンプレートとしてOA端末12へ送信する。
【0052】
以上の構成による動作を以下説明する。
図9は、図1のOA端末12の動作を示すフローチャートである。OA端末12の未審査レセプト取得部64は、接続されたUSBメモリ内に未審査レセプトが格納されていることを検出すると(S10のY)、その未審査レセプトを読み込む。ロジック点検部66は、未審査レセプトに対するロジック点検処理を実行する(S12)。匿名化部68は、未審査レセプトにおける患者の個人情報に関する所定のデータ項目に対して匿名化処理を実行する(S14)。未審査レセプト送信部70は、匿名化された未審査レセプトのデータを医療事務支援装置14へアップロードする(S16)。未審査レセプトが未検出であれば(S10のN)、S12〜S16はスキップされる。
【0053】
事例情報取得部72は、医療事務担当者から入力された未審査レセプトの点検結果の表示要求を検出すると(S18のY)、未審査レセプトの点検結果(ロジック点検結果および事例検索結果)を示すデータを医療事務支援装置14から取得する(S20)。顕名化部74は、変換テーブル62から患者の個人情報を読み出して、点検結果のデータの顕名化処理を実行する(S22)。事例情報表示制御部76は、顕名化された未審査レセプトの点検結果をディスプレイに表示させる(S24)。未審査レセプトの点検結果の表示要求が未検出であれば(S18のN)、S20〜S24はスキップされる。
【0054】
図10も、図1のOA端末12の動作を示すフローチャートである。OA端末12の拒絶レセプト取得部78は、医療事務担当者から入力された査定情報を検出し(S30のY)、再審査の指定がなされた場合(S32のY)、再審査予定フラグを査定情報のデータに設定する(S34)。再審査の指定がなければ(S32のN)、S34はスキップされる。拒絶レセプト送信部80は、査定情報を医療事務支援装置14へ送信する(S36)。査定情報の入力が未検出であれば(S30のN)、S32〜S36はスキップされる。申出書取得部82は、医療事務担当者から入力された再審査申出書の表示要求を検出すると(S38のY)、申出書取得部82は再審査申出書の文書データを医療事務支援装置14から取得し(S40)、申出書表示制御部84はそのデータを、編集可能な再審査申出書のテンプレートとしてディスプレイに表示させる(S42)。再審査申出書の表示要求が未検出であれば(S38のN)、S40およびS42はスキップされる。
【0055】
図11は、図1の医療事務支援装置14の動作を示すフローチャートである。医療事務支援装置14の未審査レセプト受付部28は、OA端末12から未審査レセプトを受け付けると(S50のY)、その未審査レセプトのデータを未審査レセプトDB20へ格納する(S52)。検索部32は、未審査レセプトに記載された患者への医療行為の内容を検索キーとして査定事例DB22の査定事例を検索し、未審査レセプトの記載内容に対して合致もしくは類似する査定事例を特定する(S54)。統計処理部40は、査定事例検索の結果を審査属性単位(具体的には地域別および診療科別に)集計し(S56)、検索結果記録部42は、集計結果を検索結果DB24へ格納する(S58)。未審査レセプトを受け付けなければ(S50のN)、S52〜S58はスキップされる。
【0056】
続いて事例情報提供部46は、未審査レセプトの点検結果の取得要求をOA端末12から受け付けると(S60のY)、ロジック点検結果および事例検索結果を含む点検結果のデータを検索結果DB24から取得してOA端末12へ送信する(S62)。未審査レセプトの点検結果の取得要求を受け付けなければ(S60のN)、S62はスキップされる。
【0057】
図12も、図1の医療事務支援装置14の動作を示すフローチャートである。医療事務支援装置14の拒絶レセプト受付部30は、OA端末12から査定情報を受け付けると(S70のY)、その査定情報を査定事例DB22へ格納する(S72)。査定情報に再審査予定フラグが設定されている場合(S74のY)、検索部32は、査定情報における拒絶レセプトに記載された患者への医療行為の内容を検索キーとして査定事例DB22の査定事例を検索し、拒絶レセプトの記載内容に対して合致もしくは類似する査定事例を特定する(S76)。統計処理部40は、査定事例検索の結果を審査属性単位(具体的には地域別および診療科別に)集計する(S78)。申出書記録部48は、集計結果を再審理由欄に設定した再審査申出書の文書データを申出書DB26へ格納する(S80)。再審査予定フラグが未設定であれば(S74のN)、S76〜S80はスキップされ、査定情報を受け付けなければ(S70のN)、S72〜S80はスキップされる。
【0058】
続いて申出書提供部50は、再審査申出書の取得要求をOA端末12から受け付けると(S82のY)、再審査申出書のデータを申出書DB26から取得してOA端末12へ送信する(S84)。再審査申出書の取得要求を受け付けなければ(S82のN)、S84はスキップされる。
【0059】
本実施の形態の医療事務支援システム100によれば、医療事務支援装置14においてレセプトの査定事例を蓄積し、未審査レセプトと記載内容が同一・類似の査定事例について、その件数および未審査レセプト数に占める査定件数の割合を医療事務担当者へ提示する。これにより、現状のレセプトの記載が査定されやすいものか否かを示唆することができ、医療事務担当者は、未審査レセプトの記載内容が、審査により拒絶されるリスクの程度を過去の事例を踏まえて判断し、その内容を適宜修正することができる。レセプトの審査結果は、審査者の主観に左右されるものであるところ、医療事務支援システム100によれば、点検ロジックによる静的なチェックだけでなく、合致もしくは類似する記載内容での査定状況を医療事務担当者に提示することで、未審査レセプトの点検作業における精度向上を支援することができる。
【0060】
本実施の形態では、未審査レセプトと記載内容が同一のみならず類似の査定事例も検索して、その検索結果を提供することにより、未審査レセプトの点検作業における精度を一層向上させることができる。例えば、図6の検索結果の第2レコードは、同一査定事例は0件であるものの、類似査定事例は多数存在することを示しており、未審査レセプトの現在の記載内容は不適応と認定されてしまうリスクが高いことを医療事務担当者は把握できる。より具体的には、未審査レセプトにおいて後発医薬品名が記載されていた場合に、後発医薬品と同一視が可能な先発医薬品名が記載された査定事例を把握することができる。
【0061】
また医療事務支援システム100によれば、医療事務支援装置14において検索条件レセプトの審査属性(地域や診療科)に合致する査定事例については他の査定事例と区別して集計して、査定件数や査定割合を医療事務担当者へ提示する。これにより、地域や診療科ごとの審査傾向を医療事務担当者が把握することを容易にし、その傾向に応じて適宜修正を行うことを支援できる。例えば、医療事務担当者は、図6のレセプト点検結果の第1レコードを確認した場合、レセプトの現在の記載は全国的には査定されてしまうリスクが高いが、県内では査定されるリスクが低いため、現状の記載を維持してよいと等の判断ができる。
【0062】
また医療事務支援システム100によれば、図7で示した再審査申出書における第1エリア200の各項目には、各項目に対応づけられた査定通知書の記載内容や、拒絶レセプトの記載内容が自動で設定される。その一方で、再審申出書における第2エリア202、すなわち再審理由欄には、拒絶レセプトに対する査定事例検索の結果が設定される。例えば医師は、再審理由欄の査定事例件数を考慮して再審の有無を判断でき、また、再審理由の1つとして査定事例件数を容易に引用できる。また、第1エリア200にて記載すべき項目の多くが自動で設定されるため、再審査申出書の作成の負担を低減することができる。
【0063】
また医療事務支援システム100によれば、未審査レセプトに記載された患者の個人情報はOA端末12内に保持されて、医療事務支援装置14に渡される未審査レセプトは匿名化されたものとなる。これにより、患者の個人情報の拡散を回避し、また漏洩のリスクを低減することができる。
【0064】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【0065】
第1の変形例を説明する。上記実施の形態では、未審査レセプトの点検結果の画面には同一査定事例の件数および類似査定事例の件数を表示させることとした。変形例としては、医療事務担当者が同一査定事例の表示欄に設けられた所定オブジェクト(件数の表示文字列でもよい)を選択した場合に、同一査定事例の内容をOA端末12のディスプレイに表示させてもよい。同様に、医療事務担当者が類似査定事例の表示欄に設けられた所定オブジェクトを選択した場合に、類似査定事例の内容をOA端末12のディスプレイに表示させてもよい。
【0066】
ここでは、類似査定事例の記載内容を提示する場合の構成例を示すが、同一査定事例の記載内容を提示する場合も同様の構成にて実現できることはもちろんである。
医療事務支援装置14の検索結果記録部42は、統計処理部40により集計された類似査定事例件数(地域・診療科別)を示す文字列に対して、集計対象となった類似査定事例のデータの識別情報(URL等)を指定したハイパーリンクを設定してもよい。医療事務担当者によりそのハイパーリンクが選択されたことを検出すると、事例情報提供部46は、類似査定事例の識別情報を指定してその取得要求を医療事務支援装置14へ送信することにより、類似査定事例の記載内容を示すデータを取得して表示させてもよい。
【0067】
この変形例によると、同一査定事例や類似査定事例の実際の内容を医療事務担当者へ提示することができ、未審査レセプトの点検作業における精度向上を一層支援することができる。特に類似査定事例は、その記載内容が未審査レセプトと異なるものであるため、その記載内容を医療事務担当者へ提示することは好適な態様である。
【0068】
第2の変形例を説明する。上記実施の形態では、類似判定条件として、レセプトの各データ項目の設定値の幅や、先発医薬品と後発医薬品との対応関係について言及した。変形例としては、査定(減点等)の要素が複数ある場合に、特に査定される確率と強い正の相関(例えば、相関係数=0.7から1)を示す要素の組み合わせが類似判定条件として予め定められてもよい。
【0069】
例えば、「この患者は65歳と高齢なので、病名Aに対して医薬品Bは不適応」という査定理由等、病名Aと医薬品Bの組み合わせがレセプト内に存在すると査定される確率が高いという統計データがあるケースを考える。このケースにおいて医療事務支援装置14の類似条件テーブル36は、病名Aと医薬品Bの組み合わせを類似判定条件として保持してもよい。類似事例検索部38は、病名Aと医薬品Bの組み合わせのある全てのレセプトを、他の記載内容の差異にかかわらず類似査定事例として特定してもよい。
【0070】
第3の変形例を説明する。上記実施の形態では、OA端末12は、所定の記録媒体(USBメモリ)を介してレセコン10における未審査レセプトのデータを読み込むこととしたが、レセコン10とOA端末12とはオンラインで接続されてもよいことはもちろんである。また、医療機関から医療事務支援装置14への査定情報の通知においては、査定通知書と拒絶レセプトの書類を、医療機関から医療事務支援装置14の管理者(システム管理会社等)へ送付してもよい。この場合、管理者側では査定通知書と拒絶レセプトの内容をOCR(Optical Character Reader)装置にて読取り、その文字データを医療事務支援装置14の拒絶レセプト受付部30が受け付けてもよい。
【0071】
第4の変形例を説明する。上記実施の形態では、未審査レセプトに対するロジック点検処理をOA端末12で実行することとしたが、このロジック点検処理が医療事務支援装置14で実行されてもよいことはもちろんである。この場合、医療事務支援装置14は、図2で説明したロジックテーブル60およびロジック点検部66をさらに備え、そのロジック点検部66は事例検索の前もしくは後に、OA端末12にて匿名化済の未審査レセプトに対するロジック点検処理を実行する。
【0072】
第5の変形例を説明する。未審査レセプトに対する査定事例検索結果の精度を高めるために査定事例の蓄積は不可欠であるところ、未審査レセプトの点検は行いたいが、査定情報は提供したくないと考える医療機関もあると想定される。医療事務支援装置14の査定事例検索結果の精度を低下させてしまうため望ましい状況ではない。そこで、上記実施の形態では言及していないが、査定情報を提供しない医療機関に対して、未審査レセプトの点検における一種の制限を課してもよい。具体的には、医療事務支援装置14は、医療機関から査定情報が提供された年月(2011年1月、2月等)を保持し、検索部32は、その提供年月以前の査定情報を検索対象の母集団としてもよい。この結果、査定情報の提供を停止した医療機関に対しては、新しい査定事例を反映しない査定事例検索結果が提供されることになり、積極的な査定事例の提供を医療機関に促すことができる。
【0073】
上述した実施の形態、変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態、変形例それぞれの効果をあわせもつ。
【0074】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【0075】
なお、請求項3に記載の内容は以下のように具体化することもできる。すなわち、類似条件保持部は、先発医薬品と後発医薬品との対応関係を保持し、検索部は、複数の査定事例のうち、患者への医療行為の内容が前記未審査レセプトにおける記載内容と不一致であるものの、その不一致の内容が前記対応関係にて定められた先発医薬品と後発医薬品の違いである査定事例を類似事例として特定してもよい。
【符号の説明】
【0076】
10 レセコン、 12 OA端末、 14 医療事務支援装置、 20 未審査レセプトDB、 22 査定事例DB、 24 検索結果DB、 26 申出書DB、 28 未審査レセプト受付部、 30 拒絶レセプト受付部、 32 検索部、 34 同一事例検索部、 36 類似条件テーブル、 38 類似事例検索部、 40 統計処理部、 42 検索結果記録部、 46 事例情報提供部、 48 申出書記録部、 50 申出書提供部、 100 医療事務支援システム。
【特許請求の範囲】
【請求項1】
医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する査定事例保持部と、
医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける未審査レセプト受付部と、
前記複数の査定事例のうち、患者への医療行為の内容が、前記未審査レセプトにおける記載内容と合致する査定事例を特定する検索部と、
前記合致する査定事例の情報をユーザへ提供する査定事例提供部と、
を備えることを特徴とする医療事務支援装置。
【請求項2】
前記複数の査定事例のそれぞれは、審査の属性を示す審査属性情報を含むものであり、
前記未審査レセプトも、前記審査属性情報を含むものであり、
前記検索部は、前記合致する査定事例のうち、前記未審査レセプトに記載された審査属性情報を含む査定事例をさらに特定し、
前記査定事例提供部は、前記合致する査定事例の情報をユーザへ提供する際、前記未審査レセプトに記載された審査属性情報を含む査定事例を識別可能な態様で提供することを特徴とする請求項1に記載の医療事務支援装置。
【請求項3】
前記未審査レセプトにおける記載内容と前記査定事例における記載内容とが異なる場合であっても類似するものとして判定すべき所定の条件を示す情報を保持する類似条件保持部をさらに備え、
前記検索部は、前記複数の査定事例のうち、患者への医療行為の内容が前記未審査レセプトにおける記載内容と不一致であるものの、その不一致の内容が前記条件と整合する査定事例を類似事例としてさらに特定し、
前記査定事例提供部は、前記類似事例の情報をユーザへさらに提供することを特徴とする請求項1または2に記載の医療事務支援装置。
【請求項4】
前記未審査レセプトの情報を蓄積して保持する未審査レセプト保持部をさらに備え、
前記検索部は、前記未審査レセプト受付部において新たな未審査レセプトが受け付けられた場合、前記未審査レセプト保持部に蓄積された未審査レセプトのうち、患者への医療行為の内容が、前記新たな未審査レセプトにおける記載内容と合致する未審査レセプトをさらに特定し、
前記査定事例提供部は、前記合致する未審査レセプトの件数に占める前記合致する査定事例の件数の割合を示す情報をユーザへさらに提供することを特徴とする請求項1から3のいずれかに記載の医療事務支援装置。
【請求項5】
前記審査機関により拒絶されたレセプトであって、かつ、再審査申立を行うべきレセプトの情報をユーザから受け付ける拒絶レセプト受付部と、
文書提供部と、
をさらに備え、
前記検索部は、前記複数の査定事例のうち、患者への医療行為の内容が、前記拒絶されたレセプトにおける記載内容と合致する査定事例を特定し、
前記文書提供部は、再審査申出書の文書データにおける再審理由の入力エリアに対して前記合致する査定事例の情報を設定した上で、その再審査申出書の文書データをユーザへ提供することを特徴とする請求項1から3のいずれかに記載の医療事務支援装置。
【請求項6】
医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する機能と、
医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける機能と、
前記複数の査定事例のうち、患者への医療行為の内容が、前記未審査レセプトにおける記載内容と合致する査定事例を特定する機能と、
前記合致する査定事例の情報をユーザへ提供する機能と、
をコンピュータに実現させるためのコンピュータプログラム。
【請求項1】
医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する査定事例保持部と、
医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける未審査レセプト受付部と、
前記複数の査定事例のうち、患者への医療行為の内容が、前記未審査レセプトにおける記載内容と合致する査定事例を特定する検索部と、
前記合致する査定事例の情報をユーザへ提供する査定事例提供部と、
を備えることを特徴とする医療事務支援装置。
【請求項2】
前記複数の査定事例のそれぞれは、審査の属性を示す審査属性情報を含むものであり、
前記未審査レセプトも、前記審査属性情報を含むものであり、
前記検索部は、前記合致する査定事例のうち、前記未審査レセプトに記載された審査属性情報を含む査定事例をさらに特定し、
前記査定事例提供部は、前記合致する査定事例の情報をユーザへ提供する際、前記未審査レセプトに記載された審査属性情報を含む査定事例を識別可能な態様で提供することを特徴とする請求項1に記載の医療事務支援装置。
【請求項3】
前記未審査レセプトにおける記載内容と前記査定事例における記載内容とが異なる場合であっても類似するものとして判定すべき所定の条件を示す情報を保持する類似条件保持部をさらに備え、
前記検索部は、前記複数の査定事例のうち、患者への医療行為の内容が前記未審査レセプトにおける記載内容と不一致であるものの、その不一致の内容が前記条件と整合する査定事例を類似事例としてさらに特定し、
前記査定事例提供部は、前記類似事例の情報をユーザへさらに提供することを特徴とする請求項1または2に記載の医療事務支援装置。
【請求項4】
前記未審査レセプトの情報を蓄積して保持する未審査レセプト保持部をさらに備え、
前記検索部は、前記未審査レセプト受付部において新たな未審査レセプトが受け付けられた場合、前記未審査レセプト保持部に蓄積された未審査レセプトのうち、患者への医療行為の内容が、前記新たな未審査レセプトにおける記載内容と合致する未審査レセプトをさらに特定し、
前記査定事例提供部は、前記合致する未審査レセプトの件数に占める前記合致する査定事例の件数の割合を示す情報をユーザへさらに提供することを特徴とする請求項1から3のいずれかに記載の医療事務支援装置。
【請求項5】
前記審査機関により拒絶されたレセプトであって、かつ、再審査申立を行うべきレセプトの情報をユーザから受け付ける拒絶レセプト受付部と、
文書提供部と、
をさらに備え、
前記検索部は、前記複数の査定事例のうち、患者への医療行為の内容が、前記拒絶されたレセプトにおける記載内容と合致する査定事例を特定し、
前記文書提供部は、再審査申出書の文書データにおける再審理由の入力エリアに対して前記合致する査定事例の情報を設定した上で、その再審査申出書の文書データをユーザへ提供することを特徴とする請求項1から3のいずれかに記載の医療事務支援装置。
【請求項6】
医療機関から審査機関へ送付されたレセプトであって、かつ、要求通りの診療報酬の支払が審査機関により拒絶されたレセプトの情報を査定事例として、複数の査定事例を保持する機能と、
医療機関から審査機関へ送付される前のレセプトである未審査レセプトの情報をユーザから受け付ける機能と、
前記複数の査定事例のうち、患者への医療行為の内容が、前記未審査レセプトにおける記載内容と合致する査定事例を特定する機能と、
前記合致する査定事例の情報をユーザへ提供する機能と、
をコンピュータに実現させるためのコンピュータプログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公開番号】特開2012−234314(P2012−234314A)
【公開日】平成24年11月29日(2012.11.29)
【国際特許分類】
【出願番号】特願2011−101781(P2011−101781)
【出願日】平成23年4月28日(2011.4.28)
【出願人】(000005979)三菱商事株式会社 (56)
【出願人】(000155469)株式会社野村総合研究所 (1,067)
【公開日】平成24年11月29日(2012.11.29)
【国際特許分類】
【出願日】平成23年4月28日(2011.4.28)
【出願人】(000005979)三菱商事株式会社 (56)
【出願人】(000155469)株式会社野村総合研究所 (1,067)
[ Back to top ]