Background

Equipes de Serviço Médico de Emergência (EMS) frequentemente chegam ao departamento de emergência com pacientes cujos dados demográficos estão incompletos ou desconhecidos — sem número de prontuário médico (MRN), sem nome confirmado e, às vezes, sem data de nascimento. Ainda assim, as notas de transporte do EMS precisam ser registradas no prontuário correto.

Para apoiar uma documentação segura e confiável, agências de EMS, serviços de integração de terceiros e equipes de integração hospitalar constroem interfaces seguras que trocam identificadores e mensagens clínicas. Quando esses identificadores não correspondem, os sistemas downstream não conseguem registrar automaticamente as notas de transporte — criando trabalho manual evitável e atrasando a completude do prontuário. Este artigo descreve como o FHIR Patient.Search (R4) pode ser usado para preencher as lacunas demográficas mais comuns e melhorar o registro automatizado.

O desafio

Em muitas integrações entre EMS e hospitais, os pacientes são inicialmente registrados sob identificadores genéricos ou temporários. O registro final — e qualquer fusão de prontuários — pode não ocorrer até mais tarde, às vezes após a alta. Até que essas atualizações se propaguem, os identificadores do paciente no EMS e no Prontuário Eletrônico (EMR) podem permanecer fora de sincronia.

Quando uma nota de transporte não pode ser registrada devido a uma incompatibilidade, a integração normalmente gera um erro que é direcionado para uma fila de trabalho do EMR para revisão manual. Nos volumes de EMS, essa fila pode crescer rapidamente. Uma causa raiz comum são mensagens de entrada que não possuem um ou mais campos demográficos necessários para uma correspondência confiável do paciente e registro no prontuário — mais frequentemente:

• Número de Prontuário Médico (MRN)
• Nome
• Data de nascimento
• Gênero

Como funciona hoje

Hoje, os dados demográficos ausentes são complementados consultando um banco de dados Microsoft SQL Server de longa duração (em operação há mais de 20 anos) que armazena uma visão interpretada de mensagens HL7 ADT (Demográficas). A camada de integração utiliza chamadas JDBC para executar procedures armazenadas e recuperar os campos necessários.

Uma abordagem baseada em FHIR

Uma opção mais moderna é recuperar os dados demográficos ausentes diretamente de um repositório FHIR. Especificamente, o FHIR Patient.Search (R4) fornece uma maneira baseada em padrões de consultar MRN, nome, data de nascimento e gênero usando qualquer informação parcial disponível no momento do registro da nota de transporte.

Para operacionalizar isso, um processo de negócio dedicado envolve a chamada Patient.Search (R4) e retorna uma resposta normalizada de volta ao fluxo de integração de origem.

Visão Geral do Fluxo de Trabalho

A origem solicitante envia um PatientSearch.Request (custom message class) para o processo de negócio.

A partir daí, o processo de negócio executa as seguintes etapas:

• Obtém um token de acesso OAuth.
• Transforma o PatientSearch.Request (custom message class) em um HS.FHIRServer.Interop.Request.
• Envia o HS.FHIRServer.Interop.Request para um repositório FHIR externo.
• Verifica se a resposta FHIR retorna HTTP OK (200).
• Converte a resposta FHIR do fluxo HTTP para um PatientSearch.Response (custom message class).
• Retorna o PatientSearch.Response (custom message class) ao processo de origem.

Considerações adicionais de fluxo de trabalho incluem:

• Garantindo que o fornecedor forneça pelo menos um dos seguintes: MRN, nome, data de nascimento ou gênero.
• Se várias respostas FHIR Patient forem retornadas, o resultado é encaminhado ao EMR como está, permitindo que o sistema gere um erro caso os campos fornecidos sejam insuficientes para identificar um paciente de forma única.