JP2005522766A - ヘルスケア請求データを処理するためのシステム。 - Google Patents

Abstract

【解決手段】請求前処理システムは、予備判定を採用して、請求の正確性を改善してから、請求をヘルスケア支払者機関又は他のエンティティに送信する。システムは、患者に対してのヘルスケアの提供に関する請求データを処理する。システムは、支払者宛てに送信するための特定の患者に対する請求に関するデータを照合するための請求データコレータ、及び照合済の請求データの処理に使用するルールのソースを含む。プリプロセッサは、照合済の請求データを該ルールを使用した処理にかけ、照合済の請求データが支払の発生を開始する処理を行う状態にあることを検証する。請求プロセッサは、プリプロセッサによる検証が成功したことに応答し、照合済の請求データを支払者へ送信する。ルールプロセッサは、取得した請求データを処理し、個々の請求要素の有効性を判定するための別のルールセットを適用開始する状態を特定する。プリプロセッサは、該ルールを使用しての検証が不成功の場合に受信される訂正された照合済み請求データに対して該ルールを使用した処理を再度行い、照合済み請求データが支払の発生を開始する処理を行う状態にあることを検証する。

Description

本発明は、例えば、ヘルスケア提供者が患者に対して提供するサービスの支払についての請求データを取得し、検証し、処理するためのシステム及びユーザインタフェースに関する。

ヘルスケア提供者（病院、クリニック、医者など）が行う重要な仕事の一つは、ヘルスケア支払者機関へ請求を送付し、患者へのサービス提供についての支払いを得ることである。これらの請求は、電子的又は紙による形式で行われる。紙による請求は、通常、電子形式への変換を行うデータ入力プロセスを経る。入力された電子請求は、通常、分類され、索引が付けられ、そして保存される。各請求は、支払者機関判定システム（payer institution adjudication）で処理される。支払者機関判定システムは、この請求データを解釈し、その請求の全部を払うべきか、部分的に払うべきか、又は拒否すべきかを判断する。この判定プロセスは、完全に自動化されているか、部分的に自動化されているか、又は人力によって行う。請求判定の結果は、被保険者及びヘルスケア提供者への小切手及びＥＯＢ（explanation of benefits）の発行、又は、追加情報の送付要求を含む。請求を審査するプロセスは、労働集約的で且つ間違いが起こり易い。

公知の判定システムは、支払者及びヘルスケア提供者が彼らの請求支払及びメディカルケース管理プロセスを簡素化するのに役立っている。支払者機関が採用している例示的な判定システムは、高速のスキャニング機器と光学文字認識ソフトウエアを使用して紙の請求書を電子データに変換する。電子請求データは、各請求データを解釈して何らかの矛盾がないかを判定するため、ルールに基づいたソフトウエアによって処理される。矛盾は、通常、オンライン請求イメージで該当部分を強調表示するか、又はレポートの形でユーザに報告される。ヘルスケア提供者が採用している例示的な判定システムは、電子請求データを支払者機関へ送信する前に評価する。ヘルスケア提供者は、支払者のルールを彼らのソフトウエアアプリケーションに組み込むか、又は「請求浄化（claim scrubbing）」アプリケーションを使用して、請求データを支払者へ提出する前に評価し、請求が正確であることを保証してから請求を送るよう最善を尽くしている、又、公知の判定システムでは、断片的な観点から請求データ処理に取り組んでおり、例えば、あるソフトウエアベンダのシステムはオンライン適格性及び電子送金に取り組んでおり、他のベンダのシステムは、医者の立場からの収入管理に取り組んでいる。別のベンダのシステムは、請求の編集をサポートしているが、請求の発生後だけである。更に、公知のシステムでは、請求が作成された後でユーザの介入を非常に多く必要とする。公知のシステムは、支払者、サービス提供者、及び患者を合わせた観点で、請求の処理及び管理に取り組んでいない。公知のシステムの別の問題は、ヘルスケア提供者が使用しているルールは不正確で古く、誤ったバージョンを含んでいるか、対象とする支払者機関が現在使用中のとは異なるバージョンを含む可能性があることである。更に、公知のシステムでは、通常、ヘルスケア提供者のシステムと支払者のシステムとの互換性に取り組んでいない。支払者の受領時点での編集処理が行えない請求が行われることになり、その結果、支払者によって却下される。請求の却下は、支払いの遅れの原因になるだけでなく、ヘルスケア提供者のキヤッシュフロー及びそのプロセスに対する患者の満足度に悪影響を与える。本発明の原理に従ったシステムは、ヘルスケア支払者機関向に請求を送る前に、請求の正確性を改善する。

請求前処理システムは、予備判定（trial adjudication）を採用して、請求の正確性を改善してから、請求をヘルスケア支払者機関又は他のエンティティに送信する。システムは、患者に対してのヘルスケアサービスの提供に関する請求データを処理する。システムは、支払者宛てに送信するための特定の患者に対する請求に関するデータを照合するための請求データコレータ、及び照合済の請求データの処理に使用するルールのソースを含む。プリプロセッサは、照合済の請求データを該ルールを使用した処理にかけ、照合済の請求データが支払の発生を開始する処理を行える状態にあることを確認する。請求プロセッサは、プリプロセッサによる検証が成功したことに応答し、照合済の請求データを支払者へ送信する。

本発明の１つの特徴によれば、このシステムは、個々の請求要素の有効性を判定するための別のルールセットの適用を開始する状態にあることを特定するため、取得した請求データを処理するためのルールプロセッサを含む。

本発明の別の特徴によれば、プリプロセッサは、該ルールを使用しての検証が不成功の場合に受信される訂正された照合済み請求データに対して該ルールを使用しての処理を再度行い、照合済み請求データが支払の発生を開始する処理を行える状態にあることを検証する。

図１は、請求をヘルスケア支払者機関又は他のエンティティへ送信する前に請求の正確性を改善するために予備判定を採用した請求処理システム全体を示す。図１のシステムにおいて、個々のヘルスケアプロバイダ及びヘルスケア支払者機関が該ルールの最新バージョンで作業が行えるようにするため、リポジトリ７４内の集中化共通ルールは常に更新される。共通化ルールを使用することによって、ヘルスケアプロバイダが該ルールの最新バージョンに準拠することが保証される。ここで使用されるルールには、ヘルスケア請求諸要素が、ヘルスプラン払い戻し（reimbursement）条件、ヘルスプランフォーマット要件、払い戻し公式、払い戻し制限、及び払い戻し計算手順等の所定の諸要件に従っていることを判定するためのヘルスケア手順が含まれる。ルールは、フォームとデータ、又はフォームとデータとの間の関連を使って、どの様に行為を提示し、実行し、調整するかについての所定のガイド、指針、又はモデルを含むこともできる。更に、ここで使われる例外は、問題の特定とその問題を処理するメカニズムをも含む。

