Interoperabilidade no SUS: Por que a IA pode falhar

Sem o padrão HL7 FHIR bem implementado

Seu diretor clínico acabou de voltar de um congresso empolgado com “IA Generativa no Prontuário“. Ele quer que o sistema resuma a história clínica do paciente automaticamente. O problema? Ele acha que isso é instalar um plugin.

Você sabe a verdade: IA não lê pensamento, lê dados estruturados.

Se o seu hospital, assim como 90% da rede pública e privada do Brasil, roda em cima de um legado (seja Tasy, MV, ou aquele “Frankenstein” em Delphi feito em 2005) com campos de texto livre, sua IA vai falhar. Ela vai alucinar diagnósticos porque não saberá distinguir “Suspeita de Dengue” (texto livre na evolução) de “Dengue Confirmada” (CID-10 no campo de diagnóstico).

A única ponte entre o seu “banco de dados sujo” e a inteligência artificial do novo projeto ITMI/BRICS é um acrônimo que você precisa dominar agora: HL7 FHIR.

O Problema: Seu Banco de Dados é um Dialeto Local

No Brasil, vivemos a “Torre de Babel” da saúde.

• Sistema A (Laboratório): Envia glicemia como “GLICO – 90 mg”.
• Sistema B (Prontuário): Espera receber “Glicose Sérica – 90 mg/dL”.
• O Resultado: O médico vê o exame no PDF, mas o algoritmo de IA vê null ou lixo.

A RNDS (Rede Nacional de Dados em Saúde) padronizou a troca de dados usando o HL7 FHIR (Fast Healthcare Interoperability Resources). Não é apenas um formato técnico como XML ou JSON; é um modelo de significado.

No mundo FHIR, não existe apenas “Glicose”. Existe um Resource chamado Observation, que exige um código LOINC universal (ex: 2345-7), uma unidade de medida UCUM e um status de validação.

O Atrito Real: Implementando FHIR no Legado Brasileiro

A teoria diz “use a API”. A prática no chão de fábrica do SUS é brutal:

1. A Armadilha do “De-Para” Manual: Para seu sistema falar FHIR, você precisará mapear cada tabela do seu banco antigo para os recursos do padrão.
   • Onde dói: Seu sistema antigo tem um campo “Sexo”. O FHIR exige “Gênero Administrativo” e “Sexo Biológico” como campos distintos com domínios de valores (CodeSystems) específicos. Quem vai decidir essa migração de 1 milhão de pacientes antigos? O estagiário de TI ou o diretor médico? (Spoiler: sobra para a TI).
2. A Conectividade com a RNDS: O Ministério da Saúde exige autenticação com certificados digitais e TLS mútuo. Em hospitais do interior, onde o firewall é configurado por um terceiro que aparece uma vez por mês, fazer essa “saída segura” para o Data Lake do SUS é onde a maioria dos projetos trava nas primeiras semanas.
3. Performance de Consultas: Sistemas legados não foram feitos para gerar JSONs complexos em tempo real. Tentar montar um objeto FHIR completo (Bundle) fazendo 50 joins no seu banco SQL de produção vai derrubar o sistema de atendimento no meio da tarde de segunda-feira.

A Solução Prática: Camada de Interoperabilidade (Middleware)

Não tente reescrever seu ERP Hospitalar. É suicídio profissional. nãA estratégia que funciona no mercado brasileiro é criar uma Camada de Fachada (Façade).

1. Mantenha o Legado Quieto: Deixe o ERP rodando como está.
2. Crie um “Tradutor” (Middleware): Um servidor separado (pode ser usando Mirth Connect, que é Open Source, ou soluções de mercado como InterSystems) que lê o banco do legado, traduz para FHIR e entrega para a IA ou RNDS.
3. Cache é Vida: Esse middleware armazena a versão FHIR dos dados. Quando a IA pedir o histórico do paciente, ela bate no middleware, não no banco do ERP que está sofrendo para fechar o faturamento.

⚠️ O Que Ninguém Te Conta: O Custo da “Semântica”

Vendedores de software dizem que seus sistemas são “Interoperáveis”. Eles mentem ou omitem. Eles entregam a interoperabilidade sintática (o cano conecta), mas não a semântica (a água é potável). Por isso deve ter uma certa atenção ao redigir o edital de compra do software que exija natividade FHIR.

A pegadinha: Você contrata a ferramenta de IA. Ela exige que todos os medicamentos estejam codificados no padrão SNOMED-CT. Seu hospital usa o padrão TUSS (obrigatório para convênios) ou códigos próprios de licitação pública. O custo oculto: Você terá que pagar horas de consultoria de farmacêuticos e médicos para fazer o “mapeamento terminológico” (TUSS → SNOMED). Sem isso, a IA não sabe que “Novalgina” é “Dipirona”, e o alerta de alergia não funciona.

Reality Check: O Custo do “Projeto IA”

Para um hospital médio (200 leitos) se preparar para integrar com projetos como o ITMI usando FHIR:

• Tempo de Saneamento de Dados: 6 a 8 meses antes de qualquer IA ser ligada.
• Equipe Necessária: Não é só “TI”. Você precisa de um enfermeiro de dados (sim, isso existe) para validar se o mapeamento clínico está correto.
• Investimento: Estime que 30% a 40% do orçamento do projeto de inovação será gasto apenas “arrumando a casa” (limpeza de dados e middleware), e não na licença da IA em si.