貴社のレベニューサイクルマネジメントデータテンプレート

アクティビティ名とは、収益サイクルライフサイクルにおける明確なアクションまたはマイルストーンを指します。例としては、「サービス提供」、「請求提出」、「送金受領」、「支払い計上」、「口座償却済み」などがあります。各アクティビティは、時間とリソースを消費するプロセス内のステップを表します。

この属性は、プロセスマップ内のノードを定義するため、プロセスマイニングにとって不可欠です。これらのアクティビティの順序、頻度、および期間を分析することで、実際のプロセスフローの可視化、設計されたモデルとの比較、および逸脱、請求拒否のような手戻りループ、非効率性の特定が可能になります。

この属性はプロセスのステップを定義し、プロセスマップの発見と可視化、手戻りの特定、およびプロセス適合性の分析に不可欠です。

イベントログ、取引テーブル、または請求モジュールや債権モジュール内のステータス変更記録から導出されることがよくあります。

イベントタイムスタンプは、アクティビティが発生または記録された時点を示します。これにより、ケース内の全てのイベントに時間的な文脈が与えられ、収益サイクルの開始から終了までのタイムラインが形成されます。

タイムスタンプは、プロセスマイニングにおけるパフォーマンス分析の根幹をなします。総サイクルタイム、特定のアクティビティ間の期間、待機時間といった重要なKPIを算出するために使用されます。タイムスタンプを分析することで、組織はケースが最も時間を費やすボトルネックを特定し、サービスレベルアグリーメントへの遵守状況を測定し、プロセスの時間的ダイナミクスを理解することができます。

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

この情報は通常、取引ログ、監査証跡、またはイベントテーブルの「作成日」や「ステータス変更日」フィールドとして利用できます。

請求イベントIDは、最初の料金計上から最終的な支払いまたは償却に至るまで、課金対象となるサービスの一つ一つに割り当てられる固有のキーです。これは、特定のサービス取引における請求書作成、提出、拒否、支払い計上など、関連する全ての活動を結びつける中心的な役割を果たします。

プロセスマイニングでは、この属性は各請求イベントのエンドツーエンドのジャーニーを再構築するために不可欠です。全ての関連活動を単一の請求イベントIDの下にまとめることで、アナリストはプロセスフローを可視化し、ボトルネックを特定し、サイクルタイムを測定し、異なるケースがどのように処理されるかのバリエーションを理解することができます。これは、収益サイクルにおける全てのケース中心の分析の基盤となります。

これは、関連するすべてのアクティビティを連携させる不可欠なケースIDであり、各請求可能サービスについて収益サイクル全体を再構築し分析することを可能にします。

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

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

ソースシステムを知ることは、データ検証、トラブルシューティング、およびプロセス断片化の理解に役立ちます。これにより、システム間の不整合を特定したり、異なるアプリケーションで管理されているプロセスステップを明らかにしたりすることができ、データ転送の遅延やエラーの原因となる可能性があります。この分析は、プロセスをサポートする全体的なITアーキテクチャの統合と効率性を評価するのに役立ちます。

複数のITシステムにまたがって断片化したプロセスを把握するのに役立ちます。データの整合性確認や、システム特有のボトルネックを特定する上でも非常に重要です。

この情報は、データ抽出の標準フィールドとして利用できることが多く、またデータが取得されたソーステーブルまたはファイルに基づいて導出することも可能です。

この属性は、データがソースシステムから最後に取得された時刻を記録します。これは、分析されているデータの鮮度と適時性を理解するために重要なメタデータフィールドです。データパイプラインの遅延を反映し、プロセスマイニング分析の現在性をI示します。

プロセスマイニングのダッシュボードや分析において、「最終データ更新」タイムスタンプは、データの通貨性についてユーザーにコンテキストを提供します。運用監視においては、表示が5分前のプロセス状態を表しているのか、昨夜のものを表しているのかを知ることが不可欠です。これにより、ユーザーの期待を管理し、既知の年代のデータに基づいて意思決定が行われることを保証するのに役立ちます。

データの適時性と鮮度に関する重要なコンテキストを提供し、分析と意思決定が理解された期間に基づいていることを保証します。

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

サービスカテゴリは、患者に提供されたケアまたはサービスの種類を分類します。これは、「入院」対「外来」のような高レベルの分類、または「外科」、「緊急」、「検査」のようなより具体的な部門カテゴリである可能性があります。異なるサービスカテゴリは、多くの場合、明確な請求ルール、支払者要件、およびプロセスフローを持っています。

サービスカテゴリ別に収益サイクルプロセスをセグメント化することは、有意義な分析のために不可欠です。これにより、組織は異なるサービスラインのパフォーマンスを比較でき、例えば、外科手術の拒否率がコンサルテーションよりも高いかどうかを確認できます。この詳細レベルは、問題を特定し、各サービス領域の特定の運用コンテキストに合わせて改善イニシアチブを調整するのに役立ちます。

異なるサービスライン間でのパフォーマンス比較を可能にし、特定の種類のケアに固有の効率性、拒否率、支払いサイクルの変動を明らかにします。

