El 7.º CMS HL7 FHIR Connectathon anual se celebró del 14 al 16 de julio de 2026, un evento virtual y gratuito organizado por los Centers for Medicare & Medicaid Services (CMS) junto con HL7 International. Su objetivo es la prueba práctica: los implementadores confrontan flujos de trabajo FHIR reales entre sí, resuelven juntos los problemas pendientes y se adelantan a los próximos requisitos de interoperabilidad de CMS y ONC.
Este año participamos en dos tracks, Burden Reduction y PDex Payer-to-Payer, probando nuestras implementaciones directamente frente a otros sistemas de pagadores y proveedores. A continuación se resume el desarrollo de cada uno.
Track Burden Reduction
En el track Burden Reduction de Da Vinci (CRD, DTR y PAS: la cadena de autorización previa electrónica), actuamos en el lado del pagador: nuestro servidor alojaba los CDS hooks, los cuestionarios DTR y las operaciones PAS, mientras los proveedores de sistemas de historia clínica electrónica (EHR) probaban sus implementaciones del lado del proveedor contra él. A lo largo de dos días realizamos sesiones con Epic, MEDITECH, Darena Health, MEDHOST, Oracle Health y Altera Digital Health. Gracias a todos por las pruebas tan bien preparadas. El escenario compartido fue una autorización previa para Terapia de Oxígeno Domiciliario: un hook CRD order-sign devuelve una tarjeta de «autorización previa requerida» con una acción de sistema de información de cobertura que apunta a un cuestionario DTR; el clínico completa el formulario prepopulado y el bundle resultante se envía a PAS Claim/$submit, donde se resuelve en cuestión de segundos. Más allá de ese flujo ideal, ejercitamos los cuatro hooks de CRD, $questionnaire-package de DTR, $inquire de PAS, $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 el envío PAS, funcionó de extremo a extremo con sistemas EHR reales como impulsores. En varias ejecuciones, los identificadores generados en nuestra respuesta CRD nos regresaron dentro del envío PAS del socio. Eso es una buena prueba de que las piezas se conectan, y requirió un esfuerzo de ingeniería real por ambas partes.
Al igual que con PDex, las pruebas contra sistemas reales nos proporcionaron una lista concreta y priorizada de mejoras, y corregimos y redesplazamos la mayoría de ellas durante el propio evento. Un payload que fallaba en una sesión matutina a menudo pasaba en la repetición de esa misma tarde. Algunos ejemplos: el mismo código HCPCS puede llegar bajo varias formas de escritura de URI, por lo que enseñamos al motor de coincidencia de políticas a canonicalizarlos en lugar de depender del que use el EHR. Ajustamos la estrictez de la validación, de modo que los desajustes inofensivos en cadenas de visualización y referencias ahora generan advertencias en lugar de bloqueos, mientras que los envíos genuinamente incompletos siguen recibiendo una respuesta de error clara. También cambiamos las aserciones de cobertura a decisiones definitivas y corregimos problemas de prepopulación de cuestionarios que solo surgían cuando clientes DTR reales abrían formularios reales.
El intercambio fue bidireccional también aquí. Enviamos a los socios notas sobre la autocontención del bundle PAS (qué recursos referenciados deben viajar dentro del bundle de envío) y sobre la señalización de lanzamiento DTR en CRD 2.1, donde la acción de sistema de información de cobertura reemplazó al patrón anterior de enlace en tarjeta, además de algunas observaciones menores sobre datos de prueba. Dos problemas los rastreamos por debajo de nuestro propio código y los reportamos a nuestro proveedor de plataforma FHIR.
Track PDex Payer-to-Payer
En el track Payer Data Exchange (PDex) Payer-to-Payer de Da Vinci, probamos nuestra implementación frente a otros tres sistemas: InterSystems, Hike Health y CareEvolution. Gracias a los participantes por probar nuestra solución. El objetivo era ejercitar el flujo completo de pagador a pagador de extremo a extremo: la concordancia de miembros mediante $bulk-member-match, seguida de la exportación de datos masivos mediante $davinci-data-export.
Las pruebas contra sistemas reales pusieron de manifiesto una lista concreta y priorizada de mejoras por parte de los equipos que se integraban con nosotros. La mayor parte de los comentarios 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, flexibilizar un par de comprobaciones estrictas de validación y cuerpo de solicitud que dificultaban el trabajo de los socios, ajustar nuestros filtros de exportación masiva y facilitar la comprensión del enrutamiento basado en consentimiento de los miembros concordados cuando un miembro resulta restringido. Ninguno de ellos es estructural; son el tipo de detalles de interoperabilidad que solo afloran cuando se prueba contra sistemas reales, y actualmente estamos resolviéndolos.
También trasladamos algunas observaciones a nuestros socios de pruebas; por ejemplo, algunas implementaciones no realizaron ninguna validación de referencias ni de FHIR durante el evento, y una mostró una discrepancia entre los recuentos de concordancia síncrona y asíncrona. Ese intercambio bidireccional es la razón de ser de un connectathon: todos los equipos se marchan con un backlog más claro y más accionable.
Pruébelo Usted Mismo
¿Desea probar nuestra implementación de la misma manera que lo hicieron nuestros socios en el connectathon? Podemos configurarle los mismos escenarios que ejecutamos durante el evento: concordancia de miembros y exportación masiva en el lado PDex, y el flujo CRD, DTR y PAS en el lado Burden Reduction. Póngase en contacto con nosotros y le ayudaremos a comenzar.
Y si está desarrollando el intercambio de pagador a pagador o la autorización previa electrónica en FHIR y simplemente desea compartir experiencias, también nos encantaría saber de usted.
