CMS-0057-F y el 1 de enero de 2027: las API de los pagadores sobre sistemas propios de reclamaciones y autorización previa

Antes del 1 de enero de 2027, las organizaciones de Medicare Advantage (aseguradoras privadas que gestionan planes de Medicare) y los programas estatales de Medicaid y CHIP (el seguro médico infantil) en modalidad fee-for-service (pago por servicio) deben tener en marcha cuatro API FHIR, conforme a la regla final de interoperabilidad y autorización previa de los Centers for Medicare & Medicaid Services (CMS), la CMS-0057-F: la Patient Access API ya existente, ampliada para incluir los datos de autorización previa, y las nuevas API Provider Access, Payer-to-Payer y Prior Authorization. Los planes de Medicaid en managed care (atención gestionada), las entidades de CHIP en managed care y las aseguradoras de Qualified Health Plans (QHP) en los mercados federales de seguros médicos se suman a partir de su primer rating period (periodo de tarifas del contrato con el estado) o plan year (año de cobertura) que empiece en esa fecha o después. A 16 de octubre de 2026 faltan once semanas, y los CMS no han movido la fecha.

La parte operativa de la regla ya está en vigor. Desde 2026, los pagadores afectados tienen que dar un motivo concreto para cada autorización previa denegada, decidir dentro de plazos fijos y publicar métricas de autorización previa.

Si tus sistemas de reclamaciones, de gestión de la utilización (utilization management, UM) y de afiliados vienen de un proveedor que entrega estas cuatro API, la mayor parte del desarrollo le toca a él. Lo tuyo es la configuración, las reglas de autorización previa digitalizadas, los avisos a los afiliados y las pruebas con tus socios.

Este artículo es para el resto: planes y agencias cuyo motor de reclamaciones, flujo de UM o datos de afiliados están en un sistema propio, ya sea desarrollado internamente, personalizado hasta el punto de no admitir actualizaciones o un Medicaid Management Information System (MMIS, el sistema de información de Medicaid de cada estado) con décadas de cambios locales. Para esos sistemas nadie entrega las API. Somos ingenieros, no abogados: aquí explicamos lo que la regla exige a un sistema, no cómo se aplica a tus contratos.

Las fechas

La regla final se publicó en el Federal Register (el diario oficial federal) el 8 de febrero de 2024 y entró en vigor el 8 de abril de 2024. Para cada una de las cuatro API fija las mismas fechas de cumplimiento: «a más tardar el 1 de enero de 2027, para las organizaciones MA y los programas FFS estatales de Medicaid y CHIP; a más tardar en el rating period que comience el 1 de enero de 2027 o después, para los planes de Medicaid en managed care y las entidades de CHIP en managed care; y para los plan years que comiencen el 1 de enero de 2027 o después, para las aseguradoras de QHP en los FFE».

Así, un plan de Medicaid en managed care cuyos rating periods empiezan el 1 de julio tiene hasta el 1 de julio de 2027. Un plan con contrato por año natural, no.

Los CMS siguen dando la misma fecha. Su página sobre la regla, modificada por última vez el 8 de octubre de 2026, dice que «los pagadores afectados tienen principalmente hasta el 1 de enero de 2027 para cumplir los requisitos de interfaz de programación de aplicaciones (API) de esta regla final».

Las obligaciones de 2026, tal como las resume la hoja informativa de los CMS, son decisiones «en un plazo de 72 horas para las solicitudes aceleradas (es decir, urgentes) y de siete días naturales para las solicitudes estándar (es decir, no urgentes)» (las aseguradoras de QHP en los mercados quedan excluidas de los plazos), un motivo concreto para cada denegación y métricas públicas, de las que «el primer conjunto de métricas debe comunicarse a más tardar el 31 de marzo de 2026». El uso de la Patient Access API también se comunica a los CMS cada año, antes del 31 de marzo. Si algo de esto todavía no funciona, ya va con retraso, y se alimenta de los mismos datos que las API.

Los medicamentos quedan fuera de todo esto. Todas las disposiciones de autorización previa de la CMS-0057-F los excluyen.

Quién está en el ámbito y quién no

La regla los llama impacted payers (pagadores afectados): organizaciones de Medicare Advantage (MA), programas estatales de Medicaid y CHIP en fee-for-service (FFS), planes de Medicaid en managed care, entidades de CHIP en managed care y aseguradoras de QHP en los Federally-facilitated Exchanges (FFE, los mercados de seguros gestionados por el Gobierno federal). Su análisis de impacto cuenta «365 organizaciones matrices, incluidas las agencias estatales de Medicaid y CHIP», que «son responsables de implementar y mantener tres nuevas API», y señala que «el 75% de los pagadores de esta categoría tienen menos de 500 empleados». Muchos son planes regionales sin un gran equipo de plataforma.

