---
{
  "title": "Cómo verificar sus APIs de CMS-0057-F: Siete preguntas que debe hacerle a su equipo",
  "description": "Su equipo afirma que las APIs de CMS-0057-F están listas. Siete preguntas que debe hacer antes de los plazos de 2027, con las evidencias que deberían aportarse como respuesta.",
  "date": "2026-11-12",
  "author": "Mike Kulakov",
  "reading-time": "15 min read",
  "tags": [
    "Compliance",
    "Integrations"
  ],
  "tldr": "Una demostración funcional no demuestra que los datos correctos lleguen a la parte correcta a tiempo. Cada obligación de CMS-0057-F existe para alguien externo a su plan: la aplicación de un afiliado, un proveedor que solicita datos del paciente, un proveedor que solicita una autorización previa, otro plan de salud, un desarrollador de aplicaciones, CMS y el público. Aquí encontrará una pregunta para cada uno de ellos, más una para su propio equipo, con lo que dice la norma y las evidencias que deberían acompañar la respuesta.",
  "utm-campaign": "fhir_expert",
  "utm-content": "cms0057-cio-how-to-check"
}
---

> For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt).
> Use it to discover all available pages before guessing URLs.

---
Su equipo, o su proveedor, afirma que las APIs de CMS-0057-F están listas. La demostración funciona: una aplicación de prueba inicia sesión y extrae las reclamaciones de un afiliado. El 1 de enero de 2027, las APIs de Acceso para Proveedores, de Plan a Plan y de Autorización Previa se vuelven obligatorias, y los datos de autorización previa se incorporan a la API de Acceso para Pacientes. La pregunta que tiene ante usted es si «lista» significa «conforme».

Una demostración muestra que un endpoint responde. No muestra con qué retraso llegan los datos, si un proveedor ve únicamente a sus propios pacientes, ni si un desarrollador puede leer la documentación sin necesidad de crear una cuenta. La norma especifica las tres cosas. Cada obligación sirve a alguien externo a su plan, y esa persona es la primera en notar cuando no se cumple.

A continuación se presentan siete preguntas que debe plantear a su equipo. Las cuatro primeras siguen el recorrido de los datos desde cada API hasta quien los solicita: la aplicación de un afiliado, un proveedor que quiere datos del paciente, un proveedor que quiere una autorización previa y otro plan de salud. Las tres últimas abarcan lo que comparten las cuatro APIs: documentación que un desarrollador de aplicaciones pueda leer, los informes y avisos que ven CMS y el público, y las pruebas que respaldan todo ello.

Cada pregunta incluye lo que dice la norma y las evidencias que su equipo debería poder mostrarle. Nada de esto requiere que usted lea código. Y esta no es una verificación puntual, así que pregunte antes de los plazos de 2027 y siga preguntando después.

Si gestiona un plan de atención administrada de Medicaid, las mismas obligaciones le alcanzan a través de su contrato con el Estado, y cada pregunta señala las diferencias pertinentes. Las fechas funcionan de manera distinta. Las suyas siguen su período de calificación, los 12 meses para los que el Estado fija sus tarifas de capitación. Cada Estado establece cuándo comienza su período de calificación, por lo que una obligación de 2027 puede comenzar para usted el 1 de abril, el 1 de julio o el 1 de septiembre de 2027.

