您的收入周期管理 data 模板

R1 RCM
您的收入周期管理 data 模板

您的收入周期管理 data 模板

此 data 模板为收集分析收入周期管理流程所需的信息提供了清晰的路线图。它概述了您应该收集的核心 attribute 以及需要追踪的关键 activity。您还将找到如何从 R1 RCM 系统中提取这些 data 的指导,帮助您为高效的 Process Mining 举措做好准备。
  • 建议收集的属性
  • 用于流程发现的关键跟踪活动
  • 针对 R1 RCM 的详细导出指南
不熟悉事件日志?了解 如何创建流程挖掘事件日志.

收入周期管理 Attribute

这些是推荐包含在 event log 中的 data 字段,用于对收入周期管理流程进行全面分析。
5 必填 6 推荐 8 可选
名称 描述
Event 时间
EventTime
指示特定活动或事件发生时间的时间戳。
描述

Event Time(事件时间)提供了活动在系统中记录的精确日期和时间。这一时间信息是进行基于时间的流程分析的基础。

在流程挖掘中,此时间戳用于按时间顺序排列事件,并计算活动之间的持续时间,这对于绩效分析至关重要。通过它,您可以计算出周期时间、处理时间和等待时间等关键指标,这些指标对于识别瓶颈和衡量效率必不可少。

为何重要

此 timestamp 是所有时间相关分析的基础,包括计算周期时间、识别瓶颈以及对照 SLA 监控流程性能。

获取方式

通常作为与 R1 RCM 中每笔交易或状态变更记录关联的“创建日期”、“Timestamp”或“最后更新日期”字段出现。

示例
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z
活动名称
ActivityName
在收入周期流程中的某个时间点发生的特定业务 event 或任务的名称。
描述

此 attribute 描述了给定计费 event 在收入周期管理流程中的单个步骤或里程碑。Activity 代表正在进行的工作,如“收费已捕获”、“报销单已提交”或“付款已入账”。

分析 Activity 序列是 Process Mining 的核心。它能够发现实际流程流向,识别 Activity 启动过慢的瓶颈,并检测不必要的重复 Activity(如“报销被拒”后紧跟“启动拒付返工”)构成的返工循环。

为何重要

它定义了流程中的步骤,支持流程图的可视化、转换时间的计算,以及流程偏差和返工的识别。

获取方式

此信息通常源自各种 R1 RCM 模块中的 event log、状态变更记录或交易代码。可能需要将技术代码映射为更易懂的业务名称。

示例
费用已捕获索赔已提交收到付款方审定结果付款已过账账户已关闭
计费事件
BillingEvent
单个计费服务或项目的唯一标识符,作为追踪整个收入周期的主要 case 标识符。
描述

计费 Event ID 代表导致收费的服务或产品交付的具体实例。它是连接所有相关 Activity 的核心线索,从最初的服务交付和收费捕获,到报销提交、付款入账,直至最终销账。

在 Process Mining 中,分析每个计费 Event 的生命周期可以全面审视端到端收入周期。它用于追踪单笔收费的完整路径、识别常用路径、衡量关键里程碑之间的周期时间,并理解导致延迟或收入流失的偏差情况。

为何重要

此标识符对于将所有相关 activity 分组到单个 case 中至关重要,从而能对每个计费 event 的收入周期进行完整且准确的流程分析。

获取方式

这是链接与患者就诊、收费、报销和付款相关的各种表的主键。请查阅 R1 RCM 文档以获取特定字段,该字段通常与就诊或报销标识符相关。

示例
BE-2023-0012345BE-2023-0054321BE-2024-0098765
最后数据更新
LastDataUpdate
此属性指示data最后一次从Salesforce Financial Services Cloud提取的日期和时间,为分析数据“新鲜度”提供背景。这对于dashboard用户理解分析时效性至关重要,有助管理数据及时性预期,并验证data pipelines是否按计划运行。
描述

此 attribute 指明 Process Mining 分析 data 的最后更新时间。它提供了所分析 data 新鲜度的背景信息。

此信息对于报告和仪表板非常重要,因为它告诉用户流程洞察的实时程度。它有助于管理对 data 及时性的预期,并确保决策是基于已知的时间范围做出的。

