您的收入周期管理数据模板
您的收入周期管理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 提取指南
收入周期管理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间戳 EventTimestamp | 特定活动或事件发生的准确日期和时间。 | ||
| 说明 Event Timestamp记录活动发生的时间点。这些时间数据对于了解收入循环中事件的时序和先后关系至关重要。 在分析中,时间戳用于计算活动之间的时长,例如费用采集延迟或付款过账时间。它们支持发现瓶颈、衡量周期时间,以及分析不同时段的流程绩效。准确的时间戳几乎是所有基于时间的KPI和仪表板的基础。 为什么重要 该属性对于计算所有基于时间的指标至关重要,包括周期时间和持续时长,这些指标是识别延迟与低效的基础。 获取位置 位于Epic Resolute的交易表或事件日志表中,并与每项已记录活动相关联。字段名称通常带有Dt、DTTM或Time等后缀。 示例 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| 活动名称 ActivityName | 收入循环管理流程中所执行特定事件或任务的名称。 | ||
| 说明 该属性描述收入循环中的单个步骤,例如“费用已采集”“索赔已提交至付款方”或“已收到付款”。每项活动都代表服务计费和收款流程中的一个独立里程碑。 活动分析是流程挖掘的基础。它支持可视化流程图、识别常见路径、发现步骤之间的瓶颈,以及衡量流程对标准操作规程的遵循程度。 为什么重要 定义流程图中的步骤,从而实现对收入循环工作流的可视化、分析和优化。 获取位置 通常来源于Epic Resolute计费和索赔模块中的事件日志、审计轨迹或状态变更记录。 示例 已捕获费用已向付款方提交索赔收到付款账户已关闭 | |||
| 计费事件 BillingEvent | 单次服务或产品交付的唯一标识符。该服务或交付会产生费用,并作为主要案例标识符。 | ||
| 说明 Billing Event是连接特定可计费项目在收入周期内所有活动的核心标识符。它始于服务提供完成,终于账户结清或关闭。 在流程挖掘分析中,该属性对于重构每项费用的端到端流程至关重要。它支持跟踪单个Billing Event中的费用捕获、索赔提交、付款过账和拒赔管理等活动,清晰呈现流程顺序及其变体。 为什么重要 这是基础Case ID,对于关联所有相关流程步骤、分析每项服务收入生成与回收的完整生命周期至关重要。 获取位置 这通常是医院账户(HAR)或Epic Resolute中特定费用会话的唯一标识符。有关HAR或Charge Session记录等具体表,请参阅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 | |||
| 事件结束时间 EventEndTime | 表示活动完成时间的时间戳,可用于计算活动持续时长。 | ||
| 说明 该属性记录活动完成时间。许多活动是瞬时事件,StartTime等于EndTime,但部分任务具有可衡量的持续时长,例如拒付跟进电话。 在可用时,EndTime支持直接计算活动处理时间(“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 | |||
| 最后数据更新时间 LastDataUpdate | 表示该事件数据最近一次从源系统刷新或提取时间的时间戳。 | ||
| 说明 该属性反映数据的新鲜度,表示记录最近一次从Epic Resolute导入流程挖掘数据集的时间。 这对于了解分析的时效性和开展数据验证非常重要。它帮助用户确认当前查看的是否为最新可用信息,也是管理数据刷新周期的关键依据。 为什么重要 确保用户了解所分析数据的时效性,这对于制定准确、及时的业务决策至关重要。 获取位置 该时间戳由ETL(提取、转换、加载)流程在数据摄取期间添加。 示例 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| 患者ID PatientId | 接受服务患者的唯一标识符。 | ||
| 说明 该属性是患者的病历号(MRN)或其他唯一标识符,用于将财务计费事件关联到具体个人。 为保护患者隐私,它通常不作为主要分析维度,但对于数据验证至关重要,也可用于汇总单个患者的所有计费事件,了解其整体财务历程。它对于未来与临床流程数据集成同样重要。 为什么重要 将财务数据关联到具体患者,支持数据验证以及对患者完整历程进行更广泛分析,但由于涉及隐私,必须谨慎处理。 获取位置 这是Epic中广泛使用的基础标识符,与患者登记记录和账户记录相关联。 示例 MRN-1234567MRN-8765432MRN-5551234 | |||
| 收入循环总周期时间 TotalRevenueCycleTime | 从首次服务事件到最终付款或账户关闭的总计算时长。 | ||
| 说明 这是案例级KPI,用于衡量单个计费事件收入循环的端到端时长。通常计算“Service Rendered”活动与最终“Payment Received”或“Account Closed”活动之间的时间差。 这一高层指标全面反映RCM流程的整体效率。持续跟踪该KPI有助于衡量流程改进措施的影响,并作为现金转换速度的重要指标。 为什么重要 从高层次提供流程效率的端到端视图,直接衡量将服务转化为现金所需的时间。 获取位置 这是在流程挖掘工具中计算的指标,通过筛选每个案例的首个和最后一个事件并计算时间差得出。 示例 259200038880005184000 | |||
| 是否自动执行 IsAutomated | 用于表示活动是否由系统或自动化流程执行的布尔标记。 | ||
| 说明 该标记用于区分系统自动执行的任务,例如自动生成索赔或资格检查,与用户手动执行的任务。 分析该属性有助于了解流程自动化程度。它可用于比较自动化活动与人工活动的效率和错误率,识别进一步自动化的机会,并监控现有机器人或系统规则的绩效。 为什么重要 区分系统驱动和人工驱动的活动,对于评估自动化影响和识别新的自动化机会至关重要。 获取位置 通常通过检查活动的“ResponsibleUser”是否为系统账户或服务账户,或标记已知由自动化执行的特定活动名称来推导。 示例 truefalse | |||
| 源系统 SourceSystem | 数据来源的信息系统。 | ||
| 说明 该属性标识记录的源系统,在此场景中为Epic Resolute。在包含多个集成系统的环境中,该字段有助于区分数据来源。 在单系统视图中它可能显得多余,但这是数据治理和扩展性的最佳实践。如果未来集成其他系统的数据,例如独立的催收机构平台,该字段可确保来源清晰。 为什么重要 提供关键的数据血缘和上下文信息,明确数据来源,对于数据治理和问题排查至关重要。 获取位置 通常是在数据提取和转换过程中添加的静态值,用于标记数据集来源。 示例 Epic ResoluteEpicResolute_V2023 | |||
| 索赔ID ClaimId | 提交给付款方的保险索赔唯一标识符。 | ||
| 说明 该属性是发送给付款方的索赔表单的具体ID,例如CMS-1500或UB-04。同一计费事件可能包含多笔索赔,例如重新计费或提出申诉时。 按Claim ID跟踪有助于详细分析索赔提交和拒付管理子流程,也能区分初始索赔活动与同一服务后续重新提交索赔的相关活动。 为什么重要 提供跟踪每笔具体索赔提交生命周期的细粒度标识符,对于分析重新提交和申诉至关重要。 获取位置 索赔创建时由Epic Resolute的索赔管理模块生成,并存储在索赔数据表中。 示例 CLM-2023-98765CLAIM-0012345623189A4567 | |||
| 调整金额 AdjustedAmount | 调整交易的金额。 | ||
| 说明 该字段记录账户调整的具体金额,可以为正数或负数,分别表示账户余额的贷记或借记。 该金额是“按类型统计账户调整量”仪表板的主要指标。按调整原因汇总该值,可以清晰呈现不同调整类型的财务影响,例如因合同义务核销的收入金额,以及因可纠正错误造成的损失金额。 为什么重要 量化账户调整的财务影响,从而衡量收入流失和计费错误成本。 获取位置 位于Epic Resolute的财务交易明细表中,并与调整类交易相关联。 示例 -1250.45-50.0025.10 | |||
收入周期管理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 付款已过账到账户 | 这是将已收到的付款应用或分配到患者账户特定费用的事件。该操作会减少计费事件的未结余额。 | ||
| 为什么重要 高效的付款过账对于保持账户余额准确并完成计费事件至关重要,也有助于准确识别需要二次计费或催收的剩余余额。 获取位置 这是Resolute中的明确交易。付款过账会将一笔付款交易关联到一笔或多笔费用交易,并记录在交易明细表中。 采集 提取将付款应用到费用的交易记录,可依据特定交易类型进行识别。 事件类型 explicit | |||
| 已向付款方提交索赔 | 标志着索赔正式发送给保险付款方进行审核。在Epic中,这是一个可跟踪事件,电子索赔文件传输至清算所或付款方时会被记录。 | ||
| 为什么重要 这是一个关键里程碑,付款方的付款周期从此开始计时。分析该节点有助于衡量索赔传输流程的效率,并支持Invoice to Payer Delivery Time KPI。 获取位置 这是Resolute中明确记录的事件。索赔记录会包含提交状态和发送时间戳。 采集 获取索赔状态变更为“Submitted”或“Transmitted”时对应的时间戳。 事件类型 explicit | |||
| 已捕获费用 | 表示正式记录已提供服务对应的可计费费用。在Epic中,这通常是记入患者账户的明确交易,可能由临床操作自动生成,也可能由人工录入。 | ||
| 为什么重要 这是第一个关键里程碑。衡量费用捕获的速度和准确性,有助于加快计费流程,并确保所有已提供服务都完成计费。 获取位置 该活动会明确记录在Resolute的交易日志中。每笔费用都是一条独立记录,包含过账日期、服务日期和金额,通常可在ARPB_TRANSACTIONS等表中找到。 采集 从系统财务交易日志中获取费用过账交易。 事件类型 explicit | |||
| 收到付款 | 表示收到付款方或患者的付款。通常在电子汇款通知(ERA)加载完成,或人工将支票录入系统时记录该事件。 | ||
| 为什么重要 该活动是表明收入即将到账的重要里程碑。从索赔提交到收到付款之间的时间,是衡量应收账款绩效的关键指标。 获取位置 在Resolute中明确记录为付款交易。这些交易会记录日期、来源和金额,通常早于付款完全过账到各项费用。 采集 从财务交易日志中提取付款交易,通常依据特定交易类型进行识别。 事件类型 explicit | |||
| 服务已提供 | 该活动标志着临床服务已提供给患者,并由此启动计费事件。通常,当临床医生在Epic EHR(EpicCare)中完成就诊或操作签署后,系统会记录这一活动。 | ||
| 为什么重要 这是收入周期的主要开始事件。分析从该节点到费用捕获所需的时间,对于识别计费启动延迟和潜在收入流失至关重要。 获取位置 该事件通常根据与计费账户关联的临床模块中的服务或就诊时间戳推断得出。费用交易中的服务日期是关键数据点。 采集 根据计费事件对应的第一笔费用交易的服务日期推断得出。 事件类型 inferred | |||
| 索赔被付款方拒付 | 表示收到付款方发出的索赔拒付通知。当Epic处理电子汇款建议(835文件)或用户手动登记拒付时,系统会记录该活动。 | ||
| 为什么重要 该活动会启动关键的返工循环。分析拒付原因和数量,对于识别根本原因、提升首次提交付款率和减少回收延迟至关重要。 获取位置 该活动会作为索赔上的交易或状态更新明确记录。拒付信息(包括原因代码)通常以电子方式接收,并记入账户。 采集 筛选表明索赔拒付的特定交易类型或索赔状态更新。 事件类型 explicit | |||
| 账户已关闭 | 这是最终活动,表示计费事件的未结余额已归零,且没有其他待处理活动。其原因可能是全额付款、调整或核销。 | ||
| 为什么重要 该事件标志着某项计费事件的收入循环已成功完成。从服务提供到关闭的端到端时长,是衡量整体流程效率的关键KPI。 获取位置 这通常是一个推断事件。通过识别计费事件账户余额变为零并持续为零的时间点确定。 采集 通过计算账户余额的累计总额,识别使余额归零的最后一笔交易的时间戳来推断。 事件类型 inferred | |||
| 余额已转入催收 | 标志着未付款账户余额被转入内部或外部催收流程。通常表现为账户或计费事件的明确状态变更。 | ||
| 为什么重要 该活动启动了追回未付款余额的最后阶段。跟踪催收流程的成功率和周期时间,对于减少坏账至关重要。 获取位置 这通常是一个明确事件。Epic提供将账户转交催收机构的功能,并在账户上生成日志条目或状态变更。 采集 识别表明账户已交由催收机构处理的状态变更或交易。 事件类型 explicit | |||
| 已启动拒付跟进 | 该活动标志着内部审核和解决拒付索赔流程的开始。通常,当用户在工作队列中接管拒付索赔或更改其状态时,系统会记录该活动。 | ||
| 为什么重要 跟踪该活动有助于衡量拒付管理团队的响应速度。拒付发生到开始跟进之间的延迟,可能不必要地延长收入周期。 获取位置 通常根据Epic工作队列中的索赔状态或分配历史变更推断得出。例如,索赔状态可能从“Denied”变更为“In Review”。 采集 根据索赔状态变更,或显示用户已开始处理拒付的审计日志记录进行推断。 事件类型 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聚焦住院或门诊计费。
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]定义提取周期。初始使用三到六个月的周期,只有在验证查询性能和事件完整性后再延长周期。
- 建立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客户端或报表平台中执行查询。确认全部十二个活动标签均以明确的行返回。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定义为账户、就诊、索赔、费用或其他获批准的业务键。
- 日期范围:先使用3至6个月。若案例可能早于报告窗口开始,请加入回溯期;若索赔、拒付、付款或结案可能发生在服务日期之后,请加入后续观察期。
- 活动时间戳:为每项活动配置一个权威时间戳。除非提取时间、文件加载时间或当前状态时间就是有文档记录的源系统事件时间戳,否则不要用它们替代实际业务事件时间。
- 筛选条件:仅在定义有文档记录且分析确有需要时,应用[Company Code filter]、[Document Type filter]、[Department filter]、付款方、服务区域和账户类别筛选条件。所有UNION ALL分支必须使用一致的筛选条件。
- 交易和状态映射:配置组织批准的费用过账、索赔创建、索赔提交、拒付、跟进、重新提交、收款、付款过账、调整、催收和结案值。由于Epic的交易值和源结构因实现而异,查询特意使用占位符。
- 空值处理:对于不适用于某项活动的属性,保留NULL。不要为缺失的拒付原因、调整原因、用户、部门或服务类型编造值。
- 性能:在连接HSP_ACCOUNT前,先根据有索引的日期列和获批准的组织筛选条件限制源数据行。谓词中避免对有索引的时间戳列应用函数。当原始历史数据量较大时,可考虑在获批准的报告视图中预先生成各项源活动。
- 去重:没有有文档记录的规则时,不要删除重复事件。同一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%。
无需信用卡,立即开始优化。