CMS-0057-F 与 2027 年 1 月 1 日：在自建理赔和事先授权系统上实现支付方 API

根据 CMS（美国联邦医疗保险和医疗补助服务中心）的互操作性与事先授权最终规则（CMS Interoperability and Prior Authorization final rule，CMS-0057-F），Medicare Advantage 组织（MA organization，以私营计划形式提供 Medicare 福利的保险公司）以及各州 Medicaid（面向低收入人群的公共医疗保险）和 CHIP（儿童健康保险计划）的按服务付费（fee-for-service）项目，必须在 2027 年 1 月 1 日前运行四个 FHIR API：现有的 Patient Access API（扩展后须承载事先授权数据），以及新增的 Provider Access API、Payer-to-Payer API 和 Prior Authorization API。Medicaid 管理式医疗计划、CHIP 管理式医疗实体，以及在联邦医疗保险交易市场上提供 Qualified Health Plan（QHP，合格健康计划）的承保方，则从该日期当天或之后开始的第一个 rating period（费率期）或计划年度起适用。截至 2026 年 10 月 16 日，距离这一日期只剩十一周，而 CMS 并没有推迟。

规则中涉及运营的那一半已经生效。自 2026 年起，受影响支付方（impacted payers）必须为每一项被拒绝的事先授权给出具体理由，在规定时限内作出决定，并公开发布事先授权指标。

如果您的理赔、医疗利用管理（utilization management，UM）和参保人系统来自一家提供这四个 API 的厂商，大部分开发工作归厂商。您要做的是配置、事先授权规则的数字化、参保人通知，以及与合作方的测试。

本文写给其余的机构：理赔引擎、UM 工作流或参保人数据位于自有系统中的计划和州机构，无论这套系统是自研的、定制到已经无法升级的，还是积累了几十年本地修改的 Medicaid Management Information System（MMIS，州 Medicaid 管理信息系统）。没有人为这类系统提供现成的 API。我们是工程师，不是律师：本文说明的是规则要求系统做什么，而不是规则如何适用于您的合同。

时间节点

最终规则刊登于 2024 年 2 月 8 日的《联邦公报》（Federal Register），并于 2024 年 4 月 8 日生效。对四个 API 中的每一个，它都规定了相同的合规日期：“MA 组织以及州 Medicaid 和 CHIP FFS 项目须在 2027 年 1 月 1 日前；Medicaid 管理式医疗计划和 CHIP 管理式医疗实体须在 2027 年 1 月 1 日当天或之后开始的 rating period 前；FFE 上的 QHP 承保方须自 2027 年 1 月 1 日当天或之后开始的计划年度起。”

因此，rating period 从 7 月 1 日开始的 Medicaid 管理式医疗计划，期限是 2027 年 7 月 1 日。按日历年签约的计划则没有这段余地。

CMS 给出的仍是同一个日期。它在该规则的政策页面上（最后修改于 2026 年 10 月 8 日）写道：“受影响支付方满足本最终规则中应用程序编程接口（API）要求的期限，主要为 2027 年 1 月 1 日。”

按 CMS 情况说明的表述，2026 年的义务包括：决定须“对加急（即紧急）请求在 72 小时内作出，对标准（即非紧急）请求在七个日历日内作出”（交易市场上的 QHP 承保方不适用这些时限），每一项拒绝都要给出具体理由，以及公开指标，其中“首批指标必须在 2026 年 3 月 31 日前报告”。Patient Access API 的使用情况同样要在每年 3 月 31 日前向 CMS 报告。如果其中任何一项还没有运行，就已经迟了，而且它用到的数据与这些 API 相同。

药品不在上述任何范围内。CMS-0057-F 中所有关于事先授权的条款都把药品排除在外。

谁在范围内，谁不在

