Introducción al Estándar HL7 FHIR

En el módulo 2 hubo tres clases:

• “Introducción al estándar HL7 FHIR” por César Galindo,
• “HL7 FHIR Principios y Fundamentos” por Alejandro Medina.
• “Recursos” por José María Andrade.

Aquí dejo los apuntes que tomé de ambas clases.

Clase 1: Introducción al estándar HL7 FHIR

Hay mucho entusiasmo con respecto a HL7 lo que ha llevado a que sea muy utilizado en el último tiempo.

¿Qué es FHIR?

FHIR es un estándar para el intercambio de datos de salud. Fue creado por HL7, una organización sin fines de lucro que desarrolla estándares sintácticos desde 1987.

Aunque si le preguntas a uno de sus creadores, te responderá algo como “(FHIR) no es un estándar, es una comunidad que convive para facilitar el intercambio de datos en salud, usando tecnologías web”.

Esto de “comunidad” no se lo toman a la ligera. Hay muchos espacios digitales donde las personas pueden ser parte de FHIR, entre ellos: la documentación, chat, blogs y foro.

Ok, volviendo a las definiciones… FHIR es el acrónimo de Fast, Healthcare, Interoperability, Resources, lo que significa:

• Fast: implementación es más rápida. Poner en marcha un sistema interoperable con FHIR es más rápido comparado con otros estándares como HL7 v2.
• Healthcare: es un estándar hecho para salud. Puede ser usado para otras cosas pero no tiene mucho sentido hacerlo.
• Interoperability: creado para intercambiar información entre 2 o más sistemas.
• Resources: utiliza una arquitectura de alta conectividad de la WEB llamada “REST”, la cual se basa en “recursos”.

¿Por qué es importante FHIR?

FHIR es el “caballo de batalla” de HL7, lo que significa que hoy en día es el estándar por defecto a utilizar para proyectos de interoperabilidad en salud.

Hay algunas acciones de la organización HL7 que dan cuenta de esto:

• El objetivo de FHIR es que sea un estándar de uso global.
• Hay un “FHIR Accelerator” que te ayuda a implementar proyectos de interoperabilidad con FHIR asesorados por HL7 internacional.
• El logo de HL7 cambió a uno muy parecido a FHIR 😉.

La historia de FHIR

El mundo de la tecnología avanzó mucho durante la primera década del 2000. Para el año 2011, había una alta conectividad en el mundo de la tecnología, mucha información a procesar (big data), avances en genómica.

Esto hizo que los estándares de esos tiempos (como HL7 v2) fueran quedándose cortos, dejaron de ser coherentes con este nuevo mundo tecnológico.

Así que un grupo de personas expertas en disponibilidad web se juntaron y crearon el primer borrador (“first draft”) de lo que sería FHIR (esto en el año 2011). Fue bien aceptado por la comunidad.

Un timeline de lo que fue ocurriendo:

• 2011: primer borrador de FHIR
• 2014: DSTU
• 2015: DSTU2 (muy usado)
• 2017: STU3 (usado en USA)
• 2018: R4 primera normativa
• 2019: R4 segunda normativa
• 2022: R5

Algunas definiciones útiles para entender esto:

• DSTU: draft standards for trial use. Significa que la especificación no está considerada como completa o no está suficientemente revisada para que sea segura de implementar.
• STU: standard for trial use. Significa que ha sido revisado y es considerado seguro para usarlo. Ha sido sometido a votación y es considerado como estándar oficial. Sin embargo, aún no ha tenido un uso generalizado en producción en todo el espectro de entornos en los que está destinado.
• Normativa: quiere decir que en el tiempo una estructura de intercambio de datos definida va a cambiar muy poco, podemos usarla con confianza.

Nota: hay más información sobre el nivel de madurez aquí.

Hay que considerar que cuando hablamos de que FHIR es normativa, realmente nos referimos a que solo parte de FHIR es normativa: FHIR trabaja con recursos. Solo algunos recursos son normativos. Hay algunos que no lo son y están lejos de serlo.

¿Qué pasa si trabajo con recursos fuera de la normativa? Es arriesgado, ya que con el tiempo la estructura de intercambio de datos puede cambiar, lo que significa que la implementación construida sobre esto quedará obsoleta y tendrá que ser actualizado.

