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

アクティビティ名は、「支払者への請求提出」や「入金受領」など、収益サイクルプロセスの各ステップを表します。プロセスマイニングでは、プロセスマップのノードを定義する基本的な属性です。

アクティビティの順序や発生頻度を分析すると、実際のプロセスの流れを可視化し、標準手順からの逸脱や、よく発生する手戻りを特定できます。プロセスの非効率な部分やコンプライアンス上の問題を把握するうえで、欠かせない分析です。

この属性はプロセスの各ステップを定義し、プロセスマップの基礎となるとともに、フローに基づくすべての分析を可能にします。

通常、イベントログ、ステータス変更記録、またはOptum360の業務テーブルにある特定の取引コードから取得します。

イベント時刻は各アクティビティに関連付けられたタイムスタンプで、発生した日付と時刻を正確に示します。この時系列データは、ケースごとのイベントの順序を構成するために欠かせません。

分析では、アクティビティ間のサイクルタイムやケースの所要時間の算出、待ち時間が長いボトルネックの特定に使用します。時間に基づくプロセス分析や実績測定の基盤となるデータです。

イベントを正しい順序に並べ、サイクルタイムやボトルネックなど、所要時間に基づく指標を算出するうえで欠かせないタイムスタンプです。

通常、Optum360のデータベーステーブルで、各取引またはステータス変更の記録とともに保存されています。

請求イベントは主なケース識別子として、請求が発生する個々のサービス提供または製品納品に関連するすべてのアクティビティを結び付けます。これにより、請求対象となる個々の項目やサービスについて、収益の発生から回収までの全過程を追跡できます。

プロセスマイニングで請求イベントごとに分析すると、サービス提供から最終入金または口座精算までの一連の流れを把握できます。この視点は、ボトルネックの特定、サイクルタイムの測定、請求や請求書の処理方法の違いの把握に役立ちます。

これは、収益サイクルに関するすべてのアクティビティを結び付け、分析に必要なプロセス全体を把握するための基本となるケースIDです。

Optum360の主要な請求テーブルと請求データテーブルのレコードを結び付ける主キーです。具体的なテーブル名とフィールド名は、Optum360の文書で確認してください。

支払者が請求を否認すると、「サービス対象外」や「請求の重複」など、問題の内容を示す否認理由コードが通知されます。これらのコードは、収益の遅延や手戻りの根本原因を把握するうえで重要です。

コードを分析すると、否認管理チームは対応の優先順位を決め、傾向を特定し、是正措置を講じられます。たとえば、「情報不足」による否認が多い場合、請求作成プロセスに問題がある可能性があります。こうした分析は、否認率の低減とキャッシュフローの改善に直結します。

請求否認の根本原因を把握し、的を絞った対策によって再発を防ぎ、コストのかかる手戻りを減らせます。

このコードは、支払者から受け取る電子送金通知（ERA）ファイルに含まれ、Optum360の請求管理モジュールに保存されます。

患者IDは、医療システム内で患者ごとに割り当てられる固有の識別子です。複数の請求イベントを同一患者に結び付け、患者単位の分析を可能にします。

患者IDを使うと、再入院の頻度や請求否認の履歴など、特定の患者に関する傾向を調べられます。また、患者の属性や履歴に基づいてプロセスを分類できるため、患者の支払い体験を改善するための重要なインサイトが得られます。

患者単位で分析し、支払いまでの全過程を把握するとともに、特定の患者集団に見られる傾向を特定できます。

Optum360の患者マスターデータや取引テーブルにある基本フィールドです。詳細はOptum360の文書で確認してください。

支払者IDは、特定の保険会社、メディケアやメディケイドなどの政府プログラム、または請求の支払いを担うその他の組織を識別します。支払者ごとに、独自の規則、提出要件、支払い傾向があることが少なくありません。

支払者ID別にプロセスを分析することは、RCMにおいて重要です。支払いサイクルが最も長い支払者、否認率が最も高い支払者、異議申し立ての手続きが最も複雑な支払者を特定できます。こうした分析結果をもとに、請求部門は支払者ごとに対応を調整し、回収を早め、事務負担を軽減できます。

支払者別にプロセスを分類すると、遅延や否認の原因となっている支払者を特定でき、支払者管理の改善に向けた対策を講じやすくなります。