规则把它们称为受影响支付方：Medicare Advantage（MA）组织、州 Medicaid 和 CHIP 按服务付费（FFS）项目、Medicaid 管理式医疗计划、CHIP 管理式医疗实体，以及联邦运营医疗保险交易市场（Federally-facilitated Exchanges，FFE）上的 QHP 承保方。规则的影响分析统计了“365 家母公司组织，包括州 Medicaid 和 CHIP 机构”，它们“负责实施和维护三个新的 API”，并指出“这一类别中 75% 的支付方员工不足 500 人”。其中许多是没有大型平台团队的地区性计划。

不在范围内的（至少不直接在范围内的）有：

• 这些项目之外的雇主计划，以及 Original Medicare（传统 Medicare）。它们不在受影响支付方名单上。
• 医疗服务提供方。它们那一侧对应的是 Medicare Promoting Interoperability 项目中的 Electronic Prior Authorization measure（电子事先授权指标），通过经认证的 EHR 技术来满足。2026 年 8 月 4 日的 FY 2027 IPPS 最终规则（IPPS 即住院患者预付费系统）把它定为医院 2027 年的可选加分指标。
• 受委托的 UM 机构和 TPA（第三方管理机构）。它们自身不承担义务，但支付方的义务要经由它们的系统来履行。对于 QHP 承保方，规则再次强调，它们“对自身的合规以及任何受委托或下游实体的合规负责”。

可以脱身的途径很少，到了这个时候也都帮不上多大忙。州可以为其 Medicaid 或 CHIP FFS 项目申请一次性延期一年，但申请须写入其 Advance Planning Document（APD，州申请联邦资金所用的预先规划文件），并且必须“在合规日期之前获得批准”。Medicaid 受益人中至少 90% 参加管理式医疗的州可以申请豁免，QHP 承保方可以向交易市场申请例外。至于计划本身，CMS 写道：“我们没有为 MA 组织或 Medicaid 管理式医疗计划提出延期或豁免。”各州还可以为构建这些 API 申领 90% 的联邦增强配套资金，经由 APD 逐案审批。

每个 API 要做什么

四个 API 都依赖一项定制系统往往缺少的东西：作为结构化数据、带有状态历史的事先授权。这部分只需建一次，四个 API 都从中读取。

Patient Access API：加入事先授权

自 2021 年 1 月 1 日起，您就已在为理赔、就诊记录和临床数据运行这个 API。从 2027 年起，它还必须承载每一项针对物品和服务的事先授权：其状态、批准或拒绝的日期、终止日期、获批的物品和服务、被拒时的具体理由，以及医疗服务提供方提交的相关结构化文档。这些数据必须在支付方收到请求后“不迟于 1 个工作日”可用，在任何状态变更后一个工作日内更新，并在授权有效期间以及最后一次变更后至少一年内保留。

以自由文本备注记录决定、或只用传真发送状态的 UM 系统，不经改造就无法提供这些数据。

Provider Access API

网络内的医疗服务提供方可以请求患者的数据：不含医疗服务提供方付款明细（remittance）和费用分担的理赔与就诊记录、USCDI（美国互操作性核心数据集）中的临床数据类别，以及事先授权信息，服务日期从 2016 年 1 月 1 日起算。支付方须在一个工作日内答复，但仅限于已归属（attribution）给该医疗服务提供方、且未选择退出的患者。

这需要三样遗留系统很少具备的东西。一是把参保人与医疗服务提供方关联起来的归属流程。二是参保人可随时更改的选择退出机制，并在首次使用前、承保开始后一周内以及每年发出通俗易懂的通知。三是批量导出，因为必需的标准包括 FHIR Bulk Data Access，供医疗服务提供方查询其整个患者名单（panel）。

Payer-to-Payer API

参保人加入时，新支付方须征得许可（这里采用选择加入），并在承保开始后一周内着手确认此前的和同时承保的支付方。确认之后，须在一周内请求五年的数据：不含付款明细和费用分担的理赔与就诊记录、USCDI 数据，以及除被拒绝之外的事先授权及其非结构化文档。原支付方须在一个工作日内答复。存在同时承保时，这种交换至少每季度重复一次。

