収益サイクル管理のデータテンプレート
収益サイクル管理のデータテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- 抽出手順
収益サイクル管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 収益サイクル管理プロセス内で実行された特定のイベントまたはタスクの名称です。 | ||
| 説明 「請求取得」、「支払者への請求提出」、「入金受領」など、収益サイクルにおける1つのステップを表す属性です。各アクティビティは、サービスの請求と入金回収における独立したマイルストーンを示します。 アクティビティの分析は、プロセスマイニングの基盤です。プロセスマップの可視化、一般的な経路の特定、ステップ間のボトルネックの発見、標準業務手順への適合度の測定が可能になります。 重要な理由 プロセスマップ上のステップを定義し、収益サイクルにおける業務の流れを可視化、分析、効率化できるようにします。 入手先 通常は、Epic Resoluteの請求・請求管理モジュール内にあるイベントログ、監査証跡、またはステータス変更記録から取得します。 例 チャージ取得支払者への請求送信入金受領口座クローズ | |||
| イベントタイムスタンプ EventTimestamp | 特定のアクティビティまたはイベントが発生した正確な日時です。 | ||
| 説明 Event Timestampは、アクティビティが実行された時点を記録します。この時間データは、収益サイクルにおけるイベントの発生時刻と順序を把握するうえで重要です。 分析では、請求取得の遅延や入金計上までの時間など、アクティビティ間の期間を計算するためにタイムスタンプを使います。ボトルネックの発見、サイクルタイムの測定、期間ごとのプロセスパフォーマンスの分析にも役立ちます。正確なタイムスタンプは、ほぼすべての時間ベースのKPIとダッシュボードに欠かせません。 重要な理由 サイクルタイムや期間など、時間に基づくすべての指標を計算するために欠かせない属性です。遅延や非効率な処理の特定に役立ちます。 入手先 Epic Resolute内の取引テーブルまたはイベントログテーブルにあり、記録された各アクティビティに関連付けられています。フィールド名には、Dt、DTTM、Timeなどの接尾辞が付くことがよくあります。 例 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| 請求イベント BillingEvent | 請求を発生させる単一のサービスまたは製品提供を識別する一意の識別子であり、主要なケース識別子として機能します。 | ||
| 説明 Billing Eventは、特定の請求対象項目について、収益サイクル内のすべてのアクティビティを結び付ける中核的な識別子です。サービスが提供された時点で始まり、口座の精算またはクローズによって終了します。 プロセスマイニング分析では、各請求のエンドツーエンドの流れを再構成するために欠かせない属性です。請求の取得、請求提出、入金計上、否認対応などのアクティビティを請求イベント単位で追跡できるため、プロセスの流れとそのばらつきを明確に把握できます。 重要な理由 関連するすべてのプロセスステップを結び付け、各サービスの収益発生から回収までのライフサイクル全体を分析するために欠かせない、基本的なCase IDです。 入手先 多くの場合、病院口座(HAR)またはEpic Resoluteにおける特定の請求セッションの一意の識別子です。HARやCharge Sessionレコードなどの具体的なテーブルについては、Epic Resoluteのドキュメントを参照してください。 例 BE10098765BE20012345BE30054321 | |||
| サービスタイプ ServiceType | 提供された医療サービスの分類または種別です。 | ||
| 説明 請求対象のサービスを、「放射線科」、「手術」、「診察」、「救急外来受診」などに分類する属性です。財務データに臨床上の背景を付加します。 サービスタイプ別に収益サイクルを分析すると、特定の診療領域に固有のプロセスの違いを発見できます。たとえば、手術は通常の外来受診よりも請求取得や承認要件が複雑で、プロセスの動きや課題が異なる場合があります。 重要な理由 財務データに臨床上の背景を付加し、医療サービスの種類が収益サイクルのプロセスと効率に与える影響を分析できます。 入手先 Epicの請求取引に関連するCharge Description Master(CDM)、サービスライン、または部門から取得します。 例 入院手術外来放射線診療救急サービス | |||
| 否認理由コード DenialReasonCode | 提出した請求を支払者が否認した理由を示す標準化コードです。 | ||
| 説明 支払者が請求を却下すると、否認理由を示すコードが返されます。「対象外サービス」、「重複請求」、「追加情報が必要」などが該当します。これらのコードは、Claim Adjustment Reason Code(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内のユーザーレコード、患者口座、またはサービス提供場所に関連付けられている場合があります。 例 循環器科の請求放射線科の収益サイクル管理中央請求オフィス | |||
| イベント終了時刻 EventEndTime | アクティビティが完了した時点を示すタイムスタンプです。アクティビティの所要時間を計算するために使います。 | ||
| 説明 アクティビティの完了時刻を記録する属性です。多くのアクティビティはStartTimeとEndTimeが同じ瞬時イベントですが、否認のフォローアップ電話など、所要時間を測定できるタスクもあります。 EndTimeがあれば、アクティビティの処理時間(「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(Extract、Transform、Load)処理によって追加されるタイムスタンプです。 例 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| 収益サイクル総時間 TotalRevenueCycleTime | 最初のサービスイベントから最終的な入金または口座クローズまでの合計期間です。 | ||
| 説明 1つの請求イベントにおける収益サイクルのエンドツーエンドの期間を測るケース単位のKPIです。通常は、「Service Rendered」アクティビティから最終的な「Payment Received」または「Account Closed」アクティビティまでの時間差として計算します。 この上位指標により、RCMプロセス全体の効率を把握できます。KPIを継続的に追跡することで、プロセス改善施策の効果を測定し、現金化の速さを示す重要な指標を得られます。 重要な理由 プロセス効率をエンドツーエンドで把握し、サービスを現金化するまでにかかる時間を直接測定できます。 入手先 プロセスマイニングツールで計算する指標です。各ケースの最初と最後のイベントを絞り込み、その時間差を求めます。 例 259200038880005184000 | |||
| 患者ID PatientId | サービスを受けた患者の一意の識別子です。 | ||
| 説明 患者のMedical Record Number(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)に関連付けられています。 例 Medicare Part BUnitedHealthcareAetna PPO | |||
| 自動化済み IsAutomated | アクティビティがシステムまたは自動処理によって実行されたかどうかを示すブール型フラグです。 | ||
| 説明 請求の自動生成や適格性チェックなど、システムが自動的に実行したタスクと、ユーザーが手動で実行したタスクを区別するフラグです。 この属性を分析すると、プロセスの自動化レベルを把握できます。自動処理と手動処理の効率やエラー率の比較、さらなる自動化の機会の特定、既存のボットやシステムルールのパフォーマンス監視に役立ちます。 重要な理由 システム主導のアクティビティと人が行うアクティビティを区別できます。自動化の効果を評価し、新たな自動化の機会を見つけるうえで重要です。 入手先 通常は、アクティビティの「ResponsibleUser」がシステムアカウントまたはサービスアカウントかどうかを確認するか、自動化されていることが分かっている特定のアクティビティ名にフラグを付けて判定します。 例 truefalse | |||
| 調整額 AdjustedAmount | 調整取引の金額です。 | ||
| 説明 口座調整の具体的な金額を記録するフィールドです。口座残高への貸方または借方を表し、正の値または負の値になります。 「口座調整量(種別別)」ダッシュボードの主要指標です。調整理由別に合計することで、契約上の義務による償却額と、修正可能なエラーによる損失額など、調整種別ごとの財務的影響を明確に把握できます。 重要な理由 口座調整による財務的影響を数値化し、収益漏れと請求の不正確さによるコストを測定できます。 入手先 Epic Resoluteの財務取引明細テーブルにあり、調整種別の取引に関連付けられています。 例 -1250.45-50.0025.10 | |||
| 請求ID ClaimId | 支払者に提出した保険請求に割り当てられる一意の識別子です。 | ||
| 説明 支払者に送信した請求フォーム(CMS-1500やUB-04など)を識別するIDです。サービスの再請求や異議申立てにより、1つの請求イベントに複数の請求が含まれる場合があります。 Claim IDで追跡すると、請求提出と否認管理のサブプロセスを詳細に分析できます。同じサービスに対する初回請求と、その後の再提出請求に関連するアクティビティを区別できます。 重要な理由 個々の請求提出のライフサイクルを詳細に追跡する識別子です。再提出や異議申立ての分析に欠かせません。 入手先 請求作成時にEpic Resoluteの請求管理モジュールが生成し、請求データテーブルに保存します。 例 CLM-2023-98765CLAIM-0012345623189A4567 | |||
収益サイクル管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| サービス提供完了 | このアクティビティは、臨床サービスが患者に提供され、請求イベントが開始される時点を示します。通常は、臨床医が診察や処置を承認した際に、Epic EHR(EpicCare)から記録されます。 | ||
| 重要な理由 収益サイクルの主な開始イベントです。この時点からチャージ取得までの時間を分析することで、請求開始の遅延と収益漏れの可能性を特定できます。 入手先 通常は、請求アカウントに紐付けられた臨床モジュールのサービス日時または来院日時から推定します。チャージ取引のサービス日が主要なデータポイントです。 取得 請求イベントにおける最初のチャージ取引に紐付くサービス日から推定します。 イベントタイプ inferred | |||
| チャージ取得 | 提供したサービスに対する請求可能なチャージを正式に記録したことを示します。Epicでは通常、患者アカウントに明示的な取引として記録され、臨床上の操作から自動生成されるか、手動で入力されます。 | ||
| 重要な理由 これは最初の重要なマイルストーンです。チャージ取得の速度と正確性を測定することで、請求プロセスを速め、提供したすべてのサービスを確実に請求できます。 入手先 Resoluteの取引ログに明示的に記録されます。各チャージは、計上日、サービス日、金額を含む個別のエントリとして記録され、通常はARPB_TRANSACTIONSなどのテーブルに保存されます。 取得 システムの財務取引ログから、チャージ計上取引を取得します。 イベントタイプ explicit | |||
| 入金受領 | 支払者または患者からの入金を表します。通常は、電子送金通知(ERA)を読み込んだとき、または手動で小切手をシステムに入力したときに記録されます。 | ||
| 重要な理由 収益の入金が始まったことを示す重要なマイルストーンです。請求提出から入金受領までの時間は、売掛金管理のパフォーマンスを測る重要な指標です。 入手先 Resoluteで支払取引として明示的に記録されます。これらの取引には日付、入金元、金額が記録され、個々の請求への計上が完了する前に記録されることもあります。 取得 財務取引ログから支払取引を取得します。通常は、特定の取引種別によって識別します。 イベントタイプ explicit | |||
| 口座クローズ | 最終アクティビティです。請求イベントの未決済残高がゼロになり、保留中のアクティビティがなくなったことを示します。全額入金、調整、または償却によって発生します。 | ||
| 重要な理由 請求イベントの収益サイクルが正常に完了したことを示すイベントです。サービス提供からクローズまでのエンドツーエンドの期間は、プロセス全体の効率を測る重要なKPIです。 入手先 通常は推定イベントです。請求イベントの口座残高がゼロになり、その後もゼロのままとなった時点を特定して判定します。 取得 口座残高の累計を計算し、残高をゼロにした最後の取引のタイムスタンプを特定して推定します。 イベントタイプ inferred | |||
| 口座への入金計上 | 受領した入金を、患者の口座にある特定の請求へ充当または配分するイベントです。この処理により、請求イベントの未決済残高が減少します。 | ||
| 重要な理由 正確な口座残高を維持し、請求イベントを完了させるには、入金計上を効率的に行うことが欠かせません。二次請求や回収に向けて、残りの残高を正しく把握できます。 入手先 Resoluteにおける明示的な取引です。入金計上では、支払取引と1件以上の請求取引を関連付け、その内容を取引明細テーブルに記録します。 取得 支払を請求に充当する取引記録を取得します。特定の取引種別によって識別できます。 イベントタイプ explicit | |||
| 支払者による請求否認 | 支払者から請求が否認されたという通知を受け取ったことを示します。Epicが電子送金通知(835ファイル)を処理した際、またはユーザーが否認を手動で計上した際に記録されます。 | ||
| 重要な理由 このアクティビティを起点に、重要なやり直しのループが始まります。否認理由と件数を分析することは、根本原因の特定、初回支払い率の向上、回収遅延の削減に欠かせません。 入手先 請求の取引またはステータス更新として明示的に記録されます。理由コードなどの否認情報は通常、電子的に受信され、アカウントに計上されます。 取得 否認を示す特定の取引種別または請求ステータスの更新を抽出します。 イベントタイプ explicit | |||
| 支払者への請求送信 | 請求が正式に保険支払者へ送信され、審査される時点を示します。Epicでは追跡対象のイベントであり、電子請求ファイルがクリアリングハウスまたは支払者へ送信された際に記録されます。 | ||
| 重要な理由 このマイルストーンから支払者の支払い期間が始まるため、重要です。分析することで、請求送信プロセスの効率を測定し、「Invoice to Payer Delivery Time」KPIの把握に役立てられます。 入手先 Resoluteに明示的なイベントとして記録されます。請求レコードには送信ステータスと送信時刻を示すタイムスタンプが記録されます。 取得 請求ステータスが「Submitted」または「Transmitted」に変わった時点のタイムスタンプを取得します。 イベントタイプ explicit | |||
| 口座調整実施 | 契約上の調整、少額残高の償却、善意による割引など、入金以外の取引によって口座残高を変更するアクティビティです。特定の取引種別として記録されます。 | ||
| 重要な理由 調整を分析することは、収益漏れの原因を特定するうえで重要です。特定の調整種別が大量に発生している場合、料金表、契約、または社内方針に問題がある可能性があります。 入手先 Resoluteの財務ログに調整取引として明示的に記録されます。各調整には、特定の種別または理由コードが付与されます。 取得 財務調整または償却に該当する取引種別で絞り込みます。 イベントタイプ explicit | |||
| 否認フォローアップの開始 | 否認された請求を確認し、解決する社内プロセスの開始を示します。通常は、ユーザーがワークキュー内で否認請求を担当した際、またはステータスを変更した際に記録されます。 | ||
| 重要な理由 これを追跡することで、否認管理チームの対応速度を測定できます。否認からフォローアップ開始までの遅延が長いと、収益サイクルが不必要に長期化します。 入手先 通常は、Epicのワークキュー内にある請求のステータス変更または割り当て履歴から推定します。たとえば、請求ステータスが「Denied」から「In Review」に変わった場合です。 取得 請求ステータスの変更、またはユーザーが否認対応を開始したことを示す監査ログのエントリから推定します。 イベントタイプ 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クエリを作成する:Common Table Expression(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などの関連マスターファイルを参照し、環境に適したコードを特定してください。
- フィルタリング:性能を高め、分析対象を絞り込むには、初期のBaseAccounts CTEにフィルターを追加します。SERV_AREA_IDで病院サービスエリアを限定したり、ACCOUNT_CLASS_Cで入院または外来の請求に絞り込んだりできます。
a サンプルクエリ 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を標準のケース識別子として使用します。組織で請求イベントを請求、請求書、受診などの単位で定義している場合は、承認済みの識別子に置き換え、すべてのアクティビティソースで一貫して使用してください。
- 各ソースアクティビティを、信頼できるタイムスタンプとソース属性にマッピングします。Service Renderedには、文書化されたサービスまたは受診の完了タイムスタンプを使用します。Charges Capturedには請求計上のタイムスタンプを使用します。Claim GeneratedとClaim Submitted to Payerには、それぞれ対応する請求ライフサイクルのタイムスタンプを使用します。拒否、フォローアップ、再提出、支払い、調整、回収、完了には、文書化された取引またはステータスのタイムスタンプを使用してください。
- クエリ内の角括弧付きソースプレースホルダーをすべて置き換えます。これには[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イベント1行、安定した列名、一貫したタイムスタンプ形式、UTF-8エンコーディングを使用し、結合セルや表示用の合計行は含めないでください。アップロード時にBillingEventをケース識別子、ActivityNameをアクティビティ、EventTimestampをイベントタイムスタンプとして設定します。
設定
- ソースマッピング:Epic Clarityの実装は組織によって異なります。角括弧付きの各ソースオブジェクトと列のプレースホルダーを、環境内で文書化されたテーブル、ビュー、または承認済みのレポーティング層に置き換えてください。別のEpic実装で一般的だからという理由だけで、テーブルやフィールドの存在を前提にしないでください。
- ケース識別子:標準のクエリマッピングではHSP_ACCOUNT.HSP_ACCOUNT_IDを使用します。組織でBillingEventをアカウント、受診、請求書、請求、その他の承認済み業務キーのどれとして定義しているか確認してください。
- 期間:まず3~6か月を対象にします。ケースがレポート期間より前に始まる場合は遡及期間を含め、請求、拒否、支払い、完了がサービス日より後に発生する場合はフォローアップ期間を含めてください。
- アクティビティのタイムスタンプ:各アクティビティに信頼できるタイムスタンプを1つ設定します。文書化されたソースシステムのイベント時刻でない限り、抽出時刻、ファイル読み込み時刻、現在のステータス時刻を実際の業務イベント時刻の代わりに使用しないでください。
- フィルター:[Company Code filter]、[Document Type filter]、[Department filter]、支払者、サービスエリア、アカウントクラスのフィルターは、定義が文書化され、分析に必要な場合にのみ適用します。すべてのUNION ALL分岐でフィルターを統一してください。
- 取引とステータスのマッピング:請求計上、請求書作成、請求書提出、拒否、フォローアップ、再提出、支払い受領、支払い計上、調整、回収、完了について、組織で承認された値を設定します。Epicでは実装ごとに取引値とソース構造が異なるため、クエリでは意図的にプレースホルダーを使用しています。
- NULLの扱い:アクティビティに該当しない属性にはNULLを保持します。拒否理由、調整理由、ユーザー、部門、サービス種別が欠落している場合に、作成した値で置き換えないでください。
- 性能:HSP_ACCOUNTと結合する前に、インデックス付きの日付列と承認済みの組織フィルターでソース行を絞り込みます。述語内でインデックス付きタイムスタンプ列に関数を適用しないでください。生の履歴が大量にある場合は、承認済みのレポーティングビューで各ソースアクティビティを具体化することを検討してください。
- 重複排除:文書化されたルールなしに重複イベントを削除しないでください。1つのBillingEventに対して、複数の支払い、調整、提出、ステータス変更が有効なイベントとなる場合があります。
- 前提条件:Epic Clarityのレポーティング権限、収益サイクルおよびアカウント履歴データへのアクセス、承認済みのSQL実行環境、保護対象医療情報の取り扱いに関する組織の承認が必要になる場合があります。請求、支払通知、ワークキュー、回収、完了履歴を利用できるかどうかは、導入済みのEpicモジュールとライセンス、インターフェースによって異なります。
a サンプルクエリ 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%短縮します。
クレジットカードは不要です。今日から最適化を始めてください。