JP2005523504A - ヘルスケア関連情報に消費者がアクセスできるようにするシステム - Google Patents

Abstract

【解決手段】システムは、ヘルスケア接触関連情報へ許可された患者がアクセスできるようにするために、統合されたヘルスケア接触のサービス、請求書発行及び請求データを使用する。システムは、患者とヘルスケアエンタープライズとの間の対話等のイベントに関する情報を含む、ヘルスケア接触関連情報への患者のアクセスをサポートする。本システムは、患者識別情報及び接触関連情報に対しての要求を受け取るインタフェースプロセッサを含む。また、システムは、患者識別子を少なくとも１つの患者の接触を特定するレコード、この少なくとも１つの患者の接触に関連する少なくとも１つのヘルスケア提供者組織を特定するデータ、及び前記少なくとも１つの患者の接触に関連する接触情報を含むレコードと関連付けるデータベースを含む。データプロセッサは、患者の識別情報及び要求に応答し、患者についての接触関連情報を提供するためにデータベースにアクセスすると共に、接触関連情報を患者へ提示するための出力通信に適合するように処理する。

Description

本発明は、ヘルスケア接触（encounter ）関連情報への患者のアクセスをサポートするすると共に、患者が接触のスケジューリングを開始し、患者に関連したヘルスケア接触情報を更新できるようにするために使用するシステム及びユーザインタフェースに関する。

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

ヘルスケア請求の判定並びに関連する請求書発行及び支払い処理は多くの問題を抱えている。提示された請求却下又は拒絶の理由を患者が理解できず、またヘルスケア支払者機関に送られた請求の進捗を追跡したり監視したりするための方法が限られていることを不満に感じることがよくある。公知のシステムは、この問題に対してヘルスケアの支払者及び提供者の観点から取り組んでいる。提供者は、各請求の状態を追跡し、支払者をフォローアップする。支払者は、提供者の活動を監視し、請求の計算が支払者の現在ルールの下で正しいか否かをチェックする。請求の状態を判定したり、例えば、適格性の検証、事前証明書の要求、又は専門医への紹介などのその他の管理的及び臨床的ヘルスケア手続きの状態を判定するための限られた方法しか患者に提供されていない。この仕事に関連する問題を複雑にしているのは、単一の医療行為において、関与した各臨床医（内科医、外科医、麻酔医、物理療法医、病理医、放射線医）について複数の請求が発生し、問題の状態を判定するために、多面的ヘルスシステムの複数の異なるエンティティと接触するという負担に直面するという事実である。また、現在使用されているそのような接触を行う最も一般的な方法は、典型的には入り組んだ顧客サービス部門へ電話をかけることである。現在、患者は、請求が送られたのか、拒否されたのか、又は支払われたのか知るための現実的な方法を有していない。また、患者が不備に気付いていれば容易に提供できたであろう情報がないために送られた請求が却下されてしまうこともある。また、アクセスシステムは、確実であると共に、機密の医療データへの許可されていないアクセスを阻止しなければならない。発明の原理に従ったシステムは、これらの要求や関連する問題に対処するものである。

システムは、例えば、インターネットを介して複数の請求にわたる活動の統合したビューを提供するにあたり、事前証明書、紹介、適格性の検証、ヘルスケアサービスの利用可能性、共同支払い、免責条項、請求及び支払い状況に関するヘルスケア接触関連情報へ許可された患者がアクセスできるようにするために、統合されたヘルスケア接触のサービス、請求書発行及び請求データを使用する。システムは、患者とヘルスケアエンタープライズとの間の対話等のイベントに関する情報を含むヘルスケア接触関連情報への患者のアクセスをサポートする。本システムは、患者識別情報及び接触関連情報に対しての要求を受け取るインタフェースプロセッサを含む。また、システムは、患者識別子を少なくとも１つの患者の接触を特定するレコード、この少なくとも１つの患者の接触に関連する少なくとも１つのヘルスケア提供者組織を特定するデータ、及び前記少なくとも１つの患者の接触に関連する接触情報を含むレコードと関連付けるデータベースを含む。データプロセッサは、患者の識別情報及び要求に応答し、患者についての接触関連情報を提供するためにデータベースにアクセスすると共に、接触関連情報を患者へ提示するための出力通信に適合するように処理する。

