Los estándares HL7 se utilizan en todo el mundo para la integración de sistemas sanitarios. Hay 5 estándares fundamentales (primary standards): HL7 V2, HL7 V3, FHIR, CDA y CCOW. Sigue leyendo para conocerlos, descubrir sus principales características y acceder a recursos clave para dominarlos.
¿Qué es HL7®? #
HL7 es el acrónimo de la organización Health Level Seven International. Es una organización sin ánimo de lucro dedicada a la creación de estándares de informática sanitaria.
HL7 se fundó en 1987 y cuenta con 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.
Te preguntarás: ¿existió HL6 o HL5?
La respuesta es «no». El Health Level Seven se refiere a la capa 7 del modelo OSI, el nivel de aplicación, para el sector sanitario. Según Wikipedia, la capa 7 «ofrece a las aplicaciones la posibilidad de acceder a los servicios de las otras capas y define los protocolos que utilizan las aplicaciones para intercambiar datos«. Por tanto, el Nivel Siete de Salud significa «Nivel de Aplicación en Salud» y se refiere a los protocolos y normas para intercambiar información entre aplicaciones sanitarias.
En resumen, HL7 se encarga de definir un marco y unas normas para el intercambio, la integración y el acceso a la información sanitaria electrónica.
¿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 o normas definen el lenguaje, la estructura y los tipos de datos necesarios para una integración fluida entre sistemas sanitarios.
Miles de hospitales de todo el mundo utilizan a diario estos estándares para intercambiar información entre sus sistemas. Cuando hablamos de estándres HL7, hablamos de interoperabilidad sanitaria.
Además de los estándares HL7, hay muchas otros que suelen aparecer junto a ellos. Puedes consultar nuestra guía de estándres 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, FHIR y CDA. Se conocen como estándares fundamentales (HL7 primary standards) y son los más utilizados para la integración e interoperabilidad de sistemas.
HL7 CCOW (HL7 Context Management Specification) formaba parte de los estándares fundamentales de HL7. Pero, esta especificación ha sido retirada, y está siendo sustituida por HL7 FHIRCast.
Hay mucha información sobre los estándares fundamentales en el sitio 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, la más extendida y utilizada de los estándares de interoperabilidad.
Se utiliza en el 95% de las organizaciones sanitarias de EE.UU. y está presente en más de 35 países.
Su primera versión se publicó en octubre de 1987, y desde entonces se han publicado múltiples actualizaciones. Las versiones suelen denominarse de la forma V2.X. En 2019 se publicó la versión HL7 V2.9, que es la más reciente hasta la fecha de este artículo.
Una versión muy utilizada de la versión 2 de HL7 es la V2.5, aunque las versiones V2.3, V2.6 y V2.7 también son muy comunes.
Mensajería HL7 V2 #
Hay muchos tipos de mensajes HL7 V2, pero los más utilizados son los de gestión de pacientes (ADT), órdenes (ORM) y resultados (ORU). Los mensajes son cadenas de texto divididas en segmentos. El segmento más importante es el de cabecera o MSH, que aparece en primer lugar y contiene, entre otros datos, el tipo de mensaje del que se trata.
Los mensajes HL7 V2 tienen un aspecto muy característico, son varias líneas largas de texto 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^JOHN|SMITH|19930803000000|M|||STREET&MAIN&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|||UNKNOWN|||ESP^SPAIN||||N
PD1|||^^^^^^FI^^^16012810~CENTRAL HOSPITAL^^^^^^XX^^^281270|^^^^^^^^^^^^^^^1231280107M PV1|1|NEn estos mensajes, cada línea corresponde a un segmento que se identifica por sus tres primeras letras. Tras 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 subcomponentes están separados por caracteres separadores especiales. Los caracteres recomendados son:
- «
|«: separador de campos (barra o tubo). - «
^«: separador de componentes (sombrero). - «
&«: separador de subcomponentes. - «
~«: separador en las iteraciones de campo. - «
\«: carácter de escape.
A partir de la versión 2.3 del estándar HL7, los mensajes también pueden codificarse en formato XML. Esta codificación se llama v2.xml.
Recursos sobre HL7 V2 en Health Level Seven International:
- Resumen de estándares.
- Guía de codificación XML v2.xml para mensajería HL7 Versión 2.5 y anteriores.
HL7 V2 vs HL7 V3 #
El estándar HL7 V2 es el más utilizado, pero tiene algunos inconvenientes. Como HL7 V2 tiene una gran flexibilidad y es muy adaptable, las diferencias entre las distintas implementaciones requieren un análisis profundo y mucha negociación para lograr la integración. Por otra parte, estas diferencias y flexibilidad también complican las pruebas y los ensayos 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 resolver 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 un enfoque semántico, basado en modelos, que es mucho más estricto y normativo que en la versión 2. La primera versión de HL7 versión 3 se lanzó en 2003 y se ha actualizado varias veces desde entonces. Cada nueva versión se identifica por el año en que se publicó, por ejemplo, «HL7 V3 2017».
La mensajería y los documentos de la versión 3 se definen en sintaxis XML, a diferencia del formato de barras utilizado en HL7 V2. También insiste mucho en el uso de vocabularios controlados (como CIE-11, LOINC y SNOMED CT), además de sus propias codificaciones.
La complejidad y extensión de la versión 3 de HL7 hacen que no sea fácil implantarla o migrar desde la versión 2. Además, tiene que competir con la propia versión 2, que está en producción satisfactoriamente en casi todas partes. Tal vez por estas razones, la versión 3 del estándar no está tan extendida como la anterior; sin embargo, se utiliza en varios servicios públicos de salud, como el Reino Unido, Países Bajos y Canadá.
Recursos sobre HL7 V3 en el sitio web de Health Level Seven International:
HL7 V3 RIM: Modelo de Información de Referencia #
Una de las principales características del estándar HL7 V3 es que se basa en el RIM (Reference Information Model, Modelo de Información de Referencia), un amplio modelo de objetos de referencia para 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 utiliza para el desarrollo de todo el estándar.
Información sobre RIM en Health Level Seven International:
El estándar HL7 CDA® #
El estándar HL7 CDA® es un estándar de documentación clínica. Esta especificación pretende facilitar el intercambio de información en forma de documentos entre prestadores de servicios sanitarios y pacientes. Los CDA pueden contener cualquier tipo de información clínica, por ejemplo: informes de alta, de radiología, de patología, o la exploración y anamnesis del paciente. CDA se basa en el modelo de datos RIM y en la metodología de trabajo HL7 V3
CDA es la abreviatura de Clinical Document Architecture (Arquitectura de Documentos Clínicos). La primera versión (CDA Versión 1) se lanzó en 2000, la segunda versión (CDA Versión 2 o CDAR2) se lanzó en 2005 y se adoptó como norma ISO/HL7 27932:2009.
Características de un documento CDA #
Según la norma CDA, las seis características que un documento clínico debe tener son:
- Persistencia: el documento permanece inalterado a lo largo del tiempo, independientemente de los cambios externos.
- Custodia: el documento debe ser gestionado por una organización o entidad.
- Posibilidad de autenticación: el documento debe tener validez legal.
- Contexto: el documento define un contexto de participantes (como el paciente o el médico), acto, proveedor de servicios sanitarios, etc.
- Integridad: el documento debe entenderse como una unidad de contenido.
- Legibilidad humana: aunque pueda 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. La creación, el almacenamiento y el intercambio de los documentos quedan fuera del alcance del estándar.
Un documento CDA se especifica en formato XML y consta de dos partes: la cabecera (header) y el cuerpo (body).
La cabecera contiene metainformación sobre el documento:
- Atributos de cabecera: identificación, fecha, título, idioma, etc.
- Participantes: el autor, el paciente, el proveedor, etc.
- Actos relacionados: otros documentos, autorizaciones, etc.
El cuerpo contiene la información del documento. Esta información debe contener siempre una parte textual que garantice 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 totalmente estructurado y codificado.
La codificación del contenido de los documentos se realiza mediante estándares de codificación, como SNOMED-CT, CIE-11 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 la versión 2 de CDA en el sitio web de 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 centra en facilitar su implantación. Además, utiliza los estándares web más comunes, 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). A día de hoy en 2023, FHIR 5 es la versión más reciente.
Puedes seguir la evolución de las distintas versiones publicadas en el historial de versiones de FHIR.
FHIR es la abreviatura de Fast Healthcare Interoperability Resources (Recursos de Interoperabilidad Sanitaria Rápida) Los recursos son las piezas clave de FHIR.
¿Qué son los recursos FHIR? #
Los Recursos son los bloques de construcción de todos los intercambios de información en FHIR. Cada recurso representa un concepto de la realidad 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 comunes:
- Una URL que identifica el recurso.
- Metadatos comunes.
- Un resumen legible por humanos.
- Un marco de extensibilidad que permite diferencias en la asistencia sanitaria.
Vemos una representación de un recurso paciente en la que se han resaltado las partes características:
Utilizando estos recursos, los procedimientos clínicos y administrativos pueden modelarse rápidamente y con menos complejidad que con otras alternativas.
Es posible consultar la lista completa de recursos, donde se definen más de 150 recursos. Además, cada recurso incluye documentación y ejemplos.
¿Cómo se gestionan e intercambian los recursos FHIR? #
Desde su concepción, FHIR está pensado para la interoperabilidad y define una API REST para el intercambio, manipulación y búsqueda de recursos. A través de esta API, es posible crear, modificar, eliminar y buscar 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-server/PatientPara solicitar un paciente, utilizaríamos una solicitud GET:
GET POST https://path-server/Patient/{id}Hay mucha documentación en el sitio web de FHIR:
- Documentación sobre la API REST.
- Guía del desarrollador, que es un buen punto de partida.
La organización de FHIR: niveles y módulos #
El estándar FHIR está organizada 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 superior de abstracción.
Los niveles son, desde el más fundamental al más abstracto:
- Nivel 1: Marco básico en el que se basa la especificación.
- Nivel 2: Apoyo a la aplicación y relación con especificaciones externas.
- Nivel 3: Relación con conceptos del mundo real en el sistema sanitario.
- Nivel 4: Registro e intercambio de datos para el proceso sanitario.
- Nivel 5: Provisión de la capacidad de razonar sobre el proceso sanitario.
En la siguiente imagen extraída del sitio web de FHIR, puedes ver los distintos niveles y los módulos que los componen:
Recursos sobre FHIR en 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 sanitaria. Además, es aconsejable seguir de cerca el estándar FHIR, que promete ser el gran heredero en el futuro de la interoperabilidad sanitaria.
HL7, FHIR, CDA y sus logotipos son marcas registradas de Health Level Seven International.
