您的收入周期管理数据模板
您的收入周期管理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- Oracle Health收入周期数据提取指南
收入周期管理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间戳 EventTimestamp | 活动在系统中记录的准确日期和时间。 | ||
| 说明 该属性为每项活动提供时间戳，标记活动发生的准确时刻。对于了解特定计费事件收入周期中的事件时序至关重要。 在分析中，事件时间戳用于按时间顺序排列活动，计算不同步骤之间的持续时间和周期时间，并开展瓶颈分析。它是所有基于时间的流程挖掘指标的基础，例如识别“索赔已提交”与“已收到汇款通知”之间的延迟。 为什么重要 该时间戳对于排列事件顺序、计算周期时间和持续时间等绩效指标，以及识别流程瓶颈至关重要。 获取位置 Oracle Health Revenue Cycle中的每个交易表或事件日志表都应包含时间戳列，用于标明记录创建或事件发生的时间。 示例 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| 活动名称 ActivityName | 收入周期流程中发生的具体步骤或事件名称。 | ||
| 说明 该属性记录计费事件生命周期中执行的每项活动名称，例如“费用已捕获”“索赔已提交至付款方”和“付款已入账”。这些活动构成发现的流程图节点。 分析活动的顺序和频率是流程挖掘的核心。该属性有助于识别最常见的流程路径，发现偏离标准流程的情况，并了解收入周期的运营流程。 为什么重要 它定义流程中的各个步骤，用于可视化流程图并分析工作流模式。 获取位置 通常来源于事件日志、状态变更记录，或Oracle Health中与收入周期不同阶段相关的特定交易表。 示例 索赔已生成已收到汇款通知拒付已申诉账户已结清 | |||
| 计费事件 BillingEvent | 单项服务或产品交付所对应的唯一标识符，该交付会产生一笔费用，并作为收入周期流程的案例标识符。 | ||
| 说明 Billing Event是主要案例标识符，用于关联从费用捕获到账户结清的所有活动，代表收入周期流程中的一个独立实例，可全面跟踪其在索赔提交、付款入账以及潜在拒付或调整等阶段的进展。 在流程挖掘分析中，该属性是还原端到端流程的基础。它支持可视化流程变体、计算活动之间的周期时间，以及识别与特定计费事件相关的瓶颈或偏差。 为什么重要 这是跟踪可计费服务完整生命周期的关键标识，可支持所有流程分析和绩效衡量。 获取位置 该标识符应是Oracle Health Revenue Cycle核心计费或费用交易表中的唯一键。请查阅系统文档，确定费用事件的主键。 示例 BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| 付款方名称 PayerName | 负责付款的保险公司或第三方付款方名称。 | ||
| 说明 该属性用于识别为服务付费的实体，例如保险公司或Medicare等政府项目。付款方信息是收入周期分析的基础。 按付款方分析流程，可以发现付款时间、拒付率和申诉成功率的显著差异，有助于识别导致延迟或收入损失的问题付款方，并有效管理付款方合同和关系。 为什么重要 支持按付款方细分流程，揭示不同的行为、拒付率和付款速度，这对于财务绩效至关重要。 获取位置 这些信息存储在Oracle Health Revenue Cycle的患者计费或保险记录中。 示例 AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| 患者类别 PatientClass | 患者就诊记录的分类，例如住院或门诊。 | ||
| 说明 该属性用于分类产生费用的患者就诊或就诊记录类型。常见分类包括住院、门诊、急诊和复诊患者。患者类别通常会决定整个计费和索赔提交流程。 不同患者类别遵循不同的流程路径，并有不同的合规要求。基于该属性分析流程，有助于了解这些差异，制定针对性的改进措施，并确保每类患者遵循正确的流程。 为什么重要 区分具有不同复杂度、时限和计费要求的流程，例如住院与门诊流程。 获取位置 这是Oracle Health中与患者就诊记录或入院记录关联的标准字段。 示例 住院门诊急诊周期性 | |||
| 拒赔原因代码 DenialReasonCode | 用于说明付款方拒绝理赔原因的标准化代码。 | ||
| 说明 付款方拒绝理赔时，会提供原因代码解释拒赔原因，例如“未承保服务”或“重复理赔”。此属性记录该代码及其对应的说明。 分析拒赔原因是改进收入周期的基础。通过分析，组织可以识别编码错误、患者资格问题等常见模式，并采取纠正措施，避免未来再次遭到拒赔。这会直接影响干净理赔率，并降低返工成本。 为什么重要 提供理赔被拒的根本原因，帮助针对性改进，提高干净理赔率并加快收入回收。 获取位置 此信息由付款方通过电子汇款通知（ANSI 835文件）提供，应存储在Oracle Health的理赔表或汇款表中。 示例 CO-16：索赔或服务缺少裁定所需的信息。PR-96：不在承保范围内的费用。CO-18：重复索赔或服务。 | |||
| 未结余额 OutstandingBalance | 特定时间点计费事件尚未支付的剩余余额。 | ||
| 说明 该属性显示应用所有付款和调整后，计费事件当前尚未结清的应付金额，代表该笔费用对应的当前应收账款。 这是“未结余额账龄”仪表板的关键属性。随时间分析该数值，有助于监控现金流转速度、评估催收效果，并计算应收账款周转天数（DSO）等关键财务KPI。 为什么重要 跟踪每个案例当前的应收账款，对于管理现金流和分析催收效果至关重要。 获取位置 此值通常根据某个计费事件的所有财务交易（费用、付款、调整）总额计算得出，也可能作为字段存在于账户汇总表中。 示例 75.000.00550.80 | |||
| 用户 UserPerformingAction | 执行活动人员的用户ID或姓名。 | ||
| 说明 该属性用于识别负责执行流程中特定活动的员工或自动化系统用户。它对于了解工作量分配、资源绩效和培训需求至关重要。 在分析中，该属性支持按用户或团队筛选流程图，比较不同资源的绩效，并分析“计费部门工作量”仪表板中的工作量。它有助于识别高绩效人员，以及可能需要额外支持或培训的人员。 为什么重要 将流程活动关联到具体用户或团队，从而支持工作量分析、绩效比较和培训机会识别。 获取位置 Oracle Health各模块的交易表中通常包含用户ID字段，例如“CREATED_BY”和“USER_ID”。 示例 j.doeasmithBillingBot_AUTOk.williams | |||
| 计费部门 BillingDepartment | 负责执行该活动的部门或职能团队。 | ||
| 说明 该属性用于标明执行活动的部门，例如“费用捕获”“编码”或“催收”，为流程提供组织背景。 从部门视角分析流程，对于了解团队间交接和识别跨职能低效至关重要。它支持“计费部门工作量”仪表板，便于在部门层面汇总活动和绩效指标。 为什么重要 将活动分配给组织单元，是分析部门间交接、工作量和团队绩效的关键。 获取位置 这些信息可能直接存储在Oracle Health的用户档案数据中，也可能根据用户或活动类型推导得出。 示例 患者接入编码计费催收 | |||
| 调整金额 AdjustmentAmount | 对账户余额进行的各项调整金额。 | ||
| 说明 该属性记录应用于计费事件的各项财务调整金额，例如合同折让、核销或更正。调整会直接减少费用对应的预期收入。 “账户调整影响”仪表板高度依赖该属性。分析调整金额及其原因，有助于识别收入流失来源、合同管理问题或初始费用捕获流程中的问题，是衡量财务健康状况的重要指标。 为什么重要 量化因核销或更正造成的收入流失，帮助识别并解决财务损耗的根因。 获取位置 可在记录患者账户调整或核销的财务交易表中找到。 示例 -50.25-120.0025.00 | |||
| 争议原因 DisputeReason | 客户或患者对发票或费用提出争议时提供的原因。 | ||
| 说明 此属性记录患者或其他责任方对账单提出争议的原因，包括费用错误、未提供服务或保险处理问题等。 此信息对于“发票争议解决指标”仪表板至关重要。了解最常见的争议原因，有助于识别费用捕获、编码或计费流程中的系统性问题。解决这些根本原因，可以显著降低争议率，以及解决争议所需的管理工作量。 为什么重要 说明发票产生争议的原因，直接揭示计费准确性或清晰度方面需要解决的问题。 获取位置 此信息可能存储在Oracle Health的案件管理或客户服务模块中，并与患者账户关联。 示例 计费服务错误重复收费保险计费错误未提供服务 | |||
| 事件结束时间 EventEndTime | 活动完成时的时间戳（如有）。 | ||
| 说明 StartTime标记活动开始时间，EventEndTime标记活动结束时间。并非所有活动都有明确的结束时间，因为许多活动属于瞬时事件。但对于具有持续时间的活动，例如可能需要一段时间处理的“拒付已申诉”，该字段非常有用。 该属性可更精确地计算单项活动的处理时长，帮助区分等待时间（活动之间的时间）和处理时间（活动实际耗时）。 为什么重要 支持直接计算活动完成所需的时间，将处理时间与等待时间区分开来。 获取位置 Oracle Health Revenue Cycle中的部分交易表可能会为特定的长时间运行任务同时记录开始和结束时间戳。 示例 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| 最后更新时间 LastDataUpdate | 表示该事件数据最近一次刷新或提取时间的时间戳。 | ||
| 说明 该属性显示数据集最近一次更新的时间，为所分析数据的新鲜度提供背景，这对于了解流程挖掘分析所得洞察的时效性十分重要。 您可以查看该属性，确认当前看到的是最新流程信息。它有助于明确数据时效预期，也是数据治理和质量保障的重要组成部分。 为什么重要 表示数据的新鲜度，确保分析和决策基于最新信息。 获取位置 这是通常在ETL过程中生成并填充的元数据字段，用于将数据加载到流程挖掘平台。 示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 患者ID PatientId | 与计费事件关联的患者唯一标识符。 | ||
| 说明 此属性是接受服务患者的唯一标识符，通常称为病历号（MRN）。它将财务交易关联到具体个人。 患者ID不是流程的案件ID，但可用于汇总单个患者的所有计费事件，了解其完整的财务历程。如果与患者主数据关联，还可根据患者人口统计信息或历史记录进行细分。 为什么重要 将财务事件关联到具体患者，支持以患者为中心的分析，并汇总其全部计费活动。 获取位置 此标识符是患者主记录的核心要素，会出现在费用、理赔和付款等所有相关交易表中。 示例 MRN-1002345MRN-1002346MRN-1002347 | |||
| 是否自动化 IsAutomated | 用于标识活动由自动化系统还是人工用户执行的标志。 | ||
| 说明 此布尔属性用于区分由软件自动化执行的活动（例如机器人或系统批处理作业）与用户手动执行的活动。例如，“理赔生成”可能是自动化步骤，而“拒赔申诉”通常需要人工处理。 分析此属性有助于了解流程的自动化程度及其对效率和错误率的影响。您可以据此比较自动化路径与人工路径的表现，并识别进一步自动化的机会。 为什么重要 区分人工活动与系统驱动活动，对于分析自动化效果和识别新的自动化机会至关重要。 获取位置 通常根据UserPerformingAction属性推导。例如，由“系统”或“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 | |||
| 费用金额 ChargeAmount | 所计费服务或产品的总金额。 | ||
| 说明 该属性表示服务在应用任何调整、合同折让或付款之前的初始未折扣计费金额，是计费事件的起始财务价值。 跟踪费用金额对于财务分析至关重要，例如计算已提供服务的总价值，了解后续调整或核销的财务影响。它也是衡量收入实现情况的基准。 为什么重要 确定案例的初始财务价值，是后续所有财务分析和影响评估的基础。 获取位置 位于Oracle Health的费用明细表或费用交易表中。 示例 150.001250.7585.50 | |||
收入周期管理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 付款已入账 | 表示将付款方收到的款项应用到患者账户中的相应费用。这是一笔由用户或自动化流程记录的财务交易。 | ||
| 为什么重要 付款入账效率会影响应收账款的准确性。此环节的延迟可能扭曲财务状况，并推迟二次计费。 获取位置 可在付款交易表中找到。每笔付款入账都有唯一的交易ID和对应时间戳。 采集 付款应用到账户时记录的一笔财务交易。 事件类型 explicit | |||
| 患者就诊记录已创建 | 表示为特定就诊或服务创建患者账户。通常，这是由登记系统或入院、出院、转院（ADT）数据源触发的明确事件。 | ||
| 为什么重要 它是特定计费事件整个收入周期的起点，可用于分析流程总时长和登记准确性。 获取位置 数据来源于Patient Registration或ADT模块日志。请查找就诊记录创建事件，或与就诊记录、财务编号相关的最早时间戳。 采集 患者登记或入院时记录的事件。 事件类型 explicit | |||
| 索赔已提交至付款方 | 表示将生成的索赔单以电子或纸质形式提交给保险公司或其他付款方。系统应记录传输的日期和时间。 | ||
| 为什么重要 该活动标志着付款周期开始计时。分析从提交到付款的时间，对于了解付款方表现和应收账款周转天数（DSO）至关重要。 获取位置 数据来自记录传输事件的索赔管理模块。请查找提交时间戳，或索赔历史中状态变更为“已提交”的记录。 采集 索赔通过清算机构成功传输时记录的事件。 事件类型 explicit | |||
| 索赔已生成 | 表示将单笔费用汇总为正式计费索赔单的节点，例如UB-04或CMS-1500。这是由系统生成的事件，用于创建初始发票。 | ||
| 为什么重要 这是表明已准备好向付款方计费的重要里程碑，也是衡量内部费用到计费滞后的终点。 获取位置 索赔生成日志或表中记录的明确事件。请查找与就诊记录关联的主索赔记录创建时间戳。 采集 创建索赔记录时记录的事件。 事件类型 explicit | |||
| 账户已结清 | 表示账户余额为零且预计不会再发生其他活动的最终活动。通常在账户余额归零时推断。 | ||
| 为什么重要 标志着收入周期成功完成。达到该状态所需的时间是衡量整体流程效率的重要指标。 获取位置 通常通过识别账户未结余额首次变为零且在所有付款和调整完成后持续为零的时间来推断。 采集 所有费用和付款入账后，账户余额首次等于零时计算。 事件类型 calculated | |||
| 催收活动已启动 | 表示由于未付款，患者账户已转入催收流程。通常通过账户财务类别或状态类别的变更进行记录。 | ||
| 为什么重要 这是管理坏账的关键步骤。分析哪些因素导致账户进入该阶段及其成功率，对于维护财务健康至关重要。 获取位置 根据账户状态字段变更为“催收”或“坏账”推断。该状态变更应带有对应时间戳。 采集 根据账户状态变更为“催收”或类似状态推断。 事件类型 inferred | |||
| 已收到拒付 | 表示付款方拒绝索赔或其中的特定明细，具体以汇款通知中的信息为准。该事件通常根据汇款数据中的拒付代码推断。 | ||
| 为什么重要 跟踪拒付对于识别编码错误、资格问题等根因，以及提高一次通过索赔率至关重要。 获取位置 根据汇款（ERA/835）数据推断。当索赔或费用明细存在非零拒付金额及对应拒付原因代码时，将触发该事件。 采集 根据包含拒付原因代码（CARC/RARC）的汇款数据推断。 事件类型 inferred | |||
| 已收到汇款通知 | 表示收到付款方发来的电子汇款通知（ERA）或纸质福利说明（EOB）。该文件详细说明了哪些费用已支付、被拒付或进行了调整。 | ||
| 为什么重要 这是付款方的首次响应，对于了解付款速度并及早识别拒付趋势至关重要。 获取位置 记录在汇款处理模块中。请查找与索赔关联的ERA文件（如835交易文件）的导入或创建时间戳。 采集 导入并处理付款方汇款文件（例如ANSI 835）时记录的事件。 事件类型 explicit | |||
| 患者账单已发送 | 表示生成并向患者发送剩余个人应付金额账单的事件。这是由患者计费模块记录的明确操作。 | ||
| 为什么重要 该活动启动收入周期中的患者付款环节。跟踪它有助于分析患者催收的有效性。 获取位置 数据来自患者计费或通信日志。系统应记录每份账单生成或发送的日期。 采集 患者账单生成并打印或以电子方式发送时记录的事件。 事件类型 explicit | |||
| 拒付已申诉 | 表示用户或系统发起申诉，针对被拒付的索赔提出复议。通常以状态更新或工作队列中创建的特定任务记录。 | ||
| 为什么重要 该活动会启动返工循环。分析申诉频率和成功率，对于优化收入追回工作至关重要。 获取位置 这可以是用户明确发起的事件，也可以根据索赔状态变更推断，例如变为“已申诉”或“审核中”。 采集 用户针对被拒付索赔发起申诉流程时记录的状态变更或事件。 事件类型 explicit | |||
| 更正后的索赔已提交 | 表示向付款方提交修订或更正后的索赔，通常发生在拒付或收到补充信息请求之后。其特征是提交带有更正标识的新索赔。 | ||
| 为什么重要 该活动是拒付管理返工循环的重要组成部分。发生频率较高，通常说明初始索赔准确性存在问题。 获取位置 数据来自索赔提交日志。请查找同一就诊记录的新提交记录，通常会标有重新提交代码或更高的迭代编号。 采集 索赔重新提交时记录的事件，通常可通过特定的索赔频率类型代码识别。 事件类型 explicit | |||
| 账户已调整 | 表示对账户余额进行的财务调整，例如合同折让、核销或折扣。每笔调整都是一笔独立的财务交易。 | ||
| 为什么重要 调整会直接影响收入。分析调整的频率、类型和金额，有助于识别收入流失和计费错误。 获取位置 可在财务交易表中找到。每笔调整都会作为单独的明细记录，并带有特定交易代码和时间戳。 采集 使用特定调整代码记录的一笔财务交易。 事件类型 explicit | |||
| 费用已捕获 | 表示将可计费服务或项目录入患者账户。这可以由临床系统自动完成，也可以由工作人员手动录入。 | ||
| 为什么重要 该活动对于衡量“费用滞后”至关重要，即服务交付与计费启动之间的时间，它会直接影响现金流和收入完整性。 获取位置 数据来自费用交易表，以每条费用明细的创建时间戳为识别依据。在Oracle Health中，这些数据通常位于费用相关表中。 采集 每笔新费用创建时生成的交易日志记录。 事件类型 explicit | |||
| 费用已编码 | 表示医疗编码人员为已捕获的费用分配CPT或ICD-10等标准化代码的过程。通常通过费用或就诊记录的状态变更进行跟踪。 | ||
| 为什么重要 编码延迟是常见瓶颈。跟踪该活动有助于识别编码工作流中的低效环节及其对计费时效的影响。 获取位置 通常根据患者就诊记录或费用批次的状态变更推断，例如从“未编码”变为“已编码”。必须记录该状态变更的时间戳。 采集 根据就诊记录或费用状态变更为“已编码”或“可计费”推断。 事件类型 inferred | |||
提取指南
步骤
- 申请数据库访问权限：获取Oracle Health Revenue Cycle数据库的只读凭据。您需要访问包含患者、就诊、计费和财务交易数据的架构。通常需要获得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。
a 示例查询 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%，提升现金流。
无需信用卡，几分钟即可完成设置。