Integrando o Empreendimento de Assistência Médica com o WebSphere Message Broker V7.0

Estendendo a amostra Healthcare do WebSphere Message Broker para integração com o "mundo real"

Os compiladores IBM® WebSphere® Message Broker versão 7.0 inclui um conjunto de ativos de assistência médica que permitem trabalhar mais efetivamente com o sistema de mensagens HL7. Neste tutorial, aprenda a usar os ativos para desenvolver uma estratégia de integração de hospital centrada nos perfis de gerenciamento de identidade de pacientes definidos pelo do framework técnico IT Infrastructure (ITI) do Integrating Healthcare Enterprise (IHE). Exemplos práticos mostram como estender a amostra Healthcare do WebSphere Message Broker para desenvolver subfluxos reutilizáveis que aproveitam perfis do IHE para gerenciar a identidade dos pacientes. É possível estender um fluxo de amostra para os seus próprios projetos que fazem interface com o HL7 ou não.

Lee Surprenant, Software Engineer, Os compiladores IBM

Photograph of Lee SurprenantLee Surprenant é engenheiro de software IBM da equipe de padrões de software emergentes em Research Triangle Park, Carolina do Norte. É líder do projeto Stepstone Connected Health em openhealthtools.org. Lee representa a IBM no grupo de trabalho Continua Health Alliance Technical e no domínio de Patient Care Device (PCD) do Integrating Healthcare Enterprise (IHE). Lee é bacharel em ciências nas áreas de Ciências da Computação e Matemática Aplicada pela Universidade de Wisconsin-Madison.



31/Ago/2012

Antes de Iniciar

Sobre este tutorial

Há um foco global na transformação da assistência médica, com ênfase na qualidade do atendimento a um custo financeiramente suportável. Muitos estudos destacaram o papel da TI na transformação da assistência médica, e os administradores e legisladores estão atentos a isso. Há uma tremenda oportunidade de quebrar, de forma responsável, os silos de informações que podem, em conjunto, possibilitar a melhora no atendimento. Os objetivos de interoperabilidade na TI para assistência médica incluem conectar aplicativos para compartilhar dados de forma integrada e segura ao longo do ecossistema de assistência médica e entregar os dados para os cuidadores quando e onde for necessário.

Este tutorial:

  • Apresenta o WebSphere Message Broker V7.0 e explora como ele pode ser aplicado a cenários importantes da integração da assistência médica.
  • Baseia-se no suporte para as normas de sistemas de mensagens para assistência médica definidas pelo Health Level Seven International (HL7) e mostra como estender a amostra Healthcare (incluída) em um fluxo que pode executar o roteamento baseado em mensagens.
  • Explica como os frameworks técnicos da organização Integrating the Healthcare Enterprise (IHE) podem melhorar a interoperabilidade da assistência médica em um conjunto seleto de cenários de integração de alto valor.
  • Baseia-se no fluxo do roteador de mensagens HL7 para desenvolver um subfluxo reutilizável que usa a consulta Cross-reference (PIX) do IHE Patient Identifier para melhorar a integração de sistemas por meio de uma solução federada de gerenciamento de identidade de pacientes.

Objetivos

Você aprenderá sobre normas importantes para a integração da assistência médica e como usá-las para implementar uma solução de gerenciamento de identidade de pacientes de alto valor. Este tutorial é uma apresentação prática da amostra Healthcare do Message Broker. Você também aprenderá a estender as amostras para aproveitar os perfis do IHE a fim de suportar os seus próprios cenários de integração da assistência médica.

Pré-requisitos

Não há necessidade de experiência prévia com o WebSphere Message Broker nem com a integração de assistência médica, nem supomos que o leitor tem esse tipo de experiência, embora isso ajude a entender os conceitos mais rapidamente.

Para seguir este tutorial, você precisa:

  • Acesso a sistemas com o WebSphere Message Broker V7.0 e o WebSphere Message Broker Toolkit.
  • Acesso a uma instalação do Initiate Patient ou de qualquer outro produto da Enterprise Master Patient Index que implemente o agente técnico IHE Patient Identifier Cross-reference Manager (para concluir as etapas finais do tutorial).

Resources tem links para os sistemas que são pré-requisitos.


A amostra Healthcare do WebSphere Message Broker

O WebSphere Message Broker é um barramento de serviço corporativo (ESB) avançado. Clientes de vários segmentos de mercado diferentes, inclusive da assistência médica, usam o broker no "coração" de sua arquitetura orientada a serviços (SOA) para simplificar a integração de aplicativos e melhorar a agilidade de negócios. O WebSphere Message Broker inclui suporte para várias tecnologias de interface e vários adaptadores de aplicativos pré-desenvolvidos para ajudar as empresas a desenvolver fluxos de roteamento inteligente, mediação e transformação que conectam terminais heterogêneos que, de outra forma, estariam isoladas dentro do empreendimento.

O WebSphere Message Broker versão 7 tem um conjunto de ativos de assistência médica, inclusive modelos do sistema de mensagem HL7 v2 e ativos de processamento para o Minimum Lower Layer Protocol (MLLP). Os ativos são empacotados como uma Amostra Healthcare pré-desenvolvida que pode ser importada e executada a partir do WebSphere Message Broker Toolkit. Não se deixe enganar pelo termo amostra; os ativos de assistência médica foram desenvolvidos e reforçados por meio de uma série de trabalhos da IBM Global Services com provedores de assistência médica de porte médio e grande.

Importe e execute a amostra Healthcare

No WebSphere Message Broker Toolkit, na documentação da ajuda da amostra Healthcare, é possível importar e implementar a amostra Healthcare com um único clique. Também é possível encontrar o ativador Samples and Tutorials, como mostra a Figura 1. (Veja uma versão ampliada da Figura 1.)

Figura 1. Navegando para a amostra Healthcare
Navegando para a amostra Healthcare

Depois de importar e implementar a amostra Healthcare, certifique-se de examinar os projetos gerados e identificar alguns dos Ativos de processamento para assistência médica .

Usando os testes de fluxo do WebSphere Message Broker Toolkit para mensagens HL7

