Paciente no centro de todas as Informações - Parte 2

HealthShare Patient Index

Enterprise Master Patient Index - Este é o nome dado ao processo que faz com que os inúmeros cadastros e registros coletados dos vários sistemas das instituições e redes de saúde sejam identificados univocamente e interligados através de um identificador único por indivíduo.

Isto viabiliza uma infinidade de benefícios para as instituições ou redes de saúde, pois permite, além da gestão das duplicidades em um mesmo sistema de prontuário eletrônico, que todos os dados segregados por número de cadastro sejam visualizados de forma consolidada por indivíduo. Cada vez mais, as instituições estão buscando uma abordagem holística do cuidado contínuo, da prevenção e da experiência centrada no paciente.

Falando sobre o produto Healthshare Patient Index da InterSystems, podemos dividi-lo em 6 grandes grupos de funcionalidades.

1 - Integração das informações cadastrais dos pacientes

Esta etapa engloba todos os mecanismos de coleta das informações nos sistemas de origem, seja através de API’s com protocolos específicos de saúde como o HL7, seja através de processos específicos ou customizados.

Neste ponto, é importante que a plataforma de integração ofereça uma série de requisitos de interoperabilidade que assegure flexibilidade, governança e segurança.

É muito comum sistemas de prontuário eletrônico internacionais fornecerem nativamente exportações de dados usando o protocolo HL7, que neste caso também é nativo nos produtos da Intersystems. Os sistemas nacionais geralmente demandam processos menos padronizados, e é por isso que é necessário que a plataforma seja de fácil e rápida implementação.

Geralmente as informações são enviadas ou disponibilizadas no momento em que o paciente é admitido nos estabelecimentos de saúde.

A arquitetura deste processo é definida conforme as necessidades de cada organização e disponibilidade dos recursos computacionais.

2 - Análise Qualitativa e Normalização

Normalizar significa trazer para um mesmo plano de comparação informações demográficas que foram cadastradas de formas completamente diferentes. É também nesta etapa que todo o “lixo” é removido. Isto não quer dizer que a informação seja ruim, mas que não serve para o processo do MPI.

Se os dados fossem comparados sem esta etapa, provavelmente cadastros de um mesmo indivíduo nunca seriam comparados, dada à discrepância de sistema para sistema.

Se observarmos o processo de cadastro de cada estabelecimento e sistema de origem, veremos uma infinidade de formas de entrada dos dados e diversas maneiras de armazenamento das informações. Isso depende de como cada sistema foi concebido e como cada processo foi implementado em cada setor da organização.

Um exemplo típico é o processo de admissão em alas emergenciais. Muitas vezes o paciente precisa ser atendido antes mesmo de ser identificado. Isso gera uma série de especificidades que precisam ser tratadas em uma análise qualitativa antes mesmo da implementação do processo de captura dos dados.

O outro exemplo muito comum é o cadastramento de recém nascidos. Cada caso é um caso. Em alguns sistemas os nomes são cadastrados com um prefixo “RN DE” seguido pelo nome da mãe. Isso porque os pais não sabem o nome dos bebês antes do parto e eles já precisam constar nos sistemas de prontuário eletrônico. Como todos os sistemas geralmente exigem o CPF, eles podem ser cadastrados com o mesmo CPF da mãe. É claro que este é só um exemplo de uma situação pontual, mas cada caso deve ser estudado e endereçado da forma mais adequada possível.

Além das especificidades de processo, há as que são de armazenamento dos dados. Documentos como CPF, RG e carteirinhas de seguro são armazenados com pontos e traços em alguns sistemas. Em outros são armazenados sem. O mesmo ocorre com datas. Nomes geralmente são armazenados em um único campo, uns com caixa baixa, outros com alta. Alguns são abreviados pela limitação de caracteres.

Endereços são os vilões na normalização. Os sistemas mais modernos são baseados no CEP, outros não. Os que não são sofrem muitas abreviações devidos aos sufixos, títulos ou até mesmo pela limitação dos caracteres.

Enfim, mesmo que em instituições mais modernas tecnologicamente, há sempre os sistemas legados. Estes também são incorporados ao processo de MPI porque trazem informações históricas valiosas para todo o processo assistencial.

