CodeSystem em FHIR

Até aqui, falamos de FHIR em termos de estrutura: o que é um recurso, como ele é lido, em que formatos ele trafega. Mas há uma pergunta que toda integração precisa responder mais cedo ou mais tarde: quando um campo traz um código em vez de texto livre, quem definiu esse código, e onde está o “dicionário” que explica o que ele significa? É aqui que entra o recurso CodeSystem.

O que é um CodeSystem e para que ele serve

Muitos elementos de um recurso FHIR — o tipo de um exame, a categoria de uma condição clínica, o status de uma prescrição — não são preenchidos com texto livre. Eles são preenchidos com códigos, justamente para que sistemas diferentes consigam interpretar a mesma informação de forma inequívoca, sem depender de comparação textual (que quebra facilmente com sinônimos, abreviações ou erros de digitação).

O CodeSystem é o recurso pelo qual o FHIR declara formalmente a existência de um sistema de códigos: quais códigos existem e o que cada um significa.

Um ponto que a própria especificação faz questão de esclarecer, e que vale destacar aqui: o CodeSystem não é o mecanismo pensado para redistribuir terminologias inteiras como SNOMED CT, LOINC ou RxNorm. Essas terminologias têm seus próprios formatos e canais de distribuição, mantidos pelas organizações responsáveis por elas. O papel do CodeSystem é outro: declarar códigos específicos de um domínio — que podem, inclusive, ser códigos proprietários, criados por uma organização implementadora para atender a uma necessidade que nenhum catálogo internacional cobre.

CodeSystem, ValueSet e ConceptMap: uma diferença rápida

Antes de seguir, vale situar o CodeSystem entre dois recursos vizinhos com os quais ele é frequentemente confundido — sem se aprofundar neles, já que o foco deste artigo é o CodeSystem em si:

• CodeSystem define o conjunto de códigos e o que cada um significa (o “dicionário”).
• ValueSet seleciona um subconjunto de códigos — possivelmente vindos de mais de um CodeSystem — que é válido para um campo específico em um contexto específico (por exemplo, “os únicos códigos de gênero aceitos neste campo”).
• ConceptMap define como códigos de um sistema se relacionam com códigos de outro sistema, permitindo tradução entre terminologias diferentes.

Cada um resolve um problema distinto, mas o CodeSystem é o ponto de partida: sem ele, não há o que selecionar em um ValueSet nem o que mapear em um ConceptMap.

Por que uma organização pode definir seu próprio CodeSystem

Nem toda informação codificada em um sistema de saúde tem um equivalente pronto em uma terminologia internacional. Às vezes a necessidade é específica de um país, de uma regulamentação local, ou até de um processo interno de uma única instituição. Nesses casos, a organização implementadora pode — e frequentemente deve — declarar seu próprio CodeSystem em uma URL que identifica de forma única aquele conjunto de códigos como pertencente a ela.

Um exemplo simplificado de um CodeSystem proprietário para um caso de uso — o tipo de teste usado para diagnosticar uma doença, informação que precisa acompanhar o resultado de um exame para que quem recebe o dado saiba exatamente qual metodologia foi usada:

json

{
  "resourceType": "CodeSystem",
  "url": "http://exemplo.saude.gov.br/fhir/CodeSystem/tipo-teste-diagnostico",
  "name": "TipoTesteDiagnostico",
  "status": "active",
  "content": "complete",
  "concept": [
    { "code": "RT-PCR", "display": "Reação em cadeia da polimerase via transcriptase reversa" },
    { "code": "TR-AG", "display": "Teste rápido de antígeno" },
    { "code": "SOROLOGICO", "display": "Teste sorológico (detecção de anticorpos)" }
  ]
}

Repare que esses códigos (RT-PCR, TR-AG, SOROLOGICO) não vêm de nenhuma terminologia internacional pronta — eles representam uma classificação que faz sentido dentro do domínio específico de quem definiu esse CodeSystem, e é justamente para isso que o recurso existe: dar nome formal a algo que o seu contexto precisa distinguir, mas que nenhum catálogo genérico cobre da forma como você precisa. Um recurso Observation que representa o resultado de um exame, por exemplo, referenciaria um desses códigos no campo que descreve o método usado — permitindo que qualquer sistema que receba esse resultado saiba, sem ambiguidade, que tipo de teste gerou aquele dado.

Exemplo real: os CodeSystems próprios da RNDS

Esse cenário não é hipotético. O Ministério da Saúde brasileiro, ao estruturar a RNDS (apresentada no artigo 1 deste guia), precisou declarar diversos CodeSystems próprios para cobrir necessidades específicas do contexto nacional — desde classificações de tipos de estabelecimento até categorias de eventos específicos da rede. Esses CodeSystems fazem parte do Implementation Guide técnico da RNDS, publicado oficialmente, e servem como referência de como uma iniciativa nacional de interoperabilidade complementa as terminologias internacionais com vocabulário próprio onde necessário.

Terminologias internacionais de referência

Vale deixar claro que o uso de CodeSystems proprietários não substitui as terminologias internacionais consolidadas — ele as complementa. Duas merecem menção, ainda que este guia não se aprofunde nelas:

• LOINC, mantida pela Regenstrief Institute, é a referência global para identificar exames laboratoriais e observações clínicas, e já é distribuída com uma representação oficial como CodeSystem FHIR.
• SNOMED CT é a terminologia clínica abrangente mais usada internacionalmente para descrever diagnósticos, procedimentos e achados clínicos, com estrutura hierárquica rica.

Na prática, um projeto de integração em saúde tipicamente combina: terminologias internacionais como essas para conceitos clínicos amplamente padronizados, e CodeSystems próprios para o que for específico do contexto local ou institucional.

O caso brasileiro fora da RNDS: TUSS e CBHPM

Além do cenário público representado pela RNDS, o mercado de saúde suplementar brasileiro tem seu próprio padrão normativo de codificação, que convive com integrações FHIR no setor privado: a TUSS (Terminologia Unificada da Saúde Suplementar), mantida pela ANS (Agência Nacional de Saúde Suplementar), construída com base na CBHPM (Classificação Brasileira Hierarquizada de Procedimentos Médicos). A TUSS padroniza os códigos usados por operadoras de planos de saúde e prestadores de serviço para identificar procedimentos, materiais e medicamentos em guias e faturamento.

Para quem trabalha com integrações FHIR envolvendo operadoras e prestadores no Brasil, é comum ver a TUSS representada como um CodeSystem próprio dentro de um Procedure, Claim ou recurso equivalente — mais um exemplo prático de como um padrão normativo nacional, que existe independentemente do FHIR, é incorporado à estrutura do padrão através do mecanismo de CodeSystem.