Introdução ao IBM Integration Bus Healthcare Pack

O IBM® Integration Bus Healthcare Pack se baseia no IBM Integration Bus para fornecer suporte para aplicativos em ambientes de assistência médica.

O IBM Integration Bus Healthcare Pack fornece os recursos a seguir:

O diagrama a seguir mostra a arquitetura básica de uma configuração do IBM Integration Bus Healthcare Pack. Ele mostra como o IBM Integration Bus Healthcare Pack pode se conectar a uma ampla variedade de sistemas de assistência médica, incluindo dispositivos médicos, aplicativos clínicos, gateways de dispositivo, sistemas de faturamento e trocas de informações médicas.

Esse diagrama mostra como o IBM Integration Bus Healthcare Pack pode se conectar a uma ampla variedade de sistemas de saúde, incluindo dispositivos médicos, aplicativos clínicos, gateways de dispositivos, sistemas de faturamento, arquivos de imagem, repositórios de auditoria e trocas de informações de saúde.

Para obter informações adicionais sobre HL7, consulte Health Level Seven International.

Modelos de Mensagem

O IBM Integration Bus Healthcare Pack Versão 4.0 inclui dois modelos de mensagem para processamento de mensagens do HL7:
  • modelo de mensagem DFDL
  • Conjunto de mensagens HL7v25P
modelo de mensagem DFDL

DFDL (Data Format Definition Language) é uma descrição universal, compartilhável e não prescritiva para formatos de texto geral e binário que é usada no IBM Integration Bus para definir os modelos de mensagem. Para obter mais informações sobre o uso de DFDL em modelos de mensagem, consulte Modelos de Mensagem na documentação do produto IBM Integration Bus.

Nota: O Conjunto de mensagens HL7v25P que está disponível no IBM WebSphere Message Broker Connectivity Pack for Healthcare versão 7.0 ainda é suportado. No entanto, recomenda-se que o modelo de mensagem DFDL seja usado para aplicativos novos e atualizados, se possível, pois esse modelo apresenta os benefícios a seguir.
  • DFDL é um formato de padrão aberto considerando que o MRM e o Conjunto de mensagens HL7v25P são proprietários ao IBM Integration Bus.
  • O editor do DFDL fornece ferramentas mais simples para desenvolver e testar extensões para o esquema do HL7 comparado ao MRM e ao Conjunto de mensagens HL7v25P.
  • O modelo de mensagem DFDL suporta o HL7 versões 2.7, 2.6, 2.5.1 e anteriores, enquanto o MRM e o Conjunto de mensagens HL7v25P suportam somente o HL7, versão 2.5.1 e anteriores.

O IBM Integration Bus Healthcare Pack fornece três versões do modelo de mensagem DFDL, uma para o HL7, versão 2.7, uma para o HL7, versão 2.6 e uma para o for HL7, versão 2.5.1 e anterior. Cada modelo de mensagem DFDL inclui uma definição de uma mensagem HL7 genérica. Essa mensagem do HL7 genérica é usada com o analisador DFDL no padrão para ler mensagens dos aplicativos clínicos de origem e gravar as mensagens nos aplicativos clínicos de destino. Essa mensagem HL7 pode processar qualquer segmento válido definido no HL7 versões 2.7, 2.6, 2.5.1 ou anterior.

Nota: O modelo de mensagem DFDL pode ser transferido por download a partir dos recursos padrão para o padrão do Assistência Médica: HL7 para HL7 DFDL. Para informações adicionais, consulte Integrando com Aplicativos HL7.
Nota: Os padrões do HL7 que também estão disponíveis no IBM WebSphere Message Broker Connectivity Pack for Healthcare Versão 7.0 (padrão Assistência Médica: HL7 para HL7, padrão e padrão Assistência Médica: Dispositivos Médicos para EMR) usam o Conjunto de mensagens HL7v25P. No entanto, o uso do modelo de mensagem DFDL foi introduzido no IBM WebSphere Message Broker Connectivity Pack for Healthcare, versão 8.0, no padrão Assistência Médica: HL7 para HL7 DFDL. O modelo de mensagem DFDL é usado nos padrões que foram incluídos no IBM Integration Bus Healthcare Pack Version 3.0 (padrões Assistência Médica: Transformação HL7 e Assistência Médica: Home Health.)
Conjunto de mensagens HL7v25P

