IBM® Integration Bus Healthcare Pack se basa en IBM Integration Bus y proporciona soporte para las aplicaciones de entornos de servicios sanitarios.
IBM Integration Bus Healthcare Pack proporciona las siguientes características:
El diagrama siguiente muestra la arquitectura básica de una configuración de IBM Integration Bus Healthcare Pack. Muestra cómo IBM Integration Bus Healthcare Pack puede conectarse a una gran variedad de sistemas de servicios sanitarios, incluidos dispositivos médicos, aplicaciones clínicas, pasarelas de dispositivo, sistemas de facturación, y los intercambios de información de salud.
Para obtener más información acerca de las HL7, consulte Health Level Seven International.
DFDL (Lenguaje de definición de formato de datos) es una descripción universal, compartible y no preceptiva para formatos binarios y de texto generales que se utiliza en IBM Integration Bus (versión 8 y posteriores) para definir modelos de mensaje. Para obtener más información sobre el uso de DFDL en modelos de mensaje, consulte Modelos de mensaje en la documentación del producto IBM Integration Bus.
IBM Integration Bus Healthcare Pack proporciona tres versiones del modelo de mensaje DFDL, una para HL7 versión 2.7, una para HL7 versión 2.6 y una para HL7 versión 2.5.1 y anteriores. Cadamodelo de mensaje DFDL incluye una definición de un mensaje de HL7 genérico. Este mensaje genérico de HL7 se utiliza con el analizador DFDL en el patrón para leer mensajes desde las aplicaciones clínicas de origen y escribir mensajes en las aplicaciones clínicas de destino. Este mensaje de HL7 puede procesar cualquier segmento válido definido en HL7 versiones 2.7, 2.6, 2.5.1 o anteriores.
El conjunto de mensajes de HL7v25P incluye una definición del mensaje de HL7 genérico. Este mensaje de HL7 genérico se utiliza, junto con el analizador MRM del patrón, para leer mensajes de las aplicaciones clínicas de origen y para escribir los mensajes en las aplicaciones clínicas de destino. Este mensaje de HL7 puede procesar cualquier segmento válido definido en HL7 versión 2.5.1 o anterior.
Aunque se recomienda utilizar el modelo de mensaje DFDL en lugar del conjunto de mensajes de HL7v25P, hay situaciones en las que quizás desee utilizar el conjunto de mensajes de HL7v25P. Por ejemplo, si convierte datos desde el estándar no XML HL7v2 a una representación XML utilizando el conjunto de mensajes de HL7v25P, no es necesario renombrar los elementos del árbol de mensajes.
Las aplicaciones clínicas también pueden comunicar información no estándar mediante segmentos Z en mensajes de HL7. Cuando utiliza este tipo de mensaje con los patrones, puede añadir segmentos Z no estándar al mensaje de HL7 para dar soporte a estos segmentos Z específicos del sitio.
Cuando un mensaje de HL7 se lee en una instancia de patrón, también puede utilizar su modelo de mensaje elegido para crear el formulario canónico (formato XML), que se genera después del primer punto de personalización. El formulario canónico sacado por el patrón no es XML de HL7, pero puede utilizarlo para conservar una representación de sus datos que sea independiente de la plataforma. Estos datos pueden tener la forma de fechas y horas estandarizadas, formato de números y cualquier otro requisito de estandarización de datos impuesto.
Los modelos de mensaje también pueden procesar mensajes de HL7 de un tipo y código de suceso específicos. Si desea implementar aplicaciones de flujo de mensajes que procesan un mensaje para un capítulo de HL7 específico, es necesario leer y escribir los mensajes utilizando el tipo de mensaje adecuado a partir de las definiciones de capítulo descritas en el modelo de mensaje. HL7 divide todos sus mensajes en grupos, llamados capítulos, que corresponden a los capítulos del estándar HL7. Cuando está trabajando con mensajes específicos de HL7 del modelo de mensaje, es posible sacar los mensaje en formato HL7 o en formato XML de HL7. La utilización de estos formatos también simplifica la utilización de la correlación gráfica en la transformación de un mensaje entre mensajes de origen y de destino.
Para obtener más información sobre HL7, consulte Health Level Seven International.
IBM Integration Bus Healthcare Pack incluye un nodo de entrada, el nodo MedicalDeviceInput, que permite pasar la información de dispositivos médicos a un flujo de mensajes. Con la utilización de este nodo, puede desarrollar flujos de mensajes para enviar datos de dispositivos médicos a otros sistemas, por ejemplo, un almacén de datos o una estación de supervisión de enfermeras.
Cada dispositivo se conecta a un puerto de comunicaciones distinto (serie o LAN) y los controladores de dispositivo dentro del nodo MedicalDeviceInput están configurados para escuchar en estos puertos de comunicaciones. La configuración del nodo identifica los dispositivos conectados, y las medidas que se necesitan de cada dispositivo.
El diagrama muestra el flujo de datos de los dispositivos clínicos de Cama 1, Cama 2 y Cama N a los controladores de dispositivos. Por ejemplo, desde los pulsómetros al Controlador 1 y desde las bombas de infusión, a través de un grupo de ejecución al Controlador 2. El flujo pasa entonces al nodo MedicalDeviceInput, que envía la información de estado y de datos al resto del flujo.
El flujo de datos desde los flujos de mensajes no se debe interrumpir cuando se actualizan las configuraciones de dispositivo; por ejemplo, cuando se cambian las medidas que son necesarias o cuando se cambian las conexiones físicas al añadir, desconectar o mover dispositivos. Los datos de configuración se mantienen por tanto como un servicio configurable de modo que el nodo puede implementar los cambios de configuración sin necesidad de detener o volver a desplegar el flujo de mensajes que está recibiendo los datos médicos.
El nodo MedicalDeviceInput se configura mediante la pestaña Propiedades, que inicia un editor para el servicio configurable. en editor de Servicios configurables de dispositivos médicos, un administrador selecciona primero el tipo de dispositivo de una lista de dispositivos soportados y a continuación selecciona el tipo de comunicaciones (en serie o LAN) y proporciona los detalles de comunicaciones adecuados.
Frecuentemente ocurre que varios dispositivos del mismo tipo deben proporcionar el mismo tipo de medida en intervalos idénticos, por ejemplo: las pulsaciones, la temperatura de la sangre y la frecuencia respiratoria cada 5 minutos. Este requisito puede ser cierto para varios dispositivos que están desplegados en todas las camas de una sección. El editor de Servicios configurables de dispositivos médicos soporta por lo tanto la configuración de conjuntos de medidas, que especifican varias medidas y se pueden aplicar a cualquier número de dispositivos.
Al configurar un conjunto de medidas, el administrador selecciona un tipo de dispositivo y accede a una lista de medidas soportadas por ese tipo de dispositivo. El administrador puede seleccionar las medidas necesarias y, para cada medida, el administrador especifica el intervalo al que se pasan las medidas al flujo de mensajes para su proceso.
Cuando es necesario configurar muchos dispositivos y medidas, puede haber muchos datos de configuración. Por lo tanto y, a efectos aclaratorios, el administrador puede proporcionar una descripción de la ubicación de cada dispositivo, información de ID de paciente, notas y códigos para cada dispositivo y conjunto de medidas.
Los datos que fluyen desde el nodo MedicalDeviceInput los puede procesar un flujo de mensajes utilizando cualquiera de los nodos disponibles en IBM Integration Bus. Los datos de medida se pasan al flujo de mensajes como un árbol lógico de mensaje. El árbol de mensajes utiliza el dominio DataObject y tiene XML como su formato de serialización (el mensaje se serializa a XML si el mensaje se escribe en una cola de mensajes). Estos datos se pueden filtrar, transformar, agregar y direccionar mediante las prestaciones de IBM Integration Bus estándar, antes de que se escriban en puntos finales de destino: bases de datos, colas de IBM WebSphere MQ o llamadas de servicio, por ejemplo.
Para obtener más información sobre cómo utilizar el nodo de MedicalDeviceInput, consulte Utilización de datos de dispositivos médicos en flujos de mensajes y Nodo MedicalDeviceInput.
DICOM (Digital Imaging and Communications in Medicine) es un estándar para el manejo, almacenamiento, impresión y transmisión de información de imágenes médicas. La información puede incluir imágenes de DICOM e informes estructurados (SR) de DICOM.
Puede utilizar IBM Integration Bus Healthcare Pack para conectar Sistemas de comunicaciones de archivado de imágenes (PACS) de DICOM y otras modalidades de DICOM a los flujos de mensajes para poder localizar, procesar y direccionar las imágenes de DICOM dentro de un sistema de servicios sanitarios.
La función DICOM que proporciona IBM Integration Bus Healthcare Pack da soporte a varios escenarios clave.El patrón DFDL Servicio sanitario: HL7 a HL7 media entre aplicaciones clínicas que utilizan el estándar HL7 v2 para mensajes. Por ejemplo, un Sistema de administración de pacientes (PAS) puede emitir un único mensaje que se distribuya a una o varias aplicaciones clínicas que requieran la información del paciente.
El patrón no se limita a tratar con mensajes de un único tipo (por ejemplo ADT) y código (por ejemplo A01) de HL7, pero puede recibir y procesar cualquier mensaje con un tipo y código de mensaje válido. Las aplicaciones deben poder enviar y recibir los mensajes mediante MLLP a través de TCP/IP.
El patrón contiene tres flujos de mensajes diferente (si elige varios destinos, obtiene flujos de mensajes adicionales) e incluye subflujos que puede personalizar.
Para obtener más información sobre los patrones, consulte Desarrollo de aplicaciones de flujo de mensajes de servicios sanitarios mediante los patrones proporcionados en IBM Integration Bus Healthcare Pack.
IBM Integration Bus Healthcare Pack incluye un vista Supervisión operativa de Healthcare en IBM Integration Explorer para supervisar el flujo de mensajes entre sus aplicaciones clínicas y el estado de sus dispositivos médicos. Puede utilizar esta información para ayudarle a encontrar y arreglar los problemas de conectividad que surgen.
Los flujos de mensaje generados como una instancia de patrón se definen con propiedades que habilitan la supervisión operativa de IBM Integration Explorer para identificar las conexiones de TCP/IP de cada flujo de mensajes y las aplicaciones asociadas a cada una de estas conexiones de TCP/IP. Por lo tanto, los paneles de supervisión pueden mostrar un icono de aviso que identifica cuando una aplicación está desconectada para que el administrador pueda poner remedio.
El panel de supervisión de TCP/IP también puede visualizar el estado de las conexiones de TCP/IP que forma parte de los flujos de mensaje que no ha generado uno de los patrones de IBM Integration Bus Healthcare Pack. Por ejemplo, los flujos desarrollados mediante modelo de mensaje DFDL o conjunto de mensajes de HL7v25P. Estos flujos no tienen la información adicional configurada por la instancia de patrón a menos que los flujos se definan con las mismas propiedades que las utilizadas por el patrón.
vista Supervisión operativa de Healthcare para la supervisión operativa también muestra el estado de las colas utilizadas por los flujos de mensajes como una instancia de patrón. Todas las colas para una instancia de patrón dada se denominan con un prefijo de cola específico de la instancia de patrón. El uso de un prefijo de cola habilita a un administrador para que vea todas las colas para una instancia de patrón, supervise la profundidad de cola e identifique cuando se alcanza un umbral indicado por un icono de aviso visualizado para la cola. La capacidad de ver todas las colas permite determinar más problemas, en particular la construcción de mensajes en colas de secuencias, lo que indica que la falta de un mensaje en una cola de secuencia está haciendo que se retenga la entrega de los mensajes siguientes hasta la llegada del mensaje faltante. Esta acción asegura que puede poner remedio para hacer que los mensajes fluyan del origen al destino.
Puede supervisar las colas de la misma forma que las conexiones de TCP/IP, en las aplicaciones de flujo de mensajes de Servicio sanitario desarrolladas utilizando modelo de mensaje DFDL o conjunto de mensajes de HL7v25P. Si es necesario supervisar, las colas que desea supervisar deben tener el mismo prefijo en el nombre para permitir la agrupación de información para la aplicación clínica en las pantallas de supervisión.
Puede supervisar el estado de dispositivos médicos conectados a un nodo MedicalDeviceInput.
Para obtener más información sobre la supervisión operativa, consulte Supervisión operativa.
El perfil de integración de ATNA (Audit Trail and Node Authentication) abarca varios aspectos de la seguridad, incluidos los estándares y procesos para direccionar y almacenar de forma segura los mensajes de sucesos de auditoría en un repositorio. Utilizando un nodo ATNAAudit, puede generar mensajes de sucesos de auditoría de ATNA a partir de los datos de servicios sanitarios que se direccionan a través de los flujos de mensajes y enviar estos mensajes de sucesos de auditoría a un repositorio de auditoría de ATNA especificado.
Para obtener información sobre cómo auditar datos en flujos de mensajes, consulte Auditoría de datos de flujos de mensajes.
IBM Integration Bus Healthcare Pack proporciona cuatro perfiles de análisis de datos. Cada perfil se utiliza para un tipo específico de datos de servicios sanitarios.
Para obtener más información sobre cómo analizar datos de servicios sanitarios, consulte Análisis de datos de servicios sanitarios en flujos de mensajes.