この情報は、Optum360の各請求レコードに保存されています。支払者に関連するテーブル名やフィールド名については、Optum360の文書をご確認ください。

調整額は、支払者との契約、請求内容の訂正、その他の償却により、回収が見込まれない請求額の一部を示します。収益を直接減少させる金額です。

この属性は、「収益調整の影響」ダッシュボードと「収益調整率」KPIに欠かせません。調整額を分析すると、支払者との契約が財務に与える影響を把握し、請求精度の向上や契約交渉を通じて収益の流出を抑える機会を見つけられます。

収益の流出を直接測定します。財務パフォーマンスKPIの算出や収益性の把握に欠かせません。

この情報は、Optum360の財務システムにある調整取引レコードで確認できます。

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

この属性は、「請求部門のパフォーマンスベンチマーク」ダッシュボードで求められるパフォーマンス比較に欠かせません。各チームの効率、処理速度、正確性を比較し、優れた取り組みを特定できます。さらに、パフォーマンスの差を埋めるためのリソース配分にも役立ちます。

請求チーム間のパフォーマンスを比較し、成果を上げているチームや改善が必要な領域を特定できます。

タスクを実行したユーザーや、担当者を示すアカウント上のフィールドから特定できる場合があります。詳しくはOptum360の文書をご確認ください。

請求額は、支払いや調整、償却を行う前のサービス料金の総額です。請求イベントにおける売掛金の初期値を示します。

この属性は、プロセスマイニングで財務分析を行う際の基本情報です。収益調整率などの重要業績評価指標（KPI）の算出に使えるほか、金額別にケースを分類し、高額請求が低額請求と異なる処理を受けているか、遅延が多いかを確認できます。

各ケースの財務状況を把握し、金額に基づく分析や重要な財務KPIの算出に役立ちます。

Optum360の財務テーブルでは、すべての請求または患者アカウントに標準項目として記録されています。

アカウントの状態は、「支払者の処理待ち」「全額支払い済み」「回収中」など、請求イベントがプロセスのどの段階にあるかを示します。この属性により、実行中のアクティビティを把握しやすくなります。

ケースの絞り込みや分類に使うと、プロセスの特定の部分に焦点を当てて分析できます。たとえば、現在「回収中」のアカウントを分析すれば、コストのかかるこのプロセスの要因や件数を把握でき、「回収業務の件数と要因」ダッシュボードの分析に役立ちます。

ケースの現在の状態を大まかに把握し、回収中のケースなど、特定の集団に絞った分析を行えます。

通常、Optum360の患者アカウントまたは請求レコードの概要項目です。

ケース所要時間は、1件の請求イベントで最初に発生したイベントから最後に発生したイベントまでの経過時間を測定します。プロセス全体の効率を評価するための主要なKPIです。

この指標は、「RCMのエンドツーエンドサイクルタイム概要」ダッシュボードと「RCM平均サイクルタイム」KPIに対応しています。時間の経過に沿って追跡すると、改善施策が収益サイクル全体に与えた影響を確認できます。

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

一意の「BillingEvent」ケースIDごとに、最初のイベントのタイムスタンプを最後のイベントのタイムスタンプから差し引いて算出します。

サービスコードは、患者に提供した処置やサービスを正確に特定する標準医療コードです。請求に必要であり、支払額を決める主要な要素です。

サービスコード別にプロセスを分析すると、特定の処置で否認が多い、文書化の量が多い、支払いサイクルが長いといった傾向が見つかる場合があります。プロセス上の課題をより細かく把握し、サービスの種類に応じたコーディングや請求の方針を検討できます。

医療サービスの種類ごとに分析し、特定の処置に固有の否認や支払い遅延の傾向を把握できます。

Optum360の請求入力レコードおよび請求明細レコードを構成する基本項目です。

この属性は、医師、セラピスト、病院の診療科など、サービスの提供を担った提供者を特定します。提供者によって請求の傾向や文書化の方法が異なり、収益サイクルに影響する場合があります。

サービス提供者別に分析すると、診療現場で生じた請求漏れ、コーディングの正確性、ドキュメント品質に関する問題を特定しやすくなります。また、提供者への教育やプロセス改善の機会を見つけ、最初から不備のない請求を作成できるよう支援します。

