JP2005522789A - ヘルスケア及びその他の請求データを処理するためのルールの使用をサポートするシステム及びユーザインタフェース。 - Google Patents

Abstract

【解決手段】集中化ルールリポジトリには、医療手順の適切性の検証、患者紹介、治療の許可、データ入力編集、電子的な請求書発行、請求ステータス判定及び電子送金処理をサポートする際において患者請求データを処理するために使用される矛盾無く表現されたルールを保持している。患者へのヘルスケアの提供に関連した請求データを処理するために使用されるルールを管理するためのシステムは、複数の異なるソースからのルールを表すデータを取得するためのインタフェースプロセッサを含む。システムは、取得したルールを表すデータを累積するルールリポジトリ、及び受取ったメッセージに応答して、リポジトリから得た選択されたルールの請求データ処理への適用を開始するルールプロセッサを含む。結果プロセッサは、選択されたルールを請求データへ適用して得られた結果を出力のために処理する。また、インタフェースプロセッサは、取得したルールをルールリポジトリへの格納に適した共通の構文に変換する。

Description

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

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

公知の判定システムの場合、ヘルスケア請求支払者機関は、ヘルスケア提供者が発行する請求を判定するときに支払者が適用するルールの定義をヘルスケア提供者に提供する。これは、請求を作成するときに使用すると共に、ルール要件と矛盾がない情報を与える入院及び処置手順を確立するための独自のルール（理想的には支払者のルールと同じ）をヘルスケア提供者がその場所で再作成して実施するという意味である。しかしながら、ヘルスケア提供者は、ルールをその場で実行するために、支払者機関が提供するルールの定義を解釈する必要がある。更に、ヘルスケア提供者は、管理機関（ＣＣＩ（correct coding initiative）ルールなど）他のソースから及びヘルスケア提供者自身（例えば、少額の未払残を削除するルール）から取得した請求処理ルールを実行し適用することも必要である。

ある公知のルール処理システムは、臨床システムの補助として動作して、警告を発すると共に、医療ミスを防ぐのを助ける。また、このルール処理システムは、例えば、より低廉な代替薬物療法に切換えるか、又は静脈薬物療法から等価な錠剤に切換えることを推奨することにより、ヘルスケア提供者及び支払者機関のコストを低減することをユーザに対して提案する。他のルール処理システムは、請求の観点からルールにアプローチし、電子的又は手動による発行の前に請求を「きれいにする（scrub）」請求編集アプリケーションを開発している。別のルール処理システムは、独立した準拠テストエンジンを備えている。典型的な公知のルール処理システムでは、請求を支払者へ送る前に患者への請求の内容が正確であることを保証する際に、ヘルスケア提供者は独自のルールセットを確立することで、限定的なルール処理の自動化により、ヘルスケア提供者及び支払者の条件に対応している。これは、個々の提供者組織に対してセットアップ、保守及び準拠検証の負担をかけることになる。

公知のルール処理システムでは、これらのシステムが採用しているルールデータベースが断片的、分散的であり、且つ分離的であることによって複雑に絡み合う多くの問題が発生する。即ち、支払者機関が定義したルールを正確に実行しようとする場合、ルールを維持する場合、可変フォーマット及び構文を採用したルールを処理する場合、ルールの最新バージョンが採用されていることを確実にする場合、及びルールを一貫した方法で適用する場合に問題が生じる。これによって、支払者による受け取り後の編集プロセスに失敗する請求が発生し、その結果、支払者によって却下されることになる。請求の却下により支払が遅れ、ヘルスケア提供者のキヤッシュフロー及び患者のプロセスに対する満足度に悪影響を与える。発明の原理に従ったシステムは、請求をヘルスケア支払者機関へ送付する前に請求の正確性を向上するためにルールの処理を改善する。

集中化ルールリポジトリには、医療手順の適切性の検証、患者紹介、治療の許可、データ入力編集、電子的な請求書発行、請求ステータス判定及び電子送金処理をサポートする際における患者請求データの処理に使用される矛盾なく表現されたルールを保持している。患者へのヘルスケアの提供に関連した請求データを処理するために使用されるルールを管理するためのシステムは、複数の異なるソースからのルールを表すデータを取得するためのインタフェースプロセッサを含む。システムは、取得したルールを表すデータを累積するルールリポジトリ、及び受取ったメッセージに応答して、リポジトリから得た選択されたルールの請求データ処理への適用を開始するルールプロセッサを含む。結果プロセッサは、選択されたルールを請求データへ適用して得られた結果を出力のために処理する。

