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

アクティビティ名は、収益サイクルの中で個別のアクションや節目を示します。例として、「サービス提供」「請求提出」「支払通知受領」「入金処理」「債権償却」などがあります。それぞれのアクティビティは、時間とリソースを要するプロセスのステップを表します。

この属性は、プロセスマップのノードを定義するため、プロセスマイニングの基礎となります。アクティビティの順序、頻度、所要時間を分析すると、実際のプロセスの流れを可視化し、設計モデルと比較できます。また、請求却下などによる手戻りや、非効率な箇所も特定できます。

この属性はプロセスの各ステップを定義します。プロセスマップの発見と可視化、手戻りの特定、プロセスの適合性チェックに欠かせません。

イベントログや取引テーブルに記録されているほか、請求または請求審査モジュールのステータス変更記録から取得できる場合もあります。

イベントのタイムスタンプは、アクティビティが発生した時点、または記録された時点を示します。ケース内のすべてのイベントを時系列で把握できるため、収益サイクルの開始から終了までの流れを確認できます。

タイムスタンプは、プロセスマイニングでパフォーマンスを分析する際の基礎となります。総サイクルタイム、特定のアクティビティ間の所要時間、待ち時間など、重要業績評価指標（KPI）の算出に使われます。タイムスタンプを分析すると、ケースが長時間滞留するボトルネックを特定し、サービスレベル合意の遵守状況を測定して、プロセスの時間的な動きを把握できます。

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

通常、取引ログや監査証跡に記録されているほか、イベントテーブルの「作成日」または「ステータス変更日」フィールドから取得できます。

請求イベントIDは、請求情報の記録から最終的な入金または償却まで、請求可能なサービスの各案件に割り当てられる一意のキーです。特定の診療に関する請求案件の作成、送信、否認、入金消込など、関連するすべてのアクティビティを結び付ける軸になります。

プロセスマイニングでは、この属性を使って各請求イベントのエンドツーエンドの流れを再構成します。関連するアクティビティを1つの請求イベントIDにまとめることで、分析担当者はプロセスの流れを可視化し、ボトルネックを特定し、サイクルタイムを測定し、案件ごとの対応の違いを把握できます。収益サイクルにおけるケース単位の分析の基盤となります。

関連するすべてのアクティビティを結び付ける重要なケース識別子です。請求可能なサービスごとに、収益サイクル全体を再構成して分析できます。

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

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

データの検証や問題の調査、プロセスの分断状況の把握には、ソースシステムの情報が役立ちます。システム間の不整合や、異なるアプリケーションで管理されるプロセスのステップを特定でき、データ転送の遅延やエラーの原因を探る手がかりになります。こうした分析を通じて、プロセスを支えるITアーキテクチャ全体の連携状況と効率を評価できます。

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

データ抽出時の標準フィールドとして取得できることが多く、データの取得元となったテーブルやファイルから特定できる場合もあります。

この属性には、データがソースシステムから最後に取得された日時が記録されます。分析対象データの新しさや更新状況を把握するために欠かせないメタデータです。データパイプラインの遅延を示し、プロセスマイニング分析がどの時点までのデータを反映しているかを確認できます。

プロセスマイニングのダッシュボードや分析では、最終データ更新日時のタイムスタンプによって、データがいつ時点のものかを把握できます。表示内容が5分前のプロセスの状態を示すのか、前夜の状態を示すのかを確認することは、業務のモニタリングに欠かせません。データの経過時間を把握することで、利用者の期待値を適切に調整し、データの鮮度を踏まえた意思決定につなげられます。

データの更新状況や鮮度を把握できるため、分析や意思決定の対象期間を明確にできます。

通常、データの抽出、変換、読み込み（ETL）の過程で追加され、イベントログのメタデータ列に保存されます。

サービス区分は、患者に提供した医療やサービスの種類を分類します。「入院」と「外来」のような大分類から、「外科」「救急」「検査」のような部門別の分類まであります。サービス区分によって、請求規則、支払者の要件、プロセスの流れが異なることがあります。

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

診療科ごとのパフォーマンスを比較し、医療の種類に応じた効率、請求却下率、支払いサイクルの違いを明らかにできます。

