特表 2022-509783 請求分析システム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-01-24

(54)【発明の名称】請求分析システム及び方法

(51)【国際特許分類】

   G06Q 40/08 20120101AFI20220117BHJP

【ＦＩ】

G06Q40/08

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2021527129

(86)(22)【出願日】2019-11-20

(85)【翻訳文提出日】2021-05-17

(86)【国際出願番号】 IB2019059968

(87)【国際公開番号】W WO2020109928

(87)【国際公開日】2020-06-04

(31)【優先権主張番号】201811045218

(32)【優先日】2018-11-30

(33)【優先権主張国・地域又は機関】IN

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＦＩＲＥＷＩＲＥ

２．ＴＨＵＮＤＥＲＢＯＬＴ

３．ＨＤＭＩ

４．ブルートゥース

５．コンパクトフラッシュ

６．ＡＮＤＲＯＩＤ

７．ＵＮＩＸ

８．Ｌｉｎｕｘ

９．Ｃｈｒｏｍｅ

１０．Ｓａｆａｒｉ

１１．Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ

１２．Ｆｉｒｅｆｏｘ

(71)【出願人】

【識別番号】521211354

【氏名又は名称】ジョンソン・アンド・ジョンソン・メディカル・ピーティーワイ・リミテッド

(74)【代理人】

【識別番号】100088605

【弁理士】

【氏名又は名称】加藤 公延

(74)【代理人】

【識別番号】100130384

【弁理士】

【氏名又は名称】大島 孝文

(72)【発明者】

【氏名】ショー・ウォーリック

(72)【発明者】

【氏名】モヒューディン・ラシッド

(72)【発明者】

【氏名】クアットロマーニ・ジェフ

(72)【発明者】

【氏名】シャー・アシーム

(72)【発明者】

【氏名】ディル・ジャティン

【テーマコード（参考）】

5L055

【Ｆターム（参考）】

5L055BB61

(57)【要約】

本明細書では、コンピュータ実装方法が記載される。本方法は、請求審査要求を提出者システムから受信することであって、請求審査要求が請求に関する請求データを含む、受信することと、請求に１つ又は２つ以上の欠陥が存在するかどうかを判定するために、請求データを分析することと、を含む。請求データに欠陥が存在しないと判定することに応じて、本方法は、請求リリースメッセージを提出者システムに通信することであって、請求リリースメッセージが、提出者システムによって請求に関して維持されている請求ブロックをリリースさせる、通信することを更に含む。

【特許請求の範囲】

【請求項1】

コンピュータ実装方法であって、
請求審査要求を提出者システムから受信することであって、前記請求審査要求が請求に関する請求データを含む、受信することと、
１つ又は２つ以上の欠陥が前記請求に存在するかどうかを判定するために、前記請求データを分析することと、
前記請求データに欠陥が存在しないと判定することに応じて、請求リリースメッセージを前記提出者システムに通信することであって、前記請求リリースメッセージが、前記提出者システムによって前記請求に関して維持されている請求ブロックをリリースさせる、通信することと、を含む、コンピュータ実装方法。

【請求項2】

１つ又は２つ以上の欠陥が前記請求データに存在すると判定することに応じて、
前記請求で識別された前記１つ又は２つ以上の欠陥に関する情報、及び、各欠陥に関して、提案された見直しアクションを含む欠陥通知を生成することと、
前記欠陥通知を前記提出者又は前記提出者システムに通信することと、を更に含む、請求項１に記載のコンピュータ実装方法。

【請求項3】

前記請求に関する更なる請求審査要求を前記提出者システムから受信することであって、前記更なる請求審査要求が、前記請求に関する更なる請求データを含み、前記更なる請求データが、追加の請求データ、修正された請求データ、コメントのうちの１つ又は２つ以上を含む、受信することと、
前記請求に何らかの欠陥が存在するかどうかを判定するために、少なくとも前記更なる請求データを分析することと、を更に含む、請求項２に記載のコンピュータ実装方法。

【請求項4】

前記更なる請求データに欠陥が存在しないと判定することに応じて、
請求リリースメッセージを前記提出者システムに通信することであって、前記請求リリースメッセージが、前記提出者システムによって前記請求に関して維持されている請求ブロックをリリースさせる、通信することを更に含む、請求項３に記載のコンピュータ実装方法。

【請求項5】

１つ又は２つ以上の欠陥が前記更なる請求データに存在すると判定することに応じて、
前記１つ又は２つ以上の欠陥が全て軽微な欠陥であると判定することと、
前記１つ又は２つ以上の欠陥の全てが軽微な欠陥であると判定することに応じて、前記１つ又は２つ以上の欠陥の全てに関するコメントが前記提出者システムから受信されたと判定することと、
前記１つ又は２つ以上の欠陥の全てに関するコメントが前記提出者システムから受信されたと判定することに応じて、請求リリースメッセージを前記提出者システムに通信することであって、前記請求リリースメッセージが、前記提出者システムによって前記請求に関して維持されている請求ブロックをリリースさせる、通信することと、を更に含む、請求項３に記載のコンピュータ実装方法。

【請求項6】

１つ又は２つ以上の欠陥が前記更なる請求データに存在すると判定することに応じて、
１つ又は２つ以上の欠陥に関するコメントが前記提出者システムから受信されていないと判定することと、
１つ又は２つ以上の欠陥に関するコメントが前記提出者システムから受信されていないと判定することに応じて、
前記請求で識別された前記１つ又は２つ以上の欠陥に関する情報、及び、各欠陥に関して、提案された見直しアクションを含む更なる欠陥通知を生成することと、
前記更なる欠陥通知を前記提出者システムに通信することと、を更に含む、請求項３に記載のコンピュータ実装方法。

【請求項7】

１つ又は２つ以上の欠陥が前記更なる請求データに存在すると判定することに応じて、
前記１つ又は２つ以上の欠陥が重大な欠陥を含むと判定することと、
前記１つ又は２つ以上の欠陥が重大な欠陥を含むと判定することに応じて、全ての重大な欠陥に関するコメントが前記提出者システムから受信されたと判定することと、
全ての重大な欠陥に関するコメントが前記提出者システムから受信されたと判定することに応じて、
評価者入力要求を生成することと、
前記評価者入力要求を評価者システムに通信することと、を更に含む、請求項３に記載のコンピュータ実装方法。

【請求項8】

前記評価者システムから、評価者入力を受信することと、
前記評価者入力が前記請求が許可されるべきであることを示していると判定することと、
前記評価者入力は前記請求が許可されるべきであることを示していると判定することに応じて、請求リリースメッセージを前記提出者システムに通信することであって、前記請求リリースメッセージが、前記提出者システムによって前記請求に関して維持されている請求ブロックをリリースさせる、通信することと、を更に含む、請求項７に記載のコンピュータ実装方法。

【請求項9】

１つ又は２つ以上の欠陥が前記請求に存在するかどうかを判定するために、請求データを分析することが、
前記請求データに潜在的に適用可能な１つ又は２つ以上のルールを判定することと、
前記請求データに潜在的に適用可能であると判定された各ルールについて、
前記ルールが実際に適用可能かどうかを判定するために、前記ルールを前記請求データに適用することと、
前記ルールが実際に適用可能である場合、前記ルールと関連付けられた情報を分析レポートに付加することと、
前記分析レポートを返すことと、を含む、請求項１～８のいずれか一項に記載のコンピュータ実装方法。

【請求項10】

請求審査システムであって、
プロセッサと、
通信インターフェースと、
命令のシーケンスを記憶している非一時的コンピュータ可読記憶媒体であって、前記命令が、前記プロセッサによって実行されると、前記プロセッサに、請求項１～９のいずれか一項に記載のコンピュータ実装方法を実行させる、非一時的コンピュータ可読記憶媒体と、を備える、請求審査システム。

【請求項11】

命令のシーケンスを記憶している非一時的コンピュータ可読記憶媒体であって、前記命令が、コンピュータプロセッサによって実行されると、前記プロセッサに、請求項１～９のいずれか一項に記載のコンピュータ実装方法を実行させる、非一時的コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、請求分析システム及び方法を対象とする。

【背景技術】

【0002】

多くの病院は、患者の治療において提供されるサービスに関して、資金提供組織及び／又は保険業者からの支払いの請求を行う。

【0003】

保険又は支払い請求は複雑であり、しばしば不正確である。これにより、請求が保険業者によって拒否される（多大な時間及び労力を浪費する）、又は請求が不完全／不正確であるにもかかわらず認められる（例えば、提供された項目／サービスについて保険が請求されない状況が発生する）のいずれかが発生する。

【0004】

しかし、保険又は支払いの請求の複雑性のために、特にヘルスケア空間において、保険請求における潜在的な欠陥を正確かつ効率的に識別することが可能なシステム及び方法を提供することは、困難な問題を提示する。

【0005】

本明細書における任意の先行技術又は背景情報の参照は、この先行技術又は背景情報が、任意の管轄における共通の一般知識の一部を形成するか、又はこの先行技術が、当業者によって理解され、関連するものと見なされ、かつ／若しくは、他の先行技術と組み合わせることが合理的に予想され得ることを認めるものでも示唆するものでもない。

【発明の概要】

【課題を解決するための手段】

【0006】

添付の特許請求の範囲は、本発明の概要として機能し得る。

【図面の簡単な説明】

【0007】

図面は、以下の通りである。

【図1】本開示の態様による、ネットワーク化環境のブロック図である。

【図2】請求審査システムへの請求の提出で実行される操作を示すフローチャートを提供する。

【図3】請求審査システムへの請求の提出で実行される操作を示すフローチャートを提供する。

【図4】次に請求分析のために使用することができるルールを作成するために実行される動作を示すフローチャートを提供する。

【図5】請求の分析において実行される動作を示すフローチャートを提供する。

【図6】審査システムの例示的なアーキテクチャを示す。

【図7】本開示の様々な実施形態及び／又は特徴が実装され得るコンピューティングシステムのブロック図である。

