収益サイクル管理データテンプレート
収益サイクル管理データテンプレート
- 詳細な分析に推奨されるデータ属性
- 効果的に追跡すべき主要なプロセスアクティビティ
- Waystarからデータを抽出するための具体的な手順
収益サイクル管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 収益サイクルプロセス内で発生した特定のビジネスイベントまたはステップの名称です。たとえば、「請求を提出」や「支払いを計上」などがあります。 | ||
| 説明 この属性は、エンドツーエンドの収益サイクルプロセスを構成する個々のアクティビティを表します。各値は、請求の作成、否認の受信、支払いの計上など、請求イベント上で実行された個別のステップ、マイルストーン、またはタスクを示します。 これらのアクティビティの順序と頻度を分析することは、プロセスマイニングの基礎です。プロセスマップの可視化、再処理ループ(例:「請求否認」から「請求を修正」)の特定、ステップ間の移行時間の測定が可能になります。プロセスの効率とコンプライアンスを理解するために欠かせません。 重要な理由 この属性はプロセスマップ上のステップを定義するもので、収益サイクルのワークフローを可視化・分析するための基盤となります。 入手先 Waystarの請求および請求処理モジュール内のイベントログ、ステータス変更記録、または取引種別から生成されます。 例 支払者に請求を提出請求否認支払い計上アカウントをクローズ | |||
| イベントタイムスタンプ EventTimestamp | アクティビティが発生した正確な日付と時刻です。 | ||
| 説明 イベントタイムスタンプは、アクティビティが発生した正確な時点を記録します。このタイムスタンプは、イベントを時系列に並べ、プロセス内の異なるステップ間の所要時間を計算するために欠かせません。 プロセス分析では、タイムスタンプを使ってサイクルタイム、待機時間、処理時間などの主要業績評価指標を計算します。たとえば、「請求を提出」のタイムスタンプと「支払いを計上」のタイムスタンプの差から、支払いサイクル全体の所要時間を求められます。正確なタイムスタンプは、ボトルネック分析とパフォーマンス監視に不可欠です。 重要な理由 タイムスタンプは、イベントの順序付け、サイクルタイムの計算、プロセスパフォーマンスの分析に必要であり、分析の時間的な基盤となります。 入手先 Waystarのほぼすべての取引またはステータス変更記録に関連付けられた標準フィールドです。「作成日」や「取引日」などの名称が使われます。 例 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z | |||
| 請求イベント BillingEvent | 請求を発生させる単一のサービス提供または製品提供を識別する一意の識別子であり、収益サイクルプロセスにおけるケースとして機能します。 | ||
| 説明 Billing Eventは主要なケース識別子として機能し、特定の請求対象サービスについて、請求額の捕捉からアカウントのクローズまで、すべてのアクティビティを関連付けます。単一の請求または患者請求書のライフサイクル全体を表します。 プロセスマイニングでは、各Billing Eventの経過を分析することで、収益サイクルを詳細に把握できます。一般的なプロセス経路、逸脱、個々の請求に影響するボトルネックを特定できます。この粒度の分析は、請求提出や支払い計上の遅延など、改善すべき具体的な領域を特定し、プロセスパフォーマンスを理解するために欠かせません。 重要な理由 関連する収益サイクルのアクティビティをすべてつなぐ必須のCase IDであり、各請求対象項目のエンドツーエンドのプロセスを追跡できます。 入手先 通常、Waystar内の主要な請求または請求取引テーブルにある主キーです。具体的なテーブル名とフィールド名については、Waystarのドキュメントを確認してください。 例 BE-2024-0012345BE-2024-0012346BE-2024-0012347 | |||
| ソースシステム SourceSystem | イベントデータの発生元となるシステムまたはアプリケーションです。 | ||
| 説明 この属性は、イベントデータを生成したソースシステムを識別します。複雑なIT環境では、収益サイクルのイベントがWaystar内の異なるモジュールや、電子健康記録(EHR)などの連携された外部システムから発生する場合があります。 ソースシステムを把握することは、データ検証、トラブルシューティング、異なるシステムの挙動によって生じるプロセスの違いを理解するうえで重要です。問題が発生したプロセスを、正しいアプリケーションまたはインターフェースに紐付けることができます。 重要な理由 データの発生元を識別します。データガバナンス、品質保証、異なるシステム間のプロセスの違いを理解するために重要です。 入手先 多くの場合、データ抽出時に追加される固定値(「Waystar」)です。システム内の特定のモジュールまたはテーブルから導出される場合もあります。 例 Waystar RCMWaystar Billing ModuleEHR Interface | |||
| 最終データ更新 LastDataUpdate | このイベントのデータが最後に更新または抽出された時点を示すタイムスタンプです。 | ||
| 説明 この属性は、ソースシステムからデータが最後に抽出された時点のタイムスタンプを示します。ビジネスイベントが発生した時刻ではなく、分析用にレコードが取得された時刻です。 この情報は、データガバナンスと、プロセスマイニング分析におけるデータの鮮度を把握するために重要です。最新の情報を見ているかどうかを確認でき、増分データロードの管理にも欠かせません。 重要な理由 データセットの鮮度を示すことでデータの透明性を確保し、正確かつタイムリーなレポートと分析を支えます。 入手先 通常、データ取り込み時のETL(抽出、変換、ロード)プロセスによって各行に生成・追加されます。 例 2024-01-15T02:00:00Z2024-01-16T02:00:00Z | |||
| サービス種別 ServiceType | 提供された医療サービスのカテゴリーまたは種別です。「放射線科」、「診察」、「外科手術」などがあります。 | ||
| 説明 サービス種別は、患者に提供された請求対象サービスの内容を分類します。サービス種別によって、請求コード、償還率、プロセスの複雑さが異なることがあります。 この属性により、診療科またはサービスライン別に収益サイクルを詳細に分析できます。「請求の遅延が最も多いサービスラインはどれか」「外科手術は診察より否認率が高いか」といった問いに答えられます。部門パフォーマンスの分析と、対象を絞ったプロセス改善に役立ちます。 重要な理由 診療科またはサービスライン別にプロセスパフォーマンスを分析でき、効率性と収益性の違いを明らかにします。 入手先 通常、処置コード(CPT/HCPCS)から導出されるか、Waystar内でサービスを提供した部門に関連付けられます。 例 放射線科循環器科の診察救急外来の受診外来手術 | |||
| 否認理由コード DenialReasonCode | 支払者が請求を否認した理由を示す標準化コードです。 | ||
| 説明 支払者が請求を否認すると、却下理由を説明する理由コードが提供されます。情報不足、対象外サービス、コーディングエラーなどを示すコードがあります。この属性は、その特定のコードを記録します。 否認理由コードの分析は、収益サイクルの改善に欠かせません。特定の部門で頻発するエラーや、特定の支払者の要件に関する問題など、否認の根本原因を組織が特定できます。このデータは「請求否認率と理由」ダッシュボードに直接反映され、将来の否認を防ぎ、初回支払い率を高めるための施策策定に役立ちます。 重要な理由 請求否認の根本原因分析に欠かせない属性であり、収益損失と再処理を減らすための対象を絞った対応を可能にします。 入手先 否認イベントが発生した際に請求レコードへ入力されます。この情報は、送金通知で支払者から受信します。 例 CO-16:請求またはサービスに情報が不足していますPR-96:補償対象外の請求ですCO-22:この医療費は別の支払者が負担する可能性があります | |||
| 支払者名 PayerName | 請求に対して責任を負う保険会社または第三者支払者の名称です。 | ||
| 説明 この属性は、請求の審査と支払いを担う特定の支払者を識別します。保険会社、Medicareなどの政府プログラム、その他の組織が該当します。支払者ごとに、提出要件、支払いスケジュール、否認パターンが異なる場合があります。 支払者名でプロセスを分析することは、支払いサイクルが最も長い支払者、否認率が最も高い支払者、またはプロセスが最も複雑な支払者を特定するために重要です。組織はこれに基づいて方針を調整し、問題のある支払者へのフォローアップを優先し、より良い契約条件を交渉できます。 重要な理由 支払者別にプロセスを分類することは、支払者固有のボトルネック、否認理由、支払い遅延を特定するために重要です。 入手先 Waystar内の患者の保険情報に関連付けられた請求または請求情報から取得されます。 例 AetnaBlue Cross Blue ShieldCignaMedicare Part B | |||
| 未収残高 OutstandingBalance | 請求イベントについて、まだ回収されていない残りの金額です。 | ||
| 説明 未収残高は、特定の請求イベントにおける現在の売掛金額を表します。請求金額から、その時点までに適用された支払いと調整を差し引いて計算します。 キャッシュフローと売掛金を管理するための重要な財務指標です。「未収残高と滞留期間」ダッシュボードの主要属性として、売掛金総額の追跡、高残高アカウントの特定、回収活動の優先順位付けに役立ちます。この値を継続的に監視することで、回収プロセスの有効性を把握できます。 重要な理由 売掛金を直接測定する指標であり、キャッシュフローの管理、回収の優先順位付け、財務健全性の評価に欠かせません。 入手先 通常、Waystarのレポートモジュールで計算されるフィールドです(請求金額-支払済み金額-調整額)。直接利用できるフィールドがない場合は、データ抽出時に計算する必要があります。 例 30.00270.25540.50 | |||
| 請求ステータス ClaimStatus | ライフサイクルにおける請求の現在のステータスです。「提出済み」、「保留中」、「支払済み」、「否認」などがあります。 | ||
| 説明 請求ステータスは、特定の請求イベントが収益サイクルのどの位置にあるかを、その時点で示します。請求が送信済みか、支払者による審査中か、支払い済みか、却下されたかなど、最新のマイルストーンを示します。 この属性は、財務レポートと業務管理に欠かせません。プロセスマイニングでは、未完了のすべてのケースの現在の状態を把握し、「支払者による審査待ち」など、特定のステータスにケースが滞在する時間を分析できます。「未収残高と滞留期間」ダッシュボードを直接支えます。 重要な理由 処理中のすべての請求を現在の状態で把握でき、ボトルネックの分析と作業の優先順位付けに役立ちます。 入手先 Waystarの請求または請求記録にある標準フィールドで、請求がサイクルを進むにつれて更新されます。 例 提出済み支払者が受領確認済み支払拒否全額支払い済み | |||
| 請求金額 BilledAmount | 請求上で提供されたサービスに対して請求された金額の合計です。 | ||
| 説明 請求金額は、調整、契約上の控除、支払いが適用される前に、患者へ提供したサービスに対して請求する総額を表します。支払者に提出する請求の初期金額です。 この属性は、財務分析と、プロセスを通じて流れる金額の把握に欠かせません。請求金額別の分析、サービスごとの請求傾向の特定、否認や支払い遅延などの非効率が財務に与える影響の計算に利用できます。多くの財務ダッシュボードの基礎となる指標です。 重要な理由 請求の総額を表し、プロセスの遅延、否認、調整が財務に与える影響を分析できます。 入手先 Waystarの請求または請求額入力画面にある標準的な財務フィールドです。 例 150.001250.75540.50 | |||
| サービス完了から請求までの時間 ServiceToInvoiceCycleTime | サービスが完了してから、料金が取り込まれ、請求が作成されるまでの経過時間です。 | ||
| 説明 「charge lag」とも呼ばれるこの指標は、フロントエンドの請求プロセスの効率を測定します。「Service Provided/Completed」イベントから「Charges Captured」または「Claim Created」イベントまでの時間差として計算されます。 この属性は、「Service To Invoice Cycle Time」ダッシュボードに直接反映されます。charge lagとして知られるこのプロセス上の遅延は、支払いサイクルの開始を遅らせ、キャッシュフローを直接的に悪化させます。これを監視することで、すべてのサービスを迅速かつ正確に請求し、請求漏れを防ぎながら、収益サイクル全体を短縮できます。 重要な理由 フロントエンドの請求効率を測定します。この「charge lag」を短縮することは、収益サイクル全体を短縮し、請求漏れを防ぐうえで重要です。 入手先 データ変換時に、サービスイベントのタイムスタンプを料金取り込みまたは請求作成イベントのタイムスタンプから差し引いて計算されます。 例 2日8時間1日0時間5日1時間 | |||
| 初回支払いかどうか IsFirstPassPayment | 請求が否認や調整を受けることなく、初回提出で正しく支払われたかどうかを示すフラグです。 | ||
| 説明 否認、却下、追加情報の要求など、途中で否定的なイベントが発生することなく請求が支払われたかどうかを示す、計算された真偽値属性です。「true」は、その請求のプロセスがクリーンで効率的だったことを示します。 「初回支払い率」KPIを直接支えます。初回で支払われなかった請求の特徴(支払者別、サービス種別別など)を分析することで、再処理と支払い遅延の主な要因を特定できます。この率を改善すると、キャッシュフローが速まり、業務コストを削減できます。 重要な理由 請求と請求処理の品質を直接測定します。初回支払い率が高いことは、再処理が少なく効率的なプロセスであることを示します。 入手先 これは、データ変換時に計算される派生属性です。ロジックでは、「Claim Denied」や「Account Adjusted」などのイベントに先行されることなく、「Payment Posted」イベントが発生しているかどうかを確認します。 例 truefalse | |||
| 患者ID PatientId | サービスを受けた患者を識別する一意の識別子です。 | ||
| 説明 この属性は、請求イベントに関連付けられた患者の一意の識別子です。財務取引を、医療サービスを受けた個人に紐付けます。 Billing Eventがケースを表すのに対し、Patient IDを使うと患者中心の分析が可能になります。リピーター患者の特定、複数回の受診にわたる患者の財務上の経過の把握、特定の患者属性と支払い問題や高い否認率との関連性の分析に役立ちます。1人の患者に関するすべての請求アクティビティを集計できます。 重要な理由 患者中心の分析を可能にし、複数の請求イベントにまたがる個人の財務上の経過全体を把握できます。 入手先 Waystar内の請求または患者登録レコードにある標準フィールドです。EHRから連携される場合もあります。 例 MRN-887654MRN-902101MRN-123456 | |||
| 患者区分 PatientClass | 入院や外来など、受診時の患者の区分を示します。 | ||
| 説明 患者区分は患者の受診形態を分類するもので、請求ルールや償還率を左右することがあります。一般的な区分には、入院、外来、救急があります。 患者区分別に収益サイクルを分析すると、プロセスの大きな違いを明らかにできます。たとえば、入院請求は外来請求より複雑で、支払いサイクルが長くなることがあります。この分類は、現実的なパフォーマンス目標を設定し、各区分のニーズに合わせてプロセス改善施策を調整するために重要です。 重要な理由 受診の複雑さ(例:入院と外来)に基づいてプロセスを分類できます。請求ルールやサイクルタイムの違いと関連することが多い分類です。 入手先 WaystarまたはソースEHRの患者登録データや受診データにある標準フィールドです。 例 入院外来救急 | |||
| 担当ユーザー ResponsibleUser | 請求担当者、コーダー、回収担当者など、アクティビティを実行したユーザーまたは担当者です。 | ||
| 説明 この属性は、プロセス内の特定のアクティビティを実行した従業員またはシステムユーザーを識別します。たとえば、どの請求担当者が請求を提出したか、どの回収担当者がフォローアップの電話を開始したかを確認できます。 ユーザー別にプロセスを分析することで、業務量の分布、個人のパフォーマンス、トレーニングの必要性を把握できます。特定のユーザーのエラー率が高いか、否認の解決が効率的かどうかも確認できます。収益サイクル部門のチーム管理と品質管理に役立ちます。 重要な理由 プロセスステップの責任の所在を明確にし、個人またはチーム単位のパフォーマンス分析とトレーニング機会の特定を可能にします。 入手先 Waystarのイベントに関する監査証跡または取引ログから取得されます。「UserID」、「ProcessedBy」などの名称が使われます。 例 jsmithadavisbilling_bot_01 | |||
| 支払期日 PaymentDueDate | 請求書または請求に対する支払いが予定されている期限です。 | ||
| 説明 支払期日は、提供者が設定するか、支払者との契約で定められる、支払いを受領すべき日です。支払いの適時性を測定する基準になります。 「未収残高と滞留期間」ダッシュボードに欠かせない属性です。売掛金の経過日数を計算し、「0~30日」、「31~60日」などの区分に分類するために使われます。この滞留期間分析は、売掛金を管理し、期限を過ぎたアカウントの回収活動を優先するための標準的な財務手法です。 重要な理由 売掛金の滞留期間を計算する基準となり、回収管理とキャッシュフローの適時性の把握に欠かせません。 入手先 請求書または請求レコードから取得できます。請求書の日付と支払条件に基づいて計算される場合もあります。 例 2023-11-252023-12-152024-01-30 | |||
| 支払済み金額 PaidAmount | 請求について、支払者または患者から受領し、計上した金額の合計です。 | ||
| 説明 この属性は、請求イベントについて回収に成功した累計金額を記録します。主たる支払者および二次支払者からの支払いに加え、患者からの支払いも含まれます。 支払済み金額は、収益サイクルの成果を測る主要指標です。請求金額に対する最終的な回収率の計算や、プロセス全体の有効性の測定に使われます。請求金額と支払済み金額を比較することで、財務パフォーマンスを把握し、収益漏れの領域を明らかにできます。回収の有効性や財務健全性に関するダッシュボードに欠かせません。 重要な理由 実際に回収した現金を測定する指標であり、収益サイクルプロセス全体の成功度を評価する主要な成果指標です。 入手先 Waystarで請求に関連付けられた支払い計上取引から導出されます。複数の支払いレコードを合計する必要がある場合があります。 例 120.00980.500.00 | |||
| 支払者種別 PayerType | 「民間保険」、「Medicare」、「自己負担」など、支払者のカテゴリーです。 | ||
| 説明 支払者種別は、個々の支払者を性質に基づく大きなカテゴリーに分類します。特定の支払者名よりも上位の視点で分析できます。 この属性は、戦略分析とレポート作成に役立ちます。政府系支払者と民間保険会社の全体的なパフォーマンスを比較するなど、主要な支払者カテゴリーごとの傾向を把握できます。支払者との契約やリソース配分に関する戦略的な意思決定に役立ちます。 重要な理由 支払者を民間保険や政府系などのカテゴリーに分類して分析できます。カテゴリーごとに支払いの傾向やルールが異なることが多くあります。 入手先 通常、支払者名をあらかじめ定義したカテゴリー一覧に対応付けて導出します。このロジックはWaystarに存在する場合も、データ変換時に構築する必要がある場合もあります。 例 民間保険MedicareMedicaid自己負担 | |||
| 調整済み金額 AdjustedAmount | 請求イベントについて調整または償却された財務金額の合計です。 | ||
| 説明 調整済み金額は、請求イベントの残高に対して行われたすべての財務調整の合計を表します。支払者との契約で定められた契約上の控除に加え、その他の償却や修正も含まれます。 「アカウント調整率と影響」ダッシュボードの主要指標です。理由コードや支払者別にこの金額を合計すると、収益漏れの財務的影響を把握できます。損失を定量化し、調整の根本原因に対処するための根拠を示せます。 重要な理由 償却と調整によって失われた収益額を定量化し、請求上の問題や契約条件が財務に与える影響を明らかにします。 入手先 Waystar内の財務調整取引から取得されます。1つの請求イベントについて複数の調整エントリを合計する必要がある場合があります。 例 250.2550.0015.80 | |||
| 調整理由コード AdjustmentReasonCode | アカウント残高を財務的に調整した理由を説明するコードです。 | ||
| 説明 支払い以外の理由でアカウント残高が変更された場合、たとえば契約上の控除や償却が行われた場合に、理由を記録するために調整理由コードを使用します。この属性は、そのコードを記録します。 これらのコードの分析は、「アカウント調整率と影響」ダッシュボードに欠かせません。特定の支払者に対する契約上の調整の頻発や、請求エラーによる償却など、収益漏れの根本原因を特定できます。理由を理解することが、避けられる収益損失を減らす第一歩です。 重要な理由 収益が調整または償却された理由を説明し、収益漏れと支払者との契約パフォーマンスを把握するための重要な情報を提供します。 入手先 Waystarの支払い計上または売掛金モジュールにある調整取引に関連付けられます。 例 契約上の義務少額残高の償却請求エラーの訂正 | |||
収益サイクル管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| アカウントをクローズ | 支払いと調整によってアカウント残高がゼロになり、請求イベントのライフサイクルが完了しました。このケースにおける収益サイクルが正常に終了したことを示します。 | ||
| 重要な理由 プロセスの主要な終了点です。クローズまでの時間と、正常にクローズしたアカウントの割合を測定することは、全体的なパフォーマンス指標として重要です。 入手先 計算によって求められるイベントです。通常、患者会計システムで請求イベントの未収残高フィールドがゼロになった時点から推定されます。 取得 支払いと調整の合計額が請求総額と等しくなった時点で計算されます。 イベントタイプ calculated | |||
| 支払い計上 | 受領した支払いが、特定の患者アカウントおよび請求に対して適用または照合されます。このアクティビティにより、残高が売掛金から現金へ移行します。 | ||
| 重要な理由 支払者サイクルにおける重要な最終ステップです。支払い計上の処理量と遅延時間に関するKPIを支え、アカウントが適時かつ正確に更新されるようにします。 入手先 ユーザーがERAからの支払いを計上した際に、Waystarで記録される明示的な操作です。多くのシステムには自動計上機能があり、このイベントも記録されます。 取得 ERAからの支払いが、手動または自動計上によって請求に適用された時点で記録されるイベントです。 イベントタイプ explicit | |||
| 支払者に請求を提出 | 審査のため、電子請求を保険の支払者に提出することです。クリアリングハウスを介して、医療提供者のシステムから支払者のシステムへ引き渡す重要なステップです。 | ||
| 重要な理由 支払者の応答時間の計測を開始する重要なマイルストーンです。支払いサイクルのKPIを測定し、提出待ちの滞留を特定するうえで欠かせません。 入手先 Waystarのクリアリングハウス機能は、請求ファイルの送信日時を明示的に記録します。提出ログまたは請求ステータス履歴を確認します。 取得 送信が正常に完了した時点で、請求提出履歴または取引ログに記録されます。 イベントタイプ explicit | |||
| 請求を審査 | 支払者が請求を処理し、支払いの判断を下しました。このイベントは、支払者から電子送金通知(ERA)または835ファイルを受信した時点で記録されます。 | ||
| 重要な理由 プロセスにおける主要な判断ポイントです。請求が支払われるか否認されるかを決定し、収益の流れと否認管理ワークフローに直接影響します。 入手先 Waystarで請求に関連付けられたERA(835ファイル)の受領日から推定されます。ERAファイルには、支払者による詳細な判断が含まれています。 取得 支払者から受信したERA/835ファイルの処理日から推定されます。 イベントタイプ inferred | |||
| 請求否認 | 支払者が請求を却下し、支払いを行わないことが電子送金通知(ERA)に記載されています。このイベントを起点として、否認管理または再処理のループが始まります。 | ||
| 重要な理由 「請求否認率」KPIを直接支えます。否認の頻度と理由を把握することは、プロセス改善と収益回収に欠かせません。 入手先 受信したERA(835ファイル)に含まれる、Claim Adjustment Reason Code(CARC)と呼ばれる特定の否認コードから推定されます。 取得 否認を示すERAファイル内の請求調整理由コード(CARC)から導出されます。 イベントタイプ inferred | |||
| 請求対象の取り込み | 請求可能なサービスが収益サイクルシステムに登録されたことを示します。通常は、ユーザーが請求項目の入力を確定したとき、または臨床システムからデータを受信したときに明示的に記録されます。 | ||
| 重要な理由 請求プロセスの開始点です。サービス完了から請求対象の取り込みまでの時間を分析することは、収益漏れやフロントエンドの遅延を特定するうえで重要です。 入手先 このイベントはWaystarの請求項目または取引テーブルに記録され、通常、請求項目が保存または確定された時点の作成タイムスタンプが含まれます。 取得 請求項目の保存または確定時に記録されるイベントです。 イベントタイプ explicit | |||
| アカウントを調整 | アカウント残高に対して、手動または契約に基づく調整が行われます。償却、契約上の控除、患者割引、その他の修正などが含まれます。 | ||
| 重要な理由 収益漏れを把握するために欠かせません。調整を分析することで、料金表、契約管理、回収不能債権に関する問題を特定できます。 入手先 監査のため、すべての財務調整を取引として記録する必要があります。アカウント取引テーブルに明示的なイベントとして記録されます。 取得 アカウント元帳の特定の取引種別として記録されます。 イベントタイプ explicit | |||
| 否認に対する異議申立て | ユーザーが請求否認に異議を申し立てる対応を行いました。多くの場合、請求を修正して再提出するか、正式な異議申立てを提出します。このアクティビティは、再処理プロセスにおける重要なステップです。 | ||
| 重要な理由 否認管理チームの効率を測定します。否認から異議申立てまでの時間と、異議申立ての成功率を追跡することは、回収活動の最適化に重要です。 入手先 否認管理モジュールで、ユーザーによる明示的な操作またはメモとして記録される場合があります。また、否認された請求のステータス変更から推定されることもあります。 取得 ユーザーが異議申立ての対応を記録するか、請求ステータスを「異議申立て済み」に更新した時点で記録されるイベントです。 イベントタイプ explicit | |||
| 回収活動を開始 | 患者アカウントが支払遅延となり、積極的な回収活動が始まりました。自動リマインダーの送信や、第三者の回収代行会社への移管などが含まれます。 | ||
| 重要な理由 「回収活動の有効性」ダッシュボードを支えます。滞留している売掛金に対する回収活動のコストと成功率を分析できます。 入手先 通常、Waystar内でアカウントステータスが「回収中」または「貸倒金」の状態に変更されたことから推定されます。この変更により、別のワークフローが開始されます。 取得 アカウントステータスが「回収中」または「貸倒金」に変更されたことから推定されます。 イベントタイプ inferred | |||
| 患者残高明細書を送付 | 保険による審査の後、残額がある場合は明細書が作成され、患者に送付されます。回収の対象が支払者から患者へ移ったことを示します。 | ||
| 重要な理由 患者からの支払いサイクルを開始するイベントです。明細書の効果と送付時期を分析することは、患者売掛金の管理と患者体験の向上に重要です。 入手先 明細書のバッチが作成された時点、または電子送信もしくは印刷業者への送付が行われた時点で、患者請求モジュールにより明示的に記録されるイベントです。 取得 明細書が作成された時点で、患者対応履歴に記録されるイベントです。 イベントタイプ explicit | |||
| 支払者から受領確認を受信 | 支払者のシステムが、提出された請求ファイルの受領を確認します。通常は277CAや999レポートなどの自動応答で、請求が処理対象として受け付けられたことを示します。 | ||
| 重要な理由 送信が正常に完了したことを確認し、審査開始前にフォーマットやデータのエラーによるフロントエンドの却下を切り分けられるため、修正を迅速に行えます。 入手先 支払者から受領確認ファイルを受信して処理した後、Waystarのクリアリングハウスモジュール内にある請求ステータステーブルまたは応答ファイルテーブルに記録されます。 取得 支払者からの電子受領確認ファイルを処理した時点で記録されるイベントです。 イベントタイプ explicit | |||
| 請求を作成 | 取り込まれた請求対象から正式な請求を生成することを示します。支払者に提出する前に、システムが情報をまとめる内部ステップです。 | ||
| 重要な理由 請求生成の内部効率を追跡します。この段階で遅延が発生すると、請求が医療提供者のシステムを離れる前から、支払いサイクル全体が遅れる可能性があります。 入手先 明示的なイベントとして記録される場合もありますが、Waystarの請求管理モジュールにある請求レコードに関連付けられた最初のタイムスタンプから推定されることも多いです。 取得 主要な請求テーブルにある請求レコードの作成日から推定されます。 イベントタイプ inferred | |||
| 請求を修正して再提出 | 否認または却下の後、請求が修正され、支払者に再送されました。特定の請求について、審査サイクルが再開されたことを示します。 | ||
| 重要な理由 重要な再処理ループです。再提出の頻度と理由を分析することで、コーディングミスや患者情報の誤りなど、初回エラーの根本原因を特定できます。 入手先 以前に否認された請求について、新たな「支払者への請求提出」イベントを特定することで推定されます。システムに再提出請求専用のステータスがある場合もあります。 取得 以前に否認された請求識別子に関連付けられた新たな提出イベントから推定されます。 イベントタイプ inferred | |||
抽出ガイド
このプロセスの抽出方法は現在検証中です。後ほど再度ご確認いただくか、 お問い合わせ ください。
始める準備はできていますか?
収益サイクル管理を最適化するための次の一歩を踏み出しましょう。これらのデータから得られる情報を使って、効率化とキャッシュフローの改善を今すぐ進めます。
収益サイクル管理を最適化し、今すぐキャッシュフローを改善
非効率な箇所を特定し、サイクルタイムを30%短縮して、キャッシュフローを改善します。
クレジットカードは不要です。今日から最適化を始められます。