収益サイクルマネジメントデータテンプレート
収益サイクルマネジメントデータテンプレート
- 収集を推奨する項目
- プロセスディスカバリで追跡すべき主要な活動
- R1 RCM向け詳細抽出ガイド
収益サイクルマネジメント属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 収益サイクルプロセス内の特定の時点で発生したビジネスイベントまたはタスクの名前。 | ||
| 説明 この属性は、特定の請求イベントにおける収益サイクルマネジメントプロセス内の単一のステップまたはマイルストーンを記述します。活動は、「料金計上」、「請求提出済み」、「支払記帳済み」など、実行されている作業を表します。 活動のシーケンスを分析することは、プロセスマイニングの核となります。これにより、実際のプロセスフローの発見、活動の開始に時間がかかりすぎるボトルネックの特定、「請求却下」の後に「却下再作業開始」が続くなど、活動が不必要に繰り返される手戻りループの検出が可能になります。 その重要性 これはプロセスのステップを定義し、プロセスマップの可視化、遷移時間の計算、およびプロセス逸脱と手戻りの特定を可能にします。 取得元 この情報は、通常、R1 RCMの様々なモジュール内のイベントログ、ステータス変更記録、または取引コードから導出されます。技術的なコードからビジネスに適した名前にマッピングする必要がある場合があります。 例 請求取り込み済み請求の提出支払者裁定受領支払い計上口座閉鎖 | |||
| イベント日時 EventTime | 特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。 | ||
| 説明 イベントタイムは、アクティビティがシステムに記録された正確な日時を提供します。この時間情報は、時間ベースの分析からプロセスを理解するための基礎となります。 プロセスマイニングでは、このタイムスタンプはイベントを時系列に並べ、アクティビティ間の期間を計算するために使用されます。これはパフォーマンス分析に不可欠です。これにより、サイクルタイム、処理時間、待機時間といった主要なメトリックの計算が可能になり、ボトルネックの特定と効率の測定に不可欠です。 その重要性 このタイムスタンプは、サイクルタイムの計算、ボトルネックの特定、SLAに対するプロセスパフォーマンスの監視など、すべての時間関連分析の基盤となります。 取得元 通常、R1 RCM内の各取引またはステータス変更記録に関連付けられた「作成日」、「タイムスタンプ」、または「最終更新日」フィールドとして見つかります。 例 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| 請求イベント BillingEvent | 単一の請求可能なサービスまたは品目の一意の識別子であり、収益サイクル全体を追跡するための主要なケース識別子として機能します。 | ||
| 説明 請求イベントIDは、課金が発生するサービスまたは製品提供の個別インスタンスを表します。初期のサービス提供や料金計上から、請求書の提出、支払記帳、最終的な勘定閉鎖まで、関連するすべての活動を結びつける中心的な役割を果たします。 プロセスマイニングでは、各請求イベントのライフサイクルを分析することで、エンドツーエンドの収益サイクルを包括的に把握できます。単一の課金の全過程を追跡し、一般的な経路を特定し、主要なマイルストーン間のサイクルタイムを測定し、遅延や収益漏れにつながる変動を理解するために使用されます。 その重要性 この識別子は、関連するすべての活動を単一のケースにグループ化し、各請求可能イベントの収益サイクルの完全かつ正確なプロセス分析を可能にするために不可欠です。 取得元 これは、患者のエンカウンター、料金、請求、および支払いに関連する様々なテーブルをリンクする主キーです。具体的なフィールドについては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 | |||
| 却下理由コード DenialReasonCode | 請求が却下された理由を説明する、支払者からの標準化されたコード。 | ||
| 説明 支払者が請求を却下する際、CARC(請求調整理由コード)のような理由コードを提供してその決定を説明します。これらのコードは標準化されており、「サービス対象外」や「重複請求」などの問題を示します。 この属性は、却下管理にとって極めて重要です。異なる却下理由コードの頻度を分析することで、組織は却下の根本原因(患者の資格、コーディングエラー、医療上の必要性の欠如など)を特定し、対処できます。これは、手戻りの削減とキャッシュフローの加速に向けた取り組みを直接サポートします。 その重要性 請求却下の具体的な理由を提示し、根本原因分析を可能にすることで、将来の却下を減らし、手戻りを削減し、初回支払率を向上させます。 取得元 この情報は、支払者からの電子送金通知(ERAまたは835ファイル)で受け取られ、R1 RCMの請求管理モジュールに保存されます。 例 CO-16: 請求/サービスには裁定に必要な情報が不足しています。PR-97: このサービスの利益は、他のサービスの支払いや手当に含まれています。CO-22: このケアは、給付調整により別の支払者によってカバーされる場合があります。OA-18: 完全に重複する請求/サービス。 | |||
| 担当ユーザー AssignedUser | アクティビティを実行した従業員のユーザーIDまたは名前。 | ||
| 説明 この属性は、プロセス内の特定のタスク実行責任者を特定します。これには、請求書を作成した請求担当者、却下された請求を再作業したアナリスト、または支払いを記帳した専門家が含まれる可能性があります。 ユーザーごとに分析することで、作業負荷の配分、個々のパフォーマンス、およびトレーニングニーズを理解するのに役立ちます。どのユーザーが最も効率的であるか、またはどのユーザーが高いエラー率に関連している可能性があるかを浮き彫りにすることができ、的を絞った管理およびプロセス改善努力を可能にします。 その重要性 チームおよび個人のパフォーマンス、ワークロードの配分を分析し、トレーニング機会やユーザー固有のプロセス逸脱を特定するのに役立ちます。 取得元 通常、R1 RCM内の取引ログの「UserID」、「Processor」、または「UpdatedBy」フィールドとして見つかります。 例 jdoeasmithp.jonesBOT_RPA01 | |||
| 支払人名 PayerName | 支払責任を負う保険会社、政府機関、または患者の名前。 | ||
| 説明 この属性は、請求の主要な支払者を特定します。これには、エトナのような民間保険会社、メディケアのような政府支払者、または自己負担部分の患者自身が含まれる可能性があります。 支払者ごとにプロセスを分析することは、収益サイクルマネジメントの基本です。特定の支払者が高い却下率、長い支払いサイクル、またはより複雑な提出要件を持っていることを明らかにできます。これらの洞察により、組織は支払者固有の行動を効果的に管理するために、プロセスとリソースを調整できます。 その重要性 支払者ごとのプロセスセグメンテーションを可能にし、支払者固有の遅延、却下パターン、または支払い行動を特定するのに役立ちます。これは収益最適化にとって重要です。 取得元 R1 RCMにおける請求にリンクされた患者の保険情報または人口統計情報にあります。 例 メディケアユナイテッドヘルスケアBlue Cross Blue ShieldAetna自費 | |||
| 経理部門 BillingDepartment | Activityの実行を担当する部門または機能チームです。 | ||
| 説明 この属性は、「料金入力」、「請求提出」、「却下管理」など、特定のプロセスステップを実行した組織単位を特定します。これにより、異なるチーム間での作業の引き継ぎ方法を理解するのに役立ちます。 これは、部門のスループットを分析し、部門横断的なボトルネックを特定するために不可欠です。プロセスマップを部門別にフィルタリングすることで、組織は引き継ぎがスムーズな場所と遅延が発生する場所を把握でき、リソース配分と組織プロセス最適化をサポートします。 その重要性 組織単位ごとのプロセスパフォーマンス分析を可能にし、チーム固有のボトルネック、リソース制約、またはベストプラクティスを特定するのに役立ちます。 取得元 これは、R1 RCMのユーザープロファイルから導出されるか、取引データ内で「部署コード」として保存される場合があります。 例 請求取り込み保険金請求管理却下と異議申し立て支払記帳 | |||
| 請求書ステータス InvoiceStatus | 請求書または請求のライフサイクルにおける現在のステータス。 | ||
| 説明 この属性は、「提出済み」、「支払い済み」、「却下済み」、「回収中」など、請求イベントの最後に確認された状態を示します。特定の時点での請求書がプロセス内でどこにあるかのスナップショットを提供します。 請求ステータスは、年齢構成レポートの作成と売掛金の健全性の監視にとって不可欠です。プロセスマイニングでは、特定の状態に滞留しているケースをフィルタリングしたり、「支払い済み」と「却下済み」の請求経路を比較するなど、異なるプロセスバリアントの結果を分析するために使用できます。 その重要性 各ケースの現状を把握でき、年齢構成レポートの作成や、様々なプロセスパスの最終結果を分析する上で不可欠です。 取得元 これは通常、R1 RCMの主要な請求または勘定記録上のステータスフィールドです。 例 申請待ち支払者に提出済み否認全額支払済み回収中 | |||
| 請求金額 InvoiceAmount | 請求書または請求の料金の総金銭的価値。 | ||
| 説明 この属性は、特定の請求イベントで提供されたサービスの総請求額を表します。これは、請求から期待される収益を反映しています。 請求額の分析は、財務プロセスマイニングにとって非常に重要です。これにより、高価値の請求を優先し、プロセス遅延や却下が財務に与える影響を理解し、価値に基づいてプロセスをセグメント化することができます。例えば、ある金額を超える請求は、異なる、より手作業が多いプロセスパスをたどることが分析によって明らかになるかもしれません。 その重要性 プロセスに財務的な文脈を与え、プロセスのばらつきが収益にどう影響するかを分析できるようにし、改善すべき高価値なケースを優先するのに役立ちます。 取得元 R1 RCMの主要な請求または請求書ヘッダーテーブルにあり、多くの場合「TotalBilledAmount」などの名前で識別されます。 例 150.002500.7585.5012000.00 | |||
| サービスから支払いまでのサイクルタイム ServiceToPaymentCycleTime | サービスが提供されてから最終支払いが記帳されるまでの合計計算期間。 | ||
| 説明 このメトリクスは、単一の請求イベントに対する収益サイクルのエンドツーエンドの期間を測定します。これは、組織が提供されたサービスを現金に変換するのにかかる合計時間を表します。 これは、財務健全性にとって重要な主要業績評価指標(KPI)です。この期間を分析することで、プロセス加速のための主要な領域を特定するのに役立ちます。「請求までの時間」や「支払いまでの時間」など、サイクルタイムを構成要素に分解することで、組織はキャッシュフローを改善するための最大の機会を正確に特定できます。 その重要性 これは、キャッシュコンバージョンサイクルの全体的な効率を測定し、組織のキャッシュフローに直接影響を与える重要なハイレベルKPIです。 取得元 これは計算されたメトリクスです。特定の請求イベントにおいて、「サービス提供済み」活動のタイムスタンプと「支払記帳済み」活動のタイムスタンプ間の時間差です。 例 35日8時間92日4時間15日12時間 | |||
| サービスコード ServiceCode | CPTコードやHCPCSコードなど、提供された特定のサービスや処置に対する請求コード。 | ||
| 説明 CPT(Current Procedural Terminology)コードのようなサービスコードは、医療、外科、診断の手順やサービスを支払者に報告し、償還を受けるために使用される標準化された医療コードです。 サービスコードごとにプロセスを分析することは、特定のケアの種類に関連する請求問題を特定するために不可欠です。どの処置が最も頻繁に却下され、支払いサイクルが最も長く、または最も多くの手戻りが必要となるかを明らかにすることができ、コーディングおよび請求業務における的を絞った改善を可能にします。 その重要性 提供されたサービスの種類に基づいてプロセス分析を可能にします。これは、特定の処置に関連する却下パターンや支払い遅延を特定するための鍵となります。 取得元 この情報は、R1 RCM内の各料金または請求のラインアイテムレベルで見つかります。 例 992139928573560 | |||
| 回収結果 CollectionOutcome | 未収残高に対する回収活動の最終結果。 | ||
| 説明 この属性は、延滞勘定からの支払い回収努力の結果を記述します。可能な結果には、「全額支払い済み」、「和解済み」、「不良債権化」、「未解決」などがあります。 回収結果を追跡することは、回収プロセスの有効性を評価するために不可欠です。どの活動がどの結果につながるかを分析することで、組織は回収戦略を最適化し、回収率を向上させ、回収努力をいつ中止し残高を償却するかについて情報に基づいた意思決定を行うことができます。これは「回収活動パフォーマンスダッシュボード」をサポートします。 その重要性 期限超過口座の最終解決を追跡することで回収プロセスの有効性を測定し、回収戦略の最適化に役立ちます。 取得元 これは、患者勘定のステータスフィールド、またはR1 RCM内の専用回収モジュールにある可能性が高いです。 例 全額支払済み減額和解済み外部機関へ送付済み不良債権として償却済み | |||
| 患者ID PatientId | サービスを受けた患者の一意の識別子。 | ||
| 説明 この属性は、医療システム内で患者に割り当てられる一意のIDであり、多くの場合、診療記録番号(MRN)と呼ばれます。 個別の患者ケアは焦点ではありませんが、患者IDは、同じ患者にわたる経時的な繰り返しの請求問題を分析するために使用できます。また、他の患者データとリンクした場合、患者の人口統計や履歴によってプロセスをセグメント化するのに役立ち、特定の患者グループに影響を与えるシステム上の問題を明らかにする可能性があります。 その重要性 患者レベルでの請求イベント分析を可能にし、複数の診療にわたる特定の患者に関する繰り返しの問題やパターンを特定するのに役立ちます。 取得元 この識別子は、R1 RCMにおけるすべてのエンカウンターと請求にリンクされた患者の人口統計データの核心部分です。 例 MRN837262MRN937281MRN103847 | |||
| 手戻り IsRework | 却下された請求の再提出など、手戻りループの一部であるアクティビティを識別する計算済みのフラグ。 | ||
| 説明 この属性は、プロセスマイニング分析中に通常計算されるブールフラグです。活動が以前のステップの繰り返しである場合、またはエラー修正を示すシーケンスの一部である場合(例:「請求却下」に続くあらゆる活動)、このフラグは「真」となります。 手戻りを特定することは、プロセスマイニングの最も強力な機能の一つです。これは、プロセスにおける無駄な労力、時間、リソースの量を定量化します。手戻りをフラグ付けすることで、組織はまず手戻りの原因となるエラーを防ぐことに改善努力を集中でき、大幅な効率向上につながります。 その重要性 請求却下などの手戻りの頻度と影響を定量化するのに役立ち、非効率性と無駄な努力を削減するためのターゲットを絞った分析を可能にします。 取得元 これはソースシステム内のフィールドではありません。同じケースに対して「請求提出済み」活動が複数回発生したことを検出するなど、活動のシーケンスに基づいてプロセスマイニングツールによって計算されます。 例 truefalse | |||
| 自動化 IsAutomated | アクティビティが自動システムまたは人間ユーザーによって実行されたかどうかを示すフラグ。 | ||
| 説明 このブール属性は、請求提出のためのRPAボットのようなソフトウェア自動化によって実行されるタスクと、従業員が手作業で行うタスクを区別します。 この属性を分析することは、自動化イニシアチブの影響と有効性を理解する上で重要です。これにより、自動化されたプロセスと手動プロセスの速度、コスト、エラー率を比較することができ、自動化の新たな機会を特定し、既存のボットのROIを測定するのに役立ちます。 その重要性 人間によるアクティビティとシステム駆動のアクティビティを区別します。これは、プロセス効率、コスト、品質に対する自動化の影響を測定するために不可欠です。 取得元 これは、「AssignedUser」フィールドから導出できます。ここでは、特定のユーザーIDがボット用に予約されています(例:「BOT_RPA01」)。あるいは、一部のシステムには、自動化された取引をフラグ付けするための専用フィールドがあります。 例 truefalse | |||
| 調整理由 AdjustmentReason | 「契約上の控除」や「不良債権償却」など、財務調整が行われた理由。 | ||
| 説明 この属性は、勘定に財務調整が行われた理由に関するコンテキストを提供します。理由は、調整の種類を分類する標準化されたコードまたは説明であることがよくあります。 調整理由を分析することは、収益漏れの根本原因を診断するのに役立ちます。例えば、「少額残高償却」の頻度が高い場合、少額の回収プロセスが非効率であることを示唆する可能性がありますが、頻繁な「契約上の控除」は支払者交渉の予想される一部です。この分析は、「請求調整およびコンプライアンス監査ダッシュボード」をサポートします。 その重要性 収益調整の「理由」を説明し、契約上の問題、請求エラー、回収の失敗など、収益損失の根本原因を特定するのに役立ちます。 取得元 これは通常、R1 RCMのAdjustmentAmountと同じ取引記録内のコードまたはテキストフィールドです。 例 契約による控除不良債権償却少額残高償却請求エラー修正 | |||
| 調整金額 AdjustmentAmount | 勘定残高に対して行われた調整の金銭的価値。 | ||
| 説明 この属性は、初期請求後に行われた患者勘定への財務調整の値を捉えます。調整は正または負であり、契約上の控除、償却、または修正が含まれます。 調整額の追跡は、収益の完全性を理解するために不可欠です。高水準の負の調整は、不正確な料金計上や回収不能債務などの問題による収益漏れを示す可能性があります。このデータを分析することで、請求エラーや回収の非効率性が財務に与える影響を特定できます。 その重要性 収益漏れと財務修正を定量化し、請求の不正確さ、契約上の義務、または不良債権による金銭的影響を特定するのに役立ちます。 取得元 R1 RCMにおける口座調整または支払い記帳に関連するトランザクションログにあります。 例 -50.2520.00-1200.00 | |||
収益サイクルマネジメント活動
| アクティビティ | 説明 | ||
|---|---|---|---|
| サービス提供済み | 患者への請求可能なサービスまたは処置が完了した時点を表します。このイベントは、多くの場合、臨床システムやスケジュール管理システムから取得され、収益サイクルのトリガーとなります。 | ||
| その重要性 これは、サービスから支払いまでのサイクルタイムKPIの出発点です。このイベントからの時間を分析することは、収益サイクルにおけるフロントエンドの遅延を特定するのに役立ちます。 取得元 通常、電子医療記録(EHR)またはR1 RCMと統合された診療管理システムから取得されます。患者の記録にある「サービス日」または「処置完了」のタイムスタンプから推測されることがよくあります。 取得 患者の診察に関連する「サービス日」のタイムスタンプから推測されます。 イベントタイプ inferred | |||
| 入金確認済み | 支払者または患者から支払いを受領しました。このイベントは資金の受領を示しますが、資金はまだ特定の口座またはサービスラインに適用されていません。 | ||
| その重要性 これはキャッシュインフローを表します。「支払い受領」と「支払い記帳」の間の時間差は、バックオフィス業務の効率性と現金照合の遅延を理解するための重要な指標です。 取得元 支払者からの電子送金ファイル、または患者の支払い処理から取り込まれます。このイベントは入金日またはファイル受領日に対応します。 取得 ERAファイルの支払有効日、または患者の支払いのトランザクション日から記録されます。 イベントタイプ explicit | |||
| 口座閉鎖 | 請求イベントは残高ゼロで完全に解決され、勘定が正式に閉鎖されます。これは、この特定のエンカウンターにおける収益サイクルの完了を意味します。 | ||
| その重要性 これは、プロセスの主要な「ハッピーパス」の終了イベントです。勘定閉鎖サイクルタイムを測定することで、管理タスクが効率的に完了し、記録が確定されることを保証するのに役立ちます。 取得元 このイベントは、勘定残高がゼロになり、「クローズ済み」または「全額支払い済み」の最終ステータスが適用されたときに推測されます。タイムスタンプは、残高をゼロにした最後の財務取引から取得されます。 取得 口座残高がゼロになり、「閉鎖済み」ステータスが適用され、最終アクティビティタイムスタンプが付与された場合に推測されます。 イベントタイプ inferred | |||
| 支払い計上 | 受領した支払いは患者の勘定に正式に適用され、未収残高が減少します。これは、請求されたサービスとの支払いを照合する最終ステップです。 | ||
| その重要性 この活動は、「サービスから支払いまで」および「支払記帳」のサイクルタイムを計算するための終点を提供します。これにより、収益が認識され、勘定が正確に更新されていることが確認されます。 取得元 これは、R1 RCM患者会計モジュールで明示的な財務取引として記録されます。各記帳には日付、金額、およびソースが含まれます。 取得 ユーザーまたは自動化されたプロセスが支払いを適用した際に、記帳日とともに特定の取引として記録されます。 イベントタイプ explicit | |||
| 請求の提出 | 生成された請求は、保険会社などの担当支払者に電子的に提出されます。これは、償還を確保するための請求プロセスにおける最初の外部コミュニケーションとなります。 | ||
| その重要性 支払者による払い戻しの計時を開始する重要なマイルストーンです。これを追跡することで、提出の滞留を監視し、支払者への期限内の提出コンプライアンスを確保するのに役立ちます。 取得元 このイベントは、請求がクリアリングハウスに送信されたときに明示的な取引として記録されます。システムは提出タイムスタンプと確認の詳細をログに記録します。 取得 請求がクリアリングハウス経由で送信された際に、提出タイムスタンプを持つトランザクションとして明示的に記録されます。 イベントタイプ explicit | |||
| 請求取り込み済み | この活動は、患者との遭遇におけるすべての請求可能なサービス、処置、および消耗品の正式な記録を意味します。これは、臨床活動を財務取引に変換する重要なデータ入力ステップです。 | ||
| その重要性 臨床業務から財務業務への引き継ぎを示します。請求書および請求の生成サイクルタイムを測定し、請求入力の滞留を特定する出発点となります。 取得元 R1 RCMの請求入力モジュール内で取り込まれるか、EHRからのインターフェースを介して受信されます。このイベントは通常、特定のトランザクションログまたは請求レコードの作成タイムスタンプによってマークされます。 取得 請求テーブル内の請求トランザクションレコードの作成タイムスタンプによって識別されます。 イベントタイプ explicit | |||
| 不良債権処理 | すべての回収努力が尽くされ、残りの口座残高は回収不能と見なされます。この残高は不良債権として償却され、最終的な収益損失となります。 | ||
| その重要性 これは、負のプロセス結果と直接的な収益損失を表します。どのケースが不良債権になるかを分析することで、未払いのパターンと回収を改善する機会を明らかにできます。 取得元 これは通常、R1 RCMにおける明示的な取引であり、未収残高が特定の不良債権カテゴリに移動されるもので、多くの場合、ユーザーまたは自動の年齢構成ルールによってトリガーされます。 取得 残高を償却するための特定の財務取引として記録され、多くの場合、外部回収機関への移管に関連します。 イベントタイプ explicit | |||
| 却下手戻り開始 | ユーザーまたは自動化されたワークフローが、却下された請求の調査と解決を開始します。これには、コーディングの修正、書類の提出、または支払者の決定への異議申し立てが含まれる場合があります。 | ||
| その重要性 却下された請求に対する費用のかかる手戻りループの開始を追跡します。このフェーズに費やされた時間を測定することは、却下管理チームの効率性を理解するための鍵となります。 取得元 このイベントは、R1 RCMのワークキューまたは却下管理モジュール内で、却下された請求のステータスが「再作業中」または「レビュー中」に変更されたことから推測されることがよくあります。 取得 却下管理ワークキューのステータス変更、または却下された請求に対する最初のユーザーアクションから推測されます。 イベントタイプ inferred | |||
| 口座調整実施済み | 残高を変更するために、非支払い取引が口座に記帳されます。これには、支払者契約に基づく契約調整、少額残高の償却、または修正が含まれます。 | ||
| その重要性 大量の調整は、料金表、契約管理、または請求エラーに関する問題を示唆する可能性があります。調整を追跡することは、収益の整合性を分析するために不可欠です。 取得元 R1 RCMの患者会計モジュールで特定の取引タイプとして記録されます。各調整にはコード、金額、記帳日が含まれます。 取得 一意のトランザクションコードで識別可能な、明確な調整トランザクションとして記録されます。 イベントタイプ explicit | |||
| 回収活動開始済み | 患者の勘定が滞納状態になり、積極的な回収努力が開始されます。これは、自動リマインダーレターから回収専門家への引き渡しまで多岐にわたります。 | ||
| その重要性 費用のかかる回収プロセスの開始を示します。これらの活動の有効性とサイクルタイムを分析することで、不良債権回収戦略の最適化に役立ちます。 取得元 このイベントは、勘定が回収作業キューに移動されたとき、または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アプローチを使用し、さまざまなビジネスオブジェクトからのイベントを単一の時系列ログに結合します。
- このドキュメントの「クエリ」セクションに記載されている完全なクエリをコピーし、カスタムレポートのクエリエディタまたは設定インターフェースに貼り付けます。
- レポートパラメータ、特に日付範囲を設定します。クエリ内の
'{StartDate}'と'{EndDate}'プレースホルダーを設定し、抽出期間を定義します(例:過去6ヶ月)。 - 特定の施設、部門、または支払者グループでフィルタリングするなど、データの範囲を絞り込むために、レポート設定にその他の必要なフィルターを追加します。
- レポートを実行します。これにより、R1 RCMデータベースに対してクエリが実行され、指定されたパラメータに基づいて結果が生成されます。
- レポートの実行が完了したら、データをエクスポートするオプションを見つけます。ProcessMindと直接互換性があるため、エクスポート形式としてCSV(カンマ区切り値)を選択します。
- 生成されたCSVファイルをダウンロードし、開いて簡単な確認を行います。列ヘッダーが
BillingEvent、ActivityName、EventTime、SourceSystem、LastDataUpdateなどの必須属性と一致していることを確認します。 - ProcessMindにファイルをアップロードする前に、
EventTimeとLastDataUpdate列の日付と時刻の形式が一貫していることを確認します。
設定
- 前提条件: R1 RCMビジネスインテリジェンスモジュール内でカスタムレポートにアクセスし、作成するのに十分な権限を持つユーザーアカウントが必要です。
- レポートの種類: 複雑なデータ取得と、異なるデータセットを結合するためのUNION ALLステートメントの使用を可能にするカスタムクエリまたは高度なレポートビルダーを使用してください。
- 日付範囲: パフォーマンスとデータ量を管理するため、特定の期間でフィルタリングすることが重要です。最初の分析では3〜6か月の期間から始めることをお勧めします。各アクティビティのプライマリタイムスタンプフィールドに日付フィルターを適用します。
- 主要フィルター: 日付範囲に加えて、分析を特定の運用領域に集中させ、エクスポートサイズを削減するために、
施設ID、支払者タイプ、または請求部門のフィルター適用を検討してください。 - エクスポート形式: 出力形式として常にCSVを選択してください。これにより、クリーンで構造化されたファイルが確保され、プロセスマイニングツールで容易に解析できます。
- スケジュール設定: R1 RCMレポートモジュールがサポートしている場合、継続的な監視のためにデータ更新を自動化するために、このレポートを定期的に(例:毎週または毎月)実行するようにスケジュールすることを検討してください。
a クエリ例 config
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;