HL7 un estándar de interoperabilidad en Salud

¿Qué es HL7® ?

La mayoría de los profesionales de sistemas de información en el ámbito de la sanidad reconocen HL7 como un estándar de interoperabilidad. Sin embargo, hay más detrás de HL7. Realmente es un conjunto de estándares que toma el nombre de la organización que los define.

HL7 es el acrónimo de Health Level Seven Internacional. Una organización sin ánimo de lucro dedicada a proporcionar estándares para la interoperabilidad en el ámbito de salud.

HL7 Internacional fue fundada en 1987, y desde 1994 está acreditada por ISO (International Organization for Standarization) y por ANSI (American National Standards Institute).

La organización cuenta con el apoyo de más de 1.600 miembros de más de 50 países, incluyendo 500 miembros corporativos que representan a proveedores de atención médica, actores gubernamentales, pagadores, compañías farmacéuticas, vendedores / proveedores y empresas de consultoría.

¿Qué significa HL7®?

Aunque pueda parecer que estamos hablando de la séptima versión de un protocolo que se llama HL, no es así. No hay un HL5 ni un HL6. El nombre HL7 tiene origen, por un lado, del dominio de Salud (en inglés Health), y por otro, el nivel siete (en inglés Level Seven).

¿Por qué nivel siete?

El modelo de referencia OSI (ISO/IEC 7498-1) define siete niveles para protocolos de red. Cada uno de ellos especifica los protocolos que deben utilizarse en dicha capa.

HL7 es un conjunto de estándares para el nivel de aplicación. Es decir, se define sobre el nivel 7 de OSI por tratarse específicamente de un protocolo de intercambio de datos en dicho nivel.

El nivel 7 ofrece a las aplicaciones la posibilidad de acceder a los protocolos de las capas inferiores, y define los protocolos que utilizan las aplicaciones para intercambiar datos.

Esto quiere decir que se podría intercambiar mensajes HL7 a través de TCP, o FTP, o HTTP, o prácticamente en cualquiera de los protocolos de niveles inferiores.

Estrategias de HL7 para la interoperabilidad en el ámbito de la sanidad

La organización Health Level Seven International agrupa sus estándares en siete grandes categorías de referencia. En la primera de ellas, Estándares Primarios, se incluyen los más populares para integraciones de sistemas e interoperabilidad, los más utilizados y demandados en el ámbito de la sanidad.

Desde su fundación, la organización HL7 ha seguido tres estrategias principales de estandarización para el intercambio de información en sanidad. Por orden cronológico esta tres estrategias se materializan en los tres estándares mas importantes de la organización: HL7 v.2, HL7 v.3 y FHIR.

HL7 v.2x

Se conoce comúnmente como «mensajería HL7» por estar basada en el intercambio de «mensajes» de estructura definida. Este estándar ha ido evolucionando desde su aparición en 1986 hasta la versión mas actual, HL7 v.2.8. Aún en la actualidad sigue siendo el más utilizado en el mundo de las TIC en sanidad.

Se trata de un conjunto de estándares ad hoc para cada necesidad y cada localización. Dispone de cierta flexibilidad para pactar entre partes implicadas, esta es su gran ventaja en cuanto a facilidad de implementación. Esta flexibilidad también supone un inconveniente si lo vamos a considerar como estándar, ya que deja muchos aspectos a la negociación entre ambas partes. Por otro lado, y a la vez, también tiene cierta rigidez en cuanto a la estructura de los mensajes, que a veces dificulta el pacto entre partes, que deben incluir información no relevante para sus propósitos.

Se podría decir que HL7 v2 supuso una disrupción tecnológica en el ámbito de las TIC en sanidad, convirtiéndose en un estándar real. Se puede decir que todo proveedor de TIC para salud fue adaptando sus sistemas antiguos a este estándar.

Uno de los motivos que le ha hecho fuerte como estándar para interoperabilidad en sanidad ha sido permitir conectar varios sistemas y dispositivos a partir de los eventos que van sucediendo. De hecho, su origen está en ASTM, un protocolo para el intercambio de información entre dispositivos clínicos.

¿Cómo son los mensajes HL7 v2?