請求に関する問題の発生源をたどり、医療スタッフへの的を絞ったフィードバックや研修につなげることで、請求漏れや文書化の改善に役立ちます。

この情報は、Optum360の請求または請求明細レコードの主要項目であり、多くの場合、提供者マスターデータと関連付けられています。

この属性は、特定のイベントのデータを抽出したソースシステムを示します。複雑なIT環境では、RCMデータの取得元として、Optum360の中核プラットフォーム、連携された電子カルテ（EHR）、クリアリングハウス、患者ポータルなどが考えられます。

ソースシステムを把握すると、データの検証や連携の問題の調査に役立ちます。また、システムの動作やデータ入力方法の違いによるプロセスの差異も分析できます。

データの取得元を示します。データガバナンスや品質評価、異なるシステム間のプロセスの違いを把握するうえで重要です。

データ抽出時に設定する固定値の場合と、データの取得元を示すソーステーブル内のフィールドの場合があります。

ユーザー属性は、特定のアクティビティを実行した担当者、チーム、または自動化ボットを識別します。個人またはグループ単位でパフォーマンスを分析できます。

アクションを実行したユーザーやチームを把握すると、生産性、品質、標準手順の遵守状況を評価するうえで役立ちます。研修が必要な領域を特定したり、成果を上げている個人やチームを評価したりできます。また、手作業で行ったタスクと自動化によって処理されたタスクを区別できます。

プロセスの各ステップの担当を明確にし、個人またはチーム別のパフォーマンス分析を可能にします。リソース管理や研修に役立ちます。

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

この属性には、ソースシステムからデータを最後に抽出し、プロセスマイニングツールに読み込んだ日時が記録されます。分析対象データの鮮度を把握するための情報です。

分析担当者や業務ユーザーが、最新の情報を見ているかどうかを判断するのに役立ちます。データの反映にかかる時間について認識を共有でき、分析プロジェクトに必要なメタデータの1つとなります。

データの鮮度に関する重要な情報を示し、分析結果がどの程度最新かを把握できます。

通常、データの抽出、変換、読み込み（ETL）プロセスによって生成・保存されるタイムスタンプです。

手戻りの有無は、「否認後の手戻り開始」や「異議申し立ての提出」など、付加価値を生まない手戻りとみなされるアクティビティを識別する真偽値フラグです。こうしたアクティビティは通常、プロセスが理想経路から外れたときに発生します。

この属性を使うと、プロセス内の手戻りの量を定量化できます。手戻りは、非効率性やコストを直接示す指標です。「請求エラー手戻り率」KPIの算出に使えるほか、「ボトルネックの特定と手戻りループ」ダッシュボードで、非効率なループを簡単に絞り込み、可視化できます。

手戻りに該当するアクティビティにフラグを付けてプロセスの非効率性を定量化し、無駄の測定と削減に役立てます。

通常、プロセスマイニングツール内の業務ロジックから算出します。たとえば、「否認通知の受領」イベント以降のアクティビティを手戻りとして判定できます。

支払額は、特定の請求イベントについてアカウントに記録されたすべての支払いの累計です。実際に回収した現金を示し、収益サイクルの成果を測る主要な指標となります。

プロセス分析では、キャッシュフローと財務パフォーマンス全体を把握するために、支払額を追跡することが欠かせません。支払いの速度を分析したり、請求額と回収額を比較したりすることで、過少支払いや回収不能債権の問題を把握できます。

実際の回収額を示します。RCMプロセスの成果を測る主要指標であり、キャッシュフロー分析にも欠かせません。

通常、Optum360の支払い取引テーブルに保存されるか、アカウント単位で集計されます。

終了時刻は、アクティビティが完了した時刻を示します。開始時刻がイベントの発生時刻を示すのに対し、終了時刻は「否認対応の手戻り開始」からその完了までのように、処理時間が明確なアクティビティの所要時間を算出するために必要です。

プロセス分析では、アクティビティの開始時刻と終了時刻を比較して処理時間を算出します。これにより、実際に作業している時間と、アクティビティ間の待ち時間を区別し、プロセスの効率を詳しく把握できます。

アクティビティの処理時間を正確に算出し、プロセス内の実作業時間と待ち時間を区別できます。

アクティビティによっては、ソースシステムに独立したタイムスタンプフィールドがあります。別のアクティビティの開始時刻から推定する場合もあります。