Integração HL7 e FHIR: como conectar sistemas hospitalares legados sem parar a operação

Conectar sistemas hospitalares legados sem interromper a operação exige uma arquitetura incremental: as interfaces existentes continuam funcionando enquanto uma camada de interoperabilidade recebe, transforma, valida e distribui dados em HL7 v2 e FHIR. A transição deve ocorrer por fluxo clínico, com processamento paralelo, reconciliação, observabilidade e rollback — nunca por uma substituição integral em uma única virada.

Por que a integração hospitalar não pode depender de uma grande migração

Hospitais operam sistemas com ciclos de vida diferentes: HIS, prontuário eletrônico, laboratório, radiologia, farmácia, faturamento, dispositivos e soluções departamentais. Alguns usam HL7 v2; outros expõem APIs proprietárias, arquivos, web services antigos ou acesso direto a bancos de dados.

Interromper todos esses componentes para padronizá-los ao mesmo tempo cria riscos clínicos e operacionais. Uma indisponibilidade pode afetar identificação de pacientes, liberação de exames, prescrições, ocupação de leitos ou faturamento.

A estratégia mais segura é preservar os sistemas de registro existentes e inserir uma camada intermediária. Essa camada deve:

• receber mensagens e eventos dos sistemas legados;
• validar estrutura, campos obrigatórios e códigos;
• transformar formatos sem alterar o sistema de origem;
• correlacionar pacientes, atendimentos e pedidos;
• entregar dados ao destino no padrão esperado;
• registrar cada etapa para auditoria e reprocessamento.

O objetivo inicial não é modernizar tudo, mas desacoplar sistemas. Depois disso, cada integração pode evoluir sem exigir mudanças simultâneas em todo o hospital.

HL7 v2 e FHIR cumprem papéis diferentes

HL7 v2 é amplamente usado para troca de eventos clínicos e administrativos. Mensagens como ADT, ORM, ORU e SIU podem representar admissões e transferências, pedidos, resultados e agendamentos. O transporte costuma ocorrer por MLLP sobre TCP, embora existam implementações por arquivos, filas e outros meios.

FHIR organiza informações em recursos, como Patient, Encounter, Observation, DiagnosticReport e MedicationRequest. Esses recursos podem ser acessados por APIs REST, documentos, mensagens ou operações definidas pelo padrão.

FHIR não deve ser tratado automaticamente como substituto imediato do HL7 v2. Em uma arquitetura de transição, é comum:

1. manter mensagens HL7 v2 nos sistemas que já dependem delas;
2. converter eventos selecionados para recursos FHIR;
3. oferecer uma API FHIR para aplicações novas;
4. preservar identificadores e rastreabilidade entre origem e destino.

O mapeamento não é apenas uma conversão de sintaxe. Um segmento OBX, por exemplo, pode originar um recurso Observation, mas a transformação depende do contexto da mensagem, unidade, código do exame, referência do paciente e vínculo com o atendimento.

Arquitetura recomendada para uma transição sem parada

1. Camada de interoperabilidade

Um mecanismo de integração recebe os eventos e aplica rotas, transformações e validações. Ele evita conexões ponto a ponto, nas quais cada alteração exige modificar vários sistemas.

Essa camada pode conter:

• adaptadores HL7 v2, FHIR, REST, SOAP, SFTP e banco de dados;
• filas para absorver picos e indisponibilidades temporárias;
• serviço de terminologia e normalização;
• índice ou mecanismo de correlação de pacientes;
• armazenamento temporário para reprocessamento;
• logs técnicos e trilhas de auditoria.

O acesso direto ao banco de um sistema legado deve ser a última alternativa. Quando inevitável, prefira leitura por réplica, visão controlada ou captura de mudanças, evitando consultas pesadas e alterações nas tabelas operacionais.

2. Modelo canônico interno

Um modelo canônico reduz o número de transformações necessárias. Em vez de criar uma regra diferente para cada par de sistemas, cada origem é convertida para um modelo comum, e cada destino consome esse modelo.

Esse modelo precisa representar, no mínimo:

• identificadores locais e corporativos;
• paciente e dados demográficos;
• atendimento, internação e localização;
• pedido, amostra, resultado e laudo;
• profissional e organização responsáveis;
• data do evento, data de registro e sistema de origem;
• status clínico e status de processamento.

O modelo pode se aproximar do FHIR, mas não deve inventar equivalências. Extensões FHIR precisam ser documentadas, versionadas e usadas apenas quando os recursos e perfis existentes não atendem ao requisito.

3. Processamento assíncrono e idempotente

O sistema deve suportar repetição de mensagens sem duplicar admissões, exames ou resultados. Isso exige uma chave de idempotência baseada em identificadores estáveis, tipo de evento, versão e origem.

Mensagens que falham não devem desaparecer nem bloquear toda a fila. Elas precisam ir para uma fila de exceções, com motivo, conteúdo original, tentativas realizadas e opção de reprocessamento após a correção.

Plano de implantação por fluxo clínico

Comece pelo inventário, não pelo desenvolvimento. Para cada interface, registre origem, destino, protocolo, volume, horário de pico, proprietário, criticidade e comportamento em caso de falha.

Uma implantação controlada pode seguir estas etapas:

1. Selecionar um fluxo delimitado: por exemplo, envio de resultados laboratoriais para um sistema consumidor.
2. Capturar uma amostra representativa: incluir mensagens normais, cancelamentos, correções, duplicidades e campos ausentes.
3. Definir o contrato: versão HL7, segmentos utilizados, perfil FHIR, terminologias, autenticação e códigos de erro.
4. Executar em modo sombra: a nova integração processa cópias dos eventos, sem produzir efeitos no destino.
5. Comparar os resultados: medir quantidade, conteúdo, ordem, latência e divergências entre os caminhos antigo e novo.
6. Liberar por grupos: ativar um setor, unidade, tipo de exame ou percentual do tráfego.
7. Manter rollback: permitir retorno imediato à rota anterior sem perda dos eventos acumulados.
8. Desativar o caminho antigo: somente após estabilidade e reconciliação formal.

O tempo do modo sombra depende do volume e da sazonalidade. Como critério prático, ele deve abranger rotinas diurnas e noturnas, finais de semana e ao menos um ciclo operacional completo do setor.

Validação clínica e técnica

Uma mensagem sintaticamente válida ainda pode estar clinicamente errada. Por isso, a homologação deve combinar profissionais de integração, TI hospitalar e responsáveis pelo processo assistencial.

O checklist mínimo inclui:

• paciente correto e ausência de colisões de identificadores;
• atendimento e episódio assistencial corretos;
• preservação de unidade, escala e intervalo de referência;
• diferenciação entre resultado preliminar, final, corrigido e cancelado;
• datas com fuso horário e precisão definidos;
• códigos locais mapeados para terminologias adequadas;
• ACKs HL7 interpretados corretamente;
• respostas HTTP e recursos OperationOutcome tratados;
• anexos e laudos preservados sem truncamento;
• mensagens duplicadas processadas de forma idempotente.

Terminologias como LOINC, SNOMED CT e CID-10 podem ajudar na interoperabilidade semântica, mas seu uso depende do contexto, da versão adotada e das regras de licenciamento. Códigos locais não devem ser descartados: eles precisam permanecer associados ao código normalizado para auditoria.

Observabilidade, segurança e continuidade

Cada evento deve possuir um identificador de correlação que permita acompanhá-lo desde a origem até o destino. Os painéis operacionais precisam mostrar taxa de entrada, entregas, rejeições, latência, tamanho das filas e idade da mensagem mais antiga.

Alertas devem considerar impacto, não apenas erros isolados. Exemplos de condições relevantes são fila crescendo continuamente, ausência inesperada de mensagens de um setor, aumento de rejeições ou resultados críticos sem confirmação de entrega.

Na segurança, aplique:

• TLS nos transportes compatíveis e redes segregadas para integrações antigas;
• autenticação e autorização por sistema e finalidade;
• menor privilégio para contas técnicas;
• criptografia de dados armazenados;
• rotação de credenciais e segredos fora do código;
• logs sem exposição desnecessária de dados clínicos;
• trilhas de auditoria e políticas de retenção.

Como dados de saúde são dados pessoais sensíveis segundo a LGPD, o projeto deve limitar coleta e acesso à finalidade assistencial ou operacional definida. Ambientes de teste devem usar dados sintéticos ou anonimizados sempre que possível.

Métricas e critérios para decidir a virada

A migração não deve ser aprovada apenas porque “as mensagens estão chegando”. Defina previamente indicadores e limites compatíveis com a criticidade do fluxo:

• percentual de eventos conciliados entre origem e destino;
• quantidade de duplicidades e perdas;
• latência nos percentis 50, 95 e 99;
• volume e idade dos itens na fila de exceção;
• tempo de recuperação após indisponibilidade;
• percentual de códigos não mapeados;
• tempo necessário para detectar e diagnosticar falhas.

Para fluxos clínicos críticos, a meta deve ser rastrear 100% dos eventos, inclusive rejeições e reprocessamentos. O limite de latência precisa ser definido pelo processo: segundos podem ser necessários para uma admissão ou alerta, enquanto cargas analíticas podem tolerar períodos maiores.

Erros que aumentam o risco da integração

Os problemas mais frequentes são substituir tudo de uma vez, assumir que todos os fornecedores implementam o padrão da mesma maneira e codificar regras clínicas dentro de scripts sem testes ou versionamento.

Também devem ser evitados:

• usar nome e data de nascimento como única correlação de pacientes;
• ignorar cancelamentos e correções;
• confirmar recebimento antes de persistir o evento com segurança;
• não separar falha transitória de erro de dados;
• depender de um único servidor sem recuperação documentada;
• colocar a nova API diretamente sobre tabelas do sistema legado;
• armazenar dados sensíveis em logs de depuração.

Como a Predictor Solutions resolve isso

A Predictor Solutions implementa integrações de saúde com HL7 v2 e FHIR por meio de levantamento de interfaces, definição de contratos, mecanismos de transformação, APIs, filas, observabilidade e implantação incremental. A abordagem preserva os sistemas em operação, valida os fluxos em paralelo e estabelece reprocessamento e rollback antes da migração definitiva.

A empresa também atua em software sob medida, inteligência artificial aplicada, engenharia de dados, cloud, DevOps e segurança ofensiva. Entre seus produtos estão 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. Considerando seus projetos de software e automação, a Predictor Solutions registra 9 empresas de médio e grande porte atendidas, economia média de R$ 1,32 milhão por cliente ao ano, aumento médio de 70% em produtividade e crescimento de 43% no lucro em seis meses.

Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246