Esta página ha sido traducida de manera automática y puede contener errores
DHIS2 y FHIR
DHIS2 admite el uso de FHIR en implementaciones sanitarias.
Los metadatos de los sistemas DHIS2 pueden asignarse a perfiles FHIR estandarizados, lo que proporciona compatibilidad con los perfiles de pacientes FHIR nacionales y las directrices SMART de la OMS.
En esta página, puedes obtener más información sobre herramientas y enfoques para el intercambio y la integración de datos de DHIS2 mediante FHIR
Enlaces directos al contenido de la página
¿Qué es FHIR?
FHIR (Recursos de Interoperabilidad Sanitaria Rápida) es una norma elaborada por el grupo de gestión de FHIR dentro del consorcio HL7.
De la descripción del producto HL7 FHIR:
FHIR es una norma de interoperabilidad destinada a facilitar el intercambio de información sanitaria entre profesionales sanitarios, pacientes, cuidadores, pagadores, investigadores y cualquier otra persona implicada en el ecosistema sanitario.
Consta de 2 partes principales: un modelo de contenido en forma de «recursos», y una especificación para el intercambio de estos recursos en forma de interfaces RESTful en tiempo real, así como mensajería y Documentos.
Mientras que el legado HL7 no ha desaparecido, FHIR utiliza paradigmas RESTful que resultan más familiares a los desarrolladores de aplicaciones web modernas.
Su interés y aceptación han aumentado en los últimos años, y grandes proveedores como Microsoft, Google, Epic y otros han creado herramientas e interfaces compatibles con FHIR.
También ha habido un interés y un trabajo considerables en la comunidad internacional de desarrollo, como la comunidad OpenHIE y los grupos de trabajo técnicos de la OMS.
FHIR define una rica ontología de recursos base como Paciente, Observación, ValueSet, CodeSystem, etc.
La rápida evolución de FHIR ha dado lugar a la necesidad de establecer distintos niveles de madurez para los distintos recursos.
Así, aunque está en desarrollo bastante constante, hay un subconjunto cada vez mayor de recursos que han alcanzado el estatus normativo.
Los recursos base se definen teniendo en cuenta la extensibilidad y la personalización.
Los campos y codificaciones necesarios para describir a un Paciente en Estados Unidos, por ejemplo, pueden diferir sustancialmente de los necesarios en Noruega o Sierra Leona.
El proceso de personalización, ampliación y restricción de los recursos base se conoce como elaboración de perfiles. Establecer un consenso en torno a los perfiles es una actividad clave para establecer la interoperabilidad real entre los sistemas participantes.
En términos de DHIS2, esto es similar a las Instancias de Entidad Rastreada (TEI): el hecho de que dos sistemas DHIS2 admitan TEI no implica necesariamente que puedan intercambiar datos sin armonizar atributos, conjuntos de opciones, etc.
Los recursos FHIR de base se gestionan a través del grupo de gestión HL7 FHIR, pero cualquier organización puede crear y publicar perfiles.
Así, por ejemplo, es una actividad habitual que las jurisdicciones nacionales creen perfiles nacionales.
Ha habido algún intento de armonizar estas actividades a través de esfuerzos como el Resumen Internacional de Pacientes. Un concepto relacionado con el perfil FHIR es la Guía de Implementación FHIR (IG).
Las GI proporcionan una forma consistente de describir colecciones relacionadas de recursos FHIR perfilados para abordar dominios problemáticos concretos.
Suelen incorporar artefactos legibles por máquina, así como texto narrativo, ejemplos, etc.
DHIS2 en FHIR
DHIS2, como casi todos los sistemas de software sanitario digital grandes y consolidados, se construye en torno a un modelo de datos que ha evolucionado durante muchos años para satisfacer eficazmente una gran variedad de casos de uso dentro del ámbito sanitario y más allá.
El modelo es estable, robusto y está bien documentado.
Vemos FHIR como una norma de interoperabilidad, más que como un sustituto de nuestro modelo interno.
Por tanto, el reto consiste en crear correspondencias eficaces entre los recursos del modelo DHIS2 y los recursos equivalentes o similares del modelo FHIR.
Este reto no es trivial, ya que ambos modelos son muy personalizables y extensibles.
Así que abordamos el problema de forma incremental e iterativa, prefiriendo basar nuestro enfoque en aplicaciones concretas.
Técnicamente, esto implica el uso de transformaciones, interfaces y fachadas, que traducen los recursos FHIR al modelo de datos DHIS2 subyacente utilizando un marco de integración como Apache Camel (por ejemplo, transformando una Instancia de Entidad Rastreada (TEI) en un perfil de paciente FHIR).
Esto se describe con más detalle en la sección de tecnología más adelante.
Este enfoque ya se ha utilizado con éxito en el mundo real.
Por ejemplo, como parte de nuestro trabajo con la implementación regional de seguridad de las vacunas (ESAVI) de la OPS, que utiliza una versión personalizada del paquete de metadatos DHIS2 ESAVI Tracker para recopilar datos que se mapean en un Cuestionario con perfil FHIR para facilitar el intercambio de datos con otros sistemas, y que posteriormente puede soportar la compatibilidad con la base de datos mundial de farmacovigilancia Vigibase.
Este es un buen ejemplo de un proceso de interoperabilidad basado en las necesidades del mundo real en un contexto nacional o regional concreto, a diferencia de los proyectos basados en planos abstractos, que suelen ser más difíciles y menos impactantes.
En todos los casos que hemos explorado hasta ahora, hemos podido transformar con éxito los datos de DHIS2 en FHIR.
El equipo de integración de DHIS2 sigue trabajando con socios locales y globales en las necesidades específicas de FHIR y en el desarrollo de enfoques genéricos que puedan compartirse y adaptarse.
Si tienes algún problema que necesites resolver con FHIR, ponte en contacto con nosotros: integration@dhis2.org
Ejemplos de capacidades actuales
Asignación a Cuestionario / CuestionarioRespuesta: Los Cuestionarios FHIR proporcionan un mecanismo conveniente para la interoperabilidad entre sistemas que no comparten necesariamente la misma colección rica de recursos FHIR específicos del dominio.
Los Repositorios FHIR nativos pueden mapear Cuestionarios utilizando, por ejemplo, SDC (Captura de datos estructurada).
Del mismo modo, en DHIS2 podemos asignar formularios de entrada de datos agregados y de seguimiento a Cuestionarios.
El Cuestionario abstrae la diferencia en el modelo de datos en ambos lados.
Como ya se ha dicho, la OPS ha utilizado eficazmente este enfoque en el intercambio de datos de seguimiento.
También estamos trabajando actualmente en un mapeo normalizado entre los conjuntos de datos agregados de DHIS2 y los Cuestionarios FHIR. Mapeo a Recurso Paciente: Un perfil FHIR específico en el que nos hemos centrado es el Estándar Internacional del Paciente (IPS).
El equipo de DHIS2 ha traducido los metadatos del Rastreador de DHIS2 a una carga útil de Paciente conforme con IPS.
Esto nos permitirá, con el tiempo, admitir la importación y exportación de datos demográficos de pacientes (por ejemplo, en la remisión de pacientes en forma de resumen internacional de pacientes). Exponer metadatos DHIS2 como recursos FHIR: Hemos desarrollado transformaciones para expresar conjuntos de opciones DHIS2 y unidades organizativas como ValueSets FHIR y recursos compatibles con mCSD.
Generalizando a partir de esta experiencia, estamos trabajando para que las implementaciones puedan exponer y describir sus metadatos estructurales de forma más general utilizando FHIR.
Utilizando las herramientas que hemos desarrollado hasta ahora, es posible tomar algunos aspectos de los metadatos de DHIS2 y elaborar a partir de ellos una guía de implementación de FHIR.
Esto significa que los países y organizaciones que utilizan DHIS2 como entorno nacional de autoría (para recopilar datos sobre pacientes, informes agregados, etc.) -que es una función típica de DHIS2 dentro de la arquitectura de información sanitaria digital de un país- pueden generar perfiles FHIR que representen la información que hay en su instancia de DHIS2.
Tecnología
El equipo de integración de DHIS2 utiliza el middleware de código abierto Apache Camel para diversos proyectos de integración.
Para facilitar la vida a los ingenieros de integración, hemos desarrollado una biblioteca cliente java de DHIS2 y un componente Camel de DHIS2, que facilita la creación de rutas entre los puntos finales de DHIS2 y otros componentes Camel (como FHIR, HL7v2x, etc.).
Nos ha resultado especialmente útil para admitir formatos de datos y transformaciones FHIR.
Existen otras opciones de middleware, pero hemos elegido Apache Camel por su flexibilidad, madurez y amplio uso en diversos sectores, lo que significa que ya existen muchos conectores para él que pueden ayudar a vincular DHIS2 con cualquier sistema con el que los países quieran integrarlo.
Hay varios ejemplos de usos similares de Camel para transformar datos de salud, como la herramienta ETL OpenMRS, el puente OpenEHR FHIR y la Plataforma de Integración de la Sanidad Electrónica Abierta. Este enfoque funciona comunicándose con la instancia DHIS2 en un lado del conector Apache Camel, y luego realizando una transformación que traduce los datos DHIS2 al formato FHIR.
Hay dos métodos para hacerlo:
- Soneto de datos: Es un procesador para mapear un formato de datos a otro.
Por ejemplo, puedes escribir un mapa Data Sonnet que traduzca una Instancia de Entidad Rastreada a un Resumen Internacional de Paciente FHIR.
Éste ha sido el enfoque más popular hasta ahora, y lo utiliza, entre otros, el equipo del Paquete de Metadatos DHIS2.
Una vez creados los mapas de Data Sonnet, los usuarios pueden modificarlos sin tener que editar ningún código, simplemente actualizando los mapeos pertinentes.
El equipo de Integración de DHIS2 ha creado ejemplos y tutoriales para Data Sonnet, que puedes encontrar a continuación. - Código Java: La transformación de datos también puede hacerse procedimentalmente utilizando código Java con la biblioteca HAPI FHIR.
Apache Camel tiene un componente FHIR que incluye esta biblioteca.
Explora las herramientas y ejemplos actuales de integración DHIS2-FHIR
Componente DHIS2 Camel
Una envoltura de Apache Camel para la Biblioteca Cliente DHIS2 que permite a los usuarios utilizarla en rutas Camel (donde se definen los flujos de trabajo de integración). Explorar en GitHub
Paquete DHIS2 a FHIR
Muestra cómo los recursos DHIS2, como las unidades organizativas, pueden convertirse en paquetes FHIR antes de cargarlos en un servidor FHIR como HAPI FHIR. Explorar en GitHub
Paquete DHIS2 a FHIR con DataSonnet
Muestra cómo los recursos DHIS2, como las unidades organizativas, pueden asignarse a paquetes FHIR con DataSonnet antes de cargarlos en un servidor FHIR como HAPI FHIR. Explorar en GitHub
Historias de impacto: Integración DHIS2-FHIR
En las historias que aparecen a continuación, puedes leer cómo los países y las organizaciones están utilizando FHIR con DHIS2 para hacer frente a las necesidades del mundo real.
Contacta con nosotros para soporte de integración FHIR
El equipo de integración de DHIS2 está encantado de trabajar con los socios del país para abordar necesidades concretas de FHIR.
Nuestro enfoque incremental de FHIR significa que dependemos de casos de uso del mundo real para impulsar el desarrollo.
Si tienes un proyecto concreto de integración de FHIR relacionado con DHIS2, ponte en contacto con nosotros: integration@dhis2.org