Culturalmente e diferentemente dos sistemas norte americanos, os sistemas brasileiros possuem um único campo para capturar os nomes. Para melhorar a eficácia do processo de vinculação é importante que os sistemas tenham a capacidade de separar os nomes, considerando também os primeiros nomes compostos.

Outra capacidade não menos importante é a capacidade de trabalhar com as abreviações nos endereços. Isto requer um dicionário específico de abreviações para o nosso país.

3 - Indexação ou formação dos pares de comparação

Nesta etapa é que se decide quais serão os cadastros que serão comparados entre si, formando assim os chamados pares de comparação.

A decisão de se comparar registros não se baseia apenas nos documentos do paciente, assim como o CPF. Isso acontece porque há casos que não se tem o CPF do paciente ou casos que os filhos recebem o CPF dos pais. Para isto é necessário que o processo utilize os dados probabilísticos, assim como o nome, a data de nascimento, o sexo, os dados de contato e o endereço.

É preciso que este processo tenha algoritmos sofisticados para que os sistemas não gerem um número excessivo de comparações indevidas, assim como não deixem de fora comparações necessárias.

Por exemplo: A comparação de todos os “Josés” com todos os outros “Josés” não seria tão eficaz, pois poderia acarretar numa sobrecarga de processamento.

Outro ponto não menos importante nesta fase é a capacidade de se trabalhar com algoritmos fonéticos para o mercado brasileiro, que são completamente diferentes dos algoritmos americanos.

Isso significa que nomes escritos de maneiras diferentes ou equivocadas também serão considerados no processo. Exemplo: Dois cadastros de um determinado paciente com os nomes Walter Xavier e Valter Chavier podem se referir ao mesmo indivíduo.

O Healthshare MPI utiliza um processo extremamente eficiente de análise combinatória que evita este tipo de problema, utilizando tanto informações demográficas determinísticas quanto probabilísticas.

4 - Pontuação dos pares

Para cada par de comparação gerado, todas as variáveis demográficas são pontuadas separadamente: Primeiros nomes, nomes do meio, sobrenomes, documentos, sexo, cep, telefones, e-mails e endereços.

Antes de iniciar a comparação, é determinado um peso com uma pontuação máxima e mínima para cada variável, considerando a singularidade de cada uma. Por exemplo, o sexo possui um peso menor que a data de nascimento, que possui peso menor que o nome, que possui um peso menor que o CPF. E assim por diante.

Cada variável possui um algoritmo específico não binário de comparação que vai atribuir uma pontuação entre a mínima e a máxima para cada variável demográfica.

Exemplo: Se o sexo for o mesmo, serão atribuídos 2 pontos. Se não for o mesmo será atribuída a pontuação mínima, -4 pontos. Se o CPF for o mesmo, serão atribuídos 14 pontos,

Primeiros nomes e sobrenomes comuns também recebem pontuações menores que nomes mais comuns, assim como Silva e Souza.

Nomes de casada e solteira também devem ser considerados aqui no Brasil.

5 - Avaliação e determinação do identificador unívoco dos pares

Antes desta etapa, é necessário configurar as faixas de pontuação ou limiares que serão utilizados para vincular (mesmo indivíduo) ou não vincular (indivíduos diferentes) os pares de cadastro.

Neste ponto, pode-se definir também a faixa de pontuação dos pares que irão para uma lista de trabalho, passíveis de uma avaliação ou revisão humana.

Limiares a serem configurados:

Vínculo Automático – Acima de quantos pontos os pares serão automaticamente vinculados. Exemplo: Se o total de pontos dos pares estiver acima de 35 os mesmos serão automaticamente vinculados e não necessitarão de revisão humana.

Vínculo com posterior avaliação na Lista de Trabalho – Entre quantos pontos os pares irão para a lista de trabalho como vinculados (mesmos indivíduos) para avaliação humana. Exemplo: Os pares entre 30 e 35 pontos serão vinculados, mas poderão sofrer revisão de um profissional ou equipe designados para esta tarefa.

