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
- ¿Qué es HL7?
- ¿Qué son los estándares HL7?
- ¿Cuáles son los estándares HL7 más importantes?
- El estándar HL7 V2
- HL7 V2 vs HL7 V3
- El estándar HL7 V3
- El estándar HL7 CDA
- El estándar HL7 FHIR
- El estándar CCOW
- Conclusión
Última actualización: 4 de junio de 2021.
¿Qué es HL7®?
HL7 son las siglas de la organización Health Level Seven International. Se trata de una organización sin ánimo de lucro que se dedica a la creación de estándares de informática de la salud.
HL7 fue fundada en 1987 y participan en ella 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, la rama española o la rama argentina.
Puede que te preguntes: ¿existió 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 la Wikipedia, el nivel 7 «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, Health Level Seven quiere decir «Nivel de Aplicación en Salud» y se refiere a los protocolos y estándares para intercambiar información entre aplicaciones de salud.
En resumen, HL7 se encarga de definir un marco de trabajo y estándares para el intercambio, la integración y el acceso a la información electrónica de salud.
¿Qué son los estándares HL7?
Los estándares HL7 o protocolos HL7 indican cómo se organiza 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 fluida entre sistemas de salud.
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.
Además de los estándares HL7, existen muchos otros que aparecen a menudo junto a ellos. Puedes consultar nuestra guía de estándares de interoperabilidad en salud para saber más.
¿Cuáles son los estándares HL7 más importantes?
Los estándares HL7 más importantes son HL7 V2, HL7 V3, CDA, HL7 FHIR y CCOW. Estos cinco son los que se conocen como estándares primarios (HL7 primary standards) y son los más usados para la integración de sistemas y la interoperabilidad.
Hay una gran cantidad de información sobre los estándares primarios en la web de HL7.
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 2019 se publicó la versión HL7 V2.9 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.
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|NEn 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):
- Resumen del estándar.
- Guía de codificación en XML v2.xml para mensajería HL7 Version 2.5 y anteriores.
- Guías de implementación.
HL7 V2 vs HL7 V3
El estándar HL7 V2 es el más usado pero tiene algunos inconvenientes. Debido a que HL7 V2 tienen una gran flexibilidad y es muy adaptable, las diferencias entre distintas implementaciones requieren profundos análisis y mucha negociación para conseguir la integración. Por otro lado, estas diferencias y flexibilidad hacen que también sea complicado de 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.
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-10, LOINC 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):
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.
Información sobre RIM en Health Level Seven International (en inglés):
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. En la actualidad CDA Release 3 se encuentra en desarrollo.
CDA está basado en el modelo de datos RIM y en la metodología de trabajo de HL7 V3.
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.
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-CT, CIE-10 (ICD-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:
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 nació en 2011 y evolucionó rápidamente hasta que en 2019 se publicó su primera versión con contenido normativo FHIR Release 4 (versión 4.0.1). Es posible seguir la evolución de las distintas versiones publicadas en el histórico de versiones de FHIR.
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.
¿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:
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.
¿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/PatientPara 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:
- Documentación sobre la API REST de FHIR.
- Guía para el desarrollador FHIR, que es un buen sitio por donde empezar.
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:
Recursos sobre FHIR en Health Level International:
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:
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
5 comentarios
Únete a la conversaciónVito - 19 septiembre, 2018
FHIR es un estándar abierto?
Pedro M. Torres - 19 septiembre, 2018
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.
Victor Figueroa - 17 mayo, 2023
Pedro, como se pudiera elaborar un demo con datos de salud del gobierno ? son abiertos tambien ?
Pedro M. Torres - 18 mayo, 2023
Hola Victor, esa pregunta es difícil de responder sin más contexto sobre el tipo de datos, las organizaciones implicadas, etc. Algunos gobiernos tienen API de integración FHIR pública para integrar con proveedores, por ejemplo, pero eso no quiere decir que los datos estén disponibles públicamente.
En cualquier caso, te invito a publicar tu cuestión en nuestro foro https://www.caduceus.es/forum aportando toda la información que sea relevante.
ivan - 19 noviembre, 2021
habra una plantilla de cda que se pueda implementar en un consultorio privado que mantenga la privacidad de los datos, normalmente los servicios que lo hacen son costosos y entiendo el por que, pero creo que puede ayudar el tener una herramienta en la que haya interaccion con el paciente sin tener que elevar los costos de consulta para poder costearlo