Así que la normativa es relativa dependiendo de los recursos que nos estemos refiriendo. En R4 los recursos normativos son los más básicos.

Describiendo FHIR

Para describir FHIR, es útil saber un poco de los estándares que lo preceden:

• HL7 versión 2: es muy usado, pero tiene 2 desventajas. La primera, es que es estructurado pero con mucho rango de libertad (fácil de romper). La segunda, que es poco amigable con la lógica semántica para casos de uso en salud.
• HL7 versión 3: la idea era mejorar la narrativa semántica para que fuera altamente computable. Es muy bueno para documentos clínicos, pero fue un fracaso porque era muy difícil de utilizar.
• CDA: nació con la versión 3, es bueno para contar historias de un evento particular de un paciente, lo cual lo hace ideal para documentos clínicos.
• CCOW: para documento clínicos de uso particular.

Luego FHIR viene a usar lo mejor de cada uno de estos estándares, para así ser EL estándar de intercambio de datos en salud en contextos diversos. Lo que se busca con FHIR es:

• Combinar lo mejor de los estándares en uso.
• Aplicar aprendizajes de mensajería V2, V3 y CDA.
• Aplicar tecnología web moderna.
• Busca mejorar la capacidad de implementación.

Fundamentos de FHIR

FHIR está diseñado específicamente para la WEB, basado en una arquitectura (conjunto de reglas) que reina sobre la web, la cual se llama “REST”.

REST, o REpresentational State Transfer, es un estilo arquitectónico para proporcionar estándares entre sistemas informáticos en la web, lo que facilita la comunicación entre los sistemas — Fuente

En REST, la unidad básica de información (mínima información que se puede intercambiar) se llama “recurso”. Estos recursos en FHIR están preconfigurados para salud. Es por eso que podrás ver un recurso para paciente, otro para profesional de la salud, etc.

Piensa en los recursos como “formularios” de papel que reflejan diferentes tipos de información clínica y administrativa que se pueden capturar y compartir. La especificación FHIR define una “plantilla de formulario” genérica para cada tipo de información clínica, es decir, una para alergias, una para recetas, una para referencias, etc. — (Fuente)

Una “API FHIR” es un servicio web que me ofrece información usando el estándar FHIR. Puedes usar esta “API” para crear aplicaciones sobre la misma (reutilización).

Por ejemplo, Google Maps ofrece una API que me permite crear distintos tipos de aplicaciones, tales como Uber, Rappi, entre otros.

Así que un servicio que ofrece una API FHIR me servirá para crear aplicaciones en el área de salud.

Un API es una interfaz que define cómo hacer la interacción entre distintos sistemas. Un API REST es una arquitectura particular que utiliza las reglas “REST”. La mayoría de los sistemas web utilizan esta arquitectura, lo cual facilita el trabajo para los implementadores que ya están acostumbrado a su utilización.

Para los estándares antiguos, existía un problema de contextualización de la información. Esto ya no ocurre en FHIR porque los recursos están vinculados: puedes crear documentos clínicos gracias a los vínculos.

FHIR te proveé una base que está diseñado para cubrir el 80% de los casos de uso. El 20% depende de cada caso (de las reglas de negocio particulares) y estas se pueden implementar gracias a “extensiones”. Es decir, podemos construir sobre FHIR en vez de hacer todo de 0.

¿Por qué FHIR?

• FHIR fue hecho para implementadores.
• Cuando haces desarrollos, la dificultad siempre existe. La pregunta es, ¿dónde movemos la dificultad? (teorema de Graham Grieve),
• Es fácil de implementar. En promedio, implementar con HL7v2 y CDA tomaba 1 año y medio, mientras que con FHIR son solo 6 meses.
• Tiene posibilidad de “mapeo” a otros formatos. Es decir, es fácil transformar de FHIR a V2 o CDA.
• Mejor capacidad de comunicar información.
• Costo de implementación bajos (500USD). Esto es considerando solo costo de diseño y costo del sistema base.

El mundo FHIR

• En la página web puedes encontrar todos los recursos.
• Cada día hay más herramientas. Ejemplo: SMART on FHIR
• Todo se publica. Hay guías de implementación ya publicadas para distintos casos de uso.
• Muchas librerías (gratuitas) que implementadores pueden utilizar.

Preguntas de la clase