Un mensaje HL7 es una estructura jerárquica de segmentos y campos, asociada a un evento disparador que lo desencadena.

Lo que estandariza HL7 v2 es:

• La estructura de los mensajes.
• La codificación de los mensajes.
• Los eventos que generan la información y son disparadores de estos mensajes.

Respecto a la codificación, a lo largo del tiempo han habido dos sistemas para la codificación de mensajería: ER7 y XML.

Formato ER7

Es muy característico, y consiste en una estructura de líneas de texto con pipes y gorritos separando los campos de información.

Un ejemplo tendría este aspecto:

MSH|^~\&|HIS|HOSPITAL|BBANK|EXTERNO|20190429090131||ACK^^ACK|12345679|P|2.5
MSA|AR|123456
ERR|PID^1^16^103&Table value not found&HL70357

Formato XML

Fue una evolución posterior para eliminar algunas limitaciones del formato ER7, con unas reglas de codificación de documento XML. El mismo mensaje, con la misma información que el ejemplo anterior en ER7, pero en este caso, en XML, tendría este aspecto:

<ACK
    xmlns="urn:hl7-org:v2xml"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:hl7-org:v2xml ACK.xsd">
    <MSH>
        <MSH.1>|</MSH.1>
        <MSH.2>^~\&amp;</MSH.2>
        <MSH.3>
            <HD.1>HIS</HD.1>
        </MSH.3>
        <MSH.4>
            <HD.1>HOSPITAL</HD.1>
        </MSH.4>
        <MSH.5>
            <HD.1>BBANK</HD.1>
        </MSH.5>
        <MSH.6>
            <HD.1>EXTERNO</HD.1>
        </MSH.6>
        <MSH.7>
            <TS.1>20190429090131</TS.1>
        </MSH.7>
        <MSH.9>
            <MSG.1>ACK</MSG.1>
            <MSG.3>ACK</MSG.3>
        </MSH.9>
            <MSH.10>12345679</MSH.10>
        <MSH.11>
            <PT.1>P</PT.1>
        </MSH.11>
        <MSH.12>
            <VID.1>2.5</VID.1>
        </MSH.12>
    </MSH>
    <MSA>
        <MSA.1>AR</MSA.1>
        <MSA.2>123456</MSA.2>
    </MSA>
    <ERR>
        <ERR.1>
        <ELD.1>PID</ELD.1>
        <ELD.2>1</ELD.2>
        <ELD.3>16</ELD.3>
        <ELD.4>
            <CE.1>103</CE.1>
            <CE.2>Table value not found</CE.2>
            <CE.3>HL70357</CE.3>
        </ELD.4>
        </ERR.1>
    </ERR>
</ACK>

Ventajas e inconvenientes de HL7 v2

Este estándar permitió conectar sistemas informáticos con dispositivos dentro del mismo hospital, o sistemas de distintos hospitales, e incluso entre organizaciones.

El objetivo de elaborar un estándar era precisamente eliminar todas esas conexiones ad hoc entre los sistemas que conviven en el ecosistema TIC de la sanidad. En lugar de elaborar conexiones a medida entre los sistemas, elaborar un estándar al que todos se adapten, permitiendo reutilización del desarrollo interoperable.

Su mayor fortaleza a día de hoy es que sigue siendo el estándar mas utilizado en sanidad.

Entre los problemas que tiene este estándar, y que han dado lugar a la creación de otros, como HL7 v3 y HL7 FHIR, es que es bastante estricto en cuanto a la estructura. Los mensajes tienen definida una estructura por estandar, y en ocasiones dentro de esa estructura puede haber carencias de información para los propósitos de una integración, o exceso.

En el caso del exceso de información, cuando son campos obligatorios, es necesario, para cumplir el estándar, rellenarlos con información no útil. Cuando tenemos defecto de información, HL7 con el tiempo proporcionó unos segmentos personalizados, denominados segmentos Z. En estos segmentos se personaliza la información necesaria para la integración, y que no se incluye en el estándar.

HL7 v.3

