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 camada de interoperabilidade que mantenha os fluxos existentes em HL7 v2 enquanto disponibiliza dados por APIs FHIR. A estratégia mais segura combina levantamento de interfaces, normalização de identificadores, processamento idempotente, operação paralela, reconciliação e migração gradual por fluxo clínico.

Por que substituir tudo de uma vez é arriscado

Hospitais normalmente operam um ecossistema heterogêneo: HIS, prontuário eletrônico, LIS, RIS, PACS, farmácia, faturamento, monitorização, equipamentos e soluções departamentais. Alguns sistemas enviam mensagens HL7 v2 por MLLP; outros usam arquivos, banco compartilhado, SOAP ou protocolos proprietários.

Uma substituição abrupta cria riscos clínicos e operacionais porque integrações hospitalares não transportam apenas dados cadastrais. Elas movimentam admissões, altas, transferências, prescrições, solicitações de exames, resultados, alergias e informações utilizadas em decisões assistenciais.

“Não parar a operação” não significa ausência absoluta de risco. Significa evitar uma indisponibilidade planejada ampla por meio de coexistência, implantação incremental e mecanismos de retorno. A migração deve preservar o sistema atual até que o novo fluxo seja comprovadamente equivalente.

HL7 v2 e FHIR cumprem papéis diferentes

HL7 v2 continua amplamente utilizado para eventos dentro de hospitais. Mensagens como ADT, ORM, ORU e SIU representam, respectivamente, movimentações de pacientes, pedidos, resultados e agendamentos. O transporte pode ocorrer por MLLP sobre TCP, com confirmações ACK indicando aceitação ou erro.

FHIR organiza informações clínicas em recursos acessíveis principalmente por APIs HTTP. Entre os recursos mais comuns estão:

• Patient: paciente e identificadores;
• Encounter: atendimento, internação ou passagem;
• Observation: sinais vitais e resultados pontuais;
• DiagnosticReport: laudo ou conjunto de resultados;
• ServiceRequest: solicitação de exame ou procedimento;
• MedicationRequest: prescrição de medicamento;
• Appointment: agendamento;
• Organization e Practitioner: instituição e profissional.

FHIR não deve ser tratado como simples conversão de JSON. Ele define estrutura, terminologias, referências e regras de interoperabilidade. Também não elimina automaticamente o HL7 v2: em muitos projetos, HL7 v2 permanece como protocolo operacional e FHIR funciona como modelo canônico ou interface para novas aplicações.

Arquitetura recomendada para integração sem parada

Uma arquitetura resiliente separa os sistemas clínicos das regras específicas de cada consumidor. Em vez de criar conexões ponto a ponto, utiliza-se um mecanismo intermediário para receber, validar, transformar, rotear e monitorar os dados.

1. Adaptadores de entrada

Os adaptadores recebem mensagens por MLLP, APIs, filas, arquivos ou consultas controladas ao banco. Cada entrada deve preservar a mensagem original, o horário de recebimento, a origem e um identificador de correlação.

A conexão direta ao banco legado deve ser o último recurso. Quando inevitável, prefira réplicas de leitura ou captura de alterações — CDC — para reduzir bloqueios e dependência do esquema interno.

2. Motor de integração

O motor interpreta versões e variações locais do HL7 v2, aplica validações e encaminha mensagens. Dois sistemas que declaram usar HL7 v2.5.1 podem preencher segmentos, campos e códigos de formas diferentes; por isso, o acordo de interface precisa documentar os valores realmente utilizados.

Funções essenciais incluem:

• controle de ACK e timeout;
• repetição com backoff;
• fila de mensagens com erro;
• idempotência para evitar duplicidade;
• versionamento de transformações;
• trilha de auditoria;
• reprocessamento controlado.

3. Modelo canônico e servidor FHIR

Um modelo canônico reduz o número de transformações. Em vez de cada sistema compreender todos os demais, cada origem é convertida para um formato central, e cada destino consome esse formato.

FHIR pode exercer esse papel, mas é necessário definir perfis, extensões, terminologias e identificadores. O projeto deve informar, por exemplo, qual campo HL7 v2 origina Patient.identifier, como uma internação se torna Encounter e qual código representa cada tipo de exame.

4. Consumidores desacoplados

Dashboards, aplicativos, modelos de inteligência artificial e portais devem consumir APIs ou eventos sem depender diretamente do HIS. Esse desacoplamento permite modernizar novas funções sem alterar imediatamente os sistemas responsáveis pela operação principal.

Plano de migração em sete etapas

1. Inventariar os fluxos reais

Liste origem, destino, protocolo, frequência, volume, versão, criticidade, responsável e janela operacional de cada interface. Analise amostras reais anonimizadas: a documentação frequentemente diverge do tráfego de produção.

Classifique os fluxos em três níveis:

1. críticos para assistência imediata;
2. importantes para operação e faturamento;
3. analíticos ou administrativos tolerantes a atraso.

Comece por um fluxo de escopo controlado, não necessariamente pelo mais simples nem pelo mais crítico.

2. Definir a identidade do paciente

A associação incorreta de pacientes é um dos maiores riscos. CPF não pode ser presumido como identificador universal: pode estar ausente, incorreto ou compartilhado em cadastros temporários.

Defina um MPI — Master Patient Index — ou regras equivalentes, preservando número de prontuário, autoridade emissora e histórico de fusões. Correspondência probabilística pode apoiar revisão, mas não deve unir registros automaticamente sem critérios e governança compatíveis com o risco.