【図8】請求欠陥通知の例示的な電子メールフォーマットを提供する。

【図9】例示的な評価者ユーザインターフェースを提供する。

【0008】

本発明は様々な改変及び代替的形態が適用可能であるが、特定の実施形態を例示のために図面に示し、詳細に説明する。しかしながら、図面及び詳細な説明は、本発明を開示された特定の形態に限定することを意図するものではないことを理解されたい。添付の特許請求の範囲によって定義される本発明の趣旨及び範囲に該当する全ての修正、同等物、及び代替物を含むことが意図される。

【発明を実施するための形態】

【0009】

本開示の概略の文脈は、請求提出者による保険業者への保険請求の作成及び提出である。参照を容易にするために、請求提出者は、単に請求提出者と称され、保険業者は、請求受信者と称される。

【0010】

本開示は、ヘルスケア分野に焦点を当て、病院によって作成され、評価及び支払いのために健康保険業者に提出される患者のヘルスケアの請求の文脈に焦点を当てている。

【0011】

本開示は、コンピュータ実装請求審査システムを紹介する。以下に詳細に記載されるように、システムは、受信した請求を自動的に審査し、リアルタイムで（又はほぼリアルタイムで）当該請求に関するフィードバックを提供する。このフィードバックに基づいて、請求受信者への請求の実際の提出前に（必要に応じて）提出を改善し、最適化することができる。

【0012】

このようなフィードバックを提供することにより、請求審査システムは、請求提出者（例えば、病院）が収入の減少を抑制し、非効率性を低減し、コストを削減し、病院内の無駄を削減することを支援する。

【0013】

環境の概要
図１は、本開示の実施形態及び特徴が実装される例示的な環境１００を示す。例示的な環境１００は、請求提出者システム１１０（例えば、病院のシステム）と、請求審査システム１２０と、評価者システム１４０とを相互接続する通信ネットワーク１０２を含む。

【0014】

請求提出者システム１１０は、請求提出者によって操作されるコンピュータシステムである。提出者システム１１０は、典型的には、様々なソフトウェアアプリケーションを実行する様々な相互動作システムを含む。しかしながら、本開示に関連して、システム１１０は、審査システムクライアントアプリケーション１１２及び提出者データベースシステム１１４を含む。

【0015】

審査システムクライアントアプリケーション１１２及び提出者データベースシステム１１４は、別個のコンピュータシステム／デバイスに提供されてもよい。例えば、審査システムクライアントアプリケーション１１２は、パーソナルコンピューティングデバイス（例えば、ラップトップコンピュータ、デスクトップコンピュータ、携帯電話、タブレット、又は他のコンピューティングデバイス）、及び別個のコンピューティングシステム（例えば、より大きな病院システム）によってホストされた提出者データベースシステム１１４にインストールされてもよい。この場合、パーソナルコンピューティングデバイスは、例えば、同じネットワーク上にあることによって、ＶＰＮ接続によって、又は他の（典型的にはセキュアな）通信チャネルによって、病院システムに接続して、提出者データベースシステム１１４にアクセスする。

【0016】

処理ユニット（例えば、処理ユニット７０２）によって実行されると、審査システムクライアントアプリケーション１１２は、クライアント側請求審査システム機能を提供するように、クライアントアプリケーションが実行されているコンピュータシステムを構成する。これは、請求審査システム１２０（特に、請求審査システム１２０によって提供されるサーバアプリケーション１２２）と（以下に記載の７１６などの通信インターフェースを使用して）通信することを含む。

【0017】

審査システムクライアントアプリケーション１１２は、様々な形態をとることができる。例えば、審査システムクライアントアプリケーション１１２は、請求審査システム１２０及び提出者システムデータベース１１２のＡＰＩサーバと通信する専用のアプリケーションクライアント、ｈｔｔｐ／ｈｔｔｐｓプロトコルを使用して、請求審査システムウェブサーバと通信するウェブブラウザ（Ｃｈｒｏｍｅ、Ｓａｆａｒｉ、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｆｉｒｅｆｏｘ、若しくは代替的なウェブブラウザなど）、又は請求審査システム１２０と通信するように既存のソフトウェアアプリケーションを構成する提出者システム１１０（例えば、課金システム）の既存のソフトウェアアプリケーションへの拡張／統合モジュールであってもよい。

【0018】

提出者データベースシステム１１４は、（本目的のため）、提出者システム１１０のオペレータによって作成される請求の提出に関連する、提出者システム１１０によって取り込まれ／記憶された情報を記憶する。

【0019】

提出者データベースシステム１１４によって記憶される正確なデータは、特定のコンテキスト及び実装、例えば、提出者システム１１０によって通常取り込まれるデータの種類、及び請求審査システム１２０によって予期／要求されたデータの種類に依存する。例として、提出者データベースシステム１１４によって記憶されるデータは、病院データ、患者識別データ、患者の年齢データ、紹介医師データ、担当医師データ（及びその専門分野）、臨床的状態及び／若しくは臨床コードデータ、臨床診断及び／若しくは臨床診断コードデータ、過去の治療及び／若しくは治療コードデータ、過去の、現在の、かつ計画された薬剤及び投与データ、提案された治療及び／若しくは治療コードデータ、実際の治療及び／若しくは治療コードデータ、使用されたインプラント及び／若しくはインプラントコードデータ、使用された消耗品及び／若しくは消耗品コードデータ、手術時間長さデータ、入院日／時間データ、退院（separation）／退院（discharge）の日／時間データ、滞在日数データ、ＤＲＧコードデータ、臨床記録データ、入院時記録データ、紹介記録データ、又は任意の他のデータを含んでもよい。

【0020】

単一の提出者システム１１０が例示されているが、環境は、典型的には、請求審査システム１２０と相互作用する複数の提出者システム１１０（異なるエンティティによって操作される）を含むであろう。例えば、請求審査システムを使用する各独立した病院は、独自の提出者システム１１０を有するであろう。

【0021】

高レベルでは、請求審査システム１２０は、サーバアプリケーション１２２、分析エンジン１２４、ルール生成エンジン１２６、及びデータベースシステム１２８を含む。

【0022】

請求審査システムサーバアプリケーション１２２は、例えば、審査システムクライアントアプリケーション１１２及び１１４からの要求を受信し、それに応答することによって、サーバ側機能を提供するように、請求審査システム１２０を構成する。サーバアプリケーション１２２は、（ウェブブラウザクライアントと対話するための）ウェブサーバ、又は（専用のアプリケーションクライアントと対話するための）アプリケーションサーバであってもよい。

【0023】

請求審査システム１２０の分析エンジン１２４は、以下に記載されるように、請求分析を行う。一般的に言えば、これは、請求データにアクセスするか、又は請求データを受信すること、及び、データが関連する請求が受諾可能であるか、又は可能性のある欠陥を有するかどうかを判定することを含む。特定の実施形態では、可能性のある欠陥は、潜在的な欠陥（軽微な欠陥とも呼ばれる）又は可能性の高い欠陥（重大な欠陥とも呼ばれる）のいずれかとして分類されてもよい。

【0024】

請求審査システム１２０のルール生成エンジン１２６は、分析エンジン１２４が請求の分析に適用されるルールを生成するように動作する。

【0025】

審査システムデータベースシステム１２８は、請求審査システム１２０によって使用された様々な情報を記憶する。これは、分析のために受信された（この場合、請求データベース１３０に記憶された）請求に関する請求データ、ルール生成エンジン１２６によって生成され、分析エンジン１２４によって使用された（この場合、ルールデータベース１３２に記憶された）ルール、並びに、新規ルールの生成及び検証においてルール生成エンジン１２６によって使用された（この場合、学習データベース１３４に記憶された）訓練データを含む。

【0026】

以下で更に論じるように、審査システム１２０は、提出者システム１１０（例えば、様々な提出者システムへのサービスとしてソフトウェアを提供するクラウド実装）とは独立していてもよい。代替実施形態では、審査システム１２０は、例えば、提出者システム１１０によって維持されているハードウェア上に関連するアプリケーション及びデータベースをインストールすることによって、提出者システム１１０の一部として実装されてもよい。これは、提出者システム（又はそのオペレータ）が、外部的に請求データを通信することを望まない場合に有利であり得る。

【0027】

環境１００は、評価者システム１４０を更に含む。評価者システム１４０は、その上にインストールされた審査システムのクライアントアプリケーション１４２を有するコンピュータ処理システムである。評価者システム１４０はまた、その上にインストールされ／その上で実行される他のアプリケーション、例えばオペレーティングシステムを有する。

【0028】

評価者システム１４０によって（例えば、後述するユニット７０２などの処理ユニットによって）実行されると、審査システムクライアントアプリケーション１４２は、クライアント側審査システム機能を提供するように評価者システム１４０を構成する。審査システムクライアントアプリケーション１４２は、提出者システム１１０のクライアントアプリケーション１１２、又は異なるクライアントアプリケーションと同じであってもよい。しかしながら、以下で更に論じるように、クライアントアプリケーション１４２によって提供される機能は、クライアントアプリケーション１１２によって提供される機能とは異なる。請求評価者によって使用される場合、クライアントアプリケーション１４２は、請求評価で使用されるように評価者システム１４０を構成する。ルール評価者によって使用される場合、クライアントアプリケーション１４２は、ルール評価で使用されるように、評価者システム１４０を構成する。対照的に、クライアントアプリケーション１１２は、請求提出者によって使用するために、提出者システム１１０を構成する。アプリケーション１４２及び１１２が同じアプリケーションである場合、２つのシステムに提供されたユーザ資格情報に基づいて、差異が提供される（提出者ユーザ資格情報は、提出者システムクライアントアプリケーション１１２に提供され、請求評価者又はルール評価者ユーザ資格情報は、レビュワーシステムクライアントアプリケーション１１２に提供される）。

【0029】

