Conectar sistemas hospitalares legados sem parar a operação exige uma camada de interoperabilidade que mantenha os sistemas atuais funcionando enquanto traduz, valida e distribui dados em HL7 v2, FHIR ou formatos proprietários. A abordagem mais segura combina implantação incremental, processamento assíncrono, operação paralela, reconciliação de dados e possibilidade real de rollback.
Por que uma integração hospitalar não pode depender de uma virada única
Em hospitais, uma indisponibilidade não afeta apenas produtividade: pode impedir acesso a alergias, resultados laboratoriais, prescrições, leitos e dados de identificação. Por isso, substituir todas as interfaces em uma única janela de implantação — o chamado big bang — costuma representar risco desnecessário.
O cenário mais comum contém uma combinação de:
- HIS ou sistema de gestão hospitalar legado;
- prontuário eletrônico do paciente, ou PEP;
- sistemas laboratoriais LIS;
- sistemas de radiologia RIS e PACS;
- farmácia, faturamento, prescrição e gestão de leitos;
- equipamentos que enviam dados em protocolos proprietários;
- mensagens HL7 v2 em versões e perfis diferentes;
- APIs REST recentes, mas sem modelo clínico padronizado;
- bancos de dados acessados por arquivos, views ou integrações ponto a ponto.
O objetivo inicial não deve ser “modernizar tudo”. Primeiro, é necessário garantir que cada evento clínico chegue ao destino correto, uma única vez, com identidade, significado e rastreabilidade preservados.
O papel de HL7 v2 e FHIR na arquitetura
HL7 v2 e FHIR não precisam competir. Em uma transição bem planejada, ambos podem operar simultaneamente.
Onde o HL7 v2 continua relevante
HL7 v2 é amplamente usado para eventos hospitalares e comunicação entre sistemas internos. Exemplos comuns incluem:
- ADT para admissão, transferência e alta;
- ORM ou OML para pedidos;
- ORU para resultados e observações;
- SIU para agendamentos;
- mensagens financeiras, conforme o fluxo implementado.
As mensagens geralmente trafegam por MLLP sobre TCP, embora arquivos e outros transportes também existam. O recebimento deve produzir ACK ou NACK, mas um ACK técnico apenas confirma o processamento acordado entre as partes; ele não substitui a validação clínica ou a confirmação de que todos os sistemas downstream foram atualizados.
Também não basta declarar suporte a “HL7 v2”. É preciso registrar versão, tipo de mensagem, evento, segmentos obrigatórios, códigos, campos customizados e comportamento esperado diante de erros.
Onde o FHIR agrega valor
FHIR organiza informações em recursos como Patient, Encounter, Observation, Condition, MedicationRequest e DiagnosticReport. Esses recursos podem ser acessados por APIs REST, pesquisas, operações e outros mecanismos previstos pelo padrão.
FHIR é especialmente útil para:
- expor uma API clínica padronizada;
- integrar aplicativos, portais e plataformas analíticas;
- reduzir dependência do banco interno do fornecedor;
- controlar acesso por recurso e contexto;
- construir novos serviços sem alterar imediatamente o sistema legado.
Ainda assim, uma API só é interoperável quando existe um contrato claro. Versão FHIR, perfis, terminologias, cardinalidades, extensões, códigos HTTP e regras de busca precisam ser definidos. “JSON compatível com FHIR” não garante interoperabilidade sem validação contra os perfis adotados.
Arquitetura para migrar sem interromper o hospital
A estratégia recomendada segue o padrão strangler: novas capacidades são construídas ao redor do legado e assumem fluxos gradualmente. O sistema antigo permanece ativo até que o novo caminho demonstre estabilidade e completude.
Uma arquitetura típica possui cinco componentes.
1. Adaptadores de entrada
Cada sistema se conecta por um adaptador compatível com sua realidade: MLLP, API, arquivo, fila, leitura controlada de banco ou outro protocolo autorizado. O adaptador deve separar transporte de regra clínica, evitando que mudanças de conexão contaminem todo o fluxo.
2. Motor de integração
O motor recebe, valida, transforma e roteia mensagens. Ele também deve preservar a mensagem original, gerar identificadores de correlação e impedir que uma falha temporária resulte em perda silenciosa.
3. Modelo canônico
Um modelo intermediário reduz o número de transformações. Em vez de criar conversores exclusivos entre cada par de sistemas, cada origem é traduzida para o modelo canônico, e cada destino recebe sua transformação específica.
FHIR pode compor esse modelo, mas nem todo dado legado possui correspondência direta e imediata. Extensões, tabelas de mapeamento e regras de proveniência devem ser governadas para evitar perda semântica.
4. Filas e processamento assíncrono
Filas desacoplam os sistemas e absorvem picos. Se o LIS ficar indisponível, por exemplo, eventos podem permanecer retidos e ser reenviados depois, dentro dos limites operacionais definidos.
Para isso funcionar, consumidores precisam ser idempotentes. O reprocessamento do mesmo evento não pode criar duas internações, duplicar uma observação ou repetir uma cobrança.
5. Observabilidade e trilha de auditoria
A equipe precisa responder rapidamente:
- qual sistema originou o evento;
- quando ele foi recebido;
- quais transformações foram aplicadas;
- quais destinos confirmaram o processamento;
- por que uma mensagem falhou;
- se houve reenvio ou intervenção manual.
Logs técnicos, métricas e rastreamento devem usar identificadores de correlação, mas não devem expor dados clínicos desnecessários. O acesso à trilha precisa ser controlado e auditável.
Plano de implantação em sete etapas
1. Inventariar os fluxos reais
Mapeie sistemas, responsáveis, versões, transportes, volume, latência aceitável, janelas críticas e consequências de falha. Compare documentação com tráfego real: interfaces antigas frequentemente contêm campos customizados não registrados.
2. Classificar criticidade
Separe os fluxos por impacto. Admissão, alergias, medicação e resultados críticos demandam controles diferentes de relatórios administrativos. Defina RTO, RPO e procedimento de contingência para cada grupo, em vez de usar uma meta genérica para todo o hospital.
3. Formalizar contratos
Para cada interface, documente:
- origem e destino;
- evento disparador;
- versão HL7 ou FHIR;
- campos obrigatórios e opcionais;
- terminologias e unidades;
- identificadores de paciente e atendimento;
- ACK, códigos de erro e política de repetição;
- regras de deduplicação e reconciliação.
4. Testar com dados representativos
Os testes devem incluir acentos, homônimos, pacientes sem documento, alterações cadastrais, resultados corrigidos, mensagens fora de ordem, campos vazios, duplicidades, indisponibilidade de rede e grande volume. Dados reais só devem ser usados quando houver base legal, controle de acesso e proteção adequados; ambientes de teste devem preferir dados sintéticos ou devidamente desidentificados.
5. Executar em modo sombra
No modo sombra, a nova integração recebe uma cópia dos eventos, mas ainda não controla o processo assistencial. As saídas são comparadas com o caminho vigente para medir divergências sem afetar usuários.
Critérios de avanço podem incluir taxa de mensagens válidas, ausência de perda, latência por percentil, consistência dos identificadores e conclusão da reconciliação. Os limites devem ser definidos conforme a criticidade do fluxo, não por um percentual universal.
6. Fazer um rollout progressivo
Ative primeiro uma unidade, tipo de evento ou destino de menor risco. Mantenha o caminho anterior disponível até que o novo fluxo cumpra os critérios acordados durante um período representativo, incluindo trocas de plantão e picos de atendimento.
7. Desativar com evidências
Uma interface antiga só deve ser removida depois da reconciliação e da aprovação conjunta das áreas clínica, operacional e técnica. Preserve documentação, trilhas exigidas e procedimento de restauração conforme a política institucional.
Checklist para entrada em produção
Antes do corte de qualquer fluxo, confirme:
- [ ] contratos HL7/FHIR versionados e aprovados;
- [ ] identificação de paciente e atendimento validada;
- [ ] mensagens duplicadas tratadas com idempotência;
- [ ] filas, retentativas e fila de mensagens com falha configuradas;
- [ ] alertas para latência, erro e acúmulo de mensagens;
- [ ] reconciliação entre origem e destino automatizada quando possível;
- [ ] rollback testado, e não apenas documentado;
- [ ] contingência clínica conhecida pelos plantões;
- [ ] permissões baseadas no menor privilégio;
- [ ] criptografia em trânsito e proteção dos segredos;
- [ ] retenção de logs compatível com LGPD e políticas internas;
- [ ] fornecedores e responsáveis disponíveis durante a implantação.
Trade-offs que precisam ser decididos
Tempo real versus processamento assíncrono: eventos clínicos urgentes podem exigir baixa latência, enquanto cargas históricas funcionam melhor em lote. Exigir tempo real para tudo aumenta custo e acoplamento.
FHIR nativo versus tradução: substituir imediatamente todos os modelos pelo FHIR pode alongar o projeto. Uma camada de tradução acelera a coexistência, mas precisa de governança para não se tornar um conjunto opaco de regras.
Consistência imediata versus eventual: filas aumentam resiliência, porém alguns destinos podem ficar temporariamente defasados. O limite tolerável deve ser explícito por fluxo.
Leitura de banco versus interface oficial: acessar tabelas pode parecer rápido, mas cria dependência do esquema interno, risco de segurança e problemas em atualizações. Deve ser exceção controlada quando não houver interface suportada.
Comprar versus desenvolver: motores prontos aceleram conectividade e operação; desenvolvimento sob medida oferece flexibilidade. A decisão deve considerar licenciamento, suporte, competência interna, volume, observabilidade e custo de manutenção por vários anos.
Segurança e LGPD na interoperabilidade
Dados de saúde são dados pessoais sensíveis. A arquitetura deve aplicar minimização, segregação de ambientes, controle de acesso, auditoria, gestão de segredos e criptografia. Também é necessário definir base legal, finalidade, retenção e responsabilidades entre hospital e fornecedores com apoio jurídico e do encarregado de dados.
Não registre payloads clínicos completos indiscriminadamente. Quando o conteúdo for necessário para suporte ou auditoria, aplique acesso restrito, mascaramento quando possível, prazo de retenção e registro de consulta. Backups e filas também fazem parte do perímetro de proteção.
Como a Predictor Solutions resolve isso
A Predictor Solutions atua como praticante em integrações de saúde com HL7 v2 e FHIR, combinando engenharia de software, dados, cloud/DevOps e segurança. O trabalho começa pelo inventário das interfaces e dos riscos clínicos, seguido por contratos versionados, adaptadores, filas, observabilidade, testes de carga e implantação progressiva sem exigir a 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. Essa experiência exige tratar interoperabilidade não apenas como conversão de formato, mas como garantia de identidade, contexto clínico, qualidade, proveniência e disponibilidade.
Em seu conjunto de projetos de software, dados e automação, a Predictor Solutions atende 9 empresas de médio e grande porte, com resultados informados 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. Em integração hospitalar, qualquer meta deve ser validada separadamente conforme sistemas, volume, infraestrutura e criticidade assistencial.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.