Para executar a amostra Healthcare, pode-se usar o fluxo de teste predefinido HL7_Text_Test_Message.mbtest para enfileirar uma mensagem HL7 de amostra. Ao modificar essa mensagem de amostra ou criar a sua, observe que as mensagens HL7 v2 normalmente são formadas por um ou mais segmentos de mensagem separados por um terminador de segmento (normalmente, o caractere de retorno de linha). Já que pode ser difícil criar ou detectar esse caractere na caixa de texto fornecida, é recomendável visualizar a mensagem em hexadecimal para se certificar de que haja apenas um caractere de retorno de linha (0x0d) entre cada segmento.

Agora você está pronto para executar a amostra para o WebSphere Info Center Instruções para executar a amostra Healthcare .

A amostra basicamente executa uma série de ações de enfileirar e desenfileirar que testa os fluxos do emissor e do receptor e as transformações de mensagem de HL7 para CIM e vice versa, por meio de um cenário simples de envio e confirmação. Depois de enfileirar a mensagem de amostra em HCA_TEST_ACK_APP_OUT, ela é enviada por meio de um MLLP de transporte definido pelo HL7 para Flows.Main Receiver.msgflow. Em seguida, esse fluxo processa a mensagem e retorna uma confirmação para SendingApplication. A confirmação está na fila HCA_TEST_ACK_APP_OUT.

O Receiver.msgflow também enfileira a mensagem original na fila HCA_HL7_TO_CIM_IN, onde ela passa por uma transformação para o Modelo de Informação Comum (CIM) e novamente para HL7. O resultado dessa transformação round trip é colocado na fila HCA_SENDER_IN, onde ele é selecionado pelo Flows.Main Sender.msgflow e enviado em MLLP para a amostra ReceivingApplication. Em seguida, o ReceivingApplication coloca essa mensagem na fila HCA_TEST_RECEIVE_APP_OUT, na qual ela pode ser desenfileirada e verificada na visualização Test Client de HL7_Text_Test_Message.mbtest.

Figura 2. Testando a amostra Healthcare
Testando a amostra Healthcare

Quando acabar de revisar a amostra, certifique-se de parar o HealthcareExecutionGroup mas não remova a amostra do broker ou da área de trabalho. Você reutilizará esses ativos, inclusive as filas de amostra que foram criadas, mais adiante no tutorial.


Integrating the Healthcare Enterprise (IHE)

O IHE é uma colaboração entre os profissionais de assistência médica e o segmento de mercado para melhorar o compartilhamento de informações entre os sistemas de informática da assistência médica. A organização está dividida em domínios clínicos e operacionais relacionados. Em cada domínio:

  • Os usuários com experiência clínica e operacional identificam as prioridades de compartilhamento de informações e integração.
  • Os fornecedores de sistemas de informações relevantes desenvolvem soluções unânimes baseadas em normas para tratar dessas prioridades.

Cada domínio do IHE publica o seu próprio framework técnico, que aproveita e impõe normas relevantes dos segmentos de mercado de tecnologia da informação e assistência médica. O framework define um conjunto interoperável de trocas de mensagens, chamadas transactions, entre agentes do sistema de informações. Para resolver um determinado caso de uso ou cenário médico, as transações são agrupadas em um perfil IHE .

Health Level Seven (HL7)

Em muitos casos, o IHE seleciona normas do Health Level Seven International, uma das organizações mais proeminentes de desenvolvimento de normas de TI para assistência médica. Há duas versões principais de normas do HL7: versão 2.x e versão 3.x. Este tutorial concentra-se principalmente nas mensagens da versão 2.x.

O HL7 v2 permite flexibilidade — portanto, as implementações de sistema frequentemente são incompatíveis ou requerem um nível significativo de design e customização no site para funcionar em conjunto. Para melhorar essa situação, o IHE definiu diretrizes gerais para sistemas de mensagens HL7 v2 no Apêndice C do Volume 2x no seu framework técnico de IT Infrastructure (ITI). Além disso, cada perfil de transação do IHE pode definir os seus próprios requisitos para implementadores. O IHE testa a conformidade com as diretrizes por meio de vários eventos de "connect-a-thon" (maratona de conexões) e mantém um registro de produtos do fornecedor que alegam conformidade. Você encontra links para as diretrizes e para o diretório em Resources.

Gerenciamento de identidade dos pacientes

Pode-se dizer que o ponto de partida da interoperabilidade na assistência médica é o gerenciamento da identidade de pacientes. Para montar e trocar com precisão os dados dos pacientes ao longo dos aplicativos e silos de dados é necessário ter uma identificação comum do paciente. Muitos aplicativos, inclusive dentro de um empreendimento, criam seus próprios Identificadores de pacientes. um Enterprise Master Patient Index (EMPI) controla e gerencia identificadores de pacientes ao longo de diversos domínios de identificador. O Volume 1 do framework técnico de IT Infrastructure (ITI) do IHE define o seguinte conjunto de perfis para ajudar a melhorar a interoperabilidade por meio do gerenciamento de identidade de pacientes:

  • Patient Identity Cross-referencing (PIX)
  • Patient Demographics Query (PDQ)
  • Patient Administration Management (PAM)

Para suportar esses perfis, o Volume 2 do framework técnico define um conjunto de transações numeradas — muitas delas se baseiam no sistema de mensagens HL7 v2.

O restante deste tutorial se concentra em duas das transações de gerenciamento de identidade de pacientes usadas com maior frequência: o Patient Identity Feed (ITI-8) e o PIX Query (ITI-9). Você encontra links para esses dois volumes em Downloads.

Cenário de amostra: roteador Patient Identity Feed

O fluxo de mensagens que você desenvolverá é um roteador de feed de identidade de pacientes. Esse fluxo fornece um exemplo concreto de extensão da amostra Healthcare do WebSphere Message Broker no contexto de uma troca simples de mensagens usada amplamente nos hospitais. O fluxo tomará uma mensagem HL7 admit, discharge, transfer (ADT) em conformidade e a roteará para um sistema de destino verificando o aplicativo receptor desejado no cabeçalho da mensagem.