O Conjunto de mensagens HL7v25P inclui uma definição da mensagem HL7 genérica. Essa mensagem HL7 genérica é usada, com o analisador MRM no padrão, para ler mensagens dos aplicativos clínicos de origem e gravar as mensagens nos aplicativos clínicos de destino. Esta mensagem do HL7 pode processar qualquer segmento válido que é definido no HL7 versão 2.5.1 ou anterior.

Embora seja recomendado usar o modelo de mensagem DFDL em vez do Conjunto de mensagens HL7v25P, há situações em que talvez seja preferível usar o Conjunto de mensagens HL7v25P. Por exemplo, se você converter dados do padrão HL7v2 não XML para uma representação XML usando o Conjunto de mensagens HL7v25P, não será necessário renomear os elementos da árvore de mensagens.

Nota: O Conjunto de mensagens HL7v25P pode ser transferido por download a partir dos recursos padrão para o padrão do Assistência Médica: HL7 para HL7. Para informações adicionais, consulte Integrando com Aplicativos HL7.

Os aplicativos clínicos também podem comunicar informações não padrão usando segmentos Z em mensagens do HL7. Ao usar este tipo de mensagem com os padrões, é possível incluir o segmentos Z não padrão adicional na mensagem do HL7 para suportar esses segmentos Z específicos ao site.

Quando um mensagem HL7 é lida em uma instância padrão, é possível também usar o modelo de mensagem escolhido para publicar o formulário canônico (formato XML), que é gerado após o primeiro ponto de customização. O formato canônico que é publicado pelo padrão não é HL7 XML, mas é possível usá-lo para reter uma representação de seus dados que é independente de plataforma. Esses dados podem estar na forma de datas e horas padronizadas, formatação de números ou qualquer outro requisito de padronização de dados que seja imposto.

Os modelos de mensagem também podem processar mensagens HL7 de um determinado tipo e código de evento. Se você desejar implementar aplicativos de fluxo de mensagens que processam uma mensagem de um capítulo específico do HL7, as mensagens deverão ser lidas e gravadas, usando o tipo de mensagem apropriado das definições de capítulo no modelo de mensagem. O HL7 divide todas as suas mensagens em grupos que são chamados de capítulos, que correspondem aos capítulos do padrão do HL7. Ao trabalhar com mensagens HL7 específicas do modelo de mensagem, é possível publicar as mensagens em formato HL7 ou em formato XML HL7. O uso desses formatos também simplifica o uso de mapeamento gráfico na transformação de uma mensagem entre mensagens de origem e destino.

Para obter informações adicionais sobre HL7, consulte Health Level Seven International.

Nós HL7

Se você estiver usando o modelo de mensagem DFDL, os nós HL7 a seguir serão fornecidos para uso nos fluxos de mensagens para enviar e receber mensagens HL7:
  • HL7DFDLInput, que pode ser usado em um fluxo de mensagens para receber mensagens HL7 para processamento em seu fluxo de mensagens e determinar se uma mensagem é uma duplicata.
  • HL7DFDLOutput, que pode ser usado para transmitir mensagens HL7 para um destino sobre MLLP e verificar se uma confirmação válida é recebida.
Para obter mais informações sobre esses nós HL7, consulte Nó HL7DFDLInput e Nó HL7DFDLOutput.
Se você estiver usando o Conjunto de mensagens HL7v25P, os nósHL7 a seguir serão fornecidos para uso nos fluxos de mensagens para enviar e receber mensagens HL7:
  • GenericHL7Input, que pode ser usado em um fluxo de mensagens para receber mensagens HL7 para processamento em seu fluxo de mensagens e determinar se uma mensagem é uma duplicata.
  • GenericHL7Output, que pode ser usado para transmitir mensagens HL7 para um destino sobre MLLP e verificar se uma confirmação válida é recebida.
Para obter mais informações sobre esses nós HL7, consulte Nó GenericHL7Input e Nó GenericHL7Output.

Integração de Dispositivo Médico

