Integração HL7 e FHIR: como conectar sistemas hospitalares legados sem parar a operação

Conectar sistemas hospitalares legados sem interromper a operação exige uma arquitetura de transição: os sistemas existentes continuam funcionando enquanto uma camada de interoperabilidade traduz, valida e distribui mensagens HL7 v2 e recursos FHIR. A migração deve ocorrer por fluxos clínicos, com operação paralela, testes em sombra, reconciliação de dados, monitoramento e possibilidade de rollback.

Por que HL7 v2 e FHIR precisam coexistir

Hospitais raramente podem substituir simultaneamente prontuário eletrônico, laboratório, radiologia, farmácia, faturamento e sistemas departamentais. Alguns desses sistemas utilizam bancos proprietários; outros expõem arquivos, APIs específicas ou mensagens HL7 v2 transmitidas por MLLP.

O HL7 v2 permanece relevante para eventos transacionais já consolidados, como:

• ADT: admissão, alta, transferência e atualização cadastral;
• ORM: solicitação de exames e procedimentos;
• ORU: resultados laboratoriais e observações clínicas;
• SIU: agendamento;
• ACK: confirmação positiva ou negativa do processamento.

O FHIR, por sua vez, organiza dados em recursos acessíveis por APIs, como Patient, Encounter, Observation, ServiceRequest, DiagnosticReport e MedicationRequest. Ele facilita integrações com aplicações web, dispositivos, plataformas analíticas e novos serviços, mas não elimina automaticamente as regras construídas durante anos nos sistemas legados.

Portanto, a decisão prática não é “HL7 ou FHIR”. Em grande parte dos ambientes, a solução é HL7 v2 para compatibilidade operacional e FHIR para padronizar novos acessos e evoluções.

Arquitetura para integrar sem desligar o legado

A arquitetura recomendada intercala uma camada de interoperabilidade entre produtores e consumidores. Ela evita conexões ponto a ponto, nas quais cada mudança em um sistema exige alterações em vários outros.

Um fluxo típico funciona assim:

1. O sistema de origem produz uma mensagem HL7 v2, arquivo ou evento proprietário.
2. Um adaptador recebe o conteúdo e registra a mensagem original sem alterações.
3. A camada de integração valida estrutura, campos obrigatórios e códigos.
4. Os dados são convertidos para um modelo canônico ou para recursos FHIR.
5. Regras de roteamento determinam quais sistemas devem receber o evento.
6. O destino confirma o processamento ou devolve um erro rastreável.
7. Métricas, logs e trilhas de auditoria permitem acompanhar todo o percurso.

Essa camada pode conter um motor de interfaces, servidor FHIR, filas de mensagens, API gateway e mecanismos de observabilidade. A composição depende do volume, da criticidade e das capacidades de cada fornecedor.

Por que usar mensageria

Uma fila desacopla os sistemas. Se o laboratório estiver temporariamente indisponível, por exemplo, a admissão do paciente não precisa parar: o evento permanece armazenado e pode ser reprocessado quando o destino voltar.

Para isso funcionar, a implementação precisa prever:

• entrega ao menos uma vez e tratamento de duplicidades;
• identificador único por mensagem ou evento;
• retentativas com intervalo controlado;
• fila de mensagens não processadas, também chamada de dead-letter queue;
• ordenação quando a sequência clínica for relevante;
• limites de tempo e circuit breaker para destinos instáveis.

Migração gradual em seis etapas

1. Inventariar sistemas e fluxos clínicos

O levantamento não deve começar pelas tabelas do banco, mas pelos processos: quem cadastra o paciente, quem solicita o exame, onde o resultado é validado e quais sistemas dependem desse resultado.

Para cada interface, registre:

• origem, destino e responsável técnico;
• versão e perfil do HL7 utilizado;
• mensagens, segmentos e campos realmente consumidos;
• protocolo de transporte;
• volume normal e picos;
• latência aceitável;
• comportamento diante de duplicidade ou indisponibilidade;
• impacto clínico e operacional de uma falha.

Mensagens declaradas como HL7 v2.5, por exemplo, podem conter segmentos personalizados Z, códigos locais e interpretações diferentes do mesmo campo. A versão nominal não substitui a análise das mensagens reais.

2. Definir contratos e semântica

Interoperabilidade sintática significa conseguir ler a mensagem. Interoperabilidade semântica significa interpretar o dado da mesma forma em todos os sistemas.

O contrato deve estabelecer:

• cardinalidade e obrigatoriedade dos campos;
• formatos de data, unidade e precisão;
• sistemas de terminologia adotados;
• tratamento de valores ausentes;
• identificação de paciente, atendimento e profissional;
• regras para atualização, cancelamento e correção.

Quando possível, terminologias como LOINC, SNOMED CT e CID podem reduzir ambiguidades, respeitando licenciamento, escopo e adoção institucional. Códigos locais ainda podem existir, mas precisam de tabelas de correspondência versionadas e auditáveis.

No FHIR, também é necessário definir perfis, extensões, terminologias e operações permitidas. Expor um endpoint genérico sem um guia de implementação apenas transfere a ambiguidade para a API.

3. Tratar identidade e deduplicação

Um mesmo paciente pode possuir números diferentes no prontuário, laboratório e faturamento. Usar apenas nome e data de nascimento cria risco de associação incorreta.

A integração deve manter identificadores com seus respectivos emissores e, quando necessário, utilizar um índice mestre de pacientes. O processo de vinculação precisa combinar regras determinísticas, revisão humana para casos ambíguos e trilha de auditoria. Correspondências automáticas de baixa confiança não devem alterar registros clínicos silenciosamente.