図１は、請求をヘルスケア支払者機関又は他のエンティティへ送信する前に請求の正確性を改善するたに予備判定を採用した請求処理システム全体を示す。図１のシステムにおいて、個々のヘルスケアプロバイダ及びヘルスケア支払者機関が該ルールの最新バージョンで作業が行えるようにするため、リポジトリ７４の中の集中化共通ルールは常に更新されている。集中化ルールを使用することによって、ヘルスケアプロバイダが該ルールの最新バージョンに準拠することが保証される。本明細書で使用されるルールという語は、ヘルスケア請求の要素が、ヘルスプラン払い戻し（reimbursement）条件、ヘルスプランフォーマット要件、払い戻し公式、払い戻し制限、及び払い戻し計算手順を含めた、所定の要件に従っていることを判定するための手順（実行可能手順又は手動介入によって実施される手順を含む）を含む。ルールは、フォームとデータ、又はフォームとデータとの間の関連を使って、作業をどのように提示し、実行し、調整するかにについての予め決められたガイド、指針、又はモデルをも含むことがある。ここで説明したルールリポジトリは、他の実姉形態においては、単一のリポジトリ又は異なる配置の複数のリポジトリとして配置されることもある。更に、本明細書で使用される例外という語は、問題を特定すること及びその問題を処理するメカニズムまで包含するものである。又、本明細書で使用される請求の要素という語は、請求の一部、請求全体、請求の各レコード、及び患者とヘルスケアサービス提供者との接触（encounter）に関連したレコードデータを含む。加えて、本明細書で使用されるウインドウという語は、ユーザに対して所望のテキスト又はグラフィック又はその他の内容を表示するために使うイメージ領域を含み、マイクロソフトやその他特定の動作環境に限定されるものではない。

集中化ルールリポジトリ７４によって、ヘルスケア業界の参加者全体を通してのルールセットの統合及び通信を一貫性のあるものにできる。ルールリポジトリ７４は、ユニット５０によるチェック及びユニット４６での実行のための最新のカレントルールを含む。該ルールは、複数のアプリケーションプラットフォーム及びヘルスエンタープライズとの互換性を保証するために、標準の構文及びプロセス標準の請求データ識別子及び値のセットで表現される。図１のシステムでは、請求の正確性を保証するため、ヘルスケアと患者の接触情報及び関連する請求データを処理するために、複数のヘルスケアエンティティ全体からルールを収集して組み合わせることをサポートする。本明細書で使用される接触（encounter）という語は、ヘルスケア企業との患者との接触を含み、これには、経済的又は取引の結果を伴う患者とヘルスケア企業とのやりとりを含み、例えば、患者の訪問、電話連絡、入院患者の滞在又は外来患者の処置などを含む。集中化ルールリポジトリ７４によって、システムの参加者は、変化の速いルールと規制を遵守することが可能になる。更に、（事実の後のシーケンシャル処理ではなく）必要な場合に臨床的イベントに応じてルールを適用することによって、請求の却下が予期せずに発生したり、遅れて発生したり、又はさかのぼって発生したりすることなく、要求されたアクションが起きることに確信が持てるようになる。ルールは頻繁に変わり、正確には、新しい技術、手順、及び治療方式の導入によって変わる。リポジトリ７４は、有利なことに、ルールだけでなく廃棄されたルールや古くなったルールのレコードの有効な期日及び解約日を保持している。更に、請求データを処理する際のルールの選択及び動作は、患者のヘルスケアとの接触に関連した入院日、誕生日、退院日、及び処置日などの特定の日付によって影響される。

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

図１のシステムは、請求に間違いがないことを保証するため、請求データを編集するためにルールリポジトリ７４からのルールを採用する。また、このシステムは、有利なことに、該ルールを使って請求の予備判定（前処理）を実行し、編集された照合済みの請求データが、支払いの発生を開始するための支払者機関による実際の判定のために送出できる状態にあるかどうかを検証する。予備判定が失敗に終わった場合は、自動的に欠陥の修正が開始されるか、専門担当者が行うべきワークリストの仕事をスケジューリングすることにより、手動による介入が行われる。予備判定が成功裏に完了すると、請求データは、支払者宛に電子的に送信するために、再び待行列に自動的に加えられる。支払通知は、手動による介入なしに電子的に処理され、所定の口座に自動的に記帳される。

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

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

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

