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

アクティビティ名とは、「支払者に請求提出済み」や「支払い受領済み」など、レベニューサイクルプロセスにおけるステップを説明するものです。この属性は、プロセスマイニング内のノードを定義するため、プロセスマイニングにとって不可欠です。

活動の順序と頻度を分析することで、組織は実際のプロセスフローを可視化し、標準手順からの逸脱を特定し、一般的な手戻りループを正確に指摘できます。この分析は、プロセスの非効率性やコンプライアンス問題を理解するための鍵となります。

この属性はプロセスの個々のステップを定義し、プロセスマップの基礎を形成し、すべてのフローベース分析を可能にします。

これは通常、Optum360の運用テーブル内のイベントログ、ステータス変更レコード、または特定のトランザクションコードから導出されます。

イベントタイムは、各活動に関連付けられたタイムスタンプであり、その発生の正確な日時を示します。この時間データは、各ケースのイベントの時系列順序を構築するために不可欠です。

分析では、イベントタイムは活動間のサイクルタイムの計算、ケース期間の測定、およびかなりの時間が待機に費やされるボトルネックの特定に使用されます。これは、時間ベースのプロセス分析とパフォーマンス測定のバックボーンです。

このtimestampは、eventを正しく順序付けし、cycle timeやbottleneckなどのすべての期間ベースのメトリクスを計算するために不可欠です。

この情報は通常、Optum360のデータベーステーブル内の各トランザクションまたはステータス変更レコードと共に保存されます。

請求イベントは主要なケース識別子として機能し、単一のサービス提供または製品納品によって発生するすべての活動をリンクします。これにより、個々の請求可能項目またはサービスごとの収益生成および回収ライフサイクルを包括的に追跡できます。

プロセスマイニングでは、請求イベント別にプロセスを分析することで、サービス提供から最終支払いまたは口座クローズまでのエンドツーエンドの全過程を組織が把握できます。この視点は、ボトルネックの特定、サイクルタイムの測定、および異なる請求書やインボイスがどのように処理されるかの変動を理解する上で非常に重要です。

これは、すべての関連する収益サイクル活動を接続する不可欠なケースIDであり、分析のための完全なエンドツーエンドのプロセスビューを可能にします。

これは、Optum360のコア請求およびクレームテーブル内のレコードをリンクする主キーです。特定のテーブル名とフィールド名については、Optum360のドキュメントを参照してください。

支払者が請求を否認する際、「サービス対象外」や「重複請求」などの問題点を説明する否認理由コードが提供されます。これらのコードは、収益遅延や再作業の根本原因を理解する上で不可欠です。

これらのコードを分析することで、否認管理チームは作業の優先順位を決定し、傾向を特定し、是正措置を実施できます。例えば、「情報不足」による否認が頻繁に発生する場合、請求作成プロセスに問題がある可能性を指摘できます。この分析は、否認率を低減し、キャッシュフローを加速させる上で中心的な役割を果たします。

請求却下の根本原因を提供し、将来の却下を防ぎ、高コストな手戻りを削減するためのターゲットを絞った介入を可能にします。

このコードは、支払者から受信する電子送金アドバイス（ERA）ファイルに含まれており、Optum360の請求管理モジュールに保存されます。

患者IDは、医療システム内の各患者に割り当てられる一意の識別子です。複数の請求イベントを1人の患者にリンクさせ、患者中心の分析を可能にします。

患者IDを使用することで、アナリストは頻繁な再入院や請求否認の履歴など、特定の患者に関連するパターンを調査できます。また、患者の人口統計や履歴に基づいてプロセスをセグメンテーションすることも可能になり、患者の財務体験を改善するための重要な洞察を明らかにできます。

患者中心の分析を可能にし、エンドツーエンドの財務プロセスを理解し、特定の患者集団のパターンを特定するのに役立ちます。

この識別子は、Optum360内の患者マスターデータおよびトランザクションテーブルにおけるコアフィールドです。詳細についてはOptum360のドキュメントを参照してください。

支払者IDは、特定の保険会社、メディケアやメディケイドのような政府プログラム、または請求の支払い責任を負うその他のエンティティを識別します。各支払者は、独自の規則、提出要件、支払い行動を持つことが多いです。

RCMにおいて、支払者ID別にプロセスを分析することは極めて重要です。これにより、どの支払者が最も長い支払いサイクル、最高の否認率、または最も複雑な異議申し立てプロセスを持つかを特定できます。この洞察により、請求部門は回収速度を向上させ、管理負担を軽減するために、異なる支払者に対して戦略を調整できるようになります。

支払者ごとにプロセスをセグメント化することは、どの支払者が遅延や却下を引き起こしているかを特定するために不可欠であり、支払者管理におけるターゲットを絞った改善を可能にします。

この情報は、Optum360内の各請求レコードに保存されています。支払者関連のテーブル名とフィールド名については、Optum360のドキュメントを参照してください。

請求部門属性は、収益サイクル業務内で特定のアクティビティを担当するチームまたは機能領域を識別します。例えば、コーディング、請求提出、否認管理などは異なるチームが担当する場合があります。