Embora o fluxo de roteamento tenha sido desenvolvido no contexto da transação Patient Identity Feed, seria possível desenvolver um mecanismo semelhante para tratar uma ampla variedade de tipos de mensagem e transações a partir de um único terminal.

Cenário de amostra: PIX Query Adapter

O segundo fluxo de mensagens é um subfluxo PIX Query Adapter que:

  • Aceitará qualquer mensagem HL7 de entrada
  • Extrairá o segmento de patient identifier (PID)
  • Executará uma consulta PIX usando essas informações
  • Substituirá o PID original pelo resultado

Seria possível usar esse subfluxo para adaptar mensagens HL7 entre sistemas para que o aplicativo de origem e o de destino pudessem continuar a usar os seus próprios identificadores locais. Esse cenário se baseia no roteador Patient Identity Feed para mostrar como o suporte de middleware do perfil de PIX do IHE pode melhorar a integração entre vários sistemas em um empreendimento de assistência médica.


Desenvolvendo um roteador Patient Identity Feed

IHE ITI-8: Patient Identity Feed

Versão do HL7

No fix pack 1, o WebSphere Message Broker V7.0 suporta HL7 v2.5.1, que é compatível com as versões anteriores das normas de sistemas de mensagens HL7 v2. O modelo de mensagem tem capacidade de manipular as mensagens v2.3.1 ADT requeridas pelo IHE ITI-8.

A transação Patient Identity Feed do IHE ITI se baseia em uma troca de mensagens HL7 v2.3.1 ADT simples de ponto a ponto, de um agente Patient Identity Source para um agente receptor, como um Patient Identifier Cross-reference Manager. A transação, também conhecida como feed de ADT, pode representar vários eventos relacionados ao paciente, tais como:

  • Admissão de um paciente hospitalizado (A01)
  • Registro de um paciente ambulatorial (A04)
  • Pré-admissão de um paciente hospitalizado (A05)
  • Atualização das informações do paciente no registro (A08)

Desenvolvendo um roteador simples de feed de identidade

Se o sistema emissor e o sistema receptor suportam a transação Patient Identity Feed do IHE, deve ser possível configurar esses sistemas para trabalharem juntos. Mesmo assim, talvez seja útil usar um ESB para as funções de roteamento e para melhorar a visibilidade e governança da arquitetura. Por exemplo: pode ser difícil manter uma integração ponto a ponto em caso de ciclos de manutenção, aquisições e fusões corporativas e outras iniciativas de transformação corporativa.

No exemplo a seguir, você incluirá um roteador simples para os feeds corporativos de identidade de pacientes, para que cada sistema de origem possa apontar para um broker central que roteia adequadamente a solicitação com base nas informações do cabeçalho.

Para começar o novo projeto:

  1. Abra o WebSphere Message Broker Toolkit e selecione New... --> Message Broker / Message Flow Project, conforme mostrado abaixo.
    Figura 3. Novo projeto
    Novo projeto

    Você deve ver o New Message Flow Project mostrado na Figura 4.

    Figura 4. Referências do projeto de fluxo
    Referências do projeto de fluxo

    Depois de criar um novo projeto, crie um novo fluxo de mensagens para o fluxo do roteador Patient Identity Feed. A forma mais fácil de começar é basear o fluxo na amostra já existente.

  2. Navegue para o HealthCareAsset --> Flows --> Flows.Main e:
    1. Copie o fluxo Receiver.
    2. Cole uma cópia no projeto que acabou de criar.
    3. Dê a ele um nome significativo (como PatientIdentityFeedRouter).
    4. Abra o fluxo.

O framework técnico ITI do IHE exige o uso do MLLP para mensagens HL7 v2. Esse protocolo é suportado no WebSphere Message Broker por meio do uso de TCP/IP e dos nós Trim/Add MLLP Bytes. Depois de cortar os bytes de controle de fluxo no nó Trim MLLP Bytes, o Receiver.msgflow tentará analisar o BLOB recebido em uma mensagem HL7 adequada.

A Seção C.2: "HL7 Implementation Notes" do framework faz várias restrições ao uso de mensagens HL7 v2 em uma transação do IHE. Especificamente, a seção C.2.2: "Message Control" exige que os sistemas incluam o Aplicativo e as Instalações Emissoras e Receptoras na mensagem (MSH.3, MSH.4, MSH.5 e MSH.6). Para garantir o cumprimento das diretrizes, é necessário incluir algumas verificações adicionais para o procedimento de análise e validação CheckMSHFields , como mostra a Listagem 1.

Listagem 1. Analisar e validar: largura máxima de CheckMSHFields()
...
SET env.ErrorCondition = 'MSH parsing or validation error: MSH.4.SendingFacility is null';
SET env.InputMSH.Field4= MSHFields.hl7:MSH.hl7:"MSH.4.SendingFacility".hl7:"HD.1";
                
--begin user add
SET env.ErrorCondition = 'MSH parsing or validation error: ' ||
'MSH.5.ReceivingApplication is null';
SET env.InputMSH.Field5= MSHFields.hl7:MSH.hl7:"MSH.5.ReceivingApplication".hl7:"HD.1";

SET env.ErrorCondition = 'MSH parsing or validation error: ' ||
					'MSH.6.ReceivingFacility is null';
SET env.InputMSH.Field6= MSHFields.hl7:MSH.hl7:"MSH.6.ReceivingFacility".hl7:"HD.1";

SET env.ErrorCondition = 'MSH parsing or validation error: ' ||
					'MSH.7.DateTimeOfMessage is null';
SET env.InputMSH.Field7= MSHFields.hl7:MSH.hl7:"MSH.7.DateTimeOfMessage";
	
SET env.ErrorCondition = 'MSH parsing or validation error: ' ||
					'MSH.9.MessageType is null';
SET env.InputMSH.Field9= MSHFields.hl7:MSH.hl7:"MSH.9.MessageType";
--end user add
...