O IBM Integration Bus Healthcare Pack inclui um nó de entrada, o nó do MedicalDeviceInput, que permite que as informações dos dispositivos médicos conectados sejam passadas para um fluxo de mensagens. Usando este nó, é possível desenvolver fluxos de mensagens para enviar dados de dispositivo médico para outros sistemas, por exemplo, um data warehouse ou para uma estação de monitoramento de enfermeiras.

Cada dispositivo é conectado a uma porta de comunicação separada (serial ou LAN) e os drivers de dispositivo no nó MedicalDeviceInput são configurados para atender nessas portas de comunicação. A configuração do nó identifica os dispositivos conectados e as medidas necessárias a cada dispositivo.

Este diagrama mostra o fluxo de dados dos dispositivos clínicos para os drivers de dispositivo. O fluxo vai para o nó MedicalDeviceInput, que envia as informações de status e dados para o resto do fluxo.

O diagrama mostra o fluxo de dados dos dispositivos clínicos em cada Cama 1, Cama 2 e Cama N para os drivers de dispositivo. Por exemplo, a partir dos monitores de frequência cardíaca para o Driver 1 e a partir das bombas de infusão, por meio de um servidor de integração para o Driver 2. O fluxo, então, vai para o nó do MedicalDeviceInput, que envia as informações de status e de dados para o restante do fluxo.

Configurando o Nó MedicalDeviceInput

O fluxo de dados dos fluxos de mensagens não deve ser interrompido quando as configurações do dispositivo são atualizadas; por exemplo, ao alterar as medidas necessárias ou alterar as conexões físicas conforme os dispositivos são incluídos, desconectados ou movidos. Os dados de configuração são, portanto, mantidos como um serviço configurável para que as mudanças na configuração possam ser implementadas pelo nó sem a necessidade de parar ou reimplementar o fluxo de mensagens que está recebendo os dados médicos.

O nó do MedicalDeviceInput é configurado usando a guia Propriedades, que inicia um editor para o serviço configurável. No editor de Serviço Configurável de Dispositivo Médico, um administrador primeiro seleciona o tipo de dispositivo em uma lista de dispositivos suportados, em seguida, seleciona o tipo de comunicação (serial ou LAN) e fornece os detalhes de comunicações apropriados.

Conjuntos de medidas

Normalmente um número de dispositivos do mesmo tipo são necessários para fornecer os mesmos tipos de medida nos mesmos intervalos, por exemplo, o batimento cardíaco, a temperatura do sangue e a taxa de respiração a cada 5 minutos. Esse requisito pode ser verdadeiro em vários dispositivos implementados em todas as camas em uma ala. O editor de Serviço Configurável de Dispositivo Médico, portanto, suporta a configuração de conjuntos de medidas, que especificam um número de medidas e podem ser aplicados em qualquer número de dispositivos.

Quando o administrador está configurando um conjunto de medida, ele seleciona um tipo de dispositivo e é apresentado a uma lista de medidas que são suportadas por esse tipo de dispositivo. O administrador pode selecionar as medidas necessárias e para cada medida o administrador especifica o intervalo no qual as medidas são passadas para o fluxo de mensagens para processamento.

Embora muitos dispositivos e medidas requeiram configuração, os dados de configuração podem ser extensivos. Portanto, para incluir esclarecimento, o administrador pode fornecer uma descrição do local de cada dispositivo, informações de ID do paciente, notas e tags para cada dispositivo e conjunto de medida.

Usando o nó do MedicalDeviceInput em fluxos de mensagens

Os dados que fluem do nó MedicalDeviceInput podem ser processados por um fluxo de mensagens usando qualquer um dos nós disponíveis no IBM Integration Bus. Os dados de medida são passados para o fluxo de mensagens como uma árvore de mensagem lógica. A árvore de mensagens usa o domínio DataObject e possui XML como seu formato de serialização (a mensagem é serializada para XML se a mensagem for gravada em uma fila de mensagens). Esses dados podem ser filtrados, transformados, agregados e roteados usando recursos padrão do IBM Integration Bus, antes de serem gravados em terminais de destino, por exemplo, bancos de dados, filas do IBM WebSphere MQ ou chamadas de serviço.

Para obter informações adicionais sobre o uso do nó do MedicalDeviceInput, consulte Usando dados de dispositivos médicos em fluxos de mensagens e Nó MedicalDeviceInput.