本発明者らは、事前証明書、紹介、適格性の検証、ヘルスケアサービスの利用可能性、共同支払い、免責、請求及び支払状況に関連した情報へ、患者が効率的にアクセスすることができるシステムを提供することが望ましいと認識した。更に、こうした患者の情報へのアクセスが、都合の良い時間帯（毎日２４時間が理想的）に、且つ、都合の良い場所から行えることが望ましい。図１は、許可された患者（又は消費者）がヘルスケア接触関連情報へアクセスすることを可能にする接触データの処理システム全体を示す。ここで使われる接触（encounter）という語は、ヘルスケア企業との患者との接触を含み、これには、経済的又は取引の結果を伴うヘルスケア企業との対話を含み、例えば、患者の訪問、電話連絡、入院患者の滞在又は外来患者の処置、インタビュー、診察、手続き、治療に関連した事柄、ヘルスケアエンタープライズへの入院、検査又は薬物治療の指令などを含む。図１のシステムでは、リポジトリ６８の統合されたヘルスケア接触サービス、請求書発行、及び請求のデータは、許可された患者が事前許可、紹介、適格性の検証、ヘルスケアサービスの利用可能性、共同支払い、免責、請求、及び支払状況についてのヘルスケア接触関連情報へアクセスすることを可能にするために使われる。本システムは、例えば、複数の患者への請求にわたっての活動の統合されたビューを含む各種のフォーマットで情報を、例えば、インターネットを介して安全に患者に対して提供する。これによって患者は、ケアについてのエピソードに関するデータを追跡することができるようになり、且つ誤った請求書の発行につながる可能性があるデータを訂正する機会が与えられる。患者は、累積限度（cumulative limits）、家族及び個人の免責、所定の期間に許される訪問の回数の限度及び、所定の医療状態ごとの払い戻し限度（例えば、1年間当たり又は患者の生涯を通してしての限度）を含む、支払者機関のヘルスプラン保険の払い戻し及び治療適格性ルールにもアクセスできる。同様に、患者は、許可された薬局又はその他のサービス提供者を決め、第２の意見に対する許可を得て、紹介の要件を決め、且つ、許可された薬物治療及びカバーされない対象外のサービスを見つけることが可能である。更に、図１のシステムでは、許可されたユーザが別の個人のレコード（典型的なものとして、その個人に対して会計上の責任がある家族又はユーザ）へアクセスすることが可能になり、且つ患者が別の個人又はエンティティに権限を与えて彼の秘密情報へアクセスできるようになる。アクセスは、患者の秘密情報への無許可のアクセスを防ぐため、支払者が提供するポリシデータを基に厳しく管理される。また、図１のシステムは、ヘルスケア提供者と支払者機関との間の電子ダイアログのサポートも行ない、患者又は会計上の責任がある関係者が支払者機関及びヘルスケア提供者と直接対話して、閲覧された情報に関する問題点を伝えて、正しくない情報を訂正するよう要求することを可能にする。

接触のサービス、請求書発行、及び請求データが統合された図１システムのリポジトリ６８には、請求を伴う接触のレコードと、患者のヘルスプランの払い戻し及び適格性ルール、及び患者の医療又は病気についての送金レコードをリンクするリレーショナルデータベースを含む。本データベースは、複数の提供者及び場所を横切って、入院前検査、入院患者の滞在、外来患者のフォローアップ、請求書及び支払を含めたケアに関する複数の接触を論理的にリンクするために公知の技術を使用している。これによって、リポジトリ６８は、患者などのユーザが消費者ポータル２４を介して特定の請求、接触、患者のカバー範囲のルール又は送金レコードに関する情報へのアクセスを可能にしている。
同様に、ユーザは、請求の発行及び払い戻しに影響する請求の更新及びカバー範囲のルールの変更に関する履歴を見ることか可能である。また、リポジトリ６８は、ユーザがイベント（後述）の間の経過時間を見ると共に、ユーザが指定した期間内における複数の個人又は1以上の個人の行為を見ることも可能にしている。

本明細書で使用されるルールと言う語は、ヘルスケアの請求要素が、ヘルスプランの払い戻し条件、ヘルスプランの請求フォーマット要件、払い戻し公式、払い戻し上の制限、及び払い戻しの計算手順を含む所定の要件に従っていることを判定するための手順を含む。ルールは、フォームとデータ、又はフォームとデータとの間の関連を使って、どの様に行為を提示し、実行し、調整するかに関する所定のガイド、指針、又はモデルを含むこともできる。更に、本明細書で使用される例外という語は、問題の特定だけでなく、その問題を処理するメカニズムを含み、又、本明細書で使用される請求要素という語は、請求の一部、請求全体。請求の中のレコード、及びヘルスケアサービス提供者と個々の患者との接触に関連するレコードデータを含む。更に、請求（claim）は、サービス及び関連した変更を特定するために保険会社が使う手段であるが、支払いは期待されない。これに対して、請求書（bill）（一般に、保証人又はその他の会計上責任のある関係者宛）は、支払いを期待できる。

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

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

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

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

