FHIR ES LA PRIMERA ESPECIFICACIÓN DE HL7 PENSADA PARA LA INTEROPERABILIDAD CLINICA.


“Cuando hace unos días compartí con mis contactos de Linkedin la alegría por haber finalizado el curso de HL7 FHIR me sorprendió gratamente la cantidad de felicitaciones que recibí por parte de mi entorno profesional. Sin embargo, aterrizado de mi nube, me quedé cavilando sobre si “esto de FHIR” sería realmente tan conocido como a priori podría parecer (al menos a mí) o si, por el contrario, para la mayor parte de profesionales del sector salud (más allá de los perfiles puramente técnicos, como los implantadores y los desarrolladores) no sería más que una más de esas on-trend siglas anglosajonas.

Así que, me decidí a escribir este post, en un tono didáctico y terrenal, para aquellos que tengáis curiosidad por ampliar vuestra información sobre lo que es FHIR, lo que significa en las vidas de los profesionales que nos dedicamos a las tecnologías de la información y las comunicaciones en el ámbito clínico y, sobre todo, las implicaciones que tiene en los nuevos entornos TI de las organizaciones de salud.


Precisamente por esas cualidades tecnológicas que arriba te contaba y, aunque los estándares HL7 v2, v3 y CDA todavía permanecerán con nosotros los próximos 5 a 10 años, es el nuevo estándar de HL7 el que llega para quedarse, de ahí la importancia de estar preparados para un futuro muy cercano.


FHIR está hoy en una etapa de activo desarrollo, pero se espera publicarlo como un HL7 Standard Release 4 antes de la finalización del 2018 como estándar Hl7/ANSI/ISO. Ante esto queda claro que, para los proveedores de TIC Salud, es clave y diferenciador participar desde ya de esta tecnología que, sin duda, marcará un antes y un después en la interoperabilidad clínica.»
 CDA quiere decir "Clinical Document Architecture" o en español "arquitectura de documento clínico" y forma parte de HL7 versión 3 (CDA®) es un estándar de marcado de documentos que especifica la estructura y la semántica de los "documentos clínicos" con el fin de intercambiar entre los proveedores de atención médica y los pacientes. Define un documento clínico que tiene las siguientes seis características: 
1) persistencia, 
2) administración, 
3) potencial de autenticación, 
4) contexto, 
5) integridad y 
6) legibilidad humana.

La Arquitectura de Documentos Clínicos (CDA) HL7 es un estándar de marcado XML que pretende especificar la codificación, estructura y semántica de documentos clínicos para intercambio entre sistemas informáticos. En noviembre 2000 HL7 publicó la versión 1.0. La versión 2.0 fue publicada en 2005

Un CDA puede contener cualquier tipo de contenido clínico; los documentos CDA típicos serían un Resumen de alta, un informe de imágenes, un informe de admisión y examen físico, de patología y más. El uso más popular es para el intercambio de información entre empresas, tal como está previsto para un Intercambio de información de salud "Health Information Exchange" (HIE).

FHIR son las siglas de Fast Healthcare Interoperability Resources (pronunciado como fire) y se trata del último estándar desarrollado y promovido por la organización internacional HL7 (Health Level Seven), responsable de algunos de los protocolos de comunicaciones más utilizados hoy en día en el ámbito sanitario.
La especificación misma está disponible en www.hl7.org/FHIR.
Contiene gran cantidad de hipervínculos y es fácil de seguir.
Es muy recomendable que tengan acceso a la especificación mientras leen este módulo, ya que hay muchas referencias a ella – particularmente para algunos
detalles de los aspectos más complejos de FHIR.

La especificación FHIR central de HL7 se basa en un conjunto de "recursos", que son los bloques de información atómicos en todo lo que dice cumplir con la especificación FHIR. Un ejemplo sería un "Paciente": este es un recurso con algunos atributos definidos internacionalmente como parte de la especificación FHIR HL7.

Un perfil es una forma de especializar un recurso FHIR para un caso de uso particular. Esta especialización puede tomar la forma de restringirla (por ejemplo, en nuestro perfil de "Paciente" no queremos ver una especie, ya que solo nos interesan los humanos), pero también puede incluir "extensiones" que agregan atributos adicionales. al paciente (por ejemplo, queremos agregar un nuevo campo para que la farmacia designada por el paciente respalde nuestra solución nacional de prescripción electrónica. Es importante tener en cuenta que un perfil es simplemente un conjunto de reglas, y el verdadero recurso "paciente" del FHIR enviar de un sistema a otro seguirá cumpliendo con la definición internacional HL7, pero también puede ajustarse a su perfil más específico.

Estamos trabajando con INTEROPen para acordar un conjunto de perfiles de "Care Connect" a nivel nacional de NHS para darnos un nivel de coherencia en la representación de estos recursos en las implementaciones de FHIR en Inglaterra.

Sin embargo, todos los perfiles definen la información que cada recurso puede contener, lo que nos lleva a la segunda parte de esta discusión: las API de FHIR.

Además de definir un conjunto de recursos y un mecanismo para crear perfiles, la especificación HL7 FHIR también proporciona un conjunto de reglas sobre cómo esos recursos se pueden usar en ambos mensajes tradicionales (por ejemplo, agrupando un grupo de perfiles en un mensaje o FHIR documento para enviar a otro sistema), y también en las API ReST. La última parte, las API ReST, es donde se concentra gran parte de la comunidad FHIR.

Referencias

Comentarios

Entradas más populares de este blog

ESCANEO DEL CODIGO PDF417 DEL DNI (Documento Nacional de Identidad digital)

¿Que tipos de Mensajes de HL7 hay?

Apex SQL una herramienta free útil para interpretar mejor el código SQL