図１のシステムは、シームレスで、正確且つ迅速な処理を提供できるように、ヘルスケア請求データ処理サイクルの事前登録、適格性、登録許可、請求作成、予備判定、請求発行、支払送金、及び送金後処理をそれぞれ自動化している。このシステムでは、雇用者及び支払者の活動の協調を自動化し、事前訪問入会者（enrollee）データの正確性を保証する。これにより、患者が消費者ポータル（２４）を使って訪問のスケジュールを決める場合、又は、ヘルスケア施設が保険に関する情報を患者から取得する場合、医療の必要性、（専門医などへの）紹介、及び適性の検証処理が自動的に開始される。請求は、その請求が完了する前（即ち、例えば、請求に挙げられる個々のヘルスケアについての個々の請求要素として）及び完成した請求が支払いのために送信される前に、ルールリポジトリ７４内の適用可能なツールを使い、ルール実行機能４６及び判定ユニット４８によって正確性が評価され、且つ編集される。図１のシステムの中の種々のポータル２０〜ポータル２８は、患者、支払者、プロバイダ、雇用者、及び政府機関に対して請求データへのアクセスを提供するため、インタフェース１０によって制御、管理される。このシステムは、自動化された、ルールに基づく編集及び審査システムを使うことにより、ヘルスケア提供者が政府及び支払者ルールに準拠し易くする。

図１のシステムは、請求に間違いがないことを保証するため、請求データを自動的に編集する。このシステムは、有利なことに、該ルールを使って請求の予備判定（前処理）を実行し、編集された照合済みの請求データが、支払いの発生を開始するための支払者機関による実際の判定を行える状態にあるかどうかを検証する。このため、請求の一部又は全部の拒絶が減少し、これに従って、提供者及び支払者両者の運用コストを減少できる。請求が正確で且つ電子的に受領されるので、支払者は請求処理の日量を効率的に増やすことが可能になる。これによって、提供者及び患者からの保険及び請求事項に関する電話による照会の量も減少する。収入サイクルが短縮されることによって、支払の送金が速くなり、担当者の介入が減り、且つ患者の満足度が改善される。予備判定が失敗に終わった場合は、自動的に欠陥の修正が開始されるか、専門担当者が行うべきワークリストの仕事をスケジューリングすることにより、手動による介入が行われる。予備判定が成功裏に完了すると、請求データは、支払者宛に電子的に送信するために、再び待行列に自動的に加えられる。支払通知は、手動による介入なしに電子的に処理され、所定の口座に自動的に記帳される。

図１のシステムは、請求データを処理するためにソフトウエアアプリケーション及び実行可能手続きで実行される機能群を含む。これらの機能は、１台以上のコンピュータシステム及びサーバ内に常駐し、且つ、内部及び外部との通信用の１以上の通信ネットワークを含む、ハードウエア又はハードウエアとソフトウエアの両者の組合せによっても実現できる。このシステムでの患者に対して施されたヘルスケアに関する請求データの処理は、支払者宛に送られる患者についての請求に関連するデータを照合することによって行われる。照合済データは、その照合済み請求データが支払いの発生を開始できる状態にあることを検証するため、ルールを使用する前処理にかけられる。この検証が成功すると、検証済の請求データは支払者宛に送信される。請求データは、インタフェース１０を介し、データ取得ユニット３２によって照合され、データリポジトリ６８へ格納される。リポジトリ６８は、現在進行中のヘルスケア接触に関するファイナンシャルデータと臨床データを格納する。データ取得ユニット３２は、複数の異なるソースからの応答型（solicited）データと任意型（unsolicited）データの両者を受取ること、及びこれらのソースからインタフェース１０を介してデータを要求することができる。種々のソースには、図１のシステムに加入して使用している外部ユーザ（参加者）が含まれ、更に、例えば、ヘルスケア提供者、ヘルスケア支払者機関（例えば、保険会社、ＨＭＯ（Health Maintenance Organization）など）、消費者、雇用者、及び政府機関も含まれる。

データキーパユニット６４は、ヘルスケアデータリポジトリ６８に対してのデータの格納及び取り出しを管理すると共に、ポジトリ６８へのデータの格納、変更、及び取出し要求を処理するためのゲートウエイ及びデータ管理システムとしての役割を果たす。データキーパユニット６４は、更に、ポジトリ６８内のデータの変化を、変化が生じた時刻、日付及び性質及びその変化の記述者の識別とソースを記録することによって追跡して、データ更新の監査トレイルを維持する。ヒストリアンユニット７０は、古いデータ値をアーカイブし、保持するのに使用され、また、金銭取引きが完了した後の患者接触（即ち、未決着になっている関連する金銭取引がない接触）に関連したデータレコードのアーカイブ及びこれらの接触の処理に専用される。ここで使われる接触（encounter）という語は、ヘルスケア企業との患者との接触を含み、これには、経済的又は取引の結果を伴うヘルスケア企業とのやりとりを含み、例えば、患者の訪問、電話連絡、入院患者の滞在又は外来患者の処置などを含む。これらの接触のレコードは、データキーパユニット６４によってリポジトリ６８に保持される。ヒストリアンユニット７０は、アーカイブ済データをデータベース７２（データウエアハウス）へ格納する。

照合済のデータは、その照合済み請求データが支払いの発生を開始できる状態にあることを検証するため、予備判定器（trial adjudicator）４８によって行われるルールを使用した前処理にかけられる。予備判定器４８は、ルール実行ユニット４６によるルールのサブセットの実行を開始する。ユニット４６は、関連ルールの適用を起動するイベントの発生を検出し、そのイベントに関連するルールを実行する。イベントには、リポジトリ６８へ追加されるデータの受取り、指定されたルールのリストの実行要求、及び図１のシステム内での機能の働きによって起動されるイベントが含まれる。ユニット４６によって実行されるルールは、起動イベントを自身で生成し、他のルールの実行を開始する。個々のルールは、ルールの実行時に「真」又は「偽」の判定結果を示すテストを含む。各ルールは、例えば、結果が真の場合に実行されるアクションのリスト及び結果が偽の場合に実行される別のアクションのリストを含む。アクションのリストは、自動的及び手動で実行される作業のワークリストの作成、ログ、監査レポート及び会計レポートの作成、エラーレポートの作成、請求の作成、送金の記帳、データの変更、及びその他のアクションを含む。データモーファユニット（data morpher unit）４４は、コマンドに応答してルールが呼び出し、リポジトリ６８内のデータを変更する下位分類のアクションを含む。また、ユニット４６は、インタフェース１０が関与する通信中に、プロテクタ１２、トランスレータ１４、トランスポータ１６が必要とし使用するルールを含む、関係ルールリポジトリ１８に格納されているルールを処理し実行する。

