Connecting eHealth blog

Los 5 estándares HL7 fundamentales

Los estándares HL7 se utilizan en todo el mundo para la integración de sistemas de salud. Existen 5 estándares fundamentales: HL7 V2, HL7 V3, FHIR, CDA y CCOW. Sigue leyendo para conocerlos, descubrir sus principales características y acceder a los recursos clave para dominarlos.

Contenido

Volver arriba

¿Qué es HL7®?

Logotipo de Health Level Seven International
Logotipo de Health Level Seven International

HL7 son las siglas de Health Level Seven International, una organización sin ánimo de lucro que se dedica a la creación de estándares de informática de la salud. Fue fundada en 1987 y en ella participan más de 1.600 miembros de 50 países. Entre los miembros hay más de 500 organizaciones de todos los ámbitos de la salud. Existen diferentes ramas nacionales de HL7, por ejemplo, HL7 Spain es la rama española de Health Level Seven International.

HL7 se dedica a proveer un marco de trabajo y estándares para el intercambio, integración y acceso a la información electrónica de salud. La información de salud no solo se refiere a la práctica clínica, sino también a todos los conceptos de la atención sanitaria como la administración y la gestión.

Puede que te preguntes. ¿existieron HL6 o HL5?. La respuesta es “no”. Health Level Seven hace referencia al nivel 7 del modelo OSI, el nivel de aplicación, para el sector salud. Según Wikipedia, el nivel de aplicación “ofrece a las aplicaciones la posibilidad de acceder a los servicios de las demás capas y define los protocolos que utilizan las aplicaciones para intercambiar datos“. Por tanto, la organización Health Level Seven se puede entender como “Nivel de Aplicación en Salud” y se dedica a definir los protocolos y estándares para el intercambio de información entre aplicaciones de salud.

Volver arriba

¿Qué son los estándares HL7?

Los estándares HL7 (también llamados protocolos HL7) definen cómo se empaqueta y comunica la información entre dos partes. Estos estándares definen el idioma, la estructura y los tipos de datos requeridos para una integración de sistemas de salud fluida.

Miles de hospitales en todo el mundo utilizan a diario estos estándares para intercambiar información entre sus sistemas. Si hablamos de estándares HL7, hablamos de interoperabilidad en salud.

Volver arriba

¿Cuáles son los estándares HL7 más importantes?

Los estándares HL7 más importantes son los que se conocen como estándares primarios (HL7 primary standards). Dichos estándares son los más utilizados para la integración de sistemas e interoperabilidad..

Hay cinco estándares HL7 primarios: HL7 V2, HL7 V3, CDA, HL7 FHIR y CCOW.

Estándares HL7 primarios: HL7 V2, HL7 V3, CDA, FHIR, CCOW
Estándares HL7 primarios: HL7 V2, HL7 V3, CDA, FHIR, CCOW

Hay una gran cantidad de información sobre estos estándares primarios en  Health Level Seven International.

Además, existen otros que se usan junto a los estándares HL7. Para aprender más sobre ellos, puedes consultar nuestra guía de estándares de interoperabilidad en salud .

Volver arriba

El estándar HL7 V2

El estándar HL7 V2 (o protocolo HL7 V2) es un estándar de mensajería que permite el intercambio de información entre distintos sistemas. Es, sin duda, el más extendido y usado de los estándares de interoperabilidad.

Su primera versión se publicó en octubre de 1987, desde entonces se han publicado múltiples actualizaciones. Las versiones se nombran habitualmente de la forma V2.X. En 2014 se publicó la versión HL7 V2.8 que es la más reciente a la fecha de este artículo.

Las versión más utilizada de HL7 versión 2 es la V2.5, aunque es muy frecuente encontrar también las versiones V2.3, V2.6 y V2.7.

Volver arriba

La mensajería HL7 V2

Existen muchos tipos de mensajes HL7 V2, pero los más usados son los de gestión de paciente (ADT), órdenes (ORM) y resultados (ORU). Los mensajes son cadenas de texto divididas en segmentos. El segmento más importante es la cabecera o segmento MSH, que aparece en primer lugar y contiene, entre otros datos, el tipo de mensaje que es.

Los mensajes de HL7 V2 tienen un aspecto muy característico, son varias líneas de texto largas similares a las siguientes:

MSH|^~\&|HOSPITAL|CMQUI|EXTSYS|CMQUI|20180906175029||ADT^A31^ADT_A05|79854440|P|2.5|||AL|NE||8859/1
EVN|A31|20180906162458|||HL7_cib^^^^^^^^^^^^^^^
PID|1|127912359^^^CAMD^JHN^^^^MD&&ISO3166-2|1235340^^^^PI^|NCHR123^^^MS^HC^^^^ESP&&ISO3166|ANCA^FRANCISCO JUAN^PEREZ|GARCIA|19930803000000|M|||CALLE&PRINCIPAL&1^2 D 2ºD^79^28^28018^724^^16||912233595^PRN^PH^^^^^^^^^12333595~12328569^ORN^PH^^^^^^^^^634728569~^PRN^Internet^|123728569^PRS^CP|||||28/13668662-41|12399976Y|||DESCONOCIDA|||ESP^ESPAÑA||||N
PD1|||^^^^^^FI^^^16012810~HOSPITAL CENTRAL^^^^^^XX^^^281270|^^^^^^^^^^^^^^^1231280107M
PV1|1|N

En estos mensajes, cada línea corresponde a un segmento que se identifica por sus tres primeras letras. A continuación de la identificación del segmento, vienen los campos de ese segmento. Estos campos, a su vez, están formados por componentes y subcomponentes.

Los campos, componentes y subcomponenetes se separan mediante caracteres separadores especiales. Los caracteres recomendados son:

  • |“: separador de campos (barra o pipe).
  • ^“: separador de componentes (gorro o hat).
  • &“: separador de subcomponentes.
  • ~“: separador en iteraciones de campos.
  • \“: carácter de escape.

Desde la versión 2.3 del estándar HL7 se pueden codificar los mensajes también en formato XML. Esta codificación se denomina v2.xml.

Recursos sobre HL7 V2 en Health Level Seven International (en inglés):

Volver arriba

HL7 V2 vs HL7 V3

El estándar HL7 V2 es el más usado pero tiene algunos inconvenientes.  HL7 V2 tienen una gran flexibilidad y es adaptable a casi todos los casos, pero esta flexibilidad tiene un coste. Este coste es que las diferencias entre distintas implementaciones requieren profundos análisis y mucha negociación para conseguir la integración. Por otro lado, esta flexibilidad y diferencias también hacen que sea complicado testear y llevar a cabo pruebas de conformidad.

Esta situación impulsó el desarrollo del estándar HL7 V3. Este estándar es mucho más ambicioso y amplio que la versión anterior. El enfoque de este nuevo estándar es mucho más formal y pretende solucionar algunos de los inconvenientes de su versión anterior.

Volver arriba

El estándar HL7 V3

El estándar HL7 V3 pretende cubrir todos los aspectos de la implementación: mensajería, tipos de datos y terminologías. Estas características lo convierten en una iniciativa muy ambiciosa dentro de los estándares de interoperabilidad. Esta versión del estándar tiene una aproximación semántica, basada en modelos, que es mucho más estricta y normativa que en la versión 2. La primera versión de HL7 versión 3 fue lanzada en 2003 y ha seguido actualizándose desde entonces.

La mensajería y documentos de la versión 3 se definen en sintaxis XML, a diferencia del formato de pipes usado en HL7 V2. Asimismo, insiste mucho en el uso de vocabularios controlados (como CIE-10LOINC y SNOMED CT), además de codificaciones propias.

La complejidad y extensión de HL7 versión 3 hacen que no sea fácil de implantar ni de migrar desde la versión 2. Además, tiene que competir con la misma versión 2, que se encuentra en producción de forma satisfactoria en casi todas partes. Quizá por estos motivos, la versión 3 del estándar no está tan extendida como la versión anterior, no obstante es usada en varios servicios públicos de salud como Reino Unido, Países Bajos y Canadá.

Recursos sobre HL7 V3 en la web de Health Level Seven International (en inglés):

Volver arriba

HL7 V3 RIM: Reference Information Model

Una de las principales características del estándar HL7 V3 es que está basado en el RIM (Reference Information Model)un amplio modelo de objetos de referencia de los datos clínicos.

El RIM es un modelo de toda la información de los servicios sanitarios, que identifica el ciclo de vida de la mensajería dentro de la actividad clínica.  Este modelo es la referencia que se usa para el desarrollo de todo el estándar.

Estándar HL7 V3 RIM
Diagrama UML de HL7 RIM

Información sobre RIM en Health Level Seven International (en inglés):

Volver arriba

El estándar HL7 CDA®