予備判定ユニット４８によって実行されるルールは、予測される判定結果を、指定された一組の請求データを指定された支払者宛に送信する際に決定する。ユニット４８は、ルールキーパインタフェース６６を介してリポジトリ７４（又は、ルールアクセッサ５２）から取出されるルールを使用し、指定された一組の請求データを指定された支払者宛に送信した結果を予測する。この目的のため、ユニット４８が使用するルールが、選択された特定の支払者が使用するルールを複製する。ユニット４８は、請求を指定された支払者宛に送信する前に、支払拒否になりそうな状態を特定し、こうした状態を（自動的又は手動で）直すことができるようにしておく。この手順は、リポジトリ７４から取出されるルールを使うか、遠隔地からアクセスされるルールを使って、エラーの無い請求の作成を容易に行うことができ、有利である。規制ガイドライン及び諸指示を含むルールは、継続的に取得されてリポジトリ７４に格納され、且つ、ルールキーパ６６を介してこのリポジトリ内で更新されて、保持される。ルールリポジトリ７４には、医者の識別子と患者との関係がリストされたコードセットの汎用カタログを採用し、データが電子的形態、イメージ、その他の表示形態でどのように表示されるかを制御するためのヘルスケアデータルールが組込まれている。これらのルールは、データのフォーマット化を決定し、且つ、選択可能なデータフォーマット（例えば、mm-dd-yyyy 又は yyyy-mm-dd、他）を含む、様式ＵＢ９２の要件（電子バージョン６）、又はＡＮＳＩ８３７ｐ（バージョン４０１０）の要件を含む、実施ガイドの汎用カタログを使用する。また、リポジトリ７４は、規制機関によって義務付けられており、診断コードなどのコードセット、ＣＣＩ（Correct Coding Initiative）の要件、ＡＰＧ（Ambulatory Patient Group）及びＤＲＧ（Diagnosis Related Group）患者分類体系からなる汎用カタログを採用したヘルスケア準拠ルールをも含む。リポジトリ７４は、ルールの名前を識別し、ルールセットをグループにまとめ、シーケンシャルに実行すべきルールセットを指定するためのリスト、さらに、業務処理を楽にするための業務ルール又はその他のルールをも含む。システム接続性ルールもリポジトリ７４及び関係リポジトリ１８にも保持されている（インタフェース１０を介して通信をサポート）。これらの接続性ルールは、ｅ-コマースコミュニケーション(例えば、特定のノード名に対しての２４００ＫボーでのＦＴＰの使用)をサポートする、又は、通信モードを決定する（例えば、問合せ又は回答を調べるためにＥメールを使うことを促す）。その他のルールは、照合済み請求データの電話番号、郵便番号、住所又は其の他地理上の識別子などを保持しているデータフィールド間の矛盾を検出する。

ルールアーカイブユニット７６はユニット６６と共に、アーカイブすべきルールに日付及び時間をスタンプすると共に、期限の切れた、即ち古いバージョンのルールを（ルールウエアハウス）データベース７８に格納する。アーカイブ済ルールは、例えば、特定の請求データに対して、過去のある日において有効であったルールを用いた判定を行った結果を決定するためにアクセス可能且つ使用可能である。リポジトリ７４は、支払者機関加入者から取得する判定ルール及び支払者との前の取引から確立されたルールを含む。リポジトリ７４は、該システムおよび許可された参加者によって作られた、自動化プロセスをシステムへ追加する諸ルールをも含む。パターンクリエータユニット３８は、監視調査プロセスを定義するための専用ルールを作成し、ルールメーカユニット５６を使い、汎用ルールを作成する。

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

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

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

図２は、図１の請求処理システム全体において使用される、サーバをベースにしたルール機能（正確には、ルール機能１８、４６、５０、５２、５４、５６）を含むルール処理システムを示す。前述の通り、ユニット４６は、患者の請求データの処理において、インタフェース６６を介してリポジトリ７４から取り出したルールを実行する、リポジトリ７４内のルールは、インタフェース１０及びデータネットワーク５８（図１）を介してルールアクセッサ５２によって、外部のルールソース（図１の支払者機関６０が所有するルール６２など）から得る。ルール取得ユニット５４は、取得したルール（ルールギャザラサービス８０及び手動入力及びその他の手段によって取得される）を、図１に関連して前に述べた方法でルールメーカ５６が供給するユーザインタフェースを使用して構文の解析を行う。関係ルールリポジトリ１８は、通信を確立する際に使われる他のルール及びインタフェース１０が関与する通信の間に、プロテクタ１２、トランスレータ１４、及びトランスポータ１６が必要とし使用するルールを含む。