• ¿Qué es una guía de implementación? (esta la hice en clases): “si quiere hacer esto, siga estas reglas”. Son guías que definen reglas basadas en ciertos casos de uso de la vida real. Una parte es “diseño” (cómo se van a comunicar) y otra es “desarrollo” (implementar apps que se van a conectar).
• ¿Quién crea las extensiones? Una extensión es para guardar información adicional importante para nuestro caso de uso que queda dentro del 20% que no cubre FHIR. Un ejemplo en Chile es guardar si un paciente es GES o no. No hay regulación sobre esto, pero está el capítulo de HL7, y además hay un listado de extensiones disponibles en el sitio de FHIR.

Una pregunta extra que me surgió mientras hacía estos apuntes:

• ¿Qué es SMART? Entiendo que es un estándar para hacer aplicaciones que se puedan conectar a distintas fuentes de información. Es decir, podría crear una APP de ficha electrónica para el Hospital Salvador y usar exactamente la misma APP (sin rescribir código) para que la clínica Alemana la utilice. Aquí hay más información.

Clase 2: HL7 FHIR — Principios y fundamentos

Esta clase es más teórica que la anterior, y dieron detalles específicos del estándar.

Alejandro nos enseñó a navegar por la página de FHIR, la cual es https://www.hl7.org/fhir/

La organización de la documentación está distribuida en 5 puntos:

• Nivel 1: Framework base.
• Nivel 2: Apoyo a la implementación.
• Nivel 3: relación de recursos FHIR y conceptos del ecosistema real.
• Nivel 4: registro e intercambio de datos de procesos clínicos.
• Nivel 5: generación de conocimientos con datos clínicos.

Nivel 1

Cada parte de la documentación tiene un “banner” como este:

Que indica quién trabaja, el estado y la seguridad. También indica si es normativo o no.

Por ejemplo, el de la imagen, dice que es información “Normativa”, lo que quiere decir que ha sido probado y que no presentará grandes cambios a futuro.

Cada recurso tiene un nivel de madurez. Los distintos niveles puedes verlos aquí (esto es un nivel de madurez a nivel de recurso solamente).

Tipos de datos: (documentación), hay unos tipos de datos “primitivos”, y hay datos de propósito general que son datos compuestos de elementos primitivos.

Elemento base: (documentación) de aquí se derivan todos los tipos de datos. Es decir, todos los tipos de datos tendrán un identificador (id) y se le podrán asignar extensiones (extension).

Recurso base: (documentación) todo recurso definido en FHIR se compone del recurso base. El recurso base tiene un identificador (id), metadata (meta), un conjunto de reglas (implicitRules) y un lenguaje (language).

Extensiones: (documentación) es un tipo de dato que nos permite implementar aquellas cosas que están dentro del 20% que no nos entrega FHIR. Recordar la regla 80/20 que dice que el 80% lo entrega FHIR, y el 20% depende de cada implementación.

Perfiles: (documentación) es el producto de la formalización de una implementación. Pasa que FHIR crea una plataforma común que permite diferentes implementaciones, en consecuencia, usualmente se requiere modificaciones para adaptar a distintos contextos de uso. Estas adaptaciones o modificaciones se especifican en un perfil. Son la base de las guías de implementación.

Formatos: (documentación) para transmitir la información (entre servidores) se utilizan los formatos JSON y XML (ambos normativos). Hay otros formatos pero que todavía no son normativos (como RDF y ND-JSON).

Nivel 2

Elementos que tienen que ver con el apoyo a la implementación.

Soporte: (documentación) descargas para herramientas, versiones, casos de uso (para orientar), librerías de desarrollo, servidores públicos, herramientas de testing.

Seguridad y privacidad: (documentación) recursos para dejar huellas, recursos de auditoría, se puede hacer trazabilidad.

Conformidad: (documentación) todo lo que puede hacer y las operaciones que soporta.

Terminología: (documentación) cómo implementar un servidor terminológico.

Mecanismo de intercambio: (documentación) API Rest, mensajes, documentos, SOA, base de datos.

Nivel 3

Elementos relacionados con conceptos reales (documentación)

Casos de uso: algunos ejemplos como registro de paciente y actividades clínicas.

Nivel 4

Tiene que ver con procesos (clínicos, diagnóstico, medicamentos, flujo de trabajo, financieros, etc).