Conforme o que foi discutido nas informações sobre a amostra Healthcare do WebSphere Message Broker (consulte Resources para ver o link), o nó Detect Duplicate é um subfluxo opcional que filtra mensagens repetidas usando o Message Control Identifier no MSH-10. Da mesma forma, o nó Add Sequence Number é opcional e possibilita o sequenciamento "primeiro a entrar, primeiro a sair" das mensagens do fluxo. Se em vez disso você quer usar um sequenciamento baseado no conteúdo da mensagem, deve remover o nó Sequence da amostra e depender dos aplicativos de origem e destino para manter a sequência com base nos dados da mensagem HL7. No caso do fluxo de roteador Patient Identity Feed de amostra neste tutorial, remova o nó de sequência do fluxo.

Para criar um fluxo que roteia todas as mensagens de identidade do paciente aos sistemas de destino usando o valor no primeiro componente do campo Receiving Application da mensagem — MSH.5:

  1. Remova os nós Prepare for MQ e Put to HCA_HL7_TO_CIM_IN e substitua-os por um único nó Route (localizado na paleta Routing).
  2. Depois de colocar esse nó, é possível incluir novos terminais de saída. Clique com o botão direito nos terminais de saída e selecione Add Output Terminal.
  3. Agora que você criou os terminais de saída, está na hora de criar as regras de roteamento.

    Figura 5, e A Figura 6 mostram como criar um filtro baseado em XPath que usará o valor de MSH.5.ReceivingApplication para rotear a mensagem para o terminal adequado.

    Figura 5. Construtor de expressões do nó Patient Identity Feed Route
    Construtor de expressões do nó Patient Identity Feed Route
    Figura 6. Propriedades do nó Patient Identity Feed Route
    Propriedades do nó Patient Identity Feed Route

    Também é possível usar um nó DatabaseRoute ou um nó Compute simples para executar uma tarefa semelhante. (Veja uma versão ampliada da figura 6.)

Agora as mensagens recebidas são roteadas por destino — portanto, é possível encaminhá-las para os terminais desejados. Uma forma de fazer isso é transformar o Sender.msgflow da amostra em um subfluxo com destino configurável. É possível:

  1. Copiar e colar o fluxo no novo projeto.
  2. Substituir o nó MQInput por um nó Input simples.
  3. Enganchar um nó Output no final.

Certifique-se de remover o nó Maintain Sequence para estabelecer a correspondência entre a sua mudança e o fluxo Receiver.

Por padrão, o nó HL7 ACK analisará e validará a resposta, propagando uma confirmação válida para o terminal "out". Dependendo das propriedades do aplicativo de destino, talvez seja necessário relaxar as restrições de validação removendo o sinalizador ValidateContent das opções de análise na linha 105 de Sender.esql na função Sender_Check_HL7_ACK Main(), como se mostra abaixo.

DECLARE options INTEGER BITOR(ValidateException, ValidateDeferred);

Se você quer propagar confirmações negativas e positivas, deve alterar a mesma função na linha 137.

IF error THEN
	--begin user add
	PROPAGATE TO TERMINAL 'out' MESSAGE OutputRoot EXCEPTION OutputExceptionList 
			FINALIZE NONE DELETE NONE;
	--end user add
	THROW USER EXCEPTION VALUES('ACK message with AE or AR received');
ELSE

O fluxo de mensagens da Figura 7 tomará a mensagem de amostra, converterá para um BLOB, incluirá os bytes MLLP necessários e tentará enviá-la para o destino configurado. O fluxo tem um processamento avançado, que inclui lógica para tentar novamente e um mecanismo de manipulação de exceção razoavelmente robusto que oferece criação de log baseado em variáveis de ambiente e pontos de verificação de processamento. (Veja uma versão ampliada da figura 7.)

Figura 7. Subfluxo HL7 Sender
Subfluxo HL7 Sender

A etapa final das modificações do subfluxo é promover as propriedades de conexão Send HL7 Message e TCPIPClientReceive para o nível de fluxo.

  1. Clique com o botão direito em qualquer parte do fluxo e selecione Promote Property..., conforme mostrado abaixo.
    Figura 8. Promote Properties
    Promote Properties
  2. Na Figura 9, é possível permitir que um fluxo de mensagens integre o subfluxo Sender e configure o destino de acordo com o nó.
    Figura 9. Promover as propriedades Connection details de TCP/IP
    Promover as propriedades Connection details de TCP/IP

Você alterou Sender.msgflow e pode usar esse subfluxo no Patient Identity Feed Router de exemplo, da seguinte forma:

  1. Clique com o botão direito no editor de fluxo e selecione Add Subflow....
  2. Inclua subfluxos conforme a necessidade
  3. Enganche os terminais de saída do nó Route nos terminais de entrada do subfluxo Sender.
  4. Configure os Connection details dos nós Sender para apontar para os terminais desejados.

Finalmente, já que os sistemas de destino responderão com as suas próprias mensagens de reconhecimento:

  1. Substitua o nó Build ACK por um nó Reset Content Descriptor simples.
  2. Configure-o para reconfigurar o domínio de mensagem para o tipo BLOB a fim de preparar a resposta para a transmissão ao solicitante original.

Agora você deve ter um fluxo semelhante à a figura 10. (Veja uma versão maior da Figura 10.)

Figura 10. Roteador Patient Identity Feed
Roteador Patient Identity Feed

Implementando modelos de mensagens grandes

Ao implementar fluxos que fazem referência a modelos de mensagens grandes, como o modelo de HL7 v2.5, é muito recomendável colocar os modelos de mensagem nos seus próprios arquivos bar (separados dos fluxos de mensagens compilados que fazem referência a eles). É possível poupar tempo e recursos de forma significativa permitindo que os fluxos sejam implementados sem forçar uma atualização do modelo de mensagem.

Certifique-se de que os fluxos de mensagens de amostra originais não estejam executando (para evitar conflitos) e, em seguida:

  1. Implemente o novo fluxo Patient Identity Feed Router para o broker, juntamente com o SendingApplication, para testar.
  2. Copie e cole o HL7 Message Tester no novo projeto ou substitua a mensagem de amostra original pelo conteúdo da Listagem 2.

Certifique-se de substituir as novas linhas por caracteres adequados de retorno de linha. Conforme descrito em Usando os testes de fluxo do WebSphere Message Broker Toolkit para mensagens HL7, é difícil criar esses caracteres no editor. É recomendável começar pela mensagem de amostra original ou importar a nova mensagem clicando em Import Source... e selecionando o arquivo Listing.txt adequado a partir das mensagens HL7 v2 de amostra fornecidas com este tutorial (o link para esse arquivo compactado está em Downloads).