Integração de imagem DICOM

DICOM (Digital Imaging and Communications in Medicine) é um padrão para manipular, armazenar, imprimir e transmitir informações de imagens médicas. As informações podem incluir imagens DICOM e Relatórios Estruturados (SR) DICOM.

É possível usar o IBM Integration Bus Healthcare Pack para conectar DICOM PACS (Picture Archiving Communication Systems) e outras modalidades DICOM a fluxos de mensagens para permitir localização, processamento e roteamento de imagens DICOM em todo um sistema de assistência médica.

O recurso DICOM fornecido pelo IBM Integration Bus Healthcare Pack suporta vários cenários-chave.
Coletar Estudos para Admissão de Paciente
Quando um paciente é admitido no hospital, é possível consultar os DICOM PACS que estão em um ou mais locais para descobrir e recuperar quaisquer estudos do paciente. As imagens médicas relevantes então são disponibilizadas imediatamente à equipe clínica que está tratando o paciente. Para obter mais informações sobre esse cenário, consulte Coletar Estudos para Admissão de Paciente.
Segunda Opinião ou Indicação de Especialista
Em locais onde qualificações em radiologia são limitadas, é possível encaminhar as imagens DICOM (para propósitos de diagnóstico ou pesquisa) para especialistas em outros hospitais em um sistema de assistência médica. Para obter mais informações sobre esse cenário, consulte Segunda Opinião ou Indicação de Especialista.
Portal Clínico
É possível usar um aplicativo da web para exibir detalhes dos estudos DICOM de um paciente. Nesse cenário, apenas os atributos do estudo (não os dados de imagem) são apresentados, por exemplo, a modalidade e a data e hora do estudo. Para obter mais informações sobre esse cenário, consulte Portal Clínico. Esse cenário também é implementado no padrão Assistência Médica: Serviço da Web para DICOM no IBM Integration Bus Healthcare Pack.
O IBM Integration Bus Healthcare Pack inclui três nós.
  • O nó DICOMInput, que pode ser usado para receber imagens DICOM de um nó DICOM Service Class User (SCU), por exemplo, uma modalidade DICOM. Usando este nó, é possível extrair dados de uma imagem DICOM para uso em um fluxo de mensagens. Esse nó suporta as solicitações DICOM C-STORE.
  • O nó DICOMOutput, que pode ser usado para enviar imagens DICOM para um nó DICOM Service Class Provider (SCP), por exemplo, um DICOM Picture Archiving Communication System (PACS). Usando este nó, é possível combinar metadados de um fluxo de mensagens com uma imagem DICOM e enviar o resultado para um destino externo. Esse nó suporta as solicitações DICOM C-STORE.
  • O nó DICOMFindMove, que pode ser usado para consultar uma fonte externa para imagens DICOM que correspondam aos critérios fornecidos e, opcionalmente, mover as imagens DICOM para outro local. Esse nó suporta as solicitações DICOM C-FIND e C-MOVE.
Nota: O recurso DICOM fornecido pelo IBM Integration Bus Healthcare Pack não suporta as solicitações DICOM C-GET.
Para obter mais informações sobre como usar nós DICOM em fluxos de mensagens, consulte Usando Dados das Imagens do DICOM em Fluxos de Mensagens.

Padrões de Assistência Médica

O IBM Integration Bus Healthcare Pack inclui os padrões a seguir:
Padrão de Assistência Médica: HIPAA para XML
O padrão Assistência Médica: HIPAA para XML cria um fluxo de mensagens que você pode usar para converter arquivos HIPAA em arquivos XML.

 

Padrão de Assistência Médica: Home Health
O padrão Assistência Médica: Home Health facilita dados que são registrados em dispositivos do Home Health, como escalas, sendo transferidos para o aplicativo clínico solicitante. Os dispositivos do Home Health enviam dados sobre leituras do paciente para um Application Hosting Device (AHD). O AHD envia os dados em uma WAN para o aplicativo solicitante.
Assistência Médica: Padrão do Home Health

 

Padrão de Assistência Médica: HL7 para HL7
O padrão Assistência Médica: Transformação HL7 gera mapas de dados gráficos que é possível usar para montar mensagens HL7.
Assistência Médica: Padrão de Transformação HL7

 