通常、チャージ明細に記録されています。患者区分、部門、または処置コードから取得できる場合もあります。

担当ユーザー属性は、プロセスのステップと、それを実行した個人またはシステムを関連付けます。たとえば、医療コーディングを行うコーダー、請求を提出する請求担当者、入金を処理する自動ボットなどです。ユーザーを記録することで、個人やシステムの視点からプロセスを分析できます。

ユーザーやチームごとにパフォーマンスを分析すると、研修が必要な領域や高い成果を上げている担当者を把握し、業務負荷の適切な配分につなげられます。また、コンプライアンスや監査の観点でも重要で、各アクションの責任の所在を明確にできます。この属性を使うと、リソースのパフォーマンスや稼働状況を詳しく分析できます。

チームや個人のパフォーマンス、業務負荷の配分、自動化率を分析できます。リソースの効率を把握し、研修が必要な領域を特定するのに役立ちます。

通常、取引ログや監査証跡の「ユーザーID」「従業員ID」「処理担当者」などのフィールドに記録されています。

この属性は、特定のプロセスのステップに関わる組織単位を示します。たとえば、「患者受付」「コーディング」「請求」「債権回収」などです。チーム間で業務がどのように分担され、引き継がれているかを把握できます。

部門別のプロセス分析は、部門をまたぐ連携状況の把握や、チーム間の引き継ぎで発生するボトルネックの特定に欠かせません。特定のプロセスバリアントに関わる部門や、部門ごとの効率を確認し、リソースをより適切に配分できます。また、収益サイクル全体に影響する部門内の構造的な問題を明らかにできます。

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

取引データに含まれている場合や、担当ユーザーに関連付けられたマスターデータから取得できる場合があります。

支払者名は、償還を求めて請求を提出する主な相手先を示します。支払者には、AetnaやUnitedHealthcareなどの民間保険会社、MedicareやMedicaidなどの公的制度、その他の機関が含まれます。支払者ごとに、独自の規則や提出要件、支払いの傾向があります。

この属性は、収益サイクルのパフォーマンス分析に欠かせません。支払者別にプロセスを分類すると、請求却下率が高い支払者、支払いに時間がかかる支払者、追加情報を頻繁に求める支払者を特定できます。分析結果をもとに、契約の再交渉、支払者に応じた提出手順の調整、必要性の高い領域に絞った請求却下への対応など、対象を定めた改善策を検討できます。

支払者別に請求却下率や支払い所要時間などの指標を比較できます。改善策の検討や契約交渉の対象を絞るうえで役立ちます。

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

調整額は、契約上の取り決め、割引、債権償却などの理由により、支払者や患者から回収しない請求額の一部を表します。調整によって売掛金の合計額は減少しますが、収益サイクルでは通常発生するものです。

調整額とその理由を分析することは、収益の適正性を把握するうえで重要です。調整額が多い、または想定外に高い場合は、チャージ記録、コーディング、契約管理に問題がある可能性があります。プロセスマイニングを使うと、調整率が高くなるプロセスバリアントや特定のアクティビティを特定できます。原因を詳しく調べ、収益の確保に向けた改善策を検討できます。

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

通常、財務調整テーブルまたは入金処理モジュールに記録されています。

提出した請求を支払者が却下すると、支払いに至らなかった理由を示す請求却下理由コードが通知されます。コードには、請求調整理由コード（CARC）などの業界標準が使われることが多く、「対象外のサービス」「重複請求」「追加情報が必要」などの具体的な問題を示します。

この属性は、収益サイクルの根本原因を分析するうえで特に有用です。請求却下理由ごとの発生頻度と財務的な影響を分析すると、却下につながった上流工程の問題を特定できます。たとえば、「患者情報の誤り」による却下が多ければ、患者登録プロセスに問題がある可能性があります。データに基づいて改善し、今後の請求却下を防ぐとともに、初回請求での支払率向上につなげられます。

請求却下の根本原因を分析し、将来の収益損失を防ぐため、初期工程や中間工程を対象とした改善につなげられます。

この情報は、支払者から受け取る電子送金通知（ERA）または給付内容説明書（EOB）のファイルから取得します。

