Conectar sistemas hospitalares legados sem interromper a operação exige uma arquitetura de coexistência: o sistema atual continua funcionando enquanto uma camada de integração traduz, valida e distribui mensagens HL7 v2 e recursos FHIR. A migração deve ocorrer por fluxos clínicos, com processamento paralelo, testes de contrato, monitoramento, reconciliação e rollback — nunca por uma substituição abrupta de todo o ambiente.
Por que a integração hospitalar é especialmente difícil
Hospitais operam uma combinação de prontuário eletrônico, laboratório, radiologia, farmácia, faturamento, dispositivos médicos e aplicações departamentais. Muitos desses sistemas foram implantados em épocas diferentes e usam bancos, códigos e protocolos incompatíveis.
A complexidade não está apenas no formato dos dados. É necessário preservar o significado clínico, a sequência dos eventos e a identidade correta de pacientes e profissionais. Uma mensagem tecnicamente válida pode causar problemas se associar um resultado laboratorial ao atendimento errado ou interpretar incorretamente uma unidade de medida.
Os principais obstáculos são:
- diferentes versões e customizações do HL7 v2;
- campos opcionais usados como obrigatórios por sistemas locais;
- códigos próprios para exames, medicamentos e setores;
- duplicidade ou divergência no cadastro de pacientes;
- sistemas que só enviam arquivos ou acessam bancos diretamente;
- dependência de fornecedores para alterar interfaces;
- indisponibilidade de ambientes de homologação representativos;
- operação clínica contínua, inclusive em noites e fins de semana.
Por isso, “sem parar a operação” não significa ausência absoluta de risco. Significa reduzir o risco por meio de coexistência controlada, mudanças reversíveis e isolamento de falhas.
Qual é o papel do HL7 v2 e do FHIR
HL7 v2 e FHIR não são alternativas mutuamente excludentes. Em um hospital legado, os dois padrões normalmente convivem.
HL7 v2 para eventos operacionais
O HL7 v2 é amplamente usado para transmitir eventos clínicos e administrativos. Uma mensagem ADT pode comunicar admissão, transferência ou alta; uma ORM, uma solicitação; e uma ORU, um resultado de exame.
O transporte costuma ocorrer por MLLP sobre TCP, embora existam implementações por arquivos, filas e outros mecanismos. Cada mensagem contém segmentos como MSH, PID, PV1 e OBX. O receptor responde com um ACK, indicando aceitação ou rejeição técnica.
Receber ACK não garante que o dado foi processado corretamente no destino. A integração precisa distinguir pelo menos três estados:
- mensagem entregue ao canal;
- mensagem aceita sintaticamente;
- evento aplicado corretamente ao sistema de destino.
FHIR para APIs e ecossistemas modernos
FHIR organiza informações em recursos como Patient, Encounter, Observation, DiagnosticReport, MedicationRequest e Condition. Esses recursos podem ser acessados por APIs REST, pesquisas, operações, documentos, mensagens e assinaturas, conforme o caso de uso.
FHIR facilita a conexão com aplicações web, plataformas analíticas, aplicativos para pacientes e serviços de inteligência artificial. Entretanto, publicar JSON com nomes parecidos com os recursos não torna uma API compatível. É necessário definir versão, perfis, terminologias, cardinalidades, extensões e regras de validação.
As especificações oficiais devem ser consultadas em HL7 v2 e FHIR.
Arquitetura recomendada para integrar sem interrupção
A arquitetura mais segura adiciona uma camada intermediária sem exigir que todos os sistemas sejam alterados simultaneamente.
Motor de integração
O motor de integração recebe mensagens, valida estruturas, transforma campos, aplica regras, roteia eventos e registra o processamento. Ele desacopla os sistemas: o laboratório não precisa conhecer os detalhes da API FHIR usada por uma aplicação analítica.
Uma arquitetura típica contém:
- conectores MLLP, REST, arquivos, filas ou banco de dados;
- normalização para um modelo canônico;
- serviço de terminologias e mapeamentos;
- armazenamento temporário para reprocessamento;
- fila de mensagens com controle de retentativas;
- API FHIR ou fachada de interoperabilidade;
- logs correlacionados e painel operacional;
- fila de exceções para intervenção humana.
O motor não deve se tornar um conjunto opaco de regras. Transformações precisam estar versionadas, revisadas e cobertas por testes automatizados.
Modelo canônico e tradução
Sem um modelo intermediário, cada novo sistema exige integrações ponto a ponto. Com dez sistemas, a quantidade potencial de conexões cresce rapidamente e aumenta o custo de manutenção.
O modelo canônico representa conceitos comuns — paciente, atendimento, observação, solicitação e resultado — independentemente do formato de origem. Um fluxo pode seguir esta sequência:
HL7 v2 → validação → modelo canônico → normalização terminológica → recurso FHIR → sistema consumidor
Nem todo dado de HL7 v2 possui correspondência direta e única em FHIR. O mapeamento deve registrar decisões, perdas de informação e extensões utilizadas. Campos desconhecidos não devem ser descartados silenciosamente.
Plano de implantação por etapas
Uma integração segura é entregue em incrementos pequenos e mensuráveis.
1. Inventariar sistemas e fluxos
O inventário deve identificar proprietários, fornecedores, versões, protocolos, volumes e criticidade. Para cada interface, registre:
- origem e destino;
- tipos de mensagem ou recursos;
- volume médio e pico por hora;
- tempo máximo aceitável de atraso;
- comportamento em caso de indisponibilidade;
- identificadores usados para paciente e atendimento;
- possibilidade de reenvio e reconciliação;
- janela permitida para mudança.
Priorize um fluxo relevante, mas com impacto controlável. Resultados laboratoriais não críticos para uma plataforma analítica, por exemplo, podem ser um ponto inicial mais seguro do que ordens de medicação.
2. Capturar uma amostra representativa
Layouts fornecidos em documentos raramente cobrem todas as variações reais. A equipe deve analisar mensagens anonimizadas ou protegidas, incluindo casos normais, cancelamentos, correções, duplicidades e campos ausentes.
A amostra precisa contemplar picos operacionais e diferenças entre unidades. Dados de produção só devem ser usados com controles compatíveis com a LGPD, finalidade definida e acesso restrito.
3. Criar testes de contrato
Os testes devem verificar estrutura e semântica. Exemplos:
- PID contém o identificador esperado do paciente;
- PV1 referencia o atendimento correto;
- OBX preserva unidade, valor, intervalo e status;
- mensagens duplicadas não criam registros duplicados;
- correções substituem ou complementam o resultado anterior;
- recursos FHIR atendem aos perfis acordados;
- falhas geram códigos e mensagens operacionais compreensíveis.
Um conjunto de “mensagens douradas”, com entrada e saída esperadas, permite detectar regressões quando regras são alteradas.
4. Executar em modo sombra
No modo sombra, o novo pipeline recebe uma cópia dos eventos, mas não interfere no processo clínico principal. Suas saídas são comparadas às do fluxo atual.
Devem ser medidos:
- percentual de mensagens válidas;
- divergências de pacientes e atendimentos;
- latência nos percentis 50, 95 e 99;
- volume de duplicidades;
- mensagens sem mapeamento terminológico;
- falhas por origem, tipo e versão.
O avanço depende de critérios acordados. Em fluxos clínicos críticos, aceitar “quase tudo” sem analisar as exceções pode ser perigoso.
5. Fazer o corte gradual
O corte pode ocorrer por unidade, tipo de mensagem, sistema consumidor ou grupo de pacientes. Durante um período, mantenha processamento paralelo e reconciliação diária.
O plano de rollback deve dizer quem decide, como o tráfego retorna ao fluxo anterior e como os eventos acumulados serão tratados. Rollback sem estratégia de dados pode restaurar o sistema, mas deixar informações divergentes.
Observabilidade, segurança e continuidade
Monitorar apenas CPU e memória é insuficiente. A observabilidade deve acompanhar eventos clínicos de ponta a ponta usando um identificador de correlação, sem expor dados sensíveis desnecessariamente nos logs.
Indicadores mínimos incluem:
- mensagens recebidas, processadas, rejeitadas e pendentes;
- latência por canal e sistema de destino;
- idade da mensagem mais antiga na fila;
- taxa de ACK negativo ou timeout;
- quantidade de retentativas;
- divergências encontradas na reconciliação;
- disponibilidade de conectores e dependências.
Na segurança, aplique criptografia em trânsito quando suportada, segmentação de rede, autenticação forte, menor privilégio, rotação de segredos e trilhas de auditoria. APIs FHIR expostas a aplicações devem validar autorização no nível necessário, pois autenticar um usuário não significa permitir acesso irrestrito a todos os recursos.
Também é necessário definir tempo de retenção, mascaramento em ambientes não produtivos e resposta a incidentes. Logs com nome, diagnóstico ou identificador de paciente são dados pessoais e podem conter dados pessoais sensíveis segundo a LGPD.
Checklist para decidir se a integração está pronta
Antes de direcionar tráfego de produção, confirme:
- [ ] contratos de interface e mapeamentos estão versionados;
- [ ] cenários de correção, cancelamento e duplicidade foram testados;
- [ ] existe fila persistente ou mecanismo equivalente contra perda;
- [ ] o reprocessamento é idempotente;
- [ ] alertas possuem responsáveis e critérios de escalonamento;
- [ ] a reconciliação entre origem e destino foi automatizada;
- [ ] o plano de rollback foi ensaiado;
- [ ] os acessos seguem menor privilégio;
- [ ] logs não expõem dados além do necessário;
- [ ] usuários clínicos e técnicos validaram o comportamento;
- [ ] fornecedores envolvidos conhecem a janela e o plano de contingência.
Como a Predictor Solutions resolve isso
A Predictor Solutions, software house de Lavras, Minas Gerais, implementa integrações hospitalares com HL7 v2 e FHIR usando levantamento de interfaces, camada de tradução, APIs, testes automatizados, observabilidade e implantação gradual. 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.
A prática combina interoperabilidade, engenharia de dados, cloud/DevOps e segurança ofensiva para tratar a integração como uma operação contínua, não apenas como conversão de arquivos. Nos projetos da empresa, os resultados consolidados informados incluem 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% na produtividade e crescimento de 43% no lucro em seis meses; cada resultado depende do escopo e do contexto operacional.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246