図３は、請求処理において、図１のシステムによって使用されるプロセスのフローチャートを示す。ステップ３００で開始された後のステップ３０３において、ユニット５２とユニット５４（図１）は、複数の異なるソースを間欠的に問い合わせ、リポジトリ７４内に保持されている新しいルール及び既存のルールの更新版を取得する。異なるソースには、支払者機関、支払者機関が提供するメッセージ、支払者機関のウエブサイト、規制ガイドライン、及び、以前に特定されている請求データの不備に応答して作成されたルールのソースが含まれる。ユニット５６は、ステップ３０７において、ヘルスケア請求データを処理する際に使用するルールの作成をサポートするユーザインタフェース表示イメージの生成を開始する。即ち、ユニット５６は、生成されたルールの一部として請求データに対して行うテスト又はルールをユーザが選択できるようにするプロンプト要素を含んだ表示イメージウインドウの生成を開始する。テストは、利用可能な所定のテストの中から選択される。別のイメージ要素は、生成されたルールによって処理される請求データのソースのユーザによる識別を可能にし、更に別のイメージ要素は、生成されたルールが所定の基準に適合していることを検証するために、生成されたルールの検証をユーザが開始することをサポートする。もう１つのイメージ要素は、ルール生成時にユーザをガイドするためにユーザに表示するヒントになるテキストを作り出すことをサポートする。ユニット５６は、また、生成済ルールの請求データへの適用に応答して実行すべき結果アクションをユーザが選択できるようにするプロンプト要素を含んだウインドウ及び生成済みルールを表示するウインドウの生成を開始する。

ルールメーカ５６は、ステップ３０９において、既に他の請求データセットに対して行った判定の結果に関連した情報を基にルールを導き出す。この結果情報は、サーバ８０が支払者から得るか、又は請求却下の発生及び判定の成功と失敗の割合を監視することによって得るもので、特定された問題を解決するために、判定又はルールの作成をサポートする。各ルールは、「真」状態を特定して関連する第１のアクションのセットを開始する、又は「偽」状態を特定して関連する第２のアクションのセットを開始するための１以上のテストを含む。ルールテストの条件は、単純な場合もあり、論理演算（例えば、「ＡＮＤ」、「ＯＲ」、「ＮＯＴ」）で接続された組合せテストを含む複雑なものである場合もある。リンクされた個々のテストの結果が論理的に組合されてテスト全体の結果として「真」か「偽」を提供される。ステップ３１１において、ユニット６６は、ルール及びそのルールに組み込まれたテストの両者に対して、有効期間を割当てる。ルール及びテストは、リポジトリ７４に、有効期間を示す日時スタンプインディケータと共に格納される。また、ステップ３１５において、ルールリポジトリ７４は、特定のルールを、（ａ）患者についての請求データに含めるレコードの生成、（ｂ）患者についての請求データに追加するレコードの検出、（ｃ）患者の請求発行レコードに追加するレコードの検出、（ｄ）患者の請求発行レコードの変化の検出、及び（ｅ）患者についての請求データの変化の検出などのイベントに関連付ける。

ステップ３１７において、ユニット５６は、取得したルール及び導出したルールを表すデータを解析し、リポジトリ７４への格納に適した構文に変換する。ユニット５６は、この目的のため、所定の識別子と所定の値のセットを使用して、取得したルールを共通的な構文に変換する際に取得したルールを表すデータを解析する。図８は、ユーザインタフェース表示イメージであり、特定のことが起こったことに応答して警告を発するために病院（８７０）の請求データを処理するのに使用されるルールのためのルールコード言語共通構文のフォーマットの例を示している。即ち、ルール８６０は、コモンＩＦ−ＥＮＤＩＦステートメント言語構文を使用する。これは、発生コード４１及び値コード３０（アイテム８６３及びアイテム８６７）の両方が請求を表すデータの中での出現を特定するため、及び、そのような特定に応答してユーザへの警告メッセージの生成を開始するために使用される。同様に、図９は、ユーザインタフェース表示イメージであり、請求データの処理において使用されるルールコード言語共通構文の別のフォーマットの例を表している。即ち、ルール７９０は、マルチレベルの共通入れ子Ｉｆ−ＥｎｄＩｆステートメント言語構文を使用する。これは、乗物での事故による怪我に関連した請求入力であることを指示する２番目の手順コードが請求を表すデータの中にあるかどうかを特定するのに使用される。このような手順コードが存在しない場合、このルールは、手順コードＰ０１．０９の他に入院日に等しい手順日付を追加する。この「Ｘ」カウンタ（即ち、ルール７９０の１行目のＸ＝０のステートメント）は、このルーチンが一度だけ実行されることを保証する。