予備判定ユニット４８によって実行されるルールは、予測される判定結果を、指定された一組の請求データを指定された支払者宛に送信する際に決定する。ユニット４８は、ルールキーパインタフェース６６を介してリポジトリ７４（又は、ルールアクセッサ５２）から取り出したルールを使用し、指定された一組の請求データを指定された支払者宛に送信した結果を予測する。この目的のため、ユニット４８が使用するルールが、選択された特定の支払者が使用するルールを複製する。ユニット４８は、請求を指定された支払者宛に送信する前に、支払拒否になりそうな状態を特定し、こうした状態を（自動的又は手動で）直すことができるようにしておく。この手順は、リポジトリ７４から取出されるルールを使うか、遠隔地からアクセスされるルールを使って、エラーの無い請求の作成を容易に行うことができ、有利である。規制ガイドライン及び諸指示を含むルールは、継続的に取得されてリポジトリ７４に格納され、且つ、ルールキーパ６６を介してこのリポジトリ内で更新されて、保持される。システムの接続性ルールもリポジトリ７４に保持されており、関係ルールリポジトリ１８にも保持されている（インタフェース１０を介しての通信をサポートするために）。そのような接続性ルールは、ｅ-コマースコミュニケーション(例えば、特定のノード名に対しての２４００ＫボーでのＦＴＰの使用)をサポートする、又は、通信モードを決定する（例えば、問合せ又は回答を調べるためにＥメールを使うことを促す）。その他のルールは、照合済み請求データの電話番号、郵便番号、住所又は其の他地理上の識別子などを保持しているデータフィールド間の矛盾を検出する。

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

ルール取得ユニット５４は、支払者機関に請求を送る前の判定の結果に基づくルール、及び所有権のあるプログラム化されたルールセットへの外部ユーザのアクセスを提供しない支払者が提供する資料及びその他の情報を通して、ルールデータを蓄積する。また、ユニット５４は、ルール収集サービス８０によって支払者から取得した情報を基に、ルールメーカ５６が提供するユーザインタフェースを介して行われるユーザの手動データ入力及び処理に引き続いて新しいルールを受取る。ルールチェッカユニット５０は、リポジトリ７４内のルールを監視し、不完全又は不正構文を含むルールを特定し、ユーザに示す。また、ユニット５０は、相互に矛盾するルールの組合せについてもレポートする。更に、請求データをルール実行ユニット４６及び予備採決ユニット４８を使って処理する間に、所定の例外状態が特定された場合、これに応答して、例外トラッカ機能４２は、特定された例外状態の処理及びレポートを管理するためのルールのサブセットを採用する。予備判定器４８は、遠隔地にあるルールによる予備判定に請求データをかけるためにルールアクセサ５２を使用する。

図２は、許可された患者がヘルスケア接触関連情報へアクセスして、且つ、請求の送出、請求書発行、及び送金を行なうプロセスを消費者ポータル２４を介して積極的に監視することを可能にするシステム構成を示す。ヘルスケア接触関連情報への正確且つ適時なアクセスは、リポジトリ７４（図１）内の常時更新されるルール、規制ガイド、及び指示と組み合わせて、リポジトリ６８内の統合されたヘルスケア接触サービス、請求書発行、及び請求データを使って可能になる。動作時において、患者は、消費者ポータル２４を介して、インターネットと互換性のある安全なウェブベースのユーザインタフェースを提供する消費者ポータル２００上で実行するアプリケーション２０３へアクセスする。アプリケーション２０３には、ルール実行ユニット４６の機能を含め、図１の機能群が含まれる。患者は、アプリケーション２０３が提供するユーザインタフェースを採用して、リポジトリ６８内の接触関連情報にアクセスする。アプリケーション２０３は、このデータへのアクセスを、ネットワークファイアウォール及び暗号化と復号化のアルゴリズムを含むセキュリティシステムを採用して制御する。アプリケーション２０３は、安全な情報へのアクセスを特定するＨＩＰＡＡ（Health Insurance Portability & Accountability Act of August 21 1996）準拠の監査トレイルの維持も行う。アプリケーション２０３は、ポータル２４を介しての情報の要求に応答してその要求を解釈し、構造化リレーショナルデータベースの論理レコードの連携機能を使ってその情報へアクセスし、所望の接触情報を得る。別の実施形態では、論理連携及びマッピング情報をサーバ２００に常駐させておき、これをアプリケーション２０３が使ってリポジトリ６８内の情報へアクセスすることができる。データベース６８の論理的なリンク構造では、複数の提供者と場所を横切って、入院前検査、入院患者の滞在、外来患者のフォローアップ、請求及び支払を含めたケアに関する複数の接触が論理的にリンクされる。