請求額は、請求書や請求データに記載された、提供済みサービスの合計金額です。請求イベントの起点となる金額であり、その後の支払いや調整などの財務取引を測るベースラインとなります。

プロセスマイニングでは、請求額の分析が、プロセスの非効率による財務的な影響を把握する基礎となります。ケースを高額と低額に分類すると、特定のプロセス上の問題が高額請求に偏って影響しているかどうかを確認できます。請求額をサイクルタイムや請求却下率などの指標と照らし合わせることで、財務への影響が大きい問題から優先的に改善できます。

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

請求額は、チャージ記録、請求、または請求取引のテーブルにある基本的な財務属性です。

口座ステータスは、任意の時点で請求イベントがライフサイクルのどの段階にあるかを示します。直近のアクティビティの結果が反映され、口座が未決済で入金待ちなのか、決済済みなのか、債権回収に回されたのか、あるいは別の状態なのかを確認できます。

プロセスマイニングではアクティビティの流れを再構成しますが、口座ステータス属性を使うと、現在の状態に基づいてケースを絞り込んだり分類したりできます。さまざまな段階にある口座の件数や金額を示す業務モニタリング用ダッシュボードで特に役立ちます。たとえば、支払者からの回答待ちとなっている売掛金の合計や、最近債権回収機関に送られた口座数を確認できます。

ケースの現在の状態を把握できます。業務モニタリング用ダッシュボードや、ライフサイクル上の段階に応じた口座の分類に役立ちます。

通常、患者会計システムの患者口座または請求イベントのメインレコードにあるステータスフィールドです。

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

1件のサービスをケースとして扱う請求イベントIDに対し、患者IDを使うと、同じ患者の複数の受診を横断して分析できます。登録時の誤りの繰り返しや、サービス利用の傾向などを明らかにできます。また、患者の財務状況の全体像を分析できるため、患者負担や患者との関係性を把握するうえでも役立ちます。

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

ほぼすべての診療システムや財務システムにある主要な識別子で、患者登録システムまたはEHRシステムから取得します。

支払額は、特定の請求イベントに対して処理されたすべての入金の累計です。一次・二次保険の支払者からの入金に加え、患者からの支払いも含まれます。提供したサービスに対して実際に回収した金額を表します。

支払額の分析は、収益サイクルの財務面での成果と効率を測るうえで欠かせません。支払額と請求額を比較すると、純収益や回収率を把握できます。プロセスマイニングでは、この属性を使ってプロセス経路ごとの財務結果を定量化し、請求が全額かつ期日どおりに支払われるケースと、そうでないケースの特徴を特定できます。

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

この情報は、入金処理または現金消込の取引テーブルに記録されています。

未回収残高は、請求イベントについて、まだ回収できていない金額を表します。通常、請求額から支払額と調整額を差し引いて算出します。ケースの進行に伴い、入金や調整の処理によって金額が変わります。

この属性は、売掛金の状況を示す重要な指標です。プロセスの各段階で未回収残高を分析すると、売掛金の滞留期間を把握し、回収業務の優先順位を決めるのに役立ちます。残高が高くなりやすいケースやプロセス経路を特定し、入金や請求却下の解決に関する問題を見つけられます。

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

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

請求却下理由と同様に、調整理由は請求額の一部が償却または調整された理由を示します。支払者との契約上の義務、慈善医療方針、少額残高の償却、請求誤りの訂正など、調整の背景を確認できます。

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

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

請求システムまたは患者会計システムの財務取引テーブルに記録されています。調整や債権償却の取引に関連付けられていることが多いです。

請求IDは、保険会社に送付した請求を識別するIDです。1件の請求イベントから複数の請求が発生する場合があります。一次、二次、三次の支払者にそれぞれ請求する場合や、請求を訂正して再提出する場合などです。

請求IDを追跡すると、支払者とのやり取りの詳細を把握できます。請求の再提出を伴う手戻りを分析し、支払者に送付した個々の請求の状況を追跡できます。請求IDごとにプロセスを分析すると、請求イベント単位で見る場合よりも、請求の提出から解決までの流れを詳しく確認できます。

請求の提出と再提出を詳しく追跡し、支払者とのやり取りや手戻りを細かく分析できます。

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