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

アクティビティ名は、収益サイクルのライフサイクルにおける個別のアクションまたは節目を表します。例として、「Service Rendered」「Claim Submitted」「Remittance Received」「Payment Posted」「Account Written Off」などがあります。それぞれのアクティビティは、時間とリソースを要するプロセス上の1つのステップです。

この属性は、プロセスマップのノードを定義するため、プロセスマイニングの基本となります。アクティビティの順序、頻度、所要時間を分析することで、実際のプロセスフローを可視化し、設計モデルと比較できます。また、請求否認などの逸脱や再処理ループ、非効率な箇所を特定できます。

この属性によってプロセスのステップが定義されるため、プロセスマップの発見と可視化、再処理の特定、プロセス適合性の分析に欠かせません。

イベントログ、トランザクションテーブル、または請求・請求審査モジュールのステータス変更記録から取得できます。

イベントタイムスタンプは、アクティビティが発生または記録された時点を示します。ケース内のすべてのイベントに時系列上の位置付けを与え、収益サイクルの開始から終了までのタイムラインを形成します。

タイムスタンプは、プロセスマイニングにおけるパフォーマンス分析の基盤です。総サイクル時間、特定のアクティビティ間の所要時間、待機時間など、重要なKPIの計算に使われます。タイムスタンプを分析すると、ケースが最も長く滞留するボトルネックを特定し、サービスレベル合意の遵守状況を測定し、プロセスの時間的な動きを把握できます。

サイクル時間の計算、ボトルネックの特定、プロセスのパフォーマンスと効率の分析に必要な時系列データを提供します。

通常は、トランザクションログ、監査証跡、またはイベントテーブルの「creation date」や「status change date」フィールドから取得できます。

請求イベントIDは、請求対象サービスの各インスタンスに割り当てられる一意のキーです。最初の請求取得から最終的な支払いまたは償却まで、請求作成、送信、否認、支払計上など、特定のサービス提供に関連するすべてのアクティビティをつなぐ中心的な識別子として機能します。

プロセスマイニングでは、この属性が各請求イベントのエンドツーエンドの流れを再構成するうえで重要です。関連するすべてのアクティビティを1つの請求イベントIDにまとめることで、分析担当者はプロセスフローを可視化し、ボトルネックを特定し、サイクル時間を測定できます。また、ケースごとの対応方法の違いも把握できます。これは、収益サイクルにおけるケース中心の分析の基盤となります。

関連するすべてのアクティビティをつなぐ基本的なケース識別子であり、請求対象サービスごとの収益サイクル全体を再構成して分析できます。

通常は、請求取引テーブルまたは財務イベントテーブルの主キーです。

ソースシステム属性は、特定のイベントデータの発生元を示します。複雑なIT環境では、収益サイクルプロセスが複数のシステムにまたがることがよくあります。たとえば、サービス提供には電子健康記録（EHR）システム、請求送信には専用の請求システム、回収には別の回収プラットフォームが使われます。

ソースシステムを把握すると、データ検証、トラブルシューティング、プロセスの分断状況の理解に役立ちます。システム間の不整合や、異なるアプリケーションで管理されているプロセスステップを特定できます。これらは、データ転送の遅延やエラーの原因になる場合があります。この分析により、プロセスを支えるITアーキテクチャ全体の連携状況と効率を評価できます。

異なるITシステム間でのプロセスの分断状況を把握するのに役立ち、データ検証やシステム固有のボトルネックの特定にも欠かせません。

通常はデータ抽出の標準フィールドとして提供されます。または、データの取得元となったソーステーブルやファイルに基づいて導出できます。

この属性は、データがソースシステムから最後に取得された時点を記録します。分析対象データの鮮度と適時性を把握するうえで重要なメタデータ項目です。データパイプラインの遅延を示し、プロセスマイニング分析がどの時点までの情報を反映しているかを明らかにします。

プロセスマイニングのダッシュボードや分析では、最終データ更新のタイムスタンプによって、データがどの時点のものかを確認できます。現在の表示が5分前のプロセス状態を示しているのか、前夜の状態を示しているのかを把握することは、運用監視に欠かせません。これにより、利用者の認識を適切に管理し、データの経過時間を把握したうえで意思決定できます。

データの適時性と鮮度を把握するための重要な情報であり、分析や意思決定が明確な時間範囲のデータに基づいていることを確認できます。

通常はデータの抽出、変換、ロード（ETL）処理中に追加され、イベントログのメタデータ列として保存されます。

サービス区分は、患者に提供した医療またはサービスの種類を分類します。「入院」と「外来」のような大分類の場合もあれば、「外科」「救急」「検査室」のような診療科別の分類の場合もあります。サービス区分ごとに、請求ルール、支払者の要件、プロセスフローが異なることがよくあります。

サービス区分ごとに収益サイクルを分けて分析することは、意味のある分析に欠かせません。診療科ごとのパフォーマンスを比較し、たとえば外科手術の否認率が診察より高いかどうかを確認できます。この詳細度で分析すると、問題を切り分け、各サービス領域の業務状況に合わせて改善施策を設計できます。