予備判定ユニット４８によって実行されるルールは、予測される判定結果を、指定された一組の請求データを指定された支払者宛に送信する際に決定する。ユニット４８は、ルールキーパインタフェース６６を介してリポジトリ７４（又は、ルールアクセッサ５２）から取出されるルールを使用し、指定された一組の請求データを指定された支払者宛に送信した結果を予測する。この目的のため、ユニット４８が使用するルールが、選択された特定の支払者が使用するルールを複製する。ユニット４８は、請求を指定された支払者宛に送信する前に、支払拒否になりそうな状態を特定し、こうした状態を（自動的又は手動で）直すことができるようにしておく。この手順は、リポジトリ７４から取出されるルールを使うか、遠隔地からアクセスされるルールを使って、エラーの無い請求の作成を容易に行うことができ、有利である。規制ガイドライン及び諸指示を含むルールは、継続的に取得されてリポジトリ７４に格納され、且つ、ルールキーパ６６を介してこのリポジトリ内で更新されて、保持される。ルールアーカイブユニット７６はユニット６６と共に、アーカイブすべきルールに日付及び時間をスタンプすると共に、期限の切れた、即ち古いバージョンのルールを（ルールウエアハウス）データベース７８に格納する。アーカイブ済ルールは、アクセス可能且つ使用可能で、例えば、特定の請求データに対して、過去のある日において有効であったルールを用いた判定を行った結果を決定するものである。リポジトリ７４は、支払者機関加入者から取得する判定ルール及び支払者との前の取引から確立されたルールを含む。リポジトリ７４は、該システムによって作られ加入者によって承認された、自動化プロセスをシステムへ追加する諸ルールをも含む。パターンデザイナユニット３８は、監視調査プロセスを定義するための専用ルールを作成し、ルールメーカユニット５６を使い、汎用ルールを作成する。

ユニット４８は、外部のルールソース（支払者機関６０所有のルール６２など）から、インタフェース１０及びデータネットワーク５８を介してルールアクセサ５２によって取出されるリポジトリ７４内のルールを使用する。ネットワーク５８は、従来のネットワークのＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）又はインターネットなどを含み、この他、請求判定用のデータ及びルール（例えば、支払者ルール６２）の取得を容易にするため、ヘルスケア支払者又はヘルスケア提供者が使用するクリアリングハウス又はその他サービスなどを含む。支払者ルール６２は、支払者６０によって公表されたルールで、ルール取得ユニット５４が管理する自動化プロセスを通してのアクセスはできない。ルール６２は、むしろ、手動取得プロセスを通して手動で決定されるものであり、ルールメーカユニット５６によって提供されるユーザインタフェースを使って、ルール取得ユニット５４により分解され、解析される。ルールメーカ５６のユーザインタフェースは、ユニット５４を介して取得されるルールを含めて、ルールの手動作成、レビュー及び更新をサポートする。ユニット５６は、編集後のルールをルールリポジトリ７４へ格納する前に、利用可能なテスト及びアクションのリストをユーザに示し、ルールの作成及び編集プロセスを通してユーザをガイドすることも行う。

ルール取得ユニット５４は、支払者システムにルールの自動問合せを行うこと、及び所有権のあるプログラム化されたルールセットへのアクセスを提供する支払者が提供するドキュメント及びその他の情報を通して、ルールデータを蓄積する。ユニット５４は、支払者のウエブサイト及びその他のソースから支払者が作成した情報掲示板を検索し、この材料を解析し、リポジトリ７４に組入れる新たなルール又は変更されたルールを表す情報を特定すると共に、期限切れのルールを特定する。更に、各支払者機関は、支払者ポータル２２を使いインタフェース１０を介して取得ユニット５４へルール情報を送る。取得ユニット５４は、この情報をルールキーパユニット６６を使ってリポジトリ７４へ組入れる。また、ユニット５４は、ルール収集サービス８０によって支払者から取得した情報を基に、ルールメーカ５６が提供するユーザインタフェースを介して行われるユーザの手動データ入力及び処理に引き続いて新しいルールを受取る。支払者は、例えば、新しいルール又はルールの新しいバージョンの実施に先立ち、更新済ルール情報をサービス８０へ送る。サービス８０は、これらの新規又は更新済ルールを、ルールメーカユーザインタフェース５６を使ってルールリポジトリ７４に組入れるための、実行可能な定義をユーザが作成することをサポートする。サービス８０は、また、請求拒否の発行及び判定の成功と失敗の率を監視することをサポートし、特定された問題を解決するためのルールの調整又は作成をサポートする。ルールチェッカユニット５０は、リポジトリ７４内のルールを監視し、不完全又は不正構文を含むルールを特定し、ユーザに示す。ユニット５０は、また、相互に矛盾するルールの組合せについてもレポートする。更に、請求データをルール実行ユニット４６及び予備採決ユニット４８を使って処理する間に、所定の例外状態が特定された場合、これに応答して、例外トラッカ機能４２は、特定された例外状態の処理及びレポートを管理するためのルールのサブセットを採用する。例外トラッカ機能４２は、ある特定のルールの実行に応じて、又は、ルールを実行して得られた特定の結果に応答して、ルール実行ユニット４６によって起動される。例外状態が決定された後、機能４２は、例えば、ユーザインタフェース又はワークリストを介して、受取人に対してレポート又はメッセージを送ることによって手動による介入をスケジュールする。

予備判定器４８は、請求データに対して遠隔地にあるルールによって予備判定を行うため、ルールアクセサ５２を使用する。これら遠隔地にあるルールは、図１のシステムの所有者とは別のエンティティ（支払者機関など）によって保持（又は所有）されている。こうしたルールを所有する支払者は、予備判定のために請求データを受取るための手順を確立し、請求データがその支払者所有のルールを使用してどう判定されるかを示すレポートにより応答する。