リポジトリ６８内のリンク済の情報は、患者が、入院、請求の発生、支払送金、及び追加情報の要求を含めたイベントの進捗を監視できるようにするため、接触情報と取引データとの関連付けをも行う。情報の記憶コスト及び起こりえる記憶の冗長性を減らすため、支払者６０及び提供者６１のデータベースなど外部データベースへの論理リンクが使われる。リポジトリ６８は、ポータル２４を介してユーザに提示するため、病院、クリニック、及び医者のシステムのデータを含めた複数のヘルスケア提供者のフィナンシャルアプリケーションからの非冗長データの蓄積も行う（この目的のため、図１に関連して説明したように通信リンクが確立されている）。しかしながら、このデータは複数の場所に常駐しているが、リポジトリ６８と連動して動作するアプリケーション２０３によって、論理的に接続され、その患者に１つのビューで提示される。別の実施形態では、付加的な記憶装置を設けることにより、所要データは中央のリポジトリに維持される。リポジトリ６８への更新は、ＨＩＰＡＡによて義務付けられているＡＮＳＩ（米国規格協会）Ｘ-１２と互換性のある取引を含めた各種の入力処理を通して発生する。更新は、例えば、Ｘ-１２と互換のある２７０（適格性の要求）、２７１（適格性の回答）、２７８（許可）、８７３（請求）、及び８３５（送金）取引に応答して発生する。又、オンラインの更新は、例えば、患者から他の者へ取引レコードが送られることに応答して連続的に発生する。これらの更新によって、その患者又は責任のある関係者が現在の情報を利用できることが保証される。

患者は、アプリケーション２０３を使って、病気の合計コストを算定し、又、病気のエピソードに対する請求及び送金レコード及びその他の請求書発行データへアクセスすることができるので有利である。更に、患者又は会計上責任のある関係者は（ポータル２３を介して）、家族のデータを合成したビュー又は個別のビューを構成することができ、又、接触に関した活動が必要とされるタイムフレームを選択することもできる。患者は、更に、消費者ポータルアクセスシステムに加入している支払者と提供者のリストを見て、情報への簡単なアクセスをサポートするヘルスケアベンダ又は提供者を容易に選択できる。患者は、消費者ポータル２４及びアプリケーション２０３を使い、特定のサービスを受けるため、ヘルスケア施設への訪問のスケジュールを決める。アプリケーション２０３は、これに応えて、関連するヘルスケア施設が患者から保険の情報を収集したか否かを特定し、医療必要性、紹介、及び適格性の検証処理を自動的に開始する。その上、アプリケーション２０３は、請求及び関連データへの何らかの変更をその患者に自動的に知らせるために、患者又は責任のある関係者へ請求の更新情報を、望むならばＥメールを介して、自動的に要求する。

図３は、図１及び図２のシステムによって、許可された患者にヘルスケア接触関連情報へのアクセスを提供するために採用される処理のフローチャートを示す。ステップ３０３では、ステップ３００でのスタート後、アプリケーション２０３（図２）は、患者識別情報及び接触関連情報の要求を受取る。接触関連情報には、例えば、請求に関するデータ、取引に関するデータ、患者の病院への入院を特定するデータ、支払に関するデータ、情報の要求を表すデータ、医療手続きの許可を特定するデータ、接触に関連した臨床データ又は払い戻しの拒否又は受入に関連したデータが含まれる。アプリケーション２０３は、ステップ３０７で、リポジトリ６８（図２）を含む複数のデータベースにアクセスして、患者の接触関連情報を得る。これらの複数のデータベースには、例えば、病院、クリニック、医者又は支払者のデータベースが含まれる。リポジトリ６８は、患者の識別子を、その患者の接触を特定するレコード、及び患者の接触に関連する少なくとも１つのヘルスケア提供者機関を特定するデータ、並びにその患者の接触に関連した情報を含むレコードにリンクする。リポジトリ６８（又は別の実施形態でのアプリケーション２０３）は、離れた場所にある利用可能なデータベースのマップ及び離れた場所にある利用可能なデータベースとの双方向通信を可能にする関連した通信データを保持している。ステップ３０９で、アプリケーション２０３は、取得した接触関連情報を照合して、請求、接触、保険ヘルスプランの適格性ルール、支払のレコード、請求の履歴、ユーザが指定した期間に亘る接触関連情報又はユーザが選択したイベント間の接触関連情報に関する補助的なヘルスケア情報を提供する。また、アプリケーション２０３は、取得済の情報を処理して、照合済の接触関連情報を提供する。この照合済の接触関連情報は、患者の識別子を、複数の接触を特定する少なくとも１つのレコード、複数のヘルスケア提供者機関を特定するデータ、患者へのヘルスケアの提供に関与した複数のヘルスケア提供者機関の関連するロケーションを特定するデータ、複数の患者の接触に関する情報を含む少なくとも１つのレコード、患者の医療状態の治療に関連する複数の接触の総コスト、及び患者に適用可能な支払者のヘルスプランの下での治療の適格性についての情報に関連付ける。