環境１００内の様々なシステム間の通信は、通信ネットワーク１０２を介している。通信ネットワークは、ローカルエリアネットワーク、公衆ネットワーク（例えば、インターネット）、又はその両方の組み合わせであってもよい。請求審査システムが提出者システムのオペレータによって維持される場合、審査システムクライアントアプリケーション１１２と審査システムサーバアプリケーション１２２との間の通信は、典型的には、プライベートネットワーク接続、例えば、提出者システム１１０のＬＡＮ又はＶＰＮ接続を介して行われる。

【0030】

環境１００が一例として提供されているが、代替的なシステム環境／アーキテクチャが可能である。

【0031】

請求提出プロセス
このセクションは、一実施形態による請求提出プロセス２００（図２）を説明する。

【0032】

プロセス２００は、患者のケアのエピソード全体にわたって様々なポイントで実行されてもよく、プロセスの出力は、（一般的に言えば）提出された請求の現在の状態が受諾可能であること、（それらの潜在的な欠陥に関するコメント／提案と共に）潜在的な欠陥があること、かつ／又は、（それらの可能性の高い欠陥に関するコメント／提案と共に）可能性の高い欠陥があることの指示である。この出力は、リアルタイム（又はほリアルタイム）に提供されて、提出者に、請求に関するガイダンスを提供する。

【0033】

例えば、請求は、患者の入院についての審査のために提出されてもよく、この場合、プロセスの出力は、生年月日などの患者及び／又は自身の世話人との対面でのディスカッション中に最良に取り込まれる関連情報に関して提出者をガイドする。請求はまた、（又は代替的に）患者のケアのエピソード中の審査のために提出されてもよい。この場合、プロセスの出力は、薬剤履歴、現在の治療、及び供給されたサービスなどの患者のケアのエピソード中に最良に取り込まれる関連情報に関するガイダンスを提供する。請求はまた（又は代替的に）、患者の退院／患者のケアのエピソードの完了の際の、又はその後の審査のために提出されてもよい。この場合、プロセスの出力は、実行された治療の完全な履歴及び提供されたサービスなどの、患者の退院後に最良に取り込まれる関連情報が、取り込まれることを確実にするためのガイダンスを提供する。

【0034】

全体として、請求審査プロセスの出力は、提出者（例えば、病院）が、収入の減少、非効率性、コスト、無駄を低減することを支援することを目的とする。

【0035】

２０２において、請求審査システム１２０は、提出者システム１１０から請求審査要求を受信する。より具体的には、請求審査システム１２０のサーバアプリケーション１２２は、提出者システム１１０の審査システムクライアントアプリケーション１１２から、請求審査要求を受信する。

【0036】

請求審査要求は、請求データに関連付けられる。請求データは、典型的には、提出時に提出者に利用可能であり、特定の患者のケアの特定のエピソードに関連する全てのデータである。

【0037】

請求データは、典型的には、要求と共に／同時に提出者システム１１０から受信されるが、別個に提出／アップロードされてもよい。更に、また後述するように、所与の要求に関する請求データは、（例えば、修正された請求が分析のために提出されるように）経時的に更新されてもよい。

【0038】

請求審査システム１２０に提出され得る特定の請求データ及びそれが提出されるフォーマットは、特定の実装形態に依存する。特定の実施形態では、提出者システム１１０のオペレータが審査のための請求を作成／提出しようとする場合、審査システムクライアントアプリケーション１１２は、要求に含めるために、提出者データベースシステム１１４から関連データを自動的に抽出するように構成される。代替的な実施形態では、審査のための請求を提出することを望む提出者システム１１０のオペレータに、要求された請求データの手動入力のための入力フィールドを有するユーザインターフェース（例えば、ウェブページ又は代替的なインターフェース）が提供される。

【0039】

例として、以下の表Ａは、請求システム１１０から請求審査システム１２０に請求データを通信するための例示的なＪＳＯＮフォーマットを提供する。

【0040】

【表1】

【0041】

代替的な例として、請求データは、以下の表Ｂに示されるものなどの表のフォーマットで請求審査システム１２０に通信されてもよい。

【0042】

【表2】

【0043】

特定の実施形態では、請求審査システム１２０は、受信時に請求審査要求をチェックし、その中に含まれた請求データがフォーマット要件に適合することを確実にする。請求審査要求がエラーを有する場合、請求審査システム１２０は、メッセージを提出者システム１１０に（例えば、アプリケーション１１２又は他の通信チャネル（例えば、電子メール）を介して）返し、エラーを通知する。この場合、請求審査システム１２０は、修正された審査要求が受信されるまで、請求の処理を一時停止／停止する。

【0044】

２０４において、請求審査システム１２０は、２０２で受信された請求審査要求が最初の要求である（すなわち、特定のケアのエピソードに関する初回のデータがシステム１２０に提出された）か、又は後続の要求である（すなわち、特定のケアのエピソードに関するデータが以前に提出されており、第２の／後続の回数の審査が要求されている）かを判定する。

【0045】

２０４での判定は、様々な方法で行われてもよいが、典型的には、その識別子を有する提出が既に受信され、かつ分析されたかどうかを判定するために、提出から識別子を抽出することを含む。識別子は、提出に含まれる１つ又は２つ以上の請求データ項目に基づく。例として、表Ａの請求データを使用すると、識別子は、病院＿名及び入院＿番号データ項目の組み合わせであってもよい。代替例として、再び表Ａの請求データを使用して、識別子は、病院＿名、入院＿番号、手術＿セッション、及び手術＿日データ項目の組み合わせであってもよい。

【0046】

２０４において、請求審査システム１２０が、請求審査要求が最初の要求であると判定した場合、処理は２０６に進む。請求審査要求が後続の要求であると判定された場合、処理は２５０（図３）に進む。

【0047】

２０６において、請求審査システム１２０は、２０２で受信した請求審査要求を最初の要求と判定している。この場合、審査システム１２０は、要求から請求データを抽出して、要求に関する請求審査システム記録を生成する。請求審査システム１２０は、請求審査システム記録を請求データベース１３０に保存する。

【0048】

２０８において、請求審査システム１２０は、請求データを分析する。請求分析については、図４を参照して以下でより詳細に記載する。

【0049】

請求分析プロセスは分析レポートを返す。分析レポートは、識別された任意の潜在的な、又は可能性の高い欠陥に関する欠陥データを含む。潜在的な、又は可能性の高い欠陥が識別されない場合、分析レポートは、（例えば、空であるか、又は請求が受諾可能であることを明示的に報告することによって）このことを示す。欠陥データは、問題が検出されたかどうかに関わらず、対象の請求に関する識別子を、また、問題が検出された場合には、それに関する問題及び／又は推奨の指示を含む。特定の実施形態では、欠陥データは、識別された欠陥をもたらすようにトリガされたルール（複数可）を示す１つ又は２つ以上のルール識別子を更に含む。

【0050】

所与の（可能性の高い又は潜在的な）欠陥は、提出された請求データに含まれているが異常に見える（すなわち、潜在的に含まれるべきではない）特徴／項目に関してもよい。所与の欠陥は、代替的に、提出された請求データから省略された特徴／項目（すなわち、潜在的に含まれるべき特徴／項目）に関してもよい。

【0051】

２１０において、請求審査システム１２０は、（例えば、分析プロセスから戻った分析レポートを２０８で処理することによって）請求が潜在的な／可能性の高い欠陥を有するかどうかを判定する。請求がいずれの欠陥も有しない場合、処理は２１２に進む。そうでなければ、処理は２１６に進む。

【0052】

特定の実施形態では、提出者システム１１０は、提出者システム１１０によって作成された全ての請求に関してブロック変数を維持するように構成されている。ブロック変数は、ブロックが所定の位置にある（それにより、関連付けられた請求が保険業者に提出されることが妨げられる）ことを示す１つの値（例えば、Ｔｒｕｅ）、及び、ブロックが所定の位置にない（その時点で関連付けられた請求は保険業者に提出され得る）ことを示す別の値（例えば、Ｆａｌｓｅ）を有するフラグ又は任意の他の変数によって実装され得る。このような実施形態において、新規請求が作成されるたびに、その請求のブロック変数が真に設定され（すなわち、ブロックが所定の位置にあり）、請求審査システム１２０のみが、ブロック変数を偽に設定させる（すなわち、ブロックをリリースする）ことができる。このような実施形態では、審査システム１２０は、請求が受諾可能であると判定した場合、請求に関するブロック除去メッセージを生成し、（その目的のために提出者システム１１０によって提供されるＡＰＩエンドポイントを使用して）提出者システム１１０に通信する。提出者システム１１０によって受信されると、ブロック除去メッセージは、提出者システム１１０に、ブロック変数を、請求の提出を可能にする値に（すなわち、ブロックが除去されているように）変更させる。

【0053】

請求ブロックが実装されない場合、ステップ２１２は省略される。

【0054】

２１４において、審査システム１２０は、請求受諾可能通知を生成し、これを提出者システム１１０に通信する。これにより、２０２で提出された請求が提出のために受諾可能であること（かつ、使用される場合、請求審査ブロックが除去されたこと）が提出者システム１１０に通知される。次いで、プロセス２００は終了する。一般的に言えば、請求受諾可能通知は、対象の請求が識別されることを可能にする識別情報、及び問題が検出されなかったこと／請求が受諾可能であることの指示を含む。

【0055】

請求受諾可能通知を受信すると、請求は、通常のチャネルごとに保険業者に提出することができる。これは、自動プロセス（すなわち、提出者システム１１０は、請求を自動的に提出するように構成されている）、又は手動（すなわち、提出者システム１１０のオペレータは更なるアクションを講じる必要がある）であってもよい。

【0056】

２１６では、潜在的な、又は可能性の高い欠陥が識別されている。この場合、審査システム１２０は、識別された１つ又は２つ以上の欠陥に関する提案を提供する欠陥通知を生成し、これを提出者システム１１０に通信する。

【0057】