Aunque el nombre es similar, y parece que sea una versión posterior de la anterior estrategia, no es así. No es una evolución de los mensajes de HL7 v2, sino que es completamente distinto. Es una nueva familia de estándares que incluye un modelo de referencia común como base, a nivel de mensaje y de ámbito.

Intenta solventar los problemas de la mensajería versión 2, respecto a lo poco flexible, que terminaba provocando que una integración necesitara de segmentos Z, personalizados. Esto hacía a HL7 v2 pobre como estándar. No podía reflejar cualquier escenario de interoperabilidad, y esto es lo que se intenta resolver en v3. Además incorpora evoluciones tecnológicas como estar basado en la programación orientada a objetos, y especificado en UML.

Se basa en XML como formato canónico, aquí ER7 desaparece, e incorpora terminologías internacionales.

Este enfoque parte de un modelo genérico, básico y común de referencia, conocido como Modelo de Información de Referencia (RIM). Este modelo será común para todos sus estandares, y define unas clases básicas y genéricas, que deberían valer para cualquier escenario de interoperabilidad. A partir de esas clases se podrán construir mensajes o documentos concretos.

Dentro de este grupo de estándares v3 también se considera el estándar para el intercambio de documentos de información clínica HL7 CDA.

HL7 v3 RIM: Reference Information Model

El modelo de información de referencia (RIM) en HL7 v3 está construido sobre 6 clases fundamentales, 4 de ellas son la base:

• Act: Un acto, según el estándar, es el registro de algo que está sucediendo, ha sucedido, o puede suceder en el futuro.
• Rol: Responsabilidad o papel que puede jugar una entidad.
• Entity: Un ente o entidad, documento, objeto de negocio o cosa física que puede participar en un acto jugando un rol.
• Participation: La involucración de un rol en un acto.

Además de estas tenemos también:

• Rol relacionado: Con la asociación entre dos roles.
• Acto relacionado: Con la asociación entre dos actos.

La relación entre estas clases se podría resumir en que, en todo acto, hay entidades que participan jugando algún rol.

Datatypes

El HL7 RIM tiene un segundo nivel de información básica, donde se definen los tipos de datos (datatypes). El modelo de datatypes está definido de forma independiente al HL7 RIM, aunque realmente existen referencias del modelo datatypes al modelo RIM, luego hay cierto acoplamiento.

El modelo datatypes contiene los siguientes:

• Estructuras básicas: List, Set, Interval, Bag.
• Tipos de códigos: Concept Descriptor, Concept Role, Coded Simple Value, Coded Value, Coded Ordinal, etc.
• Estructuras para la representación de nombres: Entity Name, Entity Name Part, Trivial Name, Organization Name, Person Name, etc.
• Tipos de magnitudes y magnitudes físicas: Real Number, Ratio, Physical Quantity, Integer Number, Monetary Amount, etc.
• Tipos para timming y fechas: Point in Time, Interval of Point in Time, General Timing Specification, etc.
• Otros tipos básicos: History, Telecommunication Address, Universal Resource Locator, etc.

A partir de esto, se construye todo el modelo de información del estándar:

A partir de estas clases y tipos de datos del modelo de referencia RIM se derivan los componentes del resto de estándares V3.

Para mas información en la web del estándar HL7 v3 RIM.

HL7 FHIR

El mas novedoso y actualmente mas promocionado por la organización HL7 es FHIR (Fast Healthcare Interoperability Resources). Se empezó a trabajar en este estándar en el año 2011, con la intención de resolver los problemas que se encontraron en V2 y V3. Sin embargo hasta diciembre de 2018 no se ha publicado la primera versión normativa de FHIR, y ha sido en su Release 4.

Si bien V2 fue un éxito, tecnológicamente estaba anticuado, y era necesario una renovación para incorporar las nuevas tendencias.

Por otro lado, V3, como hemos visto, era mas avanzado, pero demasiado complejo, y no tuvo éxito.

El objetivo principal de FHIR es facilitar el intercambio de información clínica, e intenta combinar lo mejor de sus dos predecesores. Para ello busca facilitar la implementación y actualizar tecnológicamente la obsolescencia de la versión v2.

Para conseguir estos objetivos, HL7 pone las especificaciones de HL7 FHIR a dominio público, gratuitas y sin restricciones. Se pueden encontrar en la página del estándar FHIR.

