您的收入周期管理数据模板
您的收入周期管理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 提取指南
收入周期管理属性
| 名称 | 描述 | ||
|---|---|---|---|
| Event 时间 EventTime | 指示特定活动或事件发生时间的时间戳。 | ||
| 描述 Event Time 是与每个活动关联的 timestamp,记录了其发生的精确日期和时间。该时间 data 对于构建每个 case 的事件时间顺序至关重要。 在分析中,Event Time 用于计算活动间的周期时间、衡量 case 持续时长,并识别花费大量时间等待的瓶颈。它是任何基于时间的流程分析和绩效衡量的基础。 为何重要 此 获取方式 此信息通常与 Optum360 数据库表中的每条交易或状态变更记录一起存储。 示例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z | |||
| 活动名称 ActivityName | 收入周期管理 (RCM) 流程中发生的特定事件或任务的名称。 | ||
| 描述 Activity Name 描述了收入周期流程中的一个步骤,例如“账单已提交给付款方”或“已收到付款”。该属性是 Process Mining 的基础,因为它定义了流程图中的节点。 通过分析活动的顺序和频率,企业可以直观地看到实际流程流向,识别偏离标准程序的行为,并精准定位常见的返工循环。这种分析对于理解流程低效和合规性问题至关重要。 为何重要 此属性定义了流程的各个步骤,构成了流程图的基础,并支持所有基于流的分析。 获取方式 这通常源自 Optum360 运营表中的事件日志、状态变更记录或特定的交易代码。 示例 索赔已创建账单已提交给付款方已收到付款收到拒付账户已结案 | |||
| 账单 Event BillingEvent | 产生费用的单次服务或产品交付的唯一标识符,用作主要 Case ID。 | ||
| 描述 计费事件充当主要的 case 标识符,将与产生费用的单次服务或产品交付相关的所有活动关联起来。这使得企业能够全面跟踪每个独立计费项目或服务的收入生成和回款生命周期。 在 Process Mining 中,按计费事件分析流程可以让组织查看从服务交付到最终付款或账户关闭的完整端到端路径。此视图对于识别瓶颈、测量周期时间以及了解不同理赔或发票处理方式的差异至关重要。 为何重要 这是必不可少的 Case ID,它连接了所有相关的收入周期活动,从而实现完整的端到端流程分析视图。 获取方式 这是连接 Optum360 核心计费和理赔表中记录的主键。有关具体的表名和字段名,请参阅 Optum360 文档。 示例 BE-2023-0012345BE-2023-0012346BE-2023-0012347 | |||
| 付款人 ID PayerId | 负责该理赔的保险公司或付款人的唯一标识符。 | ||
| 描述 付款人 ID 识别特定的保险公司、政府计划(如 Medicare 或 Medicaid)或其他负责支付理赔的实体。每个付款人通常都有自己的一套规则、提交要求和付款行为。 按付款人 ID 分析流程对 RCM 至关重要。它有助于识别哪些付款人的付款周期最长、拒付率最高或上诉流程最复杂。这种洞察力使计费部门能够针对不同付款人制定专门策略,以提高收款速度并减轻行政负担。 为何重要 按付款方对流程进行细分,对于识别哪些付款方导致了延迟或拒付至关重要,从而支持在付款方管理方面进行针对性改进。 获取方式 此信息存储在 Optum360 的每条理赔记录中。有关付款人相关的表名和字段名,请参阅 Optum360 文档。 示例 PAYER-AETNAPAYER-BCBS-MAPAYER-MEDICAREPAYER-UHC | |||
| 患者 ID PatientId | 接受服务的患者的唯一标识符。 | ||
| 描述 患者 ID 是分配给医疗系统中每位患者的唯一标识符。它将多个计费事件关联到同一位患者,从而实现以患者为中心的分析。 通过使用患者 ID,分析师可以调查与特定患者相关的模式,例如频繁再次入院或理赔遭拒的历史。它还支持根据患者人口统计信息或历史记录对流程进行细分,从而为改善患者的财务体验提供重要洞察。 为何重要 支持以患者为中心的分析,有助于了解端到端的财务历程,并识别特定患者群体的模式。 获取方式 该标识符是 Optum360 内患者主数据和交易表中的核心字段。详见 Optum360 文档。 示例 PAT-98765PAT-98766PAT-98767 | |||
| 拒付原因代码 DenialReasonCode | 来自付款方的标准代码,用于解释账单被拒的原因。 | ||
| 描述 当付款人拒绝理赔时,他们会提供拒付原因代码来说明问题,例如“服务未涵盖”或“重复理赔”。这些代码对于理解收入延迟和重做的根本原因至关重要。 分析这些代码使拒付管理团队能够确定工作优先级、识别趋势并采取纠正措施。例如,如果“信息缺失”导致的拒付频率很高,则可能表明理赔创建流程存在问题。此类分析是降低拒付率和加速现金回笼的核心。 为何重要 提供账单拒付的根本原因,支持通过针对性干预防止未来再次发生拒付,并减少代价高昂的返工。 获取方式 此代码包含在从付款人收到的电子汇款通知 (ERA) 文件中,并存储在 Optum360 的理赔管理模块中。 示例 CO-16: 账单/服务缺少信息PR-97: 此项服务的福利已包含在另一项服务/程序的支付/津贴中OA-18: 重复账单/服务 | |||
| 调整金额 AdjustedAmount | 对已计费金额进行的核销、合同调整或更正的货币价值。 | ||
| 描述 调整金额代表了因与付款人达成的合同协议、计费更正或其他核销而预计无法收回的已计费金额。这是收入的直接减少。 该属性对于“收入调整影响”仪表板和“收入调整率”KPI 至关重要。通过分析调整金额,有助于识别付款人合同对财务的影响,并通过提高计费准确性或合同谈判来寻找减少收入流失的机会。 为何重要 直接衡量收入流失情况,对于计算财务绩效 KPI 和了解盈利能力至关重要。 获取方式 此信息可在 Optum360 财务系统的调整交易记录中找到。 示例 30.00250.2510.00 | |||
| 财务部 BillingDepartment | 管理或执行计费活动的内部部门或团队。 | ||
| 描述 计费部门属性用于识别收入周期运营中负责某项活动的特定团队或职能区域。例如,不同的团队可能分别负责编码、理赔提交和拒付管理。 该属性对于“计费部门绩效对标”仪表板所需的绩效对标至关重要。它允许领导层比较不同团队的效率、速度和准确性,识别最佳实践,并有效分配资源以弥补绩效差距。 为何重要 支持在不同账单团队之间进行绩效比较,有助于识别高绩效团队和需要改进的领域。 获取方式 这可能源自执行任务的用户,或者是账户上指示归属权的字段。详见 Optum360 文档。 示例 中央结算办拒付管理小组编码科室患者财务服务 | |||
| 账单金额 BilledAmount | 理赔或发票上提交的所有费用的总货币价值。 | ||
| 描述 计费金额代表所提供服务的总费用(在进行任何支付、调整或销账之前)。它是该账单 event 初始的应收账目价值。 该属性是 Process Mining 财务分析的基础。它用于计算收入调节率等关键 KPI,并允许按价值细分 case,以观察高额账单的处理方式是否有所不同,或者是否比低额账单经历更多延迟。 为何重要 为每个 case 提供财务背景,支持基于价值的分析以及关键财务 KPI 的计算。 获取方式 这是 Optum360 财务表中每个理赔或患者账户的标准字段。 示例 150.001250.7585.50 | |||
| 最后数据更新 LastDataUpdate | 此属性指示data最后一次从Salesforce Financial Services Cloud提取的日期和时间,为分析数据“新鲜度”提供背景。这对于dashboard用户理解分析时效性至关重要,有助管理数据及时性预期,并验证data pipelines是否按计划运行。 | ||
| 描述 该属性记录了数据最后一次从源系统提取并加载到 Process Mining 工具的日期和时间。它提供了有关所分析数据新鲜度的背景信息。 这对于分析师和业务用户了解其查看的是否为最新信息非常重要。它有助于管理对数据延迟的预期,并且是任何分析项目的关键元数据。 为何重要 提供关于 data 新鲜度的关键背景信息,确保用户了解分析的时效性。 获取方式 此 timestamp 通常由数据提取、转换和加载 (ETL) 过程生成并存储。 示例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| 处理时间 ProcessingTime | 完成特定活动所需的时间,根据其开始和结束 timestamp 计算得出。 | ||
| 描述 Processing Time 衡量单个活动的持续时长,代表“接触时间”或实际执行的工作。这通常计算为活动结束时间与开始时间之差。 这一计算指标对于区分实际处理任务的时间与等待下一步的时间至关重要。在瓶颈分析中,了解处理时间有助于确定延迟是由于任务本身耗时过长还是队列过长引起的,从而实现更有效的流程改进。 为何重要 衡量活动的实际“接触时间”,在瓶颈分析中有助于区分增值工作与浪费的等待时间。 获取方式 这是通过从给定活动记录的 'EndTime' 中减去 'EventTime' (StartTime) 计算得出的。 示例 15 minutes2小时1天4小时 | |||
| 已付金额 PaidAmount | 从付款人和患者处收到的已计费服务的总货币价值。 | ||
| 描述 已付金额是针对特定计费事件记入账户的所有款项的累积总和。这代表了实际收取的现金,是衡量收入周期是否成功的主要标准。 在流程分析中,跟踪已付金额对于了解现金流和整体财务表现至关重要。它可用于分析收款速度,并将已计费金额与已收金额进行比较,从而发现少付或坏账等问题。 为何重要 代表实际收集的现金,这是 RCM 流程的关键结果指标,对于现金流分析至关重要。 获取方式 此值通常存储在付款交易表中,或在 Optum360 的账户级别进行汇总。 示例 120.001000.500.00 | |||
| 是否返工 IsRework | 一个标记,用于指示活动是否属于返工循环,例如拒付管理或申诉。 | ||
| 描述 Is Rework 是一个布尔标记,用于识别被视为无增值返工的活动,例如“拒付返工已开始”或“申诉已提交”。这些活动通常发生在流程偏离理想“快乐路径”时。 该属性有助于量化流程中的返工量,这是效率低下和成本增加的直接指标。它用于计算“账单错误返工率”KPI,并为“瓶颈识别与返工循环”仪表板提供支持,从而轻松过滤并可视化这些低效循环。 为何重要 通过标记代表返工的活动,帮助量化流程低效情况,从而更轻松地衡量并针对性减少浪费。 获取方式 这通常是在 Process Mining 工具中使用业务逻辑推导出来的。例如,“收到拒付”事件之后的任何活动都可以被标记为重做。 示例 truefalse | |||
| 服务代码 ServiceCode | 识别所提供特定服务的程序代码(例如 CPT、HCPCS)。 | ||
| 描述 服务代码是标准化的医疗代码,可精确识别向患者提供的程序或服务。这些代码是计费所必需的,也是报销的主要决定因素。 按服务代码分析流程可以发现某些程序更容易遭到拒付、需要更多文档或付款周期更长。这有助于更细致地了解流程中的挑战,并为特定类型服务的编码和计费政策提供参考。 为何重要 支持基于医疗服务类型进行分析,从而揭示特定手术或处置中存在的拒付或付款延迟模式。 获取方式 此代码是 Optum360 中费用输入和理赔明细记录的基本组成部分。 示例 992137104527447 | |||
| 服务提供商 ServiceProvider | 提供可计费服务的临床医生、部门或机构。 | ||
| 描述 该属性标识负责提供服务的特定提供者,例如医生、治疗师或医院部门。不同的提供者可能有不同的计费模式或文档记录习惯,从而影响收入周期。 按服务提供者进行分析有助于发现源于护理点的费用捕获、编码准确性或文档质量问题。它可以为提供者培训或流程改进提供方向,从而确保从源头生成准确无误的理赔申请。 为何重要 支持将计费问题追溯到源头,从而为临床人员提供有针对性的反馈和培训,以改善收费采集和文档记录。 获取方式 此信息是 Optum360 中费用或理赔记录的关键部分,通常关联到提供者主数据。 示例 艾米丽·卡特博士放射科普通外科物理治疗 | |||
| 案例持续时间 CaseDuration | 计费事件的总周期时间,从第一个活动到最后一个活动。 | ||
| 描述 Case Duration 衡量单个账单 event 从第一个 event 到最后一个 event 所经过的总时间。这是评估整体流程效率的关键高阶 KPI。 该指标直接支持“RCM 端到端周期时间概览”仪表板和“平均 RCM 周期时间”KPI。通过长期追踪,管理层可以直观看到优化方案对整个收入周期的影响。 为何重要 代表流程的端到端周期时间,是衡量整体流程速度和效率的关键 KPI。 获取方式 这是通过从每个唯一“计费事件”Case ID 的最后一个事件 timestamp 中减去第一个事件的 timestamp 计算得出的。 示例 30天95 天45天 | |||
| 源系统 SourceSystem | 记录事件数据的原始系统或应用程序。 | ||
| 描述 该属性标识提取特定事件数据的源系统。在复杂的 IT 环境中,RCM 数据可能来自 Optum360 核心平台、对接的电子健康记录 (EHR) 系统、结算中心或患者门户。 了解源系统有助于进行数据验证、排除集成问题,以及分析可能由不同系统行为或数据录入习惯导致的流程差异。 为何重要 识别 data 的来源,这对于 data 治理、质量评估以及理解不同系统间的流程差异至关重要。 获取方式 这可能是在数据提取期间设置的静态值,或者是源表中指示数据来源的字段。 示例 Optum360EHR-InterfaceClearinghouse-APIPatient-Portal | |||
| 用户 User | 执行该活动的执行人或系统代理的标识符。 | ||
| 描述 User 属性识别负责执行特定活动的人员、团队或自动机器人。这允许在个人或团队层面进行绩效分析。 了解哪个用户或团队执行了某项操作对于评估生产力、质量和标准程序的遵守情况非常有价值。它可以帮助识别培训需求,或表彰高绩效个人和团队,同时有助于区分手动任务和自动化处理的任务。 为何重要 明确流程环节的责任归属,支持按个人或团队进行绩效分析,这对于资源管理和员工培训至关重要。 获取方式 用户 ID 通常记录在 Optum360 记录的审核日志或交易历史中。 示例 j.doem.smithAutoBillerBots.jones | |||
| 结束时间 EndTime | 指示活动完成时的时间戳。 | ||
| 描述 End Time 标志着一项活动的完成。虽然 Start Time 表示事件发生的时间,但 End Time 对于计算具有明确处理时间的活动(例如“拒付重做开始”及其完成)的持续时间是必不可少的。 在流程分析中,比较活动的 Start Time 和 End Time 可以计算出处理时间。这有助于区分实际工作时间(处理时间)和空闲时间(活动之间的等待时间),从而提供更详细的流程效率视图。 为何重要 支持计算精确的活动处理时间,有助于区分流程中的实际工作时间和闲置等待时间。 获取方式 对于某些活动,这可能是源系统中的独立 timestamp 字段。对于其他活动,则可能需要根据后续活动的开始时间进行推导。 示例 2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z | |||
| 账户状态 AccountStatus | 收入周期内计费账户的当前状态。 | ||
| 描述 账户状态提供了账单 event 在整个流程中所处位置的快照,例如“等待付款方”、“已付清”或“催收中”。该属性为正在执行的活动提供了背景信息。 这对于过滤和细分 case 以关注流程的特定部分非常有用。例如,分析所有当前处于“催收中”的账户,有助于理解这一高成本环节的驱动因素和规模,为“催收活动量与诱因”仪表板提供支持。 为何重要 提供 case 当前状态的高阶背景信息,支持对特定 case 群体(如催收中的账户)进行过滤和分析。 获取方式 这通常是 Optum360 中主要患者账户或理赔记录上的汇总字段。 示例 未结等待付款方已全额支付催收中已结案 | |||
收入周期管理活动
| 活动 | 描述 | ||
|---|---|---|---|
| 付款已过账 | 收到的款项已成功匹配到特定的患者账户和服务明细。这是一个显式的手动或自动操作,用于核销未付账款。 | ||
| 为何重要 此活动对于衡量后台现金申请流程的效率至关重要。入账延迟可能会扭曲应收账款报告并推迟账户关闭。 获取方式 位于支付交易表中。入账操作的交易 timestamp 即为 event 时间。 捕获 针对特定费用生成的付款交易记录的创建 timestamp。 事件类型 explicit | |||
| 已收到服务数据 | 当从电子健康记录(EHR)或其他源系统收到临床服务信息时,标志着账单 event 的开始。该 event 通常通过集成接口在成功接入 data 时创建的显式日志条目或交易记录来捕获。 | ||
| 为何重要 这是收入周期的主要起始事件。分析从该活动到费用捕获的时间,对于识别影响整个流程的前端数据延迟至关重要。 获取方式 记录在处理来自 EHR 等外部系统的患者服务 data 的接口日志或交易表中。请查找 HL7 消息 timestamp 或 API 调用日志。 捕获 从集成日志或交易表中获取,并在收到 data 时记录 timestamp。 事件类型 explicit | |||
| 收到付款通知书 | 系统已收到来自付款人的电子汇款通知 (ERA) 文件,其中详细列出了付款、调整和拒付情况。这是系统摄入 EDI 835 文件时捕获的明确事件。 | ||
| 为何重要 此活动是一个关键里程碑,表示付款人已处理理赔。该文件的内容决定了随后的所有操作,如付款入账或拒付管理。 获取方式 记录在接收 ANSI 835 文件的 EDI 交易日志中。timestamp 反映了文件被系统接收和处理的时间。 捕获 与摄入 EDI 835(电子汇款通知)文件关联的 timestamp。 事件类型 explicit | |||
| 收到拒付 | 付款方已拒绝账单,这反映在收到的回款通知中。该 event 是通过解析回款通知 data 中与账单明细相关的特定拒付原因代码推导出来的。 | ||
| 为何重要 跟踪拒付对于识别收入损失和流程低效的根本原因至关重要。此活动是所有拒付管理和上诉重做循环的起点。 获取方式 从电子回款通知(EDI 835)data 中推断得出。系统会识别代表拒付的账单调节原因代码(CARC)。 捕获 通过在解析后的 EDI 835 回款 data 中检测特定的拒付代码(CARC/RARC)推断得出。 事件类型 inferred | |||
| 账单已提交给付款方 | 生成的理赔已通过电子方式发送至保险付款人进行裁定。成功传输后,理赔提交模块或结算中心接口会明确记录此事件。 | ||
| 为何重要 这是一个关键里程碑,标志着付款人响应时间的开始。它有助于衡量理赔提交流程的效率并识别提交延迟。 获取方式 位于账单交易日志或 EDI(电子数据交换)交易表中,专门追踪 837 账单文件提交。请查找“提交 timestamp”或“传输日期”。 捕获 来自 EDI 837 交易日志的表示成功提交的 timestamp。 事件类型 explicit | |||
| 账户已结案 | 当账户余额清零且不再预期有进一步活动时,计费事件被视为完成。当账户余额变为零且账户状态更新为“已关闭”或类似的最终状态时,即可推断出该事件。 | ||
| 为何重要 这是该流程的主要结束事件。测量到此为止的总周期时间可提供 RCM 整体效率的全面视图。 获取方式 根据账户余额归零以及账户状态字段设置为“已结案”、“已付清”或同等最终状态推断得出。 捕获 导致余额清零的最终付款入账 timestamp,或状态更改为“已关闭”的最新 timestamp。 事件类型 inferred | |||
| 催收活动已开始 | 由于未付款,患者账户已转入实际催收流程。这通常是根据账户财务类别或状态的变化推断出来的。 | ||
| 为何重要 这识别了需要更密集后续跟进的账户。分析此活动的频率和驱动因素有助于改进前端收款策略。 获取方式 根据账户状态更改为“催收”、“坏账”或“委派代理机构”推断得出。该状态更改的日期即为 event timestamp。 捕获 账户状态字段更改为催收相关值时的 timestamp。 事件类型 inferred | |||
| 已收到付款 | 表示已收到来自付款方或患者的款项,通常记录在回款通知中。该 event 可以从电子回款文件或手动收款日志中显式捕获。 | ||
| 为何重要 这是现金流分析和衡量付款速度的一项基本活动。它充当付款入账流程的触发器。 获取方式 源自 EDI 835 回款文件中的支付信息或银行的信箱文件。通常使用文件中的支票日期或处理日期。 捕获 从 EDI 835 文件的 BPR 段或银行的信箱 data 文件中提取。 事件类型 explicit | |||
| 患者结算单已发送 | 系统已生成账单并发送给患者,以支付其应付部分。这是由患者账单模块在创建报表时记录的显式 event。 | ||
| 为何重要 此活动开启了收入周期中的自费部分。跟踪此活动有助于分析患者收款的效率和成效。 获取方式 记录在患者通信或结算单生成历史表中。timestamp 指示了结算单创建或发送的时间。 捕获 来自患者账单生成日志或历史记录表的 timestamp。 事件类型 explicit | |||
| 拒付返工已开始 | 用户或自动工作流已开始审查和解决拒付账单。这可以通过用户操作显式捕获,或从账单状态更改中推断得出。 | ||
| 为何重要 此活动启动了针对拒付的重做循环。测量从收到拒付到开始重做的时间有助于识别拒付管理队列中的积压情况。 获取方式 位于拒付管理或工作队列模块中。它可以是用户“打开”或“领取”拒付任务时的显式 timestamp,也可以是从“已拒付”到“返工中”等状态更改中推断得出。 捕获 从账单状态更改为“返工”或“审查中”,或通过显式的用户操作日志推断得出。 事件类型 inferred | |||
| 收费已采集 | 代表特定的可计费服务和耗材正式进入计费系统的环节。这是一个创建计费交易记录的显式用户或系统操作。 | ||
| 为何重要 此活动对于测量计费延迟(即服务交付与计费开始之间的延迟)至关重要。减少这种延迟能直接加速收入周期。 获取方式 位于计费交易表中,通常标记为计费输入或服务明细表。计费记录的创建 timestamp 即为 event 时间。 捕获 Event 指的是收费主表或计费交易表中记录的创建 timestamp。 事件类型 explicit | |||
| 申诉已提交 | 已正式向付款方提交申诉,以质疑拒付账单。这是用户在拒付管理或申诉模块中记录的显式操作。 | ||
| 为何重要 此活动是收入回收流程中的关键步骤。跟踪上诉提交及其周期时间对于了解拒付解决策略的有效性至关重要。 获取方式 记录在申诉追踪模块中,或作为账单的特定交易类型记录。请查找“申诉日期”或“重新提交日期”字段。 捕获 当用户记录申诉提交时记录的显式 timestamp。 事件类型 explicit | |||
| 索赔已创建 | 系统已生成可计费账单,将所有费用、编码和人口统计信息汇总为标准格式。这是一个显式的系统生成 event,带有相应的创建 timestamp。 | ||
| 为何重要 此活动标志着从费用捕获到正式计费流程的过渡。它是提交的前提条件,对于跟踪内部处理时间至关重要。 获取方式 位于账单表或交易日志中。账单抬头记录的创建 timestamp 代表该 event。 捕获 从账单数据库主表记录的创建 timestamp 中获取。 事件类型 explicit | |||
| 编码已完成 | 表示医疗编码员已审查临床文档并分配了适当的 CPT、HCPCS 和 ICD 代码。这通常是由用户或自动编码引擎完成编码任务时标记的显式 event。 | ||
| 为何重要 编码是一个常见的瓶颈,可能会延迟账单提交。追踪这一活动有助于衡量编码员的生产率,并识别编码队列中的延迟。 获取方式 记录在编码工作流模块中,或通过账单 event 从“待编码”到“已编码”的状态更改进行记录。使用该状态更改或任务完成的 timestamp。 捕获 当用户或系统完成就诊编码时的状态更新或日志条目的 timestamp。 事件类型 explicit | |||
| 账户已调整 | 账户中已记录合同调整、销账或其他财务更正。这是在系统分类账中记录的显式财务交易。 | ||
| 为何重要 费用调整直接影响收入实现。分析调整的原因和时机是识别收费标准、合同执行或账单准确性问题的关键。 获取方式 位于财务交易表中,可通过特定的销账或调节交易代码识别。交易日期即为 event 时间。 捕获 带有特定调整代码的财务分类账分录的交易日期。 事件类型 explicit | |||
提取指南
该流程的提取方法正在验证中。请稍后回来查看或 联系我们 寻求帮助。