El estándar HL7 CDA® es un estándar de documento clínico. Esta especificación tiene el objetivo de facilitar el intercambio de información en forma de documentos entre proveedores de salud y pacientes. CDA puede contener cualquier tipo de información clínica, por ejemplo: informes de alta, informes de radiología, informes de patología o la exploración y anamnesis del paciente.

CDA es la abreviatura de Clinical Document Architecture (Arquitectura de Documento Clínico). La primera versión (CDA Release 1) fue lanzada en el año 2000, la segunda versión (CDA Release 2 o CDAR2) fue lanzada en 2005 y adoptada como estándar ISO/HL7 27932:2009.

CDA está basado en el modelo de datos RIM y en la metodología de trabajo de HL7 V3.

Volver arriba

Características de un documento CDA

Según el estándar CDA, las seis características que debe tener un documento clínico son:

  • Persistencia: el documento permanece inalterado en el tiempo, independientemente de cambios externos.
  • Custodia: el documento debe ser administrado por una organización o entidad.
  • Potencial para la autenticación: el documento ha de tener validez legal.
  • Contexto: el documento define un contexto de participantes (como el paciente o el médico), acto, prestador de servicios sanitarios, etc. 
  • Completitud: el documento se debe entender como una unidad de contenido.
  • Legibilidad humana: aunque puede ser procesado por sistemas informáticos, el documento debe conservar la capacidad de ser leído por personas.

Volver arriba

Estructura de un documento CDA

El objetivo del estándar HL7 CDA es definir la parte estructural y semántica del documento, pero no se ocupa del contenido de los documentos. Cómo se crean, almacenan e intercambian los documentos queda fuera del alcance del estándar.

Un documento CDA se especifica en formato XML y se compone de dos partes: la cabecera (header) y el cuerpo (body).

La cabecera o header contiene metainformación sobre el documento:

  • Atributos del encabezado: identificación, fecha, título, idioma, etc.
  • Participantes: el autor, el paciente, el proveedor, etc.
  • Actos relacionados: otros documentos, autorizaciones, etc.

El cuerpo o body contiene la información del documento. Dicha información siempre debe contener una parte textual que asegure la legibilidad humana. El estándar define tres niveles de estructura para el cuerpo:

  • Nivel 1: contenido no estructurado.  Por ejemplo, el contenido puede ser un documento PDF incrustado.
  • Nivel 2: contenido estructurado y codificado en secciones.
  • Nivel 3: contenido completamente estructurado y codificado.

La codificación del contenido de los documentos se realiza mediante estándares de codificación, como SNOMED-CTCIE-10 (ICE-10) y LOINC. Cuanto mayor sea el nivel de codificación del contenido del documento, mayor será su grado de interoperabilidad con otros sistemas.

Recursos sobre CDA Release 2 en la web Health Level Seven International:

Volver arriba

Estándar HL7 FHIR es un nuevo estándar de interoperabilidad
Logotipo del estándar HL7 FHIR

El estándar HL7 FHIR®

HL7 FHIR® es un estándar de interoperabilidad que combina lo mejor de HL7 V2, HL7 V3 y CDA y se enfoca en facilitar su implementación. Además, usa los estándares web más frecuentes, como XML, JSON y HTTP.

FHIR® es la abreviatura de Fast Healthcare Interoperability Resources (Recursos de Interoperabilidad Sanitaria Rápida). Los resources o recursos son las piezas clave de FHIR.

Volver arriba

¿Qué son los resources FHIR?

Los “Resources” son los bloques de construcción de todos los intercambios de información en FHIR. Cada resource o recurso representa un concepto de la realidad de la atención sanitaria, como pacientes, citas, organizaciones o resultados de pruebas.

Los recursos pueden representarse tanto en XML como en JSON y todos tienen ciertas características en común:

  • Una URL que identifica al resource.
  • Unos metadatos comunes.
  • Un resumen legible para humanos.
  • Un marco de extensibilidad (extensibility framework) que permite asumir las diferencias en la atención sanitaria.

Vemos una representación de un resource de paciente donde se han resaltado las partes características:

Ejemplo de resource de paciente del estándar HL7 FHIR
Ejemplo de resource de paciente. Fuente: https://www.hl7.org/fhir/summary.html

Usando estos recursos o resources se pueden modelar los procedimientos clínicos y administrativos de forma rápida y con menos complejidad que con otras alternativas.

Es posible consultar la lista completa de Resources de FHIR, donde hay más de 115 recursos definidos. Además, en cada recurso se incluye documentación y ejemplos.