ステップ３１９において、ユニット５２とユニット５４は、取得されたルール及び導出されたルールを表すデータをルールインタフェースユニット６６を介してリポジトリ７４に累積する。ステップ３２１において、ルールチェッカ５０は、取得されたルール及び導出されたルールを検証し、これらのルールには内部的に矛盾がないこと、所定の構文にフォーマット化されていること、そしてリポジトリ７４内の他のルールとの矛盾がないことを検証する。ステップ３２３において、ユニット５６は、ルールリポジトリ７４の更新を管理し、且つルールの有効期間の開始日、ルールの有効期間の最終日、及びルールの変更日に関するレコードを保持する。ステップ３２５においてイベントを特定するメッセージを受信したこと応答して、ユニット４６はステップ３２７において、そのイベント（ステップ３１５参照）に関連した特定のルールの適用を開始し、データリポジトリ６８から取り出された、特定の患者の請求に関連した照合済データの処理を行う。しかしながら、ユニット４６は、ルールの有効期間を調べ、有効期間を外れた日時においては、ルール又はテストコンポーネントを実行しない。図４は、特定の患者（患者はアイテム４２０によって特定される）に対する請求発行レコードを表示したユーザインタフェース表示イメージ示す。この請求発行レコードは、怪我の治療に関する、ヘルスケア提供者との複数の患者の接触４０２、４０４、及び４０６に対する照合済の請求データを含む。

図５は、患者の請求データの処理にて適用すべく選択されたルール及びテストを指示する病院５００のルールプロファイル５０２を表示したユーザインタフェース表示イメージを示す。このルール及びテストは、カラム５３０内で識別され且つカラム５３２に記述されている各請求要素フィールド内のデータに適用するよう指定される。最初に、請求データは解析され、請求が何か特別な特徴を含んでいるかどうか（例えば、その請求が老齢者医療保険制度又は低所得者医療扶助制度でカバーされているか）が識別される。識別された特徴は、２つのデータ要素である受取者ＩＤ５０４及びサービスタイプ５０６に対する値を取出すために解釈される。例えば、予め定義された請求カテゴリは、老齢者医療保険制度パートＡ（受取者ＩＤ＝Ｃ、例えば、アイテム５０８）、老齢者医療保険制度パートＢ（受取者ＩＤ＝ＣＢ、例えば、アイテム５１０）又は低所得者医療扶助制度（受取者ＩＤ＝Ｄ、例えば、アイテム５１２）を含む。サービスタイプは、所定の標準のルール及びテストのセットを適用する必要があることを示す「ＲＥＧ」（アイテム５１６）、サービスタイプが指定されておらず、ルール及びテストの所定のデフォルトセットが適用されることを示す「＃＃＃」（アイテム５１８）、及び、処理を必要としている請求には関連しないレポートであることを示す「Ｎ／Ａ」（アイテム５１４）を含む。その他のサービスタイプ５０６及び受取者ＩＤ５０４要素も使用することができ、ここで記載したものは例示に過ぎない。データ要素５０４及び５０６を使用して、特定のカテゴリー（５０４）及びサービスタイプ（５０６）に対してカラム５３０内の各請求要素フィールドに適用されるルール及びテストを決定する。

請求のカテゴリー５０４及びサービスタイプ５０６に対しての請求要素フィールド５３０に適用可能なルール及びテストは、見出しＲ（例えば、アイテム５２０）の下の要件テスト及び見出しＶ（アイテム５２４）の下の検証テストを含む。特定の請求要素フィールド５３０に隣接するカラムＲへのエントリが、その特定の請求要素フィールド５３０が値を含んでいない場合に採るべきアクションを特定する。特定の請求要素フィールド５３０に隣接するカラムＶへのエントリが、その特定の請求要素フィールド５３０の値が、所定のテスト基準に適合していない場合に採るべきアクションを特定する。カラムＲにリストされる例示的なアクション識別子は、値が存在しない場合には、エラーを宣言すべきであることを示す「Ｅ」、値を含んでいる場合には、そのフィールドをクリアすべきであることを示す「２」、値が存在しない場合には、その請求を保留すべきであることを示す「Ｈ」、及び、値が存在しない場合には、ユーザへの警告メッセージを生成すべきであることを示す「Ｗ」を含む。同様に、カラムＶにリストされる例示的なアクション識別子は、検出された値が検証テスト又はルールに失敗した場合には、エラーを宣言すべきであることを示す「Ｅ」、値を含んでいる場合には、そのフィールドをクリアすべきであることを示す「２」、検出された値が検証テスト又はルールに失敗した場合には、その請求を保留すべきであることを示す「Ｈ」、及び、検出された値が検証テスト又はルールに失敗した場合には、ユーザへの警告メッセージを生成すべきであることを示す「Ｗ」を含む。これらのアクションは例示的なものであり、他のアクションも採用できる。従って、例えば、サービスタイプがＲＥＧの老齢者医療保険制度（パートＡ）の請求において入院日フィールド５３０が値を持たない場合、エラーが生成される。更に、サービスタイプがＲＥＧの老齢者医療保険制度（パートＡ）の請求において、入院日フィールドが値を有しているが、検出された値が検証テスト及びルールに失敗した場合、エラーが生成される。