欠陥通知が審査システムクライアントアプリケーション１１２に直接通信される場合、提出者システム１１０は通知を受信し、欠陥通知（又はそこから導出される情報）を表示する欠陥インターフェースを提示する。欠陥インターフェースを介して、提出者システム１１０のオペレータは、欠陥及び関連付けられた情報を閲覧し、請求に変更を行い、かつ／又は欠陥（複数可）に関するコメントを提供することができる。次いで、提出者システム１１０のオペレータは、請求審査システム１２０に（修正され、かつ／又は、提供される場合にはコメントと共に）請求を再提出することができる。

【0058】

一般的に言えば、欠陥通知は、対象の請求が識別されることを可能にする識別情報、欠陥が識別されたことの指示、及びそれらの欠陥に関する情報（例えば、「この手術で複数の弁が使用されたかどうかを見直してください」などの、提案された審査システムアクション）を含む。特定の実施形態では、欠陥に関する情報は、欠陥（複数可）につながるトリガされたルール（複数可）を示す１つ又は２つ以上のルール識別子を更に含んでもよい。

【0059】

以下の表Ｃは、請求審査システム１２０から提出者システム１１０に（又は、具体的には、その上で動作する請求審査クライアントアプリケーション１１２に）請求欠陥情報を通信するための例示的なＪＳＯＮフォーマットを提供する。

【0060】

【表3】

【0061】

請求に関する欠陥通知はまた（又は代替的に）、電子メールによって（例えば、対象の請求審査要求に関連付けられた提出者システム１１０によって提供された電子メールアドレスに電子メールを送信され）、又は代替的な通信チャネルによって通信されてもよい。図８は、問題が検出された、請求に関する欠陥通知の例示的な電子メールフォーマットを提供する。

【0062】

図３を参照すると、２５２において、審査システム１２０は、２０２で受信した請求審査要求が後続の請求審査要求であると判定した。この場合、審査システム１２０は、要求から請求データを抽出し、（例えば、新規／修正された請求データを請求データベース１３０に書き込むことによって）要求のために既に存在する請求審査システム記録に付加する／保存する。

【0063】

２５４において、請求審査システム１２０は、請求データを分析する（図４に関して以下に記載される）。

【0064】

２５６において、請求審査システム１２０は、（例えば、分析プロセスから戻った分析レポートを２５４で処理することによって）請求が潜在的な／可能性の高い欠陥を有するかどうかを、また、そうである場合に、欠陥のタイプを判定する。請求が潜在的な欠陥のみを有すると判定された場合、処理は２５８に進む。請求がいずれかの欠陥を有すると判定された場合、処理は２６２に進む。欠陥がないと請求が判定された場合、処理は２７２に進む。

【0065】

２５８において、審査システム１２０は、請求の後続の審査が潜在的な欠陥のみを識別していると判定した。この場合、審査システム１２０は、識別された全ての潜在的な欠陥に関するコメントが提供されたかどうかを判定する。そうである場合、処理は２７２に進む。そうでない場合、処理は２６０に進む。

【0066】

２６０において、審査システム１２０は、更なる欠陥通知を生成し、これを提出者システム１１０に通信する。欠陥通知の内容は、請求の状態（すなわち、どのように２６０に到達しているか）に依存する。

【0067】

提出者コメントが任意の（２５８によって）潜在的な欠陥、又は（後述する２６２によって）可能性の高い欠陥に関して提供されていない結果として２６０に到達した場合、欠陥通知は、コメントが提供されていない欠陥を示し、提出者システム１１０のオペレータによって追加されるべきこれらの方向を含む。

【0068】

評価者コメントが受信され、（後述する２７０によって）１つ又は２つ以上の可能性の高い欠陥に関連付けられている結果として２６０に到達した場合、欠陥通知は、評価者コメントが追加された可能性の高い欠陥（複数可）、及び提出者システム１１０のオペレータによって見直される評価者コメントを含む。

【0069】

いずれの場合も、審査システム１２０が２６０で欠陥通知を生成し、これを提出者システム１１０に通信すると、プロセス２００が終了する。

【0070】

２６２において、審査システム１２０は、請求の後続の審査が、可能性の高い欠陥を識別していると判定した。この場合、審査システム１２０は、識別された全ての可能性の高い欠陥に関するコメントが提供されたかどうかを判定する。そうでない場合、処理は、２６０（上述）に進む。全ての識別された可能性の高い欠陥についてコメントが提供された場合、処理は２６４に進む。

【0071】

２６４において、審査システム１２０は、評価者入力要求を生成し、これを評価者システム１４０に通信する。

【0072】

評価者入力要求は、対象の請求からのデータ、請求で識別された欠陥（複数可）、及び請求提出者によって提供されたそれらの欠陥に関するコメントを含む。この情報は、評価者システム１４０にインストールされた審査システムクライアントアプリケーション１４２に通信され、評価者システム１４０は、評価者入力要求からの情報を使用して、評価者インターフェースを生成する。評価者インターフェースを介して、評価者は、請求／欠陥／提出者コメントを審査し、評価者入力を提供することができる。評価者入力は、例えば、請求が許可されるべきであることを示す入力、又は（評価者が請求を許可しない場合）、その中で既に識別された請求への評価者コメント／可能性の高い欠陥を提供する入力を含むことができる。

【0073】

例として、図９は、請求を可能にし、そのアクションの理由／コメントを提供するために、評価者によって使用可能な例示的な評価者ユーザインターフェースを提供する。

【0074】

評価者は、請求及び提供された評価者入力を審査すると、評価者インターフェース上で提出制御などを起動させ、評価者システム１４０に、評価者入力を請求審査システム１２０に通信して返す。

【0075】

２６６において、審査システム１２０は、評価者システム１４０から評価者入力を受信する。

【0076】

２６８において、審査システム１２０は、評価者が請求を承認したかどうかを確認するために、評価者入力を処理する。そうである場合、処理は２７２に進む。そうでない場合、処理は２７０に進む。

【0077】

２７０において、評価者入力において受信された評価者コメントは、対象の請求に関連付けられる。次いで、処理は２６０に進み、ここで、審査システム１２０は、上述のように欠陥通知を生成し、かつ通信する。

【0078】

２７２において、請求は、保険業者への提出の準備ができていると判定される。これは、（２５６によって）請求において欠陥が識別されなかった、潜在的な欠陥のみが識別されたが、（２５８によって）全ての潜在的な欠陥に関して、提出者コメントが提供されている、又はこのような欠陥が識別されたが、（２６８によって）請求は、評価者によって承認されたためであり得る。

【0079】

したがって、２７２において、請求審査システム１２０は、（上述の２１２によって）請求に関する請求審査ブロックを除去し、２７４において、（上述の２１４によって）請求受諾可能通知を生成／通信する。次いで、プロセス２００は終了する。

【0080】

請求分析
上述のプロセス２００は、（２０８及び２５４で）請求の分析を含む。このセクションは、一実施形態による請求分析プロセスを説明する。

【0081】

本発明では、分析エンジン１２４によって、請求分析が実行される。分析エンジン１２４は、複数のルールを使用して請求データを分析するルールエンジンである。したがって、分析エンジン１２４の構成及び使用は、２つの一般的な操作セットを含む：ルールが作成されるルール生成プロセス、及び、ルールを使用して請求データを分析するために分析エンジン１２４が動作する分析プロセスを含む。

【0082】

ルール及びルール生成
本実施形態では、請求審査システム１２０によって生成され、かつ使用されるルールは、要求されたルール、論理ルール、及び相関ルールの３つの領域に分類することができる。一般的に言えば、定義されたルールは、前条件（請求における１つ又は２つ以上のデータ項目の存在）及び事後条件（事前前条件が満たされた場合にも存在するべき１つ又は２つ以上のデータ項目）を含む。

【0083】

各種類のルールは、特定の請求に関連する請求データ（例えば、患者のケアのエピソードに関する請求データ）中の特定のデータ項目の存在（又は不在）に基づく。例として、請求データの項目は、提出者データベースシステム１１４によって維持されるものを含んでもよく、これは上述のように、病院データ、患者識別データ、患者の年齢データ、紹介医師データ、担当医師データ（及びその専門分野）、臨床的状態及び／若しくは臨床コードデータ、臨床診断及び／若しくは臨床診断コードデータ、過去の治療及び／又は治療コードデータ、過去の、現在の、かつ計画された薬剤及び投与データ、提案された治療及び／若しくは治療コードデータ、実際の治療及び／若しくは治療コードデータ、使用されたインプラント及び／若しくはインプラントコードデータ、使用された消耗品及び／若しくは消耗品コードデータ、手術時間データ、入院日／時間データ、退院（separation）／退院（discharge）の日／時間データ、滞在日数データ、ＤＲＧコードデータ、臨床記録データ、入院時記録データ、紹介記録データ、並びに又は任意の他のデータ項目などの項目を含んでもよい。

【0084】

一般的に言えば、要求されたルールは、１つ又は２つ以上の特定のデータ項目が、請求データの所与のセット（ルール事前条件）に存在する場合、関連項目もまた、請求データに存在するべきであることを定義する。請求データに関連する項目が存在しない場合、ルールは、提案を生成するように動作する。例えば、見つからない関連項目の包含は、患者のケアのエピソードの一部として／請求に含めるために考慮されるべきである。

【0085】

例として、要求されたルールは、患者の請求データが、単一の冠状動脈ステントが埋め込まれたことを示すデータ項目（例えば、特定の治療コード）を含む場合、請求データはまた、単一の冠状動脈ステントに関するデータ項目を含むべきであることを定義し得る。

【0086】

更なる例として、要求されたルールは、患者のための請求データが、腹腔鏡ステープル留めデバイスの「再装填」が発生したことを示すデータ項目を含む場合、請求データはまた、腹腔鏡ステープリングデバイスに関するデータ項目を含むべきであることを定義し得る。

【0087】