予備判定に使われ、修正（必要な場合）及び検証が行われた後で最終的に支払者宛に送信される請求データは、データリポジトリ６８から取り出される。図８〜１４は、集中データリポジトリ６８に組込まれ、請求処理で使われるデータ要素の例示的なレコード構造を示す。即ち、図８は患者レコードデータ構造の一部を示し。図９は医療レコードデータ構造を示し、図１０は支払者レコードデータ構造の一部を示す。料金レコードデータ構造及び発生コードデータ構造は、夫々、図１１及び１２に示され、又、図１３及び図１４は、夫々スパンコード（１件の請求にまとめるべきサービス料金を特定するのに使う）及び医療状態コードデータ構造を示す。これらのレコード構造は例に過ぎず、リポジトリ６８は、通常、例えば救急サービス、リハビリサービス、治療及びその他サービス及び活動などの請求データに関連した他の種類のレコードを含む。図８〜図１４のレコード構造は、リポジトリ６８内で、請求パケット識別子（８００，９００， ９２０，９４０， ９６０，９８０， ８３０）、セクション識別子（８０２，９０２， ９２２，９４２， ９６２， ９８２，８３２）、及びシーケンス番号（８０４，９０４， ９２４，９４４， ９６４，９８４， ８３４）を使って個々にアクセス可能である。

個々のレコード構造内のデータは、ある長さのフィールドに区切られている。
例えば、図８の患者レコード構造では、患者の姓（８０６）は２０桁の固定長を占め、これに続き、１２桁を占める患者の名（８０８）及び１桁を占めるミドルネームのイニシャル（８１０）がきている。図９〜図１４のレコード構造は、同様の所定の固定長フィールドにある請求データの他の事柄に関するデータを含む。例えば、図９の医療レコードは、入院診断コード（９０６）、一次診断コード（９０８）及びその他診断コード（９１０）を含む。図１０の支払者レコードは、支払コード（９２６）、支払者識別子（９２８）及び支払者副識別子（９３０）を含む。図１１の料金レコードは、サービス料金コード（９４６）、サービス料金改定コード（９４８）及びサービス日付（９５０）を含む。図１２の発生コードレコードは、発生識別コード（９６６）及び発生日付（９６８）を含む。図１３のスパンコードレコードは、スパン識別コード（９８６）、及びこの請求に対する支払に関するイベントを特定するコード及びそれに関連した日付を特定するのに使うスパン決定開始日（９８８）及び終了日（９９０）を含む。図１４の状態コードレコードは、医療状態識別コード（８３６）を含む。図８〜図１４に関連して参照される項目は、例示の目的で記載されている。しかしながら、他のレコード項目も図８〜図１１のレコード構造に示されている。これらのその他項目は、例えば、リポジトリ６８構造内の種々のレコードに含まれるデータの範囲を表す。代替の実施形態では、リポジトリ６８には、その他の非固定長データレコード構造又は別のデータレコード構造が採用される。

リポジトリ６８内の請求データは、前述の通り、複数の異なるソースからのインタフェース１０を介してデータ取得ユニット３２によって照合され、データ管理システム６４を介してリポジトリ６８に格納される。データエミッタユニット３４は、要求された請求データをリポジトリ６８から抽出してインタフェース１０を介してそれを送ることによって、外部エンティティ（例えば、ポータル及び参加者２０〜参加者３０）へ請求データを提供する。データリーチャユニット３６は、遠隔のエンティティによって格納された請求データへの読取専用アクセスを行い、且つこのデータを基に決定を下すために、図１のシステムの各機能によって使用される。更に、ユーザ３０は、サーチパターン設計機能３８を使い生成されるデータサーチ基準を使い、外部ポータル２０〜外部ポータル２８を介して、請求データリポジトリ６８をサーチ可能である。これにより、ユーザは、リポジトリ６８内の請求データを解析作業において統計上有意なデータパターン及びその他のデータパターンをサーチできる。

サーチ設計機能３８は、ルールリポジトリ７４に格納されている専用カテゴリーのルールを採用する。許可されたユーザは、サーベイランスポータル２８をインタフェー
ス１０経由で使い、ルール及び請求データ情報のサーチをサポートするための専用カテゴリーのルールを使うことができる。サーチ可能な情報ソースには、ルールリポジトリ７４、関係ルールリポジトリ１８及び請求データリポジトリ６８が含まれる。この目的のため、サーチパターンエバリュエータ機能４０は、パターン設計機能３８が生成するパターンの定義を処理するためにルール実行ユニット４６が実行するルールのサブセットを採用する。即ち、パターンエバリュエータ機能４０は、該サーチ定義にあるアクションステップに従ってサーチされたデータの中のパターンを識別し、その結果を、インタフェース１０を介してサーチイニシェータにレポートする。パターンサーチは、イベントの発生に応答して実行可能である。イベントは、例えば、コマンド（参加者の要求に応じた）を含む。イベントは、特定データの変化の検出時（例えば、ある特定の診断結果の受取り）、又はある特定の期間の終了などに応じて内部的に生成される。

インタフェース１０は、アクションのサーチ、ビュー又は始動のために、ポータル２０〜ポータル２８を介して、請求データ処理操作において種々の関連参加者３０によるアクセスを提供する。このため、例えば、参加者（ヘルスケア提供者、支払者機関の代表者、患者、雇用者又は政府機関など）は、請求データ、支払者ルールへアクセスして、データ修正アクションなど種々のアクションを開始することができる。即ち、ヘルスケアプロバイダ及びヘルスケア支払者の代表者は、これらのエンティティが夫々要求する機能を提供するポータル２０及びポータル２２を介してシステムへアクセスできる。例えば、ヘルスケアプロバイダは、ファイナンシャルデータ及び関連した臨床データをリポジトリ６８へ入力し、請求の予備判定及びその他のルールによって駆動されるプロセス群をポータル２０を介して始動、管理することができる。同様に、提供者は、自動化ルールに基づいて自身のデータを自動的に変更するか、又は手動補正及び更新を通して変更することができる。提供者は、更に、エラーの無いことが検証された支払請求の送信を開始し、且つ請求状態の問合せを開始することができる。更に、提供者は、ポータル２０を介して送金通知（即ち、送金済みの支払に関する情報）を取得し、取得した通知を対応する正しい口座へ自動的に送り、且つ２次及３次の請求を作成して送信し、そのビジネスの管理をサポートするために（行うべき作業の）ワークリスト及びレポートを得ることができる。

支払者機関は、ポータル２２を使い、判定ルールをリポジトリ７４へ格納すると共に維持し、予備又は実際の（確定）判定用の請求データを受け取り、且つ請求状態への問合せに応じることができる。支払者は、更に、情報の要求の送信、送金通知の発行、及びワークリストとレポート類の取得、及びそのビジネスと収入サイクルの管理を行うことができる。適切な権限を有する、個々の患者、扶養家族、又はヘルスケアプランへの加入者などの消費者は、消費者ポータル２４を使い、自身の請求データレコードと請求の状態を見ると共に、支払を管轄しているルールを研究することができる。更に、消費者は、システムを介して、自身のデモグラフィック（demographic）データ又は医療レコードの中のエラーの訂正、予約のスケジュールを行うこともできる。消費者は、口座残高、最近の取引記録、将来の預金情報を取得し、支払いが不足しているアイテムについて、医療支出払い戻し口座からの支払を要求することもできる。

