Integrar sistemas hospitalares legados sem interromper a operação exige uma arquitetura intermediária que receba HL7 v2, APIs FHIR, arquivos e eventos proprietários, normalize os dados e os distribua com rastreabilidade. A abordagem mais segura é implantar a integração em paralelo, validar mensagens com dados reais controlados e migrar cada fluxo gradualmente, mantendo possibilidade de rollback.
Por que a integração hospitalar não pode ser uma troca abrupta
Hospitais operam com prontuário eletrônico, laboratório, radiologia, farmácia, faturamento, leitos e equipamentos que evoluíram em momentos diferentes. Um sistema pode enviar mensagens HL7 v2 por MLLP, outro expor uma API REST e um terceiro depender de arquivos CSV, compartilhamentos de rede ou rotinas agendadas.
Substituir tudo de uma vez cria riscos clínicos e operacionais. Uma indisponibilidade pode impedir o acesso a resultados, atrasar a dispensação de medicamentos ou produzir cadastros duplicados. Por isso, a meta não deve ser apenas “fazer os sistemas conversarem”, mas preservar quatro propriedades:
- Continuidade: o sistema de origem continua funcionando durante a implantação.
- Consistência: o mesmo paciente, atendimento e exame precisam ser identificados entre aplicações.
- Rastreabilidade: cada mensagem deve ter origem, destino, horário, estado e histórico de processamento.
- Recuperação: falhas precisam gerar repetição controlada ou encaminhamento para análise, sem perda silenciosa.
O primeiro passo é mapear os fluxos existentes antes de escolher tecnologias. Para cada integração, registre sistema de origem e destino, protocolo, volume médio e de pico, latência aceitável, criticidade clínica, responsável e procedimento manual usado quando o fluxo falha.
HL7 v2 e FHIR cumprem papéis diferentes
Onde o HL7 v2 continua relevante
O HL7 v2 é amplamente usado em integrações hospitalares orientadas a mensagens. Eventos como admissão, transferência e alta costumam ser representados por mensagens ADT; solicitações e resultados podem usar famílias como ORM e ORU, dependendo da versão e da implementação local.
Na prática, duas aplicações que declaram suporte ao HL7 v2 não são automaticamente compatíveis. Campos opcionais, códigos locais, versões e segmentos personalizados variam. É necessário produzir um perfil de integração que documente:
- versão usada, como 2.3, 2.4 ou 2.5.1;
- tipos de mensagem e eventos aceitos;
- campos obrigatórios e regras condicionais;
- tabelas de códigos e unidades;
- segmentos personalizados, normalmente identificados pela letra Z;
- comportamento de ACK, timeout e reenvio.
O MLLP é um transporte comum para mensagens HL7 v2 em conexões TCP persistentes. Ele é simples, mas não resolve sozinho criptografia, autenticação, retenção, monitoramento ou reprocessamento. Esses controles devem ser implementados na rede, no motor de integração ou em componentes adicionais.
Onde o FHIR ajuda
O FHIR organiza informações clínicas e administrativas em recursos, como Patient, Encounter, Observation, Condition e MedicationRequest. Esses recursos podem ser acessados por APIs HTTP, pesquisados e combinados em fluxos modernos para aplicativos, portais, analytics e serviços de inteligência artificial.
FHIR não significa apenas transformar uma mensagem HL7 v2 em JSON. A integração precisa definir perfis, terminologias, cardinalidades, referências e regras de validação. A especificação oficial está disponível em hl7.org/fhir, mas cada projeto ainda deve estabelecer seu guia de implementação.
Uma estratégia comum é manter HL7 v2 na borda dos sistemas antigos e usar FHIR como contrato para novos serviços. Isso evita exigir que o legado seja alterado imediatamente.
Arquitetura para integrar sem parar o hospital
Uma arquitetura resiliente normalmente contém seis camadas:
- Adaptadores de entrada: recebem HL7 v2/MLLP, APIs, arquivos ou eventos proprietários.
- Persistência inicial: registra o conteúdo recebido antes de qualquer transformação relevante.
- Validação: verifica estrutura, campos obrigatórios, códigos e regras de negócio.
- Modelo canônico: representa pacientes, atendimentos, exames e observações de forma independente do fornecedor.
- Distribuição assíncrona: filas ou streams desacoplam origem e destino e absorvem picos.
- Observabilidade: métricas, logs correlacionados, alertas e painéis mostram o estado de cada fluxo.
O modelo canônico reduz transformações ponto a ponto. Sem ele, cinco sistemas podem exigir até 20 conexões direcionais distintas. Com uma camada intermediária, cada aplicação mantém contratos de entrada e saída mais previsíveis. O custo é a necessidade de governar o modelo e evitar que ele se torne amplo ou abstrato demais.
Identidade, idempotência e ordenação
O identificador do paciente é um dos maiores pontos de risco. CPF não deve ser presumido como identificador clínico universal, pois pode estar ausente, incorreto ou compartilhado indevidamente. A solução precisa preservar identificadores locais e manter uma tabela de correspondência, idealmente com regras de reconciliação e revisão humana para casos ambíguos.
Também é necessário definir uma chave de idempotência. Uma mensagem reenviada após timeout não pode gerar uma segunda internação ou duplicar um resultado. A chave pode combinar identificador da mensagem, sistema emissor e versão do evento, desde que o comportamento esteja formalizado.
Nem todo fluxo exige ordenação global. Entretanto, eventos referentes ao mesmo atendimento podem precisar ser processados na sequência correta. Particionar filas por paciente ou atendimento ajuda a manter ordem sem serializar todo o hospital.
Plano de migração em sete etapas
1. Inventariar e classificar
Classifique cada interface por impacto clínico, volume e tolerância à indisponibilidade. Comece por um fluxo observável e reversível, não pelo processo mais crítico.
2. Capturar uma linha de base
Meça antes da mudança: mensagens por minuto, latência, falhas, duplicações e tempo de resolução. Sem linha de base, não há como provar que a nova integração é melhor ou identificar regressões.
3. Criar testes de contrato
Monte exemplos válidos e inválidos, remova ou anonimize dados pessoais quando possível e teste campos ausentes, códigos desconhecidos, mensagens duplicadas e destinos indisponíveis. Dados sintéticos ajudam, mas não substituem a validação de variações encontradas na operação real.
4. Executar em modo sombra
No modo sombra, a nova plataforma recebe uma cópia dos eventos, processa e compara resultados, mas não controla o fluxo oficial. Divergências são analisadas sem afetar o atendimento.
5. Fazer dupla escrita com cautela
Quando necessário, envie dados ao caminho antigo e ao novo por um período limitado. Defina qual sistema é a fonte de verdade; caso contrário, correções concorrentes podem divergir. Dupla escrita prolongada aumenta a complexidade e deve ter critério explícito de encerramento.
6. Migrar por fluxo e unidade
Ative primeiro um tipo de mensagem, setor ou unidade. Monitore latência, ACKs negativos, fila acumulada e reconciliação. Só amplie quando os critérios de aceite forem atendidos.
7. Manter rollback operacional
Rollback não é apenas restaurar uma versão. Ele precisa indicar como redirecionar mensagens, reprocessar eventos acumulados e reconciliar alterações feitas durante a janela de retorno.
Checklist técnico antes de entrar em produção
- [ ] Perfis HL7 v2 ou FHIR versionados e aprovados pelos responsáveis dos sistemas.
- [ ] Timeouts, ACKs, reenvios e limite de tentativas definidos.
- [ ] Idempotência testada com mensagens repetidas.
- [ ] Fila de mensagens não processadas, com motivo e procedimento de reprocessamento.
- [ ] Logs sem exposição desnecessária de dados pessoais ou clínicos.
- [ ] Criptografia em trânsito e em repouso conforme a arquitetura.
- [ ] Acesso por menor privilégio e trilha de auditoria.
- [ ] Alertas para aumento de latência, erros e ausência inesperada de mensagens.
- [ ] Backup, restauração e recuperação de desastre testados.
- [ ] Plano de contingência compreendido pelas equipes clínica, operacional e de TI.
Segurança e LGPD na interoperabilidade
Dados de saúde são dados pessoais sensíveis segundo a LGPD. A integração deve limitar coleta, acesso, retenção e compartilhamento ao necessário para a finalidade definida. Ambientes de desenvolvimento e homologação não devem receber cópias integrais da produção sem controles adequados.
Segredos precisam ficar fora do código-fonte. APIs devem usar autenticação e autorização compatíveis com o risco; conexões legadas podem exigir segmentação de rede, VPN ou gateways protegidos. Logs devem registrar identificadores técnicos suficientes para investigação, evitando armazenar o conteúdo clínico completo por conveniência.
O controle técnico não substitui governança. Hospital, fornecedores e operadores precisam definir responsabilidades, bases legais, prazos de retenção e resposta a incidentes.
Como a Predictor Solutions resolve isso
A Predictor Solutions, software house de Lavras, Minas Gerais, projeta sistemas de saúde com integração HL7 v2 e FHIR. O trabalho envolve descoberta dos fluxos, definição de contratos, adaptadores para sistemas legados, mensageria, modelo canônico, testes automatizados, observabilidade, cloud/DevOps e controles de segurança.
A empresa também desenvolve o Predictor Health, dashboard de saúde integrado a wearables, e o Predictor AI Hospitals, voltado à predição de sepse, infarto e pneumonia em UTI. Em seus projetos de software, a Predictor Solutions informa ter atendido nove empresas de médio e grande porte, com 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 e dependem do contexto de cada operação.
O objetivo em interoperabilidade é migrar por etapas, manter o legado funcionando e criar uma base verificável para novos portais, automações, analytics e aplicações de IA.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246