为何重要

提供关于 data 新鲜度的关键背景信息,确保分析师和利益相关者了解流程洞察的实时程度。

获取方式

此 timestamp 在 data 提取、转换和加载 (ETL) 过程中生成,通常应用于整个数据集。

示例
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
源系统
SourceSystem
提取事件数据的记录系统。
描述

此 attribute 识别为特定 event 生成 data 的源应用程序或模块。在医疗保健等复杂环境中,data 可能来自 EMR、计费模块、报销结算中心或催收平台。

了解源系统对于 data 验证以及分析可能针对某些系统的流程变动至关重要。它有助于排查 data 不一致问题,并了解流程的技术架构。

为何重要

识别数据来源,这对于数据治理、验证以及理解不同系统在端到端流程中如何交互至关重要。

获取方式

这通常是在 data 提取过程中添加的静态值,用于识别 data 来源的系统(例如“R1 RCM”)。

示例
R1 RCMCernerEpic
付款方名称
PayerName
负责付款的保险公司、政府实体或患者的名称。
描述

此 attribute 识别报销单的主要付款方。这可以是像 Aetna 这样的商业保险公司、像 Medicare 这样的政府付款方,或者是自付部分的患者本人。

按付款方分析流程是收入周期管理的基础。它可以揭示某些付款方是否具有更高的拒付率、更长的支付周期或更复杂的提交要求。这些洞察使组织能够量身定制其流程和资源,以有效管理特定付款方的行为。

为何重要

支持按付款方对流程进行细分,以识别特定付款方的延迟、拒付模式或支付行为,这对于优化收入至关重要。

获取方式

可在 R1 RCM 中与索赔关联的患者保险或统计信息中找到。

示例
Medicare (联邦医保)UnitedHealthcareBlue Cross Blue ShieldAetna自费
发票状态
InvoiceStatus
发票或报销单在其生命周期中的当前状态。
描述

此 attribute 指明计费 event 的最后已知状态,如“已提交”、“已支付”、“已拒付”或“催收中”。它提供了发票在给定时间内所处流程位置的快照。

发票状态对于创建账龄报告和监控应收账款健康状况至关重要。在 Process Mining 中,它可用于过滤停留在特定状态的 case,或分析不同流程变体的结果,例如对比“已支付”与“已拒付”报销单的路径。

为何重要

提供每个 case 的当前状态视图,这对于生成账龄报告以及分析不同流程路径的最终结果至关重要。

获取方式

这通常是 R1 RCM 中主报销单或账户记录上的状态字段。

示例
待提交已提交至付款方已拒绝已全额支付催收中
发票金额
InvoiceAmount
发票或报销单上的总计费金额。
描述

此 attribute 代表给定计费 event 中所提供服务的总计费金额。它反映了报销申请的预期收入。

分析发票金额对于财务 Process Mining 至关重要。它允许优先处理高价值报销,理解流程延迟或拒付带来的财务影响,并基于价值对流程进行细分。例如,分析可能会显示超过一定金额的报销单会进入不同的、更多人工参与的流程路径。

为何重要

为流程提供财务背景,从而分析流程变动对收入的影响,并帮助优先改进高价值 case。

获取方式

位于 R1 RCM 的主索赔或发票表头中,通常名为 'TotalBilledAmount' 或类似名称。

示例
150.002500.7585.5012000.00
拒付原因代码
DenialReasonCode
来自付款方的标准化代码,用于解释索赔被拒的原因。
描述

当付款方拒绝报销申请时,他们会提供一个原因代码,例如 CARC(报销调整原因代码),用以解释该决定。这些代码是标准化的,指示诸如“服务未涵盖”或“重复报销”等问题。

此 attribute 对于拒付管理极其重要。通过分析不同拒付原因代码的频率,组织可以识别并解决拒付的根因,无论它们是与患者资格、编码错误还是缺乏医疗必要性有关。这直接支持了减少返工和加速现金流的工作。

为何重要

提供报销拒付的具体原因,从而进行根因分析以减少未来的拒付、降低返工率并提升首检通过率。