Listagem 2. Largura máxima da mensagem Patient Identity Feed de amostra
MSH|^~\&|IBM Message Broker|IBM|HIE|IBM|20101118104152-0500||ADT^A01^ADT_A01|1|P|2.3.1
EVN||20101118081234-0500
PID|||xxx^^^&1.3.6.1.4.1.21367.2010.1.2.300&ISO||Works^Developer||19501010|F
PV1||I

Initiate Patient

Initiate Patient é um exemplo de EMPI que implementa o agente Patient Identity Consumer no perfil do IHE Identity Feed Profile (consulte Resources para ver o link para o IBM Initiate Patient). Se for bem-sucedida, a mensagem anterior criará um novo registro a entidade paciente ou, se a entidade ainda não existe, criará uma nova entidade. A Figura 11 mostra a possível aparência do registro no Initiate Inspector, um visualizador baseado na Web para a sua instalação do Initiate Patient. Ao alimentar identidades heterogêneas de pacientes em um sistema como o Initiate Patient, o empreendimento pode manter uma visualização única do paciente em cada um dos seus sistemas. (Veja uma versão ampliada da Figura 11.)

Figura 11. Initiate Inspector
Initiate Inspector

Desenvolvendo um adaptador de feed de identidade com o Modelo de Informação Comum

Infelizmente, a maioria dos empreendimentos lida com sistemas heterogêneos que têm graus variados de suporte às normas. Nesses casos, um ESB pode fornecer mais valor por meio da mediação e transformação das trocas de mensagens. As implementações de HL7 da origem e do receptor podem ser incompatíveis devido à diferença de versões, extensões locais de "segmentos Z" ou talvez porque um único lado não suporta o sistema de mensagens HL7. Independentemente disso, você deve ser capaz de fazer interface com eles por meio do WebSphere Message Broker.

A abordagem preferencial é usar o Modelo de Informação Comum (CIM) integrado no formato de "tabela dinâmica" entre os sistemas. É possível customizar o CIM, que é baseado em normas do HL7, como um modelo interno de sistema de mensagens sem necessidade de que o usuário modifique o modelo de mensagem padrão do HL7 que é usado para fazer interface. O modelo se destina a fornecer uma visualização canônica das informações de mensagem com redundância reduzida e mais clareza.


Desenvolvendo um subfluxo Patient Identifier Cross-reference

IHE ITI-9: Consulta PIX

A transação Consulta PIX do ITI do IHE é formada por uma consulta/resposta HL7 v2.5 entre um Patient Identifier Cross-reference Consumer e um Patient Identifier Cross-reference Manager. A transação recupera uma lista de identificadores de pacientes referentes a um determinado identificador de entrada. A função de Patient Identifier Cross-reference Manager frequentemente é desempenhada por um sistema probabilístico de EMPI, como o Initiate Patient.

Anatomia de uma consulta PIX

A consulta PIX se baseia na mensagem Get Corresponding Identifiers de HL7 QBP_Q23_QBP_Q21, formada por três segmentos obrigatórios:

MSH
Cabeçalho da mensagem
QPD
Parâmetro de definição da consulta
RCP
Parâmetro de controle de resposta

A seção 3.9.4.1.2 do "Volume 2a, IHE ITI Technical Framework" detalha os requisitos de cada segmento. Em relação ao exemplo deste tutorial, o segmento QPD deve conter um Person Identifier no componente de ID do campo QPD-3.

Na maioria das mensagens HL7 v2, as informações de identificação do paciente estão incluídas na mensagem em um segmento especial de PID. Para implementar um subfluxo de consulta PIX reutilizável, é possível definir um fluxo que aceita mensagens HL7 de qualquer sistema de origem com um segmento de PID e retorna a mesma mensagem com o segmento de PID substituído pelo identificador correspondente usado pelo sistema de destino. Embora essa seja apenas uma das formas possíveis de usar a transação PIX Query, essa forma oferece o benefício de ocultar a complexidade de Patient Identifier Cross-reference a partir dos sistemas finais. Os sistemas finais continuam usando os identificadores locais e obtêm os benefícios de uma infraestrutura global de pacientes.

Criando um PIX Query Adapter básico

Primeiro, crie um novo fluxo.

  1. Vá para o assistente New Message Flow e insira as informações mostradas abaixo.
    Figura 12. Assistente de fluxo novo
    Assistente de fluxo novo
  2. Inicie o fluxo incluindo novos nós Input e Output a partir da paleta Construction.
  3. Coloque um nó Validation como marcador para validar a mensagem recebida.
  4. Crie um novo nó Mapping a partir da paleta Transformation.
    Figura 13. Início do fluxo de adaptador de PIX
    Início do fluxo de adaptador de PIX
  5. Depois de renomear o nó Mapping, clique duas vezes nele para abrir o editor de nó Map.
    Figura 14. Assistente New Message Map
    Assistente New Message Map

Nó Mapping da consulta PIX

Depois de abrir o editor de mapeamento

  1. Expanda $target na coluna Map Script do editor de tabelas.
  2. Clique com o botão direito em Q21_Query_By_Parameter e selecione Insert Children...
  3. Clique em Concluir para incluir os componentes necessários da consulta na ordem adequada.

Faça o mesmo no nó MSH que você acabou de criar e no descendente dele e inclua verificações ao lado de MSH.5 e MSH.6 (são obrigatórios de acordo com o IHE). Configure os valores padrão de campo como mostra a A figura 15.

Figura 15. Valores de MSH da consulta PIX
Valores de MSH da consulta PIX

Você deve ver um erro no mapeamento, indicando que o kit de ferramentas é:

Unable to find function, procedure, or module named "CreateHL7CurrDate"
in default broker schema.

Pode-se resolver esse erro criando um novo utilitário de ESQL no pacote padrão. A Listagem 3 mostra um exemplo.

