¿Qué es la Regla Final CMS-0057-F?
CMS-0057-F es la norma que convierte la autorización previa y el intercambio de datos entre pagadores en un plazo de ingenierÃa. Publicada en el Registro Federal el 8 de febrero de 2024, la Regla Final de Interoperabilidad y Autorización Previa de CMS otorga a los planes de salud regulados una fecha fija, el 1 de enero de 2027, para operar cuatro APIs FHIR en producción, además de un conjunto de normas operativas de autorización previa que han estado en vigor desde un año antes. CMS estima que la norma ahorrará al sistema de salud aproximadamente 15 000 millones de dólares en diez años, en su mayor parte eliminando la fricción en la autorización previa.
En el centro de la norma se encuentran cuatro APIs HL7 FHIR R4. Una de ellas es posible que ya la opere en alguna forma. Tres son nuevas.
- API de Acceso del Paciente: permite a los miembros transferir sus reclamaciones, datos clÃnicos e información de autorización previa a aplicaciones de terceros.
- API de Acceso del Proveedor: comparte reclamaciones y datos clÃnicos para los miembros atribuidos a un proveedor, de forma masiva.
- API de Pagador a Pagador: transfiere el historial de un miembro a su nuevo plan cuando cambia de cobertura.
- API de Autorización Previa: ejecuta el flujo de trabajo de autorización previa electrónica de principio a fin.
El patrón en las cuatro es el mismo. Cada una expone datos que usted ya posee, a través de una interfaz estándar, para un público especÃfico. Por eso el trabajo real reside menos en la puesta en marcha de las APIs que en los datos que hay detrás. La naturaleza de ese trabajo varÃa según la API, y las secciones siguientes abordan cada una por separado.
Quiénes deben cumplir y quiénes están exentos
La norma se aplica a seis tipos de pagador: organizaciones de Medicare Advantage, programas estatales de Medicaid y CHIP de pago por servicio, organizaciones de atención administrada de Medicaid, entidades de atención administrada de CHIP y emisores de Planes de Salud Calificados en los exchanges facilitados federalmente. Si usted gestiona uno de estos, está construyendo las cuatro APIs.
Numerosas organizaciones quedan fuera de la norma. El Medicare tradicional, los planes ERISA autofinanciados patrocinados por empleadores, los planes de medicamentos independientes de la Parte D y los planes Medigap no están cubiertos. Las entidades delegadas son una fuente más habitual de confusión. Un proveedor de gestión de utilización, TPA, MSO o IPA no está regulado directamente por CMS-0057-F. La obligación recae en el pagador, incluso para las funciones que el pagador delega. En la práctica, esto significa que un plan que delega la autorización previa sigue estando obligado a exponer una API de Autorización Previa conforme, de modo que o bien construye esa API sobre el sistema del proveedor o exige que el proveedor la suministre. El proveedor queda involucrado comercialmente, no porque la norma lo mencione.
Hay una excepción que conviene fijar, porque es el detalle que más personas interpretan erróneamente. Los emisores de QHP en los exchanges no están sujetos a los plazos de decisión de autorización previa. Estos se aplican a Medicare Advantage, Medicaid y CHIP. Todo lo demás sigue aplicándose a los QHPs: las cuatro APIs, la norma de razón de denegación especÃfica y la publicación de métricas. Por tanto, si usted gestiona un QHP, contemple el trabajo de las APIs en su totalidad y excluya el reloj de decisiones.
Dos plazos, dos tipos de trabajo
La norma estableció dos fechas en el calendario, y cada una exige equipos diferentes.
La primera, el 1 de enero de 2026, ya quedó atrás. Desde entonces, los pagadores afectados (salvo los QHPs en lo relativo a los plazos) han tenido que emitir decisiones de autorización previa en un plazo de 72 horas para solicitudes urgentes y de siete dÃas naturales para las estándar, indicar una razón especÃfica para cada denegación y publicar métricas de autorización previa en su sitio web cada año. El primer informe público venció el 31 de marzo de 2026, cubriendo el año natural 2025, y se repite anualmente. Este es un trabajo de polÃtica y proceso. Se puede cumplir con cambios en los flujos de trabajo y la gobernanza.
La segunda, el 1 de enero de 2027, es el plazo de las APIs, y es el más exigente. Es ingenierÃa, y no se puede cerrar con un memorando. Las cuatro secciones que siguen explican en qué consiste realmente esa ingenierÃa.
API de Acceso del Paciente
El Acceso del Paciente es la única API que la mayorÃa de los planes afectados ya opera en alguna forma, ya que data de la norma de 2020. Un miembro autoriza una aplicación de terceros y el plan le devuelve sus datos a través de un flujo SMART on FHIR asegurado con OAuth 2.0. El miembro controla la autorización y puede revocarla.
Lo que fluye a través de ella es amplio: reclamaciones adjudicadas y datos de encuentros en formato CARIN Blue Button, datos clÃnicos como USCDI y, para los planes con cobertura de medicamentos, información sobre formularios. CMS-0057-F añade un elemento antes del 1 de enero de 2027: la información de autorización previa, el estado y la razón especÃfica, para todo excepto los medicamentos.
El trabajo rara vez reside en el endpoint. Está en la calidad de los datos que lo respaldan: mapear correctamente las reclamaciones, mantener el flujo actualizado y asumir las brechas existentes. Los planes también reportan a CMS métricas de uso del Acceso del Paciente cada año. Bien ejecutada, esta API es más que una superficie de cumplimiento. La misma capa de datos limpia orientada al miembro puede respaldar su propia aplicación o portal para miembros.
API de Acceso del Proveedor
El Acceso del Proveedor es nuevo, y es donde los equipos subestiman el esfuerzo, porque no es solo un endpoint. Proporciona a un proveedor dentro de la red las reclamaciones, los datos de encuentros, los datos clÃnicos USCDI y la información de autorización previa de los miembros que tiene atribuidos, entregados de forma masiva.
El modelo de autenticación es diferente al del Acceso del Paciente. No hay ningún paciente que haga clic en «aprobar». El plan autentica a la organización proveedora como sistema, mediante SMART Backend Services, y ejecuta una exportación de Bulk Data FHIR sobre el grupo de miembros atribuidos al proveedor. El esfuerzo no reside en la exportación, sino en la gobernanza que la rodea:
- Atribución. El plan debe conocer qué proveedores tienen una relación de tratamiento con qué miembros, y mantener esas listas de atribución actualizadas.
- Exclusión voluntaria. Los miembros pueden negarse a compartir sus datos con los proveedores, y el plan debe respetar y registrar esa decisión.
Si se resuelven correctamente estos dos aspectos, la exportación en sà misma es rutinaria.
API de Pagador a Pagador
La API de Pagador a Pagador es un proyecto de identidad y consentimiento antes de ser un proyecto de API. Cuando un miembro se incorpora a su plan, usted dispone de una semana para solicitar al pagador anterior hasta cinco años de historial, reclamaciones, datos clÃnicos y registros de autorización previa, de modo que pueda comenzar con contexto en lugar de un historial en blanco. Cuando un miembro se va, usted está en el otro lado de esa llamada, respondiendo al nuevo plan. Los datos de costes, las remesas de proveedores y la participación en los costes del asegurado quedan excluidos.
La transferencia es la parte sencilla. Las partes difÃciles son las dos barreras que hay antes de ella. La correspondencia de miembros: usted y el otro plan deben ponerse de acuerdo en que están hablando de la misma persona a través de diferentes identificadores, sin una clave compartida. El consentimiento: a diferencia del Acceso del Proveedor, nada se mueve sin que el miembro dé su consentimiento, por lo que necesita un mecanismo para capturar ese consentimiento y respetarlo. Para los miembros que tienen cobertura de más de un plan simultáneamente, el intercambio se realiza al menos trimestralmente en lugar de solo en el momento de la inscripción.
API de Autorización Previa
Las tres primeras APIs publican o transfieren datos. La API de Autorización Previa es algo diferente: ejecuta una transacción. Un proveedor hace una pregunta a su plan y este debe responder con una decisión real, dentro de un plazo. Se trata de integración de procesos de negocio, no de exposición de datos, razón por la cual es la más compleja de las cuatro y conlleva el conjunto más profundo de estándares.
Tres guÃas de implementación Da Vinci se encadenan para ejecutar ese proceso. Comienza con CRD, Coverage Requirements Discovery. Cuando un proveedor solicita o programa un artÃculo o servicio, se activa un hook desde el EHR y su plan responde en tiempo real: ¿se requiere autorización previa y qué documentación necesita? Si es asÃ, DTR, Documentation Templates and Rules, entrega al EHR un cuestionario inteligente y rellena previamente lo que puede a partir del historial clÃnico, de modo que el proveedor no tenga que volver a introducir datos que el sistema ya posee. Finalmente, PAS, Prior Authorization Support, envÃa la solicitud y devuelve la decisión: aprobada, denegada con una razón especÃfica o pendiente de más información. CMS recomienda estas guÃas pero no las exige formalmente.
Aquà también es necesario corregir una interpretación errónea frecuente. FHIR no reemplaza a X12. La guÃa PAS está diseñada para transportar la transacción X12 278 exigida por HIPAA, de modo que la solicitud y la respuesta subyacentes siguen siendo X12 por debajo de FHIR. Un pagador puede ejecutar el back end solo con FHIR, solo con X12 o con una combinación de ambos y seguir cumpliendo la norma. La documentación clÃnica adicional se incorpora a través de un mecanismo Da Vinci separado, CDex, en lugar de introducirse a la fuerza en el propio mensaje de autorización.
Un elemento adicional conecta el lado del pagador con los proveedores. A partir del perÃodo de rendimiento de 2027, los médicos y hospitales elegibles certifican, en el marco del programa Medicare Promoting Interoperability, que solicitaron al menos una autorización previa electrónicamente a través de una API de Autorización Previa. Esa medida es la señal de demanda. Por eso su API de Autorización Previa no es solo un endpoint de cumplimiento, sino algo que su red de proveedores ya espera poder utilizar.
Qué cambió respecto a la norma de 2020
Si CMS-0057-F le resulta familiar, es porque se basa en CMS-9115-F, la norma de Interoperabilidad y Acceso del Paciente de 2020. Esa norma anterior estableció la API de Acceso del Paciente y la API de Directorio de Proveedores. También contemplaba el intercambio de datos entre pagadores, pero CMS nunca aplicó esa disposición y nunca se basó en APIs.
CMS-0057-F completa el trabajo. Conserva las APIs anteriores, reconstruye el intercambio entre pagadores como una API FHIR ejecutable, añade el Acceso del Proveedor y la Autorización Previa, incorpora los datos de autorización previa al Acceso del Paciente y añade los plazos operativos y los informes públicos. La dirección es coherente. El alcance y el rigor son nuevos. CMS no estableció una sanción especÃfica en la norma, pero la hace cumplir a través de las facultades que ya posee sobre cada programa: contratos de Medicare Advantage, supervisión de Medicaid y CHIP, y certificación de QHP. La exposición es contractual y regulatoria, no una cifra en dólares publicada.
Cómo ayuda Health Samurai
Payerbox es la plataforma de Health Samurai para CMS-0057-F destinada a planes de salud, construida sobre nuestro núcleo Aidbox nativo en FHIR R4. Implementa las cuatro APIs, con soporte en producción para las guÃas de autorización previa Da Vinci, CRD, DTR y PAS.
El principio de diseño es el que un calendario comprimido realmente exige: integrar, no reemplazar. Su plataforma de reclamaciones, su sistema de gestión de utilización y su directorio permanecen donde están. Payerbox se sitúa delante de ellos, lee sus datos y los traduce en FHIR conforme para cada API. El valor no está en mover registros a un nuevo sistema, sino en exponer los registros que usted ya tiene, correctamente, a través de una interfaz estándar.
Esa capa FHIR sigue aportando valor después del plazo. El almacén que construya para las cuatro APIs es también un almacén analÃtico: los mismos datos normalizados alimentan el ajuste de riesgo, las medidas Stars y de calidad, y la salud poblacional. El gasto en cumplimiento se convierte en un activo de datos reutilizable en lugar de un envoltorio de un solo uso, y el siguiente requisito regulatorio aterriza sobre datos que usted ya ha normalizado.
Este es software en producción, no una promesa en diapositivas. Payerbox está en funcionamiento con pagadores hoy. VillageCareMAX sirve su API de Acceso del Paciente en Payerbox y quedó en el puesto n.º 2, con 91 sobre 100, en el cuadro de puntuación independiente de noviembre de 2025 de Flexpa, por lo que no solo está en funcionamiento, sino que está valorado entre los mejores. Un proveedor delegado de autorización previa ejecuta la pila completa Payerbox ePA —CRD, DTR y PAS— en producción. Y mantenemos la pila conforme participando en el track de Reducción de Carga del HL7 Da Vinci Connectathon.
Consulte la solución completa en la página de Payerbox para CMS-0057-F. Cuando desee una evaluación de arquitecto a arquitecto sobre la situación de su plan respecto al plazo de enero de 2027, programe una llamada: mapearemos sus obligaciones, analizaremos sus sistemas de origen y le mostraremos cómo serÃa una implementación de Payerbox en función de su calendario restante.