この情報は通常、料金明細記録で利用可能であるか、患者区分、部門、または処置コードから導出することができます。

責任者属性は、プロセスステップを実行した個人またはシステムを紐付けます。これは、医療コーディングを完了したコーダー、請求書を提出した請求スペシャリスト、または支払いを計上した自動ボットである可能性があります。ユーザーを追跡することで、プロセス分析に人間またはシステム中心のレイヤーが提供されます。

ユーザーまたはチーム別にプロセスパフォーマンスを分析することで、トレーニング機会の発見、高パフォーマンスな個人の特定、適切な作業負荷の分散が可能になります。また、コンプライアンスおよび監査目的にも不可欠であり、実行された各アクションに対する明確な説明責任を可能にします。この属性により、リソースのパフォーマンスと利用状況の詳細な分析が可能になります。

チームと個人のパフォーマンス、ワークロードの配分、自動化率の分析を可能にし、リソース効率に関する洞察を提供し、トレーニングの必要性を特定します。

通常、取引ログまたは監査証跡に「ユーザーID」、「従業員ID」、または「処理者」フィールドとして見られます。

この属性は、「患者アクセス」、「コーディング」、「請求」、「回収」など、特定のプロセスステップに関連付けられた組織単位を識別します。これにより、異なるチーム間でどのように作業が分散され、引き渡されるかを理解するのに役立ちます。

部門ビューからプロセスを分析することは、部門横断的なコラボレーションを理解し、チーム間の引き渡し地点で発生するボトルネックを特定するために不可欠です。これにより、管理者は特定のプロセスバリアントにどの部門が関与しているかを確認し、部門の効率性を測定し、リソースをより効果的に割り当てることができます。この分析は、部門内の全体的な収益サイクルに影響を与える可能性のあるシステム上の問題を浮き彫りにすることができます。

部門間のボトルネックを特定し、機能領域ごとのパフォーマンスを分析するのに役立ち、より良いチーム間の連携の機会を明らかにします。

この情報は、取引データの一部であるか、責任者に関連付けられたマスターデータから導出されることがあります。

支払者が提出された請求を拒否する場合、請求が支払われなかった理由を説明する拒否理由コードを提供します。これらのコードは、多くの場合、請求調整理由コード（CARC）のような業界標準に従い、「サービス対象外」、「重複請求」、または「追加情報が必要」といった特定の課題を指摘します。

この属性は、収益サイクルにおける根本原因分析のために最も強力なものの1つです。異なる拒否理由の頻度と財務的影響を分析することで、組織は拒否につながる upstream プロセス障害を特定できます。例えば、「患者情報の間違い」による多数の拒否は、患者登録プロセスにおける問題を示唆します。これにより、データに基づいた改善を行い、将来の拒否を防ぎ、初回支払い率を向上させることが可能になります。

請求拒否の根本原因分析にとって極めて重要であり、将来の収益損失を防ぐために、フロントエンドおよびミッドサイクルプロセスの的を絞った改善を可能にします。

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

支払者名は、償還請求が提出される主要な団体を特定します。支払者には、AetnaやUnitedHealthcareのような民間保険会社、MedicareやMedicaidのような政府プログラム、その他の団体が含まれます。各支払者は、独自のルール、提出要件、および支払い行動を持っています。

この属性は、収益サイクルパフォーマンスを分析するために非常に重要です。支払者ごとにプロセスをセグメント化することで、組織はどの支払者が最も高い拒否率、最も長い支払いサイクル、または追加情報の要求が最も頻繁であるかを特定できます。この分析により、契約の再交渉、特定の支払者向けの提出プロセスの調整、最も必要とされる場所での拒否管理活動の集中といった、ターゲットを絞った介入が可能になります。

支払者（保険者）ごとに、拒否率や支払い時間などのパフォーマンス指標をセグメント化することができ、これは的を絞った改善や契約交渉に不可欠です。

この情報は通常、請求イベントに関連付けられた患者登録、保険、または請求データにあります。

調整額とは、契約上の合意、割引、償却などの理由により、支払者（保険者）または患者から回収されると予想されない請求額の一部を指します。これらの調整は、総売掛金を削減し、収益サイクルにおける通常の要素です。

調整額とその関連理由を分析することは、収益の健全性を理解するための鍵となります。高額または予期しない調整レベルは、料金Capture、コーディング、または契約管理における問題を示唆する可能性があります。プロセスマイニングは、どのプロセスバリアントまたは特定のアクティビティがより高い調整率につながるかを特定するのに役立ち、それによって収益実現を最大化するための的を絞った根本原因分析を可能にします。

償却と契約上の許容額を追跡することで収益漏れを分析するのに役立ち、契約または請求プロセスにおける潜在的な問題を浮き彫りにします。

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

請求金額とは、請求書やインボイスに記載されたサービスの総費用を示すものです。これは請求イベントの最初の財務的価値であり、支払い、調整といったその後のあらゆる金融取引を測定するための基準となります。

プロセスマイニングにおいて、請求金額の分析はプロセス非効率が財務に与える影響を理解するために不可欠です。これにより、高額なケースと低額なケースに分類し、特定のプロセス問題が高収益の請求に不均衡な影響を与えているかを明らかにできます。この金額をサイクルタイムや拒否率などの指標と関連付けることで、財務的に最も大きな影響を及ぼす問題に対する改善策を優先し、取り組むことができます。

