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

アクティビティ名は、「Claim Submitted To Payer」や「Payment Received」など、収益サイクルプロセスの各ステップを示します。この属性はプロセスマイニングの基礎となるもので、プロセスマップ上のノードを定義します。

アクティビティの順序と頻度を分析すると、実際のプロセスフローを可視化し、標準手順からの逸脱や、繰り返し発生する再作業ループを特定できます。この分析は、プロセスの非効率性とコンプライアンス上の問題を把握するうえで重要です。

プロセスの個々のステップを定義する属性であり、プロセスマップの基盤となるとともに、フローに基づくすべての分析を可能にします。

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

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

分析では、イベント時刻を使ってアクティビティ間のサイクル時間やケース期間を計算し、待機時間が長いボトルネックを特定します。時間に基づくプロセス分析とパフォーマンス測定の基盤となる情報です。

イベントを正しい順序に並べ、サイクル時間やボトルネックなど、期間に基づくすべての指標を計算するために欠かせないタイムスタンプです。

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

請求イベントは主要なケース識別子として機能し、料金が発生する単一のサービス提供または製品納入に関連するすべてのアクティビティを結び付けます。これにより、請求対象となる個々の項目またはサービスについて、収益の発生から回収、アカウント終了までのライフサイクルを詳細に追跡できます。

プロセスマイニングでは、請求イベント単位でプロセスを分析することで、サービス提供から最終支払いまたはアカウント終了までの一連の流れを確認できます。この視点は、ボトルネックの特定、サイクル時間の測定、請求やインボイスの処理方法の違いの把握に欠かせません。

関連する収益サイクルのすべてのアクティビティを結び付け、分析のための完全なエンドツーエンドのプロセスビューを可能にする、基本的なケースIDです。

Optum360の中核となる請求・請求審査テーブルでレコードを結び付ける主キーです。具体的なテーブル名と項目名については、Optum360のドキュメントを参照してください。

支払者が請求を否認すると、「Service Not Covered」や「Duplicate Claim」など、問題の内容を示す否認理由コードが提供されます。これらのコードは、収益の遅延と再作業の根本原因を把握するうえで重要です。

コードを分析すると、否認管理チームは対応の優先順位を付け、傾向を特定し、是正措置を実施できます。たとえば、「Missing Information」による否認が多い場合、請求作成プロセスに問題がある可能性があります。この分析は、否認率を下げ、キャッシュフローを早めるための中心的な取り組みです。

請求否認の根本原因を示し、将来の否認を防ぎ、コストのかかる再作業を減らすための的確な対策を可能にします。

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

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

患者IDを使うと、再入院の頻度や請求否認の履歴など、特定の患者に関するパターンを調査できます。また、患者の属性や履歴に基づいてプロセスを分類し、患者の金銭面での体験を改善するための重要な傾向を明らかにできます。

患者単位の分析を可能にし、患者集団ごとの金銭面での一連の流れやパターンを把握するのに役立ちます。

Optum360の患者マスターデータおよび取引テーブルにある主要項目です。詳細については、Optum360のドキュメントを参照してください。

支払者IDは、請求の支払い責任を負う特定の保険会社、MedicareやMedicaidなどの政府プログラム、またはその他の組織を識別します。支払者ごとに、独自のルール、提出要件、支払い傾向がある場合があります。

支払者ID単位でプロセスを分析することは、RCMにおいて重要です。支払いサイクルが最も長い支払者、否認率が最も高い支払者、異議申立てが最も複雑な支払者を特定できます。この情報により、請求部門は支払者ごとに戦略を調整し、回収を早め、事務負担を減らせます。

支払者ごとにプロセスを分類することで、遅延や否認の原因となる支払者を特定し、支払者管理を対象とした改善を進められます。

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

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

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

収益漏れを直接測定し、財務パフォーマンスKPIの計算と収益性の把握に欠かせません。

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

請求部門属性は、アクティビティを担当した収益サイクル業務内の具体的なチームまたは機能領域を示します。たとえば、コーディング、請求送信、否認管理を別々のチームが担当する場合があります。

この属性は、「Billing Department Performance Benchmarks」ダッシュボードが求めるパフォーマンス比較に欠かせません。経営層は、異なるチームの効率、処理速度、正確性を比較し、優れた方法を特定できます。また、パフォーマンスの差を埋めるために、リソースを適切に配分できます。

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

タスクを実行したユーザー、または担当を示すアカウント上の項目から取得される場合があります。Optum360のドキュメントを参照してください。

請求金額は、支払い、調整、償却が行われる前の、提供したサービスに対する総請求額です。請求イベントにおける売掛金の初期値にあたります。

この属性は、プロセスマイニングにおける財務分析の基礎となります。Revenue Adjustment Rateなどの主要KPIの計算に使われるほか、金額でケースを分類し、高額請求が低額請求と異なる処理を受けているか、より長い遅延が発生しているかを確認できます。

各ケースの財務的な背景を示し、金額に基づく分析と重要な財務KPIの計算を可能にします。

Optum360の財務テーブルにあるすべての請求または患者アカウントの標準項目です。