図６は、請求データの処理においてルールを適用した結果を表示すると共に、請求拒否の理由を説明と拒否コードによって特定するためのインタフェース表示イメージを示す。即ち、例えば、エラー６５１とエラー６５３（エラーコードｓｃ０００１８及びｓｃ０００１９）は、請求データの入院日の値が、範囲外か又は無効であることをそれぞれ表す。これらのエラーは、前述したように、サービスタイプが「ＲＥＧ」、「＃＃＃」、及び「Ｎ／Ａ」である老齢者医療保険制度パートＢカテゴリーの請求について、警告メッセージが出される。

図１０は、ステップ３２７において検証ルールを適用した請求処理結果を表示すると共に、請求拒否の理由を説明と拒否コードによって特定するためのインタフェース表示イメージを示す。即ち、行６００は、エラーコード番号、エラーコードの識別子とレベル、エラーコードのサブ識別子、エラーの説明テキスト、及び訂正されたエラー（この例にはない）を特定する解消済みエラーを含むカラムを定義するエラーリストの見出しラベルを示す。行６０２から行６１７には、検証ルールを患者についての請求データに適用した結果がリストされている。この結果リストから、無効収入コード（６０２）、データフォーマット不備（６０７）、名前欠落箇所（６０９）、入院データへの警告（６１１）、収入コード関連の警告（６１３）、手順コード関連の警告（６１５）、及び入院又は補助データの警告（６１７）を含む７つの請求拒否理由を特定している。

図３のステップ３２９に続き、ユニット４６は、出力を提供するために、選択したルールを請求データに適用することによって得られる結果を処理する。ユニット４６は、ルールの適用によって得られた結果に従って、ヘルスケアワーカが行うべき作業をスケジュールし、エラーレポートの作成を開始し、請求データを編集するためにルールを適用した結果に関するレコードの作成を開始し、会計レポートの作成を開始する。また、ユニット４６は、請求を作成すること、送金通知を送ること、ヘルスケアワーカが行う請求データのレビューのスケジューリング、請求拒否になる可能性が高い請求データの不備をユーザに指摘するために警告メッセージの作成を開始する。図３のプロセスはステップ３３１で終了する。

図７は、支払者機関からの請求の判定結果に従ってルールを取り出して変更する際に使用されるプロセスのフローチャートを示す。ステップ７６０において、特定の患者についてのヘルスケア請求に関する照合済みの請求データがヘルスケア提供者によって支払者機関へ送付される。支払者機関は、ステップ７６３において、送付された請求が特定の患者のヘルスプランに関連した支払者の所定の要件及びルールに適合しているかどうかを検査する。支払者は、ステップ７６７において、支払者ルールを使用して発行された請求の判定の後で、給付金（benefit）ステートメントの説明を患者及びヘルスケア提供者に対して提供する。ステップ７６９において、サービス（例えば、図１のサービス８０）は、受取った給付金の説明を評価し、この説明を、請求拒否の発行及び判定の成功と失敗の割合をモニタする際、及びリポジトリ７４内の既存のルールを調整する際に使う情報を提供する際、又は特定された問題を解決するために新しいルールを作成する際に使う。ステップ７７１において、リポジトリ７４内の新しいルール又は更新されたルールが保持され、且つ請求データが支払者機関へ送付される前に請求データに対して適用、これにより、請求処理の効率が改善され、請求の拒否及び却下の割合が減少する。

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

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

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

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

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

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

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

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

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

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

