Información adicional sobre HL7
El estándar HL7 contiene 256 eventos, 116 tipos de mensajes, 139 segmentos, 55 tipos de datos, 408 diccionarios de datos e implica 79 sistemas de codificación.
En el protocolo de comunicación HL7, existen cuatro conceptos básicos:
★Eventos desencadenantes: cuando eventos en el mundo real provocan un flujo de datos entre sistemas, se denomina evento desencadenante.
★Mensaje: Es la unidad más pequeña de transmisión de datos entre sistemas y consta de un conjunto de segmentos en un orden específico. Cada mensaje utiliza un tipo de mensaje para representar su propósito.
★Segmento: Es una combinación lógica de campos de datos. Cada segmento se identifica mediante un código único de tres caracteres denominado identificador de segmento.
★Campo: Es una cadena y la unidad más pequeña de un segmento.
En el protocolo de comunicación HL7, el mensaje (Mensaje) es la unidad básica para el intercambio de datos entre sistemas. Cada mensaje tiene su propio tipo de mensaje (V2.4*** tiene 112 tipos). eventos en el tipo de mensaje que define el destino del mensaje. Un mensaje consta de varios segmentos y cada segmento tiene un nombre correspondiente para definir su contenido o función (V2.4*** tiene 138 tipos).
Un segmento se compone de múltiples campos de datos (Data Field). El primer segmento de un mensaje es siempre el segmento del encabezado del mensaje, que especifica el nombre del programa emisor y receptor, el tipo de mensaje y un número de identificación de mensaje único. Los siguientes segmentos se componen del tipo de mensaje. Por ejemplo, el segmento PID (Datos de identificación del paciente) incluye nombre, dirección, número de seguro social, etc. Un campo de datos puede estar compuesto de varios componentes. Algunos mensajes se pueden desglosar aún más por códigos de evento. El siguiente es un ejemplo de un mensaje HL7:
Información real: Paciente transferido, el paciente Wang Hai fue trasladado de la sala de emergencias del Hospital 301 a Li Si, Departamento de Emergencias del Tercer Hospital de la Universidad de Pekín a las 11:12. Soy el 1 de diciembre de 2002. El sistema de referencia del hospital 301 enviará información de referencia del paciente e información básica del paciente al Tercer Hospital de la Universidad de Pekín 2 minutos después de que se confirme la transferencia: Zhang San, número de identificación 110108197404012346, hombre, dirección: No. 38 Fuxing Road, distrito de Haidian, teléfono: 85591234 . Después de convertirlo al mensaje HL7:?
MSH|^?~\amp;|005^Sala de emergencias|0802^301 Hospital|0052^Cirugía de emergencia|0801^Tercer hospital de Beijing?
PID|||| 330108197404012346||Zhang San|19740401|Hombre||C|No. 38, Fuxing Road, distrito de Haidian
PV1||Cirugía de emergencia||||0007^李思| ||Departamento de Emergencias|lt;crgt;?
¿Dónde está MSH el encabezado del mensaje (Message Header)?
¿EVN es el tipo de evento (Event Type)?
¿PID es la información básica del paciente (Identificación del paciente)?
¿PV1 es el estado de hospitalización del paciente (Visita del paciente)?
lt finaliza un segmento, este valor no puede crgt;; ser modificado por el ejecutor. El principio de funcionamiento del motor de interfaz HL7 se muestra a la derecha:
★Módulo de envío/recepción: admite el protocolo de comunicación TCP/IP. El sistema HIS envía información de registros médicos electrónicos al centro de datos. El formato cumple con el formato de cadena estándar HL7. El centro de datos recibe y analiza la información HL7, almacena la información analizada en la base de datos del centro de datos y, una vez completado, responde al remitente con un mensaje de confirmación ACK para confirmar que la información se envió correctamente.
★Módulo adaptador HL7 (módulo de conversión): realiza la conversión mutua entre datos en formato de cadena y formato XML, verifica y verifica el formato de la información y garantiza la precisión e integridad del envío/recepción de datos de registros médicos.
★Módulo API HL7 (Módulo de interfaz de aplicación): proporciona una interfaz de aplicación que cumple con los estándares HL7. Los sistemas de aplicaciones médicas pueden llamar funciones de interfaz y completar parámetros de acuerdo con el formato estándar HL7 para enviar datos a otras aplicaciones médicas. sistemas. Este módulo también puede llamar a aplicaciones de componentes de Windows que cumplen con los estándares HL7 para transferir datos de información médica a sistemas de aplicaciones médicas y recibir datos de otros sistemas de aplicaciones médicas.
★Módulo de recursos HL7 (módulo de recursos HL7): admite diversas aplicaciones prácticas de eventos de información médica HL7, como verificación de órdenes médicas, referencias, etc.
★Módulo de mapeo: proporciona una función de comparación de traducciones y se puede personalizar de acuerdo con el sistema de aplicación médica.
El concepto de motor de interfaz HL7 se puede entender de esta manera: es un conjunto de funciones o controles de llamada de proceso que admiten la comunicación HL7. El programa de aplicación proporciona parámetros de acuerdo con la convención del motor de interfaz HL7. La comunicación entre módulos se realiza mediante el motor de interfaz HL7 completado. En los países desarrollados extranjeros, la principal tecnología de integración de información médica en 2012 fue el "motor de interfaz HL7/XML". Es una tecnología de integración de información médica que integra múltiples tecnologías y se utiliza para traducir diversos datos del sistema de información hospitalaria a información XML compatible con HL7. formato para lograr compartir e intercambiar información entre varios sistemas de información médica y de salud. Para comprender profundamente los principios del motor de interfaz HL7, todavía tenemos que estudiarlo desde el aspecto de la comunicación de datos. En términos de comunicación de datos, existen dos niveles de aplicaciones de intercambio de datos. El primer nivel de la aplicación de intercambio de datos es procesar la información existente y solo "intercambiar" los datos de información existentes en el sistema existente. El segundo nivel son las aplicaciones de comunicación e intercambio de datos basadas en la comunicación de datos integrada entre diferentes sistemas, cuyo objetivo es lograr conexiones perfectas entre diferentes sistemas. El intercambio de datos en este nivel no solo intercambia diversa información de resultados, sino también diversa información de procesos, para lograr el propósito de interacción entre sistemas. Según los dos niveles anteriores de métodos de intercambio de datos, también existen dos métodos correspondientes al intercambio de datos basado en HL7. Es una especie de método de "motor HL7", cuyo objetivo principal es permitir a los usuarios tener capacidades de comunicación HL7 en el sistema que se está ejecutando actualmente y que no se pueden reemplazar. El otro es el método "HL7 Ready". En todo el sistema, el protocolo de interfaz HL7 se ha diseñado y procesado en cada terminal de aplicación. Cada terminal debe poder recibir y procesar mensajes HL7 y realizar el procesamiento relacionado. En teoría, se puede lograr una operación interactiva en tiempo real entre sistemas, y cada uno puede obtener activamente información de datos que la otra parte puede proporcionar "cuando sea necesario". La organización y prestación de servicios médicos son el resultado de la centralización de la información. Generalmente se acepta que la eficacia de las operaciones sanitarias se ve afectada por el grado de automatización de las funciones de gestión de la información. Muchos creían que si los proveedores de atención sanitaria no podían automatizar sus sistemas de información, no podrían competir eficazmente en el mercado sanitario de los años noventa.
En los últimos 20 años, las instituciones médicas, especialmente los hospitales, han comenzado a automatizar su gestión de la información. Inicialmente, hubo una tendencia a reducir el procesamiento de papel, aumentar el flujo de dinero y mejorar la toma de decisiones administrativas. En los años siguientes, el desarrollo se centró en la racionalización de los servicios clínicos y auxiliares, tanto los sistemas clínicos (en hospitales y otros entornos de internación) como los del lado del paciente (en entornos no fijos). En los últimos años, se ha centrado la atención en desarrollar la integración de toda la información relacionada con la entrega de información sobre la atención médica de un paciente durante su vida (por ejemplo, un registro médico electrónico). Es concebible que todo o parte de los registros médicos electrónicos se comuniquen electrónicamente cuando y donde sea necesario.
Hoy en día, la mayoría de los hospitales están equipados con sistemas informáticos que pueden realizar funciones de ingreso, alta, traslado, exploración clínica, radiología, facturación y contabilidad.
Estas aplicaciones suelen ser desarrolladas por diferentes proveedores u organizaciones, y cada producto de estos proveedores u organizaciones tiene un formato de información muy específico. A medida que los hospitales amplían gradualmente las operaciones de gestión de la información, ha surgido la necesidad de compartir datos críticos dentro del sistema. Los proveedores seleccionados producen sistemas integrales que abordan la mayoría, si no completas, implementaciones de gestión de información médica. Estos sistemas pueden diseñarse en una arquitectura centralizada o distribuida; sin embargo, dichos sistemas son completos en la medida en que su propósito es aliviar la necesidad de estándares externos de intercambio de datos (como HL7).
Sin embargo, existe mucha presión sobre las organizaciones para desarrollar o adquirir aplicaciones departamentales individuales de forma modular. Una fuente de presión es la incapacidad de los proveedores generales para ofrecer bien algunas (o todas) de ellas. Las necesidades de departamentos específicos, otro aspecto de la presión, son la necesidad de desarrollar el entorno general del sistema del hospital a través de una serie de crecimiento y determinación de cada departamento en lugar de una única adquisición revolucionaria. El estrés puede surgir en un entorno que incluye un sistema integrado de sistemas departamentales complementarios o un sistema discreto completo.
La tecnología de redes ha surgido como una aplicación informática utilizable que aborda la integración funcional y el cambio tecnológico en el entorno médico. Sin embargo, estas aplicaciones dependen de estructuras de mercado en lugar de desarrollarse a través de un sistema lógico similar, por lo que a menudo son muy idiosincrásicas. Para interconectar estas aplicaciones en un entorno de red, es necesaria una extensa programación y mantenimiento de programas específicos de la ubicación. Esto supone unos costes considerables para los usuarios/compradores, lo que dificulta la innovación de los empleados del vendedor, como por ejemplo el desarrollo de nuevos productos. Si los estándares de interfaz de red en entornos médicos estuvieran disponibles y fueran aceptados por proveedores y usuarios, la necesidad de trabajo especializado en interfaz de direcciones podría reducirse considerablemente.
En general, es importante que los proveedores y usuarios ya no enfrenten el problema de soportar estructuras de procesamiento/comunicación inconsistentes. En cambio, se han desarrollado marcos con una incompatibilidad mínima y un intercambio máximo de información entre sistemas. Se ha sugerido que HL7 se establezca como el estándar más alto en estos campos para promover estándares abiertos y métodos estandarizados. Esto es lo que realmente proporciona un desarrollo práctico y económico y una garantía para la interfaz estándar de las aplicaciones informáticas en las instituciones médicas. Las especificaciones de esta norma fueron desarrolladas de acuerdo a los objetivos especificados a priori. Las futuras ampliaciones de la norma también deberían respaldar estos objetivos.
El propósito de HL7 es facilitar la comunicación en entornos médicos. El objetivo principal es proporcionar un estándar para el intercambio de datos entre aplicaciones informáticas médicas que elimine o reduzca esencialmente la programación de la interfaz de usuario y el mantenimiento de programas que de otro modo serían necesarios. Este objetivo principal se puede describir mediante una serie de objetivos:
a) El estándar debe soportar el intercambio de datos entre sistemas utilizados en una amplia variedad de entornos técnicos. Su implementación se puede aplicar a muchos lenguajes de programación y sistemas operativos diferentes. También admite la comunicación en una amplia variedad de entornos de comunicación, que van desde pilas de red de Capa 7 completas que cumplen con OSI hasta entornos incompletos que incluyen interconexiones RS 232C punto a punto básicas e interconexiones a través de medios masivos como: disquetes y cintas) para transferir datos.
b) Se debe admitir la transferencia directa de un solo proceso, así como la transferencia de archivos de múltiples procesos.
c) El máximo grado posible de estandarización debe ser coherente con la localización de las variaciones de uso y el formato de determinados elementos de datos. Esta norma debe adaptarse a las necesidades de variaciones especiales de direcciones. Esto incluye tablas específicas del sitio, definiciones de codificación y posiblemente campos de información específicos del sitio. (por ejemplo: segmento Z HL7)
d) El estándar debe soportar el creciente número de nuevos requisitos que se están validando. Esto incluye soporte para introducir programas extendidos y publicarlos en entornos operativos existentes.
e) El estándar debe basarse en la experiencia con los protocolos de productos existentes y aceptar una amplia gama de protocolos estándar de la industria. No debe apoyar determinados intereses de una empresa concreta en detrimento de otros usuarios.
Al mismo tiempo, HL7 busca preservar una característica única que los desarrolladores independientes pueden llevar al mercado
f) El objetivo a largo plazo debe ser cuando sea útil y relevante para el sistema de información interno del hospital. formato y protocolo que define aplicaciones en todos los entornos sanitarios.
g) La naturaleza de los diferentes procesos de negocio que existen en los sistemas de prestación de servicios médicos impide el desarrollo de un programa o modelo de datos común para respaldar el entorno de destino de HL7. Además, HL7 no presupone la estructura de los sistemas de información médica, ni intenta resolver diferencias estructurales entre diferentes sistemas de información médica. Al menos por estas razones, HL7 no puede convertirse en un verdadero estándar de interfaz plug-and-play. Estas diferencias en HL7 se parecen más a protocolos negociados.
h) El principal interés del grupo de trabajo HL7 se ha desplazado hacia la aplicación de estándares siempre que sea posible. Para lograr esto, HL7 también ha desarrollado una organización de base que apoya un proceso de votación unánime y ha sido reconocida por el Instituto Nacional Estadounidense de Estándares (ANSI) como una Organización de Estándares Autorizada (ASO).
i) La cooperación con otros estándares médicos relacionados (como ACR/NEMA DICOM, ASC X12, ASTM, IEEE/MEDⅨ, NCPDP, etc.) se ha convertido en una actividad prioritaria de HL7. HL7 ha participado en el proceso ANSI HISPP (Grupo de Trabajo del Programa de Sistemas de Información de Salud) desde su creación en 1992. Desde marzo de 1987, el grupo de trabajo HL7 se ha reunido aproximadamente cada tres o cuatro meses para desarrollar y discutir la especificación. Al comité se unen grupos de trabajo para designar cada interfaz funcional en desarrollo. Además, el comité auxiliar designa todas las estructuras de control y las diferentes gestiones del grupo. Estos comités son responsables de desarrollar y mantener los capítulos del estándar de interfaz HL7. Además, a menudo se forman diferentes grupos de interés dentro de HL7 para desarrollar sus ideas e iniciar algunas opiniones especiales que no están cubiertas por comités especializados. Si se aprueban las acciones de un Grupo de Interés Especial y se considera necesario un nuevo capítulo después de la discusión, pueden solicitar al Presidente del Comité Técnico de HL7 y al Comité Ejecutivo que formen un comité técnico.
En las tres primeras reuniones, se preparó un borrador del estándar versión 1.0 que cubre la estructura de todas las interfaces, ADT, entrada de pedidos y consultas orientadas a la visualización. Aunque se consideró muy importante un sistema de facturación a los pacientes, el plazo no permitió su introducción en el primer borrador. Este borrador apareció en una reunión plenaria en Tyson's Corner, VA, el 8 de octubre de 1987, a la que asistieron todos los grupos.
La versión 0 se preparó posteriormente para la reunión plenaria en Tyson's Corner y apareció en la segunda reunión plenaria de Tucson en septiembre de 1988. Desde la segunda reunión plenaria, la edición y modificación de las versiones 2.1, 2.2 y 2.3 han continuado sin interrupción. El grupo de trabajo ha aumentado a 300 personas, superando con creces las 12 personas originales. Se ha implementado el siguiente contenido:
a). Se han perfeccionado y ampliado las especificaciones detalladas de los diferentes ámbitos funcionales.
b). Desarrolló enlaces formales con varios otros estándares: ANSI HISPP (Grupo de Programa de Estándares de Información Médica), que coordinó los estándares médicos, luego reemplazado por ANSI HISB (Junta de Estándares de Información Médica Responsable de); estándares EDI externos, el grupo ASTM E31.11 es responsable de los estándares de intercambio de datos clínicos, el grupo ACR/NEMA DICOM es responsable de otros aspectos de los estándares relacionados con los sistemas de información de imágenes y radiología (Radiology Information System, RIS) y el IEEE P1157. El grupo es responsable del intercambio de datos médicos (MEDⅨ).
c). Modificar la estructura de control general en función de las observaciones para adaptarse a una amplia gama de entornos de comunicación diferentes y promover la cooperación con otros grupos de estándares.
d). Se agregó un capítulo que describe la interfaz del sistema de facturación y cobro del paciente.
e). Preparé capítulos que describen resultados auxiliares, ensayos clínicos, experiencia con productos e informes de datos de forma de onda, coordiné con las normas ASTM 1238-91 y trabajé directa y activamente con los miembros del comité ASTM E31.11.
f). Se agregó un capítulo de recopilación de procesamiento que admite la transmisión sincronizada de archivos maestros en sistemas de información relacionados.
G). Capítulos sobre interfaces de programación de aplicaciones que soportan funciones de registros médicos, incluida la gestión de transcripciones, posicionamiento y seguimiento de gráficos, análisis de carencias y publicación de contenido e información.
h). Se agregó un capítulo sobre mensajes para respaldar la comunicación sobre diversos eventos para arreglos de reserva de servicios o utilización de recursos.
i). Se agregaron capítulos relevantes que definen conjuntos de mensajes para las comunicaciones de derivación de pacientes entre entidades de atención médica independientes.
j). Creó toda la base de datos, diccionarios de datos computarizados y otros componentes de mensajería. El Apéndice A incluye referencias cruzadas y otra información generada a partir de este diccionario de datos electrónico.
k). Las inconsistencias y errores encontrados en las versiones 2.0 y 2.1 anteriores han sido marcados y registrados en la versión 2.3.
l) Se han realizado amplias adiciones a los capítulos Pedido/Inicio de sesión y Observación clínica, incluidos resultados específicos para elementos de datos, pedidos de farmacia e interfaces de gestión.
m) Los acuses de recibo de mensajes se han ampliado para incluir un modo mejorado independiente que define los acuses de recibo aceptables. Si bien este modo confirmado se ha habilitado, está claro cómo HL7 puede admitir cualquier entorno (por ejemplo, servicios de almacenamiento y reenvío, ejecución de servicios fuera del "motor de interfaz") cuando el intermediario existe en la red con retrasos de tiempo inherentes. La confirmación directa se utiliza para publicar el sistema de envío desde la demanda hasta el reenvío de mensajes
n) Existe una diferencia entre las definiciones de mensajes abstractos de HL7. Esta definición abstracta está completamente definida de acuerdo con la séptima capa (capa de aplicación). ), que es una regla de codificación HL7 que convierte un mensaje abstracto en una cadena que contiene información real. Estas reglas de codificación son de hecho una sugerencia como una alternativa potencial, que está completamente definida en la definición de la Capa 6 (capa de presentación) que no existe (como: Reglas de codificación (BER) básicas ASN.1 de ISO)