ケースの初期財務価値を確立し、遅延や拒否といったプロセス非効率性の財務的影響分析を可能にします。

これは、料金捕捉、請求、または請求取引テーブルに見られるコアとなる財務属性です。

口座ステータスは、任意の時点での請求イベントがライフサイクルのどこにあるかを示すスナップショットを提供します。このステータスは、最新のアクティビティの結果を反映しており、口座がオープンで支払い待ちであるか、クローズされているか、回収手続きに送られたか、または他の状態にあるかを示します。

プロセスマイニングはアクティビティの流れを再構築しますが、口座ステータス属性は、現在の状態に基づいてケースをフィルタリングおよびセグメント化するのに貴重です。特に、支払者（保険者）からの応答待ちの現在の売掛金総額や、最近回収業者に送られた口座の数など、異なる段階にある口座の量と価値を示す必要がある運用監視ダッシュボードにとって有用です。

ケースの現状スナップショットを提供し、運用ダッシュボードや、口座がライフサイクルのどの段階にあるかに基づいて分析をセグメント化するのに役立ちます。

これは通常、患者会計システムの主要な患者口座または請求イベントレコードのステータスフィールドです。

患者IDは、医療システムのマスタ患者インデックス内で個々の患者に割り当てられる固有のキーです。この識別子は、患者の全ての臨床的および財務的記録を時系列で結びつけます。

請求イベントIDが単一のサービスに対するケースであるのに対し、患者IDは同じ患者に対する複数の診療記録を横断する広範な分析を可能にします。これにより、登録エラーの繰り返しやサービス利用パターンのような、繰り返し発生する問題を明らかにすることができます。また、患者の完全な財務的ジャーニーを分析するためにも使用でき、患者の負担額とロイヤルティを理解する上で貴重です。

同じ患者に対して複数の請求イベントを横断的に分析でき、繰り返しの問題を特定し、患者の全体的な財務ジャーニーを理解するのに役立ちます。

これは、患者登録またはEHRシステムから発せられる、事実上全ての臨床および財務システムに見られる主要な識別子です。

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

支払い済み金額の分析は、収益サイクルの財務的成功と効率を測定するために不可欠です。支払い済み金額を請求金額と比較することで、純収益と回収率に関する洞察が得られます。プロセスマイニングでは、この属性は異なるプロセスパスの財務的結果を定量化するのに役立ち、全額かつ期日通りに支払われる請求とそうでない請求の特徴を特定するために使用できます。

これはケースに対して実際に回収された現金を測定するものであり、回収の有効性とプロセスの全体的な財務パフォーマンスを評価するために不可欠です。

この情報は、支払い計上または現金適用取引テーブルに格納されています。

未収残高は、請求イベントに対してまだ回収されていない金額を示します。通常、請求金額から支払い済み金額と調整金額を差し引いて算出されます。この値は、支払いと調整が計上されるにつれて、ケースのライフサイクル全体で変化します。

この属性は、売掛金健全性の主要な指標です。プロセスマイニングにおいて、プロセスの様々な段階での未収残高を分析することは、売掛金年齢管理と回収活動の優先順位付けに役立ちます。これにより、どのタイプのケースやプロセスパスが高い残高を抱える傾向があるかを特定でき、支払いまたは拒否解決における問題を示唆します。

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

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

拒否理由と同様に、調整理由は請求額の一部が償却または調整された理由を説明します。これらの理由は、調整が支払者（保険者）との契約上の義務、慈善ケアポリシー、少額残高の償却、または請求エラーの修正によるものかどうかを明確にします。

調整理由を分析することは、収益の健全性と財務パフォーマンスに関する洞察を提供します。これにより、予期された契約上の調整と、内部エラーによる予防可能な償却を区別するのに役立ちます。特定の調整理由に基づいてプロセスマップをフィルタリングすることで、アナリストは回避可能な収益損失につながるプロセスの弱点を特定し、それに応じて改善努力を集中させることができます。

財務調整のコンテキストを提供し、契約上の義務とプロセスエラーによる予防可能な収益損失を区別するのに役立ちます。

請求システムまたは患者会計システム内の財務取引テーブルにあり、多くの場合、調整または償却取引にリンクされています。

請求IDは、保険会社に送付される請求書に対する特定の識別子です。単一の請求イベントであっても、一次、二次、三次支払者への請求が必要な場合や、請求が修正されて再提出される場合には、複数の請求が発生する可能性があります。

請求IDを追跡することは、支払者とのやり取りプロセスの詳細を理解する上で重要です。これにより、請求の再提出を含む手戻りループの分析が可能になり、支払者に送付された特定の請求書のステータスを追跡するのに役立ちます。請求イベント単体を見るよりも、請求IDでプロセスを分析することで、請求提出と解決のライフサイクルをより詳細に把握することができます。

請求の提出と再提出の詳細な追跡を可能にし、支払者（保険者）とのやり取りや手戻りループのきめ細かな分析を提供します。

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