サービス領域ごとのパフォーマンスを比較し、医療の種類によって異なる効率、否認率、支払いサイクルの差を明らかにできます。

通常は請求明細レコードで確認できます。患者区分、診療科、処置コードから導出できる場合もあります。

支払者が送信済みの請求を拒否すると、支払われなかった理由を説明する否認理由コードが提供されます。これらのコードは、請求調整理由コード（CARC）などの業界標準に基づくことが多く、「Service Not Covered」「Duplicate Claim」「Additional Information Required」など、具体的な問題を示します。

この属性は、収益サイクルにおける根本原因分析に特に有効です。否認理由ごとの頻度と財務影響を分析すると、否認につながる上流プロセスの問題を特定できます。たとえば、「Incorrect Patient Information」による否認が多い場合、患者登録プロセスに問題がある可能性があります。データに基づいて改善し、将来の否認を防ぎ、初回支払率を高められます。

請求否認の根本原因分析に欠かせません。フロントエンドおよび中間工程を対象とした改善により、将来の収益損失を防げます。

支払者から受け取った電子支払通知（ERA）または給付内容説明書（EOB）ファイルから取得します。

担当ユーザー属性は、プロセスステップと、それを実行した個人またはシステムを関連付けます。医療コーディングを完了するコーダー、請求を送信する請求担当者、支払いを計上する自動化ボットなどが該当します。ユーザーを追跡することで、人またはシステムを軸にしたプロセス分析が可能になります。

ユーザーまたはチーム別にプロセスパフォーマンスを分析すると、トレーニングの機会や高い成果を上げている担当者を特定し、作業量を適切に配分できます。また、コンプライアンスと監査の観点でも重要であり、各アクションの責任の所在を明確にできます。この属性によって、リソースのパフォーマンスと利用状況を詳細に分析できます。

チームや個人のパフォーマンス、作業量の配分、自動化率を分析できます。リソースの効率性を把握し、トレーニングの必要性を特定するのにも役立ちます。

通常は、トランザクションログまたは監査証跡の「User ID」「Employee ID」「Processor」フィールドに記録されています。

この属性は、特定のプロセスステップに関連する組織単位を示します。たとえば、「Patient Access」「Coding」「Billing」「Collections」などです。作業が異なるチーム間でどのように分担され、引き継がれているかを把握できます。

部門の視点でプロセスを分析すると、部門横断の連携状況を理解し、チーム間の引き継ぎで発生するボトルネックを特定できます。特定のプロセスバリアントに関与する部門を確認し、部門ごとの効率を測定し、リソースをより適切に配分できます。また、部門内の構造的な問題が収益サイクル全体に影響している可能性も明らかにできます。

部門間のボトルネックを特定し、機能領域別にパフォーマンスを分析できます。チーム間の連携を改善する機会も明らかになります。

トランザクションデータに含まれている場合があります。または、担当ユーザーに関連付けられたマスターデータから導出できます。

支払者名は、償還を受けるために請求を提出する主な相手を示します。支払者には、AetnaやUnitedHealthcareなどの民間保険会社、MedicareやMedicaidなどの政府プログラム、その他の組織が含まれます。支払者ごとに、固有のルール、提出要件、支払いの傾向があります。

この属性は、収益サイクルのパフォーマンス分析に欠かせません。支払者別にプロセスを分けることで、否認率が高い支払者、支払いサイクルが長い支払者、追加情報の要求が多い支払者を特定できます。これにより、契約の見直し、支払者ごとの提出プロセスの調整、必要性の高い領域への否認管理の集中といった対策を講じられます。

否認率や支払い時間などのパフォーマンス指標を支払者別に分けて分析できます。対象を絞った改善や契約交渉に欠かせない情報です。

通常は、請求イベントに関連付けられた患者登録、保険、または請求データに記録されています。

調整金額は、契約、割引、償却などの理由により、支払者または患者から回収しない請求金額の部分を表します。これらの調整によって売掛金総額が減少し、収益サイクルの通常の処理となります。

調整金額とその理由を分析することは、収益の正確性を把握するうえで重要です。調整額が高い、または想定外に大きい場合、請求取得、コーディング、契約管理に問題がある可能性があります。プロセスマイニングを使うと、調整率が高くなるプロセスバリアントや特定のアクティビティを特定し、根本原因を絞り込んで収益の実現を高められます。

償却や契約上の減額を追跡して収益漏れを分析し、契約や請求プロセスに潜む問題を明らかにできます。

通常は、財務調整テーブルまたは支払計上モジュールに記録されています。

請求金額は、請求または請求書に記載された提供サービスの総請求額を表します。請求イベントにおける最初の財務価値であり、支払いや調整など、その後のすべての財務トランザクションを測定する基準となります。

プロセスマイニングでは、請求金額を分析することで、プロセスの非効率が財務に与える影響を把握できます。ケースを高額と低額に分けることで、特定のプロセス上の問題が高収益の請求に偏って影響しているかを確認できます。この金額をサイクル時間や否認率などの指標と関連付けると、財務への影響が大きい問題から改善に取り組めます。

