JP2004005588A - 患者のヘルスケアに関連する財務データおよび請求書データを処理するシステムならびに患者ヘルスケアに関連する財務データを処理する方法 - Google Patents

Abstract

【課題】患者ヘルスケアエンカウンタ中に早期に正確な請求書データを作成して迅速な請求書データ確認とエディットを支援し、支払側に請求書を提示する前に請求書を正確なものとする。
【解決手段】患者に係わるヘルスケアデータにおけるイベントおよび関連する変更を識別するメッセージを受け取るインタフェースプロセッサと、患者に対する個々のサービス提供についての償還に関連する特性を決定するためのルールソースが設けられている。ルールプロセッサはイベント識別メッセージに応答して、患者に対する個々のサービス提供に係わる財務データを処理するためルールソースから導出されたルールの適用を開始する。結果プロセッサは財務データを処理するためルールの適用により導出された結果に応答してアクションを起こす。さらにルールプロセッサは財務データがルールに従っていることも確認する。
【選択図】　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、臨床イベントに応答して患者のヘルスケアに関連する財務データを処理するシステム、患者ヘルスケアに関連する請求書データを処理するシステム、ならびに患者ヘルスケアに関連する財務データを処理する方法に関する。
【０００２】
【従来の技術】
（病院、診療所または医師などのような）ヘルスケアプロバイダ（ｈｅａｌｔｈｃａｒｅｐｒｏｖｉｄｅｒ）によって実施される重要な機能は、ヘルスケア支払機関へ請求書を送付して患者に対するサービス提供について償還（ｒｅｉｍｂｕｒｓｅｍｅｎｔ）してもらうことである。これらの請求書は電子フォーマットであってもよいし紙のフォーマットであってもよい。紙の請求書は典型的にはデータ入力プロセスを通過し、これによってそれらの請求書は電子フォーマットに変換される。入力された電子請求書は通常、記憶されインデックスが作成されて保管される。各請求書は支払機関裁定システム（ｐａｙｅｒ　ｉｎｓｔｉｔｕｔｉｏｎ　ａｄｊｕｄｉｃａｔｉｏｎ　ｓｙｓｔｅｍ）で処理される。支払機関裁定システムは請求書データを分析して、その請求書を完全に支払うべきか一部分支払うべきかあるいは拒否すべきかを判定する。この裁定プロセスは完全に自動化することもできるし、部分的に自動化することもできるし、あるいは手動であってもよい。請求書の裁定結果には被保険者とヘルスケアプロバイダに対する小切手と給付説明（ｅｘｐｌａｎａｔｉｏｎ　ｏｆ　ｂｅｎｅｆｉｔｓＥＯＢ）の発行、あるいは付加情報送信要求を含めることができる。請求書の再調査プロセスは手間がかかるし誤りが生じがちである。
【０００３】
公知の裁定システムによれば、支払側およびプロバイダに対し請求書の支払や医療症例管理プロセスの合理化が支援される。支払機関で採用している典型的な裁定システムは、紙の請求書を電子データに変換するために高速スキャニング機器と光学文字認識ソフトウェアを使用することができる。電子請求書データは、矛盾について請求書データを分析するためにルールベースのソフトウェアによって処理される。ヘルスケアプロバイダは、ソフトウェアアプリケーションに支払規則を埋め込むことにより、あるいは支払側へ提示する前に請求書データを評価するため「請求書スクラビング（ｃｌａｉｍ　ｓｃｒｕｂｂｉｎｇ）」アプリケーションを利用することにより、請求書が必ず正確となるよう全力を尽くし、その後、支払側に請求書を送付する。また、公知のシステムはそれぞればらばらな見方で請求書データ処理に取り組んでおり、たとえばあるソフトウェアベンダシステムはオンライン資格と電子送金を扱っているし、別のベンダシステムは医師の見方から収入管理を扱っている。さらに別のベンダシステムは請求書エディットを支援しているが、これはもっぱら請求書が作られた後のみである。さらに公知のシステムは、請求書が作られるとユーザがかなり介入しなければならない。
【０００４】
【発明が解決しようとする課題】
公知のシステムは、支払側とプロバイダと患者側の見方を合わせて請求書を処理し管理しようとしていない。従来の解決手段はばらばらな見方で問題に取り組もうとしており、ヘルスケアプロバイダの環境における臨床イベントや臨床情報システムとのダイナミックな相互作用に欠けている。典型的にはあるベンダシステムは自動化された有資格性を取り扱っており、別のベンダシステムはたとえば電子支払を取り扱っており、全般的な結果として非効率になるし財務システムと臨床システムの相互作用の欠落により誤りが生じてしまう。その結果、請求書において支払側の受け取りに対するエディットプロセスがうまくいかなくなり、したがって支払側により却下されてしまう。請求書が却下されることで支払が遅れ、ヘルスケアプロバイダの資金繰りやこのプロセスによる患者の満足度に悪影響が及ぼされる。
【０００５】
【課題を解決するための手段】
本発明によればこの課題は、患者に関するヘルスケアデータにおけるイベントおよび関連する変更を識別するメッセージを受け取るためのインタフェースプロセッサと、患者に対する個々のサービス提供に関する償還に関連する特性を決定するルールソースと、前記イベント識別メッセージの受け取りに応じて患者に対する個々のサービス提供に関する財務データを処理するため前記ルールソースから導出されたルールの適用を開始するルールプロセッサと、前記財務データを処理するため前記ルールの適用により導出された結果に応答してアクションを起こす結果プロセッサが設けられていることを特徴とする、患者のヘルスケアに関連する財務データを処理するシステムにより解決される。
【０００６】
さらに上記の課題は、患者に係わる相応の請求書データ要素に関連する臨床イベントを識別するメッセージを受け取るインタフェースプロセッサと、患者に対する個々のサービス提供に係わる請求書データ要素を確認するルールソースと、前記イベント識別メッセージの受け取りに応答して請求書データ要素が不完全であることを識別するため前記ルールーソースから導出されたルールの適用を開始するルールプロセッサと、種々の請求書データ要素を個々に確認するため前記ルールの適用により得られた結果に応答してアクションを起こす結果プロセッサが設けられていることを特徴とする、患者ヘルスケアに関連する請求書データを処理するシステムにより解決される。
【０００７】
さらに上記の課題は、患者に係わるヘルスケアデータにおけるイベントおよび関連する変更を識別するメッセージを受け取り、該イベント識別メッセージの受け取りに応答して、患者に対する個々のサービス提供に係わる財務データを処理するためルールソースから導出されたルールの適用を開始し、該ルールを患者に対する個々のサービス提供についての償還に関連する特性の決定に使用し、前記財務データを処理するため前記ルールの適用により得られた結果に応答してアクションを起こすことを特徴とする、患者ヘルスケアに関連する財務データを処理する方法により解決される。
【０００８】
【発明の実施の形態】
本発明のシステムによれば、臨床データと財務データの処理オペレーションの相互作用が改善され、これによってヘルスケア支払機関への請求書提示よりも前に請求書の正確さが得られるようになる。
【０００９】
ヘルスケアプロバイダにより用いられる患者請求書データ処理システムは、臨床イベントに応答しそれを開始させ、患者のヘルスケアエンカウンタ期間中、正確な請求書データを早期に得ることができ、これによって迅速な請求書データ確認と個々の請求書要素と完全な請求書の双方に対するエディットとが支援されて、支払側への請求書提示前の請求書の正確さが改善される。システムによって、臨床イベントおよび臨床サービスに応答して患者に対するヘルスケア提供に関連する財務データが処理される。このシステムには、患者に関係するヘルスケアデータにおけるイベントおよび関連する変化を識別するメッセージを受け取るインタフェースプロセッサが含まれており、さらに患者への個々のサービス提供に対する償還に関連づけられた特性を決定するためのルールソースも含まれている。ルールプロセッサはルールソースから導出したルールの適用を開始し、これによってイベント識別メッセージの受け取りに応答して患者に対する個々のサービスの提供に関する財務データを処理する。結果プロセッサはルール適用により導出された結果に応答してアクションを起こし、財務データを処理する。本発明の１つの特徴によればルールプロセッサは財務データがルールに従っていることも確認する。
【００１０】
【実施例】
図１には請求書処理システム全体が描かれており、患者ヘルスケアエンカウンタ（ｈｅａｌｔｈｃａｒｅ　ｅｎｃｏｕｎｔｅｒ）期間中、臨床イベントに応答しそれを開始させ、支払機関または他のエンティティに請求書を提示する前の請求書の正確さを改善する。図１のシステムの場合、レポジトリ７４において継続的に更新される中央制御された共通ルールが使用されており、これによって個々のヘルスケアプロバイダも個々のヘルスケア支払機関も最も最新のバージョンのルールで作業できるようになる。中央制御されたルールを使用することで、ヘルスケアプロバイダはルールの最新の規定に従うことができるようになる。ここで使用されるルールにはヘルスケア請求書の要素が所定の要求に従っていることを判定する手順が含まれており、そのような要求にはヘルスプラン償還条件、ヘルスプランフォーマット要求、償還方式、償還制約、償還計算手順が含まれている。規定されたガイド、指針、あるいはフォームとデータまたはそれらの関係を使用してどのようにしてアクションを与え管理しまたは調整するのかについてのモデルも、ルールに含めることができる。さらにここで使用される例外には、発行の識別およびその発行を処理するメカニズムも含まれている。
【００１１】
図１のシステムは患者ヘルスケアエンカウンタ期間中に臨床イベントに応答してそれを開始し、それによって早期に適切な時点で正確な請求書データが得られるようにする。ルール実行ユニットは、多様な機能を実行するため臨床イベントおよび他のイベントに応答する。ルールによって権限、データ内容、契約条件、情報充足要求およびフォーマット要求に従っていることならびに通信コネクティビティの処理に対する決定、それらへの作用、あるいは管理が行われる。このシステムによって解消または低減されることは有利には、資格拒否の再調査と支払拒否の調査とエラーレポートのチェックと請求書郵送におけるマニュアル処理やマニュアルの支払仕訳であり、さらにこのシステムによって正確な請求書生成と提示と償還が促進される。
【００１２】
図１のシステムによって自動化されるのは事前登録、資格、登録権限、請求書生成、仮裁定、請求書提示、支払送金、ヘルスケア請求書データ処理期間の送金後プロセスであり、これによってシームレスで正確かつ迅速な処理が提供される。さらにこのシステムによって雇用側と支払側のアクティビティのコーディネートが自動化され、また、入会者データの事前検閲を正確なものとすることができる。この場合、患者がコンシューマポータル２４を使用して訪問の予定を入れたり、あるいはヘルスケア施設が患者から保険情報を収集したりするとき、医療の必要性、委託ならびに資格照合処理が自動的に開始される。正確さについて請求書が評価され、ルール実行ファンクション４６と裁定ユニット４８によってエディットされ、その際にルールレポジトリ７４内の適用可能なルールが使用され、その後、請求書が仕上げられ（つまりたとえばその請求書に対する個々のヘルスケアエンカウンタ分担のための個々の請求書要素）、さらにその後、仕上げられた請求書が支払側に提示される。図１のシステムにおける種々のポータル２０〜２８はインタフェース１０によってコントロールおよび管理され、これによって患者、支払側、プロバイダ、雇用側および政府機関に対する請求書データアクセスが提供される。このシステムによればヘルスケアプロバイダは、自動化されたルールベースのエディットおよび再調査システムの使用により政府および支払側のルールに容易に従うことができるようになる。
【００１３】
図１のシステムは、請求書データ処理用にソフトウェアアプリケーションおよび実行可能なプロシージャとしてインプリメントされたファンクションを有している。これらのファンクションを１つまたは複数のコンピュータシステムおよびサーバに格納してハードウェアまたはハードウェアとソフトウェア双方の組み合わせとしてインプリメントすることもでき、内部と外部の通信のために１つまたは複数の通信ネットワークをもたせることができる。このシステムは患者に対するヘルスケアの提供に関する請求書データを処理し、支払側に提示するための固有の患者に対する請求書に関するデータが照合される。照合された請求書データは、照合された請求書データが支払発生を開始させる処理のために満足な状態であることを確認するため、ルールを用いて予備処理のために投入される。確認がうまくいったならば照合された請求書データは支払側に提出される。請求書データはデータレポジトリ６８に記憶するためインタフェース１０を介してデータ取得ユニット３２により照合される。レポジトリ６８には、目下進行中のヘルスケアエンカウンタに関する財務データおよび臨床データが含まれている。データ取得ユニット３２は要求されたデータも要求されていないデータも種々異なるソースから受け取ることができ、それらのソースからのデータをインタフェース１０を介して要求することができる。種々のソースには図１のシステムに加入して使用する外部のユーザ（参加者）が含まれており、たとえばヘルスケアプロバイダ、ヘルスケア支払機関（たとえば保険会社、健康管理団体　Ｈｅａｌｔｈ　Ｍａｉｎｔｅｎａｎｃｅ　Ｏｒｇａｎｉｚａｔｉｏｎｓ　ＨＭＯなど）、消費者、雇用側および政府機関を挙げることができる。
【００１４】
データキーパユニット６４はゲートウェイとして動作し、さらにこのユニットはヘルスケアデータレポジトリ６８に対するデータ記憶と検索を管理するデータ管理システムとして動作し、レポジトリ６８を使用するリクエストを処理してデータを記憶、修正および検索する。データレポジトリ６８と他のシステムコンポーネントとの間にデータキーパ６４を配置することで、データキーパ６４以外システムの他の部分に影響を与えずにデータレポジトリ６８のデザインを変更することができる。データキーパユニット６４は時刻およびデータならびに行われた変更の種類ならびにソースおよび変更者の身元を記録することによりレポジトリ６８におけるデータの変更も追跡し、データ更新監査審理（ｄａｔａ　ｕｐｄａｔｅ　ａｕｄｉｔ　ｔｒｉａｌ）の保守を行う。ヒストリアン（ｈｉｓｔｏｒｉａｎ）ユニット７０は古くなったデータ値バージョンの保管ならびに保持に使用され、殊に財務トランザクションの完了に続く患者のエンカウンタ（すなわち関連する財務トランザクションが未払いでないエンカウンタ）に関連づけられたデータレコードの保管ならびにそれらのエンカウンタの処理に使用される。ここで使用されるエンカウンタは、患者に関係するヘルスケア企業や財務結果またはトランザクション結果を生じさせるヘルスケア企業相互作用による患者エンカウンタを有しており、たとえば患者訪問、通話、入院患者の逗留あるいは外来患者の治療などを有することができる。このようなエンカウンタの記録はデータキーパユニット６４によりレポジトリ６８内に保持される。ヒストリアンユニット７０は保管されたデータを保管データベース（データウェアハウス）７２内に格納する。
【００１５】
ルール実行ユニット４６はインタフェース６６を介してルールレポジトリ７４から導出されたルールを実行し、臨床イベントおよび他のイベントに応答して多様な機能を自動的に実行する。それらのファンクションとして挙げるとすればたとえば、（固有の処置の保険適用範囲のための）患者資格照合、提案された処置の医療上の必要性の照合ならびに照会処理の導入などである。また、臨床イベントおよび他のイベントに応答してルール実行ユニット４６は、個々の請求書要素が１つの請求書に組み入れられているときにそれらの要素も確認し、他のアクションも実行する。さらにルール実行ユニット４６は裁定ユニット４８と共働して、仕上げられた請求書を全体として確認する。
【００１６】
図２および図３には、ユニット４６の動作および臨床情報システム（見やすくするため図示せず）において記録されるような患者ヘルスケアエンカウンタ期間中に発生する臨床イベントとの相互作用（図１）が示されている。殊に図３には、図２の詳細図としてユニット４６により実行されるプロセスのフローチャートが示されている。図２および図３を合わせて考察すると、ステップ３００における開始に続きステップ３０３においてユニット４６は、イベント（図２の項目２１）を識別するメッセージおよびある患者に係わるヘルスケアデータ中の関連する変更を受け取る。ユニット４６はトリガイベントメッセージを検出し（図２の項目１）、イベント識別子を分析して（図２の項目２）、ステップ３０７において個々のイベントと少なくとも１つの対応するルールとをリンクするデータベース９１を使用しながらルールレポジトリ７４内のルールリスト（図２の項目９３）から１つまたはそれよりも多くのルールを選択する（図２の項目３）。
【００１７】
１つのイベントはデータ入力または更新の実行、ファイルの転送、ルールに従ったアクションの実行、指定されたタイムインターバルの満了またはアクションのスケジューリングを有している。たとえば１つのイベントには、ａ）患者に対するサービス提供関連レコードの生成、ｂ）患者に対するサービス提供に関する請求書作成関連レコードの生成、ｃ）オペレーティングプロセスによる患者に対するヘルスケア提供発生指標の生成、ｄ）患者監視機器による患者に対するヘルスケア提供発生指標の生成、ｅ）医療機器による患者に対するヘルスケア提供発生指標の生成を含めることができる。ユニット４６により実行されるルール自体によってトリガイベントを生成し他のルールの実行を開始することができる。これらのルールは、患者に対する個々のサービスの提供についての償還に関連づけられた特性を決定するために用いられる。このような特性にはたとえば、ｉ）患者に対する個々のサービスの提供について見込まれる償還額、ｉｉ）償還のための有効給付期間、ｉｉｉ）償還についての契約条件、ｉｖ）患者に対する個々のサービスの提供が固有の保険プランのもとで償還を受ける資格があることの指示、ｖ）患者に対する個々のサービスの提供が患者に対する他のサービスの提供とリンクされていることの指示、などを含めることができる。
【００１８】
図５および図６には、患者に対する臨床イベント発生に関連づけられた請求書データ処理ルールの一例が示されており、これは自動支払収集をそのつど開始させるために用いられる。たとえば図５のルール５０１〜５１３は、トリガイベントに応答して患者に対するサービス提供についての請求書データを自動的に確認し訂正するためユニット４６によって用いられる。請求書データは、ある時点である１つのサービスが患者に与えられたときにサービスに対し見込まれる償還を計算することによって処理される。患者請求書作成レコードに組み込まれるサービス料金レコードに応答して、優先順位順に適用可能な有効なヘルスケア保険証券について見込まれる償還が計算される。ユニット４６はルール５０１〜５１３および他のルールを実行し、請求書データが支払側要求に従っていることを確認する。２つの個々のサービス料金が１つの患者計算書作成レコードにおいて多様なサービスおよびそれに関連する料金をカバーする１つの請求書全体について累積しているならば、ユニット４６はこれをそれら２つの個々のサービス料金のために行う。
【００１９】
図６のルール５２１〜５３０は、保険支払側または他の管轄当事者に支払義務のある金額を追跡する目的で支払収集を自動的に開始させるためユニット４６により用いられる。ユニット４６により開始させることのできる他のルールによれば、保険請求書のフォーマッティングおよび伝送、トランザクションレコーディング、支払側の分散処理、送金処理が扱われる。図１のシステムは、ルールの選択および開始のためユニット４６により使用される保険支払側送金説明コードを含む電子送金データを自動的に処理し、支払、裁定、コメントおよびたとえばヘルスケア支払機関から受け取る他の項目について処理する。また、ユニット４６は、管轄支払側について請求されていないかさもなければうまく通達されていない料金を見つけ出して取り戻す目的のルールも実行する。たとえばユニット４６は、ａ）料金の請求された相応のレコードをもたない患者エンカウンタのレコード、ｂ）麻酔料金のない手術料金、ｃ）外科的処置を示しているが手術料金および／または麻酔料金の請求されていないＩＤＣ９−ＣＭ処置などを識別するルールを実行する。
【００２０】
ステップ３０９（図３）においてユニット４６は受け取ったイベント識別メッセージに応答してステップ３０７で選択されたルールの適用を開始し、これによって患者に対する固有のサービス提供に係わる財務データを処理する。財務データは、特有の患者に対する特定のサービスの提供についての患者と臨床サービスの識別データを合わせた請求書データである。ここで用いられる財務データは、１つの請求書の一部分、１つの請求書全体、１つの請求書の固有のレコードまたはヘルスケアサービスプロバイダによる個々の患者のエンカウンタに関連づけられたレコードデータを有する。図４には、個々の患者（患者は項目４２０によって識別されている）についての財務データを表すユーザインタフェースディスプレイイメージが描かれている。請求書作成レコードには、怪我の治療に係わるヘルスケアプロバイダによる多数の患者エンカウンタ４０２，４０４，４０６について照合された請求書データ要素が含まれている。さらに図４には、（ユニット４６により実行された）請求書データのこのセットに対し適用されたエディットルールの適用結果として生成されたメッセージも示されている。これらのルールはそのメッセージ内で２つのレベルの厳格性を有しており、すなわち訂正すべきエラーと再検討する必要のある警告という２つのレベルがある。
【００２１】
ステップ３０９（図３）においてユニット４６は、ステップ３０９（図２の項目４）において選択されたルールの連続するシーケンシャルな実行を開始する。しかしながらルール自体によってルール実行シーケンスを変化させることができ、これは処理がルールリスト内の後続のルールとは別の識別されたルールから続けられるよう命令することにより行うことができ、あるいはルールの結果として１つまたは複数の付加的なルールをシーケンスに挿入することができる。択一的にルールによって、たとえばルールシーケンスの実行終了を指示することができる。ルールの実行にあたり、個々のルール（図２の項目５）を有するテストがテストレポジトリ９５から導出され、個々のルールを有する個々のテストが連続的に実行される（図２の項目６）。個々の確認ルールに１つまたは複数のテストを含ませることができ、これによって真の条件を識別し関連づけられた第１のアクションセットを開始させるかまたは、偽の条件を識別し関連づけられた第２のセットのアクションを開始させる。ルールテスト条件は単純なものであってもよいし、あるいは論理演算子（たとえばＡＮＤ、ＯＲ、ＮＯＴ）で結合されたテストの組み合わせを含む複雑なものであってもよい。結合された個々のテストの結果が論理的に組み合わせられて（真または偽の）１つのテスト総合結果が得られるようになる。さらにアクションのセットを、いかなるアクションもトリガしない空のセットとすることができる。トリガ条件が検出されなければ、ルールのデフォルトである真の条件が示される。ルールレポジトリ７４には実行可能なルールとテストコンポーネントが含まれており、これは英語の記述と一緒に個々のルールに組み込まれていて、この記述によって表されているのは非技術系ユーザに対するヘルププロンプトおよび説明において利用するための個々のルールの機能である。有効期間を表す開始と終了の日時も、個々のルールにより組み込まれたルールと個々のテストの両方についてレポジトリ７４によって保持される。ユニット４６はルール有効期間を検査し、有効期間外の日時ではルールまたはテストコンポーネントは実行しない。
【００２２】
ユニット４６は、個々のルールを有するテストレポジトリ９５から導出されたテスト（図２の項目６）を連続的に実行し、テスト結果を論理的に合成して、図２の項目７に示されているような（真と偽の）テスト総合結果を形成する。たとえばユニット４６は（判定構造内のＡ，Ｂ，Ｃ，Ｄ，Ｅとして図に示されている）個々のテストコンポーネントを評価し、（テストレポジトリ９５内にテストともに）記憶されている論理的関係を適用して、個々のルールに対する総合的な結果状態を決定する。ルールが真の状態であればそれに応じてユニット４６は第１のアクションセット（図２のステップ８）を実行し、ルールが偽の状態であればそれに応じてユニット４６は第２のアクションセット（図２のステップ９）を実行する。
【００２３】
ステップ３１１（図３）においてユニット４６は図２のステップ１１〜１５でアクションを連続的に開始し、これらはアクション識別レポジトリ９７を使用してルール結果に基づき決定される。この目的でユニット４６はステップ１５においてアクションを開始し、それらのアクションはステップ１３においてルールインタフェース６６を介してレポジトリ９７から導出された識別データを使用してアクション定義レポジトリ９９から導出されたデータで指定されている。この種のアクションの１つは、ルールの適用に応じて判定された識別済みの請求書要素の不正確な部分の自動訂正である。ルールによって自動的に請求書データに対する訂正が行われ、これは　Ｃｅｎｔｅｒｓ　ｆｏｒ　Ｍｅｄｉｃａｒｅ　＆　Ｍｅｄｉｃａｉｄ　Ｓｅｒｖｉｃｅｓ　（ＣＭＳ）の２００２年４月１日の　Ｃｏｒｒｅｃｔ　Ｃｏｄｉｎｇ　Ｉｎｉｔｉａｔｉｖｅ　（ＣＣＩ）　Ｅｄｉｔｓ　Ｖｅｒｓｉｏｎ　８．１と互換性があり、これには医療サービスの誤ったコーディングの識別および除去が含まれている。ＣＭＳは　Ｍｅｄｉｃａｒｅ　＆　Ｍｅｄｉｃａｉｄから支払を受け取るためにＣＣＩエディットに従う必要がある。ユニット４６はＣＣＩエディットを組み込むルールを実行し、請求書に提示された臨床コードに対しそれらが適用される。ユニット４６により用いられる付加的な請求書エディットルールは、ＣＭＳ　Ｃｏｍｐｒｅｈｅｎｓｉｖｅ／Ｃｏｍｐｏｎｅｎｔ　Ｅｄｉｔｓ　（ＣＣＥ）から導出され、これらは　Ｃｏｒｒｅｃｔ　Ｃｏｄｉｎｇ　Ｉｎｉｔｉａｔｉｖｅ　（ＣＣＩ）　Ｅｄｉｔｓ　Ｖｅｒｓｔｉｏｎ　８．１と互換性がある。これらの付加的な請求書エディットルールによって一群のサービスを識別するコードあるいはこれら一群のサービスの個々のコンポーネントを識別するコードが検査される。このようなスキーマにおいて個々のコンポーネントまたは一群のサービスを符号化することができるが、両方を符号化することはできない。ユニット４６により用いられる付加的な請求書エディットルールは、ＣＭＳ　Ｍｕｔｕａｌｌｙ　Ｅｘｃｌｕｓｉｖｅ　Ｃｏｄｅ　（ＭＥＣ）　Ｅｄｉｔｓ（これは　Ｃｏｒｒｅｃｔ　Ｃｏｄｉｎｇ　Ｉｎｉｔｉａｔｉｖｅ　（ＣＣＩ）　Ｅｄｉｔｓ　Ｖｅｒｓｉｏｎ　８．１と互換性がある）を有しており、これにより同じ日付のサービスにおいて同じプロバイダにより与えられたときには両方ともは償還されない処置のペアが識別される。
【００２４】
ユニット４６により開始される他のアクションは、ヘルスケアワーカの作業リストに仕事を追加すること、あるいは作業リストから仕事を取り除くことである。作業リスト項目に加える一例としてのメッセージはたとえば、「患者　Ｊｏｈｎ　Ｄｏｅの到着のために４２１号室のベッドＡを準備せよ。到着予定日時２００２年４月１６日午後８：００」などとすることができる。別の仕事として、たとえば患者財務データを処理するために適用した結果として導出されたデータの再調査を含めることができる。また、再調査のためのデータとして、患者に対する特定の治療の拒否の通知、償還のための治療資格について設けられた特認に対する要求の通知、あるいはある患者に対する特定の治療に関する償還のための仮請求書の処理結果を挙げることができる。択一的に、（たとえば点滴注入などの）タスクを医療機器による実行のためにスケジューリングすることができるし、あるいは医療機器によるスケジューリングされた実行から除去することができる。ユニット４６により開始されるさらに別のアクションとして、入院前テストのレコードと外科的処置のレコードとのリンク、同日の外科的処置のレコードと入院患者エンカウンタレコードとのリンク、母を識別するレコードと新生児関連レコードとのリンク、あるいは同日中の外来患者処置レコードと入院患者エンカウンタとのリンクを挙げることができる。ユニット４６により開始することのできる付加的なアクションには、自動実行用タスクの作業リスト生成、ログおよび監査レポートおよびアカウンティングレポートの生成、エラーレポートの生成、請求書の生成、送金の転記、データ修正ならびにその他のアクションが含まれている。
【００２５】
ステップ３１５（図３）においてユニット４６は、特定のサービスの提供に対する請求書データ要素の確認（ステップ３０９）が失敗したことに応答して、択一的な候補サービスをユーザに促す。ステップ３１７においてユニット４６は確認済みの請求書データ要素を照合して、支払側に提示するために患者に対するサービス提供についての請求書を作成する。図３のプロセスはステップ３２０において終了する。
【００２６】
図７〜図１０には臨床システムと財務システムを介入させたルールに従ったプロセスが示されており、これは図２および図３を参照しながら説明したようにルールの実行によりユニット４６によって開始される。図７には臨床結果と財務結果をもつプロセスのフローチャートが示されており、これは患者のために実行すべき提案処置が支払側の医療的必要性に合致しているか否かのチェックにおいて用いられる。病院情報システムに加えられたプロセスを実行するための命令を受け取ると、これによって有利には自動的にユニット４６により医療的必要性判定がトリガされる。この目的で命令に関連するデータが検査され、この検査によって命令フォーマットや命令内容に問題があると識別されると命令の出所に通知される。また、命令の受け取りによって有利には自動的に、処置に対する請求書データの仮裁定（ｔｒｉａｌ　ａｄｊｕｄｉｃａｔｉｏｎ）もトリガされる。図７においてステップ５５０のスタート後、ステップ５５３において命令を受け取ってから、この命令受け取りイベントに応じてユニット４６はステップ５５５においてルールを実行し、これによって予定された処置が特定の支払組織の医療的必要性に合致していることを照合する。ユニット４６は命令の出所に対する通信を開始し、この命令は関連処置に対する医療的必要性によりステップ５５７において照合されるかまたは、ステップ５５７において関連処置に対する医療的必要性により照合が失敗している。ステップ５５９における照合失敗に応じてステップ５６０においてユニットは　”Ａｄｖａｎｃｅ　Ｂｅｎｅｆｉｃｉａｒｙ　Ｎｏｔｉｆｉｃａｔｉｏｎ　（ＡＢＮ）”の生成を開始し、これは医師と患者がこの処置の継続に同意したかを示すための患者に対する特認となるフォームである。医師と患者がこの処置の続行を選ばなければ、この財務イベント（医療的必要性照合）によって臨床作業の流れが変更される（この処置をキャンセルする決定を促す）。図７のプロセスはステップ５６５で終了する。
【００２７】
図８には臨床結果と財務結果を有するプロセスのフローチャットが示されており、これは実施された処置に対する請求書データ要素を確認する際に用いられる。図８によればステップ５８０で開始された後、ステップ５８２における支払側に対する提示のための請求書の準備に応答してユニット４６はステップ５８４において、請求された個々の処置が支払組織の医療的必要性を満たしていることの確認のためルールを実行する。ステップ５８６においてユニット４６は、医療的必要性に関して照合された処置に対する請求書要素を支払側に提示するための請求書に含めるよう指示する。また、ステップ５８８においてユニット４６は、ステップ５８４で医療的必要性の照合が失敗した処置に対し　Ａｄｖａｎｃｅ　ＢｅｎｅｆｉｃｉａｒｙＮｏｔｉｆｉｃａｔｉｏｎのレコードが存在するか否か判定される。それら特定の処置に対しそのような通告が存在していると判定されたならばステップ５９０においてユニット４６は、それら特定の処置に関連する請求書要素を支払側に提示するための請求書に含めるよう指示する。また、そのような通告が存在していない処置に対してはユニット４６はステップ５９２において、請求書作成を行わないよう指示する。図８のステップはステップ５９４において終了する。
【００２８】
図９には臨床結果と財務結果を有するプロセスのフローチャットが示されており、これは提案された処置が患者ヘルスケアプランによりカバーされるか否かを判定する際に用いられる。ユニット４６は、患者医療保険プランのもとで訪問または処置に対する償還について患者が資格をもっていることを有利には自動的に照合するルールを実行する。これは患者の訪問または処置が予定され保険情報が収集されることを表すメッセージの受け取りに応答して行われる。図９によればステップ６００における開始後、ステップ６０３において患者の訪問または処置を予定に組み込み保険情報を収集する命令を受け取った後、ユニット４６はステップ６０７において、予約された訪問または処置が患者の医療保険プランのもとで償還可能であることを照合するためのルールを実行する。ユニット４６は、ステップ６０９において訪問または処置が保険でカバーされることの照合された命令の出所（たとえば医師）と通信を始めるか、あるいはステップ６１１において訪問または処置がカバーされていない命令の出所（たとえば医師）と通信を始める。患者が契約条件に基づくサービスについて資格をもたなければ、専門家による再調査のために作業リストエントリをあとで生成することもできる。ユニット４６は、記憶されている支払側アドレス情報とともに支払側を識別する事前に収集された患者保険情報を利用し、識別された支払側へ資格性要求を送信する。個々のヘルスケアプロバイダは、応答を促進するため（作業リストエントリの作成やＥメールの送信など）さらにアックションを起こす前に資格性要求のためにどのぐらい待つのかに関するルールを決定する。ステップ６１１のようにカバーされない判定が下されると、ステップ６１３において医師は、カバーされない処置がそれにもかかわらず有利な治療方針であると決めることができる。そのような場合、臨床作業の流れに対し財務システムは影響を及ぼさない。択一的に、ステップ６１１においてカバーされないと判定されたことに応じて、ステップ６１５において択一的な治療オプションが医師に促される。医師はプロバイダポータル（図１）を利用して、患者保険プランによってカバーされる択一的な治療を決定し選択することができる。この場合、財務システムによって臨床作業の流れが変更される。図９のプロセスはステップ６２０で終了する。
【００２９】
図１０には、ある特定の患者に関する医療診断レコードの作成の結果生じるアクション実行プロセスのフローチャートが示されている。図１０によればステップ６３０において開始された後、ステップ６３４で（たとえば肺虚脱を表す）診断レコードを受信するとステップ６３８においてユニット４６は、診断イベントに応答するアクションを開始するためのルールを実行する。開始されるアクションにはたとえば患者情報の転送、Ｘ線の予約、外科医の要員確保、患者入院の実行、作業リストへ仕事を組み込むことで部屋を準備するための職員の予約などが含まれる。図１０のプロセスはステップ６４０において終了する。診断入力に応答してユニット４６により起こすことのできる他のアクションにはたとえば、Ｅメール、ポケットベルまたはＰＤＡ機器を介して指定された受取人に対しリアルタイム通告を発生させることなどが含まれる。通告の一例をたとえば、「Ｓｍｉｔｈ先生、あなたの患者Ｊｏｈｎ　Ｄｏｅは２００２年４月１６日午後７：０５にｘｙｚ病院の救急ルームに到着。患者は左脛骨骨折と診断され、骨は固定されギプスが当てられた。この措置を実施した救急ルームの医師はＪｏｎｅｓ先生。」などとすることができる。これに加えてユニット４６は、アラームの設定オフ、定期的なレポートの準備、患者調査レコードの変更、患者入院など他のイベントのトリガ、および救急ルームから割り当てられたベッドへの患者の搬送のため関連するルールの実行などを開始することができる。
【００３０】
再び図１を参照すると照合されたデータは、図２および図３を参照しながら先に説明したやり方でルールを実行するためユニット４６を用いて仮裁定器により予備処理するために提示される。この予備処理によって、照合済み請求書データが支払発生を開始する処理に適していることが確認される。データモルファユニット　Ｄａｔａ　Ｍｏｒｐｈｅｒ　ｕｎｉｔ４４は、命令に応答してレポジトリ６８内のデータの修正をルールにより生じさせるアクションのサブカテゴリを有している。ユニット４６は関係ルールレポジトリ　Ｒｅｌａｔｉｏｎｓｈｉｐ　Ｒｕｌｅｓ　Ｒｅｐｏｓｉｔｏｒｙ１８内に格納されているルールも処理および実行する。関係ルールレポジトリにはインタフェース１０を介した通信中にプロテクタ１２、トランスレータ１４、トランスポータ１６により要求され使用されるルールが含まれている。
【００３１】
調整ガイドラインとディレクティブを含むルールがレポジトリ７４における格納のため継続的に取得され、継続的に更新され、ルールキーパユニット６６を介してこのレポジトリ内に保持される。ルール保管ユニット７６はルールキーパユニット６６と共働して保管すべきルールに日時を入れ、廃れたまたは期限の切れたあるいはいっそう古いバージョンルールを保管（ルールウェアハウス）データベース７８に格納する。レポジトリ７４には、支払機関関与体から取得された裁定ルールも含まれているし、支払側との先行のトランザクションによって確立されたルールも含まれている。レポジトリ７４にはさらにシステムにより開発されたルールも含まれているし、システムに対し自動化されたプロセスを加える権限のある関与体により開発されたルールも含まれている。パターンデザイナユニット５６は汎用目的のルールを生成するために用いられる。
【００３２】
ユニット４８は、インタフェース１０とデータネットワーク５８を介してルールアクセス手段５２により（支払機関６０が所有するルール６２のような）外部ルールソースから導出されたレポジトリ７４内のルールを使用する。ネットワーク５８は、たとえばＬＡＮ（ｌｏｃａｌ　ａｒｅａ　ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ　ａｒｅａ　ｎｅｔｗｏｒｋ）またはインターネットなど慣用のネットワークによって構成することができるし、あるいは択一的にクリアリングハウス　ｃｌｅａｒｉｎｇｈｏｕｓｅまたはヘルスケア支払側またはヘルスケアプロバイダにより使用される他のサービスのようなネットワークサービスによって構成することができ、これにより請求書裁定のためのデータおよびルール（たとえば支払側ルール６２）の取得が容易になる。支払側ルール６２は支払側６０によって発布されたルールであり、それらはルール取得ユニット５４により管理される自動化プロセスを介してはアクセスできない。そうではなく支払側ルール６２はマニュアル取得プロセスを介して手動で決定され、ルールメーカユニット５６により提供されるユーザインタフェースを利用してルール取得ユニット５４により分解され分析される。ルールメーカユニット５６のユーザインタフェースにより、ユニット５４を介して取得されたルールの手動の生成、再調査ならびに更新がサポートされる。さらにルールメーカユニット５６によってユーザに対し利用可能なテストおよびアクションのリストが示唆され、エディットされたルールをルールレポジトリ７４に格納する前にルールの構築およびエディットのプロセスに関してユーザを案内する。
【００３３】
ルール取得ユニット５４は、自身が所有権をもつプログラミングされたルールセットに対しアクセスを提供する支払側によって与えられたドキュメンテーションおよび他の情報についてルールデータを収集する（ルール取得ユニット５４はルールのための支払側システムの集計を行うことのできる自動化されたユニットでもある）。ユニット５４は支払側ウェブサイトまたは他のソースから支払側の発した情報告示を検索し、それらの資料を分析して、レジストリ７４に組み込むため新たなルールまたは変更されたルールを表す情報を識別し、さらに期限の満了したルールを識別する。さらに個々の支払機関は支払側ポータル２２を使用して、インタフェース１０を介して取得ユニット５４にルール情報を伝えることができ、取得ユニット５４はルールキーパユニット６６を使用してそれらをレポジトリ７４に組み入れる。さらにユニット５４は、ルール収集サービス８０により支払側から取得された情報に基づき、ルールメーカ５６により提供されるユーザインタフェースを介してユーザが手動でデータを入力し処理した結果として生じる新たなルールも検索する。支払側は、たとえば新たなルールまたはルールバージョンのインプリメントに先立ち、更新されたルール情報をルール収集サービス８０に転送する。ルールチェッカユニット５０はレポジトリ７４内のルールを監視し、不完全なルールまたは誤ったシンタックスを含むルールを識別してユーザに指示する。さらにルールチェッカユニット５０は、互いに矛盾し合うルールの組み合わせも報告する。また、ルール実行ユニット４６および仮裁定ユニット４８による請求書データ処理中に所定の例外条件が識別されたことに応答して例外追跡ファンクション４８は、識別された例外条件の処理と報告を管理するルールのサブセットを用いる。特定のルールの実行に応答して、または特定のルール実行結果に応じて、例外追跡ファンクション４２をルール実行ユニット４６によって呼び出すことができる。例外条件の決定に基づき例外追跡ファンクション４２は手動の介入をスケジューリングすることができ、これをたとえばユーザインタフェースまたは作業リストを介して、あるいは受取側へ報告またはメッセージを送ることにより行うことができる。さらに例外追跡ファンクション４０は例外条件がなくなったとき、請求書データ補正を識別する受信メッセージに基づき、たとえばユーザアクションに応じて患者レコードの更新も行う。
【００３４】
ルール実行ユニット４６により処理され（必要に応じて）訂正され確認されて最終的には支払側に提示される請求書データは、データレポジトリ６８から導出される。
【００３５】
図１１〜図１７には、中央データレポジトリ６８に組み込まれ請求書処理に使用されるデータ要素に関するデータレコード構造が例示されている。たとえば図１１には部分的な患者レコードデータ構造が示されており、図１２には医療レコードデータ構造が、図１３には部分的な支払側レコードデータ構造が示されている。また、図１４および図１５には料金レコードデータ構造と発生コードデータ構造がそれぞれ示されており、図１６および図１７には、（単一の請求書において分類すべきサービス料金の識別に使用される）スパンコードと医療条件コードデータ構造がそれぞれ示されている。これらのレコード構造は一例にすぎずレポジトリ６８には典型的には請求書データに関連する他のタイプのレコードも含まれており、たとえば救急サービスやリハビリテーションサービス、治療および他のサービスや活動に関するレコードなども含まれている。図１１〜図１７のレコード構造は、請求書パケット識別子（８００，９００，９２０，９４０，９６０，９８０，８３０）、セクション識別子（８０２，９０２，９２２，９４２，９６２，９８２，８３２）およびシーケンス番号（８０４，９０４，９２４，９４４，９６４，９８４，８３４）を使用してレポジトリ６８において個別にアクセス可能である。
【００３６】
この例では個々のレコードデータ構造におけるデータは、フィールド長で区切られている。図１１の患者レコード構造の場合にはたとえば、患者の姓（８０６）が２０キャラクタの固定長を占めており、それに続いて患者の名（８０８）が１２キャラクタを占め、さらに中間名（８１０）が１キャラクタを占めている。図１２〜図１７のレコード構造には、まえもって決められた同様の固定長フィールドで請求書データの別の観点に関するデータが含まれている。図１２の医療レコードにはたとえば、入院診断コード（９０６）と第１診断コード（９０８）および他の診断コード（９１０）が含まれている。図１３の支払側レコードには、支払側コード（９２６）のソースと支払側識別子（９２８）と支払側副識別子（９８６）が含まれている。図１４の料金レコードには、サービス料金コード（９４６）とサービス料金改訂コード（９４８）とサービスデータ（９５０）が含まれている。図１５の発生コードレコードには、発生識別コード（９６６）と発生データ（９６８）が含まれている。図１６のスパンコードレコードには、スパン識別コード（９８６）とスパン決定開始日時（９８８）と終了日時（９９０）が含まれており、これはこの請求書の支払側に関連するイベントを識別する識別コードと関連データにおいて用いられる。図１７の条件コードレコードには医療条件識別コード（８３６）が含まれている。図１１〜図１７を参照して説明した項目は例示の目的で述べたにすぎない。図１１のレコード構造にはその他のレコード項目も示されている。これらその他の項目はたとえば、レポジトリ６８の構造において様々なレコードに含めることのできるデータの幅広さを表すものである。択一的な実施形態において、レポジトリ６８のために他の非固定長のデータレコード構造や別のデータレコード構造を用いることができる。
【００３７】
レポジトリ６８内の請求書データは、先に説明したように多数の異なるソースからインタフェース１０を介してデータ取得ユニット３２により収集され、データ管理システム６４を介してレポジトリ６８内に記憶される。データ送出ユニット３４は、要求された請求書データをレポジトリ６８から抽出しインタフェース１０を介してそれを送ることによって外部の実体（たとえばポータルおよび関与体２０〜３０）へ請求書データを供給する。データ伝達ユニット３６は、遠隔の実体により記憶された請求書データに対するリードオンリアクセスを提供しそのデータに基づき判定を下すため、図１のシステムの複数のファンクションによって使用される。さらに請求書データレポジトリ６８は、サーチパターンデザインファンクション３８を使用して生成されたデータサーチ判定基準を用い外部ポータル２０〜２８を介して関与体３０によりサーチ可能である。これによりユーザは、統計的に重要なデータパターンやその他のデータパターンをレポジトリ６８における請求書データの分析にあたりサーチすることができる。この場合、先に説明したタイプのイベントの発生または特定のデータの変更の検出（たとえば特定の診断の受け取り）に応じて、あるいは特定の期間の満了に応じて、パターンサーチを実行することができる。
【００３８】
なお、本発明は図１〜図１７に示したシステム、プロセスおよびユーザインタフェースの表示形式に限定されるものではない。同じ目的を達成するため本発明の基本原理に従って他のシステム、プロセスおよびユーザインタフェースの形式を導き出すこともできる。また、本発明の基本原理を、あらゆる産業や分野でのイベントドリブン型収入管理システムの合理化および自動化のために適用することができる。たとえば基本原理を保険産業、政府ならびにヘルスケア産業に適用することができる。
【図面の簡単な説明】
【図１】ヘルスケア支払機関または他の実体に対し請求書を提示する前に請求書の正確さを改善するため患者ヘルスケアエンカウンタ中、臨床イベントに応答しそれを開始させる本発明による請求書処理システムを示す図である。
【図２】患者ヘルスケアエンカウンタ中、臨床イベントに応答しそれを開始させる本発明によるルール実行システムを示す図である。
【図３】本発明に従って図１および図２のシステムにより請求書処理中に用いられるプロセスを示すフローチャートである。
【図４】傷害治療に係わるヘルスケアプロバイダによる多様な患者エンカウンタに対する患者請求書作成レコードを表す本発明によるユーザインタフェースを示す図である。
【図５】患者に対する臨床イベント発生に関連する本発明による請求書データ処理ルールを例示した図である。
【図６】支払側アクションと相互に作用し自動支払を開始させるために用いられる本発明による請求書データ処理ルールを例示した図である。
【図７】提案された処置が支払側の医療必要性に合致しているか否かをチェックする際に用いられ臨床結果および財務結果をもたらす本発明によるプロセスを示すフローチャートである。
【図８】実行された処置に対する請求書データ要素の確認に用いられる臨床結果および財務結果をもたらす本発明によるプロセスを示すフローチャートである。
【図９】提案された処置が患者ヘルスケアプランによりカバーされるか否かの判定に用いられ臨床結果および財務結果をもたらす本発明によるプロセスを示すフローチャートである。
【図１０】医療診断レコード生成の結果として生じる本発明によるアクション実行プロセスを示すフローチャートである。
【図１１】本発明に従い請求書処理に用いられ中央データレポジトリに組み込まれた請求書データ要素を含むデータレコードを示す図である。
【図１２】本発明に従い請求書処理に用いられ中央データレポジトリに組み込まれた請求書データ要素を含むデータレコードを示す図である。
【図１３】本発明に従い請求書処理に用いられ中央データレポジトリに組み込まれた請求書データ要素を含むデータレコードを示す図である。
【図１４】本発明に従い請求書処理に用いられ中央データレポジトリに組み込まれた請求書データ要素を含むデータレコードを示す図である。
【図１５】本発明に従い請求書処理に用いられ中央データレポジトリに組み込まれた請求書データ要素を含むデータレコードを示す図である。
【図１６】本発明に従い請求書処理に用いられ中央データレポジトリに組み込まれた請求書データ要素を含むデータレコードを示す図である。
【図１７】本発明に従い請求書処理に用いられ中央データレポジトリに組み込まれた請求書データ要素を含むデータレコードを示す図である。
【符号の説明】
１０　インタフェース
１２　プロテクタ
１４　トランスレータ
１６　トランスポータ
１８　関係ルールレポジトリ
２０　プロバイダポータル
２２　支払側ポータル
２４　コンシューマポータル
２６　雇用側ポータル
２８　監督側ポータル
６０　支払側
６４　データキーパユニット
６６　ルールキーパユニット
６８　ヘルスケアデータレポジトリ

