Presentamos FHIR Connect

FHIR Connect es un nuevo y emocionante servicio en Better Digital Health Platform (DHP) con un marco abierto e independiente del proveedor que se puede usar para integrar aplicaciones de Fast Healthcare Interoperability Resources (FHIR) con un repositorio de datos clínicos openEHR.

Está diseñado para admitir la traducción de la mayoría de los tipos de recursos FHIR a través de una especificación abierta basada en la configuración. Los desarrolladores ciudadanos, con el conocimiento adecuado de FHIR y openEHR, de proveedores de software independientes, integradores de sistemas y proveedores de atención médica podrán usar FHIR Connect para construir o reutilizar rápidamente interfaces FHIR bidireccionales que se comunican sin problemas con un repositorio openEHR. 

¿Por qué estamos haciendo esto?  
FHIR se ha establecido como el estándar "de facto" para el intercambio de información de salud y atención, con un número cada vez mayor de aplicaciones que ahora brindan soporte FHIR nativo. Además de esto, muchos sistemas de atención médica están colocando a openEHR en el centro de sus arquitecturas, ayudándolos a establecer ecosistemas de servicios disruptivos e innovadores centrados en el paciente (consulte Por qué openEHR se está comiendo la atención médica). 

En Better, creemos que FHIR y openEHR son dos estándares complementarios que deben combinarse para crear un ecosistema abierto e interoperable. Hemos publicado nuestros pensamientos sobre esto en una variedad de publicaciones (incluido FHIR + openEHR), pero es una opinión que ahora tiene cada vez más una comunidad más amplia, incluido Microsoft, quien recientemente anunció su soporte para openEHR y la importancia de complementarlo con FHIR. 

Hasta ahora, ha sido posible combinar estos estándares, pero era una tarea compleja que generalmente involucraba el desarrollo de software o mapeos complejos dentro de un motor de integración propietario. Además, muchas soluciones existentes no admiten mapeos bidireccionales o requieren que la información se duplique en cachés. Cuando se han definido mapeos, por lo general no se pueden reutilizar, lo que limita la adopción de estos estándares para que funcionen mejor juntos.

¿Cuáles son los beneficios de FHIR Connect? 

• Las definiciones de mapeo son abiertas e independientes del proveedor: siguiendo el enfoque que hemos adoptado para Better Studio Widgets (consulte este enlace), planeamos abrir la especificación de mapeo central, lo que permite que surja una comunidad en torno a la convergencia de FHIR y openEHR. 
• Las asignaciones son reutilizables globalmente y configurables localmente: hemos creado un enfoque innovador de asignación dual que permite establecer un conjunto básico de asignaciones reutilizables entre los arquetipos openEHR y los recursos FHIR. Una capa adicional de asignaciones contextuales permite definir el contexto de un caso de uso específico utilizando plantillas openEHR y el artefacto FHIR correspondiente: un recurso, perfil, paquete o guía de implementación2. 
• Las asignaciones son bidireccionales: muchas soluciones de asignación existentes solo pueden aplicar asignaciones en una dirección. Hemos diseñado FHIR Connect para aplicar implícitamente un solo conjunto de asignaciones en cualquier dirección: FHIR para abrirEHR o abrirEHR para FHIR. 
• Proporciona una plataforma para el desarrollo ciudadano: según Gartner, "para 2023, la cantidad de desarrolladores ciudadanos activos en las grandes empresas será al menos cuatro veces la cantidad de desarrolladores profesionales". Creemos que este movimiento incluirá el desarrollo de interfaces, además de las aplicaciones tradicionales orientadas al usuario. FHIR Connect se ha diseñado de una manera que permitirá que la definición de mapeos de FHIR y openEHR se exprese utilizando herramientas de código bajo1.

La idea central detrás de FHIR Connect es su enfoque de mapeo dual que permite establecer un conjunto central de mapeos reutilizables, con un grupo adicional de mapeos contextuales, alineados con un caso de uso específico, que los implementadores pueden configurar localmente. 

El primer conjunto de mapeos, llamado Model Mappings, se encuentra entre los arquetipos openEHR y los recursos FHIR. Esto representa un mapeo entre las dos unidades comparables más pequeñas de información semántica según ambos estándares y, como resultado, permite que estos mapeos sean reutilizables globalmente donde se implementan los arquetipos y la versión FHIR dados. 

El segundo conjunto de asignaciones, llamado Asignaciones contextuales, permite manejar el contexto de un caso de uso específico. En openEHR este contexto siempre está representado por una plantilla. En el lado de FHIR, este contexto podría ser una variedad de artefactos de FHIR que incluyen un recurso, un perfil, un paquete o una guía de implementación2. 

En tiempo de ejecución, un motor de mapeo evaluará el contexto de cada solicitud y aplicará la lógica de mapeo adecuada. Dado que openEHR es más descriptivo, debido a su enfoque de modelado máximo, el enfoque para procesar asignaciones de modelos siempre va en la dirección de FHIR a openEHR. 

Además, la especificación de mapeo permitirá el uso de palabras clave funcionales que aplicarán la lógica comercial condicional. Por ejemplo, para filtrar una lista de observaciones para que coincida con un código SNOMED o LOINC determinado. Como el alcance de FHIR Connect está dirigido específicamente a FHIR y openEHR, podemos ser específicos y opinar sobre las palabras clave que admitimos y cómo se implementan. 

El siguiente diagrama presenta una descripción general de alto nivel de la arquitectura. 

¿Qué casos de uso admitirá FHIR Connect?  
Los siguientes patrones arquitectónicos son los que hemos visto con mayor frecuencia cuando trabajamos con nuestros clientes. Hemos diseñado FHIR Connect para que sea modular, de modo que pueda conectarse a cualquiera de estos escenarios. 

• Patrón 1 — Fachada: Se introduce un componente de traducción para traducir las solicitudes FHIR entrantes y salientes a un repositorio openEHR. Por lo general, junto con esto, las API de openEHR se utilizarán para admitir un conjunto completo de funcionalidades. Nota: en este modelo, FHIR Connect no está diseñado para admitir el conjunto completo de capacidades del servidor FHIR, sino que se centra en la funcionalidad de mapeo alineada con las operaciones básicas de creación, lectura, actualización y búsqueda. 
• Patrón 2- agente de mensajes: un motor de integración actúa como un agente de mensajes para traducir los mensajes entrantes de aplicaciones externas. 
• Patrón 3- Agente de sincronización: existe un agente de sincronización para copiar un grupo definido de elementos de datos entre un repositorio FHIR y openEHR. 

llustración por ejemplo 
En HIMSS Europe esta semana lanzamos FHIR Connect. Como gran parte de la funcionalidad se ejecuta como un servicio en segundo plano, hemos utilizado un escenario simple, con las siguientes personas de usuario para ilustrarlo en acción.   

En este ejemplo, FHIR Connect se configuró para ejecutarse dentro de un agente de sincronización, junto con Azure Health Data Services. El escenario comienza con nuestro pediatra, Patrick, completando un formulario creado con Better low-code Studio. Estos datos de openEHR se convierten a FHIR y se guardan en Azure Health Data Services. Para ilustrar cómo se puede utilizar esta tecnología para facilitar el desarrollo de un ecosistema, nuestra endocrinóloga pediátrica, Andjela, accederá a través de Microsoft Teams a una aplicación de tablas de crecimiento de terceros del Boston Children's Hospital, que se comunica mediante FHIR.

¿Cómo se evalúan las asignaciones? 
Cuando Patrick completa el formulario, se desencadena un evento que FHIR Connect consume. Los metadatos del evento contienen información sobre la plantilla openEHR, por lo que tenemos toda la información que necesitamos para identificar el contexto. A continuación se muestra un ejemplo del Mapeo Contextual para este caso de uso3. 

Con el mapeo contextual a la mano, ahora tenemos una lista de los arquetipos de openEHR que se esperan en la carga útil. Luego, cada mapeo de modelo publicado se evalúa en comparación con la carga útil, que se filtra para contener solo el alcance del arquetipo actual. Las asignaciones se aplican y los recursos FHIR asociados se recopilan en un paquete. 

El mapeo del modelo para la altura del cuerpo se muestra a continuación. 

La lógica de procesamiento si se va en la otra dirección (FHIR a openEHR) sería ligeramente diferente, pero las asignaciones en sí permanecerían sin cambios, lo que garantiza que nuestras asignaciones sean bidireccionales para todos los casos de uso. 

Una vez que tenemos el paquete FHIR ensamblado, se publica en Azure Health Data Services, lo que permite que el ecosistema de Azure más amplio use estos datos, incluido PowerBI u otras herramientas analíticas como Azure Synapse o Data Bricks. 

¿Que sigue?  
Continuaremos trabajando con nuestros clientes y socios para desarrollar FHIR Connect para respaldar sus casos de uso. Nuestro enfoque inicialmente estará en las siguientes áreas, pero agradeceríamos recibir comentarios sobre cómo podemos desarrollar mejor FHIR Connect para acelerar la convergencia de FHIR y openEHR. 

• Especificación de FHIR Connect - pronto publicaremos la especificación de FHIR Connect para que la comunidad pueda contribuir a esta iniciativa emergente. 
• Asignaciones predeterminadas - trabajaremos para publicar un conjunto básico de asignaciones alineadas con los artefactos FHIR y openEHR más comunes.
• Estudio de código bajo - proporciona una interfaz de usuario que permitirá configurar los archivos de mapeo de una manera más visual. 

Hemos recibido comentarios fantásticos sobre FHIR Connect durante HIMSS y esperamos seguir desarrollando este producto para ayudar a brindar acceso a mejores datos y una mejor atención. No dude en ponerse en contacto con cualquiera de los autores de este artículo si desea analizarlo con más detalle. 

Autores 

Jake Smolka 
Matija Polajnar 
Alastair Allen 
Boštjan Lah 
Andjela Pavlović 

Notas

1 A Low code mapping studio is on the roadmap.
2 FHIR Profiles and implementation guides are on the roadmap.
3 The FHIR Connect mapping format for Contextual Mappings and Model Mappings is still subject to change as we implement additional use cases.