貴社の収益サイクル管理データテンプレート
貴社の収益サイクル管理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 抽出の手引き
収益サイクル管理属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 収益サイクル管理プロセス内で実行された特定のイベントまたはタスクの名称。 | ||
| 説明 この属性は、収益サイクルにおける個々のステップを記述するもので、「費用計上」「支払い者への請求提出」「支払い受領」などが含まれます。各アクティビティは、サービスの請求および支払い回収プロセスにおける明確な節目を示します。 アクティビティの分析はプロセスマイニングの基礎です。これにより、プロセス全体像の可視化、一般的な経路の特定、各ステップ間のボトルネックの発見、そして標準的な運用手順への準拠状況の測定が可能になります。 その重要性 プロセスマップ内のステップを定義し、収益サイクルにおける業務フローの可視化、分析、最適化を可能にします。 取得元 これは通常、Epic Resoluteの請求および請求モジュール内のイベントログ、監査証跡、またはステータス変更レコードから導き出されます。 例 請求情報取得済み支払者へ請求提出済み入金確認済み口座閉鎖 | |||
| イベントのタイムスタンプ EventTimestamp | 特定のアクティビティやイベントが発生した正確な日時。 | ||
| 説明 イベントタイムスタンプは、アクティビティが発生した瞬間を記録します。この時間情報は、収益サイクルにおけるイベントのタイミングと順序を理解する上で非常に重要です。 分析では、タイムスタンプを用いて費用計上遅延や支払い計上時間など、アクティビティ間の期間を算出します。これにより、ボトルネックの特定、サイクルタイムの測定、様々な期間にわたるプロセスパフォーマンスの分析が可能になります。正確なタイムスタンプは、ほぼすべての時間ベースのKPIやダッシュボードに不可欠です。 その重要性 この属性は、遅延と非効率性を特定する上で基礎となる、サイクルタイムや期間を含むすべての時間ベースのメトリクスを計算するために不可欠です。 取得元 Epic Resolute内のトランザクションまたは 例 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）、サービスライン、または部門から導出されます。 例 入院手術外来放射線科緊急サービス | |||
| 担当ユーザー ResponsibleUser | アクティビティを実行したユーザーまたは従業員の識別子。 | ||
| 説明 この属性は、収益サイクルにおける特定のタスクを完了した担当者のユーザーID、氏名、または従業員番号を記録します。これには、費用を入力した臨床医、請求を提出した請求担当者、却下に対応した回収担当者などが含まれます。 ユーザー別に分析することで、優秀な担当者を特定し、トレーニングの必要性を明確にし、作業負荷の配分を理解するのに役立ちます。これは、パフォーマンス管理や、特定の個人または役割に関連するプロセス上の逸脱を調査する上で重要な要素です。 その重要性 個人または役割ごとのパフォーマンス分析を可能にし、研修機会、業務量の不均衡、リソース関連の 取得元 通常、Epic Resolute内の監査証跡または取引ログに見られ、多くの場合、ユーザーマスターデータテーブル（例：EMPレコード）にリンクされています。 例 j.doebsmith123User7890 | |||
| 未収残高 OutstandingBalance | 請求イベントに対する、支払い者または患者からの未収金額。 | ||
| 説明 この属性は、アクティビティ発生時における特定の請求イベントに対する現在の売掛金残高を表します。これは、ケースのライフサイクル全体にわたる財務状況を反映するものです。 未収金残高は、財務報告書や「未収金残高年齢レポート」にとって極めて重要です。この値を時系列で、また支払い者や部門といった異なる切り口で分析することで、回収努力の優先順位付け、キャッシュフロー管理、そして財務リスクの評価に役立てることができます。 その重要性
取得元 これはEpic Resoluteの患者様口座または病院会計（HAR）レコードのコアフィールドです。財務取引によって更新される継続的な残高を示します。 例 1500.00250.750.00 | |||
| 査定拒否理由コード DenialReasonCode | 支払者が提出された請求を拒否した理由を示す標準化されたコードです。 | ||
| 説明 支払い者が請求を却下する際、「非適用サービス」「重複請求」「追加情報が必要」など、却下理由を説明するコードを提供します。これらのコードは、請求調整理由コード（CARCs）として標準化されていることがよくあります。 この属性は、「請求却下率と理由」ダッシュボードの基礎となります。異なる却下コードの発生頻度を分析することで、資格認定の問題、コーディングエラー、事前承認の不足など、却下の根本原因を特定し、ターゲットを絞った改善施策を講じることが可能になります。 その重要性 請求が拒否される理由を直接説明し、拒否率の削減、収益損失の防止、支払いの加速に必要な実用的なインサイトを提供します。 取得元 このデータは、支払い者から受け取った請求応答トランザクション（ANSI 835ファイルなど）に記録され、Epic Resoluteの請求管理モジュール内に保存されています。 例 CO-16: 請求/サービス情報不足OA-18: 重複請求/サービスPR-96: 対象外の請求 | |||
| 経理部門 BillingDepartment | 請求イベントまたはアクティビティを担当する部門または機能チーム。 | ||
| 説明 この属性は、「入院請求」「外来請求」「却下管理チーム」など、請求イベントに関連する、または特定の活動を実行した組織単位を示します。 このディメンションは「請求部門パフォーマンスメトリクス」ダッシュボードにとって非常に重要であり、却下率や費用計上時間といった主要な指標を部門間で比較することを可能にします。これにより、経営陣は優れたパフォーマンスを発揮している部門を特定し、ベストプラクティスを標準化し、リソースを効果的に配分するのに役立ちます。 その重要性 異なる部門間のパフォーマンス 取得元 この情報は、Epic Resolute内のユーザーレコード、患者様の口座、またはサービス提供場所にリンクされている可能性があります。 例 循環器科請求放射線科RCM中央請求`オフィス` | |||
| 調整理由 AdjustmentReason | 患者様の口座残高に対して行われた手動または自動調整の理由。 | ||
| 説明 この属性は、標準的な支払いまたは費用以外で口座残高が変更された理由を説明します。その理由には、支払い者との契約上の許容額、少額残高の償却、計上エラーの修正などが含まれます。 これは「口座調整額タイプ別」ダッシュボードにとって不可欠な要素です。調整理由を分析することで、組織は収益漏洩の発生源を特定し、支払い者契約の影響を理解し、請求プロセスにおける潜在的な非効率性やエラーを発見することができます。 その重要性 口座残高が変更される理由を明確にすることで、収益漏洩と請求の正確性に関する洞察を提供し、不要な償却を削減するのに役立ちます。 取得元 Epic Resoluteの患者会計モジュール内にある、調整項目のトランザクション詳細に記載されています。 例 契約上の許容差額小額残高償却重複請求修正 | |||
| イベントの終了時刻 EventEndTime | アクティビティが完了した時点を示すタイムスタンプ。アクティビティ期間の計算に役立ちます。 | ||
| 説明 この属性はアクティビティの完了時間を記録します。多くの活動は開始時間と終了時間が同じ瞬間的なイベントですが、却下後のフォローアップコールのように、測定可能な期間を持つタスクもあります。 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 | |||
| 処理時間 ProcessingTime | アクティビティにアクティブに費やされた時間の計算された期間。 | ||
| 説明 処理時間とは、アクティビティの開始から終了までの期間を指し、リソースがそのタスクに実際に投入された時間を測るものです。 この数値は「EventEndTime」から「EventTimestamp」を差し引いて算出されます。処理時間を分析することで、特にどのタスクに時間がかかっているかを把握し、効率改善に向けた具体的な施策を講じることが可能になります。これはリソースの生産性を測る上で不可欠な指標です。 その重要性 アクティビティの実際の作業期間を測定し、時間のかかるタスクを特定し、リソースの効率を評価するのに役立ちます。 取得元 これはソースシステム内のフィールドではありません。「EventEndTime - EventTimestamp」という式を用いてデータ変換中に計算されます。 例 900605120 | |||
| 患者ID PatientId | サービスを受けている患者の一意の識別子。 | ||
| 説明 この属性は、患者様の医療記録番号（MRN）またはその他の一意の識別子であり、財務的な請求イベントを特定の個人と関連付けます。 患者様のプライバシー保護のため、通常は主要な分析ディメンションとして使用されませんが、データ検証には不可欠であり、一人の患者様に関する全ての請求イベントを集約して、その患者様全体の財務状況を理解するために使用できます。また、臨床プロセスデータとの将来的な統合にとっても非常に重要です。 その重要性 財務データを特定の患者に関連付け、データの検証や患者ジャーニー全体の広範な分析を可能にします。ただし、プライバシー保護の観点から慎重に取り扱う必要があります。 取得元 Epic全体で共通して使われる基本的な識別子で、患者の登録 例 MRN-1234567MRN-8765432MRN-5551234 | |||
| 支払人名 PayerName | 保険会社、政府機関、またはその他の支払い責任者の名称。 | ||
| 説明 この属性は、請求イベントに関連する主要な支払い者を特定します。例えば、「Blue Cross Blue Shield」「Medicare」「Aetna」などです。自己負担の場合、患者様を示すことがあります。 支払い者別にプロセスをセグメント化することは、強力な分析手法です。これにより、特定の支払い者がより高い却下率、長い支払いサイクル、またはより複雑な要件を持っていることが明らかになる場合があります。この洞察は、効率と支払い速度を向上させるために、特定の支払い者に合わせた請求戦略を調整することを可能にします。 その重要性 支払者ごとのパフォーマンス分析を可能にし、どの支払者が高い査定拒否率や遅い支払い 取得元 この情報は患者様の保険適用詳細の一部であり、Epic Resoluteの病院会計（HAR）にリンクされています。 例 メディケアパートBユナイテッドヘルスケアAetna PPO | |||
| 支払期日 PaymentDueDate | 請求されたサービスの支払いが期待される日付。 | ||
| 説明 この属性は、請求書に記載されているか、支払い者契約によって決定される支払い期限を指定します。これは、タイムリーな支払いを測定するためのベンチマークとして機能します。 支払い期日は、「未収金残高年齢レポート」を作成するために不可欠です。現在の日付と未収金残高の期日を比較することで、売掛金を経過期間バケット（例：0～30日、31～60日延滞など）に分類でき、最も延滞している口座の回収努力を優先するのに役立ちます。 その重要性 売掛金残高分析の基礎となり、回収の優先順位付けや未払い請求書に伴う財務リスク管理にとって不可欠な情報です。 取得元 この日付は、多くの場合、請求書の日付と、支払い者契約またはEpic内の患者口座情報に保存されている支払い条件に基づいて計算されます。 例 2023-05-302023-06-152023-07-01 | |||
| 総収益サイクル時間 TotalRevenueCycleTime | 最初のサービスイベントから最終支払いまたは口座閉鎖までの総計算期間。 | ||
| 説明 これは、単一の請求イベントに対する収益サイクルのエンドツーエンドの期間を測定する、ケースレベルのKPIです。通常、「サービス提供済み」アクティビティと最終的な「支払い受領済み」または「口座閉鎖」アクティビティとの時間差として計算されます。 この高レベルの指標は、RCMプロセス全体の効率性に関する包括的な視点を提供します。このKPIを時系列で追跡することは、プロセス改善の取り組みの影響を測定し、現金化速度の重要な指標となります。 その重要性 プロセスの効率性を包括的にエンドツーエンドで把握し、サービスが現金化されるまでの期間を直接測定できます。 取得元 これは、プロセスマイニングツール内で、各ケースの最初と最後のイベントをフィルタリングし、その時間差を算出することで計算されるメトリクスです。 例 259200038880005184000 | |||
| 自動化 IsAutomated | アクティビティがシステムまたは自動プロセスによって実行されたかどうかを示すブーリアン型のフラグです。 | ||
| 説明 このフラグは、自動的な請求生成や資格確認など、システムによって自動的に実行されるタスクと、ユーザーによって手動で実行されるタスクを区別します。 この属性を分析することで、プロセスにおける自動化のレベルを理解するのに役立ちます。自動化された活動と手動活動の効率性やエラー率を比較したり、さらなる自動化の機会を特定したり、既存のボットやシステムルールのパフォーマンスを監視したりするために使用できます。 その重要性
取得元 これは多くの場合、アクティビティの「ResponsibleUser」がシステムアカウントかサービスアカウントであるかをチェックするか、または自動化されていると認識されている特定のアクティビティ名にフラグを立てることで導き出されます。 例 truefalse | |||
| 調整済み金額 AdjustedAmount | 調整取引の金額。 | ||
| 説明 このフィールドは、口座調整の具体的な金額を記録します。これはプラスまたはマイナスの値で、口座残高への貸方または借方を示します。 この金額は「口座調整額タイプ別」ダッシュボードの主要な指標です。調整理由別にこの値を合計することで、契約上の義務による償却収益額と、修正可能なエラーによる損失額など、異なる種類の調整が財務に与える影響を明確に把握できます。 その重要性 口座調整の財務的影響を定量化することで、収益漏洩や請求の不正確さによるコストを測定することを可能にします。 取得元 Epic Resoluteの財務トランザクション詳細テーブルにあり、調整タイプのトランザクションに関連付けられています。 例 -1250.45-50.0025.10 | |||
| 請求ID ClaimId | 支払い者に提出された医療保険請求に割り当てられた一意の識別子。 | ||
| 説明 この属性は、支払い者に送信された請求フォーム（例：CMS-1500やUB-04）の固有IDです。サービスが再請求または再審査された場合、単一の請求イベントが複数の請求を含む可能性があります。 請求IDによる追跡は、請求提出および却下管理のサブプロセスの詳細な分析に役立ちます。これにより、最初の請求に関連する活動と、同じサービスに対するその後の再提出された請求に関連する活動を区別することができます。 その重要性 個々の保険金請求提出のライフサイクルを追跡するための詳細な識別子を提供し、再提出や再審査の分析に不可欠な情報となります。 取得元 請求が作成された際にEpic Resoluteの請求管理モジュールによって生成されます。データは請求データテーブルに保存されます。 例 CLM-2023-98765CLAIM-0012345623189A4567 | |||
収益サイクル管理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| サービス提供済み | このアクティビティは、臨床サービスが患者様に提供され、それが請求イベントの開始点となる時点を示します。これは多くの場合、臨床医が診察や処置の承認を行った際にEpic EHR (EpicCare)から取得されます。 | ||
| その重要性 これは収益サイクルの主要な開始イベントです。この時点から費用計上までの時間を分析することは、請求開始の遅延や潜在的な収益漏洩を特定するために不可欠です。 取得元 このイベントは通常、請求口座にリンクされている臨床モジュールのサービスまたは診察のタイムスタンプから推測されます。費用取引上のサービス日付が重要なデータポイントとなります。 取得 請求 イベントタイプ inferred | |||
| 入金確認済み | 支払い者または患者からの支払い受領を表します。このイベントは通常、電子送金アドバイス（ERA）が読み込まれた際や、手動での小切手入力時にシステムに記録されます。 | ||
| その重要性 このアクティビティは、収益が間もなく入ることを示す重要なマイルストーンです。請求提出から支払い受領までの期間は、売掛金パフォーマンスの主要な指標となります。 取得元 Resoluteに支払いトランザクションとして明示的に記録されます。これらのトランザクションは、日付、ソース、金額とともに 取得 財務トランザクション イベントタイプ explicit | |||
| 口座へ支払い記帳済み | これは、受領した支払いが患者様の口座の特定の費用に適用または割り当てられるイベントです。このアクションにより、請求イベントの未収金残高が減少します。 | ||
| その重要性 効率的な支払い記帳は、正確な口座残高を維持し、請求 取得元 これはResoluteにおける明確な取引です。支払い計上は、支払い取引を1つ以上の費用取引に紐付け、これは取引詳細テーブルに記録されます。 取得 特定のトランザクションタイプで識別可能な、請求に支払いを適用するトランザクション記録を取得します。 イベントタイプ explicit | |||
| 口座閉鎖 | これは、請求イベントの未収金残高がゼロになり、保留中のアクティビティがなくなったことを示す最終アクティビティです。全額支払い、調整、または償却によって発生する可能性があります。 | ||
| その重要性 このイベントは、請求イベントの収益サイクルが成功裏に完了したことを示します。サービスからクローズまでのエンドツーエンドの期間は、プロセス全体の効率にとって重要なKPIとなります。 取得元 これは通常、推測されるイベントです。請求イベントの口座残高がゼロになり、その後もゼロの状態が続く時点を特定することで判断されます。 取得 口座残高の累積合計を計算し、残高をゼロにした_最終_トランザクションの イベントタイプ inferred | |||
| 支払者による請求拒否 | 支払い者から請求が却下されたという通知の受領を表します。これは、Epicが電子送金アドバイス（835ファイル）を処理した際や、ユーザーが手動で却下を計上した際に記録されます。 | ||
| その重要性 このアクティビティは、重要な手戻りループを開始するものです。却下理由と件数を分析することは、根本原因を特定し、初回支払い率を向上させ、回収遅延を削減するために不可欠です。 取得元 請求に関するトランザクションまたはステータス 取得 特定のトランザクションタイプまたは査定拒否を示す請求ステータス イベントタイプ explicit | |||
| 支払者へ請求提出済み | これは、請求が保険支払い者へ裁定のために正式に送付されるイベントを示します。Epicでは、これは追跡対象イベントとして、電子請求ファイルがクリアリングハウスまたは支払い者に送信されたときにログに記録されます。 | ||
| その重要性 このマイルストーンは、支払い者の支払いタイムラインの開始を意味するため、非常に重要です。これを分析することは、請求伝送プロセスの効率性を測定し、「Invoice to Payer Delivery Time」KPIをサポートするのに役立ちます。 取得元 これはResoluteに記録された明確なイベントです。請求レコードには、提出ステータスと送信された時点を示すタイムスタンプが含まれます。 取得 保険請求ステータスが「提出済み」または「送信済み」に変更された際に、それに関連する イベントタイプ explicit | |||
| 請求情報取得済み | 提供されたサービスに対する請求可能な費用の正式な記録を表します。Epicでは通常、臨床行為から自動的に生成されるか、手動で入力される形で、患者様の口座に計上される明確な取引として処理されます。 | ||
| その重要性 これは重要な最初のマイルストーンです。費用計上の速度と正確性を測定することは、請求プロセスを加速し、提供されたすべてのサービスが請求されることを保証するのに役立ちます。 取得元 Resoluteのトランザクション 取得 システムの財務トランザクションログから、料金計上（チャージポスティング）の取引データを取得します。 イベントタイプ explicit | |||
| 口座調整実行 | このアクティビティは、契約上の調整、少額残高の償却、または善意による割引など、口座残高を変更する非支払い取引を表します。これは特定の取引タイプとして記録されます。 | ||
| その重要性 調整の分析は、収益漏れを特定するための鍵となります。特定の調整タイプが多量に発生している場合、料金表、契約、または内部ポリシーに問題があることを示している可能性があります。 取得元 Resoluteの財務 取得 財務調整または償却に対応するトランザクションタイプでフィルターします。 イベントタイプ explicit | |||
| 査定拒否フォローアップ開始 | このアクティビティは、却下された請求を審査・解決するための内部プロセスの開始を示します。多くの場合、ユーザーがワークキューで却下された請求の担当となり、ステータスを変更した際に記録されます。 | ||
| その重要性 これを追跡することで、却下管理チームの応答性を測定するのに役立ちます。却下とフォローアップ開始の間の遅延は、収益サイクルを不必要に長期化させる可能性があります。 取得元 これは通常、Epicのワークキュー内における請求のステータスや割り当て履歴の変更から推測されます。例えば、請求のステータスが「却下済み」から「審査中」に変わる場合などです。 取得 請求ステータスの変更またはユーザーが査定拒否の処理を開始したことを示す監査 イベントタイプ inferred | |||
| 残高を回収部門へ送付 | これは、未払い口座残高が内部または外部の回収プロセスに転送される時点を示します。多くの場合、口座または請求イベントの明確なステータス変更として記録されます。 | ||
| その重要性 このアクティビティは、未払い残高回収の最終段階を開始するものです。回収プロセスの成功率とサイクルタイムを追跡することは、貸倒れを最小限に抑える上で不可欠です。 取得元 これは通常、明確なイベントとして記録されます。Epicには口座を回収業者に転送する機能があり、その際に口座にログエントリやステータス変更が記録されます。 取得 口座が回収機関に引き渡されたことを示すステータス変更またはトランザクションを特定します。 イベントタイプ explicit | |||
| 請求再提出済み | このイベントは、却下された請求が修正され、支払い者に再送付された後に発生します。これは元の請求に紐づけられた、明確な提出イベントです。 | ||
| その重要性 これは手戻りループの重要な部分です。再提出までの時間と再提出された請求の成功率を測定することは、却下解決プロセスの有効性を理解する上で不可欠です。 取得元 これは最初の提出と同様の明確なイベントですが、多くの場合、再提出としてフラグが立てられます。請求レコードには、新しい提出タイムスタンプが含まれ、再提出コードが含まれる場合があります。 取得 修正または再提出としてフラグ付けされた請求提出の イベントタイプ explicit | |||
| 請求生成済み | このアクティビティは、計上された費用に基づいてシステムが正式な請求書または請求を作成したことを示します。これは、請求が支払い者または患者に送付される前の準備段階です。 | ||
| その重要性 請求生成を追跡することで、費用計上から提出準備までの遅延を特定できます。これは、請求全体の適時性に影響を与える可能性のある重要な内部ステップです。 取得元 これは通常、請求または請求生成バッチジョブが実行された際にログに記録されます。システムは、特定の口座に対する請求ファイル（837ファイルなど）が作成されたときにタイムスタンプを記録します。 取得 請求が イベントタイプ 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）を使用してSQLクエリを構築し、最初に定義されたスコープ内に収まる
HSP_ACCOUNT_ID値のセットを選択します。これは請求イベントの基本母集団として機能します。 - 個別アクティビティクエリの結合: 必要な12のアクティビティそれぞれについて、関連テーブルから
データを取得する個別のSELECTステートメントを記述します。最初のCTEに結合し戻すことで、意図したアカウントのみを分析するようにします。 UNION ALLによるクエリの結合:UNION ALL演算子を使用して、すべての個別アクティビティクエリの結果を単一のまとまったイベントログに結合します。これにより、各クエリの行が垂直方向に積み重ねられます。- 標準
スキーマへのマッピング: 各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などがあります。
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データベースへの読み取り専用認証情報を取得します。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）を使用してSQLクエリを構築し、最初に定義されたスコープ内に収まる
HSP_ACCOUNT_ID値のセットを選択します。これは請求イベントの基本母集団として機能します。 - 個別アクティビティクエリの結合: 必要な12のアクティビティそれぞれについて、関連テーブルから
データを取得する個別のSELECTステートメントを記述します。最初のCTEに結合し戻すことで、意図したアカウントのみを分析するようにします。 UNION ALLによるクエリの結合:UNION ALL演算子を使用して、すべての個別アクティビティクエリの結果を単一のまとまったイベントログに結合します。これにより、各クエリの行が垂直方向に積み重ねられます。- 標準
スキーマへのマッピング: 各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などがあります。
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;