Conectar sistemas hospitalares legados sem interromper a operação exige uma camada de interoperabilidade que permita a coexistência entre HL7 v2, FHIR e formatos proprietários. A abordagem mais segura é migrar por fluxos, manter processamento paralelo, validar dados clínicos e preparar reversão antes de substituir qualquer interface em produção.
Por que integrações hospitalares não podem ser tratadas como APIs comuns
Em um hospital, uma falha de integração pode impedir a atualização de uma prescrição, atrasar a liberação de um resultado laboratorial ou criar divergências no cadastro do paciente. O problema não é apenas técnico: afeta continuidade assistencial, faturamento, auditoria e segurança do paciente.
Ambientes hospitalares costumam combinar:
- HIS ou ERP hospitalar;
- prontuário eletrônico;
- sistemas de laboratório, conhecidos como LIS;
- sistemas de radiologia, como RIS e PACS;
- farmácia, prescrição e dispensação;
- equipamentos de monitoramento;
- sistemas administrativos e de faturamento;
- aplicações próprias desenvolvidas há anos;
- serviços externos, operadoras e plataformas públicas.
Esses componentes podem usar HL7 v2, DICOM, arquivos CSV, XML, bancos compartilhados, web services SOAP ou APIs proprietárias. Mesmo sistemas que declaram suporte ao mesmo padrão frequentemente adotam campos, códigos e eventos de maneiras diferentes.
Por isso, a primeira regra é simples: não substituir todas as interfaces de uma vez. A integração deve ser desacoplada, observável e reversível.
O papel do HL7 v2 e do FHIR na arquitetura
HL7 v2 e FHIR não são padrões concorrentes que exigem uma escolha exclusiva. Eles atendem contextos diferentes e podem coexistir durante toda a modernização.
Onde o HL7 v2 continua relevante
O HL7 v2 é amplamente usado para troca de mensagens orientadas a eventos. Entre os fluxos típicos estão:
- ADT para admissão, alta e transferência;
- ORM para solicitações de exames e procedimentos;
- ORU para resultados e observações;
- SIU para agendamentos;
- MDM para documentos clínicos.
Em muitos ambientes, as mensagens são transmitidas por MLLP sobre TCP. O receptor precisa interpretar segmentos, validar campos obrigatórios e responder com ACK ou NACK. Também deve lidar com particularidades locais, como segmentos Z, tabelas próprias e diferentes versões do HL7 v2.
Quando uma interface HL7 v2 existente é estável, substituí-la apenas por ser antiga pode aumentar o risco sem gerar benefício clínico. É mais seguro encapsulá-la e normalizar seus dados na camada de integração.
Onde o FHIR agrega valor
FHIR representa informações de saúde por meio de recursos como Patient, Encounter, Observation, Condition, MedicationRequest e DiagnosticReport. Esses recursos podem ser acessados por APIs REST, pesquisados por parâmetros e agrupados em Bundle.
FHIR tende a facilitar:
- aplicativos web e móveis;
- portais de pacientes;
- integração com serviços modernos;
- compartilhamento estruturado de dados;
- análises clínicas e engenharia de dados;
- uso controlado de inteligência artificial.
Implementar FHIR, porém, não significa apenas converter JSON. É necessário definir perfis, cardinalidades, terminologias, identificadores e regras de negócio. A equipe também deve verificar qual versão e quais Implementation Guides são suportados por cada sistema.
Arquitetura recomendada para não parar o hospital
A arquitetura mais resiliente introduz uma camada intermediária entre produtores e consumidores. Ela funciona como uma camada anticorrupção: recebe formatos legados, aplica validações e publica uma representação canônica ou adequada ao destino.
Os componentes mais comuns são:
- Adaptadores de entrada: recebem MLLP, arquivos, SOAP, consultas controladas ao banco ou chamadas REST.
- Motor de integração: roteia mensagens, aplica transformações e executa regras.
- Fila ou broker: desacopla sistemas e absorve picos sem bloquear a origem.
- Repositório de terminologias e mapeamentos: relaciona códigos locais a padrões adotados.
- Servidor FHIR: valida, armazena ou expõe recursos conforme o caso de uso.
- Observabilidade: registra métricas, logs, rastreamento e alertas.
- Fila de exceções: preserva mensagens que exigem reprocessamento ou intervenção humana.
O legado não deve acessar diretamente estruturas internas do novo sistema, nem o novo sistema depender de tabelas privadas do legado. Contratos explícitos reduzem o impacto de futuras alterações.
Plano de migração por etapas
1. Inventariar interfaces e dependências
Antes de escrever código, registre para cada fluxo:
- sistema de origem e destino;
- evento que dispara a troca;
- protocolo e formato;
- frequência e volume;
- campos obrigatórios;
- responsável clínico e técnico;
- dependências de rede e infraestrutura;
- comportamento em caso de indisponibilidade;
- impacto de atraso, duplicidade ou perda.
Classifique a criticidade. Um resultado laboratorial urgente, por exemplo, exige tratamento diferente de uma atualização cadastral administrativa.
2. Definir o modelo canônico sem apagar a origem
O modelo canônico reduz transformações ponto a ponto, mas não deve eliminar informações necessárias para auditoria. Preserve a mensagem original, o identificador da origem, a data de recepção e a versão do mapeamento aplicada.
Também é necessário resolver a identidade do paciente. Nome e data de nascimento não são suficientes isoladamente. O desenho deve considerar identificadores locais, documentos, número do prontuário e as regras institucionais de conciliação, evitando unir registros diferentes de forma automática e insegura.
3. Construir uma interface piloto
Comece por um fluxo delimitado, com volume conhecido e possibilidade de conferência. O objetivo é validar conectividade, semântica, desempenho e operação — não apenas demonstrar que uma mensagem chegou ao destino.
O piloto deve testar:
- mensagens válidas e inválidas;
- campos ausentes;
- caracteres especiais e codificação;
- mensagens duplicadas ou fora de ordem;
- queda de rede;
- indisponibilidade do destino;
- reenvio e reprocessamento;
- alterações de cadastro durante o atendimento.
4. Executar em modo paralelo
No modo paralelo, o fluxo atual continua sendo a referência operacional enquanto a nova integração recebe uma cópia dos eventos. As saídas são comparadas sem interferir no atendimento.
A reconciliação deve avaliar pelo menos:
- quantidade de eventos na origem e no destino;
- pacientes, encontros e identificadores associados;
- valores, unidades e códigos clínicos;
- datas e fusos horários;
- percentual de mensagens rejeitadas;
- latência entre produção e disponibilidade.
Critérios de aceite precisam ser definidos pelo hospital. Como exemplo de SLO, e não como regra universal, uma instituição pode exigir disponibilidade mensal de 99,9% e latência inferior a 60 segundos para determinado fluxo. A meta correta depende da criticidade clínica e da infraestrutura existente.
5. Fazer o cutover com reversão preparada
A troca deve ocorrer por fluxo, unidade, especialidade ou grupo controlado de usuários. Antes do cutover, confirme:
- backup e retenção das mensagens;
- monitoramento ativo;
- equipe técnica disponível;
- canal de decisão com representantes assistenciais;
- procedimento de rollback testado;
- filas esvaziadas ou contabilizadas;
- janela e critérios para abortar a mudança.
Rollback não pode significar improvisar uma restauração. Deve existir um caminho documentado para retornar o tráfego à interface anterior sem perder os eventos recebidos durante a tentativa.
Controles essenciais de confiabilidade
Idempotência e duplicidade
Reenvios são inevitáveis. Cada mensagem ou operação deve ter uma chave idempotente baseada em identificadores confiáveis, como controle da mensagem, sistema de origem e evento. Assim, uma repetição não cria duas internações, dois exames ou duas prescrições.
ACK, retentativas e filas de exceção
Em HL7 v2, receber ACK não garante necessariamente que todo o processo clínico foi concluído; isso depende do contrato da interface. Diferencie aceite técnico, validação semântica e processamento final.
Retentativas devem usar intervalos crescentes e limite configurado. Mensagens irrecuperáveis precisam ir para uma fila de exceções com contexto suficiente para análise e reprocessamento seguro.
Observabilidade ponta a ponta
Um painel operacional deve mostrar:
- mensagens recebidas, processadas e rejeitadas;
- tamanho e idade das filas;
- latência por interface;
- taxa de NACK e erros por motivo;
- disponibilidade dos conectores;
- último evento processado por sistema;
- divergências encontradas na reconciliação.
Logs devem usar identificadores de correlação, mas evitar exposição desnecessária de dados pessoais e clínicos.
Segurança, LGPD e governança clínica
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 sistemas, criptografia em trânsito, gestão de segredos, trilhas de auditoria e políticas de retenção.
MLLP puro não oferece, por si só, todas as proteções esperadas em redes modernas. Dependendo da arquitetura, pode ser necessário usar rede segregada, VPN, TLS por meio de componentes intermediários e restrições de origem e destino.
No FHIR, a API não deve ser exposta sem controles de autenticação e autorização. OAuth 2.0 e OpenID Connect podem fazer parte da solução, mas permissões precisam refletir finalidade, perfil do usuário e escopo de dados. Segurança não termina no token: consultas amplas, exportações e logs também exigem governança.
Checklist para escolher a estratégia
Antes de iniciar, confirme se a proposta responde claramente:
- Quais fluxos permanecerão em HL7 v2?
- Quais casos justificam FHIR?
- Onde será feita a transformação semântica?
- Como serão tratados segmentos Z e códigos locais?
- Existe identificação confiável de paciente e atendimento?
- Como duplicidades e eventos fora de ordem serão processados?
- Qual é o tempo máximo aceitável de atraso por fluxo?
- Como mensagens serão auditadas e reprocessadas?
- O rollback foi realmente testado?
- Quem decide se uma divergência é técnica ou clínica?
Se essas respostas não estiverem documentadas, o risco está apenas escondido dentro da implementação.
Como a Predictor Solutions resolve isso
A Predictor Solutions projeta integrações de saúde com HL7 v2 e FHIR, conectando sistemas legados a APIs, plataformas de dados e aplicações clínicas por meio de adaptadores, filas, validação, observabilidade e migração gradual. A equipe 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.
A execução combina levantamento dos fluxos assistenciais, contratos de interface, testes com mensagens reais devidamente protegidas, operação paralela e plano de rollback. Como referência de capacidade operacional da empresa, a Predictor Solutions já atendeu 9 empresas de médio e grande porte, com resultados médios informados de R$ 1,32 milhão de economia por cliente ao ano, 70% de aumento de produtividade e 43% de aumento de lucro em seis meses; cada projeto hospitalar, porém, deve definir e medir seus próprios indicadores.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246