Conectar sistemas hospitalares legados sem interromper a operação exige uma arquitetura de integração gradual: HL7 v2 mantém os fluxos existentes, FHIR oferece uma camada moderna de APIs e um motor de integração traduz, valida e monitora as mensagens. A estratégia mais segura é executar interfaces antigas e novas em paralelo, começar com dados não críticos e só realizar a transição após validar integridade, desempenho e procedimentos de rollback.
Por que uma integração hospitalar não pode depender de uma grande virada
Hospitais operam prontuários, laboratórios, sistemas de imagem, farmácia, faturamento, dispositivos e aplicações administrativas que foram implantados em épocas diferentes. Alguns usam HL7 v2 por MLLP, outros trocam arquivos, consultam bancos de dados diretamente ou expõem APIs proprietárias.
Desligar essas integrações e substituí-las de uma vez cria riscos clínicos e operacionais. Uma falha pode impedir que uma alta seja registrada, que um resultado laboratorial chegue ao prontuário ou que uma prescrição seja processada.
A alternativa é o padrão conhecido como strangler pattern: a nova camada de interoperabilidade assume os fluxos progressivamente, sem exigir a substituição imediata dos sistemas de origem. Durante a transição, o legado continua funcionando como sistema de registro enquanto mensagens e eventos são replicados para a arquitetura nova.
Os princípios são:
- não alterar simultaneamente origem, transporte e destino;
- manter contratos de interface versionados;
- preservar identificadores clínicos e administrativos;
- executar processamento paralelo antes da transição;
- medir perdas, duplicidades, latência e erros semânticos;
- manter um caminho de retorno testado.
HL7 v2 e FHIR cumprem funções diferentes
HL7 v2 e FHIR não são concorrentes diretos. Em hospitais com sistemas legados, normalmente são usados em conjunto.
Onde o HL7 v2 continua necessário
HL7 v2 é amplamente utilizado para integração orientada a mensagens. Exemplos frequentes incluem:
- ADT: admissão, alta, transferência e atualização cadastral;
- ORM: solicitação de exames e procedimentos;
- ORU: envio de resultados e observações;
- SIU: agendamentos;
- DFT: transações financeiras.
As mensagens costumam ser transportadas por MLLP e confirmadas por respostas ACK. O integrador precisa tratar corretamente confirmações positivas e erros, incluindo códigos como AA, AE e AR, além de timeouts e retransmissões.
HL7 v2 não garante uniformidade apenas por estar presente. Versões, segmentos Z personalizados, campos opcionais e interpretações locais fazem com que duas interfaces ADT possam ter estruturas diferentes.
Onde o FHIR agrega valor
FHIR organiza os dados em recursos acessíveis por APIs HTTP, como Patient, Encounter, Observation, DiagnosticReport, ServiceRequest e MedicationRequest. Ele facilita o desenvolvimento de portais, aplicativos, dashboards, modelos de inteligência artificial e intercâmbio com plataformas modernas.
O padrão também suporta perfis, extensões, terminologias, operações, buscas e pacotes Bundle. Entretanto, instalar um servidor FHIR não resolve automaticamente a interoperabilidade. É necessário definir quais perfis serão aceitos, campos obrigatórios, identificadores, terminologias e regras de acesso.
Na prática, uma arquitetura comum recebe HL7 v2 do legado, valida a mensagem, converte seu conteúdo para um modelo canônico e publica recursos FHIR para os consumidores modernos.
Arquitetura recomendada para integração sem indisponibilidade
Uma arquitetura de transição deve separar os sistemas hospitalares da lógica de transformação. Os componentes principais são:
- Adaptadores de entrada: recebem HL7 v2, arquivos, eventos, APIs ou, quando inevitável, alterações de banco de dados.
- Motor de integração: roteia, transforma, valida e enriquece mensagens.
- Fila ou barramento: absorve picos e evita que a indisponibilidade de um destino bloqueie a origem.
- Modelo canônico: representa paciente, atendimento, exame e resultado de forma independente dos formatos proprietários.
- Servidor ou gateway FHIR: expõe recursos e aplica perfis de interoperabilidade.
- Camada de identidade: correlaciona identificadores de pacientes, atendimentos, profissionais e estabelecimentos.
- Observabilidade: registra métricas, logs, rastreamento e alertas.
- Fila de mensagens rejeitadas: preserva eventos que precisam de correção e reprocessamento.
A comunicação deve ser assíncrona sempre que a resposta imediata não for clinicamente necessária. Isso reduz o acoplamento e permite que um sistema fique temporariamente indisponível sem perder dados.
Consultar diretamente o banco do legado deve ser a última opção. Essa abordagem depende de estruturas internas não documentadas, pode aumentar a carga transacional e frequentemente ignora regras implementadas pela aplicação. Quando necessária, deve usar réplicas de leitura ou mecanismos controlados de captura de mudanças.
Plano de migração em seis etapas
1. Inventariar sistemas e fluxos
Registre origem, destino, protocolo, frequência, volume, criticidade, responsável e dependências de cada interface. O inventário deve responder quais fluxos podem tolerar atraso, quais exigem confirmação e quais afetam diretamente o cuidado do paciente.
Também é necessário identificar customizações, segmentos Z, tabelas locais, codificações de caracteres e regras não documentadas.
2. Definir contratos de dados
Para cada fluxo, produza um contrato com:
- evento de origem;
- versão e perfil HL7 utilizado;
- campos obrigatórios e opcionais;
- mapeamento para recursos FHIR;
- sistemas de terminologia;
- regras de identificação e deduplicação;
- comportamento diante de erros;
- limite aceitável de latência;
- política de reprocessamento.
O contrato deve ser versionado junto ao código. Mudanças incompatíveis precisam de uma nova versão, em vez de alterações silenciosas.
3. Implementar primeiro um fluxo de baixo risco
Começar por prescrições, resultados críticos ou altas hospitalares aumenta o impacto de qualquer erro. Um projeto inicial deve priorizar um fluxo representativo, mas com risco operacional controlável.
O objetivo é validar conectividade, transformação, autenticação, monitoramento e suporte antes de ampliar o escopo.
4. Executar em modo sombra
No modo sombra, o sistema novo recebe uma cópia dos eventos, mas não controla o processo principal. Suas saídas são comparadas às produzidas pela integração atual.
A comparação deve verificar:
- total de mensagens recebidas e processadas;
- campos obrigatórios ausentes;
- pacientes ou atendimentos não correlacionados;
- divergências de códigos e unidades;
- mensagens duplicadas;
- latência nos percentis relevantes;
- taxa de rejeição e reprocessamento.
A simples igualdade na contagem não é suficiente. Dez mil mensagens podem ter sido transportadas corretamente e ainda conter unidades, identificadores ou datas interpretados de modo errado.
5. Fazer a transição por consumidores
Após o processamento paralelo, migre um consumidor ou unidade por vez. Essa abordagem limita o raio de impacto e permite observar diferenças reais de carga e comportamento.
Durante a transição, preserve a possibilidade de retornar o roteamento ao caminho anterior. O rollback deve informar como tratar eventos processados durante a janela, evitando perda ou duplicidade.
6. Desativar com evidências
Uma interface antiga só deve ser removida quando houver evidências de estabilidade, documentação atualizada, alertas ativos e equipe treinada. Logs e artefatos necessários para auditoria devem seguir a política institucional de retenção.
Controles técnicos que evitam perda e duplicidade
A entrega de uma mensagem não significa que ela foi aplicada corretamente. Para aumentar a confiabilidade, implemente:
- idempotência: repetir o mesmo evento não pode criar resultados ou atendimentos duplicados;
- identificador de correlação: acompanha o evento da origem ao destino;
- confirmação funcional: diferencia recebimento técnico de processamento bem-sucedido;
- retries com espera progressiva: evita sobrecarregar um serviço indisponível;
- dead-letter queue: isola mensagens que excederam as tentativas;
- ordenação por entidade: preserva a sequência quando admissão e alta dependem uma da outra;
- reconciliação periódica: compara registros da origem e do destino;
- controle de versão: impede que mudanças de mapeamento alterem integrações existentes sem rastreabilidade.
Um painel operacional deve mostrar, no mínimo, mensagens por minuto, latência, erros por tipo, tamanho da fila, idade da mensagem mais antiga e quantidade de eventos aguardando intervenção.
Identidade, semântica e segurança são os maiores riscos
O erro mais perigoso não costuma ser uma conexão recusada, mas um dado tecnicamente válido associado ao paciente errado. A correlação deve considerar identificadores institucionais e regras explícitas. Nome e data de nascimento, isoladamente, não devem ser tratados como chave única.
A normalização semântica também exige atenção. Códigos locais de exames, medicamentos e procedimentos precisam ser mapeados para terminologias acordadas sem descartar o valor original. Unidades devem ser convertidas somente com regras verificáveis e rastreáveis.
Como dados de saúde são dados pessoais sensíveis segundo a LGPD, a integração deve aplicar:
- autenticação entre sistemas;
- autorização por função e finalidade;
- criptografia em trânsito e, quando aplicável, em repouso;
- segregação dos ambientes de desenvolvimento, homologação e produção;
- mascaramento ou dados sintéticos em testes;
- logs de auditoria sem exposição desnecessária de informações clínicas;
- rotação e armazenamento seguro de credenciais;
- definição de retenção e descarte.
Para APIs FHIR, OAuth 2.0 e OpenID Connect podem compor o controle de acesso, conforme a arquitetura adotada. Isso não substitui a autorização por recurso, escopo e contexto assistencial.
Checklist antes de colocar a integração em produção
- [ ] Todos os sistemas, responsáveis e dependências foram inventariados.
- [ ] O contrato HL7/FHIR está documentado e versionado.
- [ ] Há testes com mensagens válidas, inválidas, duplicadas e fora de ordem.
- [ ] Identificadores de paciente e atendimento foram reconciliados.
- [ ] Filas, retries, idempotência e reprocessamento foram testados.
- [ ] Métricas e alertas são acompanhados por uma equipe responsável.
- [ ] O modo sombra demonstrou equivalência técnica e semântica.
- [ ] O rollback foi executado em homologação.
- [ ] A segurança foi revisada de acordo com a LGPD.
- [ ] A operação sabe identificar, escalar e corrigir falhas.
Como a Predictor Solutions resolve isso
A Predictor Solutions atua na construção de sistemas de saúde com integração HL7 v2 e FHIR, engenharia de dados, cloud/DevOps e segurança. O trabalho começa pelo inventário dos fluxos e contratos, seguido da implementação de adaptadores, modelo canônico, filas, APIs FHIR, observabilidade e migração progressiva sem depender de uma substituição imediata do legado.
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 interoperáveis; por isso, validação semântica, segurança e monitoramento fazem parte da arquitetura, e não são etapas posteriores.
No conjunto de seus projetos de software e automação, a Predictor Solutions já atendeu 9 empresas de médio e grande porte, com resultados reportados de R$ 1,32 milhão de economia média por cliente ao ano, aumento médio de 70% na produtividade e crescimento de 43% no lucro em seis meses. Esses indicadores não substituem a avaliação específica de risco, escopo e retorno de cada integração hospitalar.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.