Padrão de Assistência Médica: HL7 para HL7 DFDL
Nota: Há outra versão desse padrão disponível (o padrão Assistência Médica: HL7 para HL7). No entanto, recomenda-se que o padrão Assistência Médica: HL7 para HL7 DFDL seja usado para aplicativos novos e atualizados, se possível, pois esse padrão usa o modelo de mensagem DFDL em vez de o MRM e o Conjunto de mensagens HL7v25P. O modelo de mensagem DFDL apresenta os benefícios a seguir.
  • DFDL é um formato de padrão aberto considerando que o MRM e o Conjunto de mensagens HL7v25P são proprietários ao IBM Integration Bus.
  • O editor do DFDL fornece ferramentas mais simples para desenvolver e testar extensões para o esquema do HL7 comparado ao MRM e ao Conjunto de mensagens HL7v25P.
  • O modelo de mensagem DFDL suporta o HL7 versões 2.7, 2.6, 2.5.1 e anteriores, enquanto o MRM e o Conjunto de mensagens HL7v25P suportam somente o HL7, versão 2.5.1 e anteriores.

O padrão do Assistência Médica: HL7 para HL7 DFDL media entre os aplicativos clínicos que usam o padrão do HL7 v2 para mensagens. Por exemplo, um Patient Administration System (PAS) pode emitir uma única mensagem que é distribuída para um ou mais aplicativos clínicos que requerem as informações do paciente.

O padrão não está restrito para lidar com mensagens de um único tipo do HL7 (por exemplo, ADT) e código (por exemplo, A01), mas pode receber e processar qualquer mensagem com tipo e código de uma mensagem válida. Os aplicativos devem poder enviar e receber as mensagens usando MLLP over TCP/IP.

O padrão contém três fluxos de mensagens diferentes (se escolher diversos destinos, obterá fluxos de mensagens adicionais) e incluirá subfluxos que podem ser customizados.

Este diagrama mostra os fluxos de mensagens no padrão de Assistência Médica: HL7 para HL7 DFDL. O aplicativo de origem envia a mensagem usando MLLP over TCP/IP para o fluxo do Destinatário. O fluxo Destinatário usa o WebSphere MQ para enviar a mensagem para o fluxo Transformar e Rotear. O fluxo Transformar e Rotear usa o WebSphere MQ para enviar a mensagem para um ou mais fluxos do Emissor. Os fluxos do Emissor usam MLLP sobre TCP/IP para enviar a mensagem ao aplicativo de destino.

 

Padrão de Assistência Médica: Dispositivos Médicos para EMR
O padrão Assistência Médica: Dispositivos Médicos para EMR integra dispositivos médicos a um aplicativo Electronic Medical Record (EMR) que pode receber mensagens de resultado de observação do HL7 v2 (ORU R01). O aplicativo deve poder receber mensagens do HL7 ORU R01 usando MLLP over TCP/IP. O padrão inclui subfluxos que podem ser customizados.
Este diagrama mostra os fluxos de mensagens no padrão de Assistência Médica: Dispositivos Médicos para EMR. O dispositivo médico envia a mensagem para o fluxo de Dispositivos Médicos. O fluxo de Dispositivos Médicos usa o WebSphere MQ para enviar a mensagem para o fluxo Transformar e Rotear. O fluxo de Transformar e Rotear lê informações do paciente a partir de um banco de dados, que é atualizado por um fluxo de Serviços da Web com informações de um painel de clínicos. O fluxo de Transformar e Rotear usa o WebSphere MQ para enviar a mensagem a um fluxo do Emissor. O fluxo do Emissor usa MLLP over TCP/IP para enviar a mensagem ao aplicativo de destino.

 

Padrão de Assistência Médica: Serviço da Web para DICOM
O padrão Assistência Médica: Serviço da Web para DICOM integra um aplicativo escrito usando serviços da web com aplicativos DICOM que suportam as operações C-FIND e C-MOVE. É possível usar o padrão para consultar pacientes, estudos, séries e imagens de um DICOM PACS usando um serviço da web implementado pelo IBM Integration Bus.
Este diagrama mostra os fluxos de mensagens no padrão de Assistência Médica: Serviço da Web para DICOM. O aplicativo de solicitação envia os critérios de procura como um corpo XML na mensagem de solicitação SOAP. O fluxo de mensagens principal gerado por essa instância padrão extrai o corpo e passa-o para o nó DICOMFindMove. Os resultados XML propagados pelo nó DICOMFindMove são enviados de volta para o aplicativo de solicitação em uma resposta SOAP.

 