Nivel 5

Tiene poca evidencia del uso que se está dando. Son recursos que cambian súper rápido (documentación).

Todos estos recursos tienen que ver con la generación de conocimiento. Compartir, evaluar, indicadores, etc.

Preguntas de la clase

• Especificación es distinto a implementación. Todo lo que vimos en la clase es sobre la especificación, es una guía y un conjunto de reglas. Si queremos tener nuestro servidor que cumpla con la especificación FHIR, hay que programarlo o utilizar algo ya existente. Hay código open source (libre y gratis) que podemos usar para crear nuestro servidor, no hay que reinventar la rueda. Un ejemplo es HAPI FHIR (Java).
• ¿Cómo asegurarnos que se utilicen bien los recursos? la documentación tiene un contexto de uso para cada recurso. Pero siempre va a depender de la interpretación y del caso de uso que estemos implementando.
• El perfil es un derivado de la especificación. Uno agrega cosas, no elimina.
• Es posible basarse en otras guías para implementar las nuestras. En https://simplifier.net/ hay muchas guías de implementación publicadas.

Clase 3: Recursos

¿Qué es un recurso?

Es una entidad para facilitar el intercambio de datos en salud, tanto en ámbito clínico como administrativo.

Características:

• Tienen URL definida.
• Tiene una versión.
• Derivan de DomainResource
• No es posible definir nuestros recursos. Si queremos hacer modificaciones, debemos perfilar.
• Podemos agrupar recursos con Bundle.
• En su estructura se define el tipo de Recurso.

Estructura de un recurso

• Tiene estructura de árbol.
• Los datos importantes se encuentran en la raíz.

• Cada dato tiene:

  • Cardinalidad: 1..1 (el campo siempre tiene que estar presente y debe ser solo 1), 0..1 (el campo puede estar ausente, y de existir, debe ser solo 1), 0..* (el campo puede estar ausente, y de existir, puede ser varios datos)
  • Tipo de campo
  • Descripción y restricciones
  • Banderas:
  • ?! no puede ser modificado
  • S debe ser soportado
  • Σ parte del resumen y operaciones especiales
  • I restricciones
  • NE sin restricciones
  • TU está en pruebas
  • N es normativo
  • D está en borrador (draft)

Representación de un recurso

Existen dos representaciones normativas: JSON y XML

• JSON application/json+fhir
• XML application/xml+fhir

Estos formatos son muy usados en plataformas web. Son de fácil lectura e interpretación tanto para humanos como para sistemas informáticos.

Puedes ver un ejemplo de un recurso de paciente en JSON aquí, y en XML aquí.

Los atributos importantes son:

• id, es el ID del recurso (generalmente es autogenerado por los sistemas informáticos).
• metadata, tiene información de la versión, actualización y un tag/perfil.
• narrative, es un HTML con el resumen del recurso. Es importante, ya que si por alguna razón un sistema que utiliza este recurso está limitado a las consultas que realiza, puede mostrar lo guardado en este dato para desplegar la información importante.

Organización de los recursos

Los recursos están organizados por categoría y módulo.

Cada recurso tiene una estructura parecida:

• Descripción
• Alcance y usos
• Límites y relaciones
• Cuerpo del recurso
• Enlaces terminológicos
• Restricciones
• Parámetros de búsqueda
• Operaciones
• Conversiones

Por ejemplo, revisa el recurso Paciente

¿Qué es un perfil?

Un perfil es cuando usamos un recurso en un contexto particular.

Por ejemplo, en Chile, el perfil Chileno de pacientes nos podría hacer agregar un campo (extensión) o un identificador de RUT.

Preguntas en clases

Nota: quizás no apunté todas las preguntas

¿Podemos hacer cambios en los recursos?

Podemos definir reglas nuevas. Para hacer estos cambios, haces un perfil (formalización de los cambios) y documentas su uso mediante una guía de implementación.

Se pueden hacer muchos cambios, hay que tener en cuenta los flags (banderas) cuando hacemos cambios, ya que si rompemos la regla, rompemos el estándar.

¿Con GET obtengo toda la data del paciente?

Obtienes la información definida en el recurso de Paciente. Las relaciones con otros recursos (por ejemplo, encuentros) no vienen aquí.