この属性は、「請求部門パフォーマンスベンチマーク」ダッシュボードで求められるパフォーマンスベンチマークにとって不可欠です。これにより、リーダーシップは異なるチームの効率、速度、精度を比較し、ベストプラクティスを特定し、パフォーマンスのギャップに対処するためにリソースを効果的に配分できます。

異なる請求チーム間でのパフォーマンス比較を可能にし、高パフォーマンスのグループと改善が必要な領域を特定するのに役立ちます。

これは、タスクを実行するユーザー、または所有権を示す口座のフィールドから導出される場合があります。Optum360のドキュメントを参照してください。

調整済み金額は、支払者との契約、請求修正、またはその他の償却により、請求金額のうち回収が見込まれない部分を指します。これは収益の直接的な減少となります。

この属性は、「収益調整インパクト」ダッシュボードおよび「収益調整率」KPIにとって重要です。調整額を分析することで、支払者契約が財務に与える影響を特定し、請求精度の向上や契約交渉を通じて収益の漏れを最小限に抑える機会を見つけるのに役立ちます。

収益漏洩を直接測定し、財務パフォーマンスKPIの計算と収益性の理解にとって極めて重要です。

この情報は、Optum360の財務システム内の調整トランザクションレコードに含まれています。

請求額は、支払い、調整、または償却前の、提供されたサービスに対する総費用を表します。これは、請求イベントに対する売掛金の初期値です。

この属性は、プロセスマイニングにおける財務分析の基礎となります。収益調整率のような主要なKPIの計算に使用され、高額請求が低額請求と異なる処理を受けるか、より多くの遅延を経験するかを確認するために、ケースを金額別にセグメント化することを可能にします。

各ケースの財務コンテキストを提供し、価値ベースの分析と重要な財務KPIの計算を可能にします。

これは、Optum360の財務テーブル内のすべての請求または患者口座の標準フィールドです。

アカウントステータスは、「支払者保留中」、「全額支払い済み」、または「債権回収中」など、請求イベントがプロセス全体の中でどの段階にあるかを示すスナップショットを提供します。この属性は、実行されている活動に文脈を与えます。

これは、特定のプロセス部分に焦点を当てるためにケースをフィルタリングおよびセグメント化するのに役立ちます。例えば、現在「債権回収中」のすべてのアカウントを分析することで、その特定の高コストなプロセス部分の要因と量を理解するのに役立ち、「債権回収活動量と要因」ダッシュボードをサポートします。

ケースの現在の状態に関する高レベルのコンテキストを提供し、債権回収中のケースなど、特定のケース集団のフィルタリングと分析を可能にします。

これは通常、Optum360の主要な患者口座または請求レコードのサマリーフィールドです。

ケース期間は、単一の請求イベントについて、最初のイベントから最後のイベントまでの経過時間全体を測定します。これは、プロセス全体の効率性を評価するための主要な高レベルKPIです。

この指標は、「RCMエンドツーエンドサイクルタイム概要」ダッシュボードおよび「平均RCMサイクルタイム」KPIを直接サポートします。これを経時的に追跡することで、リーダーシップは収益サイクル全体に対する改善イニシアティブの影響を確認できます。

プロセスのエンドツーエンドサイクルタイムを表し、プロセス全体の速度と効率を測定するための重要なKPIです。

これは、各ユニークな「BillingEvent」ケースIDについて、最初のイベントのタイムスタンプを最後のイベントのタイムスタンプから減算することで計算されます。

サービスコードは、患者に提供された処置またはサービスを正確に識別する標準化された医療コードです。これらのコードは請求に必須であり、償還額を決定する主要な要素となります。

サービスコード別にプロセスを分析することで、特定の処置が否認されやすい、より多くの文書を必要とする、または支払いサイクルが長いといった傾向を明らかにできます。これにより、プロセスの課題をより詳細に理解できるようになり、特定の種類のサービスに対するコーディングおよび請求ポリシーの策定に役立てることができます。

医療サービスの種類に基づいた分析を可能にし、特定の処置に特有の却下または支払い遅延のパターンを明らかにすることができます。

このコードは、Optum360における料金入力および請求詳細レコードの基本的な部分です。

この属性は、医師、セラピスト、病院部門など、サービス提供を担当する特定のプロバイダーを識別します。プロバイダーによって、収益サイクルに影響を与える異なる請求パターンや文書作成習慣がある場合があります。

サービスプロバイダー別に分析することで、料金請求、コーディングの正確性、または文書品質に関連する、ケアの時点で発生する問題を特定できます。これは、プロバイダー教育やプロセス改善の機会を強調し、最初からクリーンな請求が生成されることを確実にするのに役立ちます。

請求の問題を発生源まで遡って追跡するのに役立ち、料金捕捉と文書化を改善するための臨床スタッフへのターゲットを絞ったフィードバックとトレーニングを可能にします。

この情報は、Optum360の請求またはクレームレコードの重要な一部であり、多くの場合、プロバイダーマスターデータにリンクされています。

この属性は、特定のイベントのデータが抽出されたソースシステムを識別します。複雑なIT環境では、RCMデータはコアのOptum360プラットフォーム、連携された電子カルテ（EHR）システム、クリアリングハウス、または患者ポータルから来る可能性があります。