雇用者、又は別のプラン管理者は、ポータル２６を使い、ヘルスケア接触サイクルビジネスを管理し、人の集団（従業員）に代わってヘルスケア契約の交渉を行い、これら従業員に関する活動を監視することができる。この目的のため、雇用者は、例えば、ワークリスト又は種々の診断の発生、種々の提供者の利用状態、料金の明細（例えば、会員によって支払われる、契約により減額される、又は拒否されるなど）を確認するためのレポートを入手することができる。これにより、雇用者は、プランの会員が代りのヘルスプランを選択した方が得かどうかを判定することができる。サーベイランスポータル２８によって、許可された参加者３０（例えば、調整担当又は研究者）が研究プロジェクトを立ち上げ、実施して、ルールリポジトリ７４と連携したリポジトリ６８のパターン又は傾向をサーチすることによって、格納済の請求データを解析できる。即ち、サーチパターン設計及び実施ユニット３８と４０と連携するサーベイランスポータル２８は、例えば、（１）周期的な統計レポートの作成、（２）請求の不正と悪用の検出、（３）自然の病気又は人間（テロリスト）の活動が原因の伝染病の発生を検出するための調査をサポートする。調査の結果は、ワークリスト又はレポート類を含み、調査基準は、ルールとしてルールリポジトリ７４に格納される。

インタフェース１０は、セキュリティ機能１２、トランスレータ機能１４及びトランスポート機能１６を使い、ポータル２０〜ポータル２８を介して、参加者３０が請求データ及びルールリポジトリ６８及び７４へアクセスできるようにする。セキュリティ機能１２は、ある参加者が別の参加者と通信することを許可されているかどうか、そして、ある参加者が特定のデータにアクセスすることを許可されているかどうかを判定すると共に、参加者特権と資格を割当て、セキュリティ及びアクセスルールを保守する。ユニット１２は、セキュリティ及びその他の（例えば、ＨＩＰＡＡ）ポリシーに反する無許可のリクエストを拒否し追跡する。トランスレータ機能１４は、図１のシステムにおいて、内部及び外部の参加者が使用している異種のデータフォーマット間でデータを変換する。この目的のため、トランスレータ機能１４は、データを最初のデータフォーマットから内部的に定義された中間データフォーマットへ、次にこの中間データフォーマットから所望の出力データフォーマットへと変換する。トランスポート機能１６は、図１のシステムの内部機能相互間、及び内部機能と外部参加者との間のデータとメッセージのやりとりをサポートする。この目的のため、機能１６は、関係ルールリポジトリ１８を使って、必要な接続用プロトコルと接続方式及び元アドレスと宛先アドレスを特定する。また、機能１６は、適切なメッセージフォーマット及びプロトコルにデータをエンコードする際、及び、必要なハンドシェーキングと双方向通信を行うのに必要なその他のルーチン群を始動する際に、ルールリポジトリ１８を使用する。

関係ルールリポジトリ１８は、参加者及びシステムソフトウエアアプリケーションが使うアプリケーションプログラマインタフェース（ＡＰＩ）及び特定のソースから情報を要求し、情報を特定の参加者に提供するのに必要な手順を識別する情報を含む。参加者ＡＰＩの特定及び関連する通信情報は、個々の参加者によって供給され、リポジトリ１８へ格納される。参加者は、夫々の通信サポート情報の支配権を維持し、保守を行う。インタフェース１０は、格納されている所定のＡＰＩ及び通信情報を使用し、データを最初のデータフォーマットから内部的に定義された中間データフォーマットへ、その中間フォーマットから所望の出力データフォーマットへと変換する処理をサポートする。結果として、参加者は、自身のシステムを更新し、使用中のルール標準又はリポジトリが新しいプラットフォームへ移行したか、他の手段で根本的に変更したかどうかに関係なく、他の参加者との通信が可能である。その上、各参加者は、関連するデータフォーマット標準を、他の参加者が行っている操作を妨げることなく変更できる。

図２は、図１の請求処置システム全体で使用されるサーバベースの機能群（特に、サーバアプリケーション１１の中の機能４２、機能４６、機能４８及び機能５２）を含む予備判定システムを示す。前述の通り、リポジトリ６８からユニット６４を介して取出される照合済の請求データは、リポジトリ７４からユニット６６を介して取出されるルールを使う実行ユニット４６と連動する予備判定器４８によって前処理される。これにより、予備判定システムは、予想される判定の結果を、指定された１セットの請求データを指定された支払者宛に送信する時点で判定し、その照合済の請求データが支払いの発生を開始できる状態にあるかどうかを検証する。予備判定の結果は、リポジトリ１８内の管理ルールによる指示によって、インタフェース１０を介してポータル２０とポータル２２をそれぞれ使用して提供者又は支払者がアクセスできる。例外状態を引き起こすルールの結果は、例えば、ユーザインタフェース又はワークリストを介するか、受取人へのメッセージを送ることによって、例外処置４２の動作を呼び出して、手動による介入をスケジュールする。更に、ユニット４８は、外部のルールソース（支払者機関６０が所有するルール６２など）からルールアクセッサ５２によって、例えば、インタフェース１０及びデータネットワーク５８を介して取出されるルールが含まれるリポジトリ７４内のルールを使う。

図３は、請求の処理において、図１のシステムが使用するプロセスのフローチャートを示す。ステップ３０３において、取得ユニット３２は、データインタフェースユニット６４と連携し、データリポジトリ６８に格納する特定の患者に対する請求に関したデータの照合を行う。図４は、ある患者（この患者はアイテム４２０で識別される）に対する請求発行レコードを示したユーザインタフェース表示イメージを示す。この発行レコードは、傷害の治療に関するヘルスケアプロバイダでの複数の患者接触４０２、４０４、及び４０６に対する照合済の請求データを含む。図５は、支払者関連情報を表す、同じ患者（アイテム４２０）に対する別のフォーマットレコードを示したユーザインタフェース表示イメージ５００を示す。ステップ３０７において、ルール取得ユニット５４（及び５２）は、ルールを累積し、インタフェースユニット６６を介してリポジトリ７４へ格納する。該ルールは、ローカルソース及びリモートソースから累積されるが、これらのソースの例としては、支払者機関、支払者機関から受取るメッセージ、支払者機関のウエブサイト、以前に特定された請求データの欠陥、並びに政府関係及び規制ルール提供者からの規制ガイドライン及び指示に応答してルールを生成するのに使うルール生成プロセッサが挙げられる。ステップ３０９において、予備判定プロセッサ４８は、ルール実行ユニット４６と連携し、照合済み請求データの各請求要素の有効性を判定するのに使う最初のルールセットの適用を始動する状態を特定するために、リポジトリ６８から取得した照合済の請求データを処理する。ユニット４６及び４８は、最初の状態ステートの検出に応答して最初のルールセットを、そして２番目の状態ステートの検出に応答して２番目のルールセットを夫々適用する（両ルールセットはリポジトリ７４から取出される）。ルールの適用を起動する状態には、例えば、（ａ）患者の請求データに組入れるレコードの生成、（ｂ）患者の請求データに追加するレコードの検出、（ｃ）患者の請求発行レコードに追加するレコードの検出、（ｄ）患者の請求発行レコードの変化検出、及び（ｅ）患者の請求データの変化の検出が含まれる。

