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:
- Modelos de mensaje que puede utilizar para analizar, direccionar y transformar mensajes de HL7 en
un flujo de mensajes, consulte Modelos de mensaje
- Nodos de entrada y salida para integrar aplicaciones clínicas de HL7 con los flujos de mensajes; consulte Nodos de HL7
- Integración con dispositivos médicos para que pueda capturar datos; consulte Integración de dispositivos médicos
- Integración con los Sistemas de comunicaciones de archivado de imágenes (PACS) de DICOM y las modalidades de DICOM, para que pueda localizar, procesar y transferir imágenes de DICOM utilizando flujos de mensajes; consulte Integración de imágenes de DICOM
- Patrones específicos de médicos que puede utilizar para generar soluciones para conectar aplicaciones médicas, consulte Patrones de servicio sanitario
- Generación de sucesos de auditoría de ATNA para dar soporte a la confidencialidad de la información de pacientes, la integridad de datos y la responsabilidad de usuario, consulte Sucesos de auditoría de ATNA
- La posibilidad de extraer información a partir de datos de servicios sanitarios en flujos de mensajes y de enviar la información a almacenes de datos para su análisis; consulte Análisis de datos de servicios sanitarios
- Conversión de archivos de HIPAA a archivos XML utilizando el patrón de
Servicio sanitario: HIPAA a
XML, consulte Patrones de servicio sanitario
- Patrones que permiten crear soluciones de integración que cumplen los perfiles de integración PIX, PDQ y XDS de IHE (Integrating the Healthcare Enterprise); consulte Patrones de servicio sanitario.
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.
Modelos de mensaje
IBM Integration Bus Healthcare Pack versión
4.0 incluye
dos modelos de mensaje para procesar mensajes de
HL7:
- modelo de mensaje DFDL
- conjunto de mensajes de HL7v25P
- modelo de mensaje DFDL
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 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.
Nota: El
conjunto de mensajes de HL7v25P que está
disponible en
IBM WebSphere Message Broker Connectivity Pack for Healthcare
versión 7.0 todavía está soportado. Sin embargo, se
recomienda utilizar el
modelo de mensaje DFDL para aplicaciones nuevas y actualizadas si es
posible, ya que este modelo tiene los beneficios siguientes.
- DFDL es un formato de estándar abierto mientras que
MRM y conjunto de mensajes de HL7v25P son propiedad
de IBM Integration Bus.
- El editor DFDL proporciona herramientas más sencillas para desarrollar y probar extensiones en el esquema de HL7 en comparación con MRM y el conjunto de mensajes de HL7v25P.
- El modelo de mensaje DFDL da soporte a HL7 versiones 2.7, 2.6, 2.5.1 y anteriores, mientras que MRM y el conjunto de mensajes de HL7v25P sólo dan soporte a HL7 versión 2.5.1 y anteriores.
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.
Nota: Puede
descargar el
modelo de mensaje DFDL de los recursos del patrón para el
patrón
Servicio
sanitario: HL7 a DFDL HL7. Para obtener más información, consulte
Integración con aplicaciones de HL7.
Nota: Los patrones HL7 que también están
disponibles en IBM WebSphere Message Broker Connectivity Pack for Healthcare versión 7.0 (patrón Servicio
sanitario: HL7 a HL7, patrón y patrón Servicio sanitario: Dispositivos médicos a EMR) utilice el conjunto de mensajes de HL7v25P. Sin embargo, el
uso del modelo de mensaje DFDL se
introdujo en IBM WebSphere Message Broker Connectivity Pack for Healthcare versión
8.0, en el patrón
Servicio
sanitario: HL7 a DFDL HL7.
El modelo de mensaje DFDL se
utiliza en los patrones añadidos en
IBM Integration Bus Healthcare
Pack Versión 3.0
(patrones Servicio sanitario: Transformación de HL7 y
Servicio sanitario: Salud en el hogar).
- conjunto de mensajes de HL7v25P
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.
Nota: Puede
descargar el
conjunto de mensajes de HL7v25P de los recursos del patrón para el
patrón
Servicio
sanitario: HL7 a HL7.
Para obtener más información, consulte
Integración con aplicaciones de HL7.
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.
Nodos de HL7
Si está utilizando el
modelo de mensaje DFDL, se proporcionan los siguientes nodos
HL7 para que los utilice en los flujos de mensajes para enviar y recibir mensajes de
HL7:
- HL7DFDLInput,
que puede utilizar en un flujo de mensajes para recibir mensajes de HL7
para procesar en su flujo de mensajes y para determinar si un mensaje es un duplicado.
- HL7DFDLOutput,
que puede utilizar para pasar mensajes de HL7 a un destino a través de MLLP y para comprobar que se recibe un acuse de recibo válido.
Para obtener más información acerca de estos nodos
HL7, consulte
Nodo HL7DFDLInput y
Nodo HL7DFDLOutput.
Si está utilizando el conjunto de mensajes de HL7v25P, se proporcionan los siguientes nodos HL7 para que los utilice en los flujos de mensajes para enviar y recibir mensajes de
HL7:
- GenericHL7Input,
que puede utilizar en un flujo de mensajes para recibir mensajes de HL7
para procesar en su flujo de mensajes y para determinar si un mensaje es un duplicado.
- GenericHL7Output,
que puede utilizar para pasar mensajes de HL7 a un destino a través de MLLP y para comprobar que se recibe un acuse de recibo válido.
Para obtener más información acerca de estos nodos
HL7, consulte
Nodo GenericHL7Input y
Nodo GenericHL7Output.
Integración de dispositivos médicos
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 servidor de integració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.
- Configuración del nodo MedicalDeviceInput
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.
- Conjuntos de medidas
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.
- Utilización del nodo MedicalDeviceInput en flujos de mensajes
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.
Integración de imágenes de DICOM
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.
- Recopilar estudios para la admisión de pacientes
- Cuando se admite un paciente en el hospital, puede consultar los PACS de DICOM que están en una o más ubicaciones para encontrar y recuperar estudios del paciente. Las imágenes médicas relevantes están inmediatamente a disposición del personal médico que está tratando al paciente. Para obtener más información acerca de este escenario, consulte Recopilar estudios para la admisión de pacientes.
- Segunda opinión o remisión a especialista
- En lugares con conocimientos limitados de radiología, puede direccionar las imágenes de DICOM (para fines de diagnóstico o investigación) a especialistas de otros hospitales de un sistema de servicios sanitarios. Para obtener más información acerca de este escenario, consulte Segunda opinión o remisión a especialista.
- Portal clínico
- Puede utilizar una aplicación web para visualizar detalles de los estudios de DICOM de un paciente. En este escenario, sólo se presentan los atributos del estudio (no los datos de imágenes), como por ejemplo la modalidad y la fecha y hora del estudio. Para obtener más información acerca de este escenario, consulte Portal clínico. Este escenario también se implementa en el patrón Servicio sanitario: Servicio web a DICOM de IBM Integration Bus Healthcare Pack.
IBM Integration Bus Healthcare Pack incluye tres nodos.
- El nodo DICOMInput, que puede utilizar para recibir imágenes de DICOM desde un nodo SCU (Usuario de clase de servicio) de DICOM, por ejemplo una modalidad de DICOM. Utilizando este nodo, puede extraer datos de una imagen de DICOM para
utilizarlos en un flujo de mensajes. Este nodo da soporte a las solicitudes C-STORE de DICOM.
- El nodo DICOMOutput, que puede utilizar para enviar imágenes de DICOM a un nodo SCP (Proveedor de clase de servicio) de DICOM, por ejemplo un Sistema de comunicación de archivado de imágenes (PACS) de DICOM. Al utilizar este nodo, puede combinar metadatos de un flujo de
mensajes con una imagen de DICOM y enviar el resultado a un destino
externo. Este nodo da soporte a las solicitudes C-STORE de DICOM.
- El nodo DICOMFindMove, que puede utilizar para consultar un origen
externo de imágenes de DICOM que coinciden con los criterios dados y
también para mover las imágenes de DICOM a otra ubicación. Este nodo da soporte a las solicitudes C-FIND
y C-MOVE de DICOM.
Nota: La función DICOM que proporciona IBM Integration Bus Healthcare Pack no da soporte a las solicitudes C-GET de DICOM.
Para
obtener más información sobre la utilización de nodos de
DICOM en flujos
de mensajes, consulte
Utilización de datos de imágenes de DICOM en flujos de mensajes.
Patrones de servicio sanitario
IBM Integration Bus Healthcare Pack incluye los patrones siguientes:
- Patrón Servicio sanitario: HIPAA a
XML
- El patrón de Servicio sanitario: HIPAA a
XML crea un flujo de mensajes que puede utilizar para convertir archivos de HIPAA a archivos XML.
- Patrón Servicio sanitario: Salud en el hogar
- El patrón Servicio sanitario: Salud en el hogar facilita que los datos registrados
en los dispositivos de Salud en el hogar, como escalas, se transfieran a la aplicación clínica
solicitante. Los dispositivos de Salud en el hogar envían datos sobre lecturas de pacientes a
un dispositivo de alojamiento de aplicaciones (AHD). El AHD envía los datos a través de una WAN a la
aplicación solicitante.
- Patrón Servicio
sanitario: HL7 a HL7
- El patrón Servicio sanitario: Transformación de HL7 genera correlaciones de datos gráficos
que se pueden utilizar para ensamblar mensajes de HL7.
- Patrón Servicio
sanitario: HL7 a DFDL HL7
Nota: Existe otra versión de este patrón disponible
(el patrón
Servicio
sanitario: HL7 a HL7). Sin
embargo, se recomienda utilizar el patrón
Servicio
sanitario: HL7 a DFDL HL7 para las
aplicaciones nuevas y actualizadas si es posible, ya que este patrón
utiliza el
modelo de mensaje DFDL en
lugar de
MRM y el
conjunto de mensajes de HL7v25P. El
modelo de mensaje DFDL tiene los beneficios siguientes.
- DFDL es un formato de estándar abierto mientras que
MRM y conjunto de mensajes de HL7v25P son propiedad
de IBM Integration Bus.
- El editor DFDL proporciona herramientas más sencillas para desarrollar y probar extensiones en el esquema de HL7 en comparación con MRM y el conjunto de mensajes de HL7v25P.
- El modelo de mensaje DFDL da soporte a HL7 versiones 2.7, 2.6, 2.5.1 y anteriores, mientras que MRM y el conjunto de mensajes de HL7v25P sólo dan soporte a HL7 versión 2.5.1 y anteriores.
El patrón Servicio
sanitario: HL7 a DFDL 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.
- Patrón Servicio sanitario: Dispositivos médicos a EMR
- El patrón Servicio sanitario: Dispositivos médicos a EMR integra dispositivos médicos con una aplicación
de Historia clínica electrónica (HCE) que pueda recibir mensajes de resultado de observación de
HL7 v2 (ORU R01). La aplicación debe ser capaz de recibir mensajes de
HL7 ORU R01 utilizando MLLP a través de TCP/IP. El patrón incluye
subflujos que puede personalizar.
- Patrón Servicio sanitario: Servicio web a DICOM
- El patrón Servicio sanitario: Servicio web a DICOM integra una aplicación escrita utilizando servicios web con aplicaciones de DICOM que soportan las operaciones C-FIND y C-MOVE. Puede utilizar el patrón para consultar pacientes, estudios, series e imágenes de un PACS de DICOM utilizando un servicio web implementado por IBM Integration Bus.
- Patrón Servicio
sanitario: Gestor de referencia cruzada de identificador de paciente
- El patrón Servicio
sanitario: Gestor de referencia cruzada de identificador de paciente
permite utilizar IBM InfoSphere Master Data Management para ayudarle a crear un
Gestor de referencia cruzada de identificador de pacientes para su uso en el perfil IHE (Integrating the Healthcare Enterprise) PIX
(Patient Identifier Cross Referencing). A continuación puede
conectar sus aplicaciones clínicas al patrón, para actuar como
actores de Origen de identidad de paciente y de Consumidor de
referencia cruzada de identificador de paciente, según se define en
el perfil PIX.
- Patrón Servicio
sanitario: Distribuidor de consulta de datos demográficos
- El patrón Servicio
sanitario: Distribuidor de consulta de datos demográficos
permite utilizar IBM InfoSphere Master Data Management para ayudarle a crear un
Distribuidor de datos demográficos de pacientes para su uso en el perfil IHE (Integrating the Healthcare Enterprise) PDQ (Patient Demographics Query). A continuación puede
conectar sus aplicaciones clínicas al patrón, para actuar como
actores de Distribuidor de datos demográficos de pacientes, según se define en
el perfil PDQ.
- Patrón Servicio
sanitario: Consumidor de compartición de documentos entre empresas
- Utilice el patrón Servicio
sanitario: Consumidor de compartición de documentos entre empresas para buscar los Identificadores universales exclusivos (UUID) de documentos almacenados en un registro XDS y, a continuación, utilice el UUID para recuperar esos documentos del repositorio de XDS. Para obtener más información, consulte el patrón Servicio
sanitario: Consumidor de compartición de documentos entre empresas.
- Patrón Servicio sanitario: Transformación de FHIR
- Utilice el patrón Servicio sanitario: Transformación de FHIR para transformar recursos
HL7 FHIR entre formatos XML y JSON. Para obtener más información, consulte el patrón Servicio sanitario: Transformación de FHIR.
Para obtener más información sobre los patrones, consulte Desarrollo de soluciones de integración de servicios sanitarios mediante los patrones proporcionados en IBM Integration Bus Healthcare Pack.
Sucesos de auditoría de ATNA
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.
Análisis de datos de servicios sanitarios
Puede utilizar la perspectiva de Análisis de datos de
IBM Integration Bus con un perfil de análisis de datos que proporciona
IBM Integration Bus Healthcare Pack para analizar y filtrar datos de servicios sanitarios en los flujos de mensajes. A menudo, los datos de servicios sanitarios se transportan en documentos y mensajes complejos que no son procesados fácilmente por las aplicaciones en sentido descendente. Utilizando un proyecto de análisis de datos, puede analizar los datos de servicios sanitarios, extraer los elementos más importantes y crear una estructura simplificada de mensajes que pueda correlacionarse directamente en las tablas de base de datos que utilizan las herramientas de inteligencia empresarial.
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.
- El perfil HL7 v2 (ORU) se utiliza para analizar los datos de mensajes ORU (resultado de observación)
- El perfil HL7 CDA se utiliza para analizar documentos CDA (Arquitectura de documentos clínicos)
- El perfil HL7 v2 se utiliza para analizar otros datos de HL7
- El perfil DICOM se utiliza para analizar datos de DICOM
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.