Esta página ha sido traducida de manera automática y puede contener errores
DHIS2 y FHIR
DHIS2 apoya el uso de FHIR en las 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, puede obtener más información sobre herramientas y enfoques para el intercambio y la integración de datos DHIS2 mediante FHIR
Enlaces directos al contenido de la página
¿Qué es FHIR?
FHIR (Fast Healthcare Interoperability Resources) es un estándar elaborado por el grupo de gestión de FHIR dentro del consorcio HL7. De la descripción del producto HL7 FHIR:
FHIR es un estándar de interoperabilidad destinado 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 dos partes principales: un modelo de contenidos 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 hace uso de 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 del desarrollo, incluida la comunidad OpenHIE, así como en los grupos de trabajo técnicos de la OMS.
FHIR define una rica ontología de recursos base como Patient, Observation, ValueSet, CodeSystem, etc. La rápida evolución de FHIR ha dado lugar a la necesidad de establecer diferentes niveles de madurez para los distintos recursos. Así que, aunque está en constante desarrollo, cada vez hay más recursos que han alcanzado un estatus normativo.
Los recursos de base se definen pensando en 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 exigidos en Noruega o Sierra Leona. El proceso de personalización, ampliación y restricción de los recursos de 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 de HL7 FHIR, pero cualquier organización puede crear y publicar perfiles. Así, por ejemplo, es habitual que las jurisdicciones nacionales creen perfiles nacionales. Ha habido algunos intentos de armonizar estas actividades a través de iniciativas como el Resumen Internacional de Pacientes.
Un concepto relacionado con el perfil FHIR es la Guía de Implementación FHIR (IG). Los GI proporcionan una forma coherente 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, al igual que casi todos los sistemas informáticos sanitarios digitales de gran envergadura, se basa en un modelo de datos que ha evolucionado a lo largo de muchos años para satisfacer eficazmente una amplia gama de casos de uso en el ámbito sanitario y fuera de él. El modelo es estable, sólido y está bien documentado. Vemos FHIR como un estándar de interoperabilidad, más que como un sustituto de nuestro modelo interno. Así pues, 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 ampliables. Por eso abordamos el problema de forma gradual e iterativa, prefiriendo basar nuestro planteamiento 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 dedicada a la tecnología.
Este enfoque ya se ha utilizado con éxito en el mundo real. Por ejemplo, como parte de nuestro trabajo con Aplicación de la seguridad regional de las vacunas de la OPS (ESAVI)que utiliza una versión adaptada del rastreador DHIS2 AEFI paquete de metadatos recoger datos que se asignen a un cuestionario con perfil FHIR para facilitar el intercambio de datos con otros sistemas, y que posteriormente puedan ser compatibles con la base de datos mundial de farmacovigilancia Vigibase. Se trata de un buen ejemplo de proceso de interoperabilidad basado en las necesidades reales de un país o una región concretos, a diferencia de los proyectos basados en planos abstractos, que suelen ser más difíciles y tener menos impacto.
En todos los casos que hemos explorado hasta ahora, hemos podido transformar con éxito los datos DHIS2 en FHIR. El equipo de integración de DHIS2 sigue trabajando con socios locales y mundiales en las necesidades específicas de FHIR y en el desarrollo de enfoques genéricos que puedan compartirse y adaptarse. Si tiene algún problema que necesite resolver con FHIR, póngase en contacto con nosotros: integration@dhis2.org
Ejemplos de capacidades actuales
Correspondencia con Questionnaire / QuestionnaireResponse: Los Cuestionarios FHIR proporcionan un mecanismo conveniente para la interoperabilidad entre sistemas que no necesariamente comparten la misma colección rica de recursos FHIR específicos del dominio. Los Repositorios FHIR nativos pueden mapear Cuestionarios utilizando, por ejemplo, SDC (Structured data Capture). Del mismo modo, en DHIS2 podemos asignar formularios de entrada de datos de seguimiento y agregados a cuestionarios. El cuestionario hace abstracción de la diferencia en el modelo de datos de ambas partes.
Como ya se ha comentado, la OPS ha utilizado eficazmente este enfoque con el intercambio de datos de seguimiento. También estamos trabajando actualmente en un mapeo estandarizado entre los conjuntos de datos agregados de DHIS2 y los Cuestionarios FHIR.
Asignación a recursos de pacientes: 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 de DHIS2 Tracker a una carga útil Paciente conforme con IPS. Con el tiempo, esto nos permitirá apoyar la importación y exportación de datos demográficos de los pacientes (por ejemplo, en la remisión de pacientes en forma de resumen internacional de pacientes).
Exposición de metadatos DHIS2 como recursos FHIR: Hemos desarrollado transformaciones para expresar conjuntos de opciones y unidades de organización de DHIS2 como ValueSets de 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 producir una guía de implementación de FHIR a partir de ellos. 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 se encuentra 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 hacer la vida más fácil 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 soportar los formatos y transformaciones de datos FHIR. Existen otras opciones de middleware, pero hemos seleccionado Apache Camel debido a su flexibilidad, madurez y amplio uso en una variedad de industrias, 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. Existen varios ejemplos de usos similares de Camel para transformar datos sanitarios, como la herramienta ETL OpenMRS, el puente OpenEHR FHIR y la plataforma Open eHealth Integration Platform.
Este enfoque funciona mediante la comunicación con la instancia DHIS2 en un lado del conector Apache Camel y, a continuación, realiza una transformación que traduce los datos DHIS2 al formato FHIR. Hay dos métodos para hacerlo:
- Soneto de datos: Se trata de un procesador para mapear un formato de datos a otro. Por ejemplo, puede escribir un mapa Data Sonnet que traduzca una Instancia de Entidad Rastreada a un Resumen Internacional de Paciente FHIR. Este ha sido el enfoque más popular hasta el momento, y es el utilizado por el equipo del Paquete de Metadatos DHIS2, entre otros. Una vez creados los mapas de Data Sonnet, los usuarios pueden modificarlos sin tener que editar ningún código, simplemente actualizando los mapeos correspondientes. El equipo de integración de DHIS2 ha creado ejemplos y tutoriales para Data Sonnet, que se pueden encontrar a continuación.
- Código Java: La transformación de datos también se puede realizar de forma procedimental utilizando código Java con la biblioteca HAPI FHIR. Apache Camel tiene un componente FHIR que incluye esta biblioteca.
Explore las herramientas y ejemplos actuales de integración DHIS2-FHIR
Componente DHIS2 Camel
Una envoltura de Apache Camel para la biblioteca de clientes DHIS2 que permite a los usuarios utilizarla en rutas Camel (donde se definen los flujos de trabajo de integración).
Paquete DHIS2 a FHIR
Muestra cómo los recursos DHIS2, como las unidades de organización, pueden convertirse en paquetes FHIR antes de cargarse en un servidor FHIR como HAPI FHIR.
Paquete DHIS2 a FHIR con DataSonnet
Muestra cómo los recursos DHIS2, como las unidades de organización, se pueden asignar a paquetes FHIR con DataSonnet antes de cargarlos en un servidor FHIR como HAPI FHIR.
Historias de impacto: Integración DHIS2-FHIR
En las siguientes historias, puede leer cómo los países y las organizaciones están utilizando FHIR con DHIS2 para hacer frente a las necesidades del mundo real.
Póngase en contacto con nosotros para obtener asistencia sobre la integración de FHIR
El equipo de integración de DHIS2 está encantado de trabajar con los socios nacionales para abordar las necesidades concretas de FHIR. Nuestro enfoque gradual de FHIR significa que dependemos de casos de uso reales para impulsar el desarrollo. Si tiene un proyecto específico de integración FHIR relacionado con DHIS2, póngase en contacto con nosotros: integration@dhis2.org