アカウントステータスは、請求イベントがプロセス全体のどの位置にあるかを示します。たとえば、「Pending Payer」、「Paid in Full」、「In Collections」などです。この属性により、実行中のアクティビティの背景を把握できます。

特定のプロセス部分に焦点を当てるため、ケースのフィルタリングや分類に役立ちます。たとえば、現在「In Collections」であるすべてのアカウントを分析すると、コストの大きい回収プロセスの要因と件数を把握でき、「Collection Activity Volume & Drivers」ダッシュボードを支援できます。

ケースの現在の状態を大まかに把握でき、回収中のケースなど、特定のケース集団を対象としたフィルタリングと分析が可能になります。

通常は、Optum360の主要な患者アカウントまたは請求レコードにある集約項目です。

ケース期間は、1つの請求イベントにおける最初のイベントから最後のイベントまでの経過時間を測定します。プロセス全体の効率を評価するための、主要な上位レベルKPIです。

この指標は、「RCM End-to-End Cycle Time Overview」ダッシュボードと「Average RCM Cycle Time」KPIを直接支援します。時間の推移を追跡することで、改善施策が収益サイクル全体に与えた影響を経営層が確認できます。

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

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

サービスコードは、患者に提供した手技またはサービスを正確に識別する標準化された医療コードです。請求に必要であり、償還額を決める主要な要素です。

サービスコード単位でプロセスを分析すると、特定の手技で否認が多い、より多くの文書が必要、支払いサイクルが長いといった傾向を明らかにできます。これにより、プロセス上の課題をより細かく把握し、サービスの種類に応じたコーディングや請求方針の策定に役立てられます。

医療サービスの種類に基づく分析を可能にし、特定の手技に固有の否認や支払い遅延のパターンを明らかにできます。

Optum360の料金入力レコードと請求明細レコードに含まれる基本項目です。

この属性は、医師、セラピスト、病院部門など、サービスの提供を担当した具体的な提供者を示します。提供者によって請求のパターンや文書化の方法が異なり、収益サイクルに影響する場合があります。

サービス提供者単位で分析すると、サービス提供時点に起因する料金取得、コーディングの正確性、文書品質の問題を特定できます。また、提供者への教育やプロセス改善の機会を明らかにし、最初から不備のない請求を作成できるようにします。

請求上の問題を発生源まで追跡し、臨床スタッフへの的確なフィードバックと研修を通じて、料金取得と文書化を改善できます。

Optum360の料金または請求レコードに含まれる主要情報で、通常は提供者マスターデータと関連付けられています。

特定のイベントのデータがどのソースシステムから抽出されたかを示す属性です。複雑なIT環境では、RCMデータがOptum360の中核プラットフォーム、接続された電子健康記録（EHR）システム、クリアリングハウス、または患者ポータルから取得される場合があります。

ソースシステムを把握すると、データの検証や連携問題のトラブルシューティングに役立ちます。また、システムの動作やデータ入力方法の違いによって生じるプロセスの差異も分析できます。

データの出所を示します。データガバナンス、品質評価、異なるシステム間でのプロセスの差異を理解するうえで重要です。

データ抽出時に設定される固定値、またはデータの出所を示すソーステーブル内の項目である場合があります。

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

どのユーザーまたはチームが操作を実行したかを把握すると、生産性、品質、標準手順の遵守状況を評価できます。研修の必要性を特定したり、成果の高い個人やチームを評価したりする際にも役立ちます。また、手作業で実行されたタスクと自動化されたタスクを区別できます。

プロセスステップの担当を明確にし、個人またはチーム単位のパフォーマンス分析を可能にします。リソース管理と研修に欠かせない情報です。

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

Is Reworkは、否認再作業の開始や異議申立ての送信など、付加価値を生まない再作業とみなされるアクティビティを識別するブール型フラグです。これらのアクティビティは通常、理想的な「ハッピーパス」からプロセスが外れた場合に発生します。

この属性により、プロセス内の再作業量を定量化できます。再作業量は、非効率性とコストを直接示す指標です。「Billing Error Rework Rate」KPIの計算に使われるほか、「Bottleneck Identification & Rework Loops」ダッシュボードで、非効率なループを簡単にフィルタリングして可視化できます。

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

通常は、プロセスマイニングツール内の業務ロジックを使って導出されます。たとえば、「Denial Received」イベントの後に続くアクティビティを再作業としてフラグ付けできます。

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

アナリストや業務ユーザーが、最新の情報を見ているかどうかを確認するうえで重要です。データの遅延に対する期待値の管理にも役立ち、分析プロジェクトにおける重要なメタデータとなります。

データの鮮度に関する重要な情報を提供し、分析がどの程度最新の状態かを把握できるようにします。

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

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

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

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

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

終了時刻はアクティビティの完了時点を示します。開始時刻がイベントの発生時点を示すのに対し、終了時刻は、「Denial Rework Started」からその完了までのように、明確な処理時間を持つアクティビティの期間を計算するために必要です。

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

アクティビティの正確な処理時間を計算できるため、プロセス内の実作業時間と待機時間を区別するのに役立ちます。

アクティビティによっては、ソースシステムに独立したタイムスタンプ項目として保存されています。それ以外の場合は、後続アクティビティの開始時刻から推定する必要があります。