Volver arriba

¿Cómo se manejan e intercambian los resources en FHIR?

Desde su concepción, FHIR está diseñado para la interoperabilidad y define una API REST para el intercambio, manipulación y búsqueda de recursos. Mediante esta API es posible crear, modificar, eliminar y buscar los recursos.

Por ejemplo, para crear un paciente, tendríamos que crear el recurso y enviarlo mediante una petición POST al endpoint REST correspondiente:

POST https://path-servidor/Patient

Para solicitar un paciente, usaríamos una petición GET:

GET POST https://path-servidor/Patient/{id}

Existe gran cantidad de documentación en la web de FHIR:

Volver arriba

La organización de FHIR: niveles y módulos

El estándar FHIR está organizado en módulos que representan las distintas áreas funcionales de la especificación. Los módulos, a su vez, se agrupan en niveles, donde cada nivel corresponde a un nivel de abstracción superior.

Los niveles son, del más fundamental al más abstracto:

  • Nivel 1: Marco básico en el que se basa la especificación.
  • Nivel 2: Soporte a la implementación y relación con especificaciones externas.
  • Nivel 3: Relación con conceptos del mundo real en el sistema de atención sanitaria.
  • Nivel 4: Registro e intercambio de datos para el proceso de atención sanitaria.
  • Nivel 5: Provisión de la habilidad de razonar sobre el proceso de atención sanitaria.

En la siguiente imagen extraída de la web de FHIR se pueden observar los distintos niveles y los módulos que los componen:

Estructura de módulos y niveles del estandar HL7 FHIR
Organización de los módulos en niveles de FHIR. Fuente: https://www.hl7.org/fhir/modules.html#modules

Recursos sobre FHIR en Health Level International:

Volver arriba

El estándar CCOW

CCOW (Clinical Context Object Workgroup) es un estándar de interoperabilidad que pretende facilitar la integración de aplicaciones a nivel de uso mediante una técnica denominada Context Management.

Esta técnica permite sincronizar y unificar a nivel de interfaz de usuario la información de distintos sistemas que contienen información referida al mismo paciente, procedimiento o usuario.

Recursos en la web de Health Level Seven International:

Volver arriba

Conclusión

Aunque no son los únicos, en este artículo hemos visto los principales estándares HL7. Entre todos, destaca la mensajería HL7 V2 que podemos encontrar en casi cualquier sistema de información de salud. Además, conviene seguir de cerca al estándar FHIR, que promete ser el gran heredero en el futuro de la interoperabilidad en salud.

HL7, FHIR, CDA y sus logotipos son marcas registradas de Health Level Seven International.

Fotografía de cabecera por Bernard Hermant en Unsplash

Pedro M. TorresLos 5 estándares HL7 fundamentales

2 comentarios

Únete a la conversación
  • Vito - 19 septiembre, 2018 responder

    FHIR es un estándar abierto?

  • Pedro M. Torres - 19 septiembre, 2018 responder

    Hola, Vito,
    Sí, FHIR es abierto y gratuito.
    Puedes encontrar los detalles de la licencia en https://www.hl7.org/fhir/license.html

    Es una licencia muy poco restrictiva que incluso permite hacer obras derivadas, redistribuir y usarlo como quieras mientras respetes las marcas, las atribuciones del trabajo y algunas consideraciones más que entran dentro de lo razonable para que no perjudique al proyecto y al estándar.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Resumen de la Política de Privacidad

Responsable: Caduceus Software S.L.
Finalidad: Atender tu solicitud de publicar un comentario en este artículo. Además, si marcas "Recibir nuevos artículos por correo electrónico", suscribirte a nuestra lista de correo, .
Legitimación: Para poder publicar el comentario a tu nombre necesitamos tu nombre, email, web (opcional). Para evitar spam, tus datos personales y otra información técnica pueden ser enviados a un sistema automático de reconocimiento de spam (Akismet). Para suscribirte a nuestra lista de correo necesitamos tu correo electrónico.
Destinatarios: Tus datos para el comentario no se compartirán ni se cederán a terceros. Si marcas "Recibir nuevos artículos por correo electrónico", añadiremos tu dirección de correo y tu nombre a nuestra lista en MailChimp, una compañía estadounidense que cumple y respeta la privacidad de datos. Podrás darte de baja en cualquier momento.
Derechos: Puedes ejercer tus derechos escribiendo a info@caduceus.es o en nuestro formulario de contacto (https://www.caduceus.es/contacto/).

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.