各検証ルールは、「真」状態を特定し関連する最初のアクションのセットを開始する、又は「偽」状態を特定し関連する２番目のアクションのセットを開始するための１以上のテストを含む。ルールは、例えば、図５の請求レコードの警告アイテム５０２に示されているように、被保険者の名前の欠如を検出する。アイテム５０３は、更に、この警告状態が、請求の保留及びレポートの作成を起動することを示す。ルールテストの条件は、単純な場合もあり、論理演算（例えば、「ＡＮＤ」、「ＯＲ」、「ＮＯＴ」）で接続された組合せテストを含む複雑な場合もある。リンクされたテストの結果が論理的に組合されてテスト全体の結果が「真」又は「偽」として与えられる。更に、アクションセットが、アクションを起動しない空のセットである場合もある。非起動状態が検出されると、デフォルトの真状態が宣言される。ルールリポジトリ７４（図１）には、実行可能ルールが含まれると共に、個々のルールに組み込まれたテストコンポーネントが、非テクニカルユーザ及びその他のユーザへの操作指示と説明のヘルプに使うため個々のルールの機能を英語の文章で記述したドキュメントと共に組込まれる。ルールと該ルールによって組込まれる個々のテストコンポーネントの両方について、有効期間を示す開始日時と終了日時もリポジトリ７４によって保持されている。ユニット４６は、ルールの有効期間を調べて、時間と日付が有効期間外にあれば、ルールもテストコンポーネントも実行しない。

ステップ３１１（図３）において、予備判定ユニット４８は、照合済の請求データを、ステップ３０９（例えば、請求データ検証ルールの第１のセット）で特定されたルールセットを使用してユニット４６（図１）により行われる処理に照合済の請求データをかけて、その照合済の請求データが支払いの発生を開始できる状態にあるかどうかを検証する。ステップ３０９において、リモートに置かれたルールセットが特定された場合（例えば、支払者機関によって保持されているルール）、ユニット４８は、照合済の請求データに対して、そのルールを所有している機関が提供する請求データ送信手順（リポジトリ７４に格納されている）を使用して、リモートに置かれたルールに従った処理を行う。この目的のため、ユニット４８は、支払者機関６０を介してリモートに置かれたルール６２をアクセスする場合、ルールアクセサ５２とネットワーク５８を採用する。個々の確認ルールは、例えば、ヘルスプラン払い戻し条件、ヘルスプラン請求フォーマット条件、払い戻しフォーマット、払い戻し上の制約、払い戻し計算手順などの事前定義要件に従った請求要素を判定する手順を含む。例示的なルールは、電話番号、郵便番号、住所又はその他の地理上の識別項目を保持しているデータフィールドなどの、データフィールド間の矛盾を検出する。或いは、ルールは、例えば、照合済の請求データの要素が、支払者が指定した限度を超えているかどうかを判定する。更に、何らかのルールによって処理される請求の各要素は、請求の一部、請求全体、請求の中のレコード、又は例えば、ヘルスケアサービス提供者との個々の患者の接触に関連するレコードデータを含む。

図７は、例示的なルール及び、そのルールを患者への請求データに適用した場合に生じるエラーを特定するための関連エラーコード（左の欄に）を示す。該ルールは、カテゴリー化され、各請求要素の有効性を判定するための第１のルールセット（図７右欄のカテゴリ２のルール７０３〜ルール７０７）及び完全な請求についての照合済の請求データの処理に使う２番目のルールセット（図７右欄のカテゴリー１のルール７００、７０９、ルール７１７〜ルール７２１）を含む。例えば、あるルール（ルール７１１〜ルール７１５）は、両方のカテゴリーに入っている。ルール７０３とルール７０５は、患者に施されたサービスの日付と所定の払い戻し日範囲の矛盾を検出し警告を発する、又、ルール７０７は、ある特定の手順コードが、例えば、特定支払者プランによってカバーされていないことを検出し警告を発する。同様に、ルール７０９は、無効な患者入院日を特定して警告を発し、又、ルール７１７は、発生日（例えば、傷害）が、入院日以降であることを特定して警告を発する。ルール７１１、ルール７１３及びルール７１５は、患者に施されたサービスの診断コード、手順コード、又は複合コードと、関与した患者ついて記録された年齢又は性別とが矛盾していないかを検出し警告を発する。例えば、ルール７００は請求が傷害の原因を含み、傷害の箇所を含んでいないことを検出し警告を発し、ルール７１９は無効な患者収入コードを検出して警告を発する。また、ルール７２１は、不適切に組み合わされた請求、この場合には、例えば、別に請求しなければならない乳房Ｘ線撮影の料金を検出して警告を発する。ユニット４８（図１）は、ユニット４６と連動し、リポジトリ７４（例えば、図７のルール）によって識別された欠陥を、自動的に、リポジトリ６８内の請求データを使って矛盾を正し、又は欠落データを追加する。自動的に修正ができない状況が検出された場合には、前記の通り、手動による介入とレビューがスケジュールされる。

図６は、ステップ３１１（図３）で検証ルールを適用した請求前処理の結果を表示すると共に、請求拒否理由を説明と拒否コードによって特定するユーザインタフェース表示イメージを示す。即ち、行６００は、エラーコード番号、エラーコード識別子及びレベル、エラーコードのサブ識別子、エラーの説明テキスト、及び、訂正されたエラー（この例になし）を特定するための解決済エラーを含めたカラムを定義するエラーリストの見出しを表す。行６０２から行６１７は、ステップ３１１の検証ルールを患者についての請求データに適用した場合の結果である。この結果リストは、無効収入コード（６０２）、データフォーマット欠陥（６０７）、欠落名ポーション（６０９）、収容データの省略（６１１）、収入コード関連エラー（６１３）、手順コード関連エラー（６１５）及び収容又は副次データの省略（６１７）を含む、７つの拒否理由を特定している。

