Conectar sistemas hospitalares legados sem interromper a operação exige uma arquitetura incremental: mantenha as interfaces existentes, capture os eventos clínicos, normalize os dados e publique-os por HL7 v2 ou APIs FHIR. A transição deve ocorrer por fluxo assistencial, com execução em paralelo, validação de mensagens, reconciliação e possibilidade de rollback — nunca por uma substituição integral em uma única janela.
Por que a integração hospitalar não pode depender de um corte único
Hospitais operam continuamente, e uma falha de integração pode impedir o registro de uma admissão, atrasar um resultado laboratorial ou associar uma informação ao paciente errado. Por isso, trocar simultaneamente HIS, LIS, RIS, PACS, prontuário eletrônico e sistemas administrativos costuma representar um risco desnecessário.
Os legados também não são uniformes. Um equipamento pode enviar HL7 v2.3 por TCP/IP, um sistema administrativo pode trabalhar com arquivos CSV em SFTP e uma aplicação mais recente pode oferecer APIs REST. Até implementações que declaram usar a mesma versão do HL7 v2 podem adotar campos, códigos e segmentos opcionais de maneiras diferentes.
A abordagem mais segura é o padrão de modernização progressiva, também conhecido como strangler pattern: uma camada de interoperabilidade passa a controlar novas integrações enquanto os sistemas antigos continuam operando. Cada fluxo é migrado, observado e homologado separadamente.
HL7 v2 e FHIR cumprem papéis diferentes
HL7 v2 continua amplamente associado à troca de eventos entre sistemas hospitalares. As mensagens são orientadas a eventos e compostas por segmentos delimitados, como MSH, PID, PV1, ORC e OBX. Exemplos comuns incluem:
- ADT: admissão, alta, transferência e atualização cadastral;
- ORM ou OML: solicitação de exames e procedimentos;
- ORU: resultados laboratoriais e observações clínicas;
- SIU: agendamentos;
- MDM: documentos clínicos.
FHIR, ou Fast Healthcare Interoperability Resources, representa informações por recursos como Patient, Encounter, Observation, DiagnosticReport, Condition e MedicationRequest. Normalmente utiliza APIs HTTP e JSON, embora o padrão não se limite a REST.
FHIR não é uma simples conversão de HL7 v2 para JSON. Um evento ADT pode afetar Patient, Encounter e recursos relacionados, enquanto um ORU pode exigir Observation e DiagnosticReport. A modelagem deve preservar contexto, identificadores, códigos, autoria e data clínica.
Na prática, os dois padrões podem coexistir: HL7 v2 permanece na comunicação com sistemas legados e FHIR oferece uma camada mais consistente para portais, aplicativos, analytics e novos serviços.
Arquitetura recomendada para modernização sem parada
Uma arquitetura de transição costuma ter cinco componentes.
1. Adaptadores de origem
Recebem dados pelos protocolos disponíveis: MLLP/TCP, banco de dados, SOAP, REST, arquivos ou filas. O adaptador deve confirmar o recebimento somente depois que a mensagem estiver registrada de forma durável.
2. Motor de integração
Executa roteamento, transformação, validação e tratamento de exceções. Também deve registrar a versão de cada regra de mapeamento, pois mudanças em campos ou códigos podem alterar o significado clínico.
3. Modelo canônico
Reduz o acoplamento entre origem e destino. Em vez de construir conversões independentes para cada par de sistemas, os dados são normalizados em um modelo intermediário e depois transformados para HL7 v2, FHIR ou outro formato.
4. Repositório e fila durável
Mensagens precisam sobreviver a indisponibilidades temporárias. Filas, retentativas controladas e uma fila de mensagens inválidas evitam perda silenciosa e permitem reprocessamento.
5. APIs e serviços FHIR
A camada FHIR atende consumidores modernos e deve aplicar autenticação, autorização, auditoria e versionamento. Quando necessário, perfis e guias de implementação restringem recursos para um contexto específico.
O inventário que deve preceder qualquer mudança
Antes de desenvolver conectores, mapeie o ambiente real. O inventário precisa responder:
- Quais sistemas produzem e consomem cada informação?
- Quem é a fonte oficial para paciente, atendimento, pedido e resultado?
- Quais versões e eventos HL7 v2 estão ativos?
- Quais campos locais, segmentos Z e tabelas proprietárias são usados?
- Como pacientes e atendimentos são identificados em cada sistema?
- Qual é o volume médio e de pico de mensagens?
- Qual atraso é tolerável por fluxo?
- O sistema envia ACK, aceita reprocessamento e preserva a ordem dos eventos?
- Como são tratados cancelamentos, correções e fusões de prontuários?
- Qual equipe responde por falhas fora do horário comercial?
Amostras reais anonimizadas são mais úteis do que manuais isolados. Uma documentação pode afirmar que determinado campo é obrigatório, enquanto a operação envia valores vazios ou códigos locais há anos.
Identidade do paciente é o ponto mais crítico
O maior risco não é uma mensagem tecnicamente inválida, mas uma mensagem válida associada à pessoa errada. A integração precisa distinguir pelo menos três identificadores:
- identificador do paciente no sistema de origem;
- identificador corporativo ou mestre do paciente;
- identificador do atendimento ou episódio clínico.
Não se deve reconciliar pacientes apenas por nome. Data de nascimento, documentos, sexo cadastral, telefone e outros atributos podem apoiar o pareamento, mas as regras precisam considerar duplicidades, alterações cadastrais e qualidade dos dados.
Quando não existe um identificador corporativo confiável, pode ser necessário implementar um índice mestre de pacientes. Correspondências incertas devem seguir para revisão, em vez de serem vinculadas automaticamente.
Plano de migração em seis etapas
1. Escolha um fluxo de baixo risco relativo
Comece por um domínio com limites claros e possibilidade de conferência. Evite iniciar pelo conjunto mais crítico apenas porque ele tem maior visibilidade.
2. Capture sem interferir
Espelhe mensagens ou replique eventos para a nova camada, mantendo o destino atual. Essa execução em modo sombra permite conhecer volume, variações e erros sem afetar o atendimento.
3. Valide estrutura e semântica
Verifique segmentos, cardinalidades, tipos, códigos e relacionamentos. Uma mensagem pode estar sintaticamente correta e ainda representar incorretamente a unidade, o status ou a data do resultado.
4. Execute em paralelo
Envie os eventos ao caminho antigo e ao novo durante um período definido por volume e criticidade. Compare indicadores como:
- total produzido, recebido e processado;
- mensagens rejeitadas ou pendentes;
- latência nos percentis 50, 95 e 99;
- divergências de identificadores e códigos;
- resultados corrigidos ou cancelados;
- tempo de recuperação após indisponibilidade.
Não existe um número universal de dias para homologação. O período deve incluir picos, finais de semana e eventos menos frequentes, como transferência, cancelamento e fusão cadastral.
5. Faça o corte por consumidor
Migre um sistema ou fluxo por vez. Mantenha o mecanismo anterior disponível por um prazo controlado e documente critérios objetivos para retorno.
6. Reconcilie e desative conscientemente
Após o corte, compare contagens e amostras clínicas. Uma interface antiga só deve ser desligada quando não houver consumidores ocultos e quando auditoria, retenção e reprocessamento estiverem assegurados.
Controles indispensáveis de confiabilidade e segurança
Toda mensagem precisa ter identificador de correlação, horário de recebimento, origem, destino, status e histórico de tentativas. O processamento deve ser idempotente: reenviar uma mensagem não pode criar dois pedidos ou dois resultados.
Outros controles essenciais incluem:
- criptografia em trânsito e em repouso;
- acesso baseado em função e menor privilégio;
- trilhas de auditoria protegidas contra alteração;
- mascaramento de dados pessoais em logs;
- retenção coerente com finalidade e obrigação aplicável;
- monitoramento de filas, latência, erros e indisponibilidade;
- testes de restauração e continuidade;
- segregação entre desenvolvimento, homologação e produção.
No Brasil, dados de saúde são dados pessoais sensíveis segundo a LGPD. A arquitetura deve limitar coleta, exposição e acesso, sem usar informações clínicas reais indiscriminadamente em ambientes de teste.
Critérios para escolher entre manter HL7 v2, adotar FHIR ou combinar ambos
Mantenha HL7 v2 quando o sistema existente já possui uma interface estável e trocar o protocolo não gera benefício operacional. Adote FHIR quando novos consumidores precisam de APIs pesquisáveis, recursos estruturados e contratos mais adequados a aplicações web e móveis.
Use uma estratégia híbrida quando:
- equipamentos e sistemas legados dependem de HL7 v2;
- novos canais precisam consumir APIs;
- analytics exige dados normalizados;
- a substituição do prontuário ocorrerá gradualmente;
- vários fornecedores precisam compartilhar um contrato consistente.
A decisão deve considerar criticidade, custo total, capacidade da equipe, suporte do fornecedor, volume, latência e governança semântica — não apenas a modernidade do padrão.
Como a Predictor Solutions resolve isso
A Predictor Solutions, software house de Lavras, Minas Gerais, atua no desenvolvimento de sistemas de saúde com integração HL7 v2 e FHIR. O trabalho combina inventário das interfaces, definição de fonte oficial, mapeamento semântico, construção de adaptadores, APIs, observabilidade, testes em paralelo e migração progressiva para reduzir o risco operacional.
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. Esses produtos exigem que dados clínicos sejam identificados, contextualizados e disponibilizados de forma confiável; inteligência artificial não corrige uma integração sem governança.
No conjunto de seus projetos de software, dados e automação, a Predictor Solutions informa 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. Esses números são resultados gerais do portfólio e não uma promessa automática para todo projeto de interoperabilidade.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.