Listagem 3. CreateHL7CurrDate()
CREATE FUNCTION CreateHL7CurrDate() RETURNS CHAR
BEGIN
	DECLARE hl7DateTime CHARACTER;
	SET hl7DateTime = CAST(CURRENT_TIMESTAMP AS CHARACTER FORMAT 'yyyyMMddHHmmss');
	RETURN hl7DateTime;
END;

Você preencheu os valores do segmento MSH; portanto, podemos passar ao segmento QPD. Na parte superior de mapeamento do editor:

  1. Expanda o nó QPD no lado de destino.
  2. Clique com o botão direito no elemento CE.1 de QPD.1.MessageQueryName e selecione Enter Expression para inserir um Message Query Name.
  3. De acordo com a seção 3.9.4.1.2.2 do Volume 2a, IHE ITI Technical Framework, configure o valor como IHE PIX Query.
  4. Da mesma forma, já que QPD.2: Query Tag é exigido pelo IHE, é possível incluir uma expressão que torna esse valor exclusivo para cada solicitação.

    Para facilitar o mapeamento em relação à mensagem de origem, use MSH.10.MessageControlID como esse valor, prefixado pela letra Q (uma convenção comum para consultas HL7), como se mostra abaixo.

    fn:concat('Q',$source/tns1:HL7/tns1:MSH/tns1:MSH.10.MessageControlID)

Novamente, na parte superior de mapeamento do editor:

  1. Navegue para o segmento PID do lado de origem e arraste PID.3.PatientIdentifierList da esquerda para a direita, para QPD.3.UserParametersInSuccessiveFields à direita, como mostra a figura 16.

    Isso criará um submapa no qual é possível concentrar-se no mapeamento do identificador de paciente no QPD.3.

  2. No submapa que você acabou de criar, expanda o nó de destino na coluna Map Script do editor de tabela e insira o valor a seguir.
    fn:concat($source/tns1:CX.1, '^^^', $source/tns1:CX.4/tns1:HD.1, '&',
    $source/tns1:CX.4/tns1:HD.2, '&', $source/tns1:CX.4/tns1:HD.3)

    Basicamente, essa instrução desenvolve um Composite ID do HL7 somente a partir das partes mais relevantes do identificador de paciente recebido.

Finalmente, no segmento de RCP, configure RCP.1.QueryPriority com o valor Eu, conforme o exigido pelo IHE, indicando que a resposta deve ser retornada em um modo Immediate. (Veja uma versão ampliada da Figura 16.)

Figura 16. Mapa de mensagem PIX Adapter
Mapa de mensagem PIX Adapter

Também é possível desenvolver a mensagem PIX Query em um nó Compute. Como exemplo, veja o módulo ReceivingApplication_Build_ACK na amostra Healthcare do WebSphere Message Broker Healthcare.

Consulta PIX - domínio solicitado

No sistema de mensagens HL7, cada identificador deve ter um domínio de sistema de mensagens. Por padrão, uma consulta PIX do IHE retorna todos os identificadores correspondentes no sistema de destino. Entretanto, os clientes podem solicitar um identificador de domínio específico na resposta ao incluir um valor em QPD-4-What Domains Returned.

Listagem 4. Solicitação de inclusão de domínio do PIX Adapter
                DECLARE hl7 NAMESPACE 'urn:hl7-org:v2xml';
                ...
                CREATE COMPUTE MODULE PIXAdapter_AddDomainRequest
                DECLARE RequestedDomain EXTERNAL CHARACTER '';
                
                CREATE FUNCTION Main() RETURNS BOOLEAN
                BEGIN
                CALL CopyEntireMessage();
                
                IF RequestedDomain IS NOT null THEN
                IF RequestedDomain <> '' THEN
                DECLARE Query REFERENCE TO
                OutputRoot.MRM.hl7:QPD.hl7:"QPD.3.UserParametersInSuccessiveFields";
                
                SET Query = Query || '|^^^' || RequestedDomain;
                END IF;
                END IF;
                
                RETURN TRUE;
                END;
                ...

O operadorEXTERNAL na declaração RequestedDomain indica que essa propriedade é uma propriedade definida pelo usuário. Para que essa propriedade seja configurada como parte do fluxo, é necessário incluir uma propriedade com o nome idêntico ao da guia User Defined Properties do editor de fluxo.

Figura 17. Propriedades definidas pelo usuário do PIX Adapter
Propriedades definidas pelo usuário do PIX Adapter

Salvando e restaurando a solicitação original

Nesse ponto, é necessário incluir o subfluxo Sender que foi desenvolvido para o fluxo Patient Identity Feed Router. Configure a propriedade Connection details do nó Sender para apontar a um Patient Identifier Cross-reference Manager ou promover a propriedade para o nível de subfluxo, para permitir que os fluxos de integração configurem o destino com mais facilidade.

Agora o fluxo de exemplo pode extrair as informações do paciente de uma mensagem HL7 de entrada e realizar uma referência cruzada no identificador. Para concluir o design do subfluxo, a mensagem original deve ser retornada com o identificador original substituído pelo identificador da resposta da referência cruzada.

  1. Salve e restaure a mensagem a partir da árvore de mensagens LocalEnvironment . Não se esqueça de alterar a propriedade do nó de cálculo SaveMessage chamada Compute mode de Message a LocalEnvironment and Message para garantir que as atualizações de LocalEnvironment sejam propagadas.
  2. Já que você está armazenando a mensagem original em LocalEnvironment, é necessário garantir que nenhum outro nó de cálculo sobrescreva esse valor. Selecione cada um dos nós de cálculo do subfluxo Sender.msgflow e mude o Compute mode de cada um para "Exception and Message."
Listagem 5. PIX Adapter - Salvar mensagem original
                CREATE COMPUTE MODULE PIXAdapter_SaveMessage
                CREATE FUNCTION Main() RETURNS BOOLEAN
                BEGIN
                CALL CopyEntireMessage();
                SET OutputLocalEnvironment = InputLocalEnvironment;
                
                DECLARE hl7BitStream BLOB ASBITSTREAM(InputRoot.MRM
                ENCODING InputRoot.Properties.Encoding
                CCSID InputRoot.Properties.CodedCharSetId
                SET InputRoot.Properties.MessageSet
                TYPE InputRoot.Properties.MessageType
                FORMAT InputRoot.Properties.MessageFormat);
                
                SET OutputLocalEnvironment.originalMessageBlob = hl7BitStream;
		RETURN TRUE;
	END;
