Conteúdo observacional
Engenharia de dados e interoperabilidade são direção futura da Nexis Security, não serviço ofertado nesta fase. Este texto é análise técnica pública, não descrição de uma oferta.
Um projeto piloto conduzido pelo InovaHC, com participação de Fleury, Sírio-Libanês, Hospital Alemão Oswaldo Cruz e BP, começou a conectar dados clínicos de instituições privadas à Rede Nacional de Dados em Saúde utilizando o padrão HL7 FHIR.
Iniciativas como essa costumam ser noticiadas como resolução do problema de integração. Na prática, elas resolvem uma parte dele. Compreender qual parte é o que separa um projeto de dados que funciona de um que passa na validação e falha na análise.
Este artigo separa a interoperabilidade em três camadas distintas.
Camada 1 — Estrutural (ou sintática)
É a camada que o FHIR e os perfis nacionais resolvem.
O padrão define como um dado clínico deve ser representado: quais campos existem em um recurso, quais são obrigatórios, que tipo de valor cada um aceita e como os recursos se relacionam entre si. O BR-Core, guia de implementação mantido pela HL7 Brasil e validado com a equipe técnica da SEIDIGI do Ministério da Saúde, cumpre esse papel no contexto brasileiro: padroniza como um exame, um encaminhamento ou um sumário de alta são representados nacionalmente.
Quando duas instituições conseguem trocar um recurso DiagnosticReport sem erro de validação, a camada estrutural está resolvida.
O que essa camada garante: que o dado chegue ao destino em formato compreensível pela máquina.
O que ela não garante: que o dado signifique a mesma coisa nos dois lados.
Camada 2 — Semântica
Esta é a camada onde a maioria dos projetos de integração descobre o problema tarde demais.
Dois hospitais podem emitir um DiagnosticReport perfeitamente válido contra o BR-Core e ainda assim gerar dados incomparáveis. Basta que um codifique o exame usando um código interno e o outro use LOINC ou TUSS. A estrutura está correta em ambos os casos. A análise consolidada, no entanto, é impossível sem tradução manual.
Conformidade estrutural sem amarração de vocabulário produz integração que passa na validação e falha na análise.
Como o FHIR trata isso
A especificação prevê o conceito de binding: a regra que declara qual terminologia um campo específico pode utilizar. Existem níveis distintos de obrigatoriedade:
| Nível | O que significa |
|---|---|
required |
O campo só aceita códigos da terminologia indicada |
extensible |
Usa a terminologia indicada quando o conceito existir nela; permite alternativa quando não existir |
example |
Sugestão, sem obrigatoriedade real |
A diferença entre esses níveis determina se a interoperabilidade semântica é garantida pelo padrão ou negociada caso a caso entre instituições.
O contexto brasileiro complica
O Brasil opera hoje com múltiplas terminologias simultâneas e finalidades diferentes:
- LOINC identifica o que foi medido ou observado — o exame, a pergunta
- SNOMED CT descreve conceitos clínicos — diagnóstico, achado, procedimento
- CID-10 classifica para fins epidemiológicos e de faturamento
- TUSS padroniza procedimentos para faturamento na saúde suplementar
Um mesmo exame laboratorial pode precisar de três códigos distintos, cada um servindo a um uso diferente. A tentativa de unificar tudo em um vocabulário único perde informação em algum dos usos.
Camada 3 — Conteúdo clínico
Existe uma terceira camada, menos discutida, que permanece aberta mesmo quando as duas primeiras estão resolvidas.
O FHIR estrutura o envelope do laudo. O achado clínico em si frequentemente permanece como texto livre dentro do recurso. Um Observation pode estar corretamente codificado em LOINC e ainda assim perder o contexto que explica por que aquela observação foi registrada — informação que costuma ser decisiva para quem vai agir sobre ela.
Padronizar transporte e cabeçalho resolve metade do caminho. A outra metade é estruturar o conteúdo clínico, e isso permanece como problema aberto na maioria das implementações.
Por que essa separação importa para um projeto de dados
Quando uma organização de saúde contrata ou executa um projeto de integração, a pergunta usual é “os sistemas conseguem trocar dados?”. É a pergunta da camada 1.
As perguntas que determinam se o dado será utilizável para análise são outras:
- Os campos críticos têm binding obrigatório de terminologia, ou cada sistema codifica como preferir?
- Existe mapeamento documentado entre o vocabulário local e o padrão adotado?
- Que percentual do conteúdo clinicamente relevante permanece como texto livre?
- Quando um campo está vazio, isso significa ausência de informação ou não aplicabilidade?
Nenhuma dessas perguntas é respondida por um teste de conformidade estrutural. Todas afetam diretamente a confiabilidade de qualquer indicador construído sobre esses dados.
O ponto central
Interoperabilidade não é um problema de tecnologia de troca. É um problema de acordo sobre significado.
A tecnologia de transporte está resolvida há tempo. O que continua difícil é garantir que duas instituições descrevam a mesma realidade clínica do mesmo modo — e essa dificuldade é de modelagem de dados e de governança de terminologias, não de infraestrutura.
Projetos que tratam interoperabilidade apenas como camada 1 entregam integração tecnicamente correta e analiticamente inútil.
Referências
- Guia de Integração da RNDS, Ministério da Saúde — https://rnds-guia.saude.gov.br/
- BR-Core, guia de implementação (HL7 Brasil) — https://hl7.org.br/fhir/core/index.html
- Especificação FHIR R4 (HL7 International) — https://hl7.org/fhir/R4/index.html
- Bodenreider, Cornet & Vreeman (2018), Recent Developments in Clinical Terminologies: SNOMED CT, LOINC, and RxNorm — https://pmc.ncbi.nlm.nih.gov/articles/PMC6115234/
- Learn LOINC, Regenstrief Institute — https://loinc.org/learn/
Sobre este conteúdo
A Nexis Security está em fase de construção de autoridade técnica e não possui oferta comercial disponível. Publicamos o raciocínio antes de oferecer qualquer serviço — este texto existe para ser avaliado, discutido e corrigido.
Falar com a Nexis Security no WhatsApp · contato@nexissecurity.com.br