一般的に言えば、論理ルールは、１つ又は２つ以上の特定のデータ項目が、所定のセットの請求データ（ルール事前条件）内に存在する場合、１つ又は２つ以上の定義された論理アクションが、要求されたサービスを患者に効果的に診断する、治療する、又は供給するためにとられなければならないことを定義する。再び、ルールによって定義された論理アクションが請求データに存在しない場合、ルールは、提案を生成するように動作し、例えば、そのアクションは、患者のケアのエピソードの一部として／請求に含めるために考慮されるべきである。

【0088】

例として、論理ルールは、患者のための請求データが、薬剤が尿路感染を治療するために投与されたことを示すデータ項目を含む場合、請求データはまた、尿路感染診断が行われたことを示すデータ項目を含むべきであることを定義し得る。

【0089】

更なる例として、論理ルールは、患者のための請求データが、患者が眼内レンズ及び緑内障医療デバイスを有していたが、緑内障の治療のみがドキュメント化されていることを示すデータ項目を含む場合に、次いで、患者がまた、患者のケアのエピソードの一部として白内障手術を受けたかどうかをチェックするために、請求提出者とチェックするためにクエリが提起されるべきであることを定義し得る。

【0090】

更に別の例として、論理ルールは、患者のための請求データが、両側膝処置が実行されたが、インプラントが単一の膝処置と相関した手術内で使用されたことを示すデータ項目を含む場合に、次いで、単一又は両側の膝処置が患者に対して行われたかどうかを請求提出者とチェックするためにクエリが提起されるべきであることを定義し得る。

【0091】

一般的に言えば、相関ルールは、専門家の臨床若しくは処置知識によって、又はシステム内に保持された履歴データに機械学習技術を使用することによって生成される。相関ルールは、（例えば、患者のケアのエピソードに関連する）請求データのセット内の異常なパターンを識別するために使用される。異常なパターンが識別される場合、相関ルールにより、請求データは更なる審査のためにフラグ付けされ、適切であれば、情報は請求データに追加される。相関ルールがトリガされる場合、特定のアクション又は項目が、患者のケアのエピソードの一部として／請求に含めるために考慮されるべきであることが示唆される。

【0092】

例として、相関ルールは、請求データが、患者が化学療法剤の注入を受けるように予定されていることを示し、入院日／時間及び退院日／時間は、その患者及び他の患者のための過去の化学療法剤注入と相関するが、化学療法剤は、請求データに含まれない場合に動作し得る。この場合、相関ルールは、患者のケアのエピソード中に化学療法剤が使用されたかどうかを見直すために、提出者に対してクエリが提示されることになる。

【0093】

更なる例として、相関ルールは、患者が、ケアのエピソード内で文書化された全単一の膝置換処置のみを受けるが、滞在日数が、単一の膝置換処置がまた、疼痛管理及び理学療法サービスがドキュメント化されている過去の滞在日数に相関する場合に動作し得る。この場合、相関ルールは、患者に疼痛管理及び理学療法サービスが患者に提供されたかどうかをレ見直すために、提出者に対してクエリが提供されることになる。

【0094】

より一般的な例として、相関ルールは、「ＸＸＸ病院にて、ＹＹＹ外科医、及びＺＺＺ手術、次いで、請求はＡ、Ｂ、Ｃ、Ｄを含むべきである」などの形態であってもよい。このような相関ルールは、１つの病院及びその病院内の１人の外科医、及びその病院で外科医が行う１つの手術にのみ適用される。

【0095】

分析エンジン１２４によって使用されるルールは、様々な方法で生成されてもよい。１つの例示的なルール作成プロセス４００は、図４を参照して説明される。

【0096】

４０２において、ルール仮説が生成され、又は定義される。ルール仮説は、どのデータが維持されるかに関して、２つ以上のデータフィールド間の潜在的な関係に基づく。ルール仮説は、ユーザによって想到され、手動で入力されてもよい。ルール仮説はまた、ルール生成エンジン１２６によって自動的に生成されてもよい。ルール仮説は、市場バスケット分析又は任意の他の適切な技術などの技術を使用して、利用可能なデータ（例えば、請求データベース１３０及び／又は学習データベース１３４内）の分析に基づいて自動的に生成され得る。

【0097】

例示として、例示的なルール仮説は、成人男性が単一の膝処置を受けるとき、手術の一部として使用される疼痛管理デバイスを有する場合、成人男性が両側膝処置を受けるとき、手術の一部として使用される疼痛管理デバイスを有する場合、成人女性が単一の膝処置を受けるとき、手術で使用される疼痛管理デバイスを有さない場合、成人女性が両側膝処置を受けるとき、手術で使用される疼痛管理デバイスを有さない場合であってもよい。

【0098】

４０４において、ルール生成エンジン１２６は、４０２で生成されたルール仮説をテストして、請求仮説で識別されたデータフィールド間に十分に強い関係があるかどうかを判定する。４０４における仮説テストは、例えば、統計的方法及び／又は機械学習技術によって、様々な方法で実施され得る。一例として、上の仮説の例を続けると、成人患者の性別と、単一及び両側膝処置における疼痛管理デバイスの使用との間の関係の強度を評価するために、様々な統計的方法を用いてもよい。

【0099】

４０６において、ルール生成エンジン１２６は、請求仮説で識別されたデータフィールドが、（例えば、相関、確率、又はデータポイント間の他の形態の関係に基づいて）十分に強い関係を示すかどうかを判定する。そうである場合、処理は４０８に進む。そうでない場合、プロセス４００は終了する。

【0100】

一例として、データフィールド間の関係が数値的に（例えば、相関係数）で表されると仮定すると、関係が下限閾値未満である場合、請求仮説は拒否され、関係が下限閾値以上であるが、上限閾値未満である場合、仮説が受け入れられ（そして、次のルールは、潜在的な／軽微な欠陥に関連すると考えられる）、関係が上限閾値よりも大きい場合、仮説が承諾される（そして、次のルールは、可能性の高い／重大な欠陥に関連すると考えられる）。特定の閾値は所望に応じて選択されてもよいが、具体的な例として、下限閾値は８０％であり、上限閾値９０％であってもよい。

【0101】

４０８において、仮説に基づくドラフトルールが生成される。このルールは、プログラム的に、又は仮説及び結果を見直す評価者によって生成されてもよい。

【0102】

一例として、上の仮説のうちの１つから生じる自然言語ルールは、以下の文に沿っていてもよい。ＩＦ Ｍａｌｅ ＡＮＤ ＞１８ ｙｅａｒｓ ｏｌｄ （ｉ．ｅ．Ｙｅａｒ ｏｆ‘Ｄａｔｅ ｏｆ Ｓｕｒｇｅｒｙ’－Ｙｅａｒ ｏｆ ｂｉｒｔｈ＝＞ １８）ＡＮＤ ｓｉｎｇｌｅ ＯＲ ｂｉｌａｔｅｒａｌ ｋｎｅｅ ｓｕｒｇｅｒｙ，ＴＨＥＮ ｐａｉｎ ｍａｎａｇｅｍｅｎｔ ｄｅｖｉｃｅ ＳＨＯＵＬＤ ｂｅ ｃｌａｉｍｅｄ．（男性であり＞１８歳（すなわち、「手術日」の年－生年＝＞１８）かつ、単一又は両側膝手術の場合、疼痛管理デバイスを請求するべきである。）この自然言語ルールの表現では、「べきである（Should）」は、ルールが潜在的な／軽微な欠陥に関することを示す。ルールが可能性の高い／重大な欠陥に関連する場合、ルールに伴う提案はより強い言葉になる。例えば、「．．．ＴＨＥＮ ｐａｉｎ ｍａｎａｇｅｍｅｎｔ ｄｅｖｉｃｅ ＭＵＳＴ ｂｅ ｃｌａｉｍｅｄ．」（．．．疼痛管理デバイスを請求しなければならない。）（当然のことながら、重大な欠陥についても、ルールは適用されないことが証明されてもよく、このようなルールの違反にかかわらず、請求は審査後に評価者によって受諾される。）

【0103】

４１０において、ルール生成エンジン１２６は、テストデータセット上でドラフトルールを渡す。本実施例では、テストデータセットは、学習データベース１３４によって維持される。

【0104】

４１１において、評価者は、ルールをテストデータセットに適用して、ルールが維持され／公開され、又は拒絶されるかどうかを判定する結果を評価する。ルールが拒否された処理は終了する。ルールが継続される場合、処理は４１２に続く。

【0105】

４１２において、ルール生成エンジン１２６は、ドラフトルールに対する優先度スコアを生成する。優先度スコアは、様々な要因、例えば、ドラフトルールの適用性を検証するための臨床専門知識の利用可能性、ドラフトルールの財務的影響、ドラフトルールが呼び出される予想頻度、及び他の要因に基づいてもよい。ドラフトルールの優先度スコアは、ドラフトルールがそれらの入力のために評価者に提出される順序（例えば、４１４及び４１６によって）を優先するのを助けるために使用される。

【0106】

４１４において、ルール生成エンジン１２６は、ドラフトルール（及び関連付けられたデータ、例えば、４１０においてテストデータセットにドラフトルールを渡すことによって生じる結果、及び４１２で生成された優先度スコア情報）をルール評価者に通信する。これは様々な形で行うことができる。例えば、ドラフトルール（及び関連付けられたデータ）は、評価者システム１４０にインストールされた審査システムクライアントアプリケーション１４２に通信されてもよい。アプリケーション１４２は、ルール評価者によって使用可能なルール評価インターフェースを生成して、ドラフトルール及び関連付けられたデータを審査し、入力を提供する。入力は、例えば、ドラフトルールを承認する、ドラフトルールを拒否する、又はドラフトルールを修正することができる。

【0107】

４１６において、ルール生成エンジン１２６は、ドラフトルールに関するルール評価者入力を受信し、処理する。

【0108】

４１６において、ルール評価入力がルールが拒否されることを示す場合、プロセス４００は終了する。

【0109】

４１６においてルール評価者入力がルールに対する修正を提供する場合、ルール生成エンジン１２６は、これらの修正を４１８で行い、次いで修正ルールを４１０に戻して、修正ルールをテストデータセット上に渡すことができる。