Não vínculo – Abaixo de quantos pontos os pares não serão vinculados. Exemplo: Se o total de pontos dos pares for abaixo de 30 eles não serão vinculados (indivíduos diferentes).

Não vínculo com revisão posterior na Lista de Trabalho – Entre quantos pontos os pares irão para a lista de trabalho como não vinculado (indivíduos diferentes) para uma revisão humana. Exemplo: Os pares entre 25 e 30 pontos não serão vinculados, mas poderão sofrer revisão de um profissional ou equipe designados para esta tarefa.

Há várias situações de exceções, onde mesmo pares com pontuação elevada podem não se referir ao mesmo indivíduo. Um exemplo típico são os gêmeos, que moram na mesma residência. Para isso é necessário que o produto disponibilize de artifícios para identificar estes casos.

Há outras situações que pares com baixa pontuação podem sofrer revisões se determinadas situações ocorrerem. Exemplo: pares com o mesmo CPF e data de nascimento e baixa pontuação. Este caso é no mínimo curioso, pois pode apontar um problema na baixa qualidade dos dados.

No HealthShare Patient Index, estes dispositivos são chamados de regras de vinculação (rules), que prevalecem sobre a regra de pontuação.

O produto já possui nativamente uma série de regras de exceção e elas são fundamentais para a segurança e confiabilidade de todo o processo.

Após esta etapa, todos os cadastros recebem um identificador universal denominado MPIID - Master Patient Index Identification. Os cadastros que possuírem o mesmo MPIID são referentes ao mesmo indivíduo.

6 – Serviços e API’s

Concluindo todo o processo de vinculação (Matching), é essencial que a plataforma ofereça maneiras passivas ou ativas de se comunicarem ou interoperarem com os sistemas de origem ou outros sistemas. Neste momento entram novamente todos os requisitos de interoperabilidade do produto, que já estão presentes na plataforma HealthShare da Intersystems.

As API’s de consumo do MPI são disponibilizadas neste momento através de protocolos conhecidos (HTTP Soap ou Rest) para que sistemas consigam obter as informações desejadas para diversos casos de uso.

Estes são alguns exemplos comuns de consumo de API’s do HealthShare MPI:

• Obter identificadores de outros sistemas partindo do identificador do sistema consumidor. Este tipo de consulta é denominada pelo IHE como PIX. Exemplo: Antes de enviar a prescrição para o laboratório o sistema de origem envia o seu identificador do cadastro e recebe uma resposta da API com o número do identificador do mesmo paciente no laboratório.

• Realizar pesquisas probabilísticas por dados demográficos. Exemplo: Consultar se existem cadastros demográficos para o paciente de nome Claudio Devecchi Junior. Este tipo de consulta é denominada pelo IHE como PDQ).

• Obter o melhor dado demográfico (Golden Record ou Composite Record) de um determinado paciente para enriquecer os cadastros demográficos ou para aproveitar os seus dados no momento de um determinado cadastro.

Existem também mecanismos ativos, onde o MPI se comunica com os sistemas para enviar informações úteis. Estes mecanismos também podem ser acionados de forma passiva através da chamada das Api’s.

Alguns exemplos são:

• No momento que um cadastro está sendo incluído ou atualizado o MPI pode fazer uma chamada retornando o identificador universal - MPIID. Desta forma o sistema de origem sempre ficará atualizado com este identificador. Quaisquer mudanças nas Listas de Trabalho são gatilhos para este tipo de chamada (callback)

• Quando algum cadastro for incluído e o MPI identificar que já existe esta mesma pessoa no mesmo sistema de origem, já é possível enviar uma notificação de duplicidade. Para os casos de resolução das duplicidades, é importante que exista um serviço específico para receber as mensagens de fusão de pacientes (PIX merge).

Conclusão

Todo o processo descrito anteriormente demonstra um pouco de como o produto HealthShare Patient Index trata dos desafios na área com relação aos cadastros e identificação dos pacientes e como é importante tratar das especificidades não somente do país, mas de organização para organização.

No próximo artigo, falaremos um pouco de como funciona o Healthshare Unified Care Record (UCR) e de como ele é fundamental para ajudar as instituições na abordagem holística do cuidado contínuo, da prevenção e da experiência centrada no paciente.