Claims (16)

1. 臨床イベントに応答して患者のヘルスケアに関連する財務データを処理するシステムにおいて、
   患者に関するヘルスケアデータにおけるイベントおよび関連する変更を識別するメッセージを受け取るためのインタフェースプロセッサと、
   患者に対する個々のサービス提供に関する償還に関連する特性を決定するルールソースと、
   前記イベント識別メッセージの受け取りに応じて患者に対する個々のサービス提供に関する財務データを処理するため前記ルールソースから導出されたルールの適用を開始するルールプロセッサと、
   前記財務データを処理するため前記ルールの適用により導出された結果に応答してアクションを起こす結果プロセッサが設けられていることを特徴とする、
   患者のヘルスケアに関連する財務データを処理するシステム。
2. 前記イベントには、ａ）患者に対するサービス提供関連レコードの生成、ｂ）患者に対するサービス提供に関する請求書作成関連レコードの生成、ｃ）オペレーティングプロセスによる患者に対するヘルスケア提供発生指標の生成、ｄ）患者監視機器による患者に対するヘルスケア提供発生指標の生成、ｅ）医療機器による患者に対するヘルスケア提供発生指標の生成、のうち少なくとも１つを有する、請求項１記載のシステム。
3. 前記結果プロセッサは導出された結果に応答して、ヘルスケアワーカの作業リストへのタスク追加を開始し、該タスクには前記財務データ処理のためのルール適用の結果として導出されたデータの再調査が含まれ、該再調査のためのデータには、ａ）患者に対する特定の治療の拒否の通告、ｂ）償還のため治療資格に対して設けられるべき特認の要求通告、ｃ）患者に対する特定の治療に関する償還のための仮請求書の処理結果、のうち少なくとも１つを有する、請求項１記載のシステム。
4. 前記ルールプロセッサはルールソースから導出されたルールの適用を開始して、請求書作成レコードの検査により患者に対する個々のサービス提供に係わるデータを処理し、前記イベント識別メッセージの受け取りに応答して所定の期間内にヘルスケア支払機関により支払が行われなかったかを判定し、前記結果プロセッサは導出結果に応答して未払いの支払いを収集するアクションを起こす、請求項１記載のシステム。
5. 前記結果プロセッサは導出結果に応答して、
   ｉ）ａ）入院前テストのレコードと外科的処置のレコードとのリンク、ｂ）同日の外科的処置のレコードと入院患者エンカウンタレコードとのリンク、ｃ）母を識別するレコードと新生児関連レコードとのリンク、ｄ）同日中の外来患者処置レコードと入院患者エンカウンタとのリンク、のうち少なくとも１つ、
   ｉｉ）ヘルスケアワーカの作業リストからのタスクの消去
   ｉｉｉ）医療機器に関する作業リストへのタスクの追加、
   のうち少なくとも１つを開始する、請求項１記載のシステム。
