収益サイクル管理用データテンプレート
収益サイクル管理用データテンプレート
- 収集を推奨する属性
- プロセスディスカバリーで追跡すべき主要なアクティビティ
- R1 RCMからの詳細な抽出手順
収益サイクル管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 収益サイクルのプロセス内で、ある時点に発生した特定の業務イベントまたはタスクの名称です。 | ||
| 説明 この属性は、特定のBilling Eventにおける収益サイクル管理プロセスの1つのステップまたはマイルストーンを表します。アクティビティには、「料金取得」、「請求提出」、「支払計上」など、実行された作業が記録されます。 アクティビティの順序を分析することは、プロセスマイニングの中心です。実際のプロセスフローを発見し、アクティビティの開始までに時間がかかるボトルネックを特定できます。また、「請求拒否」の後に「拒否再処理開始」が続くような、不要な繰り返し作業のループも検出できます。 重要な理由 プロセス内のステップを定義し、プロセスマップの可視化、遷移時間の計算、プロセス逸脱や再作業の特定を可能にします。 入手先 通常、各種R1 RCMモジュールのイベントログ、ステータス変更記録、またはトランザクションコードから取得されます。技術コードを業務で分かりやすい名称に対応付ける必要がある場合があります。 例 チャージ取得完了請求の送信支払者による審査結果の受信入金計上アカウントクローズ | |||
| イベント時刻 EventTime | 特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプです。 | ||
| 説明 Event Timeは、アクティビティがシステムに記録された正確な日付と時刻を示します。この時間情報は、時間軸に沿ってプロセスを理解するための基礎となります。 プロセスマイニングでは、このタイムスタンプを使ってイベントを時系列に並べ、アクティビティ間の所要時間を計算します。これにより、サイクルタイム、処理時間、待機時間などの主要指標を算出できます。これらの指標は、ボトルネックの特定と効率性の測定に欠かせません。 重要な理由 このタイムスタンプは、サイクルタイムの計算、ボトルネックの特定、SLAに対するプロセスパフォーマンスの監視など、時間に関するすべての分析の基盤となります。 入手先 通常、R1 RCMの各トランザクションまたはステータス変更記録に関連付けられた「作成日」、「タイムスタンプ」、「最終更新日」などの項目として記録されています。 例 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| 請求イベント BillingEvent | 単一の請求対象サービスまたは項目を識別する一意の識別子であり、収益サイクル全体を追跡するための主要なケース識別子です。 | ||
| 説明 Billing Event IDは、料金が発生するサービスまたは製品の提供を1件ごとに識別します。サービスの提供と料金取得から、請求提出、支払計上、最終的なアカウントクローズまで、関連するすべてのアクティビティをつなぐ中心的な識別子です。 プロセスマイニングでは、各Billing Eventのライフサイクルを分析することで、収益サイクルを最初から最後まで把握できます。1件の料金の全過程を追跡し、よくある経路を特定し、主要なマイルストーン間のサイクルタイムを測定するとともに、遅延や収益漏れにつながる差異を把握するために使われます。 重要な理由 この識別子は、関連するすべてのアクティビティを1つのケースにまとめるために欠かせません。請求対象イベントごとに、収益サイクルを正確かつ完全に分析できます。 入手先 これは、患者の受診、料金、請求、支払いに関連する各種テーブルを結び付ける主キーです。具体的な項目についてはR1 RCMのドキュメントを確認してください。多くの場合、受診または請求の識別子に関連付けられています。 例 BE-2023-0012345BE-2023-0054321BE-2024-0098765 | |||
| ソースシステム SourceSystem | イベントデータを抽出した記録元のシステムです。 | ||
| 説明 この属性は、特定のイベントのデータを生成したソースアプリケーションまたはモジュールを識別します。医療のように複雑な環境では、EMR、請求モジュール、請求クリアリングハウス、回収プラットフォームなど、複数のシステムからデータが届く場合があります。 ソースシステムを把握することは、データ検証や、特定のシステムに起因するプロセスの差異を分析するうえで重要です。データの不整合を調査し、プロセスを支える技術環境を理解する際にも役立ちます。 重要な理由 データの出所を特定します。データガバナンスや検証、エンドツーエンドのプロセスにおける各システムの連携を理解するために重要です。 入手先 通常、データ抽出時に追加する固定値で、データの出所となるシステム（例：「R1 RCM」）を示します。 例 R1 RCMCernerEpic | |||
| 最終データ更新日時 LastDataUpdate | ソースシステムからデータを更新または抽出した最新の時刻を示すタイムスタンプです。 | ||
| 説明 この属性は、プロセスマイニング分析用のデータが最後に更新された時刻を示します。分析対象データの鮮度を把握するための情報です。 レポートやダッシュボードでは、プロセスに関する分析結果がどの時点の情報なのかを利用者が確認できます。データの適時性に関する認識をそろえ、把握した期間に基づいて意思決定できるようにします。 重要な理由 データの鮮度を把握するための重要な情報を提供し、分析担当者や関係者がプロセス分析結果の更新状況を確認できるようにします。 入手先 通常、データの抽出、変換、ロード（ETL）処理中に生成され、データセット全体に付与されます。 例 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| 担当ユーザー AssignedUser | アクティビティを実行した従業員のユーザーIDまたは氏名です。 | ||
| 説明 この属性は、プロセス内の特定のタスクを実行した担当者を識別します。請求を作成した請求担当者、拒否案件を再処理した分析担当者、支払いを計上した専門担当者などが該当します。 ユーザー別に分析すると、業務量の分布、個人のパフォーマンス、トレーニングの必要性を把握できます。処理が速いユーザーやエラー率が高いユーザーを特定し、対象を絞った管理やプロセス改善につなげられます。 重要な理由 チームおよび個人のパフォーマンス、業務量の分布を分析し、トレーニングの機会やユーザー固有のプロセス逸脱を特定できます。 入手先 通常、R1 RCMのトランザクションログにある「UserID」、「Processor」、「UpdatedBy」などの項目として記録されています。 例 jdoeasmithp.jonesBOT_RPA01 | |||
| 支払者名 PayerName | 支払いを担う保険会社、政府機関、または患者の名称です。 | ||
| 説明 この属性は、請求の主な支払者を識別します。Aetnaなどの民間保険会社、Medicareなどの公的支払者、または自己負担分を支払う患者が該当します。 支払者別のプロセス分析は、収益サイクル管理の基本です。支払者によって、拒否率、支払サイクルの長さ、提出要件の複雑さが異なることがあります。こうした情報をもとに、支払者ごとの傾向に合わせてプロセスやリソースを調整できます。 重要な理由 支払者別にプロセスを分類し、支払者固有の遅延、拒否パターン、支払傾向を特定できます。収益の最適化に欠かせない分析です。 入手先 R1 RCMで請求に関連付けられた患者の保険情報または属性情報に記録されています。 例 MedicareUnitedHealthcareBlue Cross Blue ShieldAetna自己負担 | |||
| 請求ステータス InvoiceStatus | ライフサイクル上の請求書または請求の現在のステータスです。 | ||
| 説明 この属性は、請求イベントの最後に確認された状態を示します。「提出済み」、「支払済み」、「拒否」、「回収中」などが該当します。特定の時点で請求書がプロセスのどこにあるかを把握できます。 請求ステータスは、滞留期間レポートの作成や売掛金の状況監視に欠かせません。プロセスマイニングでは、特定の状態で滞留しているケースを絞り込んだり、「支払済み」と「拒否」の請求経路を比較したりできます。 重要な理由 各ケースの現在の状態を把握でき、滞留期間レポートの作成や、異なるプロセス経路の最終結果の分析に役立ちます。 入手先 通常、R1 RCMの主要な請求レコードまたはアカウントレコードにあるステータス項目です。 例 提出待ち支払者へ提出済み支払拒否全額支払い済み回収中 | |||
| 請求拒否理由コード DenialReasonCode | 請求が拒否された理由を支払者が示す標準コードです。 | ||
| 説明 支払者が請求を拒否すると、判断理由としてCARC（Claim Adjustment Reason Code）などの理由コードを提示します。これらのコードは標準化されており、「サービス対象外」や「重複請求」などの問題を示します。 この属性は、拒否管理において非常に重要です。拒否理由コードごとの発生頻度を分析すると、患者の資格、コーディングエラー、医学的必要性の不足など、拒否の根本原因を特定して対処できます。再作業を減らし、入金を早める取り組みに直接つながります。 重要な理由 請求が拒否された具体的な理由を示し、将来の拒否を減らし、再作業を抑え、初回提出時の支払率を高めるための根本原因分析を可能にします。 入手先 支払者から電子支払通知（ERAまたは835ファイル）で受信し、R1 RCMの請求管理モジュールに保存されます。 例 CO-16：審査に必要な情報が請求またはサービスに不足しています。PR-97：このサービスの給付は、別のサービスに対する支払いまたは許容額に含まれています。CO-22：給付調整により、この医療費は別の支払者が負担する可能性があります。OA-18：請求またはサービスが完全に重複しています。 | |||
| 請求部門 BillingDepartment | アクティビティを実行する部門または機能チームです。 | ||
| 説明 この属性は、「料金入力」、「請求提出」、「拒否管理」など、特定のプロセスステップを実行した組織単位を示します。異なるチーム間でどのように業務が引き継がれているかを把握できます。 部門ごとの処理量を分析し、部門をまたぐボトルネックを特定するうえで重要です。部門でプロセスマップを絞り込むと、引き継ぎがスムーズな箇所と遅延が発生する箇所を確認でき、リソース配分や組織のプロセス改善に役立ちます。 重要な理由 組織単位ごとのプロセスパフォーマンスを分析し、チーム固有のボトルネック、リソース不足、優れた運用方法を特定できます。 入手先 R1 RCMのユーザープロファイルから取得するか、トランザクションデータの「Department Code」として保存されます。 例 請求情報の取得請求管理支払拒否・異議申立て入金消込 | |||
| 請求金額 InvoiceAmount | 請求書または請求に含まれる料金の合計金額です。 | ||
| 説明 この属性は、特定のBilling Eventで提供したサービスに対する請求総額を表します。請求から見込まれる収益を示す値です。 請求金額の分析は、財務プロセスマイニングに欠かせません。高額な請求を優先し、プロセスの遅延や拒否が財務に与える影響を把握し、金額に基づいてプロセスを分類できます。たとえば、一定額を超える請求だけが、より手作業の多い別のプロセス経路をたどっていることが分かる場合があります。 重要な理由 プロセスに財務面の情報を加え、プロセスの差異が収益に与える影響を分析できます。また、改善対象として高額なケースを優先する際にも役立ちます。 入手先 R1 RCMの主要な請求または請求書ヘッダーテーブルにあり、通常は「TotalBilledAmount」などの名称が付いています。 例 150.002500.7585.5012000.00 | |||
| サービスから支払いまでのサイクルタイム ServiceToPaymentCycleTime | サービスを提供してから最終的に支払いを計上するまでの合計所要時間です。 | ||
| 説明 この指標は、1件のBilling Eventにおける収益サイクルのエンドツーエンドの所要時間を測定します。提供したサービスを現金に変えるまでに組織が要する総時間を表します。 財務の健全性を示す重要なKPIです。この所要時間を分析すると、プロセスを大幅に短縮できる領域を特定できます。「請求までの時間」や「支払いまでの時間」などにサイクルタイムを分解すれば、キャッシュフロー改善の最大の機会を見つけられます。 重要な理由 キャッシュ化サイクル全体の効率を測定する重要な上位KPIであり、組織のキャッシュフローに直接影響します。 入手先 計算によって求める指標です。特定のBilling Eventについて、「サービス提供」アクティビティのタイムスタンプから「支払計上」アクティビティのタイムスタンプまでの時間差を示します。 例 35日8時間92日4時間15日12時間 | |||
| サービスコード ServiceCode | 提供した特定のサービスまたは処置に対する請求コードです。CPTコードやHCPCSコードなどがあります。 | ||
| 説明 CPT（Current Procedural Terminology）コードなどのサービスコードは、医療、外科、診断の処置やサービスを支払者に報告し、償還を受けるために使う標準化された医療コードです。 サービスコード別にプロセスを分析すると、特定の医療行為に関する請求上の問題を特定できます。拒否が多い処置、支払サイクルが長い処置、再作業が多い処置を把握し、コーディングや請求業務を対象を絞って改善できます。 重要な理由 提供したサービスの種類に基づいてプロセスを分析できます。特定の処置に関連する拒否パターンや支払遅延を特定するための重要な情報です。 入手先 R1 RCM内の各料金または請求の明細レベルに記録されています。 例 992139928573560 | |||
| 再作業かどうか IsRework | 拒否された請求の再提出など、再作業ループの一部であるアクティビティを識別する計算フラグです。 | ||
| 説明 この属性は通常、プロセスマイニング分析中に計算される真偽値フラグです。アクティビティが前のステップの繰り返しである場合や、エラーの訂正を示す一連の流れに含まれる場合に「true」になります。たとえば、「請求拒否」の後に続くアクティビティが該当します。 再作業の特定は、プロセスマイニングの強みの1つです。プロセス内で無駄になっている作業、時間、リソースを定量化できます。再作業を示すことで、その原因となるエラーを未然に防ぐ改善に集中でき、大幅な効率向上につながります。 重要な理由 請求拒否などの再作業の頻度と影響を定量化し、非効率や無駄な作業を減らすための対象を絞った分析ができます。 入手先 ソースシステムの項目ではありません。「請求提出」アクティビティが同じケースで複数回発生したことを検出するなど、アクティビティの順序に基づいてプロセスマイニングツールが計算します。 例 truefalse | |||
| 回収結果 CollectionOutcome | 未収残高に対する回収活動の最終結果です。 | ||
| 説明 この属性は、延滞アカウントから支払いを回収するための対応結果を示します。「全額支払済み」、「和解済み」、「貸倒金処理」、「未解決」などがあります。 回収結果を追跡することは、回収プロセスの有効性を評価するうえで欠かせません。どのアクティビティがどの結果につながるのかを分析することで、回収戦略を改善し、回収率を高め、回収を終了して残高を償却するタイミングを適切に判断できます。この分析は、Collection Activity Performanceダッシュボードを支えます。 重要な理由 延滞アカウントの最終的な解決状況を追跡し、回収プロセスの有効性を測定します。回収戦略の改善にも役立ちます。 入手先 通常、患者アカウントのステータス項目、またはR1 RCM内の専用回収モジュールに記録されています。 例 全額支払い済み減額で精算済み外部機関へ送付済み貸倒損失として償却済み | |||
| 患者ID PatientId | サービスを受けた患者を識別する一意の識別子です。 | ||
| 説明 この属性は、医療システム内で患者に割り当てられた一意のIDです。Medical Record Number（MRN）と呼ばれることもあります。 個々の患者の診療そのものを分析対象とするのではなく、患者IDを使って、同じ患者に繰り返し発生する請求上の問題を時系列で分析できます。他の患者データと関連付ければ、患者の属性や履歴でプロセスを分類し、特定の患者グループに影響する組織的な問題を見つけることもできます。 重要な理由 患者単位で請求イベントを分析し、複数回の受診にわたって特定の患者に繰り返し発生する問題やパターンを特定できます。 入手先 R1 RCMで各受診および請求に関連付けられる、患者属性データの中核となる識別子です。 例 MRN837262MRN937281MRN103847 | |||
| 自動処理かどうか IsAutomated | アクティビティを自動システムが実行したか、人が実行したかを示すフラグです。 | ||
| 説明 この真偽値属性は、請求提出用のRPAボットなどのソフトウェア自動化によって実行されたタスクと、従業員が手動で実行したタスクを区別します。 この属性を分析すると、自動化施策の効果と影響を把握できます。自動処理と手動処理の速度、コスト、エラー率を比較し、新たな自動化の機会を特定するとともに、既存ボットの投資対効果を測定できます。 重要な理由 人が実行したアクティビティとシステムが実行したアクティビティを区別し、自動化がプロセスの効率、コスト、品質に与える影響を測定できます。 入手先 「AssignedUser」項目から取得できます。特定のユーザーIDをボット用に予約している場合（例：「BOT_RPA01」）が該当します。自動トランザクションを示す専用項目を備えたシステムもあります。 例 truefalse | |||
| 調整理由 AdjustmentReason | 財務調整を行った理由です。「契約上の減額」や「貸倒金償却」などがあります。 | ||
| 説明 この属性は、アカウントに財務調整を行った理由を示します。理由は、調整の種類を分類する標準コードまたは説明文であることがよくあります。 調整理由を分析すると、収益漏れの根本原因を診断できます。たとえば、「少額残高償却」が頻繁に発生していれば、少額債権の回収プロセスが非効率である可能性があります。一方、「契約上の減額」が多い場合は、支払者との契約交渉に伴う想定内の処理である可能性があります。この分析は、Billing Adjustments & Compliance Auditダッシュボードを支えます。 重要な理由 収益調整が行われた理由を明らかにし、契約上の問題、請求エラー、回収失敗など、収益損失の根本原因を特定できます。 入手先 通常、R1 RCMでAdjustmentAmountと同じトランザクションレコードにあるコード項目またはテキスト項目です。 例 契約上の控除額貸倒金償却少額残高の償却請求エラーの訂正 | |||
| 調整金額 AdjustmentAmount | アカウント残高に対して行った調整の金額です。 | ||
| 説明 この属性は、初回請求後に患者のアカウントへ行った財務上の調整額を記録します。調整には、契約上の減額、償却、訂正などがあり、金額がプラスになる場合もマイナスになる場合もあります。 調整金額を追跡することは、収益の正確性を把握するうえで重要です。マイナス調整が多い場合、料金取得の誤りや回収不能債権などによる収益漏れが疑われます。このデータを分析すると、請求エラーや回収業務の非効率が財務に与える影響を特定できます。 重要な理由 収益漏れと財務上の訂正を金額で把握し、請求の不正確さ、契約上の義務、貸倒金が与える金銭的影響を特定できます。 入手先 R1 RCMのアカウント調整または支払計上に関連するトランザクションログに記録されています。 例 -50.2520.00-1200.00 | |||
収益サイクル管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| アカウントクローズ | 請求イベントが残高ゼロの状態で完全に解決され、アカウントが正式にクローズされます。これは、対象となる受診に関する収益サイクルが正常に完了したことを示します。 | ||
| 重要な理由 これは、プロセスにおける主要な正常終了イベントです。アカウントクローズまでのサイクルタイムを測定することで、管理業務が効率的に完了し、記録が確定されていることを確認できます。 入手先 アカウント残高がゼロになり、最終ステータスとして「クローズ」または「全額支払済み」が適用された時点で、このイベントが推定されます。タイムスタンプには、残高をゼロにした最後の財務トランザクションの時刻が使われます。 取得 アカウント残高がゼロになり、「クローズ」ステータスと最終アクティビティのタイムスタンプが適用された時点で推定されます。 イベントタイプ inferred | |||
| サービス提供完了 | 患者に対する請求対象のサービスまたは処置が完了した時点を示します。このイベントは通常、臨床システムまたはスケジューリングシステムから取得され、収益サイクルの起点になります。 | ||
| 重要な理由 サービス提供から支払いまでのサイクルタイムKPIの起点です。このイベントからの所要時間を分析することで、収益サイクルの前工程における遅延を特定できます。 入手先 通常は、R1 RCMと連携した電子健康記録（EHR）または診療所管理システムから取得します。患者記録の「サービス日」または「処置完了」のタイムスタンプから推定することもあります。 取得 患者の受診に関連付けられた「サービス日」のタイムスタンプから推定します。 イベントタイプ inferred | |||
| チャージ取得完了 | 患者の受診に対する請求対象のサービス、処置、物品を正式に記録するアクティビティです。臨床上の活動を財務取引に変換する、重要なデータ入力手順です。 | ||
| 重要な理由 臨床業務から財務業務への引き継ぎを示します。請求書や請求の生成にかかるサイクルタイムの測定開始点となり、チャージ入力の滞留を特定するのに役立ちます。 入手先 R1 RCMのチャージ入力モジュール内で取得するか、EHRからインターフェース経由で受信します。通常は、特定の取引ログまたはチャージレコードの作成タイムスタンプによって記録されます。 取得 請求テーブル内のチャージ取引レコードの作成タイムスタンプによって特定します。 イベントタイプ explicit | |||
| 入金の受領 | 支払者または患者から支払いを受け取った状態です。資金を受領したことを示しますが、特定のアカウントやサービス明細への充当はまだ行われていません。 | ||
| 重要な理由 現金の流入を示します。「入金の受領」から「入金計上」までの時間差は、バックオフィスの効率と入金照合の遅延を把握するための重要な指標です。 入手先 支払者からの電子支払通知ファイル、または患者の支払い処理から取得します。入金日またはファイル受信日に対応します。 取得 ERAファイルの支払有効日、または患者の支払い取引日から記録します。 イベントタイプ explicit | |||
| 入金計上 | 受領した支払いを患者のアカウントに正式に充当し、未払い残高を減らします。請求したサービスと支払いを照合する最後の手順です。 | ||
| 重要な理由 サービス提供から支払いまで、および入金計上のサイクルタイムを算出する際の終点になります。収益が認識され、アカウントが正確に更新されたことを確認できます。 入手先 R1 RCMの患者会計モジュール内で、明示的な財務取引として記録されます。各計上には日付、金額、発生元が含まれます。 取得 ユーザーまたは自動化されたプロセスが支払いを充当した際、計上日を含む特定の取引として記録されます。 イベントタイプ explicit | |||
| 請求の送信 | 生成した請求を、保険会社などの支払者に電子送信します。払い戻しを受けるための、請求プロセスにおける最初の外部通信です。 | ||
| 重要な理由 支払者からの払い戻しにかかる時間の計測を開始する重要なマイルストーンです。追跡することで、送信待ちの滞留を把握し、支払者の期限内請求に関するコンプライアンスを確保できます。 入手先 請求がクリアリングハウスに送信された際、明示的な取引として記録されます。システムには送信タイムスタンプと確認情報が記録されます。 取得 クリアリングハウス経由で請求を送信した際、送信タイムスタンプを含む取引として明示的に記録されます。 イベントタイプ explicit | |||
| アカウントの不良債権化 | 回収に向けたすべての対応を終えても残った残高は、回収不能と判断されます。その残高は貸倒金として償却され、最終的な収益損失となります。 | ||
| 重要な理由 これはプロセス上の望ましくない結果であり、収益の直接的な損失につながります。どのケースが貸倒金に至るのかを分析すると、未払いのパターンや回収業務を改善できる機会が見えてきます。 入手先 通常、R1 RCMでは明示的なトランザクションとして処理され、未収残高が特定の貸倒金カテゴリーに振り替えられます。ユーザーによる操作や、自動化された経過期間ルールによって開始されることがよくあります。 取得 残高を償却するための特定の財務トランザクションとして記録されます。外部の回収代行会社への移管に伴って処理されることがよくあります。 イベントタイプ explicit | |||
| アカウント調整の実施 | 残高を変更するため、支払い以外の取引をアカウントに計上します。支払者との契約に基づく契約上の調整、少額残高の償却、訂正などが含まれます。 | ||
| 重要な理由 調整件数が多い場合、料金表、契約管理、請求エラーに問題がある可能性があります。調整を追跡することは、収益の正確性を分析するうえで重要です。 入手先 R1 RCMの患者会計モジュール内で、特定の取引タイプとして記録されます。各調整にはコード、金額、計上日が含まれます。 取得 固有の取引コードで識別できる、独立した調整取引として記録されます。 イベントタイプ explicit | |||
| 否認請求の手戻り開始 | ユーザーまたは自動化されたワークフローが、否認された請求の調査と解決を開始します。コーディングの修正、書類の提出、支払者の判断への異議申し立てなどを行います。 | ||
| 重要な理由 否認請求に対する、コストの大きい手戻りループの開始を追跡します。この段階にかかった時間を測定することは、否認管理チームの効率を把握するうえで重要です。 入手先 通常は、R1 RCMの作業キューまたは否認管理モジュール内で、否認請求のステータスが「手戻り対応中」または「確認中」に変更された時点から推定します。 取得 否認管理の作業キューにおけるステータス変更、または否認請求に対する最初のユーザー操作から推定します。 イベントタイプ inferred | |||
| 回収活動の開始 | 患者のアカウントが延滞状態になり、積極的な回収活動を開始します。自動リマインドレターの送付から、回収担当者への引き継ぎまでが含まれます。 | ||
| 重要な理由 コストの大きい回収プロセスの開始を示します。これらの活動の効果とサイクルタイムを分析することで、不良債権回収の戦略を改善できます。 入手先 アカウントが回収作業キューに移された際のステータス変更、またはR1 RCM内で回収ステータスコードが割り当てられた時点から、記録または推定されます。 取得 アカウントのステータスが「回収」または「延滞」に変更された時点から推定します。 イベントタイプ inferred | |||
| 患者向け明細書の生成 | 保険による審査後、患者が負担する残額を記載した明細書を作成します。自己負担金、免責額、保険対象外のサービスなどが対象になります。 | ||
| 重要な理由 患者からの支払いに関する収益サイクルを開始するアクティビティです。患者からの回収とキャッシュフローを管理するには、発生時期と頻度の分析が重要です。 入手先 通常は、患者向け明細書を作成し、印刷または電子送信するバッチ処理の実行時に、ログイベントとして取得します。R1 RCMには明細書の生成日が記録されます。 取得 患者向け明細書を生成するバッチ処理の実行時に、取引として記録されます。 イベントタイプ explicit | |||
| 支払者による審査結果の受信 | 送信した請求について、支払者からの回答をシステムで受信します。多くの場合、電子支払通知（ERA）ファイルで受信し、支払済み、否認、調整の内容が示されます。 | ||
| 重要な理由 次のステップが入金計上になるか、否認管理になるかを決める、プロセス上の重要な分岐点です。分析することで、支払者の傾向や入金までの速さを把握できます。 入手先 支払者からのANSI 835ファイルなどの電子支払通知ファイルがR1 RCMで処理された際に取得します。このイベントは、ファイルの処理タイムスタンプによって記録されます。 取得 電子支払通知（ERA／835）ファイルを取り込み、処理した時点で記録されます。 イベントタイプ explicit | |||
| 請求の否認 | 支払者が請求全体または特定の明細項目について支払いを拒否した状態です。否認理由が記録され、手戻りと異議申し立てのプロセスが始まります。 | ||
| 重要な理由 このアクティビティは、収益の漏れとプロセスの非効率を明らかにします。否認理由を分析することは、根本原因を特定し、初回請求での受理率を高めるために欠かせません。 入手先 独立したイベントではなく、処理済みのERAファイルの内容から推定されるステータスです。送金データ内の特定の否認コードによって、請求のステータスが変更されます。 取得 処理済みのERAファイルに含まれる否認コードから推定します。否認コードによって、請求のステータスが「否認」に変更されます。 イベントタイプ inferred | |||
| 請求の生成 | 取得したチャージに基づき、システム内で正式な請求を生成します。患者の基本情報、保険情報、サービスコードを標準形式にまとめます。 | ||
| 重要な理由 外部送信前の重要な社内マイルストーンです。ここでの遅延は、コーディング、データ検証、システム設定の問題を示している可能性があり、請求プロセス全体を遅らせます。 入手先 R1 RCM内の社内システムイベントです。請求アカウントのステータス変更、または請求エンティティ自体の作成タイムスタンプとして取得される可能性があります。 取得 ステータスが「請求生成済み」に変更された時点、または請求レコードの作成タイムスタンプから推定します。 イベントタイプ inferred | |||
抽出ガイド
ステップ
- ビジネスインテリジェンスまたはレポートモジュールにアクセスする権限を持つユーザーアカウントで、R1 RCMプラットフォームにログインします。
- プラットフォームのレポートセクションに移動します。「Business Intelligence」、「Reporting Portal」、「Analytics」などの名称になっている場合があります。
- 新しいカスタムレポートまたはクエリを作成するためのツールを探します。このツールで、抽出するデータ項目とロジックを定義できます。
- R1 RCMには、あらかじめ統合されたイベントログが用意されていないため、複数のソースのデータを組み合わせて作成する必要があります。提供されているクエリ設定では、UNION ALLを使ってさまざまな業務オブジェクトのイベントを1つの時系列ログに統合します。
- このドキュメントの「Query」セクションに記載されているクエリ全体をコピーし、カスタムレポートのクエリエディターまたは設定画面に貼り付けます。
- レポートパラメーター、特に日付範囲を設定します。クエリ内の
'{StartDate}'と'{EndDate}'のプレースホルダーに値を設定し、直近6か月間など、抽出期間を指定します。 - 必要に応じて、特定の施設、部門、支払者グループに絞り込むなど、レポート設定に追加のフィルターを設定します。
- レポートを実行します。指定したパラメーターに基づいてR1 RCMデータベースに対してクエリが実行され、結果が生成されます。
- レポートの実行が完了したら、データをエクスポートするオプションを探します。エクスポート形式にはCSV（Comma Separated Values）を選択します。ProcessMindと直接互換性があります。
- 生成されたCSVファイルをダウンロードして開き、内容を簡単に確認します。列見出しが必要な属性である
BillingEvent、ActivityName、EventTime、SourceSystem、LastDataUpdateと一致していることを確認します。 - ProcessMindにファイルをアップロードする前に、
EventTime列とLastDataUpdate列の日付・時刻形式が統一されていることを確認します。
設定
- 前提条件：R1 RCMのビジネスインテリジェンスモジュールで、カスタムレポートへのアクセスと作成に必要な権限を持つユーザーアカウントが必要です。
- レポート種別：複雑なデータ取得と、異なるデータセットを結合するUNION ALL文に対応したカスタムクエリまたは高度なレポートビルダーを使用します。
- 日付範囲：パフォーマンスとデータ量を管理するため、特定の期間で絞り込むことが重要です。初回分析では3～6か月の期間から始めることを推奨します。各アクティビティの主要なタイムスタンプ項目に日付フィルターを適用します。
- 主要なフィルター：日付範囲に加え、
Facility ID、Payer Type、Billing Departmentなどのフィルターを適用し、特定の業務領域に対象を絞り、エクスポートサイズを抑えます。 - エクスポート形式：出力形式には必ずCSVを選択してください。プロセスマイニングツールで解析しやすい、整った構造のファイルになります。
- スケジュール設定：R1 RCMのレポートモジュールが対応している場合は、継続的なモニタリングに向けて、週次や月次などの定期実行を設定し、データ更新を自動化することを検討してください。
a サンプルクエリ sql
SELECT
c.ClaimID AS BillingEvent,
'Service Rendered' AS ActivityName,
c.ServiceDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ClinicianID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Rendered' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ServiceDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
c.ClaimID AS BillingEvent,
'Charges Captured' AS ActivityName,
c.ChargeEntryTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ChargeEntryUserID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Open' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ChargeEntryTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Created' AS ActivityName,
cl.CreationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.CreatedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Created' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.CreationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Submitted' AS ActivityName,
cl.SubmissionTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.SubmittedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Submitted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.SubmissionTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
era.ClaimID AS BillingEvent,
'Payer Adjudication Received' AS ActivityName,
era.ReceivedTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pa.InvoiceAmount AS InvoiceAmount,
era.PayerName AS PayerName,
'Adjudicated' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [RemittanceAdvice] era
JOIN [PatientAccounts] pa ON era.ClaimID = pa.BillingEvent
WHERE era.ReceivedTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
d.ClaimID AS BillingEvent,
'Claim Denied' AS ActivityName,
d.DenialTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Denied' AS InvoiceStatus,
d.ReasonCode AS DenialReasonCode
FROM [DenialsLog] d
JOIN [ClaimsData] cl ON d.ClaimID = cl.ClaimID
WHERE d.DenialTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
dr.ClaimID AS BillingEvent,
'Denial Rework Started' AS ActivityName,
dr.ReworkStartTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
dr.AssignedUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'In Rework' AS InvoiceStatus,
dr.OriginalDenialCode AS DenialReasonCode
FROM [DenialRework] dr
JOIN [ClaimsData] cl ON dr.ClaimID = cl.ClaimID
WHERE dr.ReworkStartTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ps.PatientAccountID AS BillingEvent,
'Patient Statement Generated' AS ActivityName,
ps.GenerationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ps.GeneratedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
ps.StatementBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Patient Billed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientStatements] ps
JOIN [PatientAccounts] pa ON ps.PatientAccountID = pa.BillingEvent
WHERE ps.GenerationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
p.AssociatedClaimID AS BillingEvent,
'Payment Received' AS ActivityName,
p.ReceiptTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
p.ProcessedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
p.PaymentAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Payment Pending' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentsLog] p
JOIN [PatientAccounts] pa ON p.AssociatedClaimID = pa.BillingEvent
WHERE p.ReceiptTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pt.ClaimID AS BillingEvent,
'Payment Posted' AS ActivityName,
pt.PostingTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pt.PostedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pt.PostedAmount AS InvoiceAmount,
pt.PayerName AS PayerName,
'Partially Paid' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentTransactions] pt
JOIN [PatientAccounts] pa ON pt.ClaimID = pa.BillingEvent
WHERE pt.PostingTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
a.ClaimID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
a.AdjustmentTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
a.AdjusterID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
a.AdjustmentAmount AS InvoiceAmount,
pa.PayerName AS PayerName,
'Adjusted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [Adjustments] a
JOIN [PatientAccounts] pa ON a.ClaimID = pa.BillingEvent
WHERE a.AdjustmentTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ca.PatientAccountID AS BillingEvent,
'Collection Activity Started' AS ActivityName,
ca.ActivityTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ca.AssignedAgentID AS AssignedUser,
'Collections' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'In Collections' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [CollectionsActivity] ca
JOIN [PatientAccounts] pa ON ca.PatientAccountID = pa.BillingEvent
WHERE ca.ActivityTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Placed in Bad Debt' AS ActivityName,
pa.BadDebtPlacementDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pa.BadDebtUserID AS AssignedUser,
'Finance' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Bad Debt' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.BadDebtPlacementDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Closed' AS ActivityName,
pa.ClosureDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
0 AS InvoiceAmount,
pa.PayerName AS PayerName,
'Closed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.ClosureDate BETWEEN '{StartDate}' AND '{EndDate}' AND pa.CurrentBalance = 0;準備はできましたか？
このテンプレートを使ってデータ収集を効率化し、収益サイクル管理の最適化に向けた取り組みを始めてください。各ステップでサポートします。
今すぐR1 RCMを最適化：収益サイクルの効率を向上
RCMのボトルネックを解消し、サイクルタイムを30％短縮して、キャッシュフローを改善します。
クレジットカードは不要です。数分で始められます。