难点不在对外答复，而在于接收来自您从未与之测试过的支付方的数据，并按规则要求把它并入您的参保人记录。

Prior Authorization API

这是触及 UM 核心的那一个。该 API 必须列出需要事先授权的承保物品和服务，标明每一项所需的文档，支持符合 HIPAA（美国《健康保险流通与责任法案》）的请求与响应，并说明支付方是已批准（附终止日期）、已拒绝（附具体理由），还是需要更多信息。

在这里，CMS 推荐但不强制要求三份 Da Vinci 实施指南（来自 HL7 Da Vinci 项目）：Coverage Requirements Discovery（CRD）、Documentation Templates and Rules（DTR）和 Prior Authorization Support（PAS）。实际上，您的承保规则和文档问卷必须变成机器可读的数据，而不是一本 PDF 政策手册。在 WEDI（美国医疗电子数据交换行业组织）的调查中，支付方把“将事先授权政策数字化”列为三大挑战之一。

在交易本身上，HHS 给了支付方余地。2024 年 2 月 28 日，它宣布了执法裁量（enforcement discretion）：据 CMS 介绍，CMS 下属的 National Standards Group“不会对选择不在电子 FHIR 事先授权流程中使用 X12 278 标准的 HIPAA 涵盖实体采取 HIPAA Administrative Simplification 执法行动”。您可以只用 FHIR 构建，也可以 FHIR 与 X12 并用，并同时保留仅使用 X12 的交易。

标准

必需的标准是 HL7 FHIR Release 4.0.1、US Core、SMART App Launch、Bulk Data Access 和 OpenID Connect Core；在一定条件下，支付方可以自愿使用更新的版本。2024 年规则列出 US Core 3.1.1 和 SMART App Launch 1.0.0 时，给它们定的失效日期是 2026 年 1 月 1 日，所以在任何人动手写映射之前，先确定要按哪些版本构建。

自建系统通常欠缺的地方

从规则的要求来看，首先要查找的是这些缺口：

• 事先授权是一条记录，而不是一份文档。状态、时间戳、拒绝理由代码和终止日期都必须是字段，在变更时写入，并保留历史。以传真发出的决定需要一份结构化的对应记录。
• 承保规则。哪些服务需要授权、每项需要什么文档，必须是 API 可以提供的数据。在许多计划中，这些信息存在于政策 PDF 和审核人员的脑子里。
• 以 FHIR 输出理赔数据。理赔和就诊记录必须以 FHIR 资源输出，面向医疗服务提供方和其他支付方时去掉付款明细和费用分担，面向参保人时则保留。
• 参保人身份与历史。把另一个支付方的数据匹配到您的参保人，以及找到新参保人此前的支付方，需要人口统计信息和承保历史，而这些数据您可能并没有集中存放。
• 同意状态。Provider Access 的选择退出和 Payer-to-Payer 的选择加入，二者都可随时更改，并且每次请求都要检查。州还必须把受益人的选择加入传递给此人所在的 Medicaid 管理式医疗计划。
• 一个工作日的时限。大型机的夜间批处理对某些数据足够，对另一些数据则太慢。要衡量从作出决定到 API 可用的时间，而不只是 API 是否有响应。
• 受委托的厂商。如果由受委托的 UM 厂商作出决定，它的数据必须及时送达，让您能履行一个工作日的义务。WEDI 2026 年 2 月的调查把“受委托第三方在与不同系统对接时面临困难”列为支付方面临的头号挑战。

行业进展到了哪一步

WEDI 于 2026 年 3 月 10 日发布的 2026 年 2 月调查发现，在 API 要求方面，“10% 尚未开始工作”，而 2025 年 10 月时这一比例为 33%。调查还报告，“预计成本超过 500 万美元的比例从 15%（2025 年 10 月）显著上升至 25%（2026 年 2 月）”。样本量很小：86 份回复，其中 52% 来自支付方。应把它当作信号来看，而不是普查。

