Health Level Seven , abreviado como HL7 , es una serie de estándares globales para la transferencia de datos administrativos y clínicos de salud entre aplicaciones con el objetivo de mejorar los resultados de los pacientes y el rendimiento del sistema de salud. Los estándares HL7 se centran en la capa de aplicación, que es la "capa 7" en el modelo de interconexión de sistemas abiertos . Los estándares son producidos por Health Level Seven International , una organización de estándares internacionales , y son adoptados por otros organismos emisores de estándares como el Instituto Nacional Estadounidense de Estándares y la Organización Internacional de Normalización . Existe una serie de estándares primarios que se utilizan comúnmente en la industria, así como estándares secundarios que se adoptan con menos frecuencia.
Las organizaciones sanitarias suelen disponer de muchos sistemas informáticos diferentes que se utilizan para procesar distintas tareas clínicas o de administración de pacientes, como la facturación, la gestión de medicamentos, el seguimiento de pacientes y la documentación. Todos estos sistemas deberían comunicarse o "interactuar" entre sí cuando reciben nueva información o cuando desean recuperar información. HL7 International especifica una serie de estándares, directrices y metodologías flexibles mediante las cuales estos sistemas sanitarios pueden comunicarse entre sí. Los estándares permiten una "interoperabilidad" más sencilla de los datos sanitarios, ya que los diferentes sistemas los comparten y procesan de forma uniforme y coherente. Esto permite compartir datos clínicos y no clínicos con mayor facilidad, lo que teóricamente mejora la atención al paciente y el rendimiento del sistema sanitario. [1]
HL7 International considera que los siguientes estándares son sus estándares principales, aquellos estándares que se usan e implementan con mayor frecuencia: [2]
Otros estándares/metodologías HL7 incluyen: [3]
El estándar HL7 versión 2 (también conocido como Pipehat) tiene como objetivo apoyar los flujos de trabajo hospitalarios. Fue creado originalmente en 1989. [4]
La versión 2 de HL7 define una serie de mensajes electrónicos para respaldar procesos administrativos, logísticos, financieros y clínicos. Desde 1987, el estándar se ha actualizado periódicamente, lo que ha dado lugar a más de diez iteraciones. Los estándares v2.x son compatibles con versiones anteriores , lo que significa que una aplicación que admita la versión 2.6 comprenderá un mensaje basado en la versión 2.3.
Los mensajes HL7 v2.x utilizan una sintaxis de codificación no XML basada en segmentos ( líneas ) y delimitadores de un carácter . [5] Los segmentos tienen compuestos ( campos ) separados por el delimitador compuesto. Un compuesto puede tener subcompuestos (componentes) separados por el delimitador de subcompuesto, y los subcompuestos pueden tener sub-subcompuestos (subcomponentes) separados por el delimitador de sub-subcompuesto. Los delimitadores predeterminados son retorno de carro para el separador de segmento, barra vertical o tubería ( |) para el separador de campo, acento circunflejo ( ^) para el separador de componente, ampersand ( &) para el separador de subcomponente y signo de número (#) para el separador de truncamiento predeterminado. La tilde ( ~) es el separador de repetición predeterminado. Cada segmento comienza con una cadena de 3 caracteres que identifica el tipo de segmento. Cada segmento del mensaje contiene una categoría específica de información. Cada mensaje tiene MSHcomo primer segmento, que incluye un campo que identifica el tipo de mensaje. El tipo de mensaje determina los tipos de segmento esperados en el mensaje. [6] Los tipos de segmento utilizados en un tipo de mensaje particular se especifican mediante la notación de gramática de segmento utilizada en los estándares HL7.
El siguiente es un ejemplo de un mensaje de admisión. MSHes el segmento de encabezado, PIDla identidad del paciente, PV1es la información de la visita del paciente, etc. El quinto campo en el PIDsegmento es el nombre del paciente, en el orden, apellido, nombre de pila, segundo nombre (o sus iniciales), sufijo, etc. Dependiendo de la versión estándar de HL7 V2.x, hay más campos disponibles en el segmento para información adicional del paciente.
MSH|^~\&|MegaReg|XYZHospC|SuperOE|XYZImgCtr|20060529090131-0500||ADT^A01^ADT_A01|01052901|P|2.5EVENTO||200605290901||||PID|||56782445^^^UAReg^PI||KLEINSAMPLE^BARRY^Q^JR||19620910|M||2028-9^^HL70005^RA99113^^XYZ|260 GOODWIN CREST DRIVE^^BIRMINGHAM^AL^35209^^M~NICKELL'S PICKLES^10000 W 100TH AVE^BIRMINGHAM^AL^35200^^O|||||||0105I30001^^^99DEF^ANPV1||I|W^389^1^UABH^^^^3||||12345^MORGAN^REX^J^^^MD^0010^UAMC^L||67890^GRAINGER^LUCY^X^^^MD^0010^UAMC^L|MED|||||A0||13579^POTTER^SHERMAN^T^^^MD^0010^UAMC^L||||||||||||||||||||||||||||||200605290900OBX|1|NM|^Altura del cuerpo||1,80|m^Metro^ISO+|||||FOBX|2|NM|^Peso corporal||79|kg^Kilogramo^ISO+|||||FAL1|1||^ASPIRINADG1|1||786.50^DOLOR EN EL PECHO, NO ESPECIFICADO^I9|||A
HL7 v2.x ha permitido la interoperabilidad entre una gran cantidad de sistemas de salud digitales, desde sistemas de administración de pacientes hasta registros médicos electrónicos y sistemas de información especializados de laboratorio y radiología. Actualmente, el estándar de mensajería HL7 v2.x cuenta con el respaldo de todos los principales proveedores de informática sanitaria de los Estados Unidos. [7]
El estándar HL7 versión 3 tiene como objetivo dar soporte a todos los flujos de trabajo de atención médica. [8] El desarrollo de la versión 3 comenzó alrededor de 1995, dando como resultado una publicación estándar inicial en 2005. El estándar v3, a diferencia de la versión 2, se basa en una metodología formal (la HDF) y principios orientados a objetos.
RIM - ISO/HL7 21731
El modelo de información de referencia [9] (RIM) es la piedra angular del proceso de desarrollo de HL7 versión 3 y una parte esencial de la metodología de desarrollo de HL7 V3. El RIM expresa el contenido de datos necesario en un contexto clínico o administrativo específico y proporciona una representación explícita de las conexiones semánticas y léxicas que existen entre la información contenida en los campos de los mensajes HL7. [10]
Marco de desarrollo HL7: ISO /HL7 27931
El marco de desarrollo de HL7 versión 3 (HDF) es un proceso en constante evolución que busca desarrollar especificaciones que faciliten la interoperabilidad entre los sistemas de atención médica. El RIM de HL7, las especificaciones de vocabulario y el proceso de análisis y diseño basado en modelos se combinan para hacer de HL7 versión 3 una metodología para el desarrollo de estándares basados en consenso para la interoperabilidad de los sistemas de información de atención médica . El HDF es la edición más actual de la metodología de desarrollo de HL7 V3.
El HDF no solo documenta los mensajes, sino también los procesos, herramientas, actores, reglas y artefactos relevantes para el desarrollo de todas las especificaciones estándar de HL7. Con el tiempo, el HDF abarcará todas las especificaciones estándar de HL7, incluidas todas las nuevas normas resultantes del análisis de las arquitecturas y los requisitos de los registros médicos electrónicos.
Las especificaciones HL7 se basan en códigos y vocabularios de diversas fuentes. El trabajo de vocabulario V3 garantiza que los sistemas que implementan las especificaciones HL7 tengan una comprensión inequívoca de las fuentes de código y los dominios de valores de código que están utilizando.
Mensajería V3
El estándar de mensajería HL7 versión 3 define una serie de mensajes de texto seguros (llamados interacciones ) para respaldar todos los flujos de trabajo de atención médica.
Los mensajes HL7 v3 se basan en una sintaxis de codificación XML, como se muestra en este ejemplo: [11] : 2.2.1
<POLB_IN224200 ITSVersion= "XML_1.0" xmlns= "urn:hl7-org:v3" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" > <id root= "2.16.840.1.113883.19.1122.7" extension= "CNTRL-3456" /> <creationTime value= "200202150930-0400" /> <!-- La versión de los tipos de datos/RIM/vocabulario utilizada es la de mayo de 2006 --> <versionCode code= "2006-05" /> <!-- interaction id= Evento de observación completo, sin responsabilidades del receptor --> <interactionId root= "2.16.840.1.113883.1.6" extensión= "POLB_IN224200" /> <processingCode código= "P" /> <processingModeCode nullFlavor= "OTH" /> <acceptAckCode código= "ER" /> <receiver typeCode= "RCV" > <device classCode= "DEV" determinerCode= "INSTANCE" > <id extensión= "GHH LAB" raíz= "2.16.840.1.113883.19.1122.1" /> <asLocatedEntity código de clase= "LOCE" > <location código de clase= "PLC" determinerCode= "INSTANCE" > <id raíz= "2.16.840.1.113883.19.1122.2" extensión= "ELAB-3" /> </location> </asLocatedEntity> </device> </receiver> < código tipo remitente = "SND" > <código clase dispositivo = "DEV" código determinante= "INSTANCIA" > <id raíz= "2.16.840.1.113883.19.1122.1" extensión= "GHH OE" /> <asLocatedEntity código clase= "LOCE" > <código clase ubicación = "PLC" código determinante= "INSTANCIA" > <id raíz= "2.16.840.1.113883.19.1122.2" extensión= "BLDG24" /> </location> </asLocatedEntity> </device> </sender> <!-- Control de eventos de activación y contenido de dominio --> </POLB_IN224200> La arquitectura de documentos clínicos HL7 (CDA) es un estándar de marcado basado en XML destinado a especificar la codificación, la estructura y la semántica de los documentos clínicos para su intercambio. [12] El estándar se publicó conjuntamente con ISO como ISO/HL7 27932.
El marco del Documento de Continuidad de Atención es un estándar específico de EE. UU. para el intercambio de resúmenes médicos, basado en el estándar de Arquitectura de Documentos Clínicos.
El etiquetado estructurado de productos describe la información publicada que acompaña a un medicamento, según HL7 versión 3.
CCOW , o "Clinical Context Object Workgroup", es un protocolo estándar diseñado para permitir que aplicaciones dispares compartan el contexto del usuario y del paciente en tiempo real y a nivel de interfaz de usuario. Las implementaciones de CCOW generalmente requieren un sistema de bóveda de CCOW para administrar la seguridad del usuario entre aplicaciones.
Fast Healthcare Interoperability Resources es una especificación de interoperabilidad moderna de HL7 International diseñada para ser más fácil de implementar, más abierta y más extensible que las versiones HL7 2.x o 3.x. Aprovecha un conjunto moderno de tecnología API basada en la web, que incluye un protocolo RESTful basado en HTTP , HTML y hojas de estilo en cascada para la integración de la interfaz de usuario, una opción de JSON o XML para la representación de datos, OAuth para la autorización y ATOM para los resultados de las consultas. [13] El objetivo principal del estándar FHIR es garantizar la interoperabilidad entre diferentes sistemas informáticos. Define el formato de datos y el protocolo para intercambiar información médica, independientemente de cómo se almacene en estos sistemas. [14]
El marco de arquitectura empresarial consciente de los servicios HL7 (SAIF) proporciona coherencia entre todos los artefactos HL7, permite un enfoque estandarizado para el desarrollo y la implementación de la arquitectura empresarial (EA) y una forma de medir la coherencia.
SAIF es una forma de pensar en la producción de especificaciones que describan explícitamente la gobernanza, la conformidad, el cumplimiento y la semántica de comportamiento que se necesitan para lograr la interoperabilidad funcional semántica computable. La tecnología de transmisión de información prevista podría utilizar un enfoque de mensajería, intercambio de documentos o servicio.
SAIF es el marco necesario para racionalizar la interoperabilidad de otros estándares. SAIF es una arquitectura para lograr la interoperabilidad, pero no es un diseño de solución integral para la gestión de la arquitectura empresarial.
La sintaxis Arden es un lenguaje para codificar el conocimiento médico. HL7 International adoptó y supervisa el estándar a partir de la sintaxis Arden 2.0. Estos módulos de lógica médica ( MLM ) se utilizan en el ámbito clínico, ya que pueden contener suficiente conocimiento para tomar decisiones médicas individuales. [ cita requerida ] Pueden producir alertas, diagnósticos e interpretaciones junto con la función de control de calidad y soporte administrativo. Un MLM debe ejecutarse en una computadora que cumpla con los requisitos mínimos del sistema y tenga el programa correcto instalado. Luego, el MLM puede brindar asesoramiento sobre cuándo y dónde se necesita.
Clinical Quality Language (CQL) es un estándar de lenguaje de expresión de alto nivel centrado en la clínica y certificado por ANSI [15] , creado por Health Level 7. [16] Está diseñado para compartir conocimientos clínicos en los dominios de la medición electrónica de la calidad clínica y el apoyo a la toma de decisiones clínicas . [17]
El lenguaje de calidad clínica se utiliza para una variedad de aplicaciones clínicas, incluidas las directrices SMART de la OMS , donde se utiliza para codificar la lógica de decisiones y los indicadores de desempeño. [18] Los Centros de Servicios de Medicare y Medicaid adoptaron el CQL para las especificaciones de las medidas de calidad clínica desde 2019. [19] [20]
CQL permite la expresión modular y flexible de la lógica y es legible por humanos y procesable por máquinas. [19]
En 2023, el Comité Nacional de Garantía de Calidad publicó y publicó una implementación de CQL con el objetivo de fomentar la adopción del lenguaje. [21]
Una gran parte de la mensajería HL7 se transporta mediante el protocolo de capa inferior mínima (MLLP), también conocido como protocolo de capa inferior (LLP) [22] o protocolo de capa mínima (MLP). [23] Para transmitir a través de TCP/IP, se agregan caracteres de encabezado y final al mensaje para identificar el comienzo y el final del mensaje porque TCP/IP es un flujo continuo de bytes. [24] El protocolo de capa inferior híbrido (HLLP) es una variación de MLLP que incluye una suma de comprobación para ayudar a verificar la integridad del mensaje. Entre otros proveedores de software, MLLP es compatible con Microsoft, [25] Oracle, [26] Cleo . [27]
MLLP no contiene seguridad ni cifrado inherentes, sino que se basa en protocolos de capa inferior, como Seguridad de la capa de transporte (TLS) o IPsec, para salvaguardar la información sanitaria protegida fuera de una red segura.
Especificaciones funcionales para una historia clínica electrónica .
Un segmento OBR transporta información sobre un examen, estudio de diagnóstico/observación. [28] Es un segmento obligatorio en un mensaje ORM (mensaje de orden) [29] o un mensaje ORU (resultado de observación). [30]
Este artículo incorpora texto de una obra de contenido libre . Licencia Creative Commons Attribution-ShareAlike 3.0. Texto tomado de Spronk 2007.