...
Listagem 6. PIX Adapter - Restaurar mensagem original e substituir o segmento PID
CREATE COMPUTE MODULE PIXAdapter_RestoreMessageAndReplacePID
	CREATE FUNCTION Main() RETURNS BOOLEAN
	BEGIN
		SET OutputRoot.Properties = InputRoot.Properties;
		
		CREATE LASTCHILD OF OutputRoot DOMAIN('MRM') PARSE(
			InputLocalEnvironment.originalMessageBlob
			ENCODING InputRoot.Properties.Encoding
			CCSID InputRoot.Properties.CodedCharSetId
			SET InputRoot.Properties.MessageSet
			TYPE InputRoot.Properties.MessageType
			FORMAT InputRoot.Properties.MessageFormat);
		
		DECLARE targetPID REFERENCE TO InputRoot.MRM.hl7:PID;
		IF CARDINALITY(targetPID.hl7:"PID.3.PatientIdentifierList"[]) > 0 THEN
			SET OutputRoot.MRM.hl7:PID = targetPID;
		END IF;
		
		RETURN TRUE;
	END;
END MODULE;

Agora você deve ter um fluxo semelhante à figura 18.

Figura 18. Fluxograma do PIX Adapter
Fluxograma do PIX Adapter

Testando o PIX Query Adapter

Para testar adequadamente o PIX Query Adapter, é necessário ter acesso a um Patient Identifier Cross-reference Manager (ou uma simulação do mesmo). Este tutorial usará o sistema Initiate Patient apresentado anteriormente. O Initiate Patient pode criar automaticamente relacionamentos entre diversos registros, como a detecção de diversos identificadores de pacientes referentes a um único paciente.

Para simular um registro de paciente a partir de diversos sistemas hospitalares de informações (por exemplo: um sistema eletrônico de registros médicos e um sistema de informações de um laboratório), envie duas mensagens de admissão de pacientes provenientes de domínios diferentes usando o fluxo Patient Identity Feed Router. a Listagem 7 mostra uma mensagem HL7 de amostra proveniente de um sistema de EMR referente à admissão do paciente "Developer Works" e A Listagem 8 mostra uma amostra proveniente de um sistema de informações de um laboratório. Assim como acontece com as mensagens de amostra anteriores, é necessário substituir os caracteres de nova linha pelo terminador de segmento adequado — normalmente, um retorno de linha. Também é possível importar as mensagens diretamente das mensagens HL7 v2 para teste encontradas no arquivo compactado fornecido com este tutorial.

Listagem 7. Mensagem HL7 de resultado da observação proveniente de um sistema EMR
MSH|^~\&|EMR|IBM|Initiate Patient|IBM|20101128104152-0500||ADT^A01^ADT_A01|10|P|2.3.1
EVN||20101128081234-0500
PID|||xxx^^^&1.3.6.1.4.1.21367.2009.2.3.27&ISO||Works^Developer||19501010|F
PV1||I
Listagem 8. Mensagem HL7 de resultado da observação proveniente do sistema de informações de um laboratório
MSH|^~\&|LIS|IBM|Initiate Patient|IBM|20101128114152-0500||ADT^A01^ADT_A01|11|P|2.3.1
EVN||20101128091234-0500
PID|||yyy^^^&1.3.6.1.4.1.21367.2009.2.3.28&ISO||Works^Developer||19501010|F
PV1||I

Dependendo da configuração, o Initiate Patient pode detectar automaticamente que os identificadores estão relacionados ao mesmo paciente ou entidade. Se as informações dadas ao sistema são muito esparsas ou muito genéricas, a entidade tem que ser resolvida manualmente. Frequentemente, o sistema identifica esses registros como "possíveis duplicações" e sinaliza os registros para revisão. Depois de fazer a ligação adequada, é possível ver os registros referentes a um determinado paciente (nesse caso, Developer Works) usando o Initiate Inspector.

Figura 19. Registros de identidade do paciente no Initiate
Registros de identidade do paciente no Initiate

Para testar o sistema de exemplo, vamos criar um fluxo muito simples que:

  • Toma uma mensagem de entrada da fila HCA_TEST_SEND_APP_IN
  • Chama o subfluxo PIXAdapter
  • Grava a resposta em HCA_TEST_ACK_APP_OUT

Como essas filas são as mesmas que você usou até agora no SendingApplication, é necessário parar o fluxo antes de colocar na fila de entrada.

Figura 20. Aplicativo de teste do PIX Adapter
Aplicativo de teste do PIX Adapter

No editor de fluxo de PIXAdapterApplication:

  1. Selecionar o ponto de rastreamento PIXAdapter .
  2. Vá para o diretório Basic da visualização Properties.
  3. Configure o valor de RequestedDomain de forma que corresponda o domínio de identidade de pacientes usado pelos sistemas no destino da mensagem.

Este tutorial supõe que os nossos sistemas hospitalares estão usando identificadores de objeto (OIDs) e simularão uma mensagem de resultado de observação do sistema do laboratório do sistema eletrônico de registros médicos. O sistema do laboratório usará o seu próprio identificador para o paciente (no domínio 1.3.6.1.4.1.21367.2009.2.3.28 ). Nosso fluxo deve executar uma consulta PIX para recuperar o identificador do paciente no sistema de destino — portanto, defina o valor do RequestedDomain como:

&1.3.6.1.4.1.21367.2009.2.3.27&ISO

Finalmente chegou a hora de testar o PIX Adapter.

  1. Implemente o fluxo PIXAdapterApplication que você acabou de criar.
  2. Enfileire uma mensagem HL7 de amostra.

Listagem 9 mostra uma mensagem HL7 de resultado de observação com base na amostra Healthcare original do WebSphere Message Broker fornecida em HL7_Text_Test_Message.mbtest.

Mais uma vez, os caracteres de nova linha das mensagens de teste devem ser substituídos pelos terminadores de segmento apropriados. Também é possível importar as mensagens de amostra diretamente dos arquivos de entrada correspondentes incluídos nas mensagens HL7 v2 para teste encontradas no arquivo compactado fornecido com este tutorial.

