您的收入周期管理数据模板
您的收入周期管理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- Oracle Health 收入周期数据提取指南
收入周期管理属性
| 名称 | 描述 | ||
|---|---|---|---|
| 事件timestamp EventTimestamp | 活动在系统中记录的精确日期和时间。 | ||
| 描述 此属性提供每个活动的 timestamp,记录其发生的精确时刻。这对于理解特定计费事件在收入周期内的发生时间和顺序至关重要。 在分析中,Event Timestamp 用于按时间先后顺序排列活动,计算不同步骤之间的持续时间和周期时间,并进行瓶颈分析。它是所有基于时间的流程挖掘指标的基础,例如识别“索赔已提交”与“汇款已收到”之间的延迟。 为何重要 此 timestamp 对于事件排序、计算周期和时长等所有性能指标以及识别流程瓶颈至关重要。 获取方式 Oracle Health 收入周期中的每个交易或事件日志表都应有一个时间戳列,指示记录创建或事件发生的时间。 示例 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| 活动名称 ActivityName | 收入周期流程中发生的特定步骤或事件的名称。 | ||
| 描述 此属性记录计费事件生命周期内执行的每个活动名称。例如:“费用已捕获”、“索赔已提交至付款方”和“付款已过账”。这些活动构成了所发现的流程图中的各个节点。 分析活动的顺序和频率是流程挖掘的核心。此属性有助于识别最常见的流程路径,发现偏离标准程序的异常情况,并深入了解收入周期的运营流向。 为何重要 它定义了流程中的步骤,支持流程图的可视化呈现和工作流模式的分析。 获取方式 通常源自事件日志、状态变更记录或与 Oracle Health 收入周期不同阶段关联的特定事务表。 示例 理赔已生成收到汇款拒付已申诉账户已关闭 | |||
| 计费事件 BillingEvent | 产生费用的单个服务或产品交付的唯一标识符,用作收入周期流程的 case 标识符。 | ||
| 描述 Billing Event 作为主要的 case 标识符,将单个计费项目从费用捕获到结账的所有活动关联起来。每个 Billing Event 代表收入周期流程的一个唯一实例,支持对其在索赔提交、付款过账以及潜在拒付或调整等各个阶段的历程进行全面追踪。 在流程挖掘分析中,此属性是重建端到端流程流的基础。通过它,可以实现流程变体可视化、计算活动间的周期时间,并识别与特定计费事件相关的瓶颈或偏差。 为何重要 这是追踪计费服务全生命周期的核心键,支持所有的流程流分析和性能评估。 获取方式 此标识符应为 Oracle Health Revenue Cycle 核心计费或费用事务表中的唯一键。请咨询系统文档以确定费用事件的主键。 示例 BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| 付款方名称 PayerName | 负责付款的保险公司或第三方付款方的名称。 | ||
| 描述 此属性标识接受服务计费的实体,例如保险公司或像 Medicare 这样的政府项目。付款方信息是收入周期分析的基础。 按付款方分析流程可以揭示支付时间、拒付率和申诉成功率方面的显著差异。这有助于识别导致延迟或收入损失的问题付款方,对于有效管理付款方合同和关系至关重要。 为何重要 支持按支付方对流程进行细分,揭示不同的行为模式、拒付率和回款速度,这对于评估财务绩效至关重要。 获取方式 此信息存储在 Oracle Health Revenue Cycle 的患者计费或保险记录中。 示例 AetnaBlue Cross Blue Shield联合健康保险 (UnitedHealthcare)Medicare (联邦医保)Cigna | |||
| 患者类别 PatientClass | 患者就诊的分类,例如:住院或门诊。 | ||
| 描述 此属性对产生费用的患者就诊或接触类型进行分类。常见分类包括住院、门诊、急诊和复诊。患者类别通常决定了整个计费和索赔提交流程。 不同的患者类别遵循不同的流程路径,且合规要求各异。基于此属性分析流程有助于理解这些差异,定制针对性的改进方案,并确保每个类别的操作都符合正确程序。 为何重要 区分不同的流程流(例如:住院 vs 门诊),这些流程在复杂度、时间线和计费要求方面存在显著差异。 获取方式 这是 Oracle Health 中与患者就诊或入院记录关联的标准字段。 示例 住院患者门诊紧急周期性/经常性 | |||
| 拒付原因代码 DenialReasonCode | 表示支付方拒绝理赔原因的标准代码。 | ||
| 描述 当付款方拒绝索赔时,他们会提供说明原因的代码,例如“不在承保范围内”或“重复索赔”。此属性捕获该代码及其关联描述。 分析拒付原因是改进收入周期的基础。它允许组织识别常见模式(如编码或患者资格问题),并实施纠正措施以防止未来再次发生拒付。这直接影响净索赔率并降低返工成本。 为何重要 提供理赔被拒的根本原因,从而实现针对性改进,提高一次性通过率并加速收入回笼。 获取方式 此信息接收自付款方的电子汇款通知(ANSI 835 文件),应存储在 Oracle Health 的索赔或汇款表中。 示例 CO-16:理赔/服务缺少裁定所需的信息。PR-96:非承保费用。CO-18:重复的理赔/服务。 | |||
| 未结余额 OutstandingBalance | 特定时间点该计费事件剩余的未付余额。 | ||
| 描述 此属性显示在应用所有付款和调整后,计费事件当前欠下的未结金额。它代表了该特定费用的活跃应收账款。 这是“未结余额账龄”仪表板的关键属性。通过随时间分析该值,有助于监控现金流速度,评估催收工作的有效性,并计算关键财务 KPI(如应收账款周转天数 DSO)。 为何重要 追踪每个 case 的当前应收账款,这对于管理现金流和分析催收有效性必不可少。 获取方式 此值通常根据给定计费事件的所有财务交易(费用、付款、调整)总和计算得出。它可能作为账户摘要表中的一个字段存在。 示例 75.000.00550.80 | |||
| 用户 UserPerformingAction | 执行该活动的人员的用户 ID 或姓名。 | ||
| 描述 此属性识别负责执行流程中特定活动的员工或自动系统用户。这对于了解工作负载分布、资源绩效以及识别培训需求至关重要。 在分析中,此属性允许按用户或团队筛选流程图,比较不同资源的绩效,并为“计费部门工作负载”仪表板分析工作量。它可以帮助识别表现优异者或可能需要额外支持或培训的人员。 为何重要 将流程活动关联到特定用户或团队,支持工作量分析、绩效对比以及培训机会的识别。 获取方式 用户 ID 字段(例如“CREATED_BY”、“USER_ID”)通常存在于 Oracle Health 各个模块的事务表中。 示例 j.doeasmithBillingBot_AUTOk.williams | |||
| 调整金额 AdjustmentAmount | 账户余额进行的任何调整金额。 | ||
| 描述 此属性捕获应用于计费事件的任何财务调整金额,例如合同折让、核销或修正。调整会直接减少该笔费用的预期收入。 “账户调整影响”仪表板(Dashboard)高度依赖此属性。分析调整金额及其关联原因有助于识别收入流失的来源、合同管理中的问题或初始费用捕获流程中的漏洞。它是衡量财务健康状况的关键指标。 为何重要 量化因核销或修正导致的收入流失,有助于识别并解决财务侵蚀的根本原因。 获取方式 存在于记录患者账户调整或核销的财务交易表中。 示例 -50.25-120.0025.00 | |||
| 财务部 BillingDepartment | 负责该活动的部门或职能团队。 | ||
| 描述 此属性指定执行该活动的部门,例如“费用捕获”、“编码”或“催收”。它为流程流提供了组织架构背景。 从部门视角分析流程对于理解团队间的交接和识别跨职能低效环节至关重要。它支持“计费部门工作负载”仪表板,允许在部门级别汇总活动和绩效指标。 为何重要 将活动分配给组织单元,这是分析部门间交接、工作量和团队绩效的关键。 获取方式 此信息可能直接存储在 Oracle Health 的用户个人资料数据中,也可能根据用户或活动类型推导得出。 示例 患者准入编码账单催收管理 | |||
| 争议原因 DisputeReason | 客户或患者对发票或费用提出争议时提供的理由。 | ||
| 描述 此属性捕获患者或其他责任方对账单提出争议的原因。原因可能包括计费错误、未提供服务或保险处理问题。 这些信息对于“发票争议解决指标”仪表板至关重要。了解最常见的争议原因有助于识别费用捕获、编码或计费流程中的系统性问题。解决这些根本原因可以显著降低争议率,并减少解决争议所需的行政管理开销。 为何重要 解释发票被质疑的原因,为需要解决的计费准确性或清晰度问题提供直接洞察。 获取方式 这可能存储在 Oracle Health 的案例管理或客户服务模块中,并与患者账户关联。 示例 错误的服务计费重复计费保险计费错误未提供服务 | |||
| 事件结束时间 EventEndTime | (如果可用)标记活动完成的 timestamp。 | ||
| 描述 StartTime 标记活动的开始,而 EventEndTime 标记其结束。并非所有活动都有明确的结束时间,因为许多是瞬时事件。然而,对于有持续时间的活动(例如可能需要时间处理的“拒付申诉”),此字段非常有用。 此属性允许更精确地计算单个活动的处理时间。它有助于区分等待时间(活动之间的时间)和处理时间(在活动上花费的时间)。 为何重要 支持直接计算完成一项活动所需的时间,将处理时间与等待时间分开。 获取方式 Oracle Health Revenue Cycle 中的某些事务表可能包含特定长期任务的开始和结束 timestamp。 示例 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| 最后数据更新 LastDataUpdate | 指示该 event 数据上次刷新或提取时间的 timestamp。 | ||
| 描述 此属性显示数据集的最后更新时间。它提供了所分析数据的时效性背景,这对于理解流程挖掘分析所得见解的及时性至关重要。 用户可以通过查看此属性来确认他们正在浏览最新的流程信息。这有助于管理对数据新鲜度的预期,也是数据治理和质量保证的关键组成部分。 为何重要 指示数据的时效性,确保分析和决策基于最新信息。 获取方式 这是一个元数据字段,通常在将数据加载到流程挖掘平台的 ETL 过程中生成并填充。 示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 处理时间 ProcessingTime | 在一项活动上实际投入工作的时间长度。 | ||
| 描述 此属性衡量某个事件的活跃处理时间,计算方法为开始和结束 timestamp 之间的差值。它有助于区分投入在任务上的实际工作时间与等待下一步处理的空闲时间。 这是绩效分析的关键指标,因为它能将执行任务的人力效率与系统延迟隔离开来。它有助于回答诸如“完成一个索赔编码或过账一笔付款实际需要多久”的问题,而不受该项目在工作队列中停留时长(排队时间)的影响。 为何重要 测量一项活动的实际工作时长,将其与空闲或等待时间区分开,从而更清晰地呈现资源效率。 获取方式 这是一个计算指标,通过 EventEndTime 减去 EventTimestamp 得出。仅当这两个字段都可用时才能计算。 示例 300120045 | |||
| 患者 ID PatientId | 与计费事件关联的患者唯一标识符。 | ||
| 描述 此属性是接受服务的患者的唯一标识符,通常称为病历号 (MRN)。它将财务交易与特定个人关联起来。 虽然 Patient ID 不是该流程的 case ID,但它对于汇总单个患者的所有计费事件以了解其完整的财务历程非常有用。如果结合患者主数据,它还支持基于患者人口统计学信息或历史记录进行细分分析。 为何重要 将财务事件关联到特定患者,支持以患者为中心的分析并汇总其所有的计费活动。 获取方式 此标识符是患者主记录的核心元素,将出现在所有相关的事务表中,如费用、索赔和付款表。 示例 MRN-1002345MRN-1002346MRN-1002347 | |||
| 是否已自动化 IsAutomated | 一个标记,指示该活动是由自动化系统还是人工用户执行的。 | ||
| 描述 此布尔属性用于区分由软件自动化执行的活动(如机器人或系统批处理作业)与由用户手动执行的活动。例如,“生成索赔”可能是一个自动化步骤,而“拒付申诉”则可能是手动的。 分析此属性有助于了解流程的自动化程度及其对效率和错误率的影响。它可以用来比较自动化路径与手动路径的性能,并识别进一步自动化的机会。 为何重要 区分人工活动和系统驱动活动,这对于分析自动化效果和识别新的自动化机会至关重要。 获取方式 这通常根据 UserPerformingAction 属性推导。例如,由“SYSTEM”或“RPA_BOT”等用户 ID 执行的活动将被标记为自动化。 示例 truefalse | |||
| 是否返工 IsRework | 标识代表返工或重复劳动的活动标签。 | ||
| 描述 此计算属性标记那些代表偏离理想“happy path”并构成返工的活动。例如“提交修正后的索赔”或“拒付申诉”,如果流程第一次就完美运行,这些活动本不该发生。 识别并量化返工是流程挖掘的一个核心目标。该标签支持对所有返工循环进行便捷的筛选和分析,有助于衡量流程低效的频率、成本和原因。这对于理解收入周期中真实的质量成本至关重要。 为何重要 有助于量化返工循环的频率和影响,突显流程效率低下和质量低下带来的成本。 获取方式 这是一个派生属性。它在数据转换过程中通过应用业务逻辑计算得出,将特定的活动名称标记为“返工”。 示例 truefalse | |||
| 源系统 SourceSystem | 提取事件数据的来源系统。 | ||
| 描述 此属性标识数据的原始来源应用程序或模块。对于此流程,通常为“Oracle Health Revenue Cycle”,但如果数据集成了多个来源,也可以指定系统内的不同模块。 此信息对于数据治理和故障排除非常有价值。它有助于确认数据谱系,在多个系统共同参与单个端到端流程的环境中尤为重要。 为何重要 提供数据来源的背景信息,这对于数据验证、治理以及理解可能依赖于系统的流程变体至关重要。 获取方式 这通常是在数据提取、转换和加载 (ETL) 过程中添加的静态值,用于标记数据集的来源。 示例 OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| 索赔ID ClaimId | 提交给付款方的保险索赔唯一标识符。 | ||
| 描述 此属性是分配给生成并发送至付款方以获取报销的索赔的唯一 ID。一个计费事件在其生命周期内可能会产生一个或多个索赔(例如在需要修正的情况下)。 使用 Claim ID 可以追踪向付款方提交的特定申请,并将其直接与反馈(如付款或拒付)关联。它在更宏观的收入周期流程中提供了更细粒度的追踪能力。 为何重要 提供特定的标识符来跟踪理赔在支付方的处理历程,这比整体计费事件更细致。 获取方式 此 ID 由 Oracle Health 在创建索赔时生成,并存储在主索赔表中。 示例 CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| 费用金额 ChargeAmount | 计费服务或产品的总金额。 | ||
| 描述 此属性代表在应用任何调整、合同折让或付款之前,为服务收取的初始、未打折金额。它是计费事件的初始财务价值。 追踪费用金额对于财务分析至关重要,例如计算所提供服务的总价值,以及了解后续调整或核销带来的财务影响。它作为衡量收入实现情况的基准。 为何重要 确定 Case 的初始财务价值,这是后续所有财务分析和影响评估的基础。 获取方式 位于 Oracle Health 中的费用明细或费用交易表中。 示例 150.001250.7585.50 | |||
收入周期管理活动
| 活动 | 描述 | ||
|---|---|---|---|
| 付款已过账 | 代表将从支付方收到的付款应用到患者账户的相应费用中。这是由用户或自动化流程记录的财务交易。 | ||
| 为何重要 付款过账的效率直接影响应收账款的准确性。此处的延迟可能会扭曲财务状况并延误二次开票。 获取方式 存在于付款交易表中。每次付款过账都有唯一的交易 ID 和相关的时间戳。 捕获 当付款应用到账户时,记录一笔财务交易。 事件类型 explicit | |||
| 已创建患者就诊 | 标志着针对特定就诊或服务创建患者账户。这通常是由登记系统或入院/出院/转院 (ADT) 馈送触发的明确事件。 | ||
| 为何重要 它作为给定计费事件整个收入周期的起点,支持对总流程时长和登记准确性进行分析。 获取方式 源自患者注册或 ADT 模块日志。请查找就诊创建事件,或与该次就诊/财务编号关联的最早 timestamp。 捕获 在患者登记或入院时记录的事件。 事件类型 explicit | |||
| 理赔已提交至支付方 | 代表将生成的理赔申请以电子或纸质形式提交给保险公司或支付方。系统应记录此次传输的日期和时间。 | ||
| 为何重要 此活动标志着支付周期的开始。分析从提交到付款的时间,是了解付款方绩效和衡量应收账款周转天数(DSO)的关键。 获取方式 源自索赔管理模块,该模块会记录传输事件。请在索赔历史记录中查找提交 timestamp 或状态变更为“已提交”的记录。 捕获 当理赔通过结算中心成功传输时记录的事件。 事件类型 explicit | |||
| 理赔已生成 | 标志着将各项费用汇编成正式理赔申请(如 UB-04 或 CMS-1500)的时间点。这是一个系统生成的创建初始发票的事件。 | ||
| 为何重要 这是一个重要的里程碑,标志着已准备好向付款方开票。它是衡量内部“从计费到开票”滞后期的终点。 获取方式 在理赔生成日志或表中记录的明确事件。请查找与就诊相关的理赔主记录的创建时间戳。 捕获 在创建理赔记录时记录的事件。 事件类型 explicit | |||
| 账户已关闭 | 最后一个活动,表示账户余额归零且后续不再有相关活动。通常在账户余额达到零时推断得出。 | ||
| 为何重要 标志着收入周期的成功完成。达到此状态所需的时间是衡量整体流程效率的关键指标。 获取方式 这通常通过识别账户未结余额在所有付款和调整后首次归零并保持为零的时间点来推断。 捕获 在所有费用和付款过账后,账户余额首次为零时计算。 事件类型 calculated | |||
| 催收活动已启动 | 指示患者账户因未付款而进入催收流程。这通常通过账户财务类别或状态类别的更改来捕获。 | ||
| 为何重要 这是管理坏账的关键步骤。分析导致进入此阶段的原因及其成功率对于财务健康至关重要。 获取方式 通过账户状态字段更改为“催收”或“坏账”来推断。此状态更改应具有相关的时间戳。 捕获 通过账户状态更改为“催收”或类似状态来推断。 事件类型 inferred | |||
| 已提交修正的理赔 | 代表向支付方提交经过修订或修正的理赔申请,通常发生在被拒或要求提供更多信息之后。这可以通过带有修正标识的新理赔提交来识别。 | ||
| 为何重要 此活动是拒付管理返工循环的关键部分。出现频率过高通常意味着初始索赔的准确性存在问题。 获取方式 从理赔提交日志中获取。查找现有就诊的新提交记录,通常标有重新提交代码或更高的迭代次数。 捕获 理赔重新提交的记录事件,通常可通过特定的理赔频率类型代码进行识别。 事件类型 explicit | |||
| 患者账单已发送 | 标志着生成并向患者发送剩余自付部分账单的事件。这是由患者计费模块记录的明确操作。 | ||
| 为何重要 这开启了收入周期中的患者自付部分。追踪此环节有助于分析患者催收的有效性。 获取方式 数据源自患者账单或通信日志。系统应记录每份对账单生成或寄出的日期。 捕获 当生成患者账单并打印或以电子方式发送时记录的事件。 事件类型 explicit | |||
| 拒付已申诉 | 指示正在对被拒理赔进行申诉的用户或系统操作。这通常表现为状态更新或在工作队列中创建的特定任务。 | ||
| 为何重要 此活动会引发返工循环(rework loop)。分析申诉的频率和成功率对于优化收入回收工作至关重要。 获取方式 这可以是一个明确的用户启动事件,也可以从索赔的状态变更中推断得出,例如“已申诉”或“审核中”。 捕获 用户针对被拒理赔启动申诉流程时的状态更改或记录事件。 事件类型 explicit | |||
| 收到拒付 | 标志着支付方拒绝理赔或特定明细项的事件(如汇款通知所示)。此事件通常从汇款数据中存在的拒付代码推断而来。 | ||
| 为何重要 追踪拒付对于识别编码错误或资格问题等根本原因至关重要,有助于提高“净索赔率”(clean claim rate)。 获取方式 通过汇款 (ERA/835) 数据推断。当理赔或明细项具有非零拒付金额和相应的拒付原因代码时,将触发此事件。 捕获 通过包含拒付原因代码 (CARC/RARC) 的汇款数据推断。 事件类型 inferred | |||
| 收到汇款 | 指示收到支付方的电子汇款通知 (ERA) 或纸质福利说明 (EOB)。该文档详细列出了哪些费用已支付、被拒或已调整。 | ||
| 为何重要 这是付款方的第一份反馈,对于了解回款速度和及早识别拒付趋势至关重要。 获取方式 记录在汇款处理模块中。查找与理赔关联的 ERA 文件(如 835 交易文件)的导入或创建时间戳。 捕获 在导入和处理支付方的汇款文件(例如 ANSI 835)时记录的事件。 事件类型 explicit | |||
| 账户已调整 | 代表对账户余额进行的财务调整,例如合同折让、核销或折扣。每次调整都是一笔独立的财务交易。 | ||
| 为何重要 调整直接影响收入。分析调整的频率、类型和金额有助于识别收入流失和计费不准确的问题。 获取方式 存在于财务交易表中。每次调整都记录为一个独立的明细项,并带有特定的交易代码和时间戳。 捕获 记录一笔带有特定调整代码的财务交易。 事件类型 explicit | |||
| 费用已捕获 | 代表将计费服务或项目录入患者账户。这可以从临床系统自动发生,也可以由工作人员手动录入。 | ||
| 为何重要 此活动对于测量“费用滞后期”(即服务交付与启动计费之间的时间差)至关重要,它直接影响现金流和收入完整性。 获取方式 从费用交易表中获取,通过每个费用明细行的创建时间戳进行识别。在 Oracle Health 中,这通常存在于费用相关表中。 捕获 为每笔新费用创建的事务日志条目。 事件类型 explicit | |||
| 费用已编码 | 代表医疗编码员为捕获的费用分配标准代码(如 CPT 或 ICD-10)的过程。这通常通过费用或就诊的状态更改来跟踪。 | ||
| 为何重要 编码延迟是一个常见的瓶颈。跟踪此活动有助于识别编码工作流中的低效环节及其对计费时间线的影响。 获取方式 通常从患者就诊或费用批次的状态更改中推断,例如从“未编码”更改为“已编码”。此状态更改需要对应的时间戳。 捕获 通过就诊或费用状态更改为“已编码”或“待计费”来推断。 事件类型 inferred | |||
提取指南
步骤
- 申请数据库访问权限: 获取 Oracle Health 收入周期数据库的只读凭据。您需要访问包含患者、就诊、计费和财务交易数据的 schema。这通常需要 IT 安全和数据库管理团队的批准。
- 确定 Schema 和表名: 与数据库管理员或系统分析师合作,确认 Oracle Health 实例的准确 schema 和表名。查询中提供的名称是通用占位符,必须映射到您的具体环境。
- 安装 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 数据库 schema 中的实际名称。例如,
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;