El 7.º CMS HL7 FHIR Connectathon anual se celebró del 14 al 16 de julio de 2026, un evento virtual gratuito organizado por los Centers for Medicare & Medicaid Services (CMS) junto con HL7 International. Su propósito es la prueba práctica: los implementadores confrontan flujos de trabajo FHIR reales entre sí, resuelven juntos los puntos conflictivos y se anticipan a los requisitos de interoperabilidad de CMS y ONC que entrarán en vigor próximamente.
Para los planes de salud, esos requisitos se rigen por un calendario concreto. CMS-0057-F pone en vigor la Prior Authorization API y la Payer-to-Payer API el 1 de enero de 2027.
Llevamos Payerbox, nuestra plataforma de cumplimiento FHIR para planes de salud, a dos tracks: Burden Reduction y PDex, probando directamente frente a otros sistemas de pagadores y proveedores. A continuación explicamos qué ejecutamos, qué falló y qué cambiamos.
Track de Burden Reduction
En el track de Da Vinci Burden Reduction (CRD, DTR y PAS: la pila de autorización previa electrónica), Payerbox ocupó el lado del pagador. Nuestro servidor alojó los servicios CDS Hooks, los cuestionarios DTR y las operaciones PAS, y los proveedores de EHR probaron sus implementaciones del lado del proveedor frente a él. Durante dos días celebramos sesiones con seis proveedores de EHR: Epic, MEDITECH, Darena Health, MEDHOST, Oracle Health y Altera Digital Health. Gracias a los seis equipos por llegar bien preparados.
El escenario compartido fue una autorización previa de terapia de oxígeno domiciliario. Un hook order-sign de CRD devuelve una tarjeta de «autorización previa requerida» que incluye una acción del sistema coverage-information que apunta a un cuestionario DTR; el clínico completa el formulario prepoblado y el bundle resultante se envía a Claim/$submit de PAS, que devuelve un ClaimResponse en cuestión de segundos. A continuación llega la decisión de gestión de utilización, que el EHR recoge mediante $inquire.
Más allá de ese flujo ideal, ejercitamos los cuatro hooks CRD que Payerbox implementa (order-sign, order-select, order-dispatch y appointment-book), el $questionnaire-package de DTR, el $inquire de PAS, el $submit-attachment de CDex, y los flujos de actualización y cancelación de reclamaciones. La cadena completa, desde la tarjeta CRD hasta el formulario DTR y la presentación PAS, se ejecutó de extremo a extremo con sistemas EHR reales como motor. En varias ejecuciones, los identificadores generados en nuestra respuesta CRD nos llegaron de vuelta dentro de la presentación PAS del socio. Eso es una buena prueba de que las piezas se conectan, y requirió un esfuerzo de ingeniería real en ambos lados.
Qué corregimos
Los clientes EHR en activo generaron una lista priorizada de defectos. Una categoría de correcciones se publicó durante el evento, en el segundo día: relajamos la estrictez de la validación para que las discrepancias en cadenas de visualización y referencias inofensivas generen advertencias en lugar de bloqueos, mientras que los envíos genuinamente incompletos siguen recibiendo una respuesta de error clara. Un payload que falló en una sesión de la mañana superó la repetición esa misma tarde.
El resto se incorporó durante los tres días siguientes:
- Cancelación de reclamación de extremo a extremo, de modo que una autorización previa cancelada sea visible a través de
$inquire. - Las aserciones de cobertura pasaron a ser decisiones definitivas en lugar de condicionales.
- Prepoblación de cuestionarios: siete cuestionarios nunca se precargaban porque sus contextos de lanzamiento no estaban vinculados, algo que solo surgió cuando clientes DTR reales abrieron formularios reales.
- Las solicitudes de hooks CRD con
fhirServer: nullse rechazaban cuando una clave ausente era aceptada; los valores nulos explícitos ahora se tratan como ausentes. - Cierre de bundle PAS: los recursos restantes de un intercambio CRD anterior ya no cuentan como referencias conocidas por el pagador, por lo que
$submitrechaza correctamente un bundle que no es autocontenido.
Qué enviamos de vuelta
Proporcionamos a los socios notas sobre la autocontención del bundle PAS (qué recursos referenciados deben viajar dentro del bundle de presentación) y sobre la señalización de lanzamiento DTR en CRD 2.1, donde la acción del sistema coverage-information reemplaza el patrón antiguo de enlace en tarjeta, además de varias observaciones menores sobre datos de prueba.
Track de PDex
En el track de Da Vinci Payer Data Exchange (PDex) probamos Payerbox frente a otros tres sistemas: InterSystems, Hike Health y CareEvolution. Gracias a los tres equipos por realizar pruebas frente a nosotros. El objetivo era el flujo payer-to-payer completo de extremo a extremo: emparejamiento de miembros mediante $bulk-member-match, seguido de exportación masiva de datos mediante $davinci-data-export.
Los equipos que se integraron con nosotros generaron su propia lista priorizada. La mayor parte se agrupó en torno a unos pocos temas:
- alinear nuestro CapabilityStatement con la forma en que el IG espera que se declaren las operaciones PDex
- relajar algunas validaciones estrictas y comprobaciones del cuerpo de la solicitud que dificultaban el trabajo de los socios
- refinar nuestros filtros de exportación masiva
- facilitar la lectura del enrutamiento basado en consentimiento de miembros emparejados cuando un miembro queda restringido
Nada de esto es estructural. Son los detalles de interoperabilidad que solo afloran frente a contrapartes en activo. Cada uno está registrado como incidencia independiente y ninguno está cerrado en el momento de la publicación, que es el estado honesto de un track al que nos presentamos precisamente para encontrar esto.
También transmitimos observaciones: algunas implementaciones no realizaron validación de referencias ni FHIR durante el evento, y una mostró una discrepancia entre los recuentos de emparejamiento síncrono y asíncrono.
Provider Access
El mismo track cubre Provider Access, otra de las cuatro API de CMS-0057-F, y nuestra sesión con InterSystems abarcó ambas. Provider Access reutiliza la mayor parte de la maquinaria payer-to-payer: $provider-member-match resuelve los miembros atribuidos a un proveedor solicitante, y el mismo $davinci-data-export entrega sus datos de reclamaciones, clínicos y de autorización previa. Vale la pena ser explícitos sobre la forma, porque es la parte que los pagadores con más frecuencia deben rediseñar: se trata de una exportación masiva sobre un grupo atribuido, no de una consulta por paciente bajo demanda. La lista de defectos anterior provino de los escenarios payer-to-payer.
Qué significa esto para los pagadores
CMS-0057-F no incluye un examen. No existe ningún organismo de pruebas autorizado ni ninguna suite de pruebas obligatoria como la que existe para los EHR certificados por ONC, y las herramientas de conformidad como Touchstone existen pero no son obligatorias. Por tanto, nada certifica que una Prior Authorization o una Payer-to-Payer API funcionen. La única evidencia es que se ha ejecutado frente a contrapartes que no se controlan.
Eso es lo que ofrece un connectathon, y es por eso que las listas de defectos anteriores son la parte útil de este artículo. Cada elemento de ellas provino del payload de un socio, no de nuestra propia suite de pruebas: un contexto de lanzamiento no vinculado que dejó un cuestionario en blanco, un bundle que parecía autocontenido hasta que un EHR real lo envió, un valor nulo donde nuestro esquema esperaba una clave ausente. Nada de esto es alcanzable probando contra uno mismo.
Por eso, cuando evalúe la preparación, la propia o la de un proveedor, esa es la pregunta que vale la pena formular antes de enero de 2027: ¿frente a qué contrapartes en activo se ha ejecutado esto, y qué falló cuando se encontró con ellas?
Pruébelo usted mismo
¿Desea probar frente a Payerbox del mismo modo que lo hicieron nuestros socios en el connectathon? Podemos configurarle los escenarios que ejecutamos durante el evento: emparejamiento de miembros y exportación masiva en el lado PDex, y CRD, DTR y PAS en el lado de Burden Reduction. Solicite acceso y le pondremos en marcha.
Si está desarrollando payer-to-payer exchange o autorización previa electrónica en FHIR y simplemente desea intercambiar experiencias, póngase en contacto con nosotros. Nos encantaría saber de usted.