Listagem 9. Mensagem HL7 de resultado de observação
MSH|^~\&|LIS|IBM|EMR|IBM|20040718235800|T|ORU^R01|103933-200128565054|T|2.5|1
PID|1||yyy^^^&1.3.6.1.4.1.21367.2009.2.3.28&ISO||Works^Developer||19501010|F||4
OBR|1|2|420002354^LA|1002085^CMP|||20040718232700|||TTROXEL|||LAB TO DRAW|20040718232800
OBX|1|NM|1000050^BUN||9|MG/DL|8-24||||F|||20040718235800
OBX|2|NM|1000070^NA||139|MEQ/L|134-144||||F|||20040718235800
OBX|3|NM|1000080^K||3.6|MEQ/L|3.6-5.3||||F|||20040718235800
OBX|4|NM|1000090^CL||106|MEQ/L|101-111||||F|||20040718235800
OBX|5|NM|1000030^GLU||110|MG/DL|74-118||||F|||20040718235800
OBX|6|NM|1000060^CREAT||1.1|MG/DL|0.5-1.4||||F|||20040718235800
OBX|7|NM|1000120^CA||8.9|MG/DL|8.5-10.3||||F|||20040718235800
OBX|8|NM|1000200^TP||7.2|G/DL|6.1-7.9||||F|||20040718235800
OBX|9|NM|1000210^ALB||3.8|G/DL|3.5-4.8||||F|||20040718235800
OBX|10|NM|1000470^BILI T||0.6|MG/DL|0.4-1.5||||F|||20040718235800
NTE|1|I|NORMAL RANGE CHANGED 01-15-04.
OBX|11|NM|1000250^ALKP||89|U/L|38-126||||F|||20040718235800
OBX|12|NM|1000260^SGOT||16|U/L|15-41||||F|||20040718235800
OBX|13|NM|1000100^CO2||26|MEQ/L|22-32||||F|||20040718235800
OBX|14|NM|1000280^SGPT||12|U/L|14-54|L|||F|||20040718235800
OBX|15|NM|1000110^AGAP||7||7-15||||F|||20040718235800

Depois de enviar a mensagem de teste, você deve encontrar o resultado a seguir na fila HCA_TEST_ACK_APP_OUT.

Lista 10. Mensagem HL7 de resultado de observação
MSH|^~\&|LIS|IBM|EMR|IBM|20040718235800|T|ORU^R01|103933-200128565054|T|2.4|1
PID|||xxx^^^CMO_IBM&1.3.6.1.4.1.21367.2009.2.3.27&ISO||Works^Developer
OBR|1|2|420002354^LA|1002085^CMP|||20040718232700|||TTROXEL|||LAB TO DRAW|20040718232800
OBX|1|NM|1000050^BUN||9|MG/DL|8-24||||F|||20040718235800
OBX|2|NM|1000070^NA||139|MEQ/L|134-144||||F|||20040718235800
...

O segmento de PID da mensagem de origem foi modificado para corresponder ao identificador usado para esse paciente no sistema de destino. Quando é combinado com o fluxo de roteador desenvolvido anteriormente, esse subfluxo simples pode formar a base de uma solução de middleware que permite que sistemas heterogêneos se integrem e se concentrem no conhecimento e nos identificadores dentro dos seus próprios domínios.

Desenvolvendo um adaptador de PIX com o CIM

Da mesma forma que o fluxo Patient Identity Feed Route, é possível alterar o subfluxo PIXAdapter para suportar terminais não HL7 mapeando de/para o CIM do IBM WebSphere Message Broker. Ao modificar os nós de entrada e saída do subfluxo PIXAdapter para o modelo de mensagem CIM (em vez do HL7), o subfluxo pode ser reutilizado facilmente em um conjunto expandido de cenários e fluxos de trabalho.

Por exemplo: um dos usos comuns do perfil Patient Identifier Cross-reference do IHE é em trocas de informações de assistência médica que implementam o perfil Cross-Enterprise Document Sharing (XDS) do IHE. Os agentes Document Source podem usar o subfluxo PIXAdapter para fazer upload de seus documentos com identificadores locais, deixando o ESB para executar uma consulta PIX que recuperará um identificador correspondente a partir do domínio de afinidade do XDS e o incluirá nos metadados de envio.


Conclusão

Neste tutorial você aprendeu a usar a amostra Healthcare do WebSphere Message Broker V7.0 para integrar sistemas hospitalares heterogêneos. O tutorial apresentou a organização IHE e explicou como os seus frameworks técnicos e perfis podem ser usados para melhorar a interoperabilidade de mensagens HL7.

O fluxo Patient Identity Feed Router demonstrou como estender os fluxos da amostra Healthcare fornecida para rotear mensagens recebidas com base nas informações do cabeçalho. Com o fluxo PIX Adapter, você explorou como usar a transação de consulta Patient Identifier Cross-reference (PIX) do IHE com uma EMPI (Initiate Patient) para manter a identidade dos pacientes ao longo dos sistemas.

Este tutorial expôs de forma superficial o que pode ser feito com o WebSphere Message Broker. Abordamos uma pequena amostra da gama de especificações de implementação definidas pelos domínios do IHE. Agora que você entende o propósito e a estrutura dos perfis de integração do IHE, é possível estender os fluxos de amostra desenvolvidos aqui para as suas próprias mediações e fluxos para projetos de interface do tipo HL7 e não HL7.


Downloads

DescriçãoNomeTamanho
Solution files for the tutorialsolution.zip50KB
HL7 v2 messages for testinghl7SampleInput.zip2KB

Recursos

Aprender

Obter produtos e tecnologias

  • Versão de teste do software IBM: Avalie os produtos de software da IBM da maneira que for melhor para você. De downloads de avaliação a produtos hospedados em nuvem, o developerWorks tem softwares especialmente para desenvolvedores.

Discutir

Mais downloads

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Segmentos de mercado, WebSphere
ArticleID=657627
ArticleTitle=Integrando o Empreendimento de Assistência Médica com o WebSphere Message Broker V7.0
publish-date=08312012