Introducción a IBM Integration Bus Healthcare Pack

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.

Este diagrama muestra cómo IBM WebSphere Message Broker Connectivity Pack for Healthcare puede conectarse a una amplia variedad de sistemas de servicios sanitarios, incluyendo dispositivos médicos, aplicaciones clínicas, pasarelas de dispositivo, sistemas de facturación, archivos de imágenes, repositorios de auditoría e 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 3 incluye dos modelos de mensaje para procesar los mensajes de HL7:
  • modelo de mensaje DFDL, que se introdujo con IBM Integration Bus versión 8 y ahora tiene soporte en IBM Integration Bus Healthcare Pack versión 8
  • conjunto de mensajes de HL7v25P, que también está disponible en IBM Integration Bus Healthcare Pack versión 7
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 (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.

Nota: El conjunto de mensajes de HL7v25P que está disponible en IBM Integration Bus Healthcare Pack versión 7 todavía tiene soporte. Sin embargo, es recomendable que el modelo de mensaje DFDL se utiliza 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 DFDL Servicio sanitario: HL7 a 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 Integration Bus Healthcare Pack versión 7 (patrón Healthcare: HL7 a HL7, patrón Servicio sanitario: HL7 a Informes y patrón Servicio sanitario: Dispositivos médicos a EMR) todavía utilizan el conjunto de mensajes de HL7v25P. Sin embargo, un nuevo patrón que utiliza el modelo de mensaje DFDL (DFDL Servicio sanitario: HL7 a HL7) está disponible en IBM Integration Bus Healthcare Pack versión 8.
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 Healthcare: 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.

Este diagrama muestra el flujo de datos de los dispositivos médicos a los controladores de dispositivos. El flujo de datos va al nodo MedicalDeviceInput, que envía la información de estado y datos al resto del flujo.

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.

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 Healthcare: 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: Transformación de HL7
Patrón DFDL Servicio sanitario: HL7 a HL7
Nota: En IBM Integration Bus Healthcare Pack versión 8, hay otra versión de este patrón disponible (Healthcare: HL7 a HL7). Sin embargo, se aconseja utilizar DFDL Servicio sanitario: HL7 a 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 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.

Este diagrama muestra los flujos de mensaje del patrón DFDL Servicio sanitario: HL7 a HL7. La aplicación de origen envía el mensaje mediante MLLP a través de TCP/IP al flujo Flujo receptor. El flujo receptor utiliza WebSphere MQ para enviar el mensaje al flujo de transformación y direccionamiento. El flujo de transformación y direccionamiento utiliza WebSphere MQ para enviar el mensaje a uno o varios flujos de remitente. Los flujos de remitente utilizan entonces MLLP a través de TCP/IP para enviar el mensaje a la aplicación de destino.

 

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.
Este diagrama muestra los flujos de mensaje del patrón Servicio sanitario: Dispositivos médicos a EMR. El dispositivo médico envía el mensaje al flujo Dispositivos médicos. El flujo de dispositivos médicos utiliza WebSphere MQ para enviar el mensaje al flujo de transformación y direccionamiento. El flujo de transformación y direccionamiento lee la información del paciente de una base de datos actualizada por un flujo de servicios web con información de un panel de médicos. El flujo de transformación y direccionamiento utiliza WebSphere MQ para enviar el mensaje a un flujo de remitente. El flujo de remitente utiliza entonces MLLP a través de TCP/IP para enviar el mensaje a la aplicación de destino.

 

Patrón Servicio sanitario: HL7 a Informes
El patrón Servicio sanitario: HL7 a Informes integra una aplicación que puede enviar mensajes de HL7 v2 con generación de informe. La aplicación de origen debe ser capaz de enviar y recibir mensajes de HL7 mediante MLLP a través de TCP/IP. El patrón incluye subflujos que puede personalizar.
Este diagrama muestra los flujos de mensaje del patrón Servicio sanitario: HL7 a Informes. La aplicación de origen envía el mensaje mediante MLLP a través de TCP/IP al flujo Flujo receptor. El flujo de receptor utiliza WebSphere MQ para enviar el mensaje al flujo de procesador, que genera un informe.

 

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.
Este diagrama muestra los flujos de mensaje del patrón Servicio sanitario: Servicio web a DICOM. La aplicación solicitante envía los criterios de búsqueda como un cuerpo XML en el mensaje de solicitud de SOAP. El flujo de mensajes principal generado por esta instancia de patrón extrae el cuerpo y lo pasa al nodo DICOMFindMove. Los resultados de XML propagados por el nodo DICOMFindMove se devuelven a la aplicación solicitante en una respuesta SOAP.

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.

Supervisión operativa

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.

Este diagrama muestra las conexiones supervisadas de la aplicación de origen al patrón Servicio sanitario: HL7 a HL7 y del patrón a las aplicaciones de destino.

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.

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.

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.

Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Comentarios

Copyright IBM Corporation 2011, 2014Copyright IBM Corporation 2011, 2014.

        
        Última actualización
        
        Última actualización : 2014-03-20 23:25:58


Tema de conceptoTema de concepto | Versión 3.0.0.0 | ha00010