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?
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.
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.
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.