Também é necessário garantir idempotência. Se uma mensagem for recebida duas vezes, o resultado esperado normalmente é uma única atualização, não dois exames, duas prescrições ou duas cobranças.

4. Executar testes em sombra

No modo sombra, a nova integração recebe uma cópia do tráfego real, mas ainda não controla o processo oficial. As saídas são comparadas com as do fluxo existente.

A validação deve medir pelo menos:

• percentual de mensagens processadas;
• mensagens rejeitadas por tipo de erro;
• latência média e percentis de cauda, como p95 e p99;
• divergências de código, unidade, status e identificação;
• duplicidades e eventos fora de ordem;
• tempo de recuperação após indisponibilidade.

Não existe uma meta universal. Os limites devem ser definidos conforme a criticidade clínica, o volume e o acordo operacional. Um painel administrativo tolera condições diferentes de um fluxo que entrega resultados usados em decisões assistenciais.

5. Fazer o corte por fluxo, não por hospital inteiro

A ativação pode começar por uma unidade, tipo de mensagem ou sistema consumidor. Exemplos: primeiro ADT para uma aplicação administrativa; depois resultados laboratoriais; por fim, fluxos com maior impacto clínico.

Durante a transição, é possível usar:

• dual write: envio para o destino antigo e para o novo;
• dual read: comparação entre duas fontes;
• feature flags: ativação por unidade ou grupo de usuários;
• canary: liberação para uma pequena parcela do tráfego;
• blue-green: ambientes alternáveis para retorno rápido.

O dual write exige cuidado: sucesso em um destino e falha no outro pode gerar divergência. Por isso, confirmação, reconciliação e reprocessamento precisam fazer parte do desenho.

6. Manter rollback e reconciliação

Rollback não é apenas restaurar uma versão do software. É saber quais mensagens foram processadas, quais ficaram pendentes e quais produziram efeitos irreversíveis.

Antes de cada corte, documente:

• condição objetiva para interromper a implantação;
• responsável por decidir o retorno;
• procedimento para redirecionar o tráfego;
• forma de reprocessar mensagens acumuladas;
• método de reconciliar origem e destino;
• canais de comunicação com equipes clínicas e administrativas.

Segurança, LGPD e rastreabilidade

Dados de saúde são dados pessoais sensíveis pela LGPD. A integração deve aplicar minimização, controle de acesso, finalidade definida e proteção durante transmissão e armazenamento.

Os controles técnicos incluem TLS, autenticação entre serviços, rotação de credenciais, segregação de ambientes, criptografia em repouso e registro de acesso. Logs não devem expor prontuários completos ou tokens; quando dados clínicos forem indispensáveis para suporte, o acesso precisa ser restrito e auditável.

Cada evento deve possuir um identificador de correlação que permita seguir o percurso sem depender da exposição integral do conteúdo. A auditoria deve responder: quem enviou, quando recebeu, qual transformação foi aplicada, quem consultou e qual foi o resultado.

Checklist antes de colocar a integração em produção

• [ ] Fluxos clínicos e dependências foram mapeados.
• [ ] Mensagens reais, inclusive segmentos personalizados, foram avaliadas.
• [ ] Perfis FHIR e tabelas de correspondência estão versionados.
• [ ] Identidade do paciente e idempotência foram testadas.
• [ ] Filas, retentativas e dead-letter queue estão operacionais.
• [ ] Há métricas de disponibilidade, latência, rejeição e backlog.
• [ ] O teste em sombra comparou resultados antigos e novos.
• [ ] O plano de rollback inclui reconciliação dos dados.
• [ ] Equipes assistenciais sabem como reportar inconsistências.
• [ ] Acesso, logs e retenção atendem às regras de segurança e LGPD.

Erros que mais aumentam o risco

Os problemas mais frequentes são integrar diretamente bancos de produção, tratar HL7 como um formato universal sem variações, ignorar códigos locais e migrar todos os fluxos em uma única janela. Outro erro é considerar o recebimento técnico como prova de sucesso: um ACK confirma determinada etapa do protocolo, mas não garante sozinho que o dado produziu o efeito clínico esperado.

Também é arriscado converter cada mensagem diretamente para FHIR sem preservar o conteúdo original. Manter o payload recebido, a versão do mapeamento e o resultado da transformação facilita auditoria, correção e reprocessamento.

Como a Predictor Solutions resolve isso

A Predictor Solutions, software house de Lavras, Minas Gerais, atua na integração de sistemas de saúde com HL7 v2 e FHIR. O trabalho combina inventário dos fluxos, desenho de contratos, adaptadores para legados, APIs FHIR, mensageria, observabilidade, testes em sombra, segurança e implantação gradual.

A empresa também desenvolve o Predictor Health, voltado a dashboards de saúde e wearables, e o Predictor AI Hospitals, direcionado à predição de sepse, infarto e pneumonia em UTI. Esses produtos exigem dados clínicos rastreáveis e integrações que preservem o funcionamento dos sistemas de origem.

No portfólio geral de projetos, a Predictor Solutions informa 9 empresas de médio e grande porte atendidas, economia média de R$ 1,32 milhão por cliente ao ano, aumento médio de produtividade de 70% e crescimento de lucro de 43% em seis meses. Esses resultados são agregados da atuação da empresa e não devem ser interpretados como garantia específica para um projeto de interoperabilidade; cada hospital depende de escopo, qualidade dos dados e maturidade operacional.

Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246