Fuera del ámbito, al menos de forma directa:

• Los planes de empresa ajenos a estos programas, y Original Medicare (el Medicare tradicional que gestiona el Gobierno federal). No figuran en la lista de pagadores afectados.
• Los prestadores de servicios de salud. Su parte es la Electronic Prior Authorization measure de los programas Promoting Interoperability de Medicare, que se cumple con tecnología de historia clínica electrónica (EHR) certificada. La regla final del IPPS (el sistema de pago de las hospitalizaciones) para el año fiscal 2027, del 4 de agosto de 2026, la convirtió en una medida de bonificación opcional para los hospitales en 2027.
• Las entidades de UM delegadas y los TPA (administradores externos de planes). No tienen obligaciones propias, pero las del pagador pasan por sus sistemas. Para las aseguradoras de QHP, la regla repite que «son responsables de su propio cumplimiento y del cumplimiento de cualquier entidad delegada o situada más abajo en la cadena».

Hay pocas salidas, y a estas alturas ninguna ayuda mucho. Un estado puede pedir una prórroga única de un año para su programa FFS de Medicaid o CHIP, pero la solicitud va en su Advance Planning Document (APD, el documento de planificación del que depende la financiación federal) y tiene que estar «aprobada antes de la fecha de cumplimiento». Un estado con al menos el 90% de sus beneficiarios de Medicaid en managed care puede pedir una exención, y las aseguradoras de QHP pueden solicitar al mercado una excepción. Sobre los planes en sí, los CMS escribieron: «No propusimos prórrogas ni exenciones para las organizaciones MA ni para los planes de Medicaid en managed care». Los estados también pueden pedir fondos federales de contrapartida reforzados del 90% para construir las API, aprobados caso por caso a través del APD.

Qué tiene que hacer cada API

Las cuatro dependen de algo que a menudo le falta a un sistema a medida: la autorización previa como datos estructurados con historial de estados. Constrúyelo una vez y las cuatro leen de ahí.

Patient Access API: añadir las autorizaciones previas

Tienes esta API en funcionamiento desde el 1 de enero de 2021, para reclamaciones, encuentros (registros de la atención prestada en managed care) y datos clínicos. A partir de 2027 también tiene que incluir cada autorización previa de artículos y servicios: su estado, la fecha en que se aprobó o denegó, cuándo vence, los artículos y servicios aprobados, un motivo concreto si se denegó y la documentación estructurada relacionada que aportó el prestador. Los datos tienen que estar disponibles «a más tardar 1 día hábil después» de que el pagador reciba la solicitud, actualizarse en un día hábil tras cualquier cambio de estado y conservarse mientras la autorización esté activa y durante al menos un año después de su último cambio.

Un sistema de UM que registra las decisiones como notas de texto libre, o que solo comunica el estado por fax, no puede alimentar esto sin cambios.

Provider Access API

Los prestadores de la red pueden pedir los datos de un paciente: reclamaciones y encuentros sin las liquidaciones a prestadores ni la parte a cargo del afiliado, las clases de datos clínicos del USCDI (el conjunto federal de datos clínicos para la interoperabilidad) y la información de autorización previa, para fechas de servicio desde el 1 de enero de 2016. El pagador responde en un día hábil, pero solo para los pacientes que ha atribuido a ese prestador y que no han ejercido la exclusión voluntaria (opt-out).

Eso requiere tres cosas que un sistema heredado rara vez tiene. Un proceso de atribución que vincule afiliados con prestadores. Un opt-out que el afiliado pueda cambiar en cualquier momento, con avisos en lenguaje sencillo antes del primer uso, en la semana siguiente al inicio de la cobertura y cada año. Y exportación masiva, porque los estándares exigidos incluyen FHIR Bulk Data Access para el prestador que consulta por todo su panel de pacientes.

Payer-to-Payer API

Cuando un afiliado se incorpora, el nuevo pagador pide su permiso (aquí es opt-in) y empieza a identificar a los pagadores anteriores y concurrentes en la semana siguiente al inicio de la cobertura. Una vez los tiene, solicita en el plazo de una semana cinco años de datos: reclamaciones y encuentros sin liquidaciones ni la parte a cargo del afiliado, datos USCDI y autorizaciones previas que no sean denegaciones, con su documentación no estructurada. El pagador anterior responde en un día hábil. Si hay cobertura concurrente, el intercambio se repite al menos cada trimestre.