【0110】

４１６においてルール評価入力がルールを可能にする場合、処理は４２０に進む。ルールの受諾に加えて、評価者はまた、それらのルールのタイプ、例えば、ルールが潜在的な欠陥又は可能性の高い欠陥に関するものであるかどうかを示す。上述したように、特定の実施形態では、ルールが関連する欠陥のタイプ（潜在的又は可能性の高い欠陥）は、ルールのテストされた有効性、例えば、ルールを４０２でテストすることによって判定された関係の強度に基づいて判定される。

【0111】

４２０において、ルール生成エンジン１２６は、ルールを（例えば、ルールデータベース１３２に追加することによって）保存し、それにより、ルールは入力請求要求に適用することができる。次いで、プロセス４００は終了する。

【0112】

請求分析
図５は、請求の分析中に実行される動作（例えば、プロセス２００の２０８及び２５４）を示すフローチャートを提供する。

【0113】

５０２において、分析エンジン１２４は、請求データを受信する、又はそれにアクセスする。これは、例えば、請求データベース１３０からアクセスされてもよい。

【0114】

特定の実施形態では、分析エンジン１２４は、所与の請求要求に潜在的に適用され得るルールをフィルタリングするように構成される。この場合、フィルタリングは５０３で行われる。ルールのフィルタリングが行われない場合、処理は５０２から５０４に直接進む。

【0115】

実施される場合、５０３では、分析エンジンは、１つ又は２つ以上のフィルタ基準に従ってルールのスーパーセット（すなわち、ルールデータベース１３２内の全てのルール）をフィルタリングする。これは、５０４で考慮されるルールのサブセットを生成する。フィルタ基準は、特定のルール又は特定のタイプのルールに関連してもよく、典型的には、部分的に限定されない。例えば、特定の提出者Ａは、潜在的な欠陥ではなく、可能性の高い欠陥について通知されることのみを望無場合がある。この場合、提出者Ａから受信したいずれかの請求審査要求を分析するとき、分析エンジン１２４は、結果として生じるサブセットが、可能性の高い欠陥に関連するルールのみを含むように、ルールをフィルタリングすることになる。

【0116】

５０４において、分析エンジン１２４は、適用可能なルール（例えば、ルールデータベース１３２から）を処理して、任意のルールが請求データに潜在的に適用され得るかどうかを判定する。フィルタリングが５０３で実施される場合、適用可能なルールは、フィルタ処理プロセスから得られるルールのサブセットである。フィルタリングが実行されない場合、適用可能なルールは、ルールのスーパーセット（例えば、ルールデータベース１３２内の全てのルール）である。

【0117】

一般的に言えば、ルール適用性を判定することは、ルール事前条件が満たされているかどうかを判定するために、請求データを評価することを含む。そうである場合、ルールは潜在的に適用されると判定され、そうでない場合、ルールが潜在的に適用されないと判定される。上述の例示的な相関ルール（「ＸＸＸ病院にて、ＹＹＹ外科医、及びＺＺＺ手術、次いで、請求はＡ、Ｂ、Ｃ、Ｄを含むべきである」）を継続すると、このルールが潜在的に適用されるかどうかを判定することは、対象の請求が、ＸＸＸ病院にて、ＹＹＹ外科医、及びＺＺＺ手術（ルール事前条件）を伴うかどうかを判定することを伴う。請求が全てのこれらの事項を含む場合、ルール事前条件が満たされ、ルールは潜在的に適用される。ルールが適用されない場合、ルールは適用されない。

【0118】

１つ又は２つ以上のルールが潜在的に適用されると判定される場合、処理は５０６に進む。ルールが潜在的に適用されない場合、プロセスは終了する。

【0119】

５０６において、分析エンジン１２４は、請求データに潜在的に適用されると判定された次の未処理ルールを選択する。

【0120】

５０８において、分析エンジン１２４は、５０６で選択されたルールを請求データに対してテストする。一般的に言えば、これは、請求データを分析して、ルールに関連付けられた事後条件が請求に存在するかどうかを判定することを含む。事後条件が存在する場合、ルールは適用されない。事後条件が存在しない場合、ルールは適用される。

【0121】

上述の例示的な相関ルール（「ＸＸＸ病院にて、ＹＹＹ外科医、及びＺＺＺ手術、次いで、請求はＡ、Ｂ、Ｃ、Ｄを含むべきである」）を継続すると、このルールが適用されるかどうかを判定することは、対象の請求が、Ａ、Ｂ、Ｃ、及びＤ（すなわち、ルール事後条件）を伴うかどうかを判定することを伴う。請求が既にＡ、Ｂ、Ｃ、及びＤの全てを含む場合、ルールは適用されない（請求に既に含まれているようにＡ、Ｂ、Ｃ、及びＤの追加を提案／要求する必要はない）。あるいは、Ａ、Ｂ、Ｃ、又はＤのいずれかが請求ではない場合、ルールは適用される（この場合、Ａ、Ｂ、Ｃ、及びＤのうちの１つ又は２つ以上が、請求に含めるために提案される必要がある）。

【0122】

ルールを請求データに適用することにより、ルール適用結果が生成される。ルール適用結果は、ルールが適用されないこと、又はルールが適用されることのいずれかを示す。適用結果が、ルールが適用されないことを示す場合、ルール適用から流れる提案を更に含む。すなわち、１つ又は２つ以上の項目は、（ルールが潜在的な／軽微な欠陥又は可能性の高い／重大な欠陥のいずれに関連するかに応じて）、請求に含めるために考慮されるべきである。

【0123】

５１０において、分析エンジン１２４は、現在のルールが請求データに適用されるかどうかを（ルール適用結果から）判定する。そうである場合、処理は５１２に進む。そうでない場合、処理は５１４に進む。

【0124】

５１２において、分析エンジン１２４は、現在のルールが請求データに適用されると判定している。この場合、分析エンジン１２４は、ルール適用結果（又はそれから導出される情報）を分析レポートに付加する。上述の例を続けると、ルールが適用されると判定される場合、そのルールに関連付けられた提案（例えば、１つ又は２つ以上の特定のアクション又は項目が、患者のケアのエピソードの一部として／請求に含めるために考慮されるべきであることの提案）が分析レポートに付加される。次いで、処理は５１４に進む。

【0125】

５１４において、分析エンジンは、テストされていない請求データ（５０４で識別されるような）に潜在的に適用される任意のルールが存在するかどうかを判定する。そうである場合、処理は５０６に戻り、次の未処理ルールがテストのために選択される。

【0126】

５１４において、全ての潜在的に適用可能なルールがテストされた場合、処理は５１６に進む。５１６において、分析エンジン１２４は分析レポートを返し、処理を終了する。

【0127】

例示的な審査システムアーキテクチャ
特定の実施形態では、請求審査システム１２０は、サービスとしての請求審査を提供するクラウドホストシステムである。図６は、クラウド実装のためのマイクロサービスアーキテクチャを有する例示的な審査システム１２０を提供する。特定のクラウドプロバイダとして、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（ＡＷＳ）プラットフォームを使用して、マイクロサービスアーキテクチャを説明する。しかしながら、代替的なクラウドプロバイダ又はオンプレミスホスティングが使用されてもよい。更に、異なる実装は、代替アーキテクチャ、例えば、追加の、より少ない、又は代替のサービスを有するアーキテクチャを使用することができる。

【0128】

アーキテクチャ６００は、請求アップロードサーバ６０４間の入力審査システム要求をルーティングするための負荷バランスサービスを含む。ＡＷＳコンテキストでは、Ａｍａｚｏｎの弾性ロードバランシング（ＥＬＢ）サービスは、ロードバランシングサービスを提供し、外部要求を内部終端にマッピングして、追加のセキュリティ層を提供するように構成される。

【0129】

アーキテクチャ６００は、審査システムのクライアントアプリケーション１１２が審査システムのためにアップロード請求に接続することができる１つ又は２つ以上の請求アップロードサーバ（複数可）６０４を含む。ＡＷＳコンテキストでは、請求アップロードサーバ（複数可）６０４は、すなわち、必要に応じてバーチャルサーバを展開／除去することによって、要求に基づいてサーバ容量をスケーリングすることを可能にする弾性計算クラウド（ＥＣ２）サービスによって提供される。しかしながら、請求アップロードサーバ（複数可）６０４は、今後、サーバレスサービス（例えば、ＡＷＳ Ｌａｍｂｄａ）によって置き換えることができる。

【0130】

アーキテクチャ６００は、ＡＷＳコンテキストにおいて審査システムクライアントアプリケーション１１２から受信した請求に関するデータを記憶するためのストレージサービス６０６を含み、記憶サービス６０６は、Ａｍａｚｏｎ単純記憶サービス（Ｓ３）によって提供される。

【0131】

アーキテクチャ６００は、請求アップロードサーバ（複数可）６０４によって使用されるＡＰＩを維持して、審査システムクライアントアプリケーション１１２と通信するための、管理されたＡＰＩ接続６０８を含む。ＡＷＳコンテキストでは、手動ＡＰＩ接続６０８は、ＡＷＳ ＡＰＩ Ｇａｔｅｗａｙサービスによって提供される。

【0132】

アーキテクチャ６００は、請求審査システム１２０の様々な構成要素を監視するための健康システム監視サービス６１０を含む。ＡＷＳコンテキストでは、監視サービス６１０はＡｍａｚｏｎ ＣｌｏｕｄＷａｔｃｈによって提供される。

【0133】

アーキテクチャ６００は、請求をルーティングするためのコントローラをホストする１つ又は２つ以上の請求ルーティングサーバ６１２を含む。ＡＷＳコンテキストでは、請求ルーティングサーバ（複数可）６１２は、ＥＣ２サービスによって提供される。代替実施形態では、請求ルーティングサーバ（複数可）６１２は、サーバレスサービス（例えば、ＡＷＬ Ｌａｍｂｄａ）によって置き換えられてもよい。

【0134】

