- Español
- English
- Deutsch
- Français
- Italiano
- Português
HL7 son las siglas de Health Level 7 y se trata de un conjunto de normas clínicas y formatos de mensajería que proporcionan un marco para la gestión, integración, intercambio y recuperación de información electrónica entre distintos sistemas sanitarios. Las normas HL7 son desarrolladas y mantenidas por Health Level Seven International, una organización de normalización sanitaria.
El objetivo de HL7 es mejorar la interoperabilidad entre los sistemas de información sanitaria (HIS) que lo han implantado. Se centra en las interfaces entre HIS distintos mediante la creación de un lenguaje común de intercambio de datos que utiliza mensajes predefinidos. Sin embargo, HL7 no dicta la arquitectura del sistema ni cómo se almacenan los datos en una aplicación.
HL7 es un protocolo basado en transacciones que se rige por eventos como el ingreso de un paciente en un hospital.
Las alertas personalizadas y la visualización de datos le permiten identificar y prevenir rápidamente los problemas de salud y rendimiento de la red.
Históricamente, la comunicación entre distintos tipos de software utilizados por diferentes organizaciones siempre ha supuesto un reto. Lo mismo ocurre con la asistencia sanitaria.
Los distintos tipos de sistemas sanitarios utilizan aplicaciones diferentes, programadas en lenguajes distintos y con funciones diferentes. Por ejemplo, los hospitales utilizan sistemas complejos y personalizados, mientras que los médicos de cabecera suelen utilizar programas de gestión de consultas listos para usar. Los institutos de investigación médica pueden utilizar software que forma parte de una red mayor, como una universidad. A menudo, este tipo de instituciones necesitan intercambiar datos sobre los pacientes.
El objetivo de HL7 es permitir a las organizaciones sanitarias crear datos uniformes que cualquiera con autorización pueda recuperar y utilizar en sus propios sistemas. La interoperabilidad entre organizaciones sanitarias requiere que las interfaces entre los distintos sistemas utilicen un protocolo común como HL7.
Implantar un sistema de historia clínica electrónica (HCE) es costoso. HL7 ayuda a optimizar el intercambio de datos entre aplicaciones y dispositivos y sugiere formas de automatizar los flujos de trabajo estándar, lo que reduce los costes operativos y laborales.
HL7 es una norma industrial aceptada internacionalmente para el intercambio de datos en la atención sanitaria. Además, es independiente de la plataforma y la tecnología.
HL7 se ha denominado norma no estándar porque el marco permite cierta personalización, por ejemplo el uso de campos opcionales y la posibilidad de añadir segmentos de mensajes.
Las organizaciones sanitarias compilan y utilizan aplicaciones dispares en función de sus necesidades específicas. HL7 permite a los desarrolladores crear interfaces para el intercambio de datos entre distintas organizaciones sanitarias en lugar de realizar cambios en su software.
HL7 permite compartir información sobre salud pública. HL7 tiene potencial para utilizarse en tiempos de crisis sanitarias nacionales, como la pandemia de COVID-19, para fomentar la colaboración entre instituciones gubernamentales y empresas sanitarias privadas y para compartir datos de investigación médica a escala mundial.
Las notificaciones en tiempo real significan una solución de problemas más rápida para que pueda actuar antes de que se produzcan problemas más graves.
Los estándares HL7 se agrupan en categorías de referencia denominadas secciones.
La Sección 1 define las especificaciones principales de conformidad, integración e interoperabilidad. La Sección 1 también describe los estándares complementarios de HL7 como Arquitectura de Documentos Clínicos (CDA), Registros Electrónicos de Salud (EHR), Fast Health Interop Resources (FHIR), Sintaxis Arden y Especificación de Gestión de Contexto Clínico (CCOW).
En la sección 2 se describen las normas documentales y los protocolos de mensajería para las especialidades clínicas.
La Sección 3 proporciona guías de implementación y casos de uso para los estándares existentes.
La sección 4 incluye directrices para el desarrollo de software y normas, especificaciones técnicas y estructuras de programación.
Una especificación para un procedimiento o un evento puede incluir material extraído de diferentes secciones de HL7. Por ejemplo, un procedimiento habitual en sanidad es la continuidad asistencial. La especificación para el estándar de continuidad asistencial consta de un estándar de arquitectura de documentos clínicos (sección 1), un documento de dominios clínicos y administrativos (sección 2) y una guía de implementación de estándares (sección 3).
Existen varias versiones de HL7. 2.las versiones x son las más utilizadas. La última versión de HL7 es HL7 FHIR.
HL7 versión 2.x
HL7 versión 2.x soporta variaciones de datos permitiendo campos opcionales y segmentos de mensaje adicionales. Todas las versiones HL7 2.x son compatibles con versiones anteriores.
HL7 versión 3
La versión 3 de HL7 se desarrolló como una redefinición completa del estándar HL7 original y pretendía ser más coherente y estructurada formalmente. HL7 versión 3 añadió más funcionalidad a HL7 versión 2.x, incluyendo herramientas para pruebas de conformidad y planificación de la implementación. La versión 3 de HL7 no ha sido ampliamente adoptada porque no es compatible con la versión 2.x de HL7.
HL7 FHIR
HL7 FHIR implementa la funcionalidad de las versiones 2.x y 3 y aprovecha el uso de servicios web. Los estándares HL7 originales no están configurados para funcionar bien con aplicaciones no clínicas como los dispositivos móviles. Las API basadas en FHIR permiten intercambiar mensajes HL7 con aplicaciones no clínicas.
FHIR permite al personal médico utilizar dispositivos móviles para comunicarse con servicios médicos clave de forma remota desde prácticamente cualquier lugar. FHIR permite a los pacientes utilizar dispositivos personales para acceder a sus historiales médicos personales (PHR) e interactuar directamente con algunos sistemas médicos, por ejemplo para ver los resultados de sus pruebas de laboratorio o reservar una consulta.
Las versiones principales del marco HL7 se complementan con otras normas que suelen diferenciarse de la norma base como productos y tecnologías suplementarios. Estos productos y tecnologías suplementarios se proporcionan en forma de directrices de implementación para procesos y procedimientos comunes, sintaxis compatibles, documentos de referencia y directrices para crear normas para casos de uso específicos.
En el futuro, es probable que los productos y tecnologías se identifiquen de manera más uniforme como perfiles para casos de uso específicos de HL7.
Algunos ejemplos de productos y tecnologías complementarios son el Documento de Continuidad Asistencial (CCD), el Etiquetado Estructurado de Productos (SPL), la Arquitectura de Documentos Clínicos (CDA), la Gestión del Contexto Clínico (CCOW) y la Sintaxis Arden.
El CCD es un documento electrónico que resume la información del paciente y ayuda a los profesionales sanitarios a compartir información clínica. La especificación SPL define la sintaxis de marcado para especificar la semántica de la información incluida con los medicamentos. CDA es una norma basada en XML para transferir datos clínicos. CCOW es la norma que permite la colaboración entre aplicaciones visuales en estaciones de trabajo clínicas. Arden Syntax es un lenguaje de marcado que se utiliza para representar y compartir información médica.
Una historia clínica electrónica (HCE) contiene toda la información sanitaria de un paciente, incluido su estado, medicación, procedimientos y diagnósticos. La HCE es generada y controlada por un médico. Un PHR es similar a un EHR pero está diseñado para ser controlado y gestionado por un paciente.
Los mensajes que se intercambian en los sistemas sanitarios incluyen información sobre admisiones, altas y traslados de pacientes; programación de visitas y exámenes de pacientes; solicitud de procedimientos; resultados de pruebas de laboratorio; consultas médicas; facturación e inventario de material; derivaciones de pacientes; y archivo de historias clínicas electrónicas.
El marco HL7 proporciona una biblioteca de definición de tipos de objetos (OTD), que es una colección de estructuras de mensajes preconstruidas. La biblioteca de mensajes HL7 permite a los proveedores sanitarios crear interfaces con sistemas de mensajería conformes a las normas HL7. HL7 también permite a los proveedores sanitarios personalizar los mensajes utilizando campos opcionales y añadiendo segmentos a los mensajes.
Un mensaje HL7 se compone de segmentos en una secuencia definida. Cada segmento tiene un identificador de tres caracteres llamado ID de segmento. Un ID de segmento describe qué información contiene el segmento, por ejemplo, segmento de encabezado de mensaje (MSH), información del paciente (PID), un tipo de evento (EVN) o detalles sobre la visita de un paciente (PV1).
Un segmento puede tener varias partes, como el segmento del accidente (ACC), que incluye campos para describir el accidente en sí, quién estuvo implicado, si el paciente falleció, y cuándo y dónde tuvo lugar el accidente.
Cada mensaje HL7 debe incluir un tipo de mensaje en la cabecera del mensaje. El tipo de mensaje describe qué tipo de mensaje se está transmitiendo. Un ejemplo de tipo de mensaje es DFT, o transacción financiera detallada.
Los tipos de mensaje se agrupan en categorías de información; por ejemplo, el tipo de mensaje DFT se encuentra en la categoría de información sobre gastos.
Cada categoría de información contiene varios códigos de activación que describen eventos específicos de esa categoría, como A01, que es el código de activación para admitir a un paciente.
Un evento desencadenante es un mensaje que describe un evento que ha tenido lugar. Los tipos de mensaje se utilizan junto con los códigos desencadenantes para iniciar la transmisión de un mensaje sobre un acontecimiento como, por ejemplo, el ingreso de un paciente en un centro médico. El encabezado del mensaje incluiría el evento desencadenante ADT-A01.
Los mensajes HL7 se agrupan por conjuntos de transacciones que describen la finalidad o el tipo de mensaje del grupo.
El conjunto de transacciones HL7 principal es el conjunto de transacciones de control. El conjunto de transacciones de control define reglas generales aplicables a todos los mensajes. Estas normas incluyen reglas de codificación de datos, cómo deben describirse los mensajes y cómo deben utilizarse los mensajes de acuse de recibo.
El conjunto de transacciones de administración de pacientes gestiona, entre otras cosas, los mensajes ADT.
Otros conjuntos de transacciones HL7 son los de gestión financiera, consultas, órdenes de procedimiento, informes de observación, horario de visitas, derivación de pacientes, gestión de historias clínicas, atención al paciente, automatización de laboratorios, gestión de aplicaciones y gestión de personal.
El conjunto de transacciones de archivo maestro es una colección de archivos de referencia que proporcionan información sobre estados de pacientes, tipos de pacientes, definiciones de pruebas de laboratorio, códigos de examen, ubicaciones, médicos, etc.
Los mensajes HL7 se transmiten mediante archivos HL7. Un archivo HL7 tiene la extensión .hl7 y sólo puede abrirse con software compatible con archivos HL7, por ejemplo 7Edit, QuickViewHL7 o el navegador Chameleon.
HL7 no especifica cómo los sistemas almacenan realmente los datos dentro de una aplicación. Sin embargo, el estándar sí especifica un tipo de datos para los campos de mensaje. Cuando se transmiten, los campos de mensaje se codifican y transmiten como cadenas de caracteres.
HL7 lo utilizan organizaciones sanitarias como hospitales, centros de diagnóstico por imagen, médicos, clínicas públicas, laboratorios, residencias, farmacias, instituciones de investigación médica y proveedores de software y hardware médico.
HL7 también se utiliza en centros médicos donde se intercambian mensajes entre distintos departamentos internos como rayos X, farmacia, fisioterapia, administración de pacientes, recursos humanos y finanzas.
Los usuarios de HL7 son desarrolladores de sistemas de TI, desarrolladores de interfaces clínicas especializadas, investigadores médicos y organizaciones médicas que necesitan compartir datos con otras instituciones y usuarios sanitarios.
Una interfaz HL7 consiste en un punto final para la aplicación emisora, un punto final para la aplicación receptora y un método de transmisión de datos entre los puntos finales. TCP/IP es el protocolo de transporte más utilizado para mover mensajes HL7 entre puntos finales.
A veces se hace referencia a una interfaz HL7 como motor de interfaz o motor de integración, pero estos términos describen funcionalidades ligeramente diferentes. Las interfaces punto a punto permiten que dos puntos finales se comuniquen independientemente de otros puntos finales de un sistema. Los motores de interfaz o de integración actúan como intermediarios para todas las interfaces que están conectadas a puntos finales en un sistema.
Aunque HL7 no proporciona un estándar de motor de interfaz plug-and-play, existen motores de interfaz comerciales y de código abierto que soportan HL7 y que pueden facilitar la personalización e implementación de interfaces HL7 para diferentes puntos finales.
Las normas HL7 se centran en la capa 7, la capa de aplicación, del modelo de Interconexión de Sistemas Abiertos (OSI). El modelo OSI estandariza las funciones de comunicación en los sistemas informáticos y de telecomunicaciones.
La importancia de la capa 7 en HL7 radica en que la capa de aplicación es donde los usuarios interactúan con una aplicación, es decir, en la interfaz. La capa 7 se ocupa de cómo se intercambian los datos, la seguridad de los datos, la disponibilidad de los datos, el control de acceso y las notificaciones de errores. También se accede a las API a través de la capa 7.
HL7 puede ser difícil de implementar entre sistemas que utilizan versiones diferentes, por ejemplo, la versión 3 de HL7 no es compatible con la versión 2.x de HL7.
HL7 no es una solución "plug-and-play" y puede necesitar cierta adaptación para diferentes modelos de datos de aplicación, por ejemplo, cuando no hay una terminología HL7 que coincida con la tecnología específica del proveedor.
Es posible que se necesiten recursos considerables para crear y probar interfaces compatibles con HL7 para cada punto final de un sistema sanitario. Mantener la interoperabilidad del sistema puede requerir ciclos de pruebas frecuentes cuando se añaden nuevos puntos finales.
Aunque la norma HL7 define la mejor manera de hacer las cosas y se presenta como un conjunto de reglas, no existe una contrapartida legal por no seguirlas. Esto podría llevar a las organizaciones a saltarse las normas para ahorrar tiempo y dinero a corto plazo, en detrimento de otros componentes del sistema sanitario a largo plazo.
PRTG es un software de monitoreo de red integral y realiza un seguimiento de toda su infraestructura de TI.
Las normas HL7 no regulan la arquitectura de los sistemas sanitarios, sino que proporcionan una guía sobre cómo debe estructurarse y compartirse la información clínica.
Tanto las normas HL7 originales basadas en archivos como los protocolos FHIR más recientes basados en XML están diseñados para automatizar el intercambio de datos, mejorar los flujos de trabajo de las transacciones y eventos médicos y ofrecer a los pacientes acceso a sus historiales desde sus propios dispositivos.
Integrating the Healthcare Enterprise (IHE) es una iniciativa para promover el uso de estándares como HL7 con el fin de ayudar a las organizaciones sanitarias a prestar una mejor asistencia sanitaria de forma más eficiente. IHE trabaja actualmente para extender el uso de perfiles en HL7. Un perfil HL7 es un estándar listo para usar diseñado para un caso de uso específico, como la continuidad de la atención sanitaria.
Para las organizaciones sanitarias es importante monitorear el estado de las interfaces clínicas en sus entornos, por ejemplo, errores de mensajes, estado de conexión a la red, colas de mensajes atascadas, estados de acuse de recibo (ACK) y mal funcionamiento de las máquinas. PTRG dispone de una solución de monitoreo proactivo diseñada para vigilar específicamente los problemas relacionados con HL7 en entornos sanitarios.
