收入周期管理数据模板
收入周期管理数据模板
- 建议收集的属性
- 建议跟踪的关键活动
- Oracle Health收入周期数据提取指南
收入周期管理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间戳 EventTimestamp | 活动记录在系统中的准确日期和时间。 | ||
| 说明 此属性为每项活动提供时间戳，标记其发生的准确时刻。它对于了解特定账单事件在收入周期中的时间安排和事件顺序至关重要。 分析时，事件时间戳用于按时间顺序排列活动、计算不同步骤之间的持续时间和周期时间，并开展瓶颈分析。所有基于时间的流程挖掘指标都以此为基础，例如识别“已提交索赔”与“收到付款通知”之间的延迟。 重要性 此时间戳对于排列事件顺序、计算周期时间和持续时间等绩效指标，以及识别流程瓶颈至关重要。 获取途径 Oracle Health收入周期中的每个交易表或事件日志表都应包含时间戳列，用于标明记录创建或事件发生的时间。 示例 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| 活动名称 ActivityName | 收入周期流程中发生的具体步骤或事件名称。 | ||
| 说明 此属性记录账单事件生命周期中每项活动的名称，例如“捕获费用”“向付款方提交索赔”和“付款入账”。这些活动构成发现的流程图中的节点。 分析活动的顺序和频率是流程挖掘的核心。此属性有助于识别最常见的流程路径、发现偏离标准过程的情况，并了解收入周期的运营流程。 重要性 此属性定义流程中的步骤，可用于呈现流程图并分析工作流模式。 获取途径 通常根据事件日志、状态变更记录，或Oracle Health中与收入周期不同阶段相关的特定交易表提取。 示例 生成索赔收到付款通知提出拒付申诉账户结清 | |||
| 账单事件 BillingEvent | 用于标识一次产生费用的服务或产品交付，是收入周期流程中的案例标识符。 | ||
| 说明 账单事件是主要的案例标识符，可将某个可计费项目从费用捕获到账户结清的所有活动关联起来。每个账单事件对应收入周期流程中的一个独立实例，可全面跟踪其在索赔提交、付款入账以及可能发生的拒付或调整等阶段的进展。 在流程挖掘分析中，此属性是重建端到端流程路径的基础。它可用于呈现流程变体、计算活动间的周期时间，并识别与特定账单事件相关的瓶颈或偏差。 重要性 这是跟踪可计费服务完整生命周期的关键标识，可支持所有流程路径分析和绩效衡量。 获取途径 此标识应是Oracle Health收入周期核心账单表或费用交易表中的唯一键。请查阅系统文档，确认费用事件的主键。 示例 BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| 付款方名称 PayerName | 负责付款的保险公司或第三方付款方名称。 | ||
| 说明 此属性用于标识为服务付费的实体，例如保险公司或Medicare等政府项目。付款方信息是收入周期分析的基础。 按付款方分析流程，可以发现付款时间、拒付率和申诉成功率方面的显著差异。这有助于识别导致延迟或收入损失的付款方，并有效管理付款方合同和合作关系。 重要性 可按付款方细分流程，揭示不同付款方的行为、拒付率和付款速度，这对财务绩效分析至关重要。 获取途径 此信息存储在Oracle Health收入周期中的患者账单或保险记录内。 示例 AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| 患者类别 PatientClass | 患者就诊记录的分类，例如住院或门诊。 | ||
| 说明 此属性用于对产生费用的患者就诊类型进行分类。常见类别包括住院、门诊、急诊和复诊患者。患者类别通常决定整个账单和索赔提交流程。 不同患者类别对应不同的流程路径和合规要求。按此属性分析流程，有助于了解这些差异、制定有针对性的改进措施，并确保各类别均遵循正确的操作规程。 重要性 区分不同的流程路径（如住院与门诊），这些路径在复杂程度、时限和账单要求方面各不相同。 获取途径 这是Oracle Health中与患者就诊记录或入院记录关联的标准字段。 示例 住院门诊急诊定期 | |||
| 拒赔原因代码 DenialReasonCode | 用于说明付款方拒绝理赔原因的标准化代码。 | ||
| 说明 付款方拒绝理赔时，会提供原因代码说明拒赔原因，例如“服务不在承保范围内”或“重复提交理赔”。此属性记录该代码及其说明。 分析拒赔原因是改善收入周期的基础。组织可以据此发现常见问题，例如编码错误或患者资格问题，并采取纠正措施，避免再次遭到拒赔。这有助于提高理赔一次通过率，并减少返工成本。 重要性 揭示理赔遭拒的根本原因，帮助有针对性地改进流程、提高理赔一次通过率并加快收入回收。 获取途径 此信息由付款方通过电子汇款通知（ANSI 835文件）提供，应存储在Oracle Health的理赔表或汇款表中。 示例 CO-16：理赔或服务缺少审核所需的信息。PR-96：收费项目不在承保范围内。CO-18：重复提交理赔或服务。 | |||
| 未结余额 OutstandingBalance | 某一时点该计费事件尚未支付的余额。 | ||
| 说明 此属性显示计费事件在应用所有付款和调整后的当前欠款金额，即该笔收费对应的应收账款。 “未结余额账龄”仪表板会重点使用此属性。持续分析该数值，有助于监控现金流转速度、评估催收成效，并计算应收账款周转天数（DSO）等关键财务指标。 重要性 跟踪每个案例当前的应收账款，是现金流管理和催收成效分析的重要依据。 获取途径 此值通常根据某一计费事件的所有财务交易（收费、付款和调整）汇总计算，也可能作为字段存储在账户汇总表中。 示例 75.000.00550.80 | |||
| 用户 UserPerformingAction | 执行活动的人员的用户ID或姓名。 | ||
| 说明 此属性用于识别负责执行流程中特定活动的员工或自动化系统用户。它对于了解工作量分配、资源绩效和培训需求至关重要。 分析时，此属性可用于按用户或团队筛选流程图、比较不同资源的绩效，以及分析“账单部门工作量”仪表板中的工作量。它有助于识别表现突出的人员，以及可能需要额外支持或培训的人员。 重要性 将流程活动关联到特定用户或团队，以便分析工作量、比较绩效并发现培训机会。 获取途径 Oracle Health各模块的交易表中通常包含用户ID字段（如“CREATED_BY”“USER_ID”）。 示例 j.doeasmithBillingBot_AUTOk.williams | |||
| 调整金额 AdjustmentAmount | 对账户余额进行的各项调整金额。 | ||
| 说明 此属性记录应用于计费事件的财务调整金额，例如合同约定减免、核销或更正。调整会直接减少收费对应的预期收入。 “账户调整影响”仪表板会大量使用此属性。分析调整金额及其原因，有助于发现收入流失来源、合同管理问题或初始收费记录流程中的问题。这是衡量财务健康状况的一项关键指标。 重要性 量化核销或更正造成的收入流失，帮助识别并解决财务损失的根本原因。 获取途径 记录患者账户调整或核销的财务交易表中。 示例 -50.25-120.0025.00 | |||
| 账单部门 BillingDepartment | 负责该活动的部门或职能团队。 | ||
| 说明 此属性用于指定执行活动的部门，例如“费用捕获”“编码”或“催收”，为流程路径提供组织层面的背景信息。 从部门视角分析流程，有助于了解团队间的交接情况并发现跨职能低效环节。此属性还支持“账单部门工作量”仪表板，可按部门汇总活动和绩效指标。 重要性 将活动分配给组织单元，是分析部门间交接、工作量和团队绩效的关键。 获取途径 此信息可能直接存储在Oracle Health的用户资料数据中，也可能根据用户或活动类型推导得出。 示例 患者服务编码账单催收 | |||
| 争议原因 DisputeReason | 客户或患者对发票或收费提出异议时给出的原因。 | ||
| 说明 此属性记录患者或其他责任方对账单提出异议的原因，例如收费错误、未提供服务或保险处理问题。 此信息对于“发票争议解决指标”仪表板至关重要。了解常见争议原因，有助于发现收费记录、编码或计费流程中的系统性问题。解决这些根本原因，可以显著降低争议率，减少处理争议所需的行政工作。 重要性 说明发票遭到质疑的原因，直接揭示计费准确性或清晰度方面需要解决的问题。 获取途径 此信息可能存储在Oracle Health的案件管理或客户服务模块中，并关联至患者账户。 示例 服务项目收费错误重复收费保险计费错误未提供服务 | |||
| 事件结束时间 EventEndTime | 标记活动完成时间的时间戳（如有）。 | ||
| 说明 StartTime标记活动的开始时间，EventEndTime则标记活动的结束时间。并非所有活动都有明确的结束时间，因为许多活动是瞬时事件。不过，对于有持续时间的活动，例如可能需要一段时间处理的“提出拒付申诉”，此字段非常有用。 此属性可更准确地计算单项活动的处理时间，并帮助区分等待时间（活动之间的间隔）和处理时间（活动本身耗费的时间）。 重要性 可直接计算活动完成所需的时间，并将处理时间与等待时间区分开来。 获取途径 Oracle Health收入周期中的部分交易表可能会同时记录特定长时间运行任务的开始和结束时间戳。 示例 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| 患者ID PatientId | 与计费事件关联的患者唯一标识符。 | ||
| 说明 此属性是接受服务的患者唯一标识符，通常称为病历号（MRN）。它将财务交易关联到具体患者。 患者ID并非流程的案例ID，但可用于汇总单个患者的所有计费事件，了解其完整的财务历程。如果与患者主数据关联，还可按患者人口统计信息或病史进行细分分析。 重要性 将财务事件关联到具体患者，支持以患者为中心的分析，并汇总其所有计费活动。 获取途径 此标识符是患者主记录的核心字段，会出现在收费、理赔和付款等相关交易表中。 示例 MRN-1002345MRN-1002346MRN-1002347 | |||
| 收费金额 ChargeAmount | 所收取服务或产品的总金额。 | ||
| 说明 此属性表示服务的初始收费金额，即尚未扣除任何折扣、合同约定减免或付款前的金额。它是该计费事件的初始财务价值。 跟踪收费金额对于财务分析至关重要，例如计算已提供服务的总价值，以及了解后续调整或核销的财务影响。它也是衡量收入实现情况的基准。 重要性 确定案例的初始财务价值，为后续财务分析和影响评估奠定基础。 获取途径 位于Oracle Health的收费明细表或收费交易表中。 示例 150.001250.7585.50 | |||
| 数据上次更新时间 LastDataUpdate | 表示此事件数据上次刷新或提取时间的时间戳。 | ||
| 说明 此属性显示数据集上次更新的时间，可帮助您了解正在分析的数据是否足够新，从而判断流程挖掘分析所得洞察的时效性。 用户可以查看此属性，确认当前查看的是最新流程信息。它有助于管理对数据新鲜度的预期，也是数据治理和质量保证的重要组成部分。 重要性 用于说明数据的新鲜度，确保分析和决策基于最新信息。 获取途径 这是一个元数据字段，通常在将数据加载到流程挖掘平台的ETL过程中生成并填充。 示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 是否自动化 IsAutomated | 用于标记活动由自动化系统还是人工用户执行。 | ||
| 说明 此布尔属性用于区分由软件自动化（如机器人或系统批处理作业）执行的活动与用户手动执行的活动。例如，“生成理赔”可能是自动化步骤，而“对拒赔提出申诉”通常由人工完成。 分析此属性有助于了解流程的自动化程度及其对效率和错误率的影响。您可以比较自动化路径与人工路径的表现，并发现进一步自动化的机会。 重要性 区分人工活动与系统执行的活动，对于分析自动化成效和发现新的自动化机会至关重要。 获取途径 此属性通常根据UserPerformingAction属性推导。例如，由“SYSTEM”或“RPA_BOT”等用户ID执行的活动会标记为自动化。 示例 truefalse | |||
| 是否返工 IsRework | 用于标记返工或重复操作的活动。 | ||
| 说明 此计算属性用于标记偏离理想路径并构成返工的活动。例如，“更正后重新提交理赔”或“对拒赔提出申诉”都属于返工，因为流程首次顺利完成时不会出现这些活动。 识别并量化返工是流程挖掘的重要目标。此标记便于筛选和分析所有返工循环，帮助衡量流程低效的频率、成本和成因，也是了解收入周期质量成本的关键。 重要性 帮助量化返工循环的频率和影响，揭示流程低效问题及质量不佳带来的成本。 获取途径 此属性由数据推导而来。在数据转换过程中，根据业务规则将特定活动名称标记为返工并计算得出。 示例 truefalse | |||
| 源系统 SourceSystem | 提取事件数据的系统。 | ||
| 说明 此属性用于标识数据来源的应用程序或模块。对于此流程，通常为“Oracle Health Revenue Cycle”；如果数据来自系统中的多个位置，也可以标明不同模块。 此信息有助于数据治理和故障排查，可用于确认数据沿袭。在多个系统共同构成单一端到端流程的环境中，这一点尤为重要。 重要性 说明数据来源，对于数据验证、治理以及了解可能由系统差异导致的流程变化至关重要。 获取途径 这通常是在数据提取、转换和加载（ETL）过程中添加的静态值，用于标记数据集的来源。 示例 OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| 理赔ID ClaimId | 提交给付款方的保险理赔唯一标识符。 | ||
| 说明 此属性是分配给理赔的唯一ID，用于生成并发送给付款方以申请报销。一个计费事件在其生命周期内可能产生一笔或多笔理赔，例如需要更正时。 通过理赔ID，可以追踪提交给付款方的具体理赔，并将其与付款或拒赔等回复直接关联。相比整体计费事件，它能提供更细粒度的跟踪信息。 重要性 为理赔与付款方之间的处理过程提供专属标识，跟踪粒度比整体计费事件更细。 获取途径 理赔创建时由Oracle Health生成此ID，并存储在理赔主表中。 示例 CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
收入周期管理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 付款入账 | 表示将收到的付款方款项记入患者账户中的相应费用。这是一笔由用户或自动化流程记录的财务交易。 | ||
| 重要性 付款入账效率会影响应收账款的准确性。此环节的延迟可能导致财务状况失真，并推迟向次级付款方开票。 获取途径 数据位于付款交易表中。每笔付款入账记录都有唯一的交易ID和对应时间戳。 采集 款项记入账户时会生成一笔财务交易记录。 事件类型 explicit | |||
| 创建患者就诊记录 | 表示为特定就诊或服务创建患者账户。通常由登记系统或入院／出院／转院（ADT）数据流触发，并记录为明确事件。 | ||
| 重要性 这是特定账单事件整个收入周期的起点，可用于分析流程总时长和登记准确性。 获取途径 数据来自患者登记或ADT模块日志。请查找就诊记录创建事件，或与就诊记录、财务编号相关的最早时间戳。 采集 患者登记或入院时记录的事件。 事件类型 explicit | |||
| 向付款方提交索赔 | 表示通过电子或纸质方式向保险公司或付款方提交已生成的索赔。系统应记录传输的日期和时间。 | ||
| 重要性 这项活动标志着付款周期开始。分析从提交到付款的时间，有助于了解付款方表现和应收账款周转天数（DSO）。 获取途径 数据来自会记录传输事件的索赔管理模块。请查找提交时间戳，或索赔历史中变为“已提交”的状态记录。 采集 索赔通过清算所成功传输时记录的事件。 事件类型 explicit | |||
| 生成索赔 | 表示将各项费用汇总为正式账单索赔的时点，例如UB-04或CMS-1500。这是系统生成的事件，会创建初始发票。 | ||
| 重要性 这是一个重要里程碑，表示已准备好向付款方开票，也是衡量内部费用到开票延迟的终点。 获取途径 这是索赔生成日志或数据表中记录的明确事件。请查找与就诊记录关联的主索赔记录创建时间戳。 采集 创建索赔记录时记录的事件。 事件类型 explicit | |||
| 账户结清 | 最后一项活动，表示账户余额为零且预计不会再有后续活动。通常在账户余额归零时推断此事件。 | ||
| 重要性 标志着收入周期顺利完成。达到此状态所需的时间是衡量整体流程效率的重要指标。 获取途径 通常通过识别账户未结余额首次归零且在所有付款和调整完成后持续为零的时间来推断。 采集 所有费用和付款均入账后，账户余额首次为零时计算。 事件类型 calculated | |||
| 向患者发送账单 | 表示生成并向患者发送剩余个人应付金额的账单。这是患者账单模块记录的明确操作。 | ||
| 重要性 这标志着收入周期进入患者付款阶段。跟踪此环节有助于分析患者催收工作的成效。 获取途径 数据来自患者账单或通信日志。系统应记录每份账单的生成或发送日期。 采集 生成患者账单并打印或以电子方式发送时记录的事件。 事件类型 explicit | |||
| 启动催收 | 表示患者因未付款而进入催收流程。通常通过账户财务类别或状态类别的变更进行记录。 | ||
| 重要性 这是管理坏账的关键环节。分析账户进入此阶段的原因及催收成功率，对维持财务健康至关重要。 获取途径 根据账户状态字段变为“催收中”或“坏账”进行推断。此状态变更应有对应的时间戳。 采集 根据账户状态变为“催收中”或类似状态进行推断。 事件类型 inferred | |||
| 捕获费用 | 表示将可计费的服务或项目录入患者账户。此操作可以由临床系统自动完成，也可以由工作人员手动录入。 | ||
| 重要性 这项活动对于衡量“费用延迟”至关重要，即服务提供与启动账单处理之间的时间差，它会直接影响现金流和收入准确性。 获取途径 数据来自费用交易表，可通过每条费用明细的创建时间戳识别。在Oracle Health中，这些数据通常位于费用相关表中。 采集 每新增一笔费用，系统都会创建一条交易日志记录。 事件类型 explicit | |||
| 提交更正后的索赔 | 表示向付款方提交修订或更正后的索赔，通常发生在索赔被拒付或收到补充信息请求之后。可通过带有更正标记的新索赔提交记录识别。 | ||
| 重要性 这项活动是拒付管理返工循环的重要环节。发生频率较高，说明初始索赔的准确性存在问题。 获取途径 数据来自索赔提交日志。请查找同一就诊记录的新提交记录，通常会标有重新提交代码或更高的迭代编号。 采集 索赔重新提交时记录的事件，通常可通过特定的索赔频率类型代码识别。 事件类型 explicit | |||
| 提出拒付申诉 | 表示用户或系统正在对被拒付的索赔提出申诉。通常记录为状态更新，或在工作队列中创建的特定任务。 | ||
| 重要性 这项活动会启动返工循环。分析申诉频率和成功率，对于优化收入追回工作至关重要。 获取途径 这可能是用户明确发起的事件，也可能根据索赔状态变更推断，例如变为“已申诉”或“审核中”。 采集 用户为被拒付的索赔发起申诉时记录的状态变更或事件。 事件类型 explicit | |||
| 收到付款通知 | 表示收到付款方发来的电子汇款建议书（ERA）或纸质福利说明（EOB）。该文件会列明哪些费用已付款、被拒付或进行了调整。 | ||
| 重要性 这是付款方的首次回复，对于了解回款速度和及早发现拒付趋势至关重要。 获取途径 记录在汇款处理模块中。请查找与索赔关联的ERA文件（例如835交易文件）的导入或创建时间戳。 采集 导入并处理付款方汇款文件（如ANSI 835）时记录的事件。 事件类型 explicit | |||
| 收到拒付 | 表示付款方拒绝了索赔或其中的特定明细，相关信息会显示在汇款通知中。通常可根据汇款数据中的拒付代码推断此事件。 | ||
| 重要性 跟踪拒付对于找出编码错误或资格问题等根本原因、提高干净索赔率至关重要。 获取途径 根据汇款（ERA／835）数据推断。当索赔或明细存在非零拒付金额及相应拒付原因代码时，即触发此事件。 采集 根据包含拒付原因代码（CARC／RARC）的汇款数据推断。 事件类型 inferred | |||
| 账户调整 | 表示对账户余额进行财务调整，例如合同折让、核销或折扣。每项调整都是一笔独立的财务交易。 | ||
| 重要性 调整会直接影响收入。分析调整的频率、类型和金额，有助于发现收入流失和账单错误。 获取途径 数据位于财务交易表中。每项调整都会作为单独的明细记录，并带有特定交易代码和时间戳。 采集 系统会使用特定调整代码记录一笔财务交易。 事件类型 explicit | |||
| 费用编码 | 表示医疗编码人员为已捕获的费用分配标准代码（如CPT或ICD-10）的过程。通常通过费用或就诊记录的状态变更进行跟踪。 | ||
| 重要性 编码延迟是常见的瓶颈。跟踪这项活动有助于发现编码工作流中的低效环节及其对账单处理时限的影响。 获取途径 通常根据患者就诊记录或费用批次的状态变更推断，例如从“未编码”变为“已编码”。需要记录该状态变更的时间戳。 采集 根据就诊记录或费用状态变为“已编码”或“可开票”进行推断。 事件类型 inferred | |||
数据提取指南
步骤
- 申请数据库访问权限：获取Oracle Health收入周期数据库的只读凭据。您需要访问包含患者、就诊、计费和财务交易数据的架构。通常需要获得IT安全团队和数据库管理团队的批准。
- 确认架构和表名：与数据库管理员或系统分析师确认Oracle Health实例中的确切架构名和表名。查询中提供的名称仅为常见示例，必须映射到您的实际环境。
- 安装SQL客户端：在工作站上安装兼容的SQL客户端，例如Oracle SQL Developer或DBeaver，用于连接数据库并运行提取脚本。
- 建立数据库连接：在SQL客户端中使用提供的主机、端口、服务名和凭据配置新的数据库连接，并测试连接是否成功。
- 自定义SQL查询：将提供的SQL脚本复制到新的查询编辑器窗口。找到
[START_DATE]和[END_DATE]等占位符，并替换为所需的分析日期范围，例如“2023-01-01”。根据分析需求调整筛选条件，例如筛选特定的Patient Class。 - 运行提取脚本：运行自定义后的SQL脚本。查询内容较全面，运行时间可能从几分钟到数小时不等，具体取决于日期范围和数据库大小。
- 检查初步结果：查询完成后，在SQL客户端的结果表格中查看前几百行。检查是否存在整列为空或数据格式错误等明显问题，确认脚本运行正常。
- 将数据导出为CSV：将完整结果集导出为CSV文件，并使用UTF-8编码以避免字符显示问题。确保导出文件包含标题行，列名与查询别名一致，例如“BillingEvent”和“ActivityName”。
- 准备上传：上传到流程挖掘工具前，先打开CSV文件确认数据完整。检查时间戳格式是否一致，列标题是否与所需属性完全匹配。完成后即可上传文件。
配置
- 日期范围：查询使用
[START_DATE]和[END_DATE]占位符。必须设置明确且合理的日期范围，以控制数据量。建议初次分析使用3至6个月的数据。 - 筛选条件：初始数据集在
RelevantEncounters部分按就诊登记日期（reg_dt_tm）筛选。您可以在此部分添加其他WHERE子句来缩小范围，例如使用e.patient_class_code IN ('INPATIENT', 'OUTPATIENT')筛选特定就诊类型。 - 性能：直接查询生产系统数据库可能影响系统性能。强烈建议在业务低峰时段执行提取，或在可用时查询生产数据库的只读副本。
- 前提条件：此方法要求数据库用户对查询中引用的所有表具有
SELECT权限，包括就诊、计费、费用、索赔、汇款和财务交易表。 - 表和列映射：提供的脚本使用常见的表名和列名示例。您必须确认这些名称，并将其映射到所在组织Oracle Health数据库架构中的实际名称。例如，系统中的
FINANCIAL_TRANSACTION可能名为AR_TRANSACTIONS。
查询示例 sql
WITH RelevantEncounters AS (
SELECT
e.billing_event_id
FROM ENCOUNTER e
WHERE e.reg_dt_tm BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
)
SELECT
e.billing_event_id AS "BillingEvent",
'Patient Encounter Created' AS "ActivityName",
e.reg_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.reg_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cd.billing_event_id AS "BillingEvent",
'Charges Captured' AS "ActivityName",
cd.charge_entry_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cd.charge_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CHARGE_DETAIL cd
JOIN ENCOUNTER e ON cd.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cd.entry_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cd.performing_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
ch.billing_event_id AS "BillingEvent",
'Charges Coded' AS "ActivityName",
ch.coded_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CODING_HISTORY ch
JOIN ENCOUNTER e ON ch.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ch.coder_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cl.billing_event_id AS "BillingEvent",
'Claim Generated' AS "ActivityName",
cl.create_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM cl
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cl.create_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Claim Submitted To Payer' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'INITIAL'
UNION ALL
SELECT
ra.billing_event_id AS "BillingEvent",
'Remittance Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM REMITTANCE_ADVICE ra
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Payment Posted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'PAYMENT'
UNION ALL
SELECT
rd.billing_event_id AS "BillingEvent",
'Denial Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
rd.denial_reason_code AS "DenialReasonCode"
FROM REMITTANCE_DETAIL rd
JOIN REMITTANCE_ADVICE ra ON rd.remit_id = ra.remit_id
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
WHERE rd.denial_reason_code IS NOT NULL
UNION ALL
SELECT
at.billing_event_id AS "BillingEvent",
'Denial Appealed' AS "ActivityName",
at.appeal_filed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
at.related_denial_code AS "DenialReasonCode"
FROM APPEAL_TRACKING at
JOIN ENCOUNTER e ON at.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON at.appeal_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON at.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Corrected Claim Submitted' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'CORRECTED'
UNION ALL
SELECT
psl.billing_event_id AS "BillingEvent",
'Patient Statement Sent' AS "ActivityName",
psl.statement_sent_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
psl.statement_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM PATIENT_STATEMENT_LOG psl
JOIN ENCOUNTER e ON psl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON psl.sent_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
UNION ALL
SELECT
ash.billing_event_id AS "BillingEvent",
'Collection Activity Started' AS "ActivityName",
ash.status_change_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ash.account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ACCOUNT_STATUS_HISTORY ash
JOIN ENCOUNTER e ON ash.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ash.change_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ash.responsible_org_id = org.organization_id
WHERE ash.new_status_code = 'COLLECTIONS'
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Account Adjusted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
ft.transaction_amount AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
ft.adjustment_reason_code AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'ADJUSTMENT'
UNION ALL
SELECT
e.billing_event_id AS "BillingEvent",
'Account Closed' AS "ActivityName",
e.account_closed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
0 AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.closed_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
WHERE e.total_account_balance = 0 AND e.account_closed_dt_tm IS NOT NULL;优化收入周期，加快回款
消除瓶颈，将周期时间缩短30%，改善现金流。
无需信用卡，几分钟即可完成设置。