到 2027 年 1 月 1 日的十一周计划

从 10 月中旬算起，MA 组织或州 FFS 项目大约还有十一周。这不足以从零开始构建四个 API，所以计划的关键在于顺序，以及上线第一天能拿出什么。

1. 本周：确认您的日期和起点。是 1 月 1 日，还是更晚的 rating period 或计划年度？列出已经上线的内容：Patient Access API 和 Provider Directory API、2026 年的指标、拒绝理由。
2. 第 1 至 2 周：把每个数据元素对应到它的来源。针对每个 API，写下目前由哪个系统保存这些数据（理赔、UM、参保登记、医疗服务提供方网络、临床），以及数据有多新。
3. 第 1 至 3 周：决定 FHIR 层放在哪里。在遗留系统前面放一个 FHIR 服务器或外观层（facade），用变更事件或高频抽取来供数，通常比让核心系统直接支持 FHIR 更快。时间主要花在映射和数据馈送上。
4. 第 2 至 7 周：先构建共享部分。事先授权记录、同意与归属、参保人匹配。四个 API 都依赖它们。
5. 第 4 至 9 周：构建 API。Patient Access 的新增内容、带批量导出的 Provider Access、双向的 Payer-to-Payer，以及载入了承保规则的 Prior Authorization API。
6. 第 8 至 11 周：与真实的对接方测试。医疗服务提供方的 EHR 厂商、另一家支付方、您受委托的 UM 厂商。测试同意变更、附理由的拒绝，以及在一个工作日内送达参保人的状态变更。
7. 2027 年 1 月 1 日：上线并测量。从第一天起就对照一个工作日规则跟踪延迟，并保留一份注明日期的未完成事项清单。

如果十一周不够，现在就把这个情况告诉您的合规团队和法律顾问，而不是等到 12 月，并附上一份计划，说明 1 月 1 日哪些内容会上线，其余部分何时跟进。

rating period 为 2027 年 7 月 1 日的 Medicaid 管理式医疗计划，或计划年度更晚的 QHP 承保方，可以按同样的步骤推进，时间更宽裕。但仍应现在就开始：您要与之测试的支付方和医疗服务提供方在 1 月 1 日上线。

还可能变化的地方

CMS-0062-P。CMS 于 2026 年 4 月 14 日发布了一项后续拟议规则。它将使目前推荐的实施指南自 2027 年 10 月 1 日起成为强制要求，自同日起把药品纳入电子事先授权，并由 HHS 采用 FHIR 取代 X12 278，作为事先授权交易的 HIPAA 标准。关于现有期限，它写道：“本提案不会改变这些合规日期。”意见征集已于 2026 年 6 月 15 日截止，截至 2026 年 10 月 16 日，《联邦公报》上尚未出现最终规则。请按 2024 年的规则构建，并把指南版本集中放在一个可配置的地方。

版本。Da Vinci 指南还在不断更新。FY 2027 IPPS 最终规则指出，按 ONC（HHS 负责医疗信息技术的部门）新的事先授权认证标准获得认证的 EHR“将要求使用 Da Vinci IG 的 2.2 版”。您的 Prior Authorization API 要对接的正是这些系统。

这些都不是等待的理由。规则已经定稿，日期写在法规条文里，CMS 在 10 月 8 日又重申了一遍。

从哪里获得帮助

我们做的是 API 背后的系统：理赔、就诊和授权数据的 FHIR 映射，从较老的理赔和 UM 平台导出的变更数据流，同意与归属逻辑，以及证明一个工作日规则得到遵守的测试。当核心系统老旧，或当初构建它的人已经离开时，我们的遗留系统维护服务就是起点；如果截止日期恰好落在平台替换的过程中，请参阅 ERP 现代化。

如果您的理赔或 UM 平台没有任何厂商会为其提供这些 API，请写信到 office@c9group.dev。我们是工程师，不是医疗领域的律师：范围和合同问题应交给您的法律顾问，我们按他们的结论来构建。