Sociedad Española de Dirección y Gestión
de los Laboratorios Clínicos
VIII Reunión
Marbella, 16-18 de febrero de 2005
Resumen-14

Implantación de un sistema de comunicaciones basado en HL7 v3 en laboratorios.
David Reche Martínez.
Departamento de I+D+i Novasoft

Introducción y objetivos: La integración de los servicios de análisis clínicos en las aplicaciones sanitarias de forma fácil, sencilla y segura, es un factor clave para la reducción de costes en los cambios de mejora tecnológicos orientados a mejorar la eficiencia de los procesos. Únicamente un enfoque orientado a servicios permite simplificar dicha integración definiendo cómo deben interactuar los sistemas a la vez que facilita extremadamente su gestión, especialmente cuanto mayor sea el número de aplicaciones y más heterogéneo sea el entorno. Dentro de las posibles alternativas de integración de servicios de información en entornos sanitarios el método mas extendido es la utilización de mensajería HL7 (Health Level Seven).

El objetivo final de este trabajo es dotar de un interfaz orientado a servicios basado en HL7v3 a nuestra aplicación de gestión de análisis clinicos NovaHIS LAB (Nexus). Mediante esta arquitectura es posible realizar estrategias de integración de aplicaciones sanitarias de forma sencilla. Por ejemplo, uno de los escenarios de utilización donde se esta usando con éxito actualmente es en la centralización de la historia clínica electrónica, otro de los escenarios de implantación a corto plazo será en la integración con las aplicaciones de atención primaria.

Material y Métodos: HL7 es un estándar aprobado por la ANSI (American National Standards Institute) donde "Level Seven" se refiere al nivel más alto del modelo de comunicación OSI (Open Systems Interconnection) de ISO (International Standards Organization), el nivel de aplicación. Este nivel indica la definición de los datos a ser intercambiados, los momentos de intercambio y la comunicación de ciertos errores a las aplicaciones. El séptimo nivel soporta funciones tales como chequeos de seguridad, identificación de los participantes, chequeos de disponibilidad, negociación de los mecanismos de intercambio y, lo más importante, la estructura de datos a intercambiar. La última versión de este protocolo de comunicación, la versión 3, utiliza como medio de representación XML.

XML (Extended Markup Language) no es un lenguaje en si, sino un metalenguaje. Son una serie de normas para crear lenguajes. XML permite una estructuración de los documentos, pudiendo diferenciar las partes y usar etiquetas que reflejen el carácter del contenido. Estas dos características son muy importantes a la hora de tratar la información mecánicamente. También hacen que el documento sea más legible para una persona. Se utilizan unos ficheros especiales llamados DTD (document type definition) para definir la sintaxis del lenguaje y poder comprobar después la validez de un documento.

Las principales características que se buscan con este estándar son: Extensibilidad (permite crear etiquetas adaptadas a necesidades especificas), portabilidad (una entidad puede enviar su sintaxis a otras de manera simple para que puedan interpretar sus propios documentos), Estructuración (aunque la estructura es muy rígida en cuanto a su sintaxis, única forma de asegurar que el estándar no se degrade, se permite el uso de etiquetas propias para que cada cual organice la información según sus propias necesidades), Lenguaje descriptivo (las etiquetas informan del significado del texto contenido en ellas).

Para la implementación de los interfaces de mensajería se utilizaron servicios Web. Los servicios Web (WS), comprenden aquellos servicios que se ofrecen mediante un servidor Web a otros sistemas que precisen consumirlos mediante los protocolos Web. Los WS se están estandarizando de forma considerable gracias al uso del lenguaje XML como el mecanismo de estandarización adoptado para la codificación e intercambio de datos.

La especificación de los WS se realiza en el lenguaje de descripción de servicios Web (WSDL o Web Services Description Languaje) que permite disponer de una definición abstracta del servicio, independiente del lenguaje de programación que se utilice para su implementación. Numerosas herramientas en el mercado permiten generar stubs Java o .NET a partir de la definición WSDL del servicio, descargando al integrador/programador de todas las tareas relacionadas con la gestión de peticiones / respuestas XML.

Para la interoperabilidad de los sistemas de Laboratorio instalados en las unidades se han desarrollado los siguientes mensajes en el estándar HL7 Versión 3.0:

  • Mensaje de Alta de Paciente (especificación PRPA_MT201102)
  • Mensaje de Orden de Laboratorio (especificación POLB_MT002100)
  • Mensaje de Resultados de Laboratorio (especificación POLB_MT004000)

Mensaje de Alta de Paciente

Para el diseño del mensaje de Alta Paciente se tomo como base este dominio ya que define demográficos de personas y pacientes, e información de visitas acerca de los pacientes. Generalmente, la información capturada en un sistema de Administración de Pacientes se comunica a sistemas clínicos y financieros.

Mensaje de Orden de Laboratorio

Es un mensaje que contempla los datos necesarios para poder levantar una orden de estudios en el laboratorio. Identifica los estudios que se realizarán al paciente y la fecha en la que tendrá que presentarse.

Mensaje de Resultados de Laboratorio

Es un mensaje que envía la información pertinente de los resultados obtenidos en los análisis de los estudios de Laboratorio así como la fecha en la que se obtuvieron éstos. Contempla los datos del Jefe de Laboratorio que valida la información capturada tanto automáticamente por el sistema como la ingresada de forma manual.

La arquitectura se basa principalmente en la utilización de servicios o procesos desatendidos que automáticamente detectan la ocurrencia de un evento, generan los mensajes necesarios y los envían vía Internet o Intranet mediante protocolos estándares como HTTP (Hypertext Transfer Protocol) a otros sistemas de información que los han requerido.

Figura 1. Arquitectura del sistema

Resultados: Actualmente este sistema esta funcionando en todos los laboratorios gestionados por NovaHIS LAB (Nexus) en México, nutriendo la historia clínica centralizada de cada paciente del IMSS (Instituto Mexicano del Seguro Social) comunicándose con el sistema ECE (Expediente Clínico Electrónico).

La facilidad de integración de estos diseños abre un nuevo abanico de posibilidades en los sistemas de información sanitarios, por ejemplo en la introducción de nuevos dispositivos en la día a día de los profesionales clínicos, como puede ser el uso de dispositivos móviles como las PDA’s (Personal Digital Assistant) gracias a protocolos de red inalámbricos como el Wi-fi.

Conclusiones: Entendemos que el objetivo fundamental de este trabajo se ha conseguido con éxito, de manera que se ha comprobado la facilidad de integración de nuestra aplicación gracias al uso de interfaces orientados al servicio basado en protocolos de comunicación estándares. Redundando todo esto en la mejora de la interoperabilidad, los costes de integración y el servicio de los sistemas de análisis clínicos.

Una vez comprobada la efectividad del trabajo vamos a continuar ampliando y mejorando nuestros sistemas mediante la utilización de estas arquitecturas, añadiendo nuevos mensajes aprobados y reconocidos internacionalmente.