本発明の原理に従った、ルール処理を採用した請求データ処理システム全体を示す。 本発明の原理に従った、図１の請求データ処理システム全体の中で使用されるルール処理システムを示す。 本発明の原理に従った、図１及び図２のシステムによって、ルール処理において採用されるプロセスのフローチャートを示す。 本発明の原理に従った、怪我の治療に関するヘルスケア提供者と患者との複数の接触についての患者の請求発行レコードを表示するユーザインタフェース表示イメージを示す。 本発明の原理に従った、患者の請求データ処理に適用すべく選択されたルール及びテストを示すホスピタル５００のルールプロファイルを表示するユーザインタフェース表示イメージを示す。 本発明の原理に従った、例示的ルールを請求データに適用した結果を表示すると共に記述及び拒否コードによって請求拒否理由を特定するユーザインタフェース表示イメージを示す。 本発明の原理に従った、支払者機関からの請求判定の結果に応答してルールを取出し、修正するときに採用されるプロセスのフローチャートを示す。 本発明の原理に従った、特定の発生に応答して警告を発するための例示的なルールコード言語共通構文のフォーマットを表示するユーザインタフェース表示イメージを示す。 本発明の原理に従った、請求データの処理において使用される、別の例示的なルールコード言語共通構文のフォーマットを表示するユーザインタフェース表示イメージを示す。 本発明の原理に従った、請求処理の結果を表示すると共に、請求拒否の理由を説明と拒否コードで特定するユーザインタフェース表示イメージを示す。 本発明の原理に従った、請求処理で使用される集中データリポジトリに組込まれるデータ要素を含むデータレコードを示す。 本発明の原理に従った、請求処理で使用される集中データリポジトリに組込まれるデータ要素を含むデータレコードを示す。 本発明の原理に従った、請求処理で使用される集中データリポジトリに組込まれるデータ要素を含むデータレコードを示す。 本発明の原理に従った、請求処理で使用される集中データリポジトリに組込まれるデータ要素を含むデータレコードを示す。 本発明の原理に従った、請求処理で使用される集中データリポジトリに組込まれるデータ要素を含むデータレコードを示す。 本発明の原理に従った、請求処理で使用される集中データリポジトリに組込まれるデータ要素を含むデータレコードを示す。 本発明の原理に従った、請求処理で使用される集中データリポジトリに組込まれるデータ要素を含むデータレコードを示す。

Claims (16)

1. 患者に対してのヘルスケアの提供に関連した請求データを処理するのに使用するルールを管理するためのシステムであって、
   複数の異なるソースからのルールを表わすデータを取得するインタフェースプロセッサと、
   取得したルールを表すデータを累積するルールリポジトリと、
   受取ったメッセージに応答して、前記リポジトリから取り出した選択されたルールの請求データ処理への適用を開始するルールプロセッサと、
   前記選択されたルールを前記請求データに適用することによって導き出された結果を出力のために処理する結果プロセッサとを含むシステム。
2. ルールは、（ａ）ヘルスプランの払い戻し条件、（ｂ）ヘルスプランのフォーマット要件、（ｃ）払い戻し公式、（ｄ）払い戻し上の制限、及び（ｅ）払い戻し計算手順の内の少なくとも１つを含む所定の要件に請求要素が従っていることを判定するための手順を含み、
   前記請求要素は、（i）請求の一部、（ii）請求全体、（iii）請求の個々のレコード、及び（iv）ヘルスケアサービス提供者と患者の個々の接触に関するレコードデータの内の少なくとも１つを含む、請求項１に記載のシステム。
3. 前記インタフェースプロセッサは、他の請求データセットについての以前の判定結果に基づいてルールを導き出す、請求項１に記載のシステム。
4. 前記インタフェースプロセッサは、ヘルスケア支払者機関が提供する（i）資料及び（ii）その他情報の内の少なくとも一方に基づいてルールを導き出し、
   前記複数の異なるソースには、（ａ）支払者、（ｂ）支払者メッセージ、（ｃ）支払者ウエブサイト、（ｄ）以前に特定された請求データの不備に応答してルールを作成するためのルール作成プロセッサ、及び（ｅ）規制ガイドラインが含まれる、請求項１に記載のシステム。
5. 前記ルールリポジトリは、有効期間を個々のルールと関連付け、
   前記ルールプロセッサは、前記ルールの有効期間を調べ、前記ルール有効期間外の日時においてはルールを適用しない、請求項１に記載のシステム。
6. ルールは真又は偽の状態を特定するのに使用される少なくとも１つのテストを含み、前記ルールプロセッサは、真の状態に応答して第１のアクションを開始し、偽の状態に応答して第２のアクションを開始し、
   前記ルールは、テストの組合せを含み、個々のテストの結果が論理的に組合せられて全体的な真又は偽の結果を提供し、
   前記ルールリポジトリは有効期間を個々のテストと関連付け、
   前記ルールプロセッサは、前記のテスト有効期間を調べ、前記テスト有効期間外の日時においてはテストを適用しない、請求項１に記載のシステム。
7. 前記インタフェースプロセッサは、取得したルールを前記ルールリポジトリへの格納に適した構文に変形し、
   前記インタフェースプロセッサは、（ａ）所定の識別子と（ｂ）所定の値のセットのうちの何れかを使用して、前記の取得したルールを前記ルールリポジトリへの格納に適した共通の構文へ変換する際に、取得したルールを表すデータを解析する、請求項１に記載のシステム。
