Para conectar sistemas hospitalares legados sem interromper a operação, mantenha os fluxos HL7 v2 existentes, introduza uma camada de interoperabilidade e exponha novos serviços em FHIR de forma gradual. A migração segura usa execução paralela, mensagens idempotentes, reconciliação de dados, monitoramento clínico e técnico, além de rollback testado antes de cada mudança.
Por que substituir tudo de uma vez é arriscado
Hospitais normalmente operam uma combinação de HIS, prontuário eletrônico, LIS, RIS, PACS, ERP, farmácia, faturamento, equipamentos médicos e aplicações departamentais. Esses componentes podem usar bancos antigos, arquivos, APIs proprietárias ou mensagens HL7 v2 transmitidas por MLLP.
Uma troca completa em uma única janela cria riscos difíceis de controlar:
- indisponibilidade de cadastro, prescrição ou resultados;
- duplicação ou perda de eventos clínicos;
- associação de exame ao paciente errado;
- quebra de integrações não documentadas;
- divergências entre faturamento e assistência;
- ausência de rollback quando o novo sistema recebe dados reais.
Em ambiente hospitalar, “não parar a operação” não significa eliminar toda manutenção. Significa evitar que a implantação interrompa processos assistenciais críticos e garantir contingência para cadastro, atendimento, prescrição, exames e alta.
A estratégia mais segura é semelhante ao padrão strangler: integrações novas passam por uma camada intermediária, enquanto os fluxos antigos são substituídos individualmente. O legado permanece ativo até que cada novo fluxo seja validado.
HL7 v2 e FHIR cumprem papéis diferentes
HL7 v2 continua amplamente utilizado para eventos operacionais. Mensagens como ADT, ORM, ORU e SIU comunicam admissões, pedidos, resultados e agendamentos. Em geral, são enviadas por MLLP, embora existam implementações baseadas em arquivos, filas e outros transportes.
FHIR organiza informações em recursos reutilizáveis, como Patient, Encounter, Observation, Condition, DiagnosticReport e MedicationRequest. Esses recursos podem ser acessados por APIs REST, mensagens, documentos ou operações definidas pelo padrão.
FHIR não deve ser tratado apenas como “HL7 em JSON”. Há diferenças importantes:
- HL7 v2 é orientado principalmente a mensagens e eventos;
- FHIR possui modelo de recursos e regras de pesquisa;
- extensões FHIR exigem governança para evitar incompatibilidade;
- terminologias clínicas precisam ser preservadas durante o mapeamento;
- versões e perfis FHIR devem ser declarados explicitamente.
Na prática, HL7 v2 e FHIR costumam coexistir. Um HIS pode continuar emitindo ADT enquanto uma camada de interoperabilidade converte o evento em recursos Patient e Encounter para aplicações mais recentes.
Arquitetura recomendada para integração sem interrupção
A arquitetura deve desacoplar os sistemas de origem e destino. Conexões diretas em malha aumentam a quantidade de dependências: cinco sistemas integrados entre si podem exigir até dez conexões bilaterais diferentes.
1. Camada de interoperabilidade
Um motor de integração ou serviço equivalente recebe, valida, transforma e roteia mensagens. Essa camada pode oferecer:
- listeners MLLP para HL7 v2;
- conectores para bancos, arquivos, filas e APIs;
- validação estrutural e semântica;
- transformação entre versões e formatos;
- API FHIR com perfis definidos;
- filas de erro e reprocessamento controlado;
- trilha de auditoria com correlação ponta a ponta.
O motor não corrige sozinho problemas de semântica. É necessário documentar, por exemplo, se PID-3 contém o identificador hospitalar, CPF ou outro código e qual autoridade atribuidora é responsável pelo valor.
2. Modelo canônico com limites claros
Um modelo intermediário pode reduzir transformações repetidas, mas não deve tentar representar todo o hospital em uma estrutura genérica. O ideal é começar pelos dados necessários para cada caso de uso.
Para um fluxo de resultados laboratoriais, o escopo inicial pode incluir paciente, atendimento, pedido, amostra, exame, resultado, unidade, intervalo de referência e status. Diagnósticos, prescrições e faturamento podem permanecer fora até serem necessários.
3. Filas e persistência temporária
Filas absorvem picos e permitem que o destino fique temporariamente indisponível sem perder eventos. Cada mensagem deve ter:
- identificador único;
- data e hora de origem e recebimento;
- sistema produtor;
- versão do esquema;
- número de tentativas;
- estado de processamento;
- chave de correlação clínica.
A retenção precisa respeitar necessidade operacional, política institucional e LGPD. O conteúdo clínico não deve aparecer integralmente em logs comuns.
Plano de implantação em etapas
Etapa 1: inventariar os fluxos reais
Não basta listar sistemas. Registre origem, destino, protocolo, frequência, volume, criticidade, proprietário técnico e responsável clínico. Capture exemplos anonimizados das mensagens e identifique variações locais.
Classifique cada fluxo:
- crítico: falha afeta imediatamente assistência ou segurança;
- alto: operação manual é possível por pouco tempo;
- moderado: atraso controlado é aceitável;
- baixo: processamento pode ser reagendado.
Etapa 2: escolher um fluxo piloto reversível
Evite começar por prescrição, administração de medicamentos ou identificação principal do paciente. Um fluxo de leitura, como distribuição secundária de resultados, tende a permitir validação paralela com menor impacto.
Defina critérios mensuráveis antes da implantação:
- 100% das mensagens recebidas devem ser contabilizadas;
- nenhuma mensagem pode desaparecer sem estado final;
- duplicidades devem ser detectadas e tratadas;
- campos clínicos críticos devem manter equivalência;
- latência máxima deve atender ao processo assistencial;
- o rollback precisa ser executável sem reconstrução improvisada.
Etapa 3: executar em modo sombra
No modo sombra, o novo fluxo recebe uma cópia dos eventos, mas ainda não controla o processo oficial. As saídas são comparadas com o sistema atual.
A validação deve conferir contagem de registros, pacientes, atendimentos, códigos, unidades, datas, status e resultados. Comparar apenas o total de mensagens é insuficiente: duas mensagens podem chegar e ainda assim estar associadas ao atendimento errado.
Etapa 4: liberar por escopo
Ative por unidade, tipo de mensagem, laboratório, convênio ou grupo de usuários. Evite liberar todos os setores simultaneamente.
Uma progressão possível é:
- ambiente de teste com dados sintéticos;
- homologação com amostras anonimizadas;
- sombra em produção;
- produção limitada a uma unidade;
- ampliação após período de estabilidade;
- desativação do fluxo antigo somente após reconciliação.
Etapa 5: retirar o legado com evidências
O fluxo antigo só deve ser removido depois que não houver dependências ocultas, a retenção estiver definida e a equipe tiver evidências de completude. Mantenha documentação do mapeamento e do procedimento de restauração.
Idempotência, ACK e prevenção de duplicidades
Redes falham, conexões expiram e sistemas reenviam mensagens quando não recebem confirmação. Por isso, “receber duas vezes e processar duas vezes” não pode ser o comportamento padrão.
Em HL7 v2, os ACKs precisam refletir o resultado correto: aceitação, erro ou rejeição. Confirmar antes de persistir com segurança pode causar perda; confirmar tarde demais pode aumentar reenvios. A decisão depende do contrato definido entre remetente e receptor.
Em FHIR, operações de criação sem controle também podem gerar recursos duplicados. Identificadores de negócio, buscas condicionais e regras de atualização devem ser definidos conforme o caso de uso.
Uma chave idempotente pode combinar identificador da mensagem, sistema de origem e evento. Entretanto, usar apenas o número de controle é perigoso quando sistemas reiniciam contadores ou reutilizam valores.
Segurança, LGPD e rastreabilidade
A integração amplia a superfície de ataque porque conecta sistemas antes isolados. Os controles mínimos incluem:
- TLS nos transportes compatíveis e rede segregada para conexões antigas;
- autenticação entre sistemas e rotação de credenciais;
- menor privilégio para contas de serviço;
- criptografia em repouso para filas e armazenamento temporário;
- auditoria de acesso e alteração;
- mascaramento de dados em logs e ambientes não produtivos;
- definição de controlador, operador, finalidade e retenção conforme a LGPD;
- plano de resposta a incidentes e revogação de acessos.
Logs técnicos devem permitir responder “qual evento entrou, como foi transformado e onde falhou” sem expor dados desnecessários. Identificadores de correlação podem ligar os registros técnicos ao evento clínico sob acesso controlado.
Checklist para a virada de produção
Antes de ativar o novo fluxo, confirme:
- [ ] mapeamento aprovado por responsáveis técnicos e assistenciais;
- [ ] perfis, versões e extensões FHIR documentados;
- [ ] mensagens HL7 v2 inválidas encaminhadas para fila de erro;
- [ ] reprocessamento idempotente testado;
- [ ] relógios dos servidores sincronizados;
- [ ] painéis monitoram volume, latência, erros e filas;
- [ ] alertas têm responsáveis e critérios de escalonamento;
- [ ] contingência manual está documentada;
- [ ] rollback foi ensaiado;
- [ ] reconciliação pós-implantação tem responsável e prazo;
- [ ] dados sensíveis não aparecem em observabilidade inadequada;
- [ ] critérios objetivos de sucesso e interrupção estão registrados.
O principal trade-off é velocidade versus controle. Uma virada única parece mais rápida, mas concentra riscos. Uma migração gradual exige operação temporária de dois caminhos, porém oferece comparação, aprendizagem e reversão.
Como a Predictor Solutions resolve isso
A Predictor Solutions projeta integrações para saúde com HL7 v2 e FHIR, começando pelo inventário dos fluxos, contratos de dados e riscos assistenciais. A implementação combina camada de interoperabilidade, APIs, transformação de mensagens, filas, observabilidade, testes de idempotência, execução em sombra e implantação progressiva.
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. Essa atuação exige tratar interoperabilidade como engenharia operacional e clínica, não apenas como conversão de formatos.
A Predictor Solutions, sediada em Lavras, Minas Gerais, já atendeu 9 empresas de médio e grande porte. Em seu conjunto de projetos de software, automação, dados e inteligência artificial, registra R$ 1,32 milhão de economia média por cliente ao ano, aumento médio de produtividade de 70% e crescimento de lucro de 43% em seis meses; esses indicadores não devem ser interpretados como resultado automático de uma integração hospitalar específica.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.