您的收入周期管理数据模板
您的收入周期管理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 数据提取指南
收入周期管理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间戳 EventTimestamp | 特定活动或事件发生的准确日期和时间。 | ||
| 说明 事件时间戳记录活动发生的时刻。此类时间数据对于了解收入周期中各事件的发生时间和先后顺序至关重要。 分析时,时间戳用于计算活动之间的时长,例如费用捕获延迟或收款入账时间。它们有助于发现瓶颈、衡量周期时间并分析不同时段的流程表现。几乎所有基于时间的KPI和仪表板都离不开准确的时间戳。 重要性 此属性对于计算所有基于时间的指标至关重要,包括周期时间和持续时长,这些指标是发现延误和低效问题的基础。 获取途径 可在Epic Resolute的交易表或事件日志表中找到,并与每项已记录活动关联。字段名称通常以Dt、DTTM或Time结尾。 示例 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| 活动名称 ActivityName | 收入周期管理流程中所执行的具体事件或任务的名称。 | ||
| 说明 此属性描述收入周期中的单个步骤,例如“费用已捕获”“索赔已提交给付款方”或“已收到付款”。每项活动都代表服务计费和收款流程中的一个独立里程碑。 活动分析是流程挖掘的基础。它可以呈现流程图、识别常见路径、发现步骤之间的瓶颈,并衡量流程与标准操作规程的一致性。 重要性 定义流程图中的步骤,以便呈现、分析和优化收入周期中的工作流。 获取途径 通常从Epic Resolute计费和索赔模块中的事件日志、审计轨迹或状态变更记录中提取。 示例 费用已捕获索赔已提交给付款方已收到付款账户已结清 | |||
| 计费事件 BillingEvent | 单次服务或产品交付的唯一标识符,该交付会产生费用,也是主要的案例标识符。 | ||
| 说明 计费事件是核心标识符,用于关联特定可计费项目在收入周期中的所有活动。事件从提供服务时开始,到账户全部结清或关闭时结束。 在流程挖掘分析中,此属性对于还原每笔费用的端到端处理过程至关重要。它可以跟踪单个计费事件中的费用捕获、索赔提交、收款入账和拒付管理等活动,清晰呈现流程及其差异。 重要性 这是基本的案例ID,对于关联所有相关流程步骤至关重要,可用于分析每项服务产生收入和收款的完整周期。 获取途径 这通常是Epic Resolute中医院账户(HAR)或特定费用会话的唯一标识符。有关HAR或费用会话记录等具体表的信息,请查阅Epic Resolute文档。 示例 BE10098765BE20012345BE30054321 | |||
| 拒付原因代码 DenialReasonCode | 用于说明付款方拒付已提交索赔原因的标准化代码。 | ||
| 说明 付款方拒绝索赔时,会提供原因代码说明拒付原因,例如“服务不在承保范围内”“重复索赔”或“需要补充信息”。这些代码通常采用标准化的索赔调整原因代码(CARC)。 此属性是“索赔拒付率及原因”仪表板的核心。分析不同拒付代码的出现频率,有助于找出拒付的根本原因,例如资质认证问题、编码错误或缺少预先授权,从而制定有针对性的改进措施。 重要性 直接说明索赔被拒的原因,为降低拒付率、防止收入损失和加快付款提供可执行的洞察。 获取途径 此数据可在付款方返回的索赔响应交易(例如ANSI 835文件)中找到,并存储在Epic Resolute的索赔管理模块中。 示例 CO-16:索赔或服务信息不完整OA-18:重复索赔或服务PR-96:不在承保范围内的费用 | |||
| 服务类型 ServiceType | 所提供医疗服务的类别或类型。 | ||
| 说明 此属性用于对可计费服务进行分类,例如“放射科”“手术”“会诊”或“急诊就诊”,为财务数据提供临床背景。 按服务类型分析收入周期,有助于发现特定临床领域的流程差异。例如,与常规门诊相比,手术可能涉及更复杂的费用记录和授权要求,因此流程表现和面临的挑战也有所不同。 重要性 为财务数据提供临床背景,便于分析不同类型的医疗服务如何影响收入周期流程及其效率。 获取途径 此信息源自Epic中与费用交易关联的费用描述主文件(CDM)、服务线或科室。 示例 住院手术门诊放射科急诊服务 | |||
| 未结余额 OutstandingBalance | 付款方或患者针对该计费事件尚未支付的金额。 | ||
| 说明 此属性表示活动发生时特定计费事件的当前应收账款余额,反映案例在整个周期中的财务状态。 未结余额对于财务报告和“未结余额账龄报告”至关重要。按时间以及付款方、部门等不同维度分析此数值,有助于确定催收工作的优先级、管理现金流并评估财务风险。 重要性 直接衡量流程延误带来的财务影响,对于确定催收优先级、管理现金流和了解应收账款至关重要。 获取途径 这是Epic Resolute患者账户或医院账户(HAR)记录中的核心字段。它是一个会随财务交易更新的累计余额。 示例 1500.00250.750.00 | |||
| 计费部门 BillingDepartment | 负责计费事件或相关活动的部门或职能团队。 | ||
| 说明 此属性表示与计费事件相关或执行特定活动的组织单位,例如“住院计费”“门诊计费”或“拒付管理团队”。 此维度对于“计费部门绩效指标”仪表板至关重要,可并列比较拒付率、费用捕获时间等关键指标。管理人员可据此识别表现出色的部门、推广最佳实践并有效分配资源。 重要性 支持跨部门绩效对标,帮助识别最佳实践,以及需要改进或增加资源的领域。 获取途径 此信息可能关联到Epic Resolute中的用户记录、患者账户或服务地点。 示例 心脏科计费放射科收入周期管理中央计费办公室 | |||
| 调整原因 AdjustmentReason | 对患者账户余额进行人工或自动调整的原因。 | ||
| 说明 此属性说明账户余额为何因标准付款或费用以外的原因发生变化。原因可能包括付款方合同折让、小额余额核销或更正入账错误。 此属性对于“按类型统计账户调整量”仪表板至关重要。分析调整原因有助于组织发现收入流失来源、了解付款方合同的影响,并识别计费流程中潜在的低效或错误。 重要性 说明账户余额变动的原因,帮助了解收入流失和计费准确性,并减少不必要的核销。 获取途径 可在Epic Resolute患者账务模块中调整条目的交易明细里找到。 示例 合同折让小额余额核销重复费用更正 | |||
| 负责人 ResponsibleUser | 执行该活动的用户或员工标识符。 | ||
| 说明 此属性记录负责完成收入周期中特定任务的人员的用户ID、姓名或员工编号。例如,录入费用的临床人员、提交索赔的计费人员,或跟进拒付的催收人员。 按用户分析有助于识别表现突出的人员、发现培训需求并了解工作量分布。这对于绩效管理,以及调查与特定人员或角色相关的流程偏差都很重要。 重要性 支持按个人或角色分析表现,帮助发现培训机会、工作量失衡和资源相关瓶颈。 获取途径 通常可在Epic Resolute的审计轨迹或交易日志中找到,并关联到用户主数据表(例如EMP记录)。 示例 j.doebsmith123User7890 | |||
| 上次数据更新 LastDataUpdate | 表示此事件数据上次从源系统刷新或提取时间的时间戳。 | ||
| 说明 此属性用于显示数据的新鲜度,即记录上次从Epic Resolute提取并载入流程挖掘数据集的时间。 了解数据时效性并验证数据时,此属性十分重要。它有助于用户确认当前查看的信息是否为最新可用数据,也是管理数据刷新周期的关键依据。 重要性 帮助用户了解所分析数据的时效性,这对于做出准确、及时的业务决策至关重要。 获取途径 此时间戳由数据载入过程中的ETL(提取、转换、加载)流程添加。 示例 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| 事件结束时间 EventEndTime | 表示活动完成时间的时间戳,可用于计算活动时长。 | ||
| 说明 此属性记录活动的完成时间。许多活动是瞬时事件,开始时间与结束时间相同;但有些任务具有可测量的持续时间,例如跟进拒赔的电话。 如果有结束时间,就可以直接计算活动处理时间(“EndTime”减去“StartTime”)。与根据下一活动的开始时间推算时长相比,这种方法更准确,因为它能反映步骤之间的空闲时间。结束时间也是计算“ProcessingTime”属性的重要组成部分。 重要性 可精确计算每项活动的完成时长,对发现低效任务和衡量资源生产效率至关重要。 获取途径 部分Epic Resolute模块可能会记录任务的开始和结束时间,例如工作队列或活动管理日志。但通常不会明确记录此信息。 示例 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| 付款到期日 PaymentDueDate | 账单所列服务的预期付款截止日期。 | ||
| 说明 此属性指定付款截止日期,依据账单所列日期或付款方合同确定,可作为衡量付款是否及时的基准。 付款到期日是生成“未结余额账龄报告”的重要依据。将未结余额的到期日与当前日期进行比较,可按账龄区间对应收账款分类,例如逾期0至30天、31至60天,从而优先跟进逾期时间最长的账户。 重要性 作为应收账款账龄分析的依据,对优先安排催收和管理未付款项的财务风险至关重要。 获取途径 此日期通常根据Epic中付款方合同或患者账户信息所记录的账单日期和付款条款计算得出。 示例 2023-05-302023-06-152023-07-01 | |||
| 付款方名称 PayerName | 负责付款的保险公司、政府机构或其他方的名称。 | ||
| 说明 此属性用于标识与计费事件关联的主要付款方,例如“Blue Cross Blue Shield”“Medicare”或“Aetna”。如果由患者自费,则可能显示患者信息。 按付款方细分流程是一种有效的分析方法,可以发现某些付款方是否拒付率更高、付款周期更长或要求更复杂。根据这些洞察调整针对不同付款方的计费策略,有助于提高效率并加快付款。 重要性 支持按付款方分析表现,发现拒付率高或付款周期长的付款方,从而制定有针对性的跟进策略。 获取途径 此信息属于患者的承保详情,并关联到Epic Resolute中的医院账户(HAR)。 示例 Medicare B部分UnitedHealthcareAetna PPO | |||
| 患者ID PatientId | 接受服务的患者的唯一标识符。 | ||
| 说明 此属性是患者的病历号(MRN)或其他唯一标识符,用于将财务计费事件关联到具体患者。 为保护患者隐私,此属性通常不作为主要分析维度,但对数据验证至关重要;也可用于汇总单个患者的所有计费事件,了解其整体财务历程。此外,它对于与临床流程数据进行潜在集成也很重要。 重要性 将财务数据关联到具体患者,便于验证数据,并为分析患者的完整历程提供可能;但由于涉及隐私,必须谨慎处理。 获取途径 这是Epic中广泛使用的基础标识符,与患者登记和账户记录相关联。 示例 MRN-1234567MRN-8765432MRN-5551234 | |||
| 收入周期总时长 TotalRevenueCycleTime | 从首次服务事件到最终付款或账户关闭的总时长。 | ||
| 说明 这是一个案例级KPI,用于衡量单次计费事件的收入周期端到端时长。通常以“已提供服务”活动与最终的“已收到付款”或“账户已关闭”活动之间的时间差计算。 这一高层指标全面反映收入周期管理(RCM)流程的整体效率。持续跟踪该KPI,有助于衡量流程改进举措的成效,也是评估现金回收速度的重要指标。 重要性 从整体和端到端角度反映流程效率,直接衡量服务转化为现金所需的时间。 获取途径 此指标由流程挖掘工具计算:筛选每个案例的首个和最后一个事件,并计算两者之间的时间差。 示例 259200038880005184000 | |||
| 是否自动执行 IsAutomated | 用于标记活动是否由系统或自动化流程执行的布尔值。 | ||
| 说明 此标记用于区分系统自动执行的任务(例如自动生成索赔或资格核验)与用户手动执行的任务。 分析此属性有助于了解流程的自动化程度。您可以比较自动化活动与手动活动的效率和错误率,发现进一步自动化的机会,并监控现有机器人或系统规则的表现。 重要性 区分系统执行与人工执行的活动,是评估自动化影响和发现新自动化机会的关键。 获取途径 通常可通过检查活动的“ResponsibleUser”是否为系统或服务账户来推断,也可根据已知为自动化的特定活动名称进行标记。 示例 truefalse | |||
| 源系统 SourceSystem | 数据来源的信息系统。 | ||
| 说明 此属性用于标识记录的源系统,在此场景中为Epic Resolute。在集成多个系统的环境中,该字段有助于区分数据来源。 在仅涉及单一系统时,这一字段看似多余,但它符合数据治理和可扩展性的最佳实践。如果之后集成其他系统的数据,例如独立催收平台的数据,该字段便可确保来源清晰。 重要性 提供关键的数据沿袭信息和背景,明确数据来源,这对于数据治理和问题排查至关重要。 获取途径 通常在数据提取和转换过程中添加固定值,用于标记数据集的来源。 示例 Epic ResoluteEpicResolute_V2023 | |||
| 索赔ID ClaimId | 提交给付款方的保险索赔所分配的唯一标识符。 | ||
| 说明 此属性是发送给付款方的索赔表单(例如CMS-1500或UB-04)的专属ID。如果服务需要重新计费或提出申诉,一次计费事件可能涉及多项索赔。 按索赔ID跟踪,有助于详细分析索赔提交和拒赔管理子流程。它可以区分与首次索赔相关的活动,以及同一服务后续重新提交的索赔活动。 重要性 为每项索赔提交提供细粒度标识,便于跟踪其完整生命周期,对分析重新提交和申诉至关重要。 获取途径 Epic Resolute的索赔管理模块在创建索赔时生成此ID,并将其存储在索赔数据表中。 示例 CLM-2023-98765CLAIM-0012345623189A4567 | |||
| 调整金额 AdjustedAmount | 调整交易的金额。 | ||
| 说明 此字段记录账户调整的具体金额,可为正数或负数,分别表示账户余额增加或减少。 此金额是“按类型统计账户调整金额”仪表板的主要指标。按调整原因汇总该金额,可以清楚了解不同类型调整的财务影响,例如因合同义务而核销的收入,以及因可纠正错误而损失的收入。 重要性 量化账户调整的财务影响,从而衡量收入流失和账单错误造成的成本。 获取途径 此数据位于Epic Resolute的财务交易明细表中,与调整类型的交易相关联。 示例 -1250.45-50.0025.10 | |||
收入周期管理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 付款已记入账户 | 此事件表示已收到的款项已应用或分配至患者账户中的特定费用,从而减少该计费事件的未结余额。 | ||
| 重要性 高效的收款入账对于保持账户余额准确并结清计费事件至关重要,也有助于准确识别剩余余额,以便进行二次计费或催收。 获取途径 这是Resolute中的明确交易。收款入账会将付款交易关联到一笔或多笔费用交易,并记录在交易明细表中。 采集 提取将付款应用于费用的交易记录,可通过特定交易类型识别。 事件类型 explicit | |||
| 付款方已拒付索赔 | 表示收到付款方发出的索赔拒付通知。Epic处理电子汇款通知(835文件)或用户手动登记拒付时,系统会记录此事件。 | ||
| 重要性 此活动会启动关键的返工循环。分析拒付原因和数量,对于找出根本原因、提高首次付款率并减少收款延误至关重要。 获取途径 此事件会作为交易或索赔状态更新明确记录。拒付信息(包括原因代码)通常以电子方式接收并记入账户。 采集 筛选表示拒付的特定交易类型或索赔状态更新。 事件类型 explicit | |||
| 已收到付款 | 表示收到付款方或患者的付款。通常在系统载入电子汇款通知(ERA)或录入手工支票时记录此事件。 | ||
| 重要性 此活动是收入到账的重要里程碑。从索赔提交到收到付款的时间,是衡量应收账款表现的关键指标。 获取途径 Resolute中会明确记录为付款交易。这些交易包含日期、来源和金额,通常在款项完全分配至各笔费用之前记录。 采集 从财务交易日志中提取付款交易,通常可通过特定交易类型识别。 事件类型 explicit | |||
| 服务已提供 | 此活动表示已向患者提供临床服务,并由此触发计费事件。通常可从Epic EHR(EpicCare)中获取,例如临床人员签署就诊或操作记录时。 | ||
| 重要性 这是收入周期的主要开始事件。分析从此时到费用捕获所需的时间,对于发现计费启动延误和潜在收入流失至关重要。 获取途径 通常根据临床模块中与计费账户关联的服务或就诊时间戳推断此事件。费用交易中的服务日期是关键数据点。 采集 根据计费事件首笔费用交易对应的服务日期推断。 事件类型 inferred | |||
| 索赔已提交给付款方 | 此事件表示索赔已正式发送给保险付款方进行审核。在Epic中,此事件会被跟踪,并在电子索赔文件传输至清算所或付款方时记录。 | ||
| 重要性 这一里程碑至关重要,因为它标志着付款方付款周期的开始。分析此环节有助于衡量索赔传输效率,并支持“发票发送至付款方所需时间”KPI的计算。 获取途径 Resolute中会明确记录此事件。索赔记录包含提交状态和发送时间戳。 采集 提取索赔状态变为“已提交”或“已传输”时对应的时间戳。 事件类型 explicit | |||
| 账户已结清 | 这是最后一项活动,表示计费事件的未结余额已归零,且没有待处理活动。余额归零可能是由于全额付款、调整或核销。 | ||
| 重要性 此事件标志着计费事件的收入周期已成功完成。从服务提供到结清的端到端时长,是衡量整体流程效率的关键KPI。 获取途径 此事件通常通过推断确定,即识别计费事件账户余额归零并保持为零的时间点。 采集 通过计算账户余额的累计值,找出使余额归零的最后一笔交易的时间戳来推断。 事件类型 inferred | |||
| 费用已捕获 | 表示正式记录已提供服务的应计费用。在Epic中,这通常是记入患者账户的明确交易,可能由临床操作自动生成,也可能由人工录入。 | ||
| 重要性 这是首个关键里程碑。衡量费用捕获的速度和准确性,有助于加快计费流程并确保所有已提供的服务均完成计费。 获取途径 在Resolute的交易日志中有明确记录。每笔费用都是独立条目,包含入账日期、服务日期和金额,通常可在ARPB_TRANSACTIONS等表中找到。 采集 从系统财务交易日志中提取费用入账交易。 事件类型 explicit | |||
| 余额已转交催收 | 此事件表示未付款账户余额已转入内部或外部催收流程。通常会明确记录为账户或计费事件的状态变更。 | ||
| 重要性 此活动标志着未付款余额回收的最后阶段开始。跟踪催收流程的成功率和周期时间,对于减少坏账至关重要。 获取途径 这通常是一个明确事件。Epic提供将账户转交给催收机构的功能,并会在账户上生成日志条目或状态变更。 采集 查找表明账户已交由催收机构处理的状态变更或交易。 事件类型 explicit | |||
| 已启动拒付跟进 | 此活动表示内部审核并解决被拒索赔的流程开始。通常在用户通过工作队列接手被拒索赔或更改其状态时记录。 | ||
| 重要性 跟踪此活动有助于衡量拒付管理团队的响应速度。拒付发生后迟迟未开始跟进,会不必要地延长收入周期。 获取途径 通常根据Epic工作队列中的索赔状态或分配历史变化推断。例如,索赔状态可能从“已拒付”变为“审核中”。 采集 根据索赔状态变化或审计日志推断;日志应显示用户已开始处理拒付。 事件类型 inferred | |||
| 索赔已生成 | 此活动表示系统根据已捕获的费用创建正式索赔或发票,是将索赔发送给付款方或患者之前的准备步骤。 | ||
| 重要性 跟踪索赔生成情况,有助于找出费用捕获与提交准备之间的延误。这是影响整体计费时效的关键内部步骤。 获取途径 通常在计费或索赔生成批处理作业运行时记录此事件。系统会记录为某个账户创建索赔文件(例如837文件)的时间戳。 采集 查找表明索赔已汇总并准备提交的日志条目或状态变更。 事件类型 explicit | |||
| 索赔已重新提交 | 被拒索赔更正后重新发送给付款方时,会发生此事件。这是与原始索赔关联的一次独立提交。 | ||
| 重要性 这是返工循环中的关键环节。衡量重新提交所需时间及重新提交索赔的成功率,对于了解拒付处理成效至关重要。 获取途径 这是与首次提交类似的明确事件,但通常会标记为重新提交。索赔记录会显示新的提交时间戳,也可能包含重新提交代码。 采集 提取标记为更正或重新提交的索赔提交时间戳。 事件类型 explicit | |||
| 账户已调整 | 此活动表示非付款类交易导致账户余额发生变化,例如合同调整、小额余额核销或善意折扣。系统会将其记录为特定交易类型。 | ||
| 重要性 分析调整情况是发现收入流失的关键。某些调整类型数量过多,可能表明费率表、合同或内部政策存在问题。 获取途径 Resolute财务日志中会明确记录调整交易。每笔调整都关联特定类型或原因代码。 采集 筛选对应财务调整或核销的交易类型。 事件类型 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语句中,为列设置别名,使其符合ProcessMind的标准架构,例如BillingEvent、ActivityName、EventTimestamp和ResponsibleUser等。对于不适用于特定活动的属性,使用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]定义提取时段。初次建议选择三至六个月,验证查询性能和事件完整性后再延长时段。
- 确定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中的时间顺序、重复记录情况、空值比例、活动数量,以及与源系统报表的对账结果。对于超出所选时段但有助于理解时段开始前已启动或结束后才完成的案例的事件,也应进行核查。
- 将结果导出为ProcessMind支持的分隔文件或数据库连接。每个事件占一行,列名保持稳定,时间戳格式一致,采用UTF-8编码,不使用合并单元格或汇总行。上传时,将BillingEvent设为案例标识符,ActivityName设为活动,EventTimestamp设为事件时间戳。
配置
- **源映射:**Epic Clarity的实施方式各不相同。请将每个方括号中的源对象和列占位符替换为您所在环境中有文档记录的表、视图或已批准的报表层。不要仅因某个表或字段在其他Epic实施环境中很常见,就假定它在您的环境中存在。
- **案例标识符:**默认查询映射使用HSP_ACCOUNT.HSP_ACCOUNT_ID。请确认贵组织将BillingEvent定义为账户、就诊、索赔、收费项目还是其他已批准的业务键。
- **日期范围:**建议从三到六个月开始。如果案例可能在报表窗口开始前启动,请加入回溯期;如果索赔、拒付、付款或结案可能发生在服务日期之后,请加入后续观察期。
- **活动时间戳:**为每项活动配置一个权威时间戳。除非文档明确说明它就是源系统记录的实际业务事件时间,否则不要用提取时间、文件加载时间或当前状态时间替代实际业务事件时间。
- **筛选条件:**仅当定义有文档记录且分析确有需要时,才应用[公司代码筛选条件]、[单据类型筛选条件]、[科室筛选条件]、付款方、服务区域和账户类别筛选条件。所有UNION ALL分支中的筛选条件应保持一致。
- **交易和状态映射:**请配置贵组织批准的收费入账、索赔创建、索赔提交、拒付、跟进、重新提交、收款、付款入账、调整、催收和结案值。由于Epic交易值和源数据结构因实施环境而异,查询中有意保留了占位符。
- **空值处理:**对于不适用于某项活动的属性,请保留NULL。不要为缺失的拒付原因、调整原因、用户、科室或服务类型编造替代值。
- **性能:**在连接HSP_ACCOUNT之前,使用带索引的日期列和已批准的组织筛选条件限制源数据行数。避免在筛选条件中对带索引的时间戳列应用函数。如果原始历史数据量较大,可考虑将各项源活动物化到已批准的报表视图中。
- **去重:**没有明确记录的规则时,不要删除重复事件。同一个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%。
无需信用卡,立即开始优化。