获取方式

此信息从付款方的电子汇款通知(ERA 或 835 文件)中接收,并存储在 R1 RCM 的报销管理模块中。

示例
CO-16:索赔/服务缺少审定所需的信息。PR-97:此项服务的福利已包含在另一项服务的付款/津贴中。CO-22:根据福利协调,此医疗服务可能由另一付款方承担。OA-18:索赔/服务完全重复。
被分配用户
AssignedUser
执行该活动员工的用户 ID 或姓名。
描述

此 attribute 识别负责执行流程中特定任务的人员。这可以是创建报销单的计费员、处理拒付返工的分析师,或执行付款入账的专员。

按用户分析有助于了解工作量分配、个人绩效和培训需求。它可以突出哪些用户效率最高,或者哪些用户可能与较高的错误率相关,从而实现针对性的管理和流程改进。

为何重要

支持分析团队及个人绩效、工作量分布,并有助于识别培训机会或特定用户的流程偏差。

获取方式

通常在 R1 RCM 交易日志中作为“UserID”、“Processor”或“UpdatedBy”字段出现。

示例
jdoeasmithp.jonesBOT_RPA01
财务部
BillingDepartment
负责执行该活动的部门或职能团队。
描述

此 attribute 指定了执行特定流程步骤的组织单元,如“收费录入”、“报销提交”或“拒付管理”。它有助于理解工作如何在不同团队之间交接。

这对于分析部门吞吐量和识别跨部门瓶颈至关重要。通过按部门过滤流程图,组织可以看到哪些交接是顺畅的,哪些地方出现了延迟,从而支持资源分配和组织流程优化。

为何重要

支持按组织单元分析流程绩效,有助于识别特定团队的瓶颈、资源限制或最佳实践。

获取方式

这可能源自 R1 RCM 中的用户配置文件,或作为“部门代码”存储在交易 data 中。

示例
费用捕获理赔管理拒付与申诉付款入账
催收结果
CollectionOutcome
未结余额催收 Activity 的最终结果。
描述

此 attribute 描述了逾期账款催收工作的分析结果。可能的结果包括“全额支付”、“已结案”、“转入坏账”或“未解决”。

追踪催收结果对于评估催收流程的有效性至关重要。通过分析哪些 Activity 导致了哪些结果,组织可以优化催收策略、提升回收率,并就何时停止催收努力和核销余额做出明智决策。这为“催收 Activity 绩效”仪表板提供了支持。

为何重要

通过追踪逾期账户的最终解决情况来衡量催收流程的有效性,有助于优化催收策略。

获取方式

这通常是患者账户上的状态字段,或处于 R1 RCM 内部专门的催收模块中。

示例
已全额支付以较低金额结案已发送至外部机构已作为坏账核销
患者 ID
PatientId
接受服务患者的唯一标识符。
描述

此 attribute 是医疗系统中分配给患者的唯一 ID,通常称为病历号 (MRN)。

虽然个人患者护理不是重点,但患者 ID 可用于分析同一患者随时间推移反复出现的计费问题。如果与其他患者 data 关联,它还可以帮助按患者人口统计特征或历史记录对流程进行细分,从而发现影响特定患者群体的系统性问题。

为何重要

支持在患者层面分析计费事件,有助于识别特定患者在多次就诊中反复出现的问题或模式。

获取方式

此标识符是与 R1 RCM 中每次就诊和报销关联的患者人口统计 data 的核心部分。

示例
MRN837262MRN937281MRN103847
是否已自动化
IsAutomated
一个用于指示该活动是由自动化系统还是人工执行的标记。
描述

此布尔值 attribute 区分了由软件自动化执行的任务(如用于报销提交的 RPA 机器人)与由员工手动执行的任务。

分析此 attribute 是理解自动化举措影响和有效性的关键。它允许对比自动化流程与手动流程的速度、成本和错误率,帮助识别新的自动化机会并衡量现有机器人的 ROI。

为何重要

区分人工活动与系统驱动的活动,这对于衡量自动化对流程效率、成本和质量的影响至关重要。

获取方式

