Ao revisar os diversos artigos que publiquei, percebi a necessidade de explicar uma funcionalidade muito prática em nosso EMPI (Enterprise Master Patient Index) que é a notificação de registros e vínculos para sistemas externos ao EMPI.

Essa funcionalidade é extremamente útil em uma ferramenta como o EMPI e, especialmente, em ambientes como o de saúde, nos quais é muito comum que o mesmo paciente tenha seus dados duplicados em diferentes sistemas, e no final seja necessário identificá-lo de forma única. A solução para reduzir esse amálgama de registros é fundir todos esses dados em um único registro que unifique todas as informações disponíveis.

Em geral, este trabalho de decidir quais registros devem ser fundidos é bastante complexo se a intenção é fazê-lo manualmente, pois é muito complicado ter acesso aos vários sistemas que contêm informações do paciente (sistemas como HIS, RIS, LIS, etc. de diferentes fornecedores distribuídos pelos diversos centros da organização de saúde), mas graças ao sistema de vinculação do EMPI, essa tarefa é simplificada, automatizando a grande maioria desses vínculos.

Como podemos informar todo esse ecossistema de aplicações que elas precisam fundir dois registros de pacientes? Bem, vamos ver como:

Conofiguração do EMPI 

O primeiro passo para começar a gerar notificações é configurar o Registro de Notificação PIX:

Aqui podemos ver que, por padrão, temos dois registros de notificação:

Um dos registros é para notificações PIXv3 usando mensagens HL7 v.3 (em XML). O outro será para PIXv2 usando mensagens HL7 v.2.

Para gerar as mensagens necessárias, devemos definir os domínios no campo definido por padrão ou marcar a caixa "All Domains" (Todos os Domínios). Este conceito de domínio corresponderá à Assignment Authority (Autoridade de Atribuição) (serviços de saúde, centros hospitalares, etc.). Com esta etapa, estaremos definindo os consumidores de nossa mensagem de saída; se não definirmos nenhum domínio, a mensagem não será gerada.

Agora, abrimos a produção que gerencia a operação do EMPI. Vamos dar uma olhada no Processo de Negócio HS.IHE.PIX.Manager.Process, que será o encarregado de criar as mensagens de resposta.

Vamos prestar atenção à configuração deste BP. Como você pode ver, temos dois parâmetros, PIXv2Operations e PIXv3Operations, que são configurados com duas Business Operations (BO) de nossa produção. A primeira delas será responsável por receber uma mensagem HL7 v.2 e a segunda, uma mensagem HL7 v.3.

Vejamos agora a BO PIXv2.Notification.Operations

Como você pode ver, definimos uma BO da classe EnsLib.HL7.Operation.FileOperation , pois simplesmente nos limitaremos a escrever a mensagem HL7 para atualização dos dados do paciente gerada em um arquivo no servidor. No entanto, você poderia usar qualquer operação de negócio que tenha desenvolvido e que aceite mensagens HL7 como entrada, podendo encaminhá-las via TCP, embutidas em um SOAP ou através de uma chamada REST para uma API externa.

Testando

Vejamos um exemplo do que acontece com dois pacientes em status de revisão de vínculo após vinculá-los normalmente.

Vamos vincular os dois primeiros, Juan García e Roberto Martín. Uma vez feito o vínculo, vamos ver o rastreamento da mensagem:

Aqui temos nossa mensagem HL7 gerada do tipo ADT_A31, na qual relatamos a atualização do paciente que foi vinculado ao novo MPIID. Agora, o paciente Roberto Martín com MRN 556432 do Hospital 12 de Octubre substituiu seu antigo MPIID (100001000) pelo mesmo que Juan García tem (100000001).

Nosso EMPI manterá um registro para cada paciente, criando apenas o vínculo com o MPIID atribuído a ambos. Com esta mensagem ADT_A31, caberia agora ao serviço de saúde ou hospital fundir ambos os pacientes em um só.

Conclusão

Como vimos neste artigo, o EMPI possui funcionalidades pré-construídas que cobrem as necessidades de qualquer organização de forma simples e ágil, e nos permite expandi-las para cobrir aquelas que são mais específicas de cada cliente. Uma delas seria precisamente as notificações automáticas para qualquer aplicação externa.