図３のステップ３１５において、ステップ３１１における請求の検証失敗に応答して、ユニット４６と連動する予備判定ユニット４８はルールを照合済の請求データの編集用に適用する。ユニット４８とユニット４６は、特に、請求拒否の結果になる可能性が高い特定された欠陥を訂正するために照合済の請求データを自動的に編集する。ユニット４８とユニット４６は、請求データの訂正プロセスにおける手動データレビュー又は手動介入を含む機能も開始する。これらの機能は、例えば、ヘルスケアワーカが実行する仕事（照合済データの中の欠陥を訂正することなど）のスケジュール作成、レビュー用のエラーレポートの作成、請求データ編集ルールの適用結果（将来の請求データ編集用）の記録作成、照合済み請求データの欠陥が請求拒否の結果になる可能性が高いことをユーザに対して指示する警報メッセージの作成、勘定レポートの作成、請求の作成、及び、送金の送信開始を含む。その他の機能は、パターンサーチ及び請求データとその他データに対するその他統計分析の開始、活動のログ（記録）の保持、レポートへのアイテムの追加、及びデータのセットのカテゴリ化（例えば、ある請求はエラーがないが、別の請求は訂正のために特定ワークリストに在ることを示すために）を含む。ステップ３１７において、訂正済の請求データを提供するための、照合済の請求データの自動又は手動編集に続き、ユニット４８は訂正された照合済み請求データを、ユニット４８がユニット４６と連携して再検証するために自動的に待ち行列へ入れる。

ステップ３２１において、ユニット４６と連動する予備判定ユニット４８は、（ステップ３１５において訂正された）請求データを検証ルールを使用して再度処理する。これは、訂正済の請求データが、支払いの発生を開始できる状態にあるかどうかを再検証するために行なわれる。ステップ３２１における請求データの再検証が成功裏に終わったこと又は、ステップ３１１における検証が成功裏に終わったことに応答して、ユニット４８は、ステップ３２３において、インタフェース１０及びネットワーク５８を使用して検証済の請求データを支払開始のため支払者宛に発行する。この目的のため、インタフェース１０は、関係リポジトリ１８を使い、検証済の請求データを処理し、支払者が事前に決めた（及びリポジトリ１８内に保持され特定された）データフォーマット、プロトコル、ハンドシェーク処理ルーチン及び発行手順を提供する。検証済の請求データを受信すると、支払者は、その検証済の請求データを受け取り、判定し、請求者ヘルスケア提供者及び患者（適用可能なら）への送金通知（remittance）の発行を記録する。ヘルスケア提供者は、請求が主支払者によって一部の支払がなされ、二次支払者によってその他の請求部分の支払がなされる場合、二次提供者宛ての二次請求を追加作成する。この二次請求の予備判定及び発行手順は、主請求に対する図３のプロセスと同様である。

ステップ３２１における再検証が失敗に終わったことに応答して、ユニット４８は、その請求の手動レビューのスケジューリングを開始する。代案の実施形態では、図３のプロセスは、ステップ３１５から始まり、失敗を宣言して手動での請求の調査を始めるまでに、事前に設定された回数くり返される。検証済の請求データに対する処理が完了すると、その請求データは、ヒストリアンユニット７０を介してデータウエアハウス７２へアーカイブされる。ステップ３２７において、ユニット４８は、インタフェース１０を採用して請求データのアクセス、及び、患者、支払者、ヘルスケア提供者、患者の雇用者、及び政府機関などの外部エンティティとシステムとの間のデータ交換をサポートする。例えば、アクセスされたデータは、ポータル２０からポータル２８上に生成されたユーザインタフェースイメージを介してユーザに示される。この目的のため、インタフェース１０は、関係リポジトリ１８を使って、アクセスされた請求データを処理し、要求中の外部及び内部エンティティが望む所定のデータフォーマットと通信プロトコルで請求データを提供する。同様に、インタフェース１０は、関係リポジトリ１８を使って、アクセスされた請求データを処理し、要求中のエンティティが望む所定のハンドシェークルーチン及びサブミッション手順を実施する。

ステップ３２９においては、このシステムが特定の支払者ルールに従って動作することを検証する複数の照合済み請求データの検証に成功したならば、システムの認証がその支払者からが取得される。この認証は、図１のシステムが達成した能力のしきいレベルを示す。図３のフローチャートに詳述されるプロセスはステップ３３１で終わる。

図１〜１４に示すシステム、プロセス及びユーザインタフェース表示フォーマットは、限定的なものではない。同じ目的を達成するために、本発明の原理に従って他のシステム、プロセス及びユーザインタフェースフォームを作り出すこともできる。本発明の原理は、あらゆる業界及び分野における売上管理プロセスの合理化と自動化に適用可能である。この原理は、特に、保険、政府及びヘルスケア業界に適用可能である。

本発明の原理に従った、請求をヘルスケア支払者機関又は他のエンティティへ送信する前に請求の正確性を改善するために予備判定を採用した請求処理システム全体を示す。 本発明の原理に従った、図１の請求処理システム全体で使用される予備判定システムを示す。 本発明の原理に従った、図１及び図２のシステムによる請求処理で採用されるプロセスのフローチャートを示す。 本発明の原理に従った、傷害の処置に関する、ヘルスケア提供者と患者との複数の接触についての患者の請求発行レコードを示すユーザインタフェース表示イメージを示す。 本発明の原理に従った、ある特定の患者への請求についてのレコードを表示したユーザインタフェース表示イメージを示す。 本発明の原理に従った、請求プリプロセスの結果を示すと共に、請求拒否理由を、説明と拒否コードによって特定するユーザインタフェース表示イメージを示す。 本発明の原理に従った、例示的なルールとルールを患者請求データへ適用した結果の関連するエラーコードを示す。 本発明の原理に従った、請求処理で使用される中央データリポジトリに組み入れられたデータ要素を含むデータレコードを示す。 本発明の原理に従った、請求処理で使用される中央データリポジトリに組み入れられたデータ要素を含むデータレコードを示す。 本発明の原理に従った、請求処理で使用される中央データリポジトリに組み入れられたデータ要素を含むデータレコードを示す。 本発明の原理に従った、請求処理で使用される中央データリポジトリに組み入れられたデータ要素を含むデータレコードを示す。 本発明の原理に従った、請求処理で使用される中央データリポジトリに組み入れられたデータ要素を含むデータレコードを示す。 本発明の原理に従った、請求処理で使用される中央データリポジトリに組み入れられたデータ要素を含むデータレコードを示す。 本発明の原理に従った、請求処理で使用される中央データリポジトリに組み入れられたデータ要素を含むデータレコードを示す。

Claims (15)