Lo difícil no es la respuesta de salida. Es recibir datos de pagadores con los que nunca has hecho pruebas e incorporarlos al expediente del afiliado, como exige la regla.

Prior Authorization API

Esta es la que llega al núcleo de UM. La API tiene que listar los artículos y servicios cubiertos que requieren autorización previa, identificar la documentación necesaria para cada uno, admitir una solicitud y una respuesta conformes con HIPAA (la ley federal que regula las transacciones y la privacidad de los datos de salud) e indicar si el pagador aprobó (con la fecha de vencimiento), denegó (con un motivo concreto) o necesita más información.

Los CMS recomiendan aquí, sin exigirlas, tres guías de implementación de Da Vinci (un proyecto de HL7): Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) y Prior Authorization Support (PAS). En la práctica, tus reglas de cobertura y tus cuestionarios de documentación tienen que volverse legibles por máquina, en vez de quedarse en un manual de políticas en PDF. Los pagadores de la encuesta de WEDI (Workgroup for Electronic Data Interchange, la asociación estadounidense del intercambio electrónico de datos en salud) sitúan la «digitalización de las políticas de autorización previa» entre sus tres principales retos.

En cuanto a la transacción en sí, el HHS (el Departamento de Salud federal) dio margen a los pagadores. El 28 de febrero de 2024 anunció discrecionalidad en la aplicación (enforcement discretion): según los CMS, su National Standards Group «no emprenderá acciones de cumplimiento de la HIPAA Administrative Simplification contra las entidades cubiertas por HIPAA que opten por no usar el estándar X12 278 como parte de un proceso electrónico de autorización previa con FHIR». Puedes construir solo con FHIR o con FHIR y X12 (el formato EDI tradicional), y mantener al lado una transacción solo X12.

Los estándares

Los estándares exigidos son HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access y OpenID Connect Core; los pagadores pueden usar versiones actualizadas de forma voluntaria, con condiciones. La regla de 2024 recogía US Core 3.1.1 y SMART App Launch 1.0.0 con fecha de caducidad el 1 de enero de 2026, así que decide con qué versiones vas a trabajar antes de que nadie escriba el mapeo.

Dónde suelen quedarse cortos los sistemas propios

A partir de lo que pide la regla, estas son las carencias que conviene buscar primero:

• La autorización previa como registro, no como documento. El estado, las marcas de tiempo, los códigos de motivo de denegación y la fecha de vencimiento tienen que ser campos, escritos cuando cambian, con historial. Una decisión enviada por fax necesita un gemelo estructurado.
• Las reglas de cobertura. Qué servicios necesitan autorización, y qué documentación necesita cada uno, tiene que ser un dato que la API pueda servir. En muchos planes vive en PDF de políticas y en la cabeza de los revisores.
• Las reclamaciones en FHIR. Las reclamaciones y los encuentros tienen que salir como recursos FHIR, sin liquidaciones ni la parte a cargo del afiliado para los prestadores y otros pagadores, pero con esos datos para el propio afiliado.
• Identidad e historial del afiliado. Asociar los datos de otro pagador con tu afiliado, y encontrar los pagadores anteriores de un afiliado nuevo, exige datos demográficos e historial de cobertura que quizá no guardes en un solo sitio.
• El estado del consentimiento. Un opt-out para Provider Access y un opt-in para Payer-to-Payer, modificables en cualquier momento y comprobados en cada solicitud. Además, un estado tiene que trasladar el opt-in de un beneficiario a los planes de Medicaid en managed care de esa persona.
• El reloj de un día hábil. Un batch nocturno en el mainframe sirve para algunos datos y es demasiado lento para otros. Mide el tiempo que va de la decisión a la API, no solo si la API responde.
• Los proveedores delegados. Si las decisiones las toma un proveedor de UM delegado, sus datos tienen que llegarte a tiempo para tu obligación de un día hábil. La encuesta de WEDI de febrero de 2026 situó «Terceros delegados con dificultades para conectarse con distintos sistemas» en el primer lugar de los retos de los pagadores.

En qué punto está el sector

La encuesta de WEDI de febrero de 2026, publicada el 10 de marzo de 2026, concluyó que, en cuanto a los requisitos de API, «el 10% todavía no ha empezado su trabajo», frente al 33% de octubre de 2025. También informó de «un aumento notable de los costes estimados superiores a 5 millones de dólares, del 15% (oct. 2025) al 25% (feb. 2026)». La muestra es pequeña: 86 respuestas, el 52% de ellas de pagadores. Tómala como una señal, no como un censo.

Un plan de once semanas hasta el 1 de enero de 2027

