收入周期管理数据模板
收入周期管理数据模板
- 建议收集的属性
- 流程发现需要追踪的关键活动
- R1 RCM数据提取详细指南
收入周期管理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 表示特定活动或事件发生时间的时间戳。 | ||
| 说明 事件时间提供活动记录到系统中的准确日期和时间,是按时间分析流程的基础。 在流程挖掘中,系统会根据此时间戳按时间顺序排列事件,并计算活动之间的持续时间,这对绩效分析至关重要。借此可以计算周期时间、处理时间和等待时间等关键指标,帮助识别瓶颈并衡量效率。 重要性 此时间戳是所有时间相关分析的基础,可用于计算周期时间、识别瓶颈,以及根据SLA监控流程绩效。 获取途径 在R1 RCM中,通常是与每笔交易或状态变更记录关联的“创建日期”“时间戳”或“最后更新日期”字段。 示例 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| 活动名称 ActivityName | 收入周期流程中某个时间点发生的具体业务事件或任务的名称。 | ||
| 说明 此属性描述特定计费事件在收入周期管理流程中的一个步骤或里程碑,例如“已记录费用”“已提交理赔申请”或“已登记付款”。活动反映实际执行的工作。 分析活动顺序是流程挖掘的核心。通过分析,您可以发现实际流程,找出活动启动延迟的瓶颈,并识别不必要的返工循环,例如“理赔申请被拒”后又“开始处理拒赔”。 重要性 此属性定义流程中的步骤,可用于展示流程图、计算转换时间,以及识别流程偏差和返工。 获取途径 此信息通常来自事件日志、状态变更记录或R1 RCM各模块中的交易代码。可能需要将技术代码映射为便于业务人员理解的名称。 示例 费用已记录索赔已提交已收到付款方裁定结果付款已入账账户已关闭 | |||
| 计费事件 BillingEvent | 用于追踪整个收入周期的单项可计费服务或项目的唯一标识,也是主要案例标识。 | ||
| 说明 计费事件ID代表一次独立的服务或产品交付,并由此产生费用。它是串联相关活动的主线,涵盖最初提供服务和记录费用、提交理赔申请、登记付款,直到账户最终关闭。 在流程挖掘中,分析每个计费事件的生命周期,可以全面了解端到端收入周期。您可以追踪单笔费用的完整流程,识别常见路径,衡量关键节点之间的周期时间,并了解导致延迟或收入流失的流程差异。 重要性 此标识用于将所有相关活动归入同一案例,从而能够针对每个可计费事件,对收入周期进行完整、准确的流程分析。 获取途径 这是关联患者就诊、费用、理赔申请和付款等相关表的主键。具体字段请参阅R1 RCM文档,通常与就诊或理赔申请标识相关。 示例 BE-2023-0012345BE-2023-0054321BE-2024-0098765 | |||
| 数据最后更新时间 LastDataUpdate | 源系统最近一次刷新或提取数据的时间戳。 | ||
| 说明 此属性表示流程挖掘分析数据的最近更新时间,可帮助您了解所分析数据的新鲜度。 此信息对于报告和仪表板至关重要,可让用户了解流程洞察的时效性。它有助于管理对数据及时性的预期,并确保决策依据的时间范围明确。 重要性 提供数据时效性的重要信息,让分析人员和相关方了解流程洞察的更新程度。 获取途径 此时间戳在数据提取、转换和加载(ETL)过程中生成,通常应用于整个数据集。 示例 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| 源系统 SourceSystem | 提取事件数据的记录系统。 | ||
| 说明 此属性用于标识生成特定事件数据的源应用或模块。在医疗等复杂环境中,数据可能来自EMR、计费模块、理赔清算平台或催收平台。 了解源系统对于数据验证以及分析特定系统导致的流程差异至关重要。它有助于排查数据不一致问题,并了解流程所涉及的技术环境。 重要性 标识数据来源,对于数据治理、数据验证以及了解不同系统如何在端到端流程中交互至关重要。 获取途径 这通常是在数据提取过程中添加的固定值,用于标识数据来源系统,例如“R1 RCM”。 示例 R1 RCMCernerEpic | |||
| 付款方名称 PayerName | 负责付款的保险公司、政府机构或患者的名称。 | ||
| 说明 此属性用于标识理赔申请的主要付款方,可能是Aetna等商业保险公司、Medicare等政府付款方,也可能是自费部分的患者本人。 按付款方分析流程是收入周期管理的基础。分析可以揭示某些付款方的拒赔率较高、付款周期较长或提交要求更复杂。组织可以据此调整流程和资源,有效应对不同付款方的特点。 重要性 支持按付款方细分流程,识别特定付款方导致的延迟、拒赔模式或付款行为,这对于优化收入至关重要。 获取途径 在R1 RCM中,可从与理赔申请关联的患者保险或人口统计信息中找到。 示例 MedicareUnitedHealthcareBlue Cross Blue ShieldAetna自费 | |||
| 发票状态 InvoiceStatus | 发票或理赔申请在其生命周期中的当前状态。 | ||
| 说明 此属性表示计费事件最近一次记录的状态,例如“已提交”“已付款”“已拒赔”或“催收中”,让您了解发票在特定时间所处的流程阶段。 发票状态对于生成账龄报告和监控应收账款状况至关重要。在流程挖掘中,您可以用它筛选卡在特定状态的案例,或分析不同流程变体的结果,例如比较“已付款”和“已拒赔”理赔申请的流程路径。 重要性 展示每个案例的当前状态,是生成账龄报告和分析不同流程路径最终结果的重要依据。 获取途径 在R1 RCM中,这通常是理赔申请或账户主记录中的状态字段。 示例 待提交已提交至付款方已拒赔已全额付款催收中 | |||
| 发票金额 InvoiceAmount | 发票或理赔申请中费用的总金额。 | ||
| 说明 此属性表示特定计费事件中已提供服务的计费总额,反映理赔申请的预期收入。 分析发票金额对于财务流程挖掘至关重要。您可以据此优先处理高价值理赔申请,了解流程延迟或拒赔造成的财务影响,并按金额划分流程。例如,分析可能发现,超过某一金额的理赔申请会采用不同且更依赖人工的流程路径。 重要性 为流程分析提供财务背景,帮助了解流程差异对收入的影响,并优先呈现需要改进的高价值案例。 获取途径 在R1 RCM的理赔申请或发票主表中,通常名为“TotalBilledAmount”或类似名称。 示例 150.002500.7585.5012000.00 | |||
| 执行用户 AssignedUser | 执行活动的员工用户ID或姓名。 | ||
| 说明 此属性用于标识负责执行流程中特定任务的人员,例如创建理赔申请的计费人员、重新处理拒赔的分析人员或登记付款的专员。 按用户分析有助于了解工作量分配、个人绩效和培训需求。分析结果可以显示哪些用户效率较高,或哪些用户可能与较高的错误率相关,从而支持有针对性的管理和流程改进。 重要性 支持分析团队和个人绩效及工作量分配,并帮助发现培训机会或特定用户相关的流程偏差。 获取途径 在R1 RCM的交易日志中,通常是“UserID”“Processor”或“UpdatedBy”字段。 示例 jdoeasmithp.jonesBOT_RPA01 | |||
| 拒赔原因代码 DenialReasonCode | 付款方用于说明理赔申请被拒原因的标准化代码。 | ||
| 说明 付款方拒绝理赔申请时,会提供原因代码,例如CARC(理赔调整原因代码),说明拒赔决定。此类代码经过标准化,用于表示“服务不在承保范围内”或“重复提交理赔申请”等问题。 此属性对于拒赔管理非常重要。通过分析不同拒赔原因代码的出现频率,组织可以识别并解决拒赔的根本原因,例如患者资格、编码错误或缺乏医疗必要性。这有助于减少返工并加快现金回流。 重要性 提供理赔申请被拒的具体原因,支持根因分析,以减少后续拒赔和返工,并提高首次提交付款率。 获取途径 此信息由付款方通过电子汇款通知(ERA或835文件)发送,并存储在R1 RCM的理赔管理模块中。 示例 CO-16:理赔申请或服务缺少裁定所需的信息。PR-97:此项服务的福利已包含在另一项服务的付款或补贴中。CO-22:根据福利协调规则,此项护理可能由其他付款方承保。OA-18:完全重复的理赔申请或服务。 | |||
| 计费部门 BillingDepartment | 负责执行活动的部门或职能团队。 | ||
| 说明 此属性用于指定执行特定流程步骤的组织单元,例如“费用录入”“理赔申请提交”或“拒赔管理”,帮助了解工作如何在不同团队之间交接。 这对于分析部门处理能力和识别跨职能瓶颈至关重要。按部门筛选流程图后,组织可以查看团队交接是否顺畅、延迟发生在哪里,从而支持资源分配和组织流程优化。 重要性 支持按组织单元分析流程绩效,帮助识别团队特有的瓶颈、资源限制或最佳实践。 获取途径 此信息可能来自R1 RCM中的用户资料,也可能存储在交易数据的“Department Code”字段中。 示例 费用记录索赔管理拒赔与申诉付款入账 | |||
| 催收结果 CollectionOutcome | 对未结余额开展催收活动的最终结果。 | ||
| 说明 此属性描述逾期账户的付款催收结果。可能的结果包括“已全额付款”“已协商结清”“已列为坏账”或“未解决”。 追踪催收结果对于评估催收流程的有效性至关重要。通过分析哪些活动会带来哪些结果,组织可以优化催收策略、提高回收率,并据此决定何时停止催收并核销余额。此属性可为“催收活动绩效”仪表板提供支持。 重要性 通过追踪逾期账户的最终处理结果,衡量催收流程的有效性,帮助优化催收策略。 获取途径 这可能是R1 RCM患者账户中的状态字段,也可能位于专用的催收模块中。 示例 已全额付款已按较低金额结清已转交外部机构已作为坏账核销 | |||
| 患者ID PatientId | 接受服务的患者的唯一标识。 | ||
| 说明 此属性是医疗系统分配给患者的唯一ID,通常称为病历号(MRN)。 虽然分析重点并非个体患者护理,但患者ID可用于分析同一患者随时间反复出现的计费问题。如果关联其他患者数据,也可以按患者人口统计特征或病史细分流程,从而发现影响特定患者群体的系统性问题。 重要性 支持在患者层面分析计费事件,帮助识别特定患者多次就诊中反复出现的问题或模式。 获取途径 此标识是患者人口统计数据的核心部分,在R1 RCM中与每次就诊和理赔申请相关联。 示例 MRN837262MRN937281MRN103847 | |||
| 是否自动执行 IsAutomated | 用于标记活动由自动化系统还是人工用户执行。 | ||
| 说明 此布尔属性用于区分由软件自动化执行的任务(例如使用RPA机器人提交理赔申请)和员工手动执行的任务。 分析此属性是了解自动化举措影响和成效的关键。您可以比较自动化与人工流程的速度、成本和错误率,发现新的自动化机会,并衡量现有机器人的投资回报。 重要性 区分人工执行和系统驱动的活动,这对于衡量自动化对流程效率、成本和质量的影响至关重要。 获取途径 可根据“AssignedUser”字段推断,特定用户ID通常专供机器人使用,例如“BOT_RPA01”。部分系统也设有专用字段,用于标记自动化交易。 示例 truefalse | |||
| 是否返工 IsRework | 用于标记返工循环中活动的计算字段,例如重新提交被拒的理赔申请。 | ||
| 说明 此属性是一个布尔标记,通常在流程挖掘分析期间计算得出。如果某项活动重复了之前的步骤,或属于表明正在纠正错误的活动序列,例如发生在“理赔申请被拒”之后的活动,则该属性为“true”。 识别返工是流程挖掘的重要能力之一。它可以量化流程中浪费的精力、时间和资源。标记返工后,组织可以重点改进流程,从源头上避免导致返工的错误,从而显著提升效率。 重要性 帮助量化理赔申请被拒等情况造成的返工频率和影响,支持有针对性的分析,以减少低效和无效工作。 获取途径 这不是源系统中的字段,而是流程挖掘工具根据活动顺序计算得出,例如检测同一案例中“已提交理赔申请”活动是否发生多次。 示例 truefalse | |||
| 服务代码 ServiceCode | 特定服务或操作的计费代码,例如CPT或HCPCS代码。 | ||
| 说明 CPT(现行操作术语)等服务代码是标准化医疗代码,用于向付款方申报医疗、外科和诊断操作及服务,以获得报销。 按服务代码分析流程对于发现特定护理类型相关的计费问题至关重要。分析可以显示哪些操作最常被拒赔、付款周期最长或返工最多,从而有针对性地改进编码和计费实践。 重要性 支持按所提供的服务类型分析流程,这对于识别特定操作相关的拒赔模式或付款延迟至关重要。 获取途径 在R1 RCM中,可在每笔费用或理赔申请的明细行中找到此信息。 示例 992139928573560 | |||
| 服务至付款周期时间 ServiceToPaymentCycleTime | 从提供服务到最终登记付款的总时长。 | ||
| 说明 此指标衡量单个计费事件的端到端收入周期时长,反映组织将已提供的服务转化为现金所需的总时间。 这是衡量财务健康状况的关键绩效指标(KPI)。分析此时长有助于发现流程提速的主要机会。将周期时间拆分为“计费耗时”和“付款耗时”等部分后,组织可以找出改善现金流的最大机会。 重要性 这是衡量现金转换周期整体效率的关键高级KPI,直接影响组织的现金流。 获取途径 这是一个计算指标,表示特定计费事件中“已提供服务”活动与“已登记付款”活动的时间戳之差。 示例 35天8小时92天4小时15天12小时 | |||
| 调整原因 AdjustmentReason | 财务调整的原因,例如“合同减免”或“坏账核销”。 | ||
| 说明 此属性说明对账户进行财务调整的原因。原因通常以标准化代码或描述表示,用于对调整类型进行分类。 分析调整原因有助于诊断收入流失的根本原因。例如,“小额余额核销”频繁出现,可能表明小额款项的催收流程效率低下;而“合同减免”频繁出现,则可能是付款方协商中的正常情况。此分析可为“计费调整与合规审计”仪表板提供支持。 重要性 说明收入调整的原因,帮助识别收入损失的根本原因,例如合同问题、计费错误或催收失败。 获取途径 在R1 RCM中,这通常是与AdjustmentAmount位于同一交易记录中的代码或文本字段。 示例 合同减免坏账核销小额余额核销计费错误更正 | |||
| 调整金额 AdjustmentAmount | 对账户余额进行调整的金额。 | ||
| 说明 此属性记录初次计费后对患者账户进行的财务调整金额。调整金额可以为正数或负数,包括合同减免、核销或更正。 追踪调整金额对于了解收入完整性至关重要。大量负向调整可能表明存在收入流失,例如费用记录错误或债务无法收回。分析这些数据有助于了解计费错误和催收效率低下造成的财务影响。 重要性 量化收入流失和财务更正,帮助确定计费错误、合同义务或坏账造成的金额影响。 获取途径 在R1 RCM中,可从与账户调整或付款入账相关的交易日志中找到。 示例 -50.2520.00-1200.00 | |||
收入周期管理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 付款已入账 | 收到的付款已正式记入患者账户,未结余额相应减少。这是将付款与已开票服务进行核对的最后一步。 | ||
| 重要性 此活动是计算服务到付款和付款入账周期时间的终点,可确认收入已入账且账户信息已准确更新。 获取途径 此事件作为明确的财务交易记录在R1 RCM患者会计模块中。每笔入账均包含日期、金额和来源。 采集 用户或自动化流程应用付款时,系统会记录具体交易及其入账日期。 事件类型 explicit | |||
| 已收到付款 | 付款方或患者已付款。此事件表示已收到资金,但款项尚未分配到具体账户或服务项目。 | ||
| 重要性 此事件代表现金流入。“已收到付款”到“付款已入账”之间的时间差,是了解后台运营效率和现金对账延迟的重要指标。 获取途径 此事件根据付款方的电子汇款文件或患者付款处理记录生成,对应存款日期或文件接收日期。 采集 根据ERA文件中的付款生效日期或患者付款交易日期记录。 事件类型 explicit | |||
| 服务已提供 | 表示面向患者的可计费服务或操作完成的时间点。此事件通常由临床系统或排班系统记录,并作为收入周期的起点。 | ||
| 重要性 这是服务到付款周期时间KPI的起点。分析从该事件开始的耗时,有助于发现收入周期前端的延迟。 获取途径 通常来自与R1 RCM集成的电子健康记录(EHR)或诊所管理系统。患者记录中的“服务日期”或“操作完成”时间戳通常可用于推断此事件。 采集 根据患者就诊记录中的“服务日期”时间戳推断。 事件类型 inferred | |||
| 索赔已提交 | 系统会将生成的索赔以电子方式提交给负责的付款方,例如保险公司。这是开票流程中首次与外部机构沟通,以申请报销。 | ||
| 重要性 这是启动付款方报销计时的关键节点。跟踪此事件有助于监控提交积压,并确保按时向付款方提交,符合相关要求。 获取途径 索赔传输至清算所时,系统会将此事件记录为明确的交易,并记录提交时间戳和确认详情。 采集 索赔通过清算所发送时,系统会将其作为交易明确记录,并附上提交时间戳。 事件类型 explicit | |||
| 账户已关闭 | 账单事件已全部解决,余额为零,账户正式关闭。这表示该次就诊的收入周期已顺利完成。 | ||
| 重要性 这是流程中理想路径的主要结束事件。衡量账户关闭周期时间,有助于确保行政工作高效完成并及时归档记录。 获取途径 账户余额归零并应用“已关闭”或“已全额付款”的最终状态时,可推断此事件。时间戳取自使余额归零的最后一笔财务交易。 采集 账户余额归零、状态变更为“已关闭”并记录最终活动时间戳时,可推断此事件。 事件类型 inferred | |||
| 费用已记录 | 此活动表示正式记录患者就诊期间所有可计费的服务、操作和用品。这是关键的数据录入步骤,将临床活动转化为财务交易。 | ||
| 重要性 标志着临床运营向财务运营的交接。它是衡量发票和索赔生成周期时间的起点,也有助于发现费用录入积压。 获取途径 此事件记录在R1 RCM的费用录入模块中,或通过与EHR的接口接收。通常由特定交易日志或费用记录的创建时间戳标记。 采集 根据账单表中费用交易记录的创建时间戳识别。 事件类型 explicit | |||
| 催收活动已开始 | 患者账户已逾期,催收工作随即启动。措施包括自动发送提醒函,或将账户交由催收专员处理。 | ||
| 重要性 此事件标志着成本较高的催收流程开始。分析这些活动的成效和周期时间,有助于优化坏账回收策略。 获取途径 账户进入催收工作队列,或在R1 RCM中被分配催收状态代码时,系统可能会记录或推断此事件。 采集 根据账户状态变更为“催收中”或“逾期”推断。 事件类型 inferred | |||
| 已收到付款方裁定结果 | 系统会收到付款方对已提交索赔的回复,通常以电子汇款通知(ERA)文件的形式提供。回复会详细说明已付款、拒付或调整的金额。 | ||
| 重要性 这是流程中的关键分岔点,决定下一步是付款入账还是拒付管理。分析此事件有助于了解付款方行为和回款速度。 获取途径 付款方的电子汇款文件(如ANSI 835文件)由R1 RCM处理时,此事件即被记录。事件时间戳为文件处理时间。 采集 系统在接收并处理电子汇款通知(ERA/835)文件时记录此事件。 事件类型 explicit | |||
| 患者账单已生成 | 保险裁定完成后,系统会生成患者账单,列明患者需承担的剩余余额,包括共付额、免赔额或不予承保的服务费用。 | ||
| 重要性 此活动启动收入周期中的患者付款环节。分析其时间和频次,对于管理患者催收和现金流十分重要。 获取途径 通常在批处理生成并打印或以电子方式发送患者账单时,作为日志事件记录。R1 RCM会记录账单生成日期。 采集 运行生成患者账单的批处理时,系统会将此事件记录为一笔交易。 事件类型 explicit | |||
| 拒付返工已开始 | 用户或自动化工作流开始调查并处理被拒的索赔,可能包括更正编码、提交文档或对付款方的决定提出申诉。 | ||
| 重要性 此事件标记被拒索赔进入成本高昂的返工环节。衡量此阶段的耗时,是了解拒付管理团队效率的关键。 获取途径 在R1 RCM工作队列或拒付管理模块中,被拒索赔的状态变更为“返工处理中”或“审核中”时,通常可据此推断此事件。 采集 根据拒付管理工作队列中的状态变更,或用户首次处理被拒索赔的操作推断。 事件类型 inferred | |||
| 索赔已创建 | 系统根据已记录的费用生成正式账单索赔,其中包括将患者人口统计信息、保险信息和服务代码汇总为标准格式。 | ||
| 重要性 这是对外提交前的关键内部节点。此处延迟可能表明编码、数据验证或系统配置存在问题,进而拖慢整个开票流程。 获取途径 这是R1 RCM内部的系统事件,可能通过账单账户的状态变更或索赔实体本身的创建时间戳记录。 采集 根据状态变更为“索赔已生成”或索赔记录的创建时间戳推断。 事件类型 inferred | |||
| 索赔被拒 | 付款方拒绝支付全部或部分索赔金额。系统会记录拒付原因,并启动返工和申诉流程。 | ||
| 重要性 此活动反映收入流失和流程低效。分析拒付原因对于找出根本问题、提高索赔首次提交通过率至关重要。 获取途径 这不是一个独立事件,而是根据已处理ERA文件中的详细信息推断出的状态。汇款数据中的特定拒付代码会触发索赔状态变更。 采集 根据已处理ERA文件中的拒付代码推断,这些代码会将索赔状态变更为“已拒付”。 事件类型 inferred | |||
| 账户已调整 | 账户中记录了一笔非付款交易,用于调整余额。此类交易包括根据付款方协议进行的合同调整、小额余额核销或更正。 | ||
| 重要性 调整量过大可能表明费率表、合同管理或开票存在问题。跟踪调整对于分析收入完整性至关重要。 获取途径 此事件作为特定交易类型记录在R1 RCM患者会计模块中。每笔调整均包含代码、金额和入账日期。 采集 系统会将其记录为独立的调整交易,并可通过唯一交易代码识别。 事件类型 explicit | |||
| 账户已转为坏账 | 所有催收措施均已用尽,账户剩余余额被认定为无法收回。该余额将作为坏账核销,构成最终收入损失。 | ||
| 重要性 这代表不利的流程结果和直接收入损失。分析哪些案例最终成为坏账,有助于发现不付款模式和改进催收的机会。 获取途径 通常,这是R1 RCM中的明确交易:未结余额被转入特定坏账类别,通常由用户操作或自动账龄规则触发。 采集 系统会将余额核销记录为特定财务交易,通常与转交外部催收机构有关。 事件类型 explicit | |||
数据提取指南
步骤
- 使用具有商业智能或报表模块访问权限的用户账户登录R1 RCM平台。
- 进入平台的报表部分。该部分可能标为“Business Intelligence”“Reporting Portal”或“Analytics”。
- 找到创建自定义报表或查询的工具,以便定义要提取的具体数据字段和逻辑。
- R1 RCM不提供预置的统一事件日志,因此您需要整合不同来源的数据来构建事件日志。所提供的查询配置采用UNION ALL,将不同业务对象中的事件合并为按时间排序的日志。
- 复制本文档“Query”部分提供的完整查询,并粘贴到自定义报表的查询编辑器或配置界面中。
- 配置报表参数,尤其是日期范围。在查询中设置
'{StartDate}'和'{EndDate}'占位符,以指定提取时间段,例如最近6个月。 - 根据需要添加其他报表筛选条件,例如按特定机构、部门或付款方组筛选,以缩小数据范围。
- 运行报表。系统将对R1 RCM数据库执行查询,并根据您指定的参数生成结果。
- 报表运行完毕后,找到数据导出选项。选择CSV(逗号分隔值)作为导出格式,该格式可直接用于ProcessMind。
- 下载生成的CSV文件并快速检查。确认列标题与所需属性一致:
BillingEvent、ActivityName、EventTime、SourceSystem和LastDataUpdate。 - 上传到ProcessMind之前,请确认
EventTime和LastDataUpdate列中的日期和时间格式一致。
配置
- 前提条件:需要拥有足够权限的用户账户,才能在R1 RCM商业智能模块中访问并创建自定义报表。
- 报表类型:使用支持复杂数据提取和UNION ALL语句(用于合并不同数据集)的自定义查询或高级报表生成器。
- 日期范围:为控制运行性能和数据量,必须筛选特定时间段。建议初次分析从3至6个月的时间范围开始,并对每项活动的主要时间戳字段应用日期筛选。
- 关键筛选条件:除日期范围外,还可按
Facility ID、Payer Type或Billing Department筛选,以聚焦特定运营领域并缩小导出文件。 - 导出格式:始终选择CSV作为输出格式,确保文件结构清晰,便于流程挖掘工具解析。
- 计划运行:如果R1 RCM报表模块支持,可设置定期运行报表(例如每周或每月),以自动刷新数据,持续监控流程。
查询示例 sql
SELECT
c.ClaimID AS BillingEvent,
'Service Rendered' AS ActivityName,
c.ServiceDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ClinicianID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Rendered' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ServiceDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
c.ClaimID AS BillingEvent,
'Charges Captured' AS ActivityName,
c.ChargeEntryTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ChargeEntryUserID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Open' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ChargeEntryTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Created' AS ActivityName,
cl.CreationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.CreatedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Created' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.CreationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Submitted' AS ActivityName,
cl.SubmissionTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.SubmittedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Submitted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.SubmissionTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
era.ClaimID AS BillingEvent,
'Payer Adjudication Received' AS ActivityName,
era.ReceivedTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pa.InvoiceAmount AS InvoiceAmount,
era.PayerName AS PayerName,
'Adjudicated' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [RemittanceAdvice] era
JOIN [PatientAccounts] pa ON era.ClaimID = pa.BillingEvent
WHERE era.ReceivedTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
d.ClaimID AS BillingEvent,
'Claim Denied' AS ActivityName,
d.DenialTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Denied' AS InvoiceStatus,
d.ReasonCode AS DenialReasonCode
FROM [DenialsLog] d
JOIN [ClaimsData] cl ON d.ClaimID = cl.ClaimID
WHERE d.DenialTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
dr.ClaimID AS BillingEvent,
'Denial Rework Started' AS ActivityName,
dr.ReworkStartTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
dr.AssignedUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'In Rework' AS InvoiceStatus,
dr.OriginalDenialCode AS DenialReasonCode
FROM [DenialRework] dr
JOIN [ClaimsData] cl ON dr.ClaimID = cl.ClaimID
WHERE dr.ReworkStartTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ps.PatientAccountID AS BillingEvent,
'Patient Statement Generated' AS ActivityName,
ps.GenerationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ps.GeneratedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
ps.StatementBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Patient Billed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientStatements] ps
JOIN [PatientAccounts] pa ON ps.PatientAccountID = pa.BillingEvent
WHERE ps.GenerationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
p.AssociatedClaimID AS BillingEvent,
'Payment Received' AS ActivityName,
p.ReceiptTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
p.ProcessedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
p.PaymentAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Payment Pending' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentsLog] p
JOIN [PatientAccounts] pa ON p.AssociatedClaimID = pa.BillingEvent
WHERE p.ReceiptTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pt.ClaimID AS BillingEvent,
'Payment Posted' AS ActivityName,
pt.PostingTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pt.PostedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pt.PostedAmount AS InvoiceAmount,
pt.PayerName AS PayerName,
'Partially Paid' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentTransactions] pt
JOIN [PatientAccounts] pa ON pt.ClaimID = pa.BillingEvent
WHERE pt.PostingTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
a.ClaimID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
a.AdjustmentTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
a.AdjusterID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
a.AdjustmentAmount AS InvoiceAmount,
pa.PayerName AS PayerName,
'Adjusted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [Adjustments] a
JOIN [PatientAccounts] pa ON a.ClaimID = pa.BillingEvent
WHERE a.AdjustmentTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ca.PatientAccountID AS BillingEvent,
'Collection Activity Started' AS ActivityName,
ca.ActivityTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ca.AssignedAgentID AS AssignedUser,
'Collections' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'In Collections' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [CollectionsActivity] ca
JOIN [PatientAccounts] pa ON ca.PatientAccountID = pa.BillingEvent
WHERE ca.ActivityTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Placed in Bad Debt' AS ActivityName,
pa.BadDebtPlacementDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pa.BadDebtUserID AS AssignedUser,
'Finance' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Bad Debt' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.BadDebtPlacementDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Closed' AS ActivityName,
pa.ClosureDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
0 AS InvoiceAmount,
pa.PayerName AS PayerName,
'Closed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.ClosureDate BETWEEN '{StartDate}' AND '{EndDate}' AND pa.CurrentBalance = 0; 立即优化R1 RCM:提升收入周期效率
消除RCM瓶颈,将周期时间缩短30%,改善现金流。
无需信用卡,几分钟即可开始。