収益サイクル管理のデータテンプレート
収益サイクル管理のデータテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- データ抽出ガイド
収益サイクル管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 収益サイクル管理プロセスで実行された特定のイベントまたはタスクの名前です。 | ||
| 説明 この属性は、収益サイクルにおける個々のステップを表します。たとえば、「請求記録」「支払者への請求提出」「入金受領」などです。各アクティビティは、サービスの請求と入金回収のプロセスにおける個別のマイルストーンです。 アクティビティの分析は、プロセスマイニングの基礎です。プロセスマップを可視化し、よくある経路を特定し、ステップ間のボトルネックを見つけ、標準業務手順への適合性を測定できます。 重要な理由 プロセスマップの各ステップを定義し、収益サイクルにおける業務の流れを可視化、分析、改善できるようにします。 入手先 通常、Epic Resoluteの請求・請求管理モジュールにあるイベントログ、監査証跡、またはステータス変更レコードから取得します。 例 請求記録支払者への請求提出入金受領アカウントのクローズ | |||
| イベントのタイムスタンプ EventTimestamp | 特定のアクティビティまたはイベントが発生した正確な日時です。 | ||
| 説明 イベントのタイムスタンプは、アクティビティが発生した時点を記録します。この時間データは、収益サイクルにおけるイベントのタイミングと順序を把握するうえで重要です。 分析では、タイムスタンプを使って、請求記録の遅れや入金消込にかかる時間など、アクティビティ間の所要時間を計算します。ボトルネックの特定、サイクルタイムの測定、期間ごとのプロセスパフォーマンスの分析にも役立ちます。正確なタイムスタンプは、時間に基づくほぼすべての重要業績評価指標(KPI)やダッシュボードに欠かせません。 重要な理由 サイクルタイムや所要時間など、時間に基づくすべての指標の計算に欠かせない属性です。遅延や非効率な点の特定に役立ちます。 入手先 Epic Resoluteのトランザクションテーブルまたはイベントログテーブルにあり、記録された各アクティビティに紐づいています。フィールド名にはDt、DTTM、Timeなどの接尾辞が使われることがよくあります。 例 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| 請求イベント BillingEvent | 請求が発生する個々のサービスまたは製品の提供を識別する一意の識別子で、主なケース識別子として使用されます。 | ||
| 説明 請求イベントは、特定の請求対象項目に関する収益サイクルのすべてのアクティビティを結びつける基本の識別子です。サービスの提供時に始まり、アカウントの精算またはクローズをもって終了します。 プロセスマイニング分析では、この属性を使って各請求の全体的な流れを再構成します。個々の請求イベントについて、請求記録、請求提出、入金消込、否認管理などのアクティビティを追跡できるため、プロセスの流れとそのばらつきを明確に把握できます。 重要な理由 これは基本となるケースIDです。各サービスの収益発生から回収までの全期間を分析するために、関連するすべてのプロセスステップを結びつけるうえで欠かせません。 入手先 Epic Resoluteでは、病院アカウント(HAR)または特定の請求セッションを識別する一意の識別子が使われることがよくあります。HARやCharge Sessionのレコードなど、具体的なテーブルについてはEpic Resoluteの文書をご確認ください。 例 BE10098765BE20012345BE30054321 | |||
| サービス種別 ServiceType | 提供された医療サービスのカテゴリーまたは種別です。 | ||
| 説明 この属性は、請求対象のサービスを「放射線科」「外科」「診察」「救急外来」などに分類します。財務データに臨床的な背景を加える情報です。 サービス種別ごとに収益サイクルを分析すると、特定の診療領域に固有のプロセスの違いを把握できます。たとえば、外科手術では一般的な外来診療よりも、請求内容の記録や承認に複雑な要件が伴う場合があります。その結果、プロセスの進み方や課題も異なります。 重要な理由 財務データに臨床的な背景を加え、医療サービスの種別が収益サイクルのプロセスや効率に及ぼす影響を分析できます。 入手先 Epicの請求取引に関連付けられた請求内容マスター(CDM)、サービスライン、または部門の情報から取得します。 例 入院手術外来放射線科救急サービス | |||
| 否認理由コード DenialReasonCode | 提出された請求を支払者が否認した理由を示す標準コードです。 | ||
| 説明 支払者が請求を却下すると、補償対象外のサービス、請求の重複、追加情報の必要性など、否認理由を示すコードが通知されます。これらのコードは、請求調整理由コード(CARC)として標準化されていることがよくあります。 この属性は「請求否認率と理由」ダッシュボードの基礎となります。否認コードの発生頻度を分析すると、資格認定の問題、コーディングミス、事前承認の不足など、否認の根本原因を特定し、対象を絞った改善策を講じられます。 重要な理由 請求が却下される理由を直接把握できます。否認率の低下、収益損失の防止、入金の迅速化に必要なインサイトが得られます。 入手先 このデータは、支払者から受信する請求応答トランザクション(ANSI 835ファイルなど)に含まれ、Epic Resoluteの請求管理モジュールに保存されています。 例 CO-16:請求またはサービスの情報不足OA-18:請求またはサービスの重複PR-96:補償対象外の請求額 | |||
| 担当ユーザー ResponsibleUser | アクティビティを実行したユーザーまたは従業員の識別情報です。 | ||
| 説明 この属性には、収益サイクルの特定のタスクを担当した人のユーザーID、名前、または従業員番号が記録されます。請求額を入力した医療従事者、請求を提出した請求担当者、否認案件をフォローアップした回収担当者などが該当します。 ユーザー別に分析すると、優れた実績を上げている担当者やトレーニングが必要な領域を特定し、業務負荷の分布を把握できます。パフォーマンス管理や、特定の個人またはロールに関連するプロセス逸脱の調査にも役立ちます。 重要な理由 個人またはロールごとのパフォーマンス分析に役立ち、トレーニングの機会、業務負荷の偏り、リソースに関するボトルネックを特定できます。 入手先 通常、Epic Resoluteの監査証跡またはトランザクションログに記録され、ユーザーマスターデータテーブル(EMPレコードなど)に紐づいています。 例 j.doebsmith123User7890 | |||
| 未払い残高 OutstandingBalance | 請求イベントについて、支払者または患者から回収する必要がある残額です。 | ||
| 説明 この属性は、アクティビティ発生時点における特定の請求イベントの売掛金残高を示します。ケースの全期間を通じた財務状況を表します。 未払い残高は、財務報告や「未払い残高の滞留期間レポート」に欠かせません。この値を期間別に、また支払者や部門などの属性別に分析すると、回収の優先順位付け、キャッシュフローの管理、財務リスクの評価に役立ちます。 重要な理由 プロセスの遅延による財務への影響を直接測定できます。回収の優先順位付け、キャッシュフローの管理、売掛金の把握に欠かせません。 入手先 Epic Resoluteの患者アカウントまたは病院アカウント(HAR)レコードにある主要フィールドです。財務トランザクションに応じて更新される累積残高です。 例 1500.00250.750.00 | |||
| 調整理由 AdjustmentReason | 患者のアカウント残高に対して手動または自動で調整を行った理由です。 | ||
| 説明 この属性は、通常の入金や請求以外の理由でアカウント残高が変更された理由を示します。支払者との契約に基づく減額、少額残高の償却、計上ミスの修正などが該当します。 この属性は「種類別アカウント調整件数」ダッシュボードに欠かせません。調整理由を分析すると、組織は収益の取りこぼしの原因を特定し、支払者との契約の影響を把握して、請求プロセスの非効率やミスを見つけられます。 重要な理由 アカウント残高が変更された理由を把握し、収益の取りこぼしや請求の精度を分析できます。不要な償却の削減にも役立ちます。 入手先 Epic Resoluteの患者会計モジュールにある調整レコードのトランザクション詳細に記録されています。 例 契約上の減額少額残高の償却請求重複の修正 | |||
| 請求部門 BillingDepartment | 請求イベントまたはアクティビティを担当する部門または機能チームです。 | ||
| 説明 この属性は、請求イベントに関連する、または特定のアクティビティを実行した組織単位を示します。「入院請求」「外来請求」「否認管理チーム」などが該当します。 この属性は「請求部門のパフォーマンス指標」ダッシュボードに欠かせません。否認率や請求記録にかかる時間などの主要指標を部門間で比較できます。管理者は、実績の高い部門を特定し、効果的な方法を標準化して、リソースを適切に配分できます。 重要な理由 部門間のパフォーマンスを比較し、効果的な方法や改善が必要な領域、追加リソースが必要な領域を特定できます。 入手先 Epic Resoluteでは、ユーザーレコード、患者アカウント、またはサービス提供場所に紐づいている場合があります。 例 循環器科の請求放射線科のRCM中央請求部門 | |||
| イベント終了時刻 EventEndTime | アクティビティの完了時刻を示すタイムスタンプです。アクティビティの所要時間の算出に使用できます。 | ||
| 説明 この属性には、アクティビティの完了時刻が記録されます。開始時刻と終了時刻が同じ瞬時のイベントも多くありますが、否認後のフォローアップ電話など、所要時間を測定できるタスクもあります。 終了時刻が記録されていれば、アクティビティの処理時間を「EndTime」-「StartTime」で直接算出できます。次のアクティビティの開始時刻から所要時間を推定する方法と異なり、ステップ間の待ち時間を考慮できるため、より正確です。「ProcessingTime」属性の算出にも使用します。 重要な理由 各アクティビティの完了にかかる時間を正確に算出できます。非効率なタスクの特定や、リソースの生産性測定に役立ちます。 入手先 作業キューやアクティビティ管理ログなど、タスクの開始時刻と終了時刻を記録するEpic Resoluteの一部モジュールで取得できる場合があります。明示的に記録されていないこともよくあります。 例 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| ソースシステム SourceSystem | データの取得元となる情報システムです。 | ||
| 説明 この属性はレコードのソースシステムを示します。この場合はEpic Resoluteです。複数のシステムを連携している環境では、データの取得元を区別するために使います。 単一システムのデータだけを見る場合は不要に思えるかもしれませんが、データガバナンスと拡張性を考慮した適切な方法です。たとえば、後から別の回収業者のシステムのデータを統合する場合も、データの出所を明確にできます。 重要な理由 データの来歴とコンテキストを明確にし、データガバナンスや問題の調査に欠かせない、データの取得元を把握できるようにします。 入手先 通常、データの抽出・変換時に、データセットの取得元を示す固定値として追加します。 例 Epic ResoluteEpicResolute_V2023 | |||
| 最終データ更新日時 LastDataUpdate | このイベントのデータがソースシステムから最後に更新または抽出された日時です。 | ||
| 説明 この属性はデータの鮮度を示します。Epic Resoluteからプロセスマイニング用のデータセットにレコードが最後に取り込まれた日時を確認できます。 分析の適時性を把握し、データを検証するうえで重要です。利用可能な最新情報を見ているかどうかを確認でき、データ更新サイクルの管理にも欠かせません。 重要な理由 分析対象のデータがいつ時点のものかを把握できるため、正確で最新の情報に基づく業務上の意思決定に役立ちます。 入手先 このタイムスタンプは、データ取り込み時にETL(抽出、変換、読み込み)プロセスによって追加されます。 例 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| 収益サイクルの合計時間 TotalRevenueCycleTime | 最初のサービスイベントから最終支払いまたはアカウントのクローズまでの合計所要時間です。 | ||
| 説明 これは、1件の請求イベントにおける収益サイクルの開始から終了までの所要時間を測るケース単位のKPIです。通常、「サービス提供」アクティビティから最終の「支払い受領」または「アカウントクローズ」アクティビティまでの時間差として算出します。 この全体指標により、RCMプロセス全体の効率を把握できます。KPIを継続的に追跡すると、プロセス改善施策の効果を測定でき、現金化の速さを示す重要な指標にもなります。 重要な理由 プロセス全体の効率を把握し、サービスの提供から現金化までにかかる時間を直接測定できます。 入手先 プロセスマイニングツールで、各ケースの最初と最後のイベントを抽出し、その時間差を求めて算出します。 例 259200038880005184000 | |||
| 患者ID PatientId | サービスを受ける患者を特定する一意の識別子です。 | ||
| 説明 この属性は、患者の医療記録番号(MRN)またはその他の一意の識別子です。財務上の請求イベントを特定の患者に関連付けます。 患者のプライバシー保護のため、通常は主要な分析軸として使用しませんが、データ検証には欠かせません。また、1人の患者に関するすべての請求イベントを集計し、患者の財務面での全体的な経過を把握するためにも利用できます。臨床プロセスのデータと連携する場合にも重要です。 重要な理由 財務データを特定の患者に関連付け、データ検証や患者の経過全体の分析に役立ちます。ただし、プライバシーに配慮して取り扱う必要があります。 入手先 Epic全体で使用される基本的な識別子で、患者の登録情報やアカウント記録に関連付けられています。 例 MRN-1234567MRN-8765432MRN-5551234 | |||
| 支払期限 PaymentDueDate | 請求対象のサービスについて、支払いが予定されている期限日です。 | ||
| 説明 この属性は、請求書に記載された期限、または支払者との契約で定められた期限を示します。支払いが期限内に行われたかを測る基準になります。 支払期限は、「未収残高の滞留期間レポート」の作成に欠かせません。未決済残高について現在の日付と支払期限を比較すると、売掛金を滞留期間別(例:0~30日、期限超過31~60日)に分類できます。これにより、期限を大幅に過ぎたアカウントを優先して回収できます。 重要な理由 売掛金の滞留期間分析の基準となり、回収の優先順位付けや未払い請求による財務リスクの管理に役立ちます。 入手先 この日付は、Epic内の支払者との契約または患者アカウント情報に保存された請求日と支払条件に基づいて算出されることがよくあります。 例 2023-05-302023-06-152023-07-01 | |||
| 支払者名 PayerName | 支払いを担う保険会社、政府機関、またはその他の組織の名前です。 | ||
| 説明 この属性は、請求イベントに関連する主な支払者を示します。「Blue Cross Blue Shield」「Medicare」「Aetna」などが該当します。患者が自己負担する場合は、患者を示すことがあります。 支払者別にプロセスを分析すると、特定の支払者で否認率が高い、支払いに時間がかかる、要件が複雑であるといった傾向が明らかになります。このインサイトをもとに、支払者ごとに請求方法を調整し、業務効率と入金速度を高められます。 重要な理由 支払者別にパフォーマンスを分析し、否認率が高い支払者や支払いに時間がかかる支払者を特定できます。対象を絞ったフォローアップの方針を立てるのに役立ちます。 入手先 この情報は患者の保険適用内容の一部であり、Epic Resoluteの病院アカウント(HAR)に関連付けられています。 例 メディケアパートBユナイテッドヘルスケアエトナPPO | |||
| 自動処理フラグ IsAutomated | アクティビティがシステムまたは自動処理によって実行されたかを示す真偽値です。 | ||
| 説明 このフラグにより、請求の自動生成や資格確認など、システムが自動で実行したタスクと、ユーザーが手動で行ったタスクを区別できます。 この属性を分析すると、プロセスの自動化の度合いを把握できます。自動処理と手動処理の効率やエラー率を比較したり、さらなる自動化の機会を見つけたり、既存のボットやシステムルールのパフォーマンスを監視したりできます。 重要な理由 システム主導のアクティビティと人が行うアクティビティを区別できます。自動化の効果を評価し、新たな自動化の機会を見つけるうえで重要です。 入手先 アクティビティの「ResponsibleUser」がシステムアカウントまたはサービスアカウントかどうかを確認するか、自動処理と判定された特定のアクティビティ名にフラグを付けて判定することがよくあります。 例 truefalse | |||
| 調整額 AdjustedAmount | 調整取引の金額です。 | ||
| 説明 この項目には、アカウント調整の具体的な金額が記録されます。アカウント残高への貸方または借方を表すため、正または負の値になります。 この金額は、「調整種別ごとのアカウント調整額」ダッシュボードの主要指標です。調整理由ごとに合計すると、契約上の義務による収益の減額と、修正可能な誤りによる損失など、調整種別ごとの財務上の影響を明確に把握できます。 重要な理由 アカウント調整の財務上の影響を数値化し、収益の漏れや請求誤りに伴うコストを測定できます。 入手先 Epic Resoluteの財務取引明細テーブルにあり、調整種別の取引に関連付けられています。 例 -1250.45-50.0025.10 | |||
| 請求ID ClaimId | 支払者に提出した保険請求に割り当てられる一意の識別子です。 | ||
| 説明 この属性は、支払者に送付した請求書(例:CMS-1500またはUB-04)を特定するIDです。サービスの再請求や異議申し立てが行われる場合、1回の請求イベントに複数の請求が含まれることがあります。 請求IDで追跡すると、請求提出や否認管理のサブプロセスを詳しく分析できます。同じサービスに対する初回請求と、その後に再提出した請求に関連するアクティビティを区別できます。 重要な理由 個々の請求提出のライフサイクルを追跡するための詳細な識別子です。再提出や異議申し立ての分析に欠かせません。 入手先 請求が作成されると、Epic Resoluteの請求管理モジュールで生成され、請求データテーブルに保存されます。 例 CLM-2023-98765CLAIM-0012345623189A4567 | |||
収益サイクル管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| アカウントのクローズ | これは最後のアクティビティです。請求イベントの未払い残高がゼロになり、保留中のアクティビティがなくなったことを示します。全額入金、調整、償却などによって完了します。 | ||
| 重要な理由 このイベントは、請求イベントの収益サイクルが完了したことを示します。サービス提供からクローズまでの全体の所要時間は、プロセス全体の効率を測る重要な業績評価指標(KPI)です。 入手先 通常、推定によって特定するイベントです。請求イベントのアカウント残高がゼロになり、その状態が続いた時点を特定します。 記録 アカウント残高の累計を計算し、残高をゼロにした最後のトランザクションのタイムスタンプを特定して推定します。 イベントタイプ inferred | |||
| アカウントへの入金消込 | 受領した入金を患者のアカウント内の特定の請求に充当または配分したイベントです。この処理により、請求イベントの未払い残高が減少します。 | ||
| 重要な理由 入金消込を効率よく行うことは、正確なアカウント残高の維持と請求イベントの完了に欠かせません。二次請求や回収の対象となる残高を正しく特定できます。 入手先 Resoluteに明示的なトランザクションとして記録されます。入金消込では、入金トランザクションと1件以上の請求トランザクションが紐づけられ、その内容がトランザクション詳細テーブルに記録されます。 記録 入金を請求に充当したトランザクションレコードを取得します。特定のトランザクション種別で識別できます。 イベントタイプ explicit | |||
| サービス提供 | このアクティビティは、患者に診療サービスを提供した時点を示し、請求イベントの起点となります。通常、医療従事者が診察や処置を確定した際に、Epic EHR(EpicCare)から記録されます。 | ||
| 重要な理由 これは収益サイクルの主な開始イベントです。この時点から請求記録までの時間を分析することで、請求開始の遅れや収益の取りこぼしにつながる可能性を特定できます。 入手先 通常、このイベントは請求アカウントに紐づく臨床モジュールのサービス日時または診察日時から推定します。請求トランザクションに記録されたサービス日が重要なデータ項目です。 記録 請求イベントにおける最初の請求トランザクションに紐づくサービス日から推定します。 イベントタイプ inferred | |||
| 入金受領 | 支払者または患者から入金を受け取ったことを示します。通常、電子送金通知(ERA)を読み込んだとき、または小切手の情報を手動でシステムに入力したときに記録されます。 | ||
| 重要な理由 このアクティビティは、収益の入金を示す重要なマイルストーンです。請求提出から入金受領までの時間は、売掛金管理の重要な指標です。 入手先 Resoluteに入金トランザクションとして明示的に記録されます。日付、入金元、金額が記録され、個々の請求に全額が消し込まれる前に登録されることもよくあります。 記録 財務トランザクションログから入金トランザクションを取得します。多くの場合、特定のトランザクション種別で識別できます。 イベントタイプ explicit | |||
| 支払者による請求否認 | 支払者から請求を否認したという通知を受け取ったことを示します。Epicが電子送金通知(835ファイル)を処理したとき、またはユーザーが否認を手動で登録したときに記録されます。 | ||
| 重要な理由 このアクティビティを起点に、重要な手戻りが発生します。否認の理由と件数を分析することは、根本原因の特定、初回支払い率の向上、回収の遅れの削減に欠かせません。 入手先 請求に対するトランザクションまたはステータス更新として明示的に記録されます。理由コードを含む否認情報は、通常、電子的に受信されてアカウントに登録されます。 記録 否認を示す特定のトランザクション種別または請求ステータスの更新を抽出します。 イベントタイプ explicit | |||
| 支払者への請求提出 | 請求を審査してもらうため、保険の支払者に正式に送信した時点を示します。Epicでは追跡対象のイベントであり、電子請求ファイルをクリアリングハウスまたは支払者に送信した際に記録されます。 | ||
| 重要な理由 このマイルストーンを起点に、支払者の支払い期間が始まるため、重要です。分析することで、請求データの送信効率を測定し、「請求書から支払者への納品時間」の重要業績評価指標(KPI)を把握できます。 入手先 Resoluteに明示的に記録されるイベントです。請求レコードには提出ステータスと送信日時が記録されます。 記録 請求ステータスが「提出済み」または「送信済み」に変わった日時を取得します。 イベントタイプ explicit | |||
| 請求記録 | 提供したサービスに対する請求対象額を正式に記録したことを示します。Epicでは通常、患者のアカウントに明示的なトランザクションとして登録されます。臨床上の処置から自動で作成される場合と、手動で入力される場合があります。 | ||
| 重要な理由 これは最初の重要なマイルストーンです。請求記録の速度と正確性を測定することで、請求プロセスを早め、提供したすべてのサービスが請求されているかを確認できます。 入手先 Resoluteのトランザクションログに明示的に記録されます。各請求は、計上日、サービス日、金額を含む個別のレコードです。ARPB_TRANSACTIONSなどのテーブルに記録されていることがよくあります。 記録 システムの財務トランザクションログから、請求計上のトランザクションを取得します。 イベントタイプ explicit | |||
| アカウント調整 | 契約上の調整、少額残高の償却、顧客対応としての割引など、入金以外のトランザクションによってアカウント残高が変更されたことを示します。特定のトランザクション種別として記録されます。 | ||
| 重要な理由 調整を分析することは、収益の取りこぼしを特定するうえで重要です。特定の調整種別が多い場合、料金表、契約、社内方針に問題がある可能性があります。 入手先 Resoluteの財務ログに調整トランザクションとして明示的に記録されます。各調整には、特定の種別または理由コードが紐づきます。 記録 財務調整または償却に該当するトランザクション種別を抽出します。 イベントタイプ explicit | |||
| 否認へのフォローアップ開始 | 否認された請求を確認し、解決するための内部プロセスが始まったことを示します。通常、ユーザーがワークキューで否認された請求の担当になったとき、またはステータスを変更したときに記録されます。 | ||
| 重要な理由 このアクティビティを追跡すると、否認管理チームの対応速度を測定できます。否認からフォローアップ開始までに遅れがあると、収益サイクルが不必要に長引く可能性があります。 入手先 通常、Epicのワークキューにおける請求ステータスまたは担当履歴の変更から推定します。たとえば、請求ステータスが「否認」から「確認中」に変わった場合です。 記録 請求ステータスの変更、またはユーザーが否認案件の対応を開始したことを示す監査ログエントリから推定します。 イベントタイプ inferred | |||
| 残高を回収部門へ移管 | 未払い残高を社内または外部の回収プロセスに移管した時点を示します。通常、アカウントまたは請求イベントのステータス変更として明示的に記録されます。 | ||
| 重要な理由 このアクティビティを起点に、未払い残高の回収に向けた最終段階が始まります。貸倒損失を抑えるには、回収プロセスの成功率とサイクルタイムを追跡することが重要です。 入手先 通常、明示的なイベントとして記録されます。Epicにはアカウントを回収業者に移管する機能があり、実行時にログエントリまたはアカウントのステータス変更が記録されます。 記録 アカウントが回収業者に委託されたことを示すステータス変更またはトランザクションを特定します。 イベントタイプ explicit | |||
| 請求データ作成 | このアクティビティは、記録された請求額に基づいて、システムが正式な請求データまたは請求書を作成したことを示します。支払者または患者に送付する前の準備段階です。 | ||
| 重要な理由 請求データの作成を追跡すると、請求の記録から提出準備までの遅延を特定できます。請求全体の所要時間に影響する、重要な内部ステップです。 入手先 通常、請求または請求データ作成のバッチ処理が実行された際に記録されます。特定のアカウント向けに請求ファイル(837ファイルなど)が作成されると、システムにタイムスタンプが記録されます。 記録 請求データが作成され、提出可能になったことを示すログエントリまたはステータス変更を特定します。 イベントタイプ explicit | |||
| 請求の再提出 | 否認された請求を修正し、支払者に再送した後に発生するイベントです。元の請求に紐づく、別個の提出イベントです。 | ||
| 重要な理由 これは手戻りの重要なステップです。再提出までの時間と、再提出した請求の承認率を測定することで、否認解決プロセスの有効性を把握できます。 入手先 初回の提出と同様に明示的に記録されるイベントですが、再提出として識別されることがよくあります。請求レコードには新しい提出日時が記録され、再提出コードが含まれる場合もあります。 記録 修正または再提出として識別された請求の提出日時を取得します。 イベントタイプ explicit | |||
データ抽出ガイド
ステップ
- データベース接続の確立:Epic Clarityデータベースへの読み取り専用の認証情報を取得します。DBeaverやMicrosoft SQL Server Management Studioなどの標準SQLクライアントを使って、データベースサーバーに接続します。
- 主要テーブルの特定:抽出対象となる主なテーブルは、ケース情報の
HSP_ACCOUNT、財務イベントのHSP_TRANSACTIONS、請求状況のCLP_CLAIM_INFO、支払い計上の詳細情報のF_ARHB_TX_SET_POST_HXです。ユーザー情報を取得するため、CLARITY_EMPなどのマスターファイルも結合します。 - 対象範囲の定義:クエリを作成する前に、分析対象を決めます。通常は3~6か月の期間を設定し、対象に含める、または除外する病院サービスエリア(
SERV_AREA_ID)やアカウントクラスを指定します。 - SQLクエリの作成:共通テーブル式(CTE)を使って、定義した対象範囲に該当する
HSP_ACCOUNT_IDを最初に抽出するSQLクエリを作成します。このデータを請求イベントの母集団として使用します。 - アクティビティごとのクエリ作成:必要な12種類のアクティビティそれぞれについて、関連テーブルからデータを取得する
SELECT文を作成します。最初のCTEと結合し、対象のアカウントだけを分析するようにします。 - UNION ALLによるクエリの結合:
UNION ALL演算子を使って、各アクティビティのクエリ結果を1つのイベントログにまとめます。各クエリの行が縦方向に追加されます。 - 標準スキーマへのマッピング:各
SELECT文で列に別名を付け、BillingEvent、ActivityName、EventTimestamp、ResponsibleUserなど、ProcessMindのスキーマに合わせます。特定のアクティビティに該当しない属性にはNULLを指定します。 - クエリの実行と調整:Clarityデータベースに対してクエリ全体を実行します。テーブルのサイズによっては、かなり時間がかかる場合があります。処理に時間がかかる場合は、期間を短くするか、最初のCTEに具体的なフィルターを追加してください。
- 出力の確認:クエリの実行後、出力の最初の数百行を確認します。すべての列が含まれていること、タイムスタンプの形式が統一されていること、想定どおりに異なる
ActivityNameの値が表示されていることを確認してください。 - CSVへのエクスポート:SQLクライアントから結果全体をCSVファイルにエクスポートします。UTF-8エンコーディングを使用し、正しい列名を含むヘッダー行を設定してください。
- アップロードの準備:ProcessMindにアップロードする前にCSVファイルを開き、書式に誤りがないことを確認します。たとえば、タイムスタンプの形式が
YYYY-MM-DD HH:MI:SSで統一されているか確認してください。これでファイルを取り込む準備が整います。
設定
- データベース接続:Epic Clarityデータベースにアクセスできる読み取り専用ユーザーアカウントが必要です。
- 期間のパラメーター:提示するクエリでは、
@StartDateと@EndDateの変数を使用します。分析期間を指定するため、これらの値を設定してください。データ量とパフォーマンスのバランスを取るには、3~6か月の期間を推奨します。 - テーブルと列のマッピング:このクエリは、Clarityの標準的なテーブル名と列名を前提としています。組織固有のEpicの設定やバージョンによって異なる場合があります。必要に応じて、テーブル名、列名、結合条件を調整してください。
- 取引コードとステータスコード:クエリには
[Your Denial Tx Type]や[Your Collections Status Code]などのプレースホルダーが含まれています。使用環境に適したコードを確認するため、Epicのシステム管理者に問い合わせるか、ZC_TX_TYPEやZC_ACCOUNT_STATUSなどの関連マスターファイルを参照してください。 - フィルタリング:パフォーマンスを高め、分析対象を絞り込むには、最初の
BaseAccountsCTEにフィルターを追加します。病院サービスエリアを限定するSERV_AREA_IDや、入院または外来の請求に絞るACCOUNT_CLASS_Cが一般的です。
クエリの例 sql
DECLARE @StartDate DATE = '2023-01-01';
DECLARE @EndDate DATE = '2023-06-30';
WITH BaseAccounts AS (
SELECT DISTINCT
HA.HSP_ACCOUNT_ID
FROM
HSP_ACCOUNT HA
WHERE
HA.ADM_DATE_TIME >= @StartDate
AND HA.ADM_DATE_TIME <= @EndDate
-- Add additional filters here if needed, for example:
-- AND HA.SERV_AREA_ID = [Your Service Area ID]
)
-- 1. Service Rendered
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Service Rendered' AS ActivityName,
tx.SERVICE_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
AND tx.ORIG_REV_TX_ID IS NULL -- Not a reversal
UNION ALL
-- 2. Charges Captured
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Charges Captured' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
UNION ALL
-- 3. Claim Generated
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Generated' AS ActivityName,
claim.GENERATED_TIME AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.GENERATED_TIME IS NOT NULL
UNION ALL
-- 4. Claim Submitted to Payer
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
claim.XMIT_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.XMIT_DATE IS NOT NULL
UNION ALL
-- 5. Claim Denied by Payer
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
remit.REMIT_CODE_ID AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN F_ARHB_TX_SET_POST_HX remit ON tx.TX_ID = remit.TX_ID
WHERE tx.TX_TYPE_C IN ([Your Denial Tx Type]) -- Placeholder for denial transaction type codes
UNION ALL
-- 6. Denial Follow-Up Initiated (assumes status change on account)
SELECT
hist.HSP_ACCOUNT_ID AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
NULL AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCT_STATUS_HX hist
INNER JOIN BaseAccounts ba ON hist.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON hist.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE hist.ACCOUNT_STATUS_C = [Your Denial Followup Status Code] -- Placeholder for a status indicating follow-up
UNION ALL
-- 7. Claim Resubmitted
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
claim.RESUBMIT_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON claim.RESUBMIT_USER_ID = emp.USER_ID
WHERE claim.RESUBMIT_DATE IS NOT NULL
UNION ALL
-- 8. Payment Received & 9. Payment Posted to Account (combined for this query)
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE tx.TX_TYPE_C IN ([Your Payer Payment Tx Type], [Your Patient Payment Tx Type]) -- Placeholder for payment transaction types
UNION ALL
-- 10. Account Adjustment Made
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
zcar.NAME AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN ZC_ADJ_REASON zcar ON tx.ADJ_REASON_C = zcar.ADJ_REASON_C
WHERE tx.TX_TYPE_C IN ([Your Adjustment Tx Type]) -- Placeholder for adjustment transaction types
UNION ALL
-- 11. Balance Sent to Collections
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
INNER JOIN HSP_ACCT_STATUS_HX hist ON acct.HSP_ACCOUNT_ID = hist.HSP_ACCOUNT_ID AND hist.ACCOUNT_STATUS_C = [Your Collections Status Code]
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE acct.ACCOUNT_STATUS_C = [Your Collections Status Code] -- Placeholder for collections status
UNION ALL
-- 12. Account Closed
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Account Closed' AS ActivityName,
acct.CLOSED_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- System or Final transaction user
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE acct.ACCT_FIN_BALANCE = 0
AND acct.CLOSED_DATE IS NOT NULL
AND acct.CLOSED_DATE BETWEEN @StartDate and @EndDate
ORDER BY
BillingEvent,
EventTimestamp; ステップ
- Epic Clarityの収益サイクルデータセットに対する正規のアクセス権があることを確認します。アカウント、請求、保険請求、否認、支払い、調整、回収、クローズの履歴に必要なソーステーブルとビューも対象です。Epicの組織によって利用できるテーブルや列名が異なるため、クエリ内の各プレースホルダーを環境内の対応するClarityオブジェクトにマッピングしてください。
- [Start date parameter]と[End date parameter]を使って抽出期間を定義します。まず3~6か月の期間で実行し、クエリのパフォーマンスとイベントの網羅性を検証してから、必要に応じて期間を延長してください。
- BillingEventのマッピングを設定します。クエリでは、利用可能な場合に
HSP_ACCOUNT.HSP_ACCOUNT_IDを既定のケース識別子として使用します。組織で請求イベントを請求、保険請求、または受診単位として定義している場合は、承認済みの識別子に置き換え、すべてのアクティビティソースで一貫して使用してください。 - 各ソースアクティビティを、信頼できるタイムスタンプとソース属性にマッピングします。「サービス提供」には文書化されたサービスまたは受診の完了タイムスタンプを使用します。「請求の記録」には請求計上のタイムスタンプを使用します。「保険請求の作成」と「支払者への保険請求の提出」には、それぞれ対応する請求ライフサイクルのタイムスタンプを使用します。否認、フォローアップ、再提出、支払い、調整、回収、クローズには、文書化された取引またはステータスのタイムスタンプを使用してください。
- クエリ内の角括弧付きプレースホルダーをすべて置き換えます。対象には[Your service source table]、[Your charge source table]、[Your claim source table]、[Your denial source table]、[Your follow-up source table]、[Your payment source table]、[Your adjustment source table]、[Your collections source table]、[Your account closure source table]が含まれます。文書化されていない取引コードに置き換えないでください。Epicのレポート作成チームが承認した取引値またはステータス値を使用します。
- 組織で承認されたSQLクライアントまたはレポートプラットフォームでクエリを実行します。12種類すべてのアクティビティラベルが、明示的な行として返されることを確認してください。ProcessMindは、残高、ステータス、イベントの順序から欠落したライフサイクルイベントを推定しません。
- 出力スキーマを確認します。結果には、BillingEvent、ActivityName、EventTimestamp、ResponsibleUser、BillingDepartment、DenialReasonCode、AdjustmentReason、OutstandingBalance、ServiceTypeが含まれている必要があります。タイムスタンプにはタイムゾーンまたは現地時刻に関する文書を添え、許可されている場合は内部監査用の抽出データにソース識別子を保持してください。
- 各BillingEvent内の時系列順、重複の扱い、NULLの割合、アクティビティ数、ソースシステムのレポートとの照合結果を検証します。対象期間より前に始まるケースや、期間終了後に完了するケースの解釈に必要なイベントが、期間外にないか確認してください。
- 結果を、ProcessMindがサポートする区切り形式のファイルまたはデータベース接続としてエクスポートします。イベントごとに1行とし、列名を固定し、タイムスタンプ形式を統一して、UTF-8エンコーディングを使用してください。セルの結合や表示用の合計行は含めないでください。アップロード時に、BillingEventをケース識別子、ActivityNameをアクティビティ、EventTimestampをイベントタイムスタンプとして設定します。
設定
- ソースマッピング: Epic Clarityの実装内容は環境によって異なります。角括弧で囲まれたソースオブジェクトと列のプレースホルダーは、それぞれの環境で文書化されたテーブル、ビュー、または承認済みのレポーティングレイヤーに置き換えてください。他のEpic環境で一般的に使われているという理由だけで、テーブルやフィールドが存在すると判断しないでください。
- ケース識別子: デフォルトのクエリマッピングでは、HSP_ACCOUNT.HSP_ACCOUNT_IDを使用します。組織でBillingEventをアカウント、受診、請求、請求項目、または別の承認済み業務キーのどれとして定義しているか確認してください。
- 日付範囲: まず3~6か月を対象にしてください。ケースがレポート期間より前に始まる場合は遡及期間を含め、請求、否認、支払い、または終了がサービス日以降に発生する場合は、その後の期間も含めてください。
- アクティビティのタイムスタンプ: 各アクティビティに対して、信頼できるタイムスタンプを1つ設定してください。実際の業務イベント時刻として文書化されたソースシステムのタイムスタンプでない限り、抽出時刻、ファイルの読み込み時刻、または現在のステータス時刻で代用しないでください。
- フィルター: [会社コードフィルター]、[文書タイプフィルター]、[部門フィルター]、支払者、サービスエリア、アカウントクラスの各フィルターは、定義が文書化され、分析に必要な場合にのみ適用してください。すべてのUNION ALL句でフィルターを統一してください。
- 取引とステータスのマッピング: 請求計上、請求データ作成、請求送信、否認、フォローアップ、再送信、支払い受領、支払い計上、調整、回収、終了について、組織で承認された値を設定してください。Epicの取引値やソース構造は実装によって異なるため、クエリでは意図的にプレースホルダーを使用しています。
- NULLの処理: アクティビティに該当しない属性はNULLのまま保持してください。否認理由、調整理由、ユーザー、部門、サービス種別が欠落している場合に、実在しない値で補わないでください。
- パフォーマンス: HSP_ACCOUNTとの結合前に、インデックス付きの日付列と承認済みの組織フィルターでソース行を絞り込んでください。条件式でインデックス付きタイムスタンプ列に関数を適用しないでください。生の履歴データが大量にある場合は、承認済みのレポーティングビューに各ソースアクティビティを事前に格納することを検討してください。
- 重複排除: 文書化されたルールがない限り、重複イベントを削除しないでください。1つのBillingEventに対して、複数の支払い、調整、送信、またはステータス変更が有効なイベントである場合があります。
- 前提条件: 必要なアクセスには、Epic Clarityのレポーティング権限、収益サイクルおよびアカウント履歴データへのアクセス、承認済みのSQL実行環境、保護対象医療情報の取り扱いに関する組織の承認が含まれる場合があります。請求、送金通知、ワークキュー、回収、終了の履歴を利用できるかどうかは、ライセンスを取得し、実装されているEpicモジュールやインターフェースによって異なります。
クエリの例 sql
WITH
service_rendered AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Service Rendered' AS ActivityName,
CAST(s.[Service rendered timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(s.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(s.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(s.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(s.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your service source table] s
ON s.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE s.[Service rendered timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND s.[Service rendered timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND [Your company code filter]
),
charges_captured AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Charges Captured' AS ActivityName,
CAST(t.[Charge captured timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(t.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(t.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(t.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(t.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN AR_PB_TRANSACTIONS t
ON t.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE t.[Charge captured timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND t.[Charge captured timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND t.[Charge transaction filter]
AND [Your company code filter]
),
claim_generated AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Generated' AS ActivityName,
CAST(c.[Claim generated timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim generated timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim generated timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim generated status filter]
AND [Your company code filter]
),
claim_submitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
CAST(c.[Claim submitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim submitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim submitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim submitted status filter]
AND [Your company code filter]
),
claim_denied AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
CAST(d.[Denial timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(d.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(d.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(d.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(d.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(d.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your denial source table] d
ON d.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE d.[Denial timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND d.[Denial timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND d.[Denial status filter]
AND [Your company code filter]
),
denial_follow_up AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
CAST(f.[Follow-up timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(f.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(f.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(f.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(f.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(f.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your follow-up source table] f
ON f.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE f.[Follow-up timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND f.[Follow-up timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND f.[Follow-up status filter]
AND [Your company code filter]
),
claim_resubmitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
CAST(c.[Claim resubmitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim resubmitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted status filter]
AND [Your company code filter]
),
payment_received AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Received' AS ActivityName,
CAST(p.[Payment received timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment received timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment received timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment received status filter]
AND [Your company code filter]
),
payment_posted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
CAST(p.[Payment posted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment posted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment posted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment posted status filter]
AND [Your company code filter]
),
account_adjustment AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
CAST(x.[Adjustment timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(x.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(x.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(x.[Adjustment reason column] AS VARCHAR(100)) AS AdjustmentReason,
CAST(x.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(x.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your adjustment source table] x
ON x.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE x.[Adjustment timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND x.[Adjustment timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND x.[Adjustment transaction filter]
AND [Your company code filter]
),
balance_collections AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
CAST(k.[Collections timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(k.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(k.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(k.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(k.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your collections source table] k
ON k.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE k.[Collections timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND k.[Collections timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND k.[Collections status filter]
AND [Your company code filter]
),
account_closed AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Closed' AS ActivityName,
CAST(z.[Account closed timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(z.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(z.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(z.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(z.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your account closure source table] z
ON z.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE z.[Account closed timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND z.[Account closed timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND z.[Account closed status filter]
AND [Your company code filter]
)
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM service_rendered
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM charges_captured
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_generated
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_submitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_denied
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM denial_follow_up
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_resubmitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_received
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_posted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_adjustment
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM balance_collections
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_closed
ORDER BY BillingEvent, EventTimestamp, ActivityName; 始める準備はできていますか?
正確なデータを使って、収益サイクル管理プロセスの可能性を引き出しましょう。今日から効率と財務パフォーマンスの向上に取り組めます。
効率を最大限に高める:今すぐ収益サイクル管理を最適化
Epic ResoluteのRCMにおける非効率を特定し、サイクルタイムを30%短縮しましょう。
クレジットカードは不要です。今日から最適化を始めましょう。