アーキテクチャ６００は、電子メールのためのメールサーバ６１４を含み、関連する提出者への審査システム結果を含む。ＡＷＳコンテキストでは、電子メールサービスは、Ａｍａｚｏｎ Ｓｉｍｐｌｅ Ｅｍａｉｌ Ｓｅｒｖｉｃｅ（ＳＥＳ）によって提供されてもよい。

【0135】

アーキテクチャ６００は、請求を分析するための分析エンジン６１６（例えば、ルールエンジン）を含む。ＡＷＳコンテキストでは、分析エンジンはＥＣ２サービスによって提供される。

【0136】

アーキテクチャ６００は、請求分析サーバ（複数可）によって実行される請求分析のデータ及び結果を記憶するための、請求結果データベース６１８を含む。本実施例では、請求結果データベース６１８は、Ａｍａｚｏｎ Ｒｅｌａｔｉｏｎａｌ Ｄａｔａｂａｓｅ Ｓｅｒｖｉｃｅ（ＲＤＳ）によって提供されるリレーショナルデータベースである。

【0137】

アーキテクチャ６００は、請求結果データベース６１８に対して様々な報告機能を提供する報告サービス６２０を含む。例として、報告サービス６２０は、Ｔａｂｌｅａｕ又は同様の製品を使用して提供されてもよい。

【0138】

上記サービスに加えて、セキュリティサービス６２２も提供される。例として、セキュリティサービス６２２は、Ｃｌｏｕｄｆｌａｒｅ又は同様の製品を使用して実装されてもよい。

【0139】

上述の例示的なマイクロサービスアーキテクチャでは、審査システム１２０への請求を提出する提出者のフローは、以下の通りである。
１．提出者は請求を提出する。
２．ＡＰＩキー及びＪＳＯＮメッセージを含む要求は、審査システム１２０に送信される。
３．要求は、ＡＰＩキーを認証するＡＰＩゲインによって受信される
４．認証された場合、要求は審査システムアプリケーションサーバに転送される
５．審査システムアプリケーションサーバは、手術日に基づいて病院の有効期限値及び有効性をチェックする
ａ．任意のフィールドが無効である場合（例えば、請求内のコードが有効日付範囲内にないため）、応答が提出者に通信され、これに通知し、プロセスが完了する。
ｂ．そうでなければ、要求はＣＲＳを通過し続ける。
６．アプリケーションサーバは、要求を分析エンジン６１８に転送する。
７．分析エンジンは、全ての適用可能なルールに対する要求を検証する。
８．ルールエンジンからの応答は、アプリケーションサーバに返送される。
９．アプリケーションサーバは、電子メールサーバに応答を返し、この応答は、最終結果を提出者電子メールアドレス及び／又は提出者システム（例えば、その上で実行されているクライアントアプリケーション）に送信する。

【0140】

ハードウェアの概要
本発明は、必ず１つ又は２つ以上のコンピュータ処理システムを使用して実施される。具体的には、提出者システム１１０の各々、請求審査システム１２０及び評価者システム１４０は、コンピュータ処理システム（又は、一緒に動作している複数のコンピュータ処理システム）である。

【0141】

図７は、コンピュータ処理システム７００の一例のブロック図である。図７に示すシステム７００は、汎用コンピュータ処理システムである。図７は、コンピュータ処理システムの全ての機能的又は物理的構成要素を図示しないことが理解されるであろう。例えば、電源又は電源インターフェースが示されていないが、システム７００は電源を搬送するか、又は電源（又はその両方）への接続のために構成されるかのいずれかである。また、特定のタイプのコンピュータ処理システムは、適切なハードウェア及びアーキテクチャ、並びに本発明の態様を実施するのに好適な代替のコンピュータ処理システムは、追加的なものを有し得ることも理解されよう。図示された構成要素よりも代替的又はより少ない構成要素は、２つ以上の構成要素を組み合わせ、及び／又は構成要素の異なる構成若しくは配置を有する。

【0142】

コンピュータ処理システム７００は、少なくとも１つの処理ユニット７０２を含む。処理ユニット７０２は、単一のコンピュータ処理デバイス（例えば、中央処理ユニット、グラフィック処理ユニット、若しくは他の計算デバイス）であってもよく、又は複数のコンピュータ処理デバイスを含んでもよい。いくつかの例では、全ての処理は、処理ユニット７０２によって実行されるが、他の例では、処理はまた、又は代替的に、システム７００によってアクセス可能かつ使用可能なリモート処理デバイスによって（共有又は専用の方法で）実行されてもよい。

【0143】

通信バス７０４を介して、処理ユニット７０２は、処理システム７００の動作を制御するための命令及び／又はデータを記憶している１つ又は２つ以上の機械可読記憶デバイス（メモリ）デバイスとデータ通信する。この場合、システム７００は、システムメモリ７０６（例えば、ＢＩＯＳ）、揮発性メモリ７０８（例えば、１つ又は２つ以上のＤＲＡＭモジュールなどのランダムアクセスメモリ）、及び不揮発性メモリ７１０（例えば、１つ又は２つ以上のハードディスク又はソリッドステートドライブ）を含む。

【0144】

システム７００はまた、システム７００が様々なデバイス及び／又はネットワークとインターフェースする、７１２によって一般的に示される１つ又は２つ以上のインターフェースを含む。一般的に言えば、他のデバイスは、システム７００と物理的に一体化されてもよく、又は物理的に別個であってもよい。デバイスが、システム７００から物理的に分離される場合、デバイスとシステム７００との間の接続は、有線又は無線のハードウェア及び通信プロトコルを介してもよく、直接又は間接（例えば、ネットワーク化された）接続であってもよい。

【0145】

他のデバイス／ネットワークとの有線接続は、任意の適切な標準又は独自のハードウェア及び接続プロトコルによってもよい。例えば、システム７００は、ＵＳＢ、ＦｉｒｅＷｉｒｅ、ｅＳＡＴＡ、Ｔｈｕｎｄｅｒｂｏｌｔ、イーサネット、ＯＳ／２、並列、直列、ＨＤＭＩ、ＤＶＩ、ＶＧＡ、ＳＣＳＩ、ＡｕｄｉｏＰｏｒｔ、のうちの１つ又は２つ以上によって他のデバイス／通信ネットワークと有線接続するように構成されてもよい。他の有線接続ももちろん可能である。

【0146】

他のデバイス／ネットワークとの無線接続は、同様に、任意の適切な標準又は独自のハードウェア及び通信プロトコルによってもよい。例えば、システム７００は、赤外線、ブルートゥース、Ｗｉ－Ｆｉ、近接場通信（ＮＦＣ）、モバイル通信用のグローバルシステム（ＧＳＭ）、拡張データＧＳＭ環境（ＥＤＧＥ）、ロングタームエボリューション（ＬＴＥ）、広帯域符号分割多元接続（Ｗ－ＣＤＭＡ）、符号分割多元接続（ＣＤＭＡ）のうちの１つ又は２つ以上を使用して、他のデバイス／通信ネットワークと無線接続するように構成されてもよい。当然ながら、他の無線接続も可能である。

【0147】

一般的に言えば、システム７００が接続するデバイスは、有線又は無線手段のいずれによっても、処理ユニット７０２によって処理されるためにデータがシステム７００内に入力され、システム７００によって出力されることを可能にする。例示的なデバイスが以下に記載されるが、全てのコンピュータ処理システムが全ての言及されたデバイスを含むわけではなく、上述したデバイスに追加的かつ代替的なデバイスを使用してもよいことが理解されるであろう。

【0148】

例えば、システム７００は、情報／データがシステム７００内に入力される（受信される）１つ又は２つ以上の入力デバイスを含むか、又はそれに接続してもよい。このような入力デバイスとしては、物理ボタン、英数字入力デバイス（例えば、キーボード）、ポインティングデバイス（例えば、マウス、トラックパッドなど）、タッチスクリーン、タッチスクリーンディスプレイ、マイクロフォン、加速度計、近接センサ、ＧＰＳデバイスなどを挙げることができる。システム７００はまた、システム７００によって制御された１つ又は２つ以上の出力デバイスを含むか、又はそれに接続して情報を出力してもよい。このような出力デバイスは、インジケータ（例えば、ＬＥＤ、ＬＣＤ又は他の光）、ディスプレイ（例えば、ＣＲＴディスプレイ、ＬＣＤディスプレイ、ＬＥＤディスプレイ、プラズマディスプレイ、タッチスクリーンディスプレイ）、スピーカ、振動モジュール、及び他の出力デバイスなどのオーディオ出力デバイスを含むことができる。システム７００はまた、システム７００がデータを読み取り、かつ／又は書き込むことができる、例えばメモリデバイス（ハードドライブ、ソリッドステートドライブ、ディスクドライブ、コンパクトフラッシュカード、ＳＤカードなど）、及び、データを表示（出力）し、タッチ信号（入力）を受信することができるタッチスクリーンディスプレイなどの入力及び出力デバイスの両方として機能し得るデバイスを含んでもよく、又はそれらに接続してもよい。

【0149】

システム７００はまた、通信ネットワーク（例えば、インターネット、ローカルエリアネットワーク、広域ネットワーク、パーソナルホットスポットなど）に接続して、ネットワーク化されたデバイスにデータを通信し、ネットワーク化されたデバイスからデータを受信してもよく、それ自体は他のコンピュータ処理システムであってもよい。

【0150】