Los enlaces de este artículo remiten a [las secciones de Medicare Advantage de la norma](https://www.ecfr.gov/current/title-42/section-422.119). Las de Medicaid se encuentran en [42 CFR parte 438](https://www.ecfr.gov/current/title-42/part-438). Para consultar la norma en su conjunto, comience con nuestro [resumen de CMS-0057-F](/articles/understanding-the-cms-0057-f-interoperability-and-prior-authorization-final-rule).

Las siete preguntas de un vistazo:

| Pregunta | Aplicable desde | Evidencias que solicitar |
|---|---|---|
| 1. La aplicación de un afiliado | Desde 2021. Datos de autorización previa desde el 1 de enero de 2027 | Reclamaciones en la API en un día hábil; recuentos por año desde 2016; un motivo en cada denegación |
| 2. Un proveedor que solicita datos del paciente | 1 de enero de 2027 | Una prueba de atribución con tres solicitudes; afiliados que optaron por no participar excluidos; respuesta completa en un día hábil |
| 3. Un proveedor que solicita una autorización previa | 1 de enero de 2027 | Cada código listado procesado a través de la API; misma documentación y resultados que sus revisores |
| 4. Otro plan de salud | 1 de enero de 2027 | Opt-in ofrecido a tiempo; solicitudes enviadas en una semana; una prueba de intercambio en ambas direcciones |
| 5. Un desarrollador de aplicaciones | Acceso para Pacientes desde 2021. Las otras tres APIs desde el 1 de enero de 2027 | Documentación accesible desde su página de inicio sin cuenta; criterios escritos para revocar el acceso a aplicaciones |
| 6. CMS y el público | Informes antes del 31 de marzo de cada año, por primera vez en 2026. Páginas para afiliados desde 2021 | Cada informe, aviso y página, con un responsable y un enlace |
| 7. Su propio equipo | Acceso para Pacientes desde 2021. Las otras tres APIs desde el 1 de enero de 2027 | Verificaciones 1 a 4 con una programación y alertas; versiones por API; último informe de pruebas de conformidad |

Para un plan de atención administrada de Medicaid, una fecha de 2026 o 2027 corresponde al primer período de calificación que comience en esa fecha o después.

## 1. La aplicación de un afiliado

**Pregúntele a su equipo.** Cuando la aplicación de un afiliado solicita sus datos, ¿están todos disponibles y se entregan a tiempo?

**Lo que dice la norma.** La API de Acceso para Pacientes debe proporcionar a la aplicación de un afiliado los siguientes datos que usted mantiene, para fechas de servicio desde el 1 de enero de 2016:

- Reclamaciones que haya adjudicado, incluidas las decisiones de pago que pueden ser, fueron o están siendo apeladas, con los reembolsos al proveedor y la participación en costos del afiliado. Con vencimiento un día hábil después de que la reclamación sea procesada.
- Datos de encuentros de proveedores a los que paga por capitación. Con vencimiento un día hábil después de recibirlos.
- Datos clínicos: cada clase de datos en USCDI, la lista federal de datos de salud estándar que incluye diagnósticos, resultados de laboratorio, medicamentos y alergias. Con vencimiento un día hábil después de recibirlos.
- Si ofrece la Parte D, reclamaciones de medicamentos de la Parte D con reembolsos y participación en costos, con vencimiento un día hábil después de que la reclamación sea adjudicada, y su formulario, con sus niveles y reglas de gestión de utilización.
- Desde el 1 de enero de 2027, cada autorización previa para artículos y servicios, excluyendo medicamentos. La aplicación verá su estado, la fecha en que fue aprobada o denegada, cuándo vence, qué fue aprobado, un motivo específico de denegación y la documentación estructurada que envió el proveedor. Con vencimiento un día hábil después de la solicitud y después de cada cambio de estado, y conservada durante al menos un año tras el último cambio.

Un plan de atención administrada de Medicaid excluye los medicamentos ambulatorios cubiertos e incluye todos sus datos de encuentros, así como las reclamaciones y los datos de encuentros de sus subcontratistas.

**Lo que debería mostrar la respuesta.** Tres resultados, obtenidos de los registros de carga y de la API, no del documento de diseño.

- **Puntualidad.** Su equipo debe saber qué proporción de las reclamaciones de la semana pasada aparecieron en un día hábil desde la fecha en que el sistema de reclamaciones las marcó como procesadas. El objetivo es la totalidad, con una causa identificada para cada una con retraso. Deben contar con la misma cifra para encuentros, datos clínicos, reclamaciones de la Parte D y autorizaciones previas, contadas cada una desde la fecha que la norma establece para ellas. Una carga que se ejecuta cada noche puede ser válida. Una carga que se ejecuta una vez a la semana no puede serlo.
- **Historial.** Tome una muestra de afiliados con antigüedad y cuente sus reclamaciones y encuentros para cada año desde 2016, una vez en la API y otra vez en sus propios registros. Esto abarca cada sistema que contiene los datos del afiliado, incluido un sistema de reclamaciones que haya reemplazado posteriormente, si aún conserva sus datos. Para un plan de Medicaid, incluye también los datos de subcontratistas y proveedores capitados. Una plataforma cargada únicamente desde su fecha de lanzamiento falla esta prueba, y también una plataforma con algún año faltante.
- **Denegaciones.** Dos cifras del mes pasado que deberían ser iguales. La primera es el número de solicitudes de autorización previa para artículos y servicios que denegó, sin contar medicamentos, en todos los sistemas que las deciden. Esto incluye a cualquier proveedor externo que las decida en su nombre, ya que el plan sigue siendo responsable de sus proveedores. La segunda es el número de esas denegaciones que llegan a la API con un motivo específico. Una diferencia entre ambas significa denegaciones que nunca llegan a la API, o que llegan sin motivo. Desde el 1 de enero de 2026, cada denegación que envíe a un proveedor ya debe incluir un motivo específico, independientemente del canal de comunicación. Por tanto, el motivo existe en algún lugar, y la pregunta es si el flujo de datos lo traslada a la API. La norma no establece ninguna lista de códigos de motivo, así que solicite también ver cinco denegaciones tal como las muestra la aplicación de un afiliado. Cada una debería indicar el porqué, por ejemplo qué criterios no cumplía la solicitud.

Hasta 2027, ejecute las verificaciones de autorización previa en preproducción, con solicitudes y denegaciones reales del flujo de producción. Los datos de prueba incluyen un motivo ya cumplimentado, por lo que no revelarán ninguna diferencia.

## 2. Un proveedor que solicita datos del paciente

**Pregúntele a su equipo.** Cuando un proveedor de la red solicita los datos de un paciente, ¿recibe únicamente los de sus propios pacientes, y solo los de quienes no han optado por no participar?

**Lo que dice la norma.** Desde el 1 de enero de 2027, la [API de Acceso para Proveedores](https://www.ecfr.gov/current/title-42/section-422.121) proporciona a los proveedores de la red los mismos datos que el Acceso para Pacientes, desde el 1 de enero de 2016, sin los reembolsos al proveedor ni la participación en costos del afiliado. Los datos deben entregarse como máximo un día hábil después de la solicitud del proveedor. Antes de compartirlos, usted confirma la identidad del proveedor y verifica que el afiliado le está atribuido, utilizando su propio proceso de vinculación de afiliados con proveedores de la red. Los afiliados pueden optar por no participar y cambiar de opinión en cualquier momento, y la manera de hacerlo debe estar disponible antes de que usted comparta datos por primera vez.

**Lo que debería mostrar la respuesta.**

- **Atribución.** Una prueba con tres solicitudes. Un proveedor de la red que consulta sobre un afiliado que le está atribuido recibe los datos. El mismo proveedor que consulta sobre un afiliado que no le está atribuido no recibe nada. Un proveedor fuera de la red no recibe nada.
- **Opt-out.** Un afiliado que optó por no participar queda excluido de la respuesta. Una vez que ese afiliado vuelve a optar por participar, sus datos vuelven a aparecer.
- **Puntualidad.** Cuánto tarda cada solicitud hasta que los datos estén disponibles. Debe ser un día hábil o menos. Para una solicitud que abarca a un grupo completo de pacientes, el tiempo se cuenta hasta la respuesta completa, no hasta el primer registro.
- **Historial.** La misma verificación año por año que en la pregunta 1.

## 3. Un proveedor que solicita una autorización previa

**Pregúntele a su equipo.** ¿La API de Autorización Previa le proporciona al proveedor la misma respuesta que nuestros revisores, para cada código, incluidos los que revisa un proveedor externo en nuestro nombre?

**Lo que dice la norma.** Desde el 1 de enero de 2027, la [API de Autorización Previa](https://www.ecfr.gov/current/title-42/section-422.122) debe contener su lista de artículos y servicios que requieren autorización previa. También debe indicar al proveedor qué documentación requiere cada uno, y señalar si usted aprueba (y hasta cuándo), deniega o necesita más información. Una denegación debe incluir un motivo específico.

**Lo que debería mostrar la respuesta.**

- **Lista de códigos.** Cada código de su lista de autorización previa se procesa a través de la API, incluidos los códigos que revisa un proveedor externo en su nombre. Los medicamentos quedan fuera del alcance. Cuando un código tiene condiciones, como el entorno de atención o el número de unidades, pruebe un caso que cumpla la condición y uno que no la cumpla. Una muestra de códigos que no están en la lista debe regresar indicando que no requieren autorización previa. La API y sus revisores trabajan con una única lista actualizada.
- **Documentación.** Para una muestra de códigos, la API solicita la misma documentación que sus revisores.
- **Decisiones.** Para algunas solicitudes de prueba, la API devuelve el resultado al que llegó un revisor: aprobada con la fecha o el evento en que vence, denegada con un motivo específico, o solicitud de información adicional.

## 4. Otro plan de salud

**Pregúntele a su equipo.** Cuando un afiliado se incorpora procedente de otro plan, ¿solicitaremos su historial a tiempo? Cuando otro plan nos lo solicite a nosotros, ¿responderemos a tiempo?

**Lo que dice la norma.** Desde el 1 de enero de 2027, ambas direcciones se gestionan a través de la API de Plan a Plan, y ambas dependen del opt-in del afiliado.

- **Solicitar.** Usted ofrece el opt-in y comienza a identificar los planes anteriores y simultáneos de cada afiliado. Para los afiliados actuales, ambas acciones comienzan antes del 1 de enero de 2027. Para los nuevos afiliados, ambas comienzan en el plazo de una semana tras el inicio de la cobertura, o tras la aceptación de la inscripción por parte de CMS si esta es posterior. Una vez que cuenta con el opt-in y con información suficiente sobre el otro plan, la solicitud se envía en el plazo de una semana. Para un plan en el que el afiliado está inscrito simultáneamente, la solicitud se repite al menos cada trimestre.
- **Responder.** Cuando otro plan solicita datos y atestigua que el afiliado está inscrito con él y ha dado su opt-in, usted pone los datos a disposición en el plazo de un día hábil.
- **Datos.** Datos de Acceso para Pacientes de los últimos cinco años, sin reembolsos al proveedor, participación en costos del afiliado ni autorizaciones previas denegadas. Se añade la documentación no estructurada que los proveedores enviaron junto con las autorizaciones previas.

Si gestiona un plan de atención administrada de Medicaid, la norma asigna al Estado la responsabilidad del opt-in y de la búsqueda de planes anteriores y simultáneos, y el Estado comparte luego el opt-in con usted. La norma no especifica cómo, y no todos los Estados tienen aún un proceso establecido. El envío de las solicitudes, su repetición y la respuesta a otros planes siguen siendo responsabilidad suya en cualquier caso.

**Lo que debería mostrar la respuesta.**

- **Oferta de opt-in.** La proporción de afiliados actuales a quienes se ofreció el opt-in antes del 1 de enero de 2027, y la proporción de nuevos afiliados a quienes se ofreció en el plazo de una semana. Cuente las ofertas, no las respuestas, porque el plazo se refiere a la oferta. Para un plan de Medicaid, pregunte en su lugar qué ha establecido su Estado para la oferta y cómo le llegarán a usted los opt-ins. Si la respuesta es que aún no hay nada, pregunte quién recoge el opt-in mientras tanto y dónde se conserva. Ninguna solicitud se envía sin uno.
- **Puntualidad.** Cuánto tiempo transcurre desde que se dispone del opt-in y de los datos del otro plan hasta el envío de la solicitud. Debe ser una semana o menos. Para los afiliados con un plan simultáneo, la última solicitud repetida debe tener menos de un trimestre de antigüedad.
- **Prueba de intercambio.** En preproducción, en ambas direcciones, con el sistema de pruebas de otro plan de salud o con uno simulado. Su solicitud indica que el afiliado está inscrito con usted y ha dado su opt-in. Su respuesta a la solicitud de ellos está lista en el plazo de un día hábil. Para un afiliado de prueba con más de cinco años de historial, devuelve exactamente los datos descritos anteriormente.

## 5. Un desarrollador de aplicaciones

**Pregúntele a su equipo.** ¿Puede alguien sin cuenta leer la documentación de las cuatro APIs?

**Lo que dice la norma.** Cada API necesita documentación pública: cómo llamarla, qué acepta, qué devuelve y cómo se registra una aplicación. La norma prohíbe «un requisito de registro o creación de cuenta para recibir la documentación». Tampoco puede cobrar una tarifa, enviarla únicamente por correo electrónico, ni obligar a los desarrolladores a leer material promocional o a aceptar recibir mensajes antes de acceder a ella.

La norma también limita cuándo puede denegar el acceso a una aplicación. Si en algún momento deniega o pone fin al acceso de una aplicación a cualquiera de las cuatro APIs, necesita criterios objetivos y verificables aplicados de la misma manera a cada aplicación. La decisión debe basarse en una constatación de que la aplicación pone en riesgo inaceptable los datos de salud de los afiliados en sus sistemas.

**Lo que debería mostrar la respuesta.** Puede verificar la documentación usted mismo. La norma exige que esté publicada en su sitio web o accesible a través de un enlace público, así que comience donde lo haría un desarrollador: la página de inicio de su plan, abierta en una ventana de navegación privada. Desde allí, encuentre la página para desarrolladores y siga los enlaces de cada API. Si no puede encontrarla desde la página de inicio, un desarrollador tampoco podrá. Debería poder leerla toda, incluido cómo registrar una aplicación, sin registrarse, rellenar un formulario de correo electrónico, pagar ni marcar ninguna casilla. Registrar una aplicación puede seguir requiriendo una cuenta. Leer cómo hacerlo no puede requerirla. La documentación que se encuentra en el portal de un proveedor externo detrás de su inicio de sesión no es válida. Para la revocación del acceso a una aplicación, solicite los criterios escritos y quién los aplica.

## 6. CMS y el público

**Pregúntele a su equipo.** ¿Qué informes, avisos para afiliados y páginas exige la norma, quién es responsable de cada uno y dónde puedo verlos?

**Lo que dice la norma.** Parte de la norma no son endpoints en absoluto, sino informes y páginas en lenguaje claro:

- Cifras de uso de la API de Acceso para Pacientes, reportadas a CMS antes del 31 de marzo de cada año, con primera entrega el 31 de marzo de 2026.
- Estadísticas de autorización previa, publicadas en su sitio web antes del 31 de marzo de cada año, con primera publicación el 31 de marzo de 2026.
- Una página que ayude a los afiliados a elegir una aplicación de forma segura y les indique dónde presentar una queja. Aplica al Acceso para Pacientes desde el 1 de enero de 2021.
- Para el Acceso para Proveedores, información en lenguaje claro para los afiliados sobre el intercambio y cómo optar por no participar. Se envía antes de compartir datos por primera vez y luego cada año, y permanece en su sitio web público. Los nuevos afiliados la reciben en el plazo de una semana tras el inicio de la cobertura, o tras la aceptación de la inscripción por parte de CMS si esta es posterior. Para un plan de Medicaid, es en el plazo de una semana tras la inscripción. Los proveedores también reciben instrucciones en lenguaje claro en su sitio web, incluido cómo usar su proceso de atribución.
- Para el Plan a Plan, información en lenguaje claro para los afiliados cuando solicita el opt-in, cada año y en su sitio web público. Un plan de Medicaid la proporciona cada año y en su sitio web. El aviso que acompaña a la solicitud de opt-in es responsabilidad del Estado.

**Lo que debería mostrar la respuesta.** Una lista de cada informe, aviso y página, con un responsable designado. Para los dos informes, la presentación de marzo de 2026 a CMS y la página con las estadísticas. Para cada página, un enlace que pueda abrir. Para los avisos a afiliados, el último envío o mensaje y la fecha en que se realizó.

## 7. Su propio equipo

**Pregúntele a su equipo.** ¿Sabremos cuándo una de estas verificaciones empieza a fallar, y ejecutamos las versiones de los estándares que permite la norma?

**Lo que dice la norma.** Cada una de las cuatro APIs necesita «pruebas y monitorización rutinarias» para garantizar su correcto funcionamiento.

La norma de CMS también nombra los estándares que sigue cada API. Para cada uno, señala una versión en una [lista mantenida por la Oficina del Coordinador Nacional de Tecnología de la Información en Salud (ONC)](https://www.ecfr.gov/current/title-45/section-170.215):

- Las cuatro APIs usan FHIR R4, el estándar base, y US Core, los perfiles estadounidenses construidos sobre él.
- Todas excepto Plan a Plan usan SMART App Launch, el mecanismo por el que una aplicación inicia sesión y se autoriza.
- El Acceso para Proveedores y el Plan a Plan usan Bulk Data, para un grupo completo de pacientes en una sola solicitud.
- El Acceso para Pacientes usa OpenID Connect, para confirmar la identidad del usuario.

Para dos de ellos, la norma de CMS señala versiones antiguas: US Core 3.1.1 y SMART App Launch 1.0.0. La norma de CMS permite usar una versión más reciente si ONC la ha aprobado para su programa de certificación y ninguna otra ley lo prohíbe. El cambio no debe interrumpir el acceso de los usuarios a los datos.

Actualmente la norma no exige las guías de implementación Da Vinci o CARIN, las especificaciones FHIR detalladas para datos de pagadores. Una [norma de CMS propuesta en abril de 2026](https://www.federalregister.gov/documents/2026/04/14/2026-07205/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-interoperability-standards) exigiría CARIN Blue Button, Da Vinci Payer Data Exchange y las guías de autorización previa Da Vinci desde el 1 de octubre de 2027. No es definitiva.

La misma propuesta «recomienda encarecidamente» a los pagadores el uso de herramientas de prueba como Inferno, la herramienta de pruebas de código abierto de ONC, para las pruebas que la norma ya exige. Inferno cuenta con [kits de prueba](https://inferno.healthit.gov/test-kits/) para US Core, SMART App Launch, Bulk Data y las guías CARIN y Da Vinci. Una ejecución exitosa demuestra que las respuestas de una API siguen el estándar. No demuestra que las reclamaciones lleguen a tiempo, que un proveedor vea únicamente a sus propios pacientes, ni que las denegaciones de un proveedor externo incluyan un motivo. Por tanto, responde a parte de esta pregunta, no a las preguntas 1 a 6.

**Lo que debería mostrar la respuesta.**

- **Monitorización.** Las verificaciones de las preguntas 1 a 4 ejecutándose según una programación, con los últimos resultados y la persona que recibe la alerta cuando alguna falla. Una única prueba antes de la puesta en producción no es monitorización.
- **Versiones.** Una línea para cada API y estándar, con la versión correspondiente. Cada versión es la que señala la norma de CMS, o una más reciente aprobada por ONC para su programa de certificación. Para una versión más reciente, el equipo puede explicar por qué el cambio no interrumpió el acceso de nadie a los datos. La lista también indica si cada API sigue las guías CARIN y Da Vinci, para que sepa cuánto trabajo queda por hacer si la propuesta se convierte en norma definitiva.
- **Conformidad.** Para cada API, el último informe de Inferno frente a las versiones de esa lista y las guías que sigue la API, con la fecha en que se ejecutó.

Si alguna línea sigue indicando US Core 3.1.1 o SMART App Launch 1.0.0, el equipo debe tener un plan para migrar. La adopción por parte de ONC de ambos expiró el 1 de enero de 2026, y desde entonces la tecnología de información en salud ya no puede certificarse con ellos. Una [norma definitiva de ONC](https://www.federalregister.gov/documents/2026/10/28/2026-21943/health-data-technology-and-interoperability-onc-deregulatory-actions-to-unleash-prosperity) elimina ambos de su lista el 28 de diciembre de 2026. La propuesta de CMS de abril de 2026 impediría a los pagadores usar una versión expirada, lo que dejaría US Core 6.1.0, diseñado para la versión 3 de USCDI, y SMART App Launch 2.0.0. Hasta que eso sea definitivo, las versiones más recientes están permitidas para los pagadores, pero no son obligatorias.

## Cómo ayuda Health Samurai

Con [Payerbox](/cms-0057-f), la plataforma de Health Samurai para CMS-0057-F, usted obtiene más que un producto: un equipo que le ayuda a responder estas siete preguntas. [Reserve una revisión de preparación de una hora](/contacts) y la realizaremos conjuntamente con su equipo.