这可以从“AssignedUser”字段中推导出来,其中特定的用户 ID 被预留给机器人(例如“BOT_RPA01”)。或者,某些系统有专门的字段来标记自动化交易。

示例
truefalse
是否返工
IsRework
一个计算出的标记,用于识别属于返工循环一部分的活动,例如重新提交被拒的索赔。
描述

此 attribute 是一个布尔值标签,通常在 Process Mining 分析期间计算。如果某个 activity 是前一步骤的重复,或是表示错误修正序列的一部分(例如“报销被拒”后的任何 activity),它将变为“true”。

识别返工是 Process Mining 最强大的功能之一。它量化了流程中浪费的精力、时间和资源。通过标记返工,组织可以将改进重点放在从源头防止导致返工的错误上,从而实现显著的效率提升。

为何重要

有助于量化返工(如索赔拒付)的频率和影响,从而进行针对性分析,减少低效和无效劳动。

获取方式

这不是源系统中的字段。它是 Process Mining 工具基于 activity 序列计算得出的,例如检测同一个 case 何时发生了多次“报销单已提交”activity。

示例
truefalse
服务代码
ServiceCode
所提供特定服务或程序的计费代码,例如 CPT 或 HCPCS 代码。
描述

服务代码(如 CPT 代码)是标准化的医学代码,用于向付款方报告医疗、手术和诊断程序及服务以获取报销。

按服务代码分析流程对于识别与特定护理类型相关的计费问题至关重要。它能突出显示哪些程序最常被拒付、支付周期最长或需要最多返工,从而针对编码和计费实践进行目标明确的改进。

为何重要

支持基于所提供的服务类型进行流程分析,这是识别与特定手术/流程相关的拒付模式或支付延迟的关键。

获取方式

此信息位于 R1 RCM 内每笔收费或报销单的项目级别。

示例
992139928573560
服务到付款周期时间
ServiceToPaymentCycleTime
从提供服务到最终付款入账的总计算时长。
描述

此指标衡量单次计费 event 收入周期的端到端时长。它代表了组织将提供的服务转化为现金所需的总时间。

这是衡量财务健康状况的关键绩效指标 (KPI)。分析这一时长有助于识别流程加速的主要领域。通过将周期时间分解为各个组成部分(如“计费用时”和“付款用时”),组织可以精准定位改善现金流的最大机会。

为何重要

这是一个关键的高层 KPI,用于衡量现金转换周期的整体效率,直接影响组织的现金流。

获取方式

这是一个计算指标。它是给定计费 Event 中“服务已交付”activity 的 timestamp 与“付款已入账”activity 的 timestamp 之间的时间差。

示例
35 天 8 小时92 天 4 小时15 天 12 小时
调整原因
AdjustmentReason
提供财务调整的原因,例如“合同津贴”或“坏账注销”。
描述

此 attribute 提供了对账户进行财务调整的原因背景。原因通常是分类调整类型的标准化代码或描述。

分析调整原因有助于诊断收入流失的根因。例如,高频出现的“小额余额注销”可能表明小额催收流程效率低下,而频繁的“合同津贴”则是付款方谈判中的预期部分。此分析为“计费调整与合规审计”仪表板提供了支持。

为何重要

解释收入调整背后的“原因”,有助于识别收入损失的根源,如合同问题、计费错误或催收失败。

获取方式

这通常是 R1 RCM 中与 AdjustmentAmount 位于同一交易记录中的代码或文本字段。

示例
合同允许限额坏账核销小额余额核销计费错误修正
调整金额
AdjustmentAmount
对账户余额进行调整的货币价值。
描述

此 attribute 捕获初始计费后对患者账户进行的任何财务调整价值。调整可以是正向或负向的,包括合同津贴、注销或修正。

追踪调整金额对于理解收入完整性至关重要。高水平的负向调整可能预示着由于收费捕获错误或无法收回的债务而导致的收入流失。分析这些 data 有助于识别计费错误和催收低效带来的财务影响。

为何重要

量化收入流失和财务修正,帮助精准定位计费不准、合同义务或坏账带来的金额影响。

获取方式