ケースの初期財務価値を示し、遅延や否認など、プロセスの非効率による財務影響を分析できます。

請求取得、請求、または請求取引テーブルに記録される主要な財務属性です。

アカウントステータスは、任意の時点で請求イベントがライフサイクルのどの段階にあるかを示します。直近のアクティビティの結果を反映し、支払い待ちで開いているのか、完了しているのか、回収部門に送られたのか、別の状態にあるのかを確認できます。

プロセスマイニングではアクティビティの流れを再構成しますが、アカウントステータス属性を使うと、現在の状態に基づいてケースをフィルタリングし、セグメント化できます。支払者の回答待ちとなっている売掛金の総額や、最近回収代行会社に送られたアカウント数など、段階別のアカウント件数と金額を表示する運用監視ダッシュボードで特に役立ちます。

ケースの現在の状態を把握できるため、運用ダッシュボードや、アカウントのライフサイクル上の位置に基づく分析のセグメント化に役立ちます。

通常は、患者会計システムの患者アカウントまたは請求イベントのメインレコードにあるステータス項目です。

患者IDは、医療システムの患者マスターインデックス内で個々の患者に割り当てられる一意のキーです。この識別子によって、患者の臨床上および財務上の受診記録を長期にわたって関連付けられます。

請求イベントIDが単一サービスのケースを示すのに対し、患者IDを使うと、同じ患者の複数の受診を横断して分析できます。繰り返し発生する登録エラーやサービス利用の傾向などを明らかにできます。また、患者の財務上の経過全体を分析し、患者負担や継続的な利用状況を把握することにも役立ちます。

同じ患者に関する複数の請求イベントを横断して分析できます。繰り返し発生する問題を特定し、患者の財務上の経過全体を把握するのに役立ちます。

これは、ほぼすべての臨床システムおよび財務システムに存在する主要な識別子で、患者登録システムまたはEHRシステムを起点としています。

支払済み金額は、特定の請求イベントに対して計上されたすべての支払いの累計です。主たる保険者と二次保険者からの支払いに加え、患者による支払いも含まれます。提供したサービスについて実際に回収した現金額を表します。

支払済み金額を分析することは、収益サイクルの財務上の成果と効率を測定するうえで重要です。支払済み金額と請求金額を比較すると、純収益と回収率を把握できます。プロセスマイニングでは、異なるプロセス経路の財務結果を定量化し、全額かつ期限内に支払われる請求と、そうでない請求の特徴を特定できます。

ケースについて実際に回収した現金額を測定します。回収の有効性とプロセス全体の財務パフォーマンスを評価するうえで重要です。

支払計上または現金適用のトランザクションテーブルに記録されています。

未収残高は、請求イベントについてまだ回収する必要がある金額を表します。通常は、請求金額から支払済み金額と調整金額を差し引いて計算します。支払いや調整が計上されると、ケースのライフサイクルに沿って変化します。

この属性は、売掛金の健全性を示す重要な指標です。プロセスマイニングでプロセスの各段階における未収残高を分析すると、売掛金の滞留期間を管理し、回収活動の優先順位を付けられます。残高が高くなりやすいケースの種類やプロセス経路を特定し、支払いや否認解決の問題を見つけることもできます。

売掛金と回収の有効性を測る重要な指標であり、フォローアップ活動の優先順位付けや売掛金の滞留期間の分析に役立ちます。

請求金額、支払済み金額、調整金額から計算することが多く、売掛金システムまたは患者会計システムのフィールドとして保存されている場合もあります。

否認理由と同様に、調整理由は請求金額の一部を償却または調整した理由を説明します。支払者との契約上の義務、慈善医療方針、少額残高の償却、請求エラーの修正など、調整の原因を明確にします。

調整理由を分析すると、収益の正確性と財務パフォーマンスを把握できます。想定される契約上の調整と、社内エラーによる防止可能な償却を区別できます。特定の調整理由でプロセスマップを絞り込むことで、回避可能な収益損失につながるプロセス上の弱点を特定し、改善に取り組めます。

財務調整の背景を示し、契約上の義務とプロセスエラーによる防止可能な収益損失を区別できます。

請求システムまたは患者会計システムの財務トランザクションテーブルに記録されています。通常は、調整または償却トランザクションに関連付けられています。

請求IDは、保険会社に送付する請求書を特定する識別子です。1回の請求イベントから、一次、二次、三次の支払者に請求する必要がある場合や、請求を訂正して再提出する場合に、複数の請求が発生することがあります。

請求IDを追跡すると、支払者とのやり取りの詳細を把握できます。請求の再提出に伴う手戻りループを分析できるほか、支払者に送付した特定の請求書のステータスを追跡できます。請求ID単位でプロセスを分析すると、請求イベントだけを見る場合よりも、請求の提出から解決までのライフサイクルを詳細に把握できます。

請求の提出と再提出を詳細に追跡できるため、支払者とのやり取りや手戻りループを細かく分析できます。

この識別子は、請求の作成時に請求システムで生成され、請求管理テーブルに保存されます。