Health Level Seven , abreviado como HL7 , es una gama de estándares globales para la transferencia de datos de salud clínicos y administrativos 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 internacional de estándares , 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 variedad de estándares primarios que se utilizan comúnmente en toda la industria, así como estándares secundarios que se adoptan con menos frecuencia.
Las organizaciones de salud suelen tener muchos sistemas informáticos diferentes que se utilizan para procesar diferentes tareas clínicas o de administración de pacientes, como facturación, gestión de medicamentos, seguimiento de pacientes y documentación. Todos estos sistemas deben comunicarse o "interconectarse" entre sí cuando reciben nueva información o cuando desean recuperar información. HL7 International especifica una serie de estándares, pautas y metodologías flexibles mediante las cuales estos sistemas de atención médica 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 manera uniforme y coherente. Esto permite compartir más fácilmente datos clínicos y no clínicos, lo que en teoría mejora la atención al paciente y el rendimiento del sistema de salud. [1]
HL7 International considera que los siguientes estándares son sus estándares principales, aquellos estándares que se utilizan e implementan con mayor frecuencia: [2]
Otros estándares/metodologías de HL7 incluyen: [3]
El estándar HL7 versión 2 (también conocido como Pipehat) tiene como objetivo respaldar los flujos de trabajo hospitalarios. Fue creado originalmente en 1989. [4]
HL7 versión 2 define una serie de mensajes electrónicos para respaldar procesos administrativos, logísticos, financieros y clínicos. Desde 1987, la norma se ha actualizado periódicamente, lo que ha dado como resultado más de diez iteraciones. Los estándares v2.x son compatibles con versiones anteriores , lo que significa que un mensaje basado en la versión 2.3 será entendido por una aplicación que admita la versión 2.6.
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 subsubcompuestos (subcomponentes) separados por el delimitador de subsubcompuesto. Los delimitadores predeterminados son retorno de carro para el separador de segmentos, barra vertical o tubería ( |) para el separador de campos, signo de intercalación ( ^) para el separador de componentes, signo comercial ( &) para el separador de subcomponentes y signo numérico (#) 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. Todo mensaje tiene MSHcomo primer segmento, el cual 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 gramatical 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.5EVN||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 DE 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 es compatible con todos los principales proveedores de informática sanitaria de los Estados Unidos. [7]
El estándar HL7 versión 3 tiene como objetivo admitir todos los flujos de trabajo de atención médica. [8] El desarrollo de la versión 3 comenzó alrededor de 1995, lo que resultó en 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 (HDF) y principios orientados a objetos.
LLANTA - 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. 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 (HDF) HL7 Versión 3 es un proceso en continua evolución que busca desarrollar especificaciones que faciliten la interoperabilidad entre sistemas de salud. 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 sistemas de información de atención médica . El HDF es la edición más actual de la metodología de desarrollo 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 del estándar HL7. Con el tiempo, el HDF abarcará todas las especificaciones del estándar HL7, incluido cualquier nuevo estándar resultante del análisis de las arquitecturas y requisitos de los registros médicos electrónicos.
Las especificaciones de HL7 se basan en códigos y vocabularios de una variedad de fuentes. El trabajo de vocabulario V3 garantiza que los sistemas que implementan las especificaciones HL7 tengan una comprensión inequívoca de las fuentes del código y los dominios de valores del 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 seguro (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 utilizados es la de mayo de 2006 --> < código versionCode = "2006-05" /> <!-- id de interacción= Evento de observación completo, sin responsabilidades del receptor --> <id de interacción raíz= "2.16.840.1.113883.1.6" extensión= "POLB_IN224200" /> < código de código de procesamiento = "P" /> <processingModeCode nullFlavor= "OTH" /> <acceptAckCode code= "ER" /> <receiver typeCode= "RCV" > <device classCode= "DEV" determinerCode= "INSTANCIA" > <id extensión= " GHH LAB" root= "2.16.840.1.113883.19.1122.1" /> <asLocatedEntity classCode= "LOCE" > <ubicación classCode= "PLC" determinerCode= "INSTANCIA" > <id root= "2.16.840.1.113883.19.1122.2" extensión= "ELAB-3" /> </ ubicación> </asLocatedEntity> </device> </receiver> <sender typeCode= "SND" > <device classCode= "DEV" determinerCode= "INSTANCIA" > <id raíz= "2.16.840.1.113883.19.1122.1" extensión= "GHH OE" /> <asLocatedEntity classCode= "LOCE" > <ubicación classCode= "PLC" determinerCode= "INSTANCIA" > <id raíz= "2.16.840.1.113883.19.1122 .2" extensión= "BLDG24" /> </ ubicación> </asLocatedEntity> </device> </sender> <!-- Ley de control de eventos de activación y contenido de dominio --> </POLB_IN224200> La Arquitectura de Documento Clínico (CDA) HL7 es un estándar de marcado basado en XML destinado a especificar la codificación, estructura y semántica de documentos clínicos para intercambio. [12] La norma se publicó conjuntamente con ISO como ISO/HL7 27932.
El marco del Documento de Continuidad de la 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 Documento Clínico.
El etiquetado estructurado del producto describe la información publicada que acompaña a un medicamento, según HL7 versión 3.
CCOW , o "Grupo de trabajo de objetos de contexto clínico", es un protocolo estándar diseñado para permitir que aplicaciones dispares compartan el contexto del usuario y el contexto del paciente en tiempo real y en el nivel de la interfaz de usuario. Las implementaciones de CCOW normalmente requieren un sistema de bóveda CCOW para gestionar 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 2.x o 3.x de HL7. Aprovecha un moderno conjunto de tecnología API basado en 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 autorización y ATOM para resultados de 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 el intercambio de información médica, independientemente de cómo se almacene en estos sistemas. [14]
El marco de arquitectura empresarial compatible con servicios (SAIF) de HL7 proporciona coherencia entre todos los artefactos de HL7 y 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 del trabajo semántico 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 interoperabilidad, pero no es un diseño de solución completa para la gestión de arquitectura empresarial.
La sintaxis de Arden es un lenguaje para codificar el conocimiento médico. HL7 International adoptó y supervisa el estándar comenzando con la sintaxis Arden 2.0. Estos módulos de lógica médica ( MLM ) se utilizan en el entorno clínico, ya que pueden contener conocimientos suficientes para tomar decisiones médicas únicas. [ cita necesaria ] 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 instalado el programa correcto. Luego, el MLM puede brindar asesoramiento sobre cuándo y dónde sea necesario.
Clinical Quality Language (CQL) es un estándar de lenguaje de expresión de alto nivel con enfoque clínico certificado por ANSI [15] y curado por Health Level 7. [16] Está diseñado para compartir conocimientos clínicos en los dominios de medición electrónica de la calidad clínica y apoyo a las 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 CQL para especificaciones de 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]
El Comité Nacional de Garantía de Calidad publicó una implementación de CQL de código abierto en 2023 con el objetivo de fomentar la adopción del lenguaje. [21]
Una gran parte de la mensajería HL7 se transporta mediante el protocolo mínimo de capa inferior (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 principio y el final del mensaje porque TCP/IP es un flujo continuo de bytes. [24] El Protocolo híbrido de capa inferior (HLLP) es una variación de MLLP que incluye una suma de verificación para ayudar a verificar la integridad del mensaje. Entre otros proveedores de software, MLLP cuenta con el respaldo de Microsoft, [25] Oracle, [26] Cleo . [27]
MLLP no contiene seguridad ni cifrado inherentes, pero se basa en protocolos de capa inferior, como Transport Layer Security (TLS) o IPsec, para salvaguardar la información médica 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 requerido en un mensaje ORM (mensaje de orden) [29] o un mensaje ORU (Resultado de observación). [30]
Este artículo incorpora texto de un trabajo de contenido gratuito . Licenciado bajo licencia Creative Commons Attribution-ShareAlike 3.0. Texto tomado de Spronk 2007.