アプリケーション２０３は、ステップ３１１で、患者識別情報と要求に応答して、照合済の接触関連情報を処理して患者への提示に適したものとし、処理した情報を、１つのレコード、１つの表示イメージ、スクロール可能表示イメージ、又は合成したマルチウインドウ表示イメージとして示す表示イメージの生成を開始する。アプリケーション２０３は、更に、患者の要求に対応して、処理済の接触関連情報を含む印刷可能なレポートの作成を開始する。ステップ３１５で、アプリケーション２０３は、ヘルスケア提供者機関を訪問するスケジュールを決めるための患者の指令を受取る。アプリケーション２０３は、この指令に応答して、ステップ３１７で、医療必要性の検証を自動的に開始して、スケジュールの決った訪問が患者のヘルスケア保険プランによってカバーされるかどうかを判断する。アプリケーション２０３は、スケジュールされた訪問及びヘルスケア保険プランの適格性の検証をサポートするために、患者の医者による紹介の要求を自動的に開始し、スケジュールされた訪問が患者のヘルスケア保険プランでカバーされていることを検証する。その上、アプリケーション２０３は、ステップ３１９で、訪問のスケジュールを記録するためにリポジトリ６８を更新し、訪問のスケジュールを示すリポジトリ６８内のその患者の診断記録への更新の特定に応答して、接触関連情報を患者に自動的に送信する。アプリケーション２０３は、ステップ３２１で、患者が医療レコードへアクセスしたことを特定する際に使用するＨＩＰＡＡに準拠した監査トレイルを保守する。図３の処理はステップ３２３で終了する。

図４は、ポータル２４を介して特定の患者（患者はアイテム４２０によって特定されている）がアクセスできる請求発行レコードを表示したユーザインタフェース表示イメージ示す。この請求発行レコードは、怪我の治療に関する、ヘルスケア提供者との複数の患者の接触４０２、４０４、及び４０６に対する照合済の請求データを含む。図５は、患者に生じた臨床イベントに関する例示的な請求データ処理ルールを示す。患者は、これらのルールを適用した結果として生じる請求活動をポータル２４を介して監視できる。図５のルール５０１〜５１３は、起動イベントに応答して、患者に対するサービスの提供についての請求データを自動的に検証すると共に訂正するために、図２のアプリケーション２０３においてユニット４６（図１）によって採用される。請求データは、患者に与えたサービスについての予想される払戻しをサービス毎に計算することで処理される。サービスについての料金のレコードが患者請求書発行レコードに組み込まれたことに応答して、適用可能な有効なヘルスケア保険ポリシーについてそれらの優先順位で予想される払戻しが計算される。ユニット４６は、請求データが支払者の要件に適合していることを検証するためにルール５０１〜５１３及びその他のルールを実行する。ユニット４６は、これを個々のサービス料金（それらが患者請求発行レコードに蓄積される時）及び複数のサービス及び関連する料金をカバーする請求全体の両方について行う。

図６は、提案された手続きを受けるためにヘルスケア提供者を訪問することをスケジューリングする際に患者を助けると共に、提案された手続きが支払者の医療必要性（medical necessity ）要件を満たしているか否かをチェックすることを含むプロセスのフローチャートを示す。このプロセスは、ユニット４６及び図１の他の処理機能を含むアプリケーション２０３によって実行される。有利なことに、手続きを受けるための訪問のスケジュールを決める患者の要求の受け取りにより、アプリケーション２０３による医療必要性の判定が自動的に起動される。図６において、ステップ５５０で開始されると共に、ステップ５５１で手続きを受けるための訪問のスケジュールを決める患者の要求の受け取った後、アプリケーション２０３は、ステップ５５３において、訪問を支援するために専門医への紹介の許可を得るために患者の医者に要求を送る。また、アプリケーション２０３は、訪問をスケジュールするための患者の要求に応答してステップ５５５でルールを実行し、スケジュールされた手続きが、特定の支払者組織の医療必要性要件を満たしていることを検証する。アプリケーション２０３は、患者（及び患者の医者）に対して、関連する手続きについての医療必要性が検証されたことをステップ５５７で知らせるか、或いは医療必要性の検証が失敗に終わったことをステップ５５９で知らせる。ステップ５５９で失敗した場合、アプリケーション２０３はステップ５６０において、患者に対してプロンプトを発生し、患者が訪問（及び関連する手続き）及び可能性のある代替案に関しての患者の医者との話し合いをスケジュールできるようにする。図６のプロセスはステップ５６５で終わる。