ソースシステムを理解することは、データ検証、統合問題のトラブルシューティング、および異なるシステム動作やデータ入力慣行によって引き起こされる可能性のあるプロセスの変動を分析するのに役立ちます。

データの出所を特定します。これは、データガバナンス、品質評価、および異なるシステム間でのプロセス変動を理解するために極めて重要です。

これは、データ抽出中に設定される静的値であるか、またはデータの発生元を示すソーステーブル内のフィールドである可能性があります。

ユーザー属性は、特定のアクティビティの実行を担当する個人、チーム、または自動化されたボットを識別します。これにより、個人またはグループレベルでのパフォーマンス分析が可能になります。

どのアクションをどのユーザーまたはチームが実行したかを理解することは、生産性、品質、および標準手順への準拠を評価する上で貴重です。これは、トレーニングの必要性を特定したり、高いパフォーマンスを発揮する個人やチームを認識したりするのに役立ちます。また、手動で実行されたタスクと自動化によって処理されたタスクを区別するのにも役立ちます。

プロセスステップの責任を割り当て、個人またはチームによるパフォーマンス分析を可能にします。これはリソース管理とトレーニングにとって重要です。

ユーザーIDは通常、Optum360のレコードの監査ログまたは取引履歴に記録されます。

この属性は、データがソースシステムから最後に抽出され、プロセスマイニングツールにロードされた日時を記録します。これにより、分析されているデータの鮮度に関するコンテキストが提供されます。

これは、アナリストやビジネスユーザーが最新の情報を閲覧しているかどうかを理解するために重要です。データの遅延に関する期待値を管理するのに役立ち、あらゆる分析プロジェクトにとって重要なメタデータの一部となります。

データの鮮度に関する重要なコンテキストを提供し、ユーザーが分析の最新性を理解できるようにします。

このタイムスタンプは通常、データ抽出、変換、ロード（ETL）プロセスによって生成および保存されます。

処理時間は、個々の活動の期間を測定し、「作業時間」または実行されたアクティブな作業を表します。これは通常、活動の終了時間と開始時間の差として計算されます。

この計算された指標は、タスクで積極的に作業に費やされた時間と次のステップを待機するために費やされた時間を区別するために重要です。ボトルネック分析では、処理時間を理解することで、遅延が長いタスクによるものか、長いキューによるものかを判断するのに役立ち、より効果的なプロセス改善につながります。

活動の実際の「作業時間」を測定し、ボトルネック分析において付加価値のある作業と無駄な待機時間を区別するのに役立ちます。

これは、指定されたアクティビティレコードの「EndTime」から「EventTime」（StartTime）を減算することで計算されます。

「手戻り」は、却下手戻り開始」や「異議申し立て提出済み」など、付加価値のない手戻りと見なされる活動を識別するブール値フラグです。これらの活動は通常、プロセスが理想的な「ハッピーパス」から逸脱した場合に発生します。

この属性は、プロセスにおける手戻りの量を定量化するのに役立ち、非効率性とコストの直接的な指標となります。「請求エラー手戻り率」KPIの計算に使用され、これらの非効率なループを簡単にフィルタリングして可視化できるようにすることで、「ボトルネック特定と手戻りループ」ダッシュボードをサポートします。

手戻りを表す活動にフラグを立てることで、プロセスの非効率性を定量化するのに役立ち、無駄の測定とターゲット設定を容易にします。

これは通常、プロセスマイニングツール内のビジネスロジックを使用して導出されます。たとえば、「否認受領」イベントに続く任意のアクティビティは再作業としてフラグ付けされる可能性があります。

支払済み金額は、特定の請求イベントに対して口座に計上されたすべての支払いの累積合計です。これは実際に回収された現金を表し、収益サイクルの成功を測る主要な指標となります。

プロセス分析において、支払済み金額の追跡はキャッシュフローと全体的な財務実績を理解するために不可欠です。支払速度を分析したり、請求金額と回収金額を比較したりすることで、過少支払いまたは回収不能債権に関する問題を浮き彫りにすることができます。

実際に回収された現金額を表し、RCMプロセスの主要な成果指標であり、キャッシュフロー分析に不可欠です。

この値は通常、支払いトランザクションテーブルに保存されるか、Optum360で口座レベルで要約されます。

終了時間はアクティビティの完了を示します。開始時間がイベント発生時を示すのに対し、終了時間は「否認再処理開始」とその完了など、明確な処理時間を持つアクティビティの期間を計算するために必要です。

プロセス分析では、アクティビティの開始時間と終了時間を比較することで処理時間を計算できます。これにより、実作業時間（処理時間）とアイドル時間（アクティビティ間の待機時間）を区別し、プロセス効率をより詳細に把握できます。

正確な活動処理時間の計算を可能にし、プロセスにおけるアクティブな作業時間とアイドル状態の待機時間を区別するのに役立ちます。

一部の活動では、これはソースシステム内の個別のタイムスタンプフィールドである場合があります。他の活動では、後続の活動の開始時刻から推測する必要がある場合があります。