Padrão de Assistência médica: Patient Identifier Cross-reference Manager
O padrão Assistência médica: Patient Identifier Cross-reference Manager permite usar o IBM InfoSphere Master Data Management para ajudá-lo a criar um Patient Identifier Cross-reference Manager para uso no perfil Integrating the Healthcare Enterprise (IHE) Patient Identifier Cross Referencing (PIX). É possível, então, conectar seus aplicativos clínicos ao padrão para agirem como agentes do Patient Identity Source and Patient Identifier Cross-reference Consumer, conforme definido no perfil PIX.

 

Padrão de Assistência médica: Patient Demographics Query Supplier
O padrão Assistência médica: Patient Demographics Query Supplier permite usar o IBM InfoSphere Master Data Management para ajudá-lo a criar um Patient Demographics Supplier para uso no perfil Integrating the Healthcare Enterprise (IHE) Patient Demographics Query (PDQ). É possível, então, conectar seus aplicativos clínicos ao padrão para agirem como agentes do Patient Demographics Consumer, conforme definido no perfil PDQ.

 

Padrão de Assistência médica: Cross-Enterprise Document Sharing Consumer
Use o padrão Assistência médica: Cross-Enterprise Document Sharing Consumer para localizar Unique Universal Identifiers (UUID) do documento armazenado em um registro XDS e, em seguida, use o UUID para recuperar esses documentos a partir do repositório XDS. Para obter mais informações, consulte o padrão Assistência médica: Cross-Enterprise Document Sharing Consumer.

 

Padrão de Assistência médica: FHIR Transformation
Use o padrão Assistência médica: FHIR Transformation para transformar recursos do HL7 FHIR entre os formatos XML e JSON. Para obter mais informações, consulte o padrão Assistência médica: FHIR Transformation.

 

Para obter informações adicionais sobre os padrões, consulte Desenvolvendo soluções de integração de assistência médica usando os padrões fornecidos em IBM Integration Bus Healthcare Pack.

Eventos de auditoria ATNA

O Perfil de Integração ATNA (Audit Trail and Node Authentication) abrange diversos aspectos de segurança, incluindo os padrões e processos para rotear e armazenar com segurança mensagens de evento de auditoria em um repositório. Usando um nó ATNAAudit, é possível gerar mensagens de evento de auditoria ATNA dos dados de assistência médica roteados por meio de fluxos de mensagens e enviar essas mensagens de evento de auditoria para um determinado repositório de auditoria ATNA.

Para obter informações sobre dados de auditoria em fluxos de mensagens, consulte: Auditoria dos Dados nos Fluxos de Mensagens.

Análise de dados de assistência médica

É possível usar a perspectiva Análise de Dados do IBM Integration Bus com um perfil de Análise de Dados fornecido pelo IBM Integration Bus Healthcare Pack para analisar e filtrar dados de assistência médica em seus fluxos de mensagens. Os dados de assistência médica muitas vezes são transportados em mensagens e documentos complexos que não são processados facilmente pelos aplicativos de recebimento de dados. Usando um projeto de Análise de Dados, é possível analisar dados de assistência médica, extrair elementos-chave e criar uma estrutura de mensagens simplificada que pode ser mapeada diretamente nas tabelas de banco de dados que são utilizadas por ferramentas de inteligência de negócios.

O IBM Integration Bus Healthcare Pack fornece quatro perfis de Análise de Dados. Cada perfil é usado para um tipo específico de dados de assistência médica.

Para obter mais informações sobre análise de dados de assistência médica, consulte Analisando Dados de Assistência Médica em Fluxos de Mensagens.

Copyright IBM Corporation 2011, 2015Copyright IBM Corporation 2011, 2015.

        
        Última atualização
        
        Última atualização : 2015-06-23 08:48:59


Tópico de ConceitoTópico de Conceito | Versão 4.0.0.0 | ha00010