図７は、提案された手続きを受けるためにヘルスケア提供者を訪問することをスケジューリングする際に患者を助けると共に、提案された手続きが患者のヘルスケアプランでカバーされるか否かを判定することを含む別のプロセスのフローチャートを示す。即ち、有利なことに、訪問のスケジュールを決めるための患者の要求に応答して、アプリケーション２０３は、患者の医療保険プランの下で、患者が訪問又は手続きに対して払戻しを受ける資格があることを自動的に検証する。図７において、ステップ６００で開始されると共に、ステップ６０３で手続きを受けるための訪問のスケジュールを決める患者の要求の受け取った後、アプリケーション２０３は、スケジュールされた訪問又は手続きが患者の医療保険プランの下で支払を受けることできるかを検証する。アプリケーション２０３は、患者（及び患者の医者）に対して、訪問又は手続きが保険によってカバーされることが検証されたことをステップ６０９で知らせるか、或いは訪問又は手続きが保険によってカバーされないことをステップ６１１で知らせる。契約条件に基づき患者がサービスについての払い戻しを受ける資格がないとされた場合、アプリケーション２０３はステップ６１５において、患者に対してプロンプトを発生し、手続きの保険によるカバー、及び患者のヘルスプランの下で払い戻しを受けることができる可能性のある代替治療についての患者の医者との話し合いをスケジュールできるようにする。アプリケーション２０３は、支払者を特定する事前に収集された患者保険情報を、格納された支払者住所情報と共に使用し、特定された支払者に対して適格性要求を送る。個々のヘルスケア提供者は、回答を促進するために更なるアクション（例えば、ワークリストの入力、電子メールの送信など）を開始する前に、適格性の回答を待つ期間の長さに関するルールを決定する。ステップ６１１でカバーされないと判断された場合、医者はステップ６１５においてカバーされない手続きが好ましい治療であると判定することもある。図７のプロセスはステップ６２０で終わる。

図８は、ポータル２４を介して患者がアクセスした照合済みの接触関連情報を示す。患者は、病気の一以上の症状について、サービス及び手続き並びに関連するコスト６３５に関連する情報を得るために情報要求を構成できる。図８の例は、単一の病院（ＨＤＸメモリアル（アイテム６３０））による患者の医療状態の治療のために施される手続き６４０、６４３、６４５、６４７、６４９などの手続きを示している。しかし、患者は、複数の病院又はその他のヘルスケア提供者によって提供される一種以上のケアについての情報を得るために、例えば、ポップメニューにより情報要求を構成することもできる。

ポータル２４を介して患者に提供される統合されたヘルスケア接触のサービス、請求書発行及び請求データは、必要に応じて、データリポジトリ６８又はその他の遠隔地のデータベースから取り出される。図９〜図１５は、許可された患者がアクセスできる、中央データリポジトリ６８に組込まれたヘルスケア接触関連情報を示す。即ち、図９は部分的患者レコードデータ構造の一部を示し。図１０は医療レコードデータ構造を示し、図１１は支払者レコードデータ構造の一部を示す。料金レコードデータ構造及び発生コードデータ構造は、図１２及び図１３にそれぞれ示され、図１４及び図１５は、スパンコード及び医療状態コードデータ構造をそれぞれ示す。スパンコードは、所定の期間に亘って行われる臨床又はその他のイベントについての他の発生コードである。これらのレコード構造は例に過ぎず、リポジトリ６８は、通常、例えば救急サービス、リハビリサービス、治療及びその他サービス及び活動などの請求データに関連した他の種類のレコードを含む。
図９〜図１５のレコード構造は、夫々、リポジトリ６８内で、請求パケット識別子（８００、９００、９２０、９４０、９６０，９８０、８３０）、セクション識別子（８０２、９０２、９２２、９４２、９６２、９８２、８３２）、及びシーケンス番号（８０４、９０４、９２４、９４４、９６４、９８４、８３４）を使ってアクセス可能である。

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

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

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

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

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

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

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

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

図１〜１５に示すシステム、プロセス及びユーザインタフェース表示フォーマットは、限定的なものではない。同じ目的を達成するために、本発明の原理に従って他のシステム、プロセス及びユーザインタフェースフォームを作り出すこともできる。本発明の原理は、他の業界において関心のある情報への消費者の確実なアクセスを提供するのに適用可能であり、特に、保険、政府及びヘルスケア業界に適用可能である。