システム７００は、非限定的な例として、デスクトップコンピュータ、ラップトップコンピュータ、ネットブックコンピュータ、タブレットコンピュータ、スマートフォン、携帯情報端末（ＰＤＡ）、携帯電話、ウェブアプライアンスなどの任意の好適なコンピュータ処理システムであってもよいことが理解されるであろう。典型的には、システム７００は、少なくともユーザ入力及び出力デバイス７１４、並びに（システムがネットワーク化される場合）、ネットワーク１０２と通信するための通信インターフェース７１６を含む。システム７００が含むか又は接続するデバイスの数及び特定の種類は、特定のタイプのシステム７００に依存する。例えば、システム７００がデスクトップコンピュータである場合、システム７００は、典型的には、（少なくとも）キーボード、ポインティングデバイス（例えば、マウス）、ディスプレイデバイス（例えば、ＬＣＤディスプレイ）などの物理的に別個のデバイスに接続する。あるいは、システム７００がラップトップコンピュータである場合、システム７００は、典型的には、（物理的に統合された方法で）キーボード、ポインティングデバイス、ディスプレイデバイス、及び音声出力デバイスを含む。更に別の方法としては、システム７００がタブレットデバイス又はスマートフォンである場合、典型的には、タッチスクリーンディスプレイ（入力手段及びディスプレイ出力手段の両方を提供する）、音声出力デバイス、及び１つ又は２つ以上の物理ボタンを含む。

【0151】

システム７００は、ソフトウェア（例えば、コンピュータ可読命令及びデータ）を記憶しているか、又はそれにアクセスし、ソフトウェアは、処理ユニット７０２によって処理されると、データを受信し、処理し、かつ出力するようにシステム７００を構成する。このような命令及びデータは、典型的には、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ ＯＳＸ、Ａｐｐｌｅ ＩＯＳ、Ａｎｄｒｏｉｄ、Ｕｎｉｘ、又はＬｉｎｕｘなどのオペレーティングシステムを含む。

【0152】

システム７００はまた、ソフトウェアに記憶するか、又はそれにアクセスし、ソフトウェアは、処理ユニット７０２によって処理されると、本明細書に記載される実施形態によって、様々なコンピュータ実装プロセス／方法を実行するようにシステム７００を構成する。このようなソフトウェアの例としては、提出者及び評価者システム１１０及び１４０にそれぞれインストールされた審査システムクライアントアプリケーション１１２及び１４２が挙げられる。上記の実施例では、審査システムの各サービスもソフトウェアによって実装される。一部の場合には、所与のコンピュータ実装方法の一部又は全ては、システム７００自体によって実行されるが、他の場合には、処理は、システム７００とデータ通信する他のデバイスによって実行されてもよいことが理解されるであろう。

【0153】

命令及びデータは、システム７００にアクセス可能な非一過性機械可読媒体上に記憶される。例えば、命令及びデータは、非一過性メモリ７１０に記憶されてもよい。命令は、（例えば）有線又は無線ネットワーク接続によって有効化された送信チャネル内のデータ信号を介してシステム７００に送信／受信されてもよい。

【0154】

前述の明細書において、本発明の実施形態は、実装形態ごとに異なり得る多数の具体的な詳細を参照して説明されてきた。したがって、本発明たらしめるもの、また、本出願人が本発明であることを意図するものに関する唯一及び排他的な指示は、任意の後続の補正を含むこのような特許請求の範囲が発行される特定の形態にある、本出願から発行される特許請求の範囲のセットである。特許請求の範囲に含まれる本明細書に明示的に記載される任意の定義は、特許請求の範囲で使用されるようなこのような用語の意味を支配するものとする。したがって、特許請求の範囲に明示的に記載されていない要素、特性、特徴、利点、又は属性は、任意の方法でこのような請求項の範囲を制限するべきである。したがって、本明細書及び図面は、制限的な意味ではなく例示的なものと見なされるべきである。

【0155】

本明細書で使用するとき、用語「含む（include）」及び「備える（comprise）」（並びに、「含む（including）」、「含む（includes）」、「備える（comprising）」、「備える（comprises）」、「備える（comprised）」などのそれら用語の変形例）は、包括的であることを意図され、更なる特徴、構成要素、整数又はステップを除外することを意図するものではない。

【0156】

本開示の様々な特徴は、フローチャートを使用して説明されている。所与のフローチャートステップの機能／処理は、様々な異なる方法で、様々な異なるシステム又はシステムモジュールによって潜在的に実行され得る。更に、所与のフローチャートステップを複数のステップに分割することができ、かつ／又は複数のフローチャートステップを単一のステップに組み合わせることができる。更に、ステップの順序は、本開示の範囲から逸脱することなく変更することができる。

【0157】

本明細書に開示され、かつ定義された実施形態は、テキスト又は図面から言及され、又は明らかな個々の特徴のうちの２つ以上の全ての代替的な組み合わせに及ぶことが理解されるであろう。これらの異なる組み合わせの全ては、実施形態の様々な代替的態様を構成する。

【0158】

〔実施の態様〕
（１） コンピュータ実装方法であって、
請求審査要求を提出者システムから受信することであって、前記請求審査要求が請求に関する請求データを含む、受信することと、
１つ又は２つ以上の欠陥が前記請求に存在するかどうかを判定するために、前記請求データを分析することと、
前記請求データに欠陥が存在しないと判定することに応じて、請求リリースメッセージを前記提出者システムに通信することであって、前記請求リリースメッセージが、前記提出者システムによって前記請求に関して維持されている請求ブロックをリリースさせる、通信することと、を含む、コンピュータ実装方法。
（２） １つ又は２つ以上の欠陥が前記請求データに存在すると判定することに応じて、
前記請求で識別された前記１つ又は２つ以上の欠陥に関する情報、及び、各欠陥に関して、提案された見直しアクションを含む欠陥通知を生成することと、
前記欠陥通知を前記提出者又は前記提出者システムに通信することと、を更に含む、実施態様１に記載のコンピュータ実装方法。
（３） 前記請求に関する更なる請求審査要求を前記提出者システムから受信することであって、前記更なる請求審査要求が、前記請求に関する更なる請求データを含み、前記更なる請求データが、追加の請求データ、修正された請求データ、コメントのうちの１つ又は２つ以上を含む、受信することと、
前記請求に何らかの欠陥が存在するかどうかを判定するために、少なくとも前記更なる請求データを分析することと、を更に含む、実施態様２に記載のコンピュータ実装方法。
（４） 前記更なる請求データに欠陥が存在しないと判定することに応じて、
請求リリースメッセージを前記提出者システムに通信することであって、前記請求リリースメッセージが、前記提出者システムによって前記請求に関して維持されている請求ブロックをリリースさせる、通信することを更に含む、実施態様３に記載のコンピュータ実装方法。
（５） １つ又は２つ以上の欠陥が前記更なる請求データに存在すると判定することに応じて、
前記１つ又は２つ以上の欠陥が全て軽微な欠陥であると判定することと、
前記１つ又は２つ以上の欠陥の全てが軽微な欠陥であると判定することに応じて、前記１つ又は２つ以上の欠陥の全てに関するコメントが前記提出者システムから受信されたと判定することと、
前記１つ又は２つ以上の欠陥の全てに関するコメントが前記提出者システムから受信されたと判定することに応じて、請求リリースメッセージを前記提出者システムに通信することであって、前記請求リリースメッセージが、前記提出者システムによって前記請求に関して維持されている請求ブロックをリリースさせる、通信することと、を更に含む、実施態様３に記載のコンピュータ実装方法。

【0159】

（６） １つ又は２つ以上の欠陥が前記更なる請求データに存在すると判定することに応じて、
１つ又は２つ以上の欠陥に関するコメントが前記提出者システムから受信されていないと判定することと、
１つ又は２つ以上の欠陥に関するコメントが前記提出者システムから受信されていないと判定することに応じて、
前記請求で識別された前記１つ又は２つ以上の欠陥に関する情報、及び、各欠陥に関して、提案された見直しアクションを含む更なる欠陥通知を生成することと、
前記更なる欠陥通知を前記提出者システムに通信することと、を更に含む、実施態様３に記載のコンピュータ実装方法。
（７） １つ又は２つ以上の欠陥が前記更なる請求データに存在すると判定することに応じて、
前記１つ又は２つ以上の欠陥が重大な欠陥を含むと判定することと、
前記１つ又は２つ以上の欠陥が重大な欠陥を含むと判定することに応じて、全ての重大な欠陥に関するコメントが前記提出者システムから受信されたと判定することと、
全ての重大な欠陥に関するコメントが前記提出者システムから受信されたと判定することに応じて、
評価者入力要求を生成することと、
前記評価者入力要求を評価者システムに通信することと、を更に含む、実施態様３に記載のコンピュータ実装方法。
（８） 前記評価者システムから、評価者入力を受信することと、
前記評価者入力が前記請求が許可されるべきであることを示していると判定することと、
前記評価者入力は前記請求が許可されるべきであることを示していると判定することに応じて、請求リリースメッセージを前記提出者システムに通信することであって、前記請求リリースメッセージが、前記提出者システムによって前記請求に関して維持されている請求ブロックをリリースさせる、通信することと、を更に含む、実施態様７に記載のコンピュータ実装方法。
（９） １つ又は２つ以上の欠陥が前記請求に存在するかどうかを判定するために、請求データを分析することが、
前記請求データに潜在的に適用可能な１つ又は２つ以上のルールを判定することと、
前記請求データに潜在的に適用可能であると判定された各ルールについて、
前記ルールが実際に適用可能かどうかを判定するために、前記ルールを前記請求データに適用することと、
前記ルールが実際に適用可能である場合、前記ルールと関連付けられた情報を分析レポートに付加することと、
前記分析レポートを返すことと、を含む、実施態様１～８のいずれかに記載のコンピュータ実装方法。
（１０） 請求審査システムであって、
プロセッサと、
通信インターフェースと、
命令のシーケンスを記憶している非一時的コンピュータ可読記憶媒体であって、前記命令が、前記プロセッサによって実行されると、前記プロセッサに、実施態様１～９のいずれかに記載のコンピュータ実装方法を実行させる、非一時的コンピュータ可読記憶媒体と、を備える、請求審査システム。

【0160】

（１１） 命令のシーケンスを記憶している非一時的コンピュータ可読記憶媒体であって、前記命令が、コンピュータプロセッサによって実行されると、前記プロセッサに、実施態様１～９のいずれかに記載のコンピュータ実装方法を実行させる、非一時的コンピュータ可読記憶媒体。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【国際調査報告】