6. 患者に対する個々のサービス提供に関するプロバイダへの償還に関連する前記特性には、ａ）患者に対する個々のサービス提供についての見込まれる償還額、ｂ）該償還のための有効給付期間、ｃ）該償還についての契約条件、ｄ）患者に対する個々のサービスの提供が固有の保険プランのもとで償還を受ける資格があることの指示、ｅ）患者に対する個々のサービスの提供が患者に対する他のサービスの提供とリンクされていることの指示、のうち少なくとも１つが含まれている、請求項１記載のシステム。
7. ａ）ヘルスプラン償還条件、ｂ）ヘルスプランフォーマット要求、ｃ）償還方式、ｄ）償還制限、ｅ）償還計算手順、のうち少なくとも１つを含む所定の要求に請求書要素が従っているかを判定するための手順がルールに含まれており、
   前記請求書要素には、ｉ）請求書の一部分、ｉｉ）請求書全体、ｉｉｉ）請求書の個々のレコード、ｉｖ）ヘルスケアサービスプロバイダによる個々の患者エンカウンタ関連のレコードデータ、のうち少なくとも１つが含まれる、
   請求項１記載のシステム。
8. 前記イベント識別メッセージは臨床情報システムから受け取られ、ａ）ヘルスケアワーカ、ｂ）医療機器のうち少なくとも一方によるヘルスケア関連タスクの実行に応答して生成される、請求項１記載のシステム。
9. 前記ルールプロセッサは、個々のイベントと少なくとも１つの対応するルールとをリンクするデータベースを使用して識別されたイベントに基づき、前記ルールソースから導出されたルールを選択する、請求項１記載のシステム。
10. 前記ルールプロセッサは前記イベント識別メッセージの受け取りに応答して、患者に対する相応の種々の個々のサービス提供に関する種々の請求書データ要素を個別に確認するため、前記ルールソースから導出されたルールの適用を開始し、
    前記ルールプロセッサは、ａ）前記請求書データ要素はヘルスケア保険プランのもとで償還可能であるか、ｂ）前記請求書データ要素はヘルスケア保険プランのもとで医療的必要性を満たすよう決められているか、ｃ）前記サービス提供に対して見込まれる償還額、ｄ）許可されるべき償還のためにルール特認が必要とされるか、のうち少なくとも１つを判定することにより、患者に対する個々のサービス提供についての請求書データ要素を確認する、
    請求項１記載のシステム。