Desde mediados de octubre, una organización MA o un programa FFS estatal tiene unas once semanas. No basta para construir cuatro API desde cero, así que el plan trata del orden de los trabajos y de lo que puedas demostrar el primer día.

1. Esta semana: confirma tu fecha y tu punto de partida. ¿El 1 de enero, o un rating period o plan year posterior? Haz una lista de lo que ya está en producción: las API Patient Access y Provider Directory, las métricas de 2026, los motivos de denegación.
2. Semanas 1 y 2: vincula cada elemento de datos con su origen. Para cada API, anota qué sistema tiene hoy los datos (reclamaciones, UM, afiliación, red de prestadores, datos clínicos) y cómo de actualizados están.
3. Semanas 1 a 3: decide dónde vive la capa FHIR. Un servidor o fachada FHIR delante de los sistemas heredados, alimentado por eventos de cambio o extracciones frecuentes, suele ser más rápido que enseñar FHIR al sistema central. El tiempo se va en el mapeo y en los flujos de datos.
4. Semanas 2 a 7: construye primero las piezas compartidas. El registro de autorización previa, el consentimiento y la atribución, el emparejamiento de afiliados. Las cuatro API dependen de ellas.
5. Semanas 4 a 9: construye las API. Las ampliaciones de Patient Access, Provider Access con exportación masiva, Payer-to-Payer en ambas direcciones y la Prior Authorization API con tus reglas de cobertura cargadas.
6. Semanas 8 a 11: prueba con contrapartes reales. El proveedor de EHR de un prestador, otro pagador, tu proveedor de UM delegado. Prueba cambios de consentimiento, una denegación con su motivo y un cambio de estado que llegue al afiliado en un día hábil.
7. 1 de enero de 2027: pon en marcha y mide. Controla la latencia frente a las reglas de un día hábil desde el primer día, y mantén una lista fechada de lo que no está terminado.

Si once semanas no bastan, llévalo ya a tu equipo de cumplimiento y a tus abogados, no en diciembre, con un plan que muestre qué estará en producción el 1 de enero y qué vendrá después, y cuándo.

Un plan de Medicaid en managed care con un rating period que empieza el 1 de julio de 2027, o una aseguradora de QHP con un plan year posterior, puede seguir los mismos pasos con más margen. Empieza ya de todos modos: los pagadores y prestadores con los que vas a hacer pruebas entran en producción el 1 de enero.

Qué puede cambiar todavía

CMS-0062-P. El 14 de abril de 2026, los CMS publicaron una propuesta de regla complementaria. Haría obligatorias desde el 1 de octubre de 2027 las guías de implementación que hoy solo se recomiendan, añadiría los medicamentos a la autorización previa electrónica desde esa misma fecha y haría que el HHS adoptara FHIR como estándar HIPAA para las transacciones de autorización previa en lugar de X12 278. Sobre los plazos existentes dice: «Esta propuesta no modificaría esas fechas de cumplimiento». El periodo de comentarios cerró el 15 de junio de 2026 y, a 16 de octubre de 2026, no ha aparecido ninguna regla final en el Federal Register. Construye conforme a la regla de 2024 y mantén las versiones de las guías en un único lugar configurable.

Versiones. Las guías Da Vinci siguen cambiando. La regla final del IPPS para el año fiscal 2027 señala que las EHR certificadas con los nuevos criterios de autorización previa de la ONC (el organismo federal que supervisa la certificación del software sanitario) «exigirán el uso de la versión 2.2 de las IG de Da Vinci». Esos son los sistemas con los que va a hablar tu Prior Authorization API.

Nada de esto es motivo para esperar. La regla es definitiva, las fechas están en el texto normativo y los CMS las repitieron el 8 de octubre.

Dónde conseguir ayuda

Trabajamos en los sistemas que hay detrás de las API: el mapeo FHIR de los datos de reclamaciones, encuentros y autorizaciones, los flujos de cambios desde plataformas antiguas de reclamaciones y UM, la lógica de consentimiento y atribución, y las pruebas que demuestran que se cumplen las reglas de un día hábil. Nuestro servicio de mantenimiento de sistemas heredados es por donde se empieza cuando el sistema central es antiguo o las personas que lo construyeron ya no están, y si el plazo te pilla en mitad de una sustitución de plataforma, consulta modernización de ERP.

Si tu plataforma de reclamaciones o de UM es una de esas para las que ningún proveedor va a entregar estas API, escribe a office@c9group.dev. Somos ingenieros, no abogados especializados en sanidad: las cuestiones de ámbito y de contrato corresponden a tus asesores jurídicos, y construimos según su respuesta.