Recursos FHIR

FHIR se basa en el concepto de Recursos (Resources), y se desarrolla sobre arquitectura REST, en HTTP, con una filosofía cliente-servidor.

El servidor ofrece acceso a los recursos a un cliente REST, permitiendo consultar o modificar dichos recursos a través de peticiones HTTP.

Estas peticiones HTTP a través del verbo, al estilo de REST, indicará el tipo de operación que se pretende hacer sobre el recurso concreto:

• Get: Para obtener un recurso, normalmente a través de un identificador. Por ejemplo, para solicitar información de un paciente con identificador 4721 podría realizarse esta llamada: GET http://hapi.fhir.org/baseR4/Patient/4721
• Post: Para crear un recurso nuevo en el servidor.
• Put: Para actualizar el estado de un recurso ya existente.
• Delete: Para eliminar el recurso.

Los datos se intercambian tanto en formato JSON como en XML.

En resumen, los recursos representan conceptos de la realidad clínica, como pacientes, pruebas, citas, etc. Y como la arquitectura tecnológica de FHIR no es mas que REST, la curva de aprendizaje del estándar se reduce a los conceptos de recursos.

El listado completo de recursos FHIR puede consultar en la web del estándar, que en la Release 4 son 143 recursos, de los cuales, solo 11 son normativos (estables). Pueden parecer muchos, pero hay que decir que uno de los principios de FHIR ha sido seguir el principio de diseño 80/20. Esto es, no incluir todos los recursos, no contemplar todo, sino solo lo intercambiable, porque es un estándar de interoperabilidad:

Enfocarse en cubrir el 20% de los requisitos que satisfagan el 80% de las necesidades de interoperabilidad.

De cualquier forma, esto es lo definido nativamente, cada usuario podrá crear adaptaciones.

Un recurso FHIR consta de cuatro partes:

1. Un apartado de Metadatos, que incluirá la identificación del recurso.
2. Una parte narrativa, legible por humanos.
3. Una parte para añadir extensiones, con URL a su definición.
4. Datos estructurados, con el contenido estandar del recurso.

Tipos de datos

En FHIR tenemos dos tipos de datos: Primitivos y Complejos.

Los tipos de datos primitivos son aquellos directamente representables en XML o JSON, como cadenas de texto, números, fechas, etc. Mientras que los tipos de datos complejos son estructuras de mayor complejidad, y están definidos como recursos FHIR.

Los tipos de datos están definidos en la página de tipos de datos del estándar, así como la correspondencia entre estos tipos de datos FHIR con los de otros estándares como HL7 v2 o RIM.

Éxito y fracaso

Se puede decir claramente que, como estándar de mensajería HL7 v3 no tuvo éxito en comparación con la versión HL7 v2. Como documento clínico, y sobre todo gracias a HL7 CDA, sí ha tenido una gran implantación.

A pesar de que la opinión de muchos expertos sobre ambos estándares es que HL7 v3 es una evolución hacia un estándar mejor definido y elaborado, después de años de perfeccionamiento y esfuerzo por conseguir un consenso en el sector, la versión HL7 v2 ha seguido desarrollándose y evolucionando después de la versión v3, e implantándose como el estándar más utilizado en el ámbito de la salud.

Algunos expertos han publicado artículos sobre la decadencia de la versión 3, y el porqué de este hecho no está claro. Mi opinión es que la complejidad de su implementación y la universalización de la versión 2, ha influido bastante que su falta de aceptación.

Entre los motivos que algunos expertos exponen para entender que HL7 v3 está obsoleto como mensajería:

• El proceso de diseño de V3 impone consistencia en nuestros estándares (es uno de los objetivos deseados) aunque la inconsistencia no se debía a HL7, sino a la inconsistencia de los procesos de negocio clínicos.
• HL7 V3 es independiente de tecnología y plataforma, es un pro que se vuelve en contra cuando hace que la implementación sea más costosa.
• Con HL7 v3 se pretende anticipar todos los modelos posibles, y esto se traduce en que el coste del cambio es aterrador. Terminó produciendo modelos que no eran implementables, demasiado grande.

