HL7

El estándar HL7 versión 2 (también conocido como Pipehat) admite el flujo de trabajo diario de un hospital: tareas administrativas, facturación, logística y procesos clínicos como órdenes y resultados. ^{[ 4 ]} Se publicó por primera vez en 1987 y se ha revisado periódicamente desde entonces, dando lugar a más de diez versiones (de la 2.1 a la 2.9). ^{[ 5 ]} Las versiones v2.x son retrocompatibles entre sí, por lo que un mensaje creado para la versión 2.3 seguirá siendo comprendido por una aplicación que admita la versión 2.6.

A diferencia de los estándares HL7 más recientes, los mensajes de la versión 2.x se escriben como texto plano delimitado en lugar de XML . ^{[ 6 ]} Un mensaje se construye en cuatro capas anidadas, cada una separada de la siguiente por su propio carácter de puntuación:

• Cada segmento ocupa una línea y comienza con un código de tres caracteres que identifica su contenido (por ejemplo, PID para la identificación del paciente o PV1 para los detalles de la visita del paciente). Cada mensaje comienza con un segmento MSH , que indica el tipo de mensaje; esto determina qué otros segmentos se esperan a continuación.
• Un segmento se divide en campos mediante el carácter de barra vertical (| |). Por ejemplo, un campo del segmento PID contiene el nombre del paciente.
• Los componentes de un campo se pueden dividir aún más en componentes mediante un circunflejo ( ^), de modo que un campo de nombre puede contener componentes separados para el apellido, el nombre de pila, etc.
• Los subcomponentes pueden a su vez separarse mediante un signo de ampersand (& &) cuando se necesita un detalle aún más fino.