3. Criar contratos de interface

Para cada fluxo, documente:

• evento de origem e condição de disparo;
• campos obrigatórios e opcionais;
• códigos e terminologias;
• regras de transformação;
• resposta esperada;
• política de repetição;
• tratamento de cancelamento e correção;
• responsável por incidentes.

Use exemplos positivos, negativos e casos-limite. Uma interface de laboratório deve testar resultado corrigido, exame cancelado, unidade ausente e paciente com múltiplos identificadores.

4. Executar em modo sombra

No modo sombra, o novo pipeline recebe cópias do tráfego sem controlar o processo clínico. As saídas são comparadas com o sistema atual, permitindo identificar perdas, duplicidades, diferenças semânticas e problemas de ordenação.

A validação deve observar ao menos:

• 100% dos eventos críticos reconciliados;
• nenhuma duplicidade com efeito clínico;
• mensagens rejeitadas identificáveis e recuperáveis;
• latência dentro do limite definido com a área assistencial;
• rastreamento completo da origem ao destino.

Esses são critérios de aceite recomendados, não garantias automáticas do uso de HL7 ou FHIR.

5. Ativar por canário

Direcione uma unidade, setor, tipo de exame ou grupo controlado para o novo fluxo. Evite alterar simultaneamente cadastro, prescrição, laboratório e faturamento.

O canário precisa de um plano de rollback: chave de roteamento, versão anterior disponível, responsáveis de plantão e procedimento para reconciliar mensagens produzidas durante o retorno.

6. Expandir gradualmente

Após a estabilização, amplie por setor ou fluxo. Mantenha métricas comparáveis entre o legado e a nova integração. A expansão deve ser interrompida se houver perda de eventos, crescimento contínuo das filas ou divergências de identidade.

7. Desativar com evidência

Só remova a interface antiga depois do período acordado de operação paralela, da reconciliação e da aprovação clínica, técnica e operacional. Documente dependências remanescentes e preserve mensagens conforme as políticas legais e institucionais.

Segurança, LGPD e observabilidade

Dados de saúde são dados pessoais sensíveis segundo a LGPD. A integração deve aplicar controle de acesso por função, autenticação entre serviços, criptografia em trânsito e em repouso, gestão de segredos, auditoria e minimização de dados.

Ambientes de teste não devem receber bases produtivas sem anonimização ou proteção adequada. Logs também exigem cuidado: registrar mensagens HL7 completas pode expor nome, diagnóstico, documento e resultado de exame.

O painel operacional precisa mostrar:

• mensagens recebidas, processadas e rejeitadas;
• latência média e percentis, como p95 e p99;
• tamanho e idade das filas;
• taxa de ACK negativo e timeout;
• tentativas de reprocessamento;
• divergências de pacientes e códigos;
• disponibilidade por interface.

Alertas devem indicar impacto e contexto, não apenas “serviço indisponível”. Uma fila crescendo pode ser mais relevante que um processo tecnicamente ativo.

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

• [ ] Fluxos e responsáveis estão inventariados.
• [ ] Versões e particularidades do HL7 v2 foram documentadas.
• [ ] Perfis e recursos FHIR estão definidos.
• [ ] Identificadores de paciente e atendimento são consistentes.
• [ ] Duplicidades são neutralizadas por idempotência.
• [ ] ACK, timeout, repetição e fila de erro foram testados.
• [ ] Correções, cancelamentos e mensagens fora de ordem foram simulados.
• [ ] Há correlação ponta a ponta e auditoria.
• [ ] Dados sensíveis estão protegidos nos logs.
• [ ] Modo sombra e reconciliação foram concluídos.
• [ ] O rollback foi testado, não apenas documentado.
• [ ] Equipes clínica, operacional, segurança e infraestrutura aprovaram a mudança.

Principais trade-offs

Usar FHIR como modelo canônico facilita APIs e aplicações modernas, mas exige governança de perfis e terminologias. Manter HL7 v2 reduz mudanças nos sistemas atuais, porém preserva variações locais e limitações semânticas.

Processamento síncrono oferece resposta imediata, mas aumenta o acoplamento e o efeito de indisponibilidades. Filas assíncronas absorvem picos e facilitam repetição, porém exigem tratamento de mensagens fora de ordem e consistência eventual.

Construir conectores internamente oferece controle, mas transfere para a equipe a manutenção de versões, segurança e observabilidade. Adotar um motor de integração acelera funções comuns, embora não elimine o trabalho de mapear regras clínicas específicas.

Como a Predictor Solutions resolve isso

A Predictor Solutions projeta integrações hospitalares com HL7 v2 e FHIR usando inventário de interfaces, contratos versionados, mecanismos de idempotência, filas, observabilidade, testes de reconciliação e ativação gradual. A empresa também desenvolve sistemas de saúde como o Predictor Health, voltado a dashboards e wearables, e o Predictor AI Hospitals, direcionado à predição de sepse, infarto e pneumonia em UTI.

A abordagem combina engenharia de software, dados, cloud/DevOps e segurança ofensiva para evitar que interoperabilidade seja tratada apenas como conversão de mensagens. Nos projetos da software house, os resultados gerais registrados incluem 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 70% em produtividade e crescimento de 43% no lucro em seis meses; o resultado de cada integração depende do escopo, da infraestrutura e da maturidade operacional.

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