1. 患者に対して提供されたヘルスケアに関連した請求データを処理するためのシステムであって、
   支払者宛に発行するための特定の患者についての請求に関連したデータを照合する請求データコレータと、
   照合済の請求データの処理に使用するルールのソースと、
   前記照合済の請求データを前記ルールを使用する処理にかけて、前記照合済み請求データが、支払いの発生を開始するための処理を行う状態にあることを検証するプリプロセッサと、
   前記プリプロセッサによる検証が成功したことに応答して前記の照合済の請求データを支払者宛に送る請求プロセッサとを含むシステム。
2. プリプロセッサは、前記ルールを使用して行った検証が不成功の場合に受信される訂正された照合済の請求データを前記ルールを使用する処理に再びかけて、前記照合済み請求データが、支払いの発生を開始するための処理を行う状態にあることを検証する、請求項１に記載のシステム。
3. ルールは、（ａ）ヘルスプランの払い戻し条件、（ｂ）ヘルスプランの請求フォーマット要件、（ｃ）払い戻し公式、（ｄ）払い戻し上の制限、及び（ｅ）払い戻し計算手順の内の少なくとも１つを含む所定の要件に請求要素が従っていることを判定するための手順を含み、
   前記請求要素は、（i）請求の一部、（ii）請求全体、（iii）請求の個々のレコード、及び（iv）ヘルスケアサービス提供者と患者の個々の接触に関するレコードデータの内の少なくとも１つを含む、請求項１に記載のシステム。
4. ルールは、（ａ）前記照合済み請求データの複数のデータフィールド間の矛盾を検出すること、及び（ｂ）前記照合済み請求データの要素が支払者が指定した限度を超えているか否かを判定することの少なくとも一方を行い、
   前記の複数のデータフィールドは、（i）電話番号、（ii)郵便番号、（iii)住所、（iv）別の地理的の識別子、（vi）臨床データ、及び（vii）その他の請求データの内の少なくとも２以上を含む、請求項１に記載のシステム。
5. 前記プリプロセッサは、訂正された照合済み請求データを前記プリプロセッサによる再検証のために自動的に待ち行列に入れる、請求項１に記載のシステム。
6. プリプロセッサは、
   （ａ）前記プリプロセッサのよる検証が不成功の場合に応答して、前記照合済の請求データの、前記の検証の結果として特定された欠陥が請求拒否をもたらす可能性が高いことをユーザに示すための警告メッセージの生成を開始すること、
   （ｂ）前記プリプロセッサのよる検証が不成功の場合に応答して、請求拒否をもたらす可能性が高い前記照合済み請求データ中の欠陥を訂正することを含む、ヘルスケアワーカが行なうべき仕事のスケジューリングを開始すること、及び
   （ｃ）前記プリプロセッサによる検証が不成功の場合に応答して、請求拒否をもたらす可能性が高い前記照合済み請求データ中の欠陥を訂正するために前記照合済データを処理することの内の少なくとも１つを行う、請求項１に記載のシステム。
7. 前記のルールのソースは、（ａ）支払者が提供する遠隔に位置するルールソース、及び（ｂ）ルールリポジトリの内の少なくとも１つであり、
   前記プリプロセッサは、前記照合済の請求データを、前記ユーザが提供する請求サブミッッション手続き使用して、前記支払者ルールでの処理にかける、請求項１に記載のシステム。
8. （ａ）支払者、（ｂ）支払者メッセージ、（ｃ）支払者ウエブサイト、（ｄ）以前に特定された請求データの不備に応答してルールを作成するためのルール作成プロセッサ、及び（ｅ）規制ガイドラインを含む複数のソースの内の少なくとも１つから、前記ルールソースが保持すべきルールを蓄積するためのルールアキュムレータを含む、請求項１に記載のシステム。
9. ルールの適用を起動する条件を特定するために、取得した請求データを処理するルールプロセッサを備え、前記ルールプロセッサは、少なくとも、
   （ｉ）特定された条件に応答して、ルールを請求データの編集作業に適用し、ルールプロセッサは、第１の条件の状態に応答して第１のルールセットを、又、第２の条件の状態に応答して第２のルールセットを適用すること、
   （ｉｉ）（ａ）患者についての請求データに組入れるレコードの生成、（ｂ）患者についての請求データに追加するレコードの検出、（ｃ）患者請求書発行レコードに追加するレコードの検出、（ｄ）患者請求書発行レコード内の変化の検出、及び（ｅ）患者についての請求データ内の変化の検出の内の少なくとも１つを含むイベントに応答して、取得した請求データの処理すること、及び
   (iii)前記ルールの適用に応答して、（ａ）ヘルスケアワーカが行うべき仕事のスケジュールを作成する、（ｂ）エラーレポートを作成する、（ｃ）請求データの編集作業において使用する前記ルールを適用した結果のレコードを生成する、（ｄ）会計レポートを生成する、（ｅ）請求の生成、及び、（ｆ）送金を受領することの内の少なくとも1つを実行すること
   の何れかを行う、請求項１に記載のシステム。
10. 前記ルールプロセッサは、条件の特定に応答して、ヘルスケアワーカが実行すべき取得済の請求データのレビューのスケジューリングを開始する、請求項９に記載のシステム。
11. （ａ）患者、（ｂ）支払者、（ｃ）ヘルスケア提供者、（ｄ）患者の雇用者、及び（ｅ）政府機関の内の少なくとも１つによる照合済の請求データへのアクセスをサポートするユーザインタフェースを含む、請求項１に記載のシステム。
12. （ａ）患者、（ｂ）支払者、（ｃ）ヘルスケア提供者、（ｄ）患者の雇用者、及び（ｅ）政府機関の内の少なくとも１つの外部エンティティと前記システムとの間のデータの交換をサポートするインタフェースプロセッサを含み、前記データ交換は、データフォーマット及びプロトコル変換を使用することによってサポートされる、請求項１に記載のシステム。
13. 個々の請求要素の有効性を判定するための別のルールセットの適用を起動する条件を特定するために、取得した請求データを処理するルールプロセッサを含む、請求項１に記載のシステム。
14. ルールプロセッサは、前記個々のヘルスケア接触のレコードが前記の特定の患者の照合済み請求データへ組入れられることに応答して、個々のヘルスケア接触についての個々の請求要素を処理する、請求項１３に記載のシステム。
15. 患者に対して施されるヘルスケアに関する請求データを処理する方法であって、
    支払者宛に発行するための患者についての請求に関連したデータを照合するステップと、 前記照合済データが支払いの発生を開始する処理を行う状態にあることを検証するため、所定のルールを使用して照合済み請求データを処理するステップと、
    前記プリプロセッサによる検証が成功したことに応答して、支払者宛に前記照合済の請求データを発行するステップとを含む方法。

Images