您的收入周期管理数据模板
您的收入周期管理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 数据提取指南
收入周期管理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 表示特定活动或事件发生时间的时间戳。 | ||
| 说明 事件时间是与每项活动关联的时间戳,记录活动发生的准确日期和时间。此时间数据对于按时间顺序排列每个案例中的事件至关重要。 分析时,事件时间用于计算活动之间的周期时间、衡量案例持续时间,并找出等待时间较长的瓶颈。它是所有基于时间的流程分析和绩效衡量的基础。 重要性 此时间戳对于正确排列事件顺序,以及计算周期时间和瓶颈相关的各项时长指标至关重要。 获取途径 此信息通常与每笔交易或状态变更记录一同存储在Optum360数据库表中。 示例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z | |||
| 活动名称 ActivityName | 收入周期管理流程中发生的具体事件或任务名称。 | ||
| 说明 活动名称用于描述收入周期流程中的一个步骤,例如“已向付款方提交理赔”或“已收到付款”。此属性是流程挖掘的基础,用于定义流程图中的节点。 通过分析活动的顺序和频率,机构可以直观查看实际流程,发现与标准过程的偏差,并找出常见的返工循环。这有助于了解流程低效和合规问题。 重要性 此属性定义流程中的各个步骤,是构建流程图和开展所有流程分析的基础。 获取途径 通常从Optum360运营表中的事件日志、状态变更记录或特定交易代码中提取。 示例 已创建理赔已向付款方提交理赔已收到付款已收到拒付账户已关闭 | |||
| 计费事件 BillingEvent | 为单次服务或产品交付生成费用的唯一标识符,也是主要案例ID。 | ||
| 说明 计费事件是主要案例标识符,用于关联与单次服务或产品交付及其费用相关的所有活动。借助这一标识符,您可以全面追踪每个可计费项目或服务的收入生成和收款生命周期。 在流程挖掘中,按计费事件分析流程,机构可以查看从服务交付到最终付款或账户关闭的完整端到端过程。这有助于识别瓶颈、衡量周期时间,并了解不同理赔或发票的处理方式有何差异。 重要性 这是关联所有相关收入周期活动的关键案例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 | 理赔申请或发票中提交的所有费用总额。 | ||
| 说明 账单金额是已提供服务的总费用,不扣除任何付款、调整或核销金额。它是该账单事件应收账款的初始值。 此属性是流程挖掘财务分析的基础,可用于计算收入调整率等关键KPI,也可按金额对案例进行细分,查看高金额理赔是否采用不同处理方式,或是否比低金额理赔经历更多延误。 重要性 为每个案例提供财务背景,支持按金额分析并计算关键财务KPI。 获取途径 这是Optum360财务表中每条理赔或患者账户记录的标准字段。 示例 150.001250.7585.50 | |||
| 已付款金额 PaidAmount | 付款方和患者为已计费服务支付的总金额。 | ||
| 说明 已付款金额是特定账单事件中记入账户的所有付款总和,代表实际收取的现金,是衡量收入周期成效的主要指标。 在流程分析中,跟踪已付款金额有助于了解现金流和整体财务表现。该指标可用于分析回款速度,并比较账单金额与实收金额,从而发现少付或无法收回的欠款问题。 重要性 代表实际收取的现金,是RCM流程的关键结果指标,也是现金流分析的重要依据。 获取途径 此金额通常存储在付款交易表中,或汇总在Optum360的账户级记录中。 示例 120.001000.500.00 | |||
| 数据上次更新时间 LastDataUpdate | 源系统最近一次刷新或提取数据的时间戳。 | ||
| 说明 此属性记录最近一次从源系统提取数据并加载到流程挖掘工具的日期和时间,可帮助了解所分析数据的新鲜度。 分析人员和业务用户需要了解当前查看的数据是否为最新数据。此信息有助于管理对数据延迟的预期,也是分析项目的重要元数据。 重要性 提供数据新鲜度的重要信息,帮助用户了解分析所用数据的时效性。 获取途径 此时间戳通常由数据提取、转换和加载(ETL)流程生成并存储。 示例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| 是否返工 IsRework | 用于标记某项活动是否属于返工循环,例如拒付管理或申诉。 | ||
| 说明 “是否返工”是一个布尔标记,用于识别被视为非增值返工的活动,例如“开始拒付返工”或“已提交申诉”。这些活动通常发生在流程偏离理想路径时。 此属性有助于量化流程中的返工,这是衡量低效和成本的直接指标。它用于计算“账单错误返工率”KPI,并支持“瓶颈识别与返工循环”仪表板,便于筛选和可视化这些低效循环。 重要性 标记代表返工的活动,帮助量化流程低效,更轻松地衡量并减少浪费。 获取途径 此标记通常根据流程挖掘工具中的业务逻辑生成。例如,“收到拒付”事件之后的任何活动都可以标记为返工。 示例 truefalse | |||
| 服务代码 ServiceCode | 用于标识具体服务的操作代码,例如CPT、HCPCS。 | ||
| 说明 服务代码是标准化医疗代码,用于准确标识向患者提供的操作或服务。这些代码是账单处理所必需的,也是决定报销金额的主要因素。 按服务代码分析流程,可以发现某些操作是否更容易被拒付、需要更多文档,或付款周期更长。这样可以更细致地了解流程问题,并为特定服务类型制定编码和账单政策提供依据。 重要性 支持按医疗服务类型进行分析,发现特定操作相关的拒付或付款延迟规律。 获取途径 此代码是Optum360费用录入和理赔明细记录的基础组成部分。 示例 992137104527447 | |||
| 服务提供者 ServiceProvider | 提供可计费服务的临床医生、部门或机构。 | ||
| 说明 此属性用于识别负责提供服务的具体人员或部门,例如医生、治疗师或医院科室。不同服务提供者的账单处理方式和文档记录习惯可能不同,进而影响收入周期。 按服务提供者分析,有助于定位护理环节产生的费用捕获、编码准确性或文档质量问题,也能发现开展提供者培训或改进流程的机会,确保从一开始就生成准确的理赔申请。 重要性 帮助追溯账单问题的源头,以便有针对性地向临床人员提供反馈和培训,改进费用捕获和文档记录。 获取途径 此信息是Optum360费用或理赔记录的重要组成部分,通常关联提供者主数据。 示例 Emily Carter医生放射科普通外科物理治疗 | |||
| 案例时长 CaseDuration | 从首次活动到最后一次活动的账单事件总周期时间。 | ||
| 说明 案例时长衡量单个账单事件从首次事件到最后一次事件经过的总时间,是评估整体流程效率的关键KPI。 此指标直接支持“RCM端到端周期时间概览”仪表板和“RCM平均周期时间”KPI。持续跟踪该指标,管理层可以了解改进举措对整个收入周期的影响。 重要性 代表流程的端到端周期时间,是衡量整体流程速度和效率的关键KPI。 获取途径 对每个唯一的“BillingEvent”案例ID,用最后一个事件的时间戳减去第一个事件的时间戳即可计算得出。 示例 30天95天45天 | |||
| 源系统 SourceSystem | 记录事件数据的原始系统或应用程序。 | ||
| 说明 此属性用于标识提取特定事件数据的源系统。在复杂的IT环境中,RCM数据可能来自Optum360核心平台、对接的电子健康记录(EHR)系统、清算所或患者门户。 了解源系统有助于验证数据、排查集成问题,并分析由不同系统行为或数据录入方式造成的流程差异。 重要性 标识数据来源,对于数据治理、质量评估以及了解不同系统间的流程差异至关重要。 获取途径 此值可以在数据提取时设为固定值,也可以来自源表中用于标识数据来源的字段。 示例 Optum360EHR接口清算所API患者门户 | |||
| 用户 User | 执行该活动的用户或系统代理的标识符。 | ||
| 说明 用户属性用于识别负责执行某项活动的具体人员、团队或自动化机器人,支持按个人或团队分析绩效。 了解由哪个用户或团队执行了某项操作,有助于评估生产力、质量和标准流程遵循情况,也有助于发现培训需求或表彰表现出色的个人和团队。此外,还可区分人工执行的任务与自动化处理的任务。 重要性 明确流程步骤的责任归属,并支持按个人或团队分析绩效,为资源管理和培训提供依据。 获取途径 Optum360记录的用户ID通常保存在审计日志或交易历史中。 示例 j.doem.smithAutoBillerBots.jones | |||
| 结束时间 EndTime | 表示活动完成时间的时间戳。 | ||
| 说明 结束时间表示活动完成的时间。开始时间表示事件发生的时间,而结束时间则用于计算具有明确处理时长的活动,例如从“已开始处理拒付返工”到返工完成。 在流程分析中,比较活动的开始时间和结束时间,可以计算处理时间。这有助于区分主动工作时间(处理时间)和空闲时间(活动之间的等待时间),从而更细致地了解流程效率。 重要性 可准确计算活动处理时间,帮助区分流程中的主动工作时间和空闲等待时间。 获取途径 对于某些活动,源系统中可能有单独的时间戳字段;对于其他活动,则可能需要根据后续活动的开始时间推断。 示例 2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z | |||
| 账户状态 AccountStatus | 收入周期中账单账户的当前状态。 | ||
| 说明 账户状态显示账单事件在整体流程中的当前进展,例如“等待付款方处理”“已全额付款”或“催收中”。此属性为正在执行的活动提供背景信息。 您可以据此筛选和细分案例,聚焦流程的特定环节。例如,分析所有处于“催收中”状态的账户,有助于了解这一成本较高环节的成因和业务量,并为“催收活动量与驱动因素”仪表板提供支持。 重要性 概述案例的当前状态,支持筛选和分析特定案例群体,例如处于催收阶段的案例。 获取途径 此字段通常是Optum360患者主账户或理赔记录中的汇总字段。 示例 未结等待付款方处理已全额付款催收中已关闭 | |||
收入周期管理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 已向付款方提交理赔 | 系统已通过电子方式将生成的理赔发送给保险付款方进行裁定。理赔提交模块或清算所接口在成功传输后会明确记录此事件。 | ||
| 重要性 这是一个关键节点,标志着付款方响应时间开始计算。追踪此活动有助于衡量理赔提交效率并发现提交延迟。 获取途径 可在理赔交易日志或EDI(电子数据交换)交易表中查找,重点查看837理赔文件的提交记录。请查找“提交时间戳”或“传输日期”字段。 采集 来自EDI 837交易日志的时间戳,用于标记成功提交。 事件类型 explicit | |||
| 已完成付款入账 | 已成功将收到的付款分配至特定患者账户和服务项目。用户或自动化操作会明确记录此事件,以便将付款与未结费用进行核对。 | ||
| 重要性 此活动对于衡量后台现金应用流程的效率至关重要。入账延迟会影响应收账款报告的准确性,并延迟账户结清。 获取途径 可在付款交易表中查找。付款入账操作的交易时间戳即为事件时间。 采集 分配至特定费用的付款交易记录的创建时间戳。 事件类型 explicit | |||
| 已收到付款通知 | 系统已收到付款方发送的电子付款通知(ERA)文件,其中列明付款、调整和拒付信息。系统导入EDI 835文件时会明确记录此事件。 | ||
| 重要性 此活动是一个重要节点,表明付款方已处理理赔。文件内容决定后续操作,例如付款入账或拒付管理。 获取途径 记录在接收ANSI 835文件的EDI交易日志中。时间戳表示系统收到并处理文件的时间。 采集 与导入EDI 835(电子付款通知)文件相关的时间戳。 事件类型 explicit | |||
| 已收到拒付 | 付款方拒绝了某项理赔,相关信息记录在收到的付款通知中。通过解析付款通知数据,查找与理赔项目相关的特定拒付原因代码,可以推断出此事件。 | ||
| 重要性 追踪拒付对于找出收入损失和流程低效的根本原因至关重要。此活动是所有拒付管理和申诉返工循环的起点。 获取途径 根据电子付款通知(EDI 835)数据推断。系统会识别表示拒付的理赔调整原因代码(CARC)。 采集 通过解析EDI 835付款通知数据,检测特定拒付代码(CARC/RARC)来推断。 事件类型 inferred | |||
| 已收到服务数据 | 从电子健康记录(EHR)或其他源系统收到临床服务信息时,计费事件即开始。通常,集成接口成功导入数据后会生成明确的日志条目或交易记录,以记录此事件。 | ||
| 重要性 这是收入周期的主要开始事件。分析从此活动到费用录入所需的时间,对于发现影响整个流程的前端数据延迟至关重要。 获取途径 此事件记录在接口日志或交易表中,这些日志或表用于处理来自EHR等外部系统的患者服务数据。请查找HL7消息时间戳或API调用日志。 采集 从集成日志或交易表中提取数据接收时记录的时间戳。 事件类型 explicit | |||
| 账户已关闭 | 计费事件已完成,账户余额为零,且预计不会再有后续活动。当账户余额归零,且账户状态更新为“已关闭”或类似最终状态时,可推断此事件。 | ||
| 重要性 这是流程的主要结束事件。衡量截至此节点的总周期时间,可以全面了解RCM的整体效率。 获取途径 根据账户余额归零,以及账户状态字段设为“已关闭”“已全额付款”或同等最终状态来推断。 采集 取导致余额归零的最后一笔付款入账时间戳,或状态变为“已关闭”的时间戳,以较晚者为准。 事件类型 inferred | |||
| 已创建理赔 | 系统已生成可计费理赔,并将所有费用、代码和人口统计信息汇总为标准格式。系统会明确记录此事件及相应的创建时间戳。 | ||
| 重要性 此活动标志着流程从费用录入转入正式计费阶段。理赔提交前必须完成此步骤;追踪该活动对于衡量内部处理时间也至关重要。 获取途径 可在理赔表或交易日志中查找。理赔主记录的创建时间戳即为事件时间。 采集 从理赔数据库表中主记录的创建时间戳提取。 事件类型 explicit | |||
| 已向患者发送账单 | 系统已生成账单并发送给患者,列明患者应承担的费用。患者计费模块在创建账单时会明确记录此事件。 | ||
| 重要性 此活动启动收入周期中的患者自付部分。追踪此活动有助于分析患者收款工作的效率和成效。 获取途径 记录在患者通信记录表或账单生成历史表中。时间戳表示账单的创建或发送时间。 采集 来自患者账单生成日志或历史表的时间戳。 事件类型 explicit | |||
| 已完成编码 | 表示医疗编码人员已审核临床文档,并分配相应的CPT、HCPCS和ICD代码。通常,用户或自动编码引擎完成编码任务时会明确记录此事件。 | ||
| 重要性 编码环节经常成为瓶颈,导致理赔提交延迟。追踪此活动有助于衡量编码人员的工作效率,并发现编码队列中的延迟。 获取途径 此事件记录在编码工作流模块中,也可能通过计费事件状态从“待编码”变为“已编码”来识别。使用状态变更或任务完成的时间戳。 采集 用户或系统完成就诊编码时记录的状态更新时间戳或日志条目时间戳。 事件类型 explicit | |||
| 已开始催收 | 由于未付款,患者账户已转入主动催收流程。通常可根据账户财务类别或状态的变更推断此事件。 | ||
| 重要性 此事件标识出需要加强跟进的账户。分析此活动的频率和影响因素,有助于改进前端催收策略。 获取途径 根据账户状态变为“催收中”“坏账”或“已转交催收机构”等情况推断。状态变更日期即为事件时间戳。 采集 账户状态字段变为催收相关值时记录的时间戳。 事件类型 inferred | |||
| 已开始处理拒付返工 | 用户或自动化工作流已开始审核并处理被拒付的理赔。系统可能会明确记录用户操作,也可能根据理赔状态变更推断此事件。 | ||
| 重要性 此活动启动拒付返工循环。衡量从收到拒付到开始返工的时间,有助于发现拒付管理队列中的积压。 获取途径 可在拒付管理或工作队列模块中查找。用户“打开”或“领取”拒付任务时可能会记录明确的时间戳,也可以根据“已拒付”变为“返工中”等状态变更推断。 采集 根据理赔状态变为“返工中”或“审核中”推断,也可依据明确记录的用户操作日志识别。 事件类型 inferred | |||
| 已录入费用 | 将具体的可计费服务和用品正式录入计费系统的环节。此事件由用户或系统明确触发,并生成费用交易记录。 | ||
| 重要性 此活动对于衡量费用延迟至关重要,即服务交付与启动计费之间的时间差。缩短这一延迟可直接加快收入周期。 获取途径 可在费用交易表中查找,表名通常包含费用录入或服务项目等字样。费用记录的创建时间戳即为事件时间。 采集 事件时间为费用主表或费用交易表中记录的创建时间戳。 事件类型 explicit | |||
| 已提交申诉 | 已正式向付款方提交申诉,对被拒付的理赔提出异议。用户在拒付管理或申诉模块中执行此操作时会留下明确记录。 | ||
| 重要性 此活动是收入回收流程中的关键步骤。追踪申诉提交情况及其周期时间,对于了解拒付处理策略的成效至关重要。 获取途径 记录在申诉追踪模块中,也可能作为针对理赔的特定交易类型记录。请查找“申诉日期”或“重新提交日期”字段。 采集 用户记录申诉提交时留下的明确时间戳。 事件类型 explicit | |||
| 已收到付款 | 表示已收到付款方或患者的付款,通常记录在付款通知中。此事件可从电子付款通知文件或手动现金收款日志中明确提取。 | ||
| 重要性 这是现金流分析和衡量付款速度的基础活动,也是启动付款入账流程的触发点。 获取途径 从EDI 835付款通知文件中的付款信息或银行的锁箱文件中提取。通常使用文件中的支票日期或处理日期。 采集 从EDI 835文件的BPR段或银行锁箱数据文件中提取。 事件类型 explicit | |||
| 已调整账户 | 已将合同调整、核销或其他财务更正记入账户。这是一笔明确记录在系统分类账中的财务交易。 | ||
| 重要性 调整会直接影响收入实现。分析调整原因和时间,对于发现收费标准、合同或计费准确性方面的问题至关重要。 获取途径 可在财务交易表中查找,并通过核销或调整对应的特定交易代码识别。交易日期即为事件时间。 采集 财务分类账中带有特定调整代码的条目交易日期。 事件类型 explicit | |||
数据提取指南
此流程的提取方法目前正在验证中。请稍后再查看,或 联系我们 获取帮助。
优化收入周期管理,立即减少延误
与已将周期时间缩短30%的行业管理者一道,改善财务状况。
无需信用卡,几分钟即可完成设置。