可在 R1 RCM 中与账户调整或支付入账相关的交易日志中找到。

示例
-50.2520.00-1200.00
必填 推荐 可选

收入周期管理 Activity

这些是应在 event log 中捕获的关键流程步骤和里程碑,以便在收入周期管理中进行准确的流程发现。
6 推荐 8 可选
活动 描述
付款已过账
收到的付款正式入账至患者账户,减少未结余额。这是将付款与已计费服务进行核对的最后一步。
为何重要

此 Activity 为计算“服务到付款”和“付款入账”周期时间提供了终点。它确认了收入已确认且账户已准确更新。

获取方式

这记录在 R1 RCM 患者账务模块中的一笔明确财务交易。每笔入账都包含日期、金额和来源。

捕获

当用户或自动化流程执行付款时,记录为带有入账日期的特定交易。

事件类型 explicit
已收到付款
收到来自付款方或患者的款项。此事件标志着资金到账,但资金尚未分摊到具体的账户或服务项目中。
为何重要

代表现金流入。“收到付款”与“付款入账”之间的时间间隔是了解后台效率和现金对账延迟的关键指标。

获取方式

捕获自付款方的电子汇款文件或患者支付处理记录。该事件对应存款日期或文件接收日期。

捕获

根据 ERA 文件的付款生效日期或患者支付的交易日期记录。

事件类型 explicit
服务已提供
代表为患者完成计费服务或程序的时点。此 event 通常从临床或排班系统中获取,并作为收入周期的触发点。
为何重要

这是“服务到付款”周期时间 KPI 的起点。分析自此 event 开始的时间有助于识别收入周期前端的延迟。

获取方式

通常源自与 R1 RCM 集成的电子健康档案 (EHR) 或执业管理系统。它通常根据患者记录中的“服务日期”或“程序已完成”timestamp 推断得出。

捕获

根据与患者就诊关联的“服务日期”时间戳推断。

事件类型 inferred
索赔已提交
生成的报销单以电子方式提交给负责的付款方(如保险公司)。这标志着计费流程中为获得报销而进行的首次外部沟通。
为何重要

一个关键里程碑,标志着付款方报销时钟的开启。追踪此项有助于监控提交积压,并确保符合付款方的及时申报合规要求。

获取方式

当报销单传输至结算中心时,此 event 被记录为一笔明确的交易。系统会记录提交 timestamp 和确认详情。

捕获

当索赔通过清算所发送时,明确记录为带有提交时间戳的交易。

事件类型 explicit
账户已关闭
计费 event 已完全解决,余额归零,账户正式关闭。这标志着该次就诊收入周期的成功完成。
为何重要

这是流程的主要“理想路径”终点 event。衡量销账周期时间有助于确保行政任务高效完成且记录最终定案。

获取方式

当账户余额归零且应用了“已关闭”或“全额支付”的最终状态时,即可推断出此 event。timestamp 取自使余额归零的最后一笔财务交易。

捕获

当账户余额归零并应用“关闭”状态时推断,同时记录最终活动时间戳。

事件类型 inferred
费用已捕获
此 Activity 标志着正式记录患者就诊的所有计费服务、程序和耗材。这是一个关键的 data 录入步骤,将临床活动转化为财务交易。
为何重要

标志着从临床操作到财务操作的交接。它是衡量发票和索赔生成周期时间的起点,有助于识别费用录入积压情况。

获取方式

在 R1 RCM 的费用录入模块中捕获,或通过 EHR 接口接收。该事件通常由特定交易日志或费用记录的创建时间戳标记。

捕获

由计费表中的费用交易记录创建时间戳识别。

事件类型 explicit
催收活动已启动
患者账户已逾期,启动主动催收工作。形式包括自动化催缴函以及转交给催收专员。
为何重要

标志着高成本催收程序的开始。分析这些活动的有效性和周期时间有助于优化坏账追回策略。

获取方式

当账户在 R1 RCM 内部被移入催收工作队列或被分配催收状态代码时,此 event 可能会被记录或通过状态变更推断出来。

捕获

根据账户状态更改为“催收”或“逾期”推断。