Dos caracteres más completan la sintaxis: una tilde ( ~) marca valores repetidos dentro de un campo, y desde HL7v2.7 un signo de número ( #) es el carácter de truncamiento predeterminado. ^{[ 7 ]}

El siguiente ejemplo es un mensaje de admisión. MSHes el encabezado; PIDcontiene la identidad del paciente; PV1contiene los detalles de la visita. En el segmento PID, el campo del nombre del paciente contiene tres componentes separados por circunflejos, apellido ( KLEINSAMPLE), nombre ( BARRY) e inicial del segundo nombre ( Q), lo que ilustra la división de campos/componentes descrita anteriormente.

MSH|^~\&|MegaReg|XYZHospC|SuperOE|XYZImgCtr|20060529090131-0500||ADT^A01^ADT_A01|01052901|P|2.5 EVN||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^AN PV1||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|||||||||||||||||||||||||||||200605290900 OBX|1|NM|^Altura del cuerpo||1,80|m^Metro^ISO+|||||F OBX|2|NM|^Peso corporal||79|kg^Kilogramo^ISO+|||||F AL1|1||^ASPIRINA DG1|1||786.50^DOLOR DE PECHO, NO ESPECIFICADO^I9|||A 

Esta flexibilidad ha permitido que HL7 v2.x interconecte una amplia gama de sistemas hospitalarios, desde la administración de pacientes hasta los registros médicos electrónicos y los sistemas especializados de laboratorio y radiología, y sigue contando con el soporte de todos los principales proveedores de informática sanitaria en los Estados Unidos. ^{[ 8 ]}

El estándar HL7 versión 3 tiene como objetivo dar soporte a todos los flujos de trabajo sanitarios. ^{[ 9 ]} El desarrollo de la versión 3 comenzó alrededor de 1995, lo que dio como resultado una publicación inicial del estándar en 2005. El estándar v3, a diferencia de la versión 2, se basa en una metodología formal (el HDF) y en principios orientados a objetos.

RIM - ISO/HL7 21731

El Modelo de Información de Referencia ^{[ 10 ]} (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. ^{[ 11 ]}

Marco de desarrollo HL7 - ISO /HL7 27931

El marco de desarrollo HL7 versión 3 (HDF) es un proceso en constante evolución que busca desarrollar especificaciones que faciliten la interoperabilidad entre sistemas de atención médica. El HL7 RIM, 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 consensuados para la interoperabilidad de los sistemas de información de atención médica . El HDF es la edición más reciente de la metodología de desarrollo HL7 V3.

El HDF no solo documenta la mensajería, sino también los procesos, herramientas, actores, reglas y artefactos relevantes para el desarrollo de todas las especificaciones del estándar HL7. Eventualmente, el HDF abarcará todas las especificaciones del estándar HL7, incluidas las nuevas que surjan 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 desarrollo del vocabulario V3 garantiza que los sistemas que implementan las especificaciones HL7 comprendan de forma inequívoca las fuentes de código y los dominios de valores de código que utilizan.

Mensajería V3

El estándar de mensajería HL7 versión 3 define una serie de mensajes de texto seguros (denominados interacciones ) para dar soporte a todos los flujos de trabajo sanitarios.

Los mensajes HL7 v3 se basan en una sintaxis de codificación XML, como se muestra en este ejemplo: ^{[ 12 ] : 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= Observation Event Complete, w/o Receiver Responsibilities --> <interactionId root= <id extension= "2.16.840.1.113883.1.6" extension= "POLB_IN224200" /> <processingCode code= "P" /> <processingModeCode nullFlavor= "OTH" /> <acceptAckCode code= "ER" /> <receiver typeCode= "RCV" > <device classCode= "DEV" determinerCode= "INSTANCE" > <id extension= "GHH LAB" root= "2.16.840.1.113883.19.1122.1" /> <asLocatedEntity classCode= "LOCE" > <location classCode= "PLC" determinerCode= "INSTANCE" > <id root= "2.16.840.1.113883.19.1122.2" extension= "ELAB-3" /> </location> </asLocatedEntity> </device> </receiver> <sender typeCode= "SND" > <device classCode= "DEV" determinerCode= "INSTANCE" > <id root= "2.16.840.1.113883.19.1122.1" extension= "GHH OE" /> <asLocatedEntity classCode= "LOCE" > <location classCode= "PLC" determinerCode= "INSTANCE" > <id root= "2.16.840.1.113883.19.1122.2" extensión= "BLDG24" /> < /ubicación> </asLocatedEntity> </dispositivo> </remitente> <!-- Activar evento de control Acto y contenido del 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. ^{[ 13 ]} El estándar fue publicado conjuntamente con ISO como ISO/HL7 27932.

El marco de trabajo 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 Documentos Clínicos.

El etiquetado estructurado de productos describe la información publicada que acompaña a un medicamento, según la versión 3 de HL7.

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 del paciente en tiempo real y a nivel de interfaz de usuario. Las implementaciones de CCOW generalmente requieren un sistema de bóveda CCOW para gestionar la seguridad del usuario entre aplicaciones.

Fast Healthcare Interoperability Resources (FHIR) 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 conjunto moderno de tecnologías API basadas 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, la 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. ^{[ 14 ]} 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. ^{[ 15 ]}

El marco de arquitectura empresarial compatible con servicios HL7 (SAIF) proporciona coherencia entre todos los artefactos HL7 y permite un enfoque estandarizado para el desarrollo e implementación de la arquitectura empresarial (EA), así como una forma de medir dicha coherencia.

SAIF es una metodología para generar especificaciones que describan explícitamente la gobernanza, la conformidad, el cumplimiento y la semántica de comportamiento necesarios para lograr una interoperabilidad semántica computable. La tecnología de transmisión de información prevista podría utilizar mensajería, intercambio de documentos o servicios.

SAIF es el marco necesario para racionalizar la interoperabilidad de otros estándares. SAIF es una arquitectura para lograr la interoperabilidad, pero no es una 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 contienen el conocimiento suficiente para tomar decisiones médicas individuales. Pueden generar alertas, diagnósticos e interpretaciones, además de ofrecer funciones de control de calidad y soporte administrativo. Un MLM debe ejecutarse en un ordenador que cumpla los requisitos mínimos del sistema y tenga instalado el programa correcto. De esta forma, el MLM puede proporcionar asesoramiento cuando y donde sea necesario.

El Clinical Quality Language (CQL) es un estándar de lenguaje de expresión de alto nivel con enfoque clínico, certificado por ANSI ^{[ 16 ] y curado por Health Level 7. [ 17 ]} Está diseñado para compartir conocimientos clínicos en los dominios de medición electrónica de la calidad clínica y apoyo a la toma de decisiones clínicas . ^{[ 18 ]}

El lenguaje de calidad clínica se utiliza para diversas aplicaciones clínicas, incluidas las directrices SMART de la OMS , donde se emplea para codificar la lógica de decisión y los indicadores de rendimiento. ^{[ 19 ]} Los Centros de Servicios de Medicare y Medicaid adoptaron el CQL para las especificaciones de medidas de calidad clínica desde 2019. ^{[ 20 ] [ 21 ]}

CQL permite una expresión modular y flexible de la lógica y es legible tanto para humanos como para máquinas. ^{[ 20 ]}

Una implementación de CQL fue publicada como código abierto por el Comité Nacional para el Aseguramiento de la Calidad en 2023 con el objetivo de fomentar la adopción del lenguaje. ^{[ 22 ]}

Especificaciones funcionales para un registro electrónico de salud .

Un segmento OBR contiene información sobre un examen, estudio diagnóstico u observación. ^{[ 23 ]} Es un segmento obligatorio en un mensaje ORM (mensaje de orden) ^{[ 24 ]} o en un mensaje ORU (Resultado de observación). ^{[ 25 ]}

• HL7 RIM: Un estándar incoherente
• HL7 RIM bajo escrutinio (intento de refutación) (¿fecha de publicación?)
• RELOJ HL7
• Actualización 2013: La acción humana en el ámbito sanitario: un análisis crítico del modelo de información de referencia de HL7.