8. 前記ルールプロセッサは、（ａ）取得したルールと（ｂ）前記リポジトリ内のルールの内の少なくとも一方を検証して、ルールが（i）内部的に矛盾がないもの、（ii）所定の構文にフォーマット化されているもの、及び（iii）前記リポジトリ内の他のルールとの矛盾がないものの内の少なくとも１つであることを検証する、請求項１に記載のシステム。
9. 前記インタフェースプロセッサは、前記ルールリポジトリの更新を管理すると共に、（ａ）ルールの有効期間の初日、（ｂ）ルールの有効期間の最後日、及び（ｃ）ルールが変更された日の内の少なくとも１つの日のレコードを保持する、請求項１に記載のシステム。
10. 前記ルールリポジトリは、特定のルールをイベントに関連付け、
    前記ルールプロセッサは、前記受け取ったメッセージ内に特定された前記イベントの発生に応答して、前記特定ルールの請求データ処理への適用を開始し、
    前記イベントには、（ａ）患者についての請求データに含めるレコードの生成、（ｂ）患者についての請求データに追加するレコードの検出、（ｃ）患者請求書発行レコードに追加するレコードの検出、（ｄ）患者請求書発行レコード内の変化の検出、及び（ｅ）患者についての請求データ内の変化の検出が含まれる、請求項１に記載のシステム。
11. 前記の複数の異なるソースには、支払者が提供する遠隔地のルールソースが含まれ、
    前記ルールプロセッサは、前記支払者が提供した請求送出手順を使用して、前記支払者のルールでの処理のために前記請求データを送出し、
    前記インタフェースプロセッサは、（ａ）新しいルール、及び（ｂ）前記ルールリポジトリ内に保持されている既存ルールの更新の内の少なくとも一方を得るために前記複数の異なるソースの内の少なくとも１つに間欠的に問い合わせる、請求項１に記載のシステム。
12. 前記複数の異なるソースには、（ａ）支払者、（ｂ）支払者メッセージ、（ｃ）支払者ウエブサイト、（ｄ）以前に特定された請求データの不備に応答してルールを作成するルール生成プロセッサ、及び（ｅ）規制ガイドラインによって提供されるルールを含む、請求項１に記載のシステム。
13. 前記結果プロセッサは、（ａ）ヘルスケアワーカが行うべき作業をスケジュールすること、（ｂ）エラーレポートを作成すること、（ｃ）請求データの編集時に使用する前記ルールを適用した結果のレコードを作成すること、（ｄ）会計レポートを作成すること、（ｅ）請求を生成すること、（ｆ）送金を受取ること、（ｇ）ヘルスケアワーカが行う請求データのレビューのスケジューリングを開始すること、及び（ｈ）請求拒否になる可能性が高い請求データ内の不備を示すためにユーザに対する警告メッセージの生成を開始することの内の少なくとも１つを行う、請求項１に記載のシステム。
14. 前記ルールプロセッサは、取得したルールを表すデータを前記ルールリポジトリへの格納に適した構文に変形し、受け取ったメッセージ内に特定された前記イベントの発生に応答して、請求データを処理するために前記イベントに関連した前記ルールの適用を開始する、請求項１に記載のシステム。
15. 患者に対してのヘルスケアの提供に関連した請求データの処理におけるルールの使用をサポートするユーザインタフェースを提供する方法であって、
    生成されたルールを表示するウインドウ、
    生成されたルールの一部として請求データに対して行うべきテストを特定する少なくとも１つの表示要素含むウインドウ、
    前記生成されたルールによって処理すべき請求データ項目を特定する少なくとも１つの表示要素含むウインドウ、及び
    前記生成されたルールの請求データへの適用に応答して行われる結果動作を特定する少なくとも１つの表示要素含むウインドウ、
    を含む少なくとも１つの表示イメージの生成を開始するステップを含む方法。
16. 患者に対してのヘルスケアの提供に関連した請求データの処理に使用するルールを管理する方法であって、
    メッセージを受け取るステップと、
    複数の異なるソースからのルールを表すデータを取得するステップと、
    ルールリポジトリ内に取得したルールを表すデータを累積するステップと、
    前記受け取ったメッセージに応答して、前記リポジトリから取り出された選択されたルールの請求データ処理への適用を開始するステップと、
    前記選択されたルールを前記請求データへ適用することによって得られた結果を出力のために処理するステップとを含む方法。

Images