11. 前記ルールプロセッサは確認された請求書データ要素を照合して、患者に対する複数のサービス提供に関する請求書を生成する、請求項１０記載のシステム。
12. 前記ルールプロセッサは、複数の請求書データ要素が種々のサービス提供に関して組み合わせられた償還を必要とする償還ルールに従っていることを確認する、請求項１０記載のシステム。
13. １つの請求書データ要素には、患者に対する固有のサービスについて患者サービスおよび臨床サービスの識別データとともに財務データが含まれており、該請求書データ要素に対し、ａ）情報充足要求に従っていること、ｂ）書式要求に従っていること、のうち少なくとも一方を判定するルールにより確認を行う、請求項１０記載のシステム。
14. 前記ルールプロセッサは、特定のサービス提供に関する請求書データ要素の確認失敗に応答してユーザに対し択一的な候補サービスを示唆する、請求項１０記載のシステム。
15. 臨床イベントに応答して患者ヘルスケアに関連する請求書データを処理するシステムにおいて、
    患者に係わる相応の請求書データ要素に関連する臨床イベントを識別するメッセージを受け取るインタフェースプロセッサと、
    患者に対する個々のサービス提供に係わる請求書データ要素を確認するルールソースと、
    前記イベント識別メッセージの受け取りに応答して請求書データ要素が不完全であることを識別するため前記ルールーソースから導出されたルールの適用を開始するルールプロセッサと、
    種々の請求書データ要素を個々に確認するため前記ルールの適用により得られた結果に応答してアクションを起こす結果プロセッサが設けられていることを特徴とする、
    患者ヘルスケアに関連する請求書データを処理するシステム。
16. 臨床イベントに応答して患者ヘルスケアに関連する財務データを処理する方法において、
    患者に係わるヘルスケアデータにおけるイベントおよび関連する変更を識別するメッセージを受け取り、
    該イベント識別メッセージの受け取りに応答して、患者に対する個々のサービス提供に係わる財務データを処理するためルールソースから導出されたルールの適用を開始し、該ルールを患者に対する個々のサービス提供についての償還に関連する特性の決定に使用し、
    前記財務データを処理するため前記ルールの適用により得られた結果に応答してアクションを起こすことを特徴とする、
    患者ヘルスケアに関連する財務データを処理する方法。

Images