本発明の原理に従った、許可された患者がヘルスケア接触関連情報にアクセスすることを可能にする接触データ処理システム全体を示す。 本発明の原理に従った、許可された患者がヘルスケア接触関連情報へアクセスすることを可能にするシステム構成を示す。 本発明の原理に従った、図１及び図２のシステムによって、ヘルスケア接触関連情報へのアクセスを許可された患者に提供する際に採用されるプロセスのフローチャートを示す。 本発明の原理に従った、怪我の治療に関するヘルスケア提供者と患者との複数の接触についての患者の請求発行レコードを表示するユーザインタフェース表示イメージを示す。 本発明の原理に従った、患者に発生した臨床イベントに関連する例示的な請求データ処理ルールを示す。 本発明の原理に従った、提案された手続きを受けるためにヘルスケア提供者を訪問することをスケジューリングする際に患者を助けると共に、提案された手続きが支払者の医療必要性要件を満たしているか否かをチェックすることを含むプロセスのフローチャートを示す。 本発明の原理に従った、提案された手続きを受けるためにヘルスケア提供者を訪問することをスケジューリングする際に患者を助けると共に、提案された手続きが患者のヘルスケアプランでカバーされるか否かを判定することを含むプロセスのフローチャートを示す。 本発明の原理に従った、患者がアクセスした照合済み接触関連情報を示す。 本発明の原理に従った、許可された患者によってアクセス可能なヘルスケア接触関連情報レコードを示す。 本発明の原理に従った、許可された患者によってアクセス可能なヘルスケア接触関連情報レコードを示す。 本発明の原理に従った、許可された患者によってアクセス可能なヘルスケア接触関連情報レコードを示す。 本発明の原理に従った、許可された患者によってアクセス可能なヘルスケア接触関連情報レコードを示す。 本発明の原理に従った、許可された患者によってアクセス可能なヘルスケア接触関連情報レコードを示す。 本発明の原理に従った、許可された患者によってアクセス可能なヘルスケア接触関連情報レコードを示す。 本発明の原理に従った、許可された患者によってアクセス可能なヘルスケア接触関連情報レコードを示す。

Claims (15)

1. 患者とヘルスケアエンタープライズとの間の対話等のイベントに関する情報を含むヘルスケア接触関連情報への患者のアクセスをサポートするシステムであって、
   患者識別情報及び接触関連情報に対しての要求を受け取るインタフェースプロセッサと、
   患者識別子を、少なくとも１つの患者の接触を特定するレコード、前記少なくとも１つの患者の接触に関連する少なくとも１つのヘルスケア提供者組織を特定するデータ、及び前記少なくとも１つの患者の接触に関連する接触情報を含むレコードと関連付けるデータベースと、
   前記患者識別情報及び前記要求に応答し、患者についての接触関連情報を提供するために前記データベースにアクセスすると共に、前記接触関連情報を前記患者へ提示するための出力通信に適合するように処理するデータプロセッサとを含むシステム。
2. 前記インタフェースプロセッサは、ヘルスケア提供者組織への訪問をスケジュールするための患者の指令を受け取り、
   この指令に応答して、前記データプロセッサは、（ａ）前記スケジュールされた訪問が患者のヘルスケア保険プランでカバーされていることを判断する医療必要性検証、（ｂ）前記スケジュールされた訪問をサポートするための患者の医者による紹介の要求、及び（ｃ）前記スケジュールされた訪問が前記患者のヘルスケア保険プランでカバーされていることを検証するヘルスケア保険プラン適格性検証の内の少なくとも１つを自動的に開始し、
   前記データプロセッサは、前記予定された訪問のスケジュールを記録するために前記データベースを更新する、請求項１に記載のシステム。
3. 前記システムは、前記患者識別情報及び前記要求に応答して前記患者についての要求された接触関連情報を得るために遠隔データベースと通信する通信プロセッサを含み、前記システムは、利用可能な遠隔データベースのマップと関連する通信データとを含み、前記通信プロセッサが利用可能な遠隔データベースとの双方向通信を確立できるようにする、請求項１に記載のシステム。
4. 前記接触は、患者のヘルスケアエンタープライズとの対話などのイベントであり、（ａ）訪問、（ｂ）電話、（ｃ）インタビュー、（ｄ）診察、（ｅ）手続き、（ｆ）治療に関連したできごと、（ｇ）ヘルスケアエンタープライズへの入院、（ｈ）検査、及び（ｉ）薬物治療の指令の内の少なくとも１つを含む、請求項１に記載のシステム。
5. 前記システムは、前記接触関連情報に対する更新が特定されたことに応答して、自動的に接触関連情報を前記患者に送る通信プロセッサを含む、請求項１に記載のシステム。
6. 前記接触関連情報は、（ａ）請求関連データ、（ｂ）取引き関連データ、（ｃ）患者の入院を特定するデータ、（ｄ）支払い関連データ、（ｅ）情報要求を表すデータ、（ｆ）医療手続き許可を特定するデータ、（ｇ）接触に関連した臨床データ、及び（ｈ）払戻し拒否又は受け入れに関連するデータの内の少なくとも１つを含む、請求項１に記載のシステム。
7. 前記システムは、患者の訪問についての医療コストの少なくとも一部をヘルスケア提供者に払う責任のある支払者機関などの保証人がヘルスケア接触関連情報にアクセスするのをサポートし、
   前記データプロセッサは、保証人識別情報及び前記保証人からの接触関連情報の要求に応答して、患者についての接触関連情報を提供するために前記データベースにアクセスすると共に、前記接触関連情報を処理して前記保証人へ提示するための出力通信に適合させる、請求項１に記載のシステム。