La materialización de esta idea llega cuando en 2009 Gartner Group, en su informe 2009 The Hype Cycle for Healthcare Provider Technologies and Standards declara a HL7 v3 obsoleta antes de la meseta. Es decir, obsoleta antes de ser mainstream, decepcionante para el mercado.

Clave del éxito de v2

En mi opinión, el éxito de v2 ha venido de ser más un marco de trabajo para negociar una integración entre sistemas heterogéneos, que un estándar proscriptivo.

La diversidad del ecosistema TIC en salud hace difícil establecer unas vías universales impositivas, ya que no se trabaja igual en todas partes.

Si consideramos la multitud de implementadores y sistemas de información en sanidad, no solo proveedores distintos sino ámbitos distintos, y multiplicamos por la localidad de los procesos de negocio en salud, cada región, cada centro, trabaja de una forma distinta, tenemos un popurrí difícil de normalizar. Al final un sistema de información se adapta a las reglas de negocio, no impone las reglas de negocio. Si son diferentes en cada centro, en cada región, establecer un estándar proscriptivo que sea inflexible es la condena al fracaso.

Creo que esto es lo que resume el éxito de v2 y el fracaso de v3 como mensajería.

¿Es FHIR una disrupción tecnológica?

Con estos precedentes, surge FHIR como un intento de resolver la obsolescencia tecnológica de HL7 v2, y la complejidad y formalidad de HL7 v3. Intenta basarse en la experiencia previa para poner el foco en cuatro puntos:

1. Facilitar la implementación, y superar así el problema de HL7 v3.
2. Flexibilidad y adaptabilidad, y superar así lo inflexible de HL7 v2.
3. Enfocarse en la comunicación de información clínica entre sistemas, que es la materialización real de la necesidad clínica.
4. Actualización tecnológica de la que carecía HL7 v2: Basarse en los estándares web: XML, JSON, Oauth y REST.

El hecho de que en FHIR se utilicen tecnologías existentes, principalmente REST y JSON, o XML, y que sea de dominio público, ha despertado gran interés en el ámbito de la salud. A pesar de ser nuevo, recordemos que la primera versión normativa FHIR Release 4 ha sido publicada en Diciembre de 2018, ya hay un grueso de desarrollo en esta especificación, y una gran inversión por los proveedores de TIC en Salud en la utilización. Se espera que en la curva de popularidad de Gartner, el Hype Cycle, lo veamos superando las expectativas con éxito. Aún es pronto para afirmar que sea una disrupción tecnológica, pero lo que sí se puede apreciar es que hay un alto grado de expectativa. Cualquier nuevo proyecto de software para sanidad debe llevar algo de FHIR.

Ya cuenta con el soporte de grandes proyectos y empresas, como por ejemplo el Proyecto Argonaut: Accenture, Apple, Cerner, Mayo Clinic, Epic, etc..

FHIR vs (v2 y v3)

En comparación con los estándares anteriores, en FHIR se enfoca al recurso, en lugar de enfocarse al documento como en v3, y en la información que se necesite, y no en toda la estructura, como v2.

Un problema que ya trae FHIR es que, con la primera versión normativa, la Release 4, ya están coexistiendo varias versiones de FHIR (las anteriores). Esto ya pasaba con HL7 v2.

Por otro lado, sigue adoptando un problema que ya estaba también en v2, al poderse adaptar recurso de manera libre, las implementaciones pueden ser ad hoc, y por tanto no ser reutilizables. Tal como decíamos de HL7 v2.

Otro punto a tener en cuenta, la existencia de extensiones recuerda a los segmentos Z de la versión v2, por lo que también queda en duda la reutilización de implementaciones.

Dicho esto, entre las ventajas que ya hemos comentado podemos resumir:

• Sencillo de entender conceptualmente.
• Basado en arquitectura tecnológica ya conocida, lo que sumado a la anterior hace que tenga una curva de aprendizaje muy atractiva.
• Especificaciones de dominio público, libres y gratuitas.
• Hay multitud de recursos disponibles para implementadores.

Todo apunta a que FHIR es el futuro, y HL7 v2 y v3 ya empiezan a ser el pasado.