事件类型 inferred
已进行账户调整
账户中记录一笔非付款交易以更改余额。这可能包括基于付款方协议的合同调整、小额余额冲销或错误修正。
为何重要

大量的调整可能意味着收费表、合同管理或计费错误方面存在问题。追踪调整对于分析收入完整性至关重要。

获取方式

记录为 R1 RCM 患者账务模块中的特定交易类型。每笔调整都有代码、金额和入账日期。

捕获

记录为独立的调整交易,可通过唯一的交易代码识别。

事件类型 explicit
患者对账单已生成
在保险公司审定后,为患者生成一份对账单,详细列出其需承担的剩余余额。这可能包括共付额(co-pays)、免赔额(deductibles)或非承保服务。
为何重要

此 Activity 开启了收入周期中的患者支付环节。分析其时间和频率对于管理患者催收和现金流至关重要。

获取方式

通常在运行批处理程序以创建、打印或以电子方式发送患者账单时作为记录 event 被捕获。R1 RCM 会记录账单生成的日期。

捕获

在运行生成患者对账单的批处理程序时记录为交易。

事件类型 explicit
拒付返工已开始
用户或自动化工作流开始调查并解决被拒的索赔。这可能涉及更正编码、提交证明文件或对付款方的决定提出上诉。
为何重要

追踪被拒报销单代价昂贵的返工循环起点。衡量此阶段花费的时间是了解拒付管理团队效率的关键。

获取方式

此 event 通常通过 R1 RCM 工作队列或拒付管理模块中被拒报销单的状态变更为“返工进行中”或“审核中”来推断。

捕获

根据拒付管理工作队列中的状态更改,或根据用户对被拒索赔的首次操作推断。

事件类型 inferred
收到付款方审定结果
系统收到付款方关于已提交报销单的回复,通常是电子汇款通知 (ERA) 文件。该回复详细列出了已支付、拒付或调整的内容。
为何重要

此 event 是流程中的一个关键分歧点,决定了下一步是付款入账还是拒付管理。分析这一点有助于了解付款方的行为和付款速度。

获取方式

当 R1 RCM 处理付款方发送的电子汇款文件(如 ANSI 835 文件)时捕获。该事件以文件的处理时间戳为准。

捕获

在摄取并处理电子汇款通知 (ERA/835) 文件时记录。

事件类型 explicit
索赔已创建
系统根据捕获的费用生成正式的计费索赔。这涉及将患者统计信息、保险信息和服务代码汇总为标准化格式。
为何重要

这是外部提交前的关键内部里程碑。此处的延迟可能预示着编码、data 验证或系统配置存在问题,从而减慢整个计费流程。

获取方式

这是 R1 RCM 内部的系统 event。它可能通过计费账户上的状态变更或报销单实体本身的创建 timestamp 来捕获。

捕获

根据状态更改为“索赔单已生成”或索赔记录的创建时间戳推断。

事件类型 inferred
索赔已拒绝
付款方拒绝支付报销申请(全额或特定项目)。获取拒付原因,并启动返工和申诉流程。
为何重要

此 Activity 突出了收入流失和流程低效问题。分析拒付原因是识别根因并提高首检报销通过率的关键。

获取方式

这并非离散 event,而是根据已处理 ERA 文件中的详情推断出的状态。汇款 data 中的特定拒付代码会触发报销单的状态变更。

捕获

根据已处理的 ERA 文件中的拒付代码推断,这些代码会将索赔状态更改为“Denied”(已拒付)。

事件类型 inferred
账户已转入坏账
所有催收努力均已尝试但无果,剩余账户余额被视为无法收回。该余额作为坏账冲销,代表最终的收入损失。
为何重要

这代表了负面的流程结果和直接的收入损失。分析哪些 case 以坏账告终,可以揭示未付账款的模式以及改进催收的机会。

获取方式

这通常是 R1 RCM 中的一笔明确交易,其中未结余额被移至特定的坏账类别,通常由用户或自动化账龄规则触发。

捕获

记录为冲销余额的特定财务交易,通常与转交给外部催收机构相关。

事件类型 explicit
推荐 可选

提取指南

如何从 R1 RCM 获取数据