8. 前記データプロセッサは、ユーザが患者のレコード情報をアクセスしたことを特定するのに使用するための監査トレイルを維持している、請求項１に記載のシステム。
9. 前記接触関連情報は、患者識別子を、（ａ）複数の接触を特定する少なくとも１つのレコード、（ｂ）複数のヘルスケア提供者組織を特定するデータ、（ｃ）前記患者にヘルスケアを提供することに関与したヘルスケア提供者組織の複数の関連するロケーションを特定するデータ、（ｄ）複数の患者接触に関連した接触情報を含む少なくとも１つのレコード、（ｅ）患者の医療状態の治療に関連する複数の接触の総コスト、及び（ｆ）前記患者に適用可能な支払者のヘルスプランの下での治療適格性情報の内の少なくとも１つと関連付けている、請求項１に記載のシステム。
10. 前記データベースは、（ａ）病院、（ｂ）クリニック、（ｃ）医者、（ｄ）支払者、（ｅ）薬局、（ｆ）長期介護施設、（ｇ）高度看護設備、（ｈ）救急車、及び（ｉ）耐久性のある医療器具の内の少なくとも１つについての接触関連情報を含むデータベースである、請求項１に記載のシステム。
11. （ａ）ある者による前記患者のレコードのアクセスを、前記患者のレコードをアクセスすることを前記の者に許可する許可情報を前記患者から受け取ったことに応答して許可すること、及び（ｂ）前記患者によって提供されたヘルスケア保険ポリシー情報を受け取ったことに応答して前記患者に関連する個人のレコードにアクセスすることを許可することの内の少なくとも一方を行う許可プロセッサを含み、前記許可プロセッサは、支払者機関の従業員による前記患者に関連する個人のレコードへのアクセスを許可する、請求項１に記載のシステム。
12. 前記データプロセッサは、
    前記患者についての要求された接触関連情報を得ると共に、
    前記受け取った患者識別情報と、（ａ）前記取得済みの接触関連情報を訂正すること、及び（ｂ）前記取得済みの接触関連情報を補充することの内の少なくとも一方に対する前記要求とに応答して、前記取得済みの接触関連情報に関して、支払者機関及びヘルスケア提供者とのユーザの通信をサポートする、請求項１に記載のシステム。
13. 患者とヘルスケアエンタープライズとの間の対話等のイベントに関する情報を含むヘルスケア接触関連情報への患者のアクセスをサポートするシステムであって、
    患者識別情報及びヘルスケア提供者組織への訪問のスケジュールを決めるための患者の指令を受け取るインタフェースプロセッサと、
    前記患者についての医療レコードを含むデータベースと、
    （ａ）前記スケジュールされた訪問が患者のヘルスケア保険プランでカバーされていることを判断する医療必要性検証、（ｂ）前記スケジュールされた訪問をサポートするための患者の医者による紹介の要求、及び（ｃ）前記スケジュールされた訪問が前記患者のヘルスケア保険プランでカバーされていることを検証するヘルスケア保険プラン適格性検証の内の少なくとも１つを自動的に開始し、前記訪問のスケジュールを示すために前記データベース内の前記医療レコードを更新するデータプロセッサとを含むシステム。
14. 患者とヘルスケアエンタープライズとの間の対話等のイベントに関する情報を含むヘルスケア接触関連情報への患者のアクセスをサポートするユーザインタフェースシステムであって、
    患者識別情報及び接触関連情報に対しての要求を受け取るステップと、
    患者についての接触関連情報を提供するためにデータベースにアクセスするステップと、
    前記患者識別情報及び前記要求に応答して、前記接触関連情報を前記患者への提示に適合するように処理するステップとを含み、
    前記データベースは、患者識別子を、少なくとも１つの患者の接触を特定するレコード、前記少なくとも１つの患者の接触に関連する少なくとも１つのヘルスケア提供者組織を特定するデータ、及び前記少なくとも１つの患者の接触に関連する接触情報を含むレコードと関連付けるユーザインタフェースシステム。
15. 患者とヘルスケアエンタープライズとの間の対話等のイベントに関する情報を含むヘルスケア接触関連情報への患者のアクセスを可能にする方法であって、
    患者識別情報及びヘルスケア提供者組織への訪問のスケジュールを決めるための患者の指令を受け取るステップと、
    前記患者の指令に応答して、
    （ａ）前記スケジュールされた訪問が患者のヘルスケア保険プランでカバーされていることを判断する医療必要性検証、（ｂ）前記スケジュールされた訪問をサポートするためための患者の医者による紹介の要求、及び（ｃ）前記スケジュールされた訪問が前記患者のヘルスケア保険プランでカバーされていることを検証するヘルスケア保険プラン適格性検証の内の少なくとも１つを自動的に開始するステップと、
    前記訪問のスケジュールを示すためにデータベース内の前記患者の医療レコードを更新するステップとを含む方法。

Images