> 継続的なプロセス改善 > 収益サイクル管理 > R1 RCM > データテンプレート

収益サイクル管理のデータテンプレート

R1 RCM

収益サイクル管理の属性(19) 収益サイクル管理のアクティビティ(14) データ抽出ガイド(1)

収益サイクル管理のデータテンプレート

このデータテンプレートでは、収益サイクル管理プロセスの分析に必要な情報を収集するための手順を確認できます。収集すべき属性と、追跡が必要な主要アクティビティをまとめています。また、R1 RCMシステムからデータを抽出する方法も説明しているため、プロセスマイニングを円滑に始めるための準備に役立ちます。

収集を推奨する属性
プロセスの発見に向けて追跡する主要アクティビティ
R1 RCMからのデータ抽出手順

イベントログを初めて作成する方はこちら：プロセスマイニング用イベントログの作成方法.

テンプレートをダウンロード

収益サイクル管理の属性

収益サイクル管理プロセスを詳しく分析するため、イベントログに含めることを推奨するデータ項目です。

5 必須 6 推奨 8 任意

	名前	説明
	アクティビティ名 ActivityName	収益サイクルの中で、特定の時点に発生した業務イベントまたはタスクの名前です。
説明この属性は、請求イベントにおける収益サイクル管理の個々のステップや節目を表します。アクティビティは実施された作業を示し、「料金を記録」「請求データを提出」「支払いを計上」などが該当します。アクティビティの順序を分析することは、プロセスマイニングの中心的な機能です。実際のプロセスの流れを明らかにし、開始までに時間がかかるアクティビティのボトルネックを特定できます。また、「請求拒否」の後に「拒否への再対応を開始」するような、不要な繰り返し作業も検出できます。重要な理由プロセスの各ステップを定義する情報です。プロセスマップの可視化、ステップ間の所要時間の算出、プロセス逸脱や手戻りの特定に役立ちます。入手先通常は、イベントログ、ステータス変更の記録、またはR1 RCMの各種モジュールにある取引コードから取得します。技術コードを業務で使う名称に対応付ける必要がある場合もあります。例料金記録請求データ送信支払者の審査結果を受信入金記録アカウントクローズ
	イベント発生時刻 EventTime	特定のアクティビティまたはイベントが発生した日時を示すタイムスタンプです。
説明イベント発生時刻は、アクティビティがシステムに記録された正確な日時を示します。時間に基づいてプロセスを分析するうえで欠かせない情報です。プロセスマイニングでは、このタイムスタンプを使ってイベントを時系列に並べ、アクティビティ間の所要時間を算出します。サイクルタイム、処理時間、待ち時間などの主要な指標を計算できるため、ボトルネックの特定や効率の測定に役立ちます。重要な理由サイクルタイムの算出、ボトルネックの特定、SLAに対するプロセスの状況確認など、時間に関する分析の基礎となるタイムスタンプです。入手先通常、R1 RCMの各取引またはステータス変更の記録にある「作成日」「タイムスタンプ」「最終更新日」などのフィールドに記録されています。例 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z
	請求イベント BillingEvent	請求対象となる個々のサービスまたは項目を識別する一意のIDです。収益サイクル全体を追跡する際の主なケース識別子として使用されます。
説明請求イベントIDは、料金が発生するサービスまたは製品の提供を個別に識別します。サービスの提供と料金の記録から、請求データの提出、入金の計上、最終的な勘定の締め処理まで、関連するすべてのアクティビティを結び付ける中心的な識別子です。プロセスマイニングでは、請求イベントごとのライフサイクルを分析することで、収益サイクル全体を把握できます。個々の請求の流れを追跡し、よくある経路を特定するほか、主要な節目間の所要時間を測定し、遅延や収益の取りこぼしにつながる違いを把握できます。重要な理由この識別子を使うと、関連するすべてのアクティビティを1つのケースにまとめられ、請求イベントごとの収益サイクルを漏れなく正確に分析できます。入手先患者の診療、料金、請求、支払いに関する各テーブルを結び付ける主キーです。具体的な項目については、診療IDや請求IDに関連するフィールドなど、R1 RCMの文書を確認してください。例 BE-2023-0012345BE-2023-0054321BE-2024-0098765
	ソースシステム SourceSystem	イベントデータの抽出元となる記録システムです。
説明この属性は、特定のイベントのデータを生成したアプリケーションまたはモジュールを示します。医療機関のように複雑な環境では、電子カルテ、請求モジュール、請求データの中継機関、債権回収プラットフォームなど、さまざまなシステムからデータが集まることがあります。ソースシステムを把握することは、データの検証や、特定のシステムに起因するプロセスの違いを分析するうえで重要です。データの不整合を調査し、プロセスを支えるシステム構成を理解する際にも役立ちます。重要な理由データの出所を特定する情報です。データガバナンスや検証に役立つほか、プロセス全体で各システムがどのように連携しているかを把握できます。入手先データの抽出時に追加される固定値であることが多く、データの取得元となるシステム（例：「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（請求調整理由コード）などの理由コードが通知されます。これらの標準コードは、「対象外のサービス」や「重複請求」などの問題を示します。この属性は、請求拒否への対応において特に重要です。理由コードごとの発生頻度を分析すると、患者の受給資格、コーディングミス、医療上の必要性の不足など、拒否の根本原因を特定して対処できます。これにより、手戻りの削減と入金の迅速化を直接支援できます。重要な理由請求拒否の具体的な理由を把握できます。根本原因を分析して今後の拒否を減らし、手戻りを抑え、初回請求での支払い率を高めるのに役立ちます。入手先支払者から電子支払通知（ERAまたは835ファイル）として受け取り、R1 RCMの請求管理モジュールに保存されます。例 CO-16：審査に必要な情報が請求またはサービスに不足しています。PR-97：このサービスの給付は、別のサービスに対する支払いまたは許容額に含まれています。CO-22：給付調整により、この医療費は別の支払者が負担する可能性があります。OA-18：請求またはサービスが完全に重複しています。
	請求部門 BillingDepartment	アクティビティを実施する部門または機能別チームです。
説明この属性は、「料金入力」「請求データ提出」「請求拒否管理」など、特定のプロセスステップを実施した組織単位を示します。チーム間で業務がどのように引き継がれるかを把握できます。部門ごとの処理状況を分析し、部門をまたぐボトルネックを特定するうえで重要です。プロセスマップを部門で絞り込むと、チーム間の引き継ぎが円滑な箇所や遅延が発生する箇所を確認でき、リソース配分や組織内のプロセス改善に役立ちます。重要な理由組織単位でプロセスの状況を分析し、チーム固有のボトルネック、リソースの制約、効果的な取り組みを特定できます。入手先 R1 RCMのユーザープロフィールから取得するか、取引データの「部門コード」として保存されている場合があります。例料金の記録請求案件管理請求拒否と異議申し立て支払いの計上
	請求金額 InvoiceAmount	請求書または請求データに記載された料金の合計金額です。
説明この属性は、請求イベントで提供したサービスの請求総額を表します。請求に対して見込まれる収益を示します。請求金額の分析は、財務プロセスマイニングに欠かせません。金額の大きい請求を優先して確認し、プロセスの遅延や請求拒否が財務に与える影響を把握できるほか、金額に応じてプロセスを分類できます。たとえば、一定額を超える請求では、手作業の多い別のプロセス経路をたどることが分かる場合があります。重要な理由プロセスを財務面から把握するための情報です。プロセスの違いが収益に与える影響を分析し、改善対象として高額のケースを優先できます。入手先 R1 RCMの請求データまたは請求書のヘッダーテーブルにあり、「TotalBilledAmount」などの名前が付いていることがよくあります。例 150.002500.7585.5012000.00
	サービスコード ServiceCode	提供したサービスまたは手技を示す請求コードです。CPTコードやHCPCSコードなどが該当します。
説明 CPT（Current Procedural Terminology）コードなどのサービスコードは、医療、外科、診断に関する手技やサービスを支払者に報告し、払い戻しを受けるための標準化された医療コードです。サービスコード別のプロセス分析は、特定の種類の医療に関する請求上の問題を特定するうえで重要です。請求拒否が多い手技、支払いまでの期間が長い手技、手戻りが多い手技を把握し、コーディングや請求業務の改善につなげられます。重要な理由提供したサービスの種類に基づいてプロセスを分析できます。特定の手技に関連する請求拒否の傾向や支払いの遅延を特定するうえで役立ちます。入手先 R1 RCMの各料金または請求データの明細行に記録されています。例 992139928573560
	サービス提供から支払いまでのサイクルタイム ServiceToPaymentCycleTime	サービスの提供から最終的な支払いの計上までにかかった時間の合計です。
説明この指標は、1件の請求イベントにおける収益サイクル全体の所要時間を測定します。提供したサービスを入金に結び付けるまでに組織が要する時間を示します。財務状況を測る重要業績評価指標（KPI）です。この所要時間を分析すると、プロセスを短縮できる主な箇所を特定できます。「請求までの時間」や「支払いまでの時間」などに分けて確認することで、キャッシュフローを改善する機会を見つけられます。重要な理由資金回収サイクル全体の効率を測る重要な上位指標であり、組織のキャッシュフローに直接影響します。入手先計算指標です。請求イベントについて、「サービス提供」アクティビティと「支払い計上」アクティビティのタイムスタンプの差を算出します。例 35日8時間92日4時間15日12時間
	債権回収の結果 CollectionOutcome	未払い残高に対する債権回収活動の最終結果です。
説明この属性は、支払いが滞っている勘定からの回収結果を示します。「全額支払い済み」「減額で和解」「貸倒処理」「未解決」などが該当します。債権回収の結果を追跡することは、回収プロセスの効果を評価するうえで欠かせません。どのアクティビティがどの結果につながるかを分析すると、回収方法を見直し、回収率を高められます。また、回収を終了して残高を貸倒処理するタイミングについて、根拠に基づいて判断できます。この分析は、「債権回収アクティビティのパフォーマンス」ダッシュボードに役立ちます。重要な理由滞納勘定の最終的な解決状況を追跡し、債権回収プロセスの効果を測定できます。回収方法の見直しにも役立ちます。入手先 R1 RCMの患者勘定にあるステータスフィールド、または専用の債権回収モジュールに記録されていると考えられます。例全額支払い済み減額で和解外部の回収業者に引き継ぎ貸倒処理
	患者ID PatientId	サービスを受けた患者を識別する一意のIDです。
説明この属性は、医療システム内で患者に割り当てられた一意のIDで、医療記録番号（MRN）と呼ばれることもあります。個々の患者の診療そのものを分析対象とするわけではありませんが、患者IDを使って、同じ患者に繰り返し発生する請求上の問題を時系列で分析できます。他の患者データと紐付ければ、患者の属性や履歴でプロセスを分類し、特定の患者グループに影響する組織的な問題を見つけられる場合もあります。重要な理由患者単位で請求イベントを分析し、複数回の診療にわたって特定の患者に繰り返し発生する問題や傾向を特定できます。入手先 R1 RCMで、すべての診療記録と請求データに紐付けられる患者属性データの基本項目です。例 MRN837262MRN937281MRN103847
	手戻りかどうか IsRework	拒否された請求の再提出など、手戻りの一連の処理に含まれるアクティビティを示す計算フラグです。
説明この属性は真偽値のフラグで、通常はプロセスマイニングの分析時に算出されます。アクティビティが前のステップの繰り返しである場合や、「請求拒否」の後に続くアクティビティのように、エラーの修正を示す一連の処理に含まれる場合に「true」になります。手戻りの特定は、プロセスマイニングの主な機能の1つです。プロセス内で無駄になっている作業、時間、リソースを定量化できます。手戻りを検出することで、その原因となるエラーを未然に防ぐ改善に取り組み、効率の向上につなげられます。重要な理由請求拒否などの手戻りの頻度と影響を定量化し、非効率や無駄な作業を減らすための分析に役立ちます。入手先ソースシステムのフィールドではありません。アクティビティの順序に基づいてプロセスマイニングツールが算出します。たとえば、同じケースで「請求データを提出」が複数回発生したことを検出します。例 truefalse
	自動処理かどうか IsAutomated	アクティビティを自動処理システムと人のどちらが実施したかを示すフラグです。
説明この真偽値属性は、請求データの提出を行うRPAボットなどのソフトウェアによる自動処理と、従業員による手作業を区別します。自動化の取り組みがどのような効果をもたらしているかを把握するうえで、この属性の分析が役立ちます。自動処理と手作業の速度、コスト、エラー率を比較し、新たな自動化の候補を見つけたり、既存のボットの投資対効果を測定したりできます。重要な理由人が行ったアクティビティとシステムによるアクティビティを区別できます。自動化がプロセスの効率、コスト、品質に与える影響を測定するうえで重要です。入手先「AssignedUser」フィールドから判定できます。たとえば、「BOT_RPA01」のように、特定のユーザーIDがボット用に割り当てられている場合があります。また、自動処理を示す専用フィールドがあるシステムもあります。例 truefalse
	調整理由 AdjustmentReason	「契約上の減額」や「貸倒処理」など、財務調整の理由です。
説明この属性は、勘定に財務調整を行った理由を示します。調整の種類を分類するため、標準コードや説明が使われることがよくあります。調整理由を分析すると、収益の取りこぼしの根本原因を特定できます。たとえば、「少額残高の貸倒処理」が頻繁に発生している場合、少額債権の回収プロセスに非効率がある可能性があります。一方、「契約上の減額」が多い場合は、支払者との契約に伴う通常の処理と考えられます。この分析は、「請求調整とコンプライアンス監査」ダッシュボードに役立ちます。重要な理由収益調整の理由を明らかにし、契約上の問題、請求ミス、債権回収の失敗など、収益減少の根本原因を特定できます。入手先通常、R1 RCMでAdjustmentAmountと同じ取引レコードにあるコードまたはテキストフィールドです。例契約上の減額貸倒処理を実施少額残高の貸倒処理請求エラーの訂正
	調整額 AdjustmentAmount	勘定残高に対して行った調整の金額です。
説明この属性は、最初の請求後に患者の勘定へ適用された財務調整の金額を記録します。調整額は正または負の値で、契約上の減額、貸倒処理、訂正などが含まれます。調整額の追跡は、収益の正確性を把握するうえで重要です。マイナスの調整が多い場合、料金の記録ミスや回収不能債権などによる収益の取りこぼしが考えられます。このデータを分析すると、請求ミスや債権回収の非効率が財務に与える影響を特定できます。重要な理由収益の取りこぼしや財務上の訂正を金額で把握し、請求の誤り、契約上の義務、貸倒れが金銭面に与える影響を特定できます。入手先 R1 RCMの勘定調整または支払い計上に関する取引ログに記録されています。例 -50.2520.00-1200.00

必須推奨任意

収益サイクル管理のアクティビティ

収益サイクル管理のプロセスを正確に把握するため、イベントログに記録する主要なプロセスの手順と節目です。

6 推奨 8 任意

	アクティビティ	説明
	アカウントクローズ	請求イベントの処理が完了して残高がゼロになり、アカウントが正式にクローズされた状態です。この診療に関する収益サイクルが正常に完了したことを示します。
重要な理由このプロセスにおける主な理想経路の終了イベントです。アカウントのクローズにかかるサイクルタイムを測定することで、事務処理が効率よく完了し、記録が確定しているかを確認できます。入手先アカウント残高がゼロになり、最終ステータスが「クローズ」または「全額支払い済み」になった時点から推定します。タイムスタンプには、残高をゼロにした最後の財務取引の時刻を使います。記録アカウント残高がゼロになり、「クローズ」ステータスが適用された時点と、最後のアクティビティのタイムスタンプから推定します。イベントタイプ inferred
	サービス提供完了	患者に対する請求対象のサービスや処置が完了した時点を示します。このイベントは、臨床システムや予約管理システムから記録されることが多く、収益サイクルの開始点となります。
重要な理由サービス提供から入金までのサイクルタイムを測定する際の起点です。このイベントからの所要時間を分析すると、収益サイクルの初期段階で発生する遅延を特定できます。入手先通常は、R1 RCMと連携する電子カルテ（EHR）または診療管理システムから取得します。患者記録の「サービス日」や「処置完了」のタイムスタンプから推定することもあります。記録患者の診療に関連付けられた「サービス日」のタイムスタンプから推定します。イベントタイプ inferred
	入金受領	支払者または患者から入金を受け取った状態です。資金を受領したことを示しますが、特定のアカウントやサービス項目への充当はまだ完了していません。
重要な理由現金の流入を示します。「入金受領」から「入金記録」までの時間差は、バックオフィス業務の効率や入金照合の遅れを把握するための重要な指標です。入手先支払者からの電子送金ファイル、または患者の支払い処理から記録します。このイベントは入金日またはファイル受領日に対応します。記録 ERAファイルの支払適用日、または患者の支払い取引日から記録します。イベントタイプ explicit
	入金記録	受領した入金を患者のアカウントに正式に充当し、未決済残高を減らします。請求したサービスと入金を照合する最終手順です。
重要な理由このアクティビティは、サービス提供から入金までのサイクルタイムと、入金記録のサイクルタイムを算出する際の終点です。収益が計上され、アカウントが正確に更新されたことを確認できます。入手先 R1 RCMの患者会計モジュールで、明示的な財務取引として記録されます。各記録には日付、金額、入金元が含まれます。記録担当者または自動処理が入金を充当した際、記録日を含む特定の取引として記録されます。イベントタイプ explicit
	料金記録	患者の診療に対する請求対象のサービス、処置、消耗品を正式に記録するアクティビティです。臨床上の処置を財務取引に反映する、重要なデータ入力の手順です。
重要な理由臨床業務から財務業務への引き継ぎを示します。請求書や請求データの作成サイクルタイムを測定する起点となり、料金入力の滞留を特定するのに役立ちます。入手先 R1 RCMの料金入力モジュールに記録されるか、電子カルテ（EHR）とのインターフェースを通じて受信します。通常、特定の取引ログまたは料金記録の作成タイムスタンプで確認できます。記録請求テーブルにある料金取引記録の作成タイムスタンプで特定します。イベントタイプ 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
	請求データ作成	記録された料金に基づき、システムで正式な請求データを作成します。患者の属性、保険情報、サービスコードを標準形式にまとめます。
重要な理由外部への送信前に行う重要な社内工程です。ここで遅延が発生している場合、コーディング、データ検証、システム設定に問題があり、請求処理全体が遅れている可能性があります。入手先 R1 RCM内のシステムイベントです。請求アカウントのステータス変更、または請求データ自体の作成タイムスタンプとして記録されると考えられます。記録ステータスが「請求データ作成済み」に変わった時点、または請求記録の作成タイムスタンプから推定します。イベントタイプ inferred
	請求否認	支払者が請求の全額または一部の項目について支払いを拒否した状態です。否認理由が記録され、修正や異議申し立てのプロセスが始まります。
重要な理由このアクティビティは、収益の逸失やプロセスの非効率を示します。否認理由を分析することは、根本原因を特定し、初回提出での請求承認率を高めるうえで重要です。入手先独立したイベントではなく、処理済みのERAファイルの内容から推定されるステータスです。送金データに含まれる特定の否認コードによって、請求のステータスが変更されます。記録処理済みのERAファイルに含まれる否認コードにより、請求のステータスが「否認」に変わったことから推定します。イベントタイプ inferred

推奨任意

データ抽出ガイド

R1 RCMからデータを取得する方法

ステップ

ビジネスインテリジェンスまたはレポート作成モジュールにアクセスできる権限を持つユーザーアカウントで、R1 RCMプラットフォームにログインします。
プラットフォームのレポートセクションに移動します。「Business Intelligence」「Reporting Portal」「Analytics」などの名称が付いている場合があります。
カスタムレポートまたはクエリを新規作成するツールを探します。このツールで、抽出するデータ項目とロジックを指定できます。
R1 RCMには、統合済みのイベントログがあらかじめ用意されていません。そのため、複数のデータソースを組み合わせて作成する必要があります。提供されたクエリ設定では、UNION ALLを使って複数の業務オブジェクトのイベントを1つの時系列ログにまとめます。
この文書の「Query」セクションにあるクエリ全体をコピーし、カスタムレポートのクエリエディターまたは設定画面に貼り付けます。
特に日付範囲など、レポートのパラメーターを設定します。クエリ内の'{StartDate}'と'{EndDate}'を置き換えて、直近6か月など、抽出対象の期間を指定します。
対象を絞るため、施設、部門、支払者グループなど、必要なフィルターをレポート設定に追加します。
レポートを実行します。指定したパラメーターに基づいてR1 RCMデータベースにクエリが実行され、結果が生成されます。
レポートの実行が完了したら、データのエクスポート機能を選びます。ProcessMindでそのまま利用できるCSV（カンマ区切り値）を形式として指定します。
生成されたCSVファイルをダウンロードして開き、内容を簡単に確認します。列見出しが必要な属性であるBillingEvent、ActivityName、EventTime、SourceSystem、LastDataUpdateと一致していることを確認します。
ProcessMindにアップロードする前に、EventTime列とLastDataUpdate列の日付・時刻形式が統一されていることを確認します。

設定

前提条件：R1 RCMのビジネスインテリジェンスモジュールでカスタムレポートにアクセスし、作成できる十分な権限を持つユーザーアカウントが必要です。
レポートの種類：複雑なデータ取得に対応し、UNION ALL文で異なるデータセットを結合できるカスタムクエリまたは高度なレポートビルダーを使用します。
日付範囲：処理性能とデータ量を考慮し、特定の期間に絞り込むことが重要です。初回の分析では、3～6か月の期間から始めることを推奨します。各アクティビティの主要なタイムスタンプ項目に日付フィルターを適用します。
主なフィルター：日付範囲に加え、Facility ID、Payer Type、Billing Departmentで絞り込み、特定の業務領域に対象を限定してエクスポートするデータ量を抑えることを検討してください。
エクスポート形式：出力形式には必ずCSVを選択します。プロセスマイニングツールで簡単に読み込める、整理されたファイルを作成できます。
スケジュール設定：R1 RCMのレポートモジュールが対応している場合は、継続的なモニタリングに向けて、レポートを週次や月次などの定期実行に設定し、データ更新を自動化することを検討してください。

クエリの例 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％短縮して、キャッシュフローを改善します。

無料トライアルを開始しましょう。

クレジットカードは不要です。数分で利用を開始できます。

収益サイクル管理のデータテンプレート

収益サイクル管理のデータテンプレート

収益サイクル管理の属性

収益サイクル管理のアクティビティ

データ抽出ガイド

R1 RCMのビジネスインテリジェンスレポートをエクスポート

ステップ

設定

クエリの例 sql

始める準備はできていますか？

R1 RCMを今すぐ最適化：収益サイクルの効率を向上