Durante este año hemos seguido de cerca el desarrollo de una iniciativa que promete facilitar la interoperabilidad entre sistemas de información del sector salud.
Se trata de FHIR® o Fast Healthcare Interoperability Resources (Recursos Rápidos de Interoperabilidad en Salud), la nueva propuesta de especificación de estándares HL7 para el intercambio electrónico de información en salud; cuyo surgimiento obedece a las dificultades de implementación de HL7 V3, a la necesidad de transición de HL7 V2.x y los retos que suponen las nuevas tendencias como Mobile Health y aplicaciones de telefonía móvil, Personal Health Record, intercambio de registros electrónicos de salud o historia clínica electrónica , comunicaciones en la nube y mucho más.
De acuerdo con el sitio web de Health Level Seven: “FHIR® es un marco de estándares de última generación creado por HL7. FHIR® combina las mejores características de las líneas de producto HL7 versión 2, versión 3 y CDA®, al tiempo que aprovecha los últimos estándares web, aplicado un enfoque estricto de implementación” [Ver texto original].
¿Cómo funciona FHIR®?
Para comprender la especificación FHIR®, es necesario familiarizarse con términos como "Recursos", "Elementos Narrativos" y "Extensiones"; además de tener conocimientos previos en los conceptos de "Mensajes" y "Documentos" electrónicos empleados en las especificaciones HL7 V2.X y V3.
Adicional a lo anterior, es necesario comprender el uso de ciertos formatos como XML o JSON y especificaciones de transporte de datos (transferencia de archivos FTP/FTPS, HTTP, MLLP, Mensajería MQ, SOAP, REST).
A continuación, los pondremos en contexto con algunos de éstos términos.
Los recursos.
Los artefactos de interoperabilidad de FHIR® se componen a partir de un conjunto de componentes modulares llamados "Recursos", cuyo contenido ha sido diseñado para el intercambio de datos.
Estos recursos, son representaciones de conceptos empleados en el contexto de la salud (paciente, medicación, observación, etc), que funcionan como bloques de construcción que permiten componer estructuras de mensajes y/o documentos (en forma similar a los arquetipos OpenEHR).
Todos los recursos comparten las siguientes características:
El siguiente es un ejemplo de un recurso tipo "paciente", que contiene la información de identificación básica y datos demográficos del paciente:
El siguiente es un ejemplo de un recurso tipo "observación", que en este caso contiene información de medición de la presión sanguínea:
Todos los recursos comparten las siguientes características:
- Una manera común de definirlos y representarlos, cuya construcción se hace a partir de los tipos de datos que definen patrones comunes de elementos reutilizables (similar a los CMETs de HL7 V3).
- Un conjunto común de metadatos.
- Un elemento para facilitar la legibilidad humana.
La documentación de la especificación FHIR® para cada recurso, contiene una descripción detallada, definiciones formales de los elementos, ejemplos, mapeos (para HL7 V3 y HL7 V2.x) y perfiles.
El siguiente es un ejemplo de un recurso tipo "observación", que en este caso contiene información de medición de la presión sanguínea:
Elementos narrativos.
Los elementos narrativos son segmentos incluidos en cada recurso FHIR®, cuya finalidad es facilitar la legibilidad humana del contenido. Para ello se utiliza un fragmento XHTML, para organizar el resumen de los datos, en forma no estructurada (no codificada).Este tipo de recurso es empleado también dentro de las secciones del cuerpo estructurado XML en CDA®.
Los elementos narrativos en FHIR®, se utilizan opcionalmente dependiendo del escenario de interoperabilidad.
Extensiones.
FHIR®, incorpora el uso de extensiones (similares a los segmentos Z en HL7 V2.x), que permiten incluir información adicional que hace parte de la definición básica de un recurso. Esto permite que FHIR® sea útil en contextos locales e implementaciones específicas.Mensajes.
Los recursos FHIR® se puede utilizar para componer mensajes electrónicos (en forma similar a los segmentos HL7 V2.x).En la mensajería FHIR®, cuando ocurre un evento que desencadena la necesidad de un intercambio electrónico de información, un mensaje se envía desde una aplicación de origen a una aplicación de destino (en forma similar a los mensajes y eventos disparadores en HL7 V3).
FHIR®, cuenta con un recursos tipo MessageHeader, que contiene los metadatos del mensaje. Los demás recursos empleados en la composición del mensaje, depende de la naturaleza del mismo.
La mensajería FHIR®, puede emplear transferencia de archivos (FTP/FTPS), HTTP, MLLP, Mensajería MQ, SOAP, REST o cualquier otro protocolo o metodología de transporte.
Documentos.
Los recursos FHIR® se pueden utilizar para construir documentos clínicos que representan una composición.Los documentos FHIR®, a igual que los documentos CDA®, tienen una serie de características (persistencia, custodia, potencial de autenticación, contexto, integridad y legibilidad humana), que los convierten en una representación de la realidad de un evento clínic.
FHIR® define tanto el formato de documento como el recurso de referencia del documento.
La especificación [Ver texto original]
En términos generales, la especificación FHIR® se divide en 3 partes:- Documentación general: que describe cómo se definen los recursos y se proporcionan material de referencia que incluye las definiciones de tipos de datos, códigos (vocabularios controlados), y los formatos XML y JSON.
- Implementación: que describe cómo utilizar los recursos usando REST, mensajería, documentos clínicos, o mediante una arquitectura basada en servicios.
- Lista de recursos: que contiene todos los recursos definidos por FHIR®. También cuenta con listas específicas de recursos clínicos (medicaciones, diagnósticos, interacción con dispositivos, etc), administrativos (paciente, organización, ordenes, etc) y de infraestructura (listas, manifiesto de documentos, encabezado de mensajes, consultas, etc).
Un poco de historia.
Este proyecto, inicialmente conocido como RFH (Resources For Healthcare), ideado y liderado por Grahame Grieve, Ewout Kramer y Lloyd McKenzie, vio la luz en enero de 2011 (ver proyecto Fresh Look), fue propuesto como especificación en julio y presentado en sociedad durante Working Group Meeting de septiembre del mismo año. A partir de entonces, ha seguido una vertiginosa carrera para convertirse en una especificación normativa de Health Level Seven Inc.
En mayo de 2012, durante Working Group Meeting celebrado en Vancouver, se lanzó la versión 0.01 (First Archived Version), un año despues había alcanzado la version 0.08, (Connectathon celebrado en Atlanta - Mayo de 2013), a finales de 2013 estaba disponible la versión 0.12 DSTU (Draft Standar for Trial Use) y se han incluido varios tutoriales, así como un FHIR Connectathon, en la agenda del Working Group Meeting a realizarse en San Antonio TX, en enero de 2014.
A la fecha, varias organizaciones han manifestado su interés en FHIR®, entre las que se encuentran: AEGIS.net, Inc, GE Healhcare, Mohawk College, NHS England, Open Mapping Software, Oridashi, Orion Health, Standards and Interoperability Framework, University of Western Sydney, Veterans Health Administration - Integrated Electronic Health Record, West Health Institute.
También disponible para JSON.
A pesar que FHIR® utiliza principalmente XML, tanto para para describir los recursos, como para implementar los mensajes, la especificación también incluye documentación para soportar el uso de JSON (JavaScript Object Notation), debido a la creciente popularidad de este formato.
La representación de las estructuras de datos de FHIR® en JSON se basa en la representación XML; los nombres de los objetos en JSON serán iguales que los nombres de los elementos y atributos en XML y actualmente hay suficiente tecnología para facilitar la conversión entre XML y JSON así que los usuarios de FHIR serán libres de elegir si se debe implementar en XML o en JSON, lo cual supone una enorme ventaja.
A continuación se presentan dos (2) ejemplos de recursos FHIR® empleando JSON:
A continuación se presentan dos (2) ejemplos de recursos FHIR® empleando JSON:
¿Qué pasará con HL7 V2.x y HL7 V3?
Tal como ocurre con las versiones vigentes de cualquier estándar, existirá un amplio periodo de convivencia de las versiones disponibles de HL7 y se espera que los usuarios migren paulatinamente sus implementaciones a FHIR®.
El uso de plataformas ESB (IBM WebSphere MQ, Oracle OMF, TIBCO, Microsoft BizTalk, Mule ESB, Intel SOA Express Way, etc) y motores de interoperabilidad (Mirth Connect, Interfaceware Iguana, HL7 Connect, etc), facilitarán el mapeo entre la sintaxis propia de HL7 V2.x y la sintaxis XML de FHIR®.
Por ser un estándar más robusto, contar con un Modelo de Información de Referencia, y emplear XML como tecnología de implementación, las migraciones y mapeos de HL7 V3 a FHIR, serán más sencillas.
FHIR® ha incorporado mecanismos de trazabilidad hacia HL7 RIM y otros importantes modelos de contenido. Esto asegura la alineación de patrones previamente definidos por HL7 y buenas prácticas sin que el implementador requiera un conocimiento profundo del RIM o cualquier derivación HL7 v3 [Ver texto original].
FHIR® ha incorporado mecanismos de trazabilidad hacia HL7 RIM y otros importantes modelos de contenido. Esto asegura la alineación de patrones previamente definidos por HL7 y buenas prácticas sin que el implementador requiera un conocimiento profundo del RIM o cualquier derivación HL7 v3 [Ver texto original].
De igual forma, CDA®, siendo uno de los estándares de uso intensivo entre la comunidad de usuario de HL7, mantendrá su línea de desarrollo y evolución de especificaciones y las instancias existentes eventualmente podrán migrarse a la sintaxis FHIR®, sin que su contenido pierda integridad.
Posteriormente, se recomienda una lectura exhaustiva de los siguientes documentos de la especificación:
¿Por dónde empezar?.
El grupo de trabajo de FHIR®, recomienda empezar por leer rápidamente la lista de recursos, para tener idea de cuales se han desarrollado; luego ver en detalle la definición de algún recurso (por ejemplo: Paciente), para posteriormente poderlo comparar con definiciones de recursos similares.Posteriormente, se recomienda una lectura exhaustiva de los siguientes documentos de la especificación:
Conclusión.
Aunque aún está en camino de convertirse en una especificación normativa, FHIR® promete avivar la llama de los estándares de interoperabilidad HL7.
Al revisar la documentación, FHIR® parece ser una excelente alternativa para facilitar la adopción de estándares de interoperabilidad en salud, que cuenta con un enfoque orientado a la implementación rápida.
Para que la industria de desarrollo de software para el sector salud adopte FHIR®, será necesario que Health Level Seven Inc y sus afiliados internacionales, desarrollen una estrategia adecuada de promoción, localización y apoyo para su implementación.
En Latinoamérica, donde el uso de HL7 aún no es intensivo, FHIR® puede convertirse en una alternativa interesante para nuevos proyectos y especificaciones locales, aunque habrá que esperar que Health Level Seven Inc, libere la primera versión normativa en 2015.
Imagen 1: Ver fuente.
Imagen 2: Ver fuente.
Imagen 3: Ver fuente.
Imagen 4: Adaptada por el autor.
Imagen 5: Adaptada por el autor.
Imagen 6: Adaptada por el autor.
Imagen 7: Adaptada por el autor.
Imagen 8: Ver fuente.
Imagen 9: Ver fuente.
Imagen 2: Ver fuente.
Imagen 3: Ver fuente.
Imagen 4: Adaptada por el autor.
Imagen 5: Adaptada por el autor.
Imagen 6: Adaptada por el autor.
Imagen 7: Adaptada por el autor.
Imagen 8: Ver fuente.
Imagen 9: Ver fuente.
Buenas Tardes:
ResponderEliminarCon la conclusion final, quiere decir que aun el FHIR no esta lista para ser implementada??
Gracias
¿FHIR Funciona?: SI.
Eliminar¿Ha sido suficientemente probada por la comunidad HL7?: NO
Actualmente, FHIR alcanzó el estatus de estándar DSTU (Draft Standar for Trial Use), lo cual indica que puede ser implementado con fines de prueba y retroalimentación de su uso.
Desde el punto de vista técnico, FHIR funciona para realizar intercambio electrónico de datos, pero aún requiere la validación de los miembros de la comunidad HL7, lo cual se logra a través de procesos de pruebas de uso, retroalimentaciones y posibles ajustes, antes de ser considerado un estándar normativo.
Inclusive HL7 V3 tiene aún muchas de sus especificaciones en estatus DSTU y para el caso de HL7 V2.x periódicamente se publican nuevas versiones (actualmente 2.7.1), lo cual indica que se requieren ajustas para mantener su vigencia.
Esta pregunta puede ser un poco tonta, pero me declaro ignorante el por que.
ResponderEliminarPor que no crear un OS dedicado al uso medico? como las Distro de Linux, creada con una comunidad mundial donde grandes desarrollado se pueden encontrar con grandes pensadores del área medica? ... En ese Sentido creo que por lo menos OpenEHR puede llegar a crecer mucho mas.