Análise de Perfis FHIR na RNDS
Uma abordagem bottom-up para compreender a arquitetura de dados da Rede Nacional de Dados em Saúde (RNDS), suas interdependências de perfis e os desafios para o desenvolvimento de software no SUS.
Recurso FHIR Observation Base & Reconhecimento de Chaves
Entendendo o bloco básico e a validação de elementos no padrão FHIR
Na especificação padrão do HL7 FHIR, a estrutura mínima de um recurso é extremamente flexível.
Para que um payload seja considerado um recurso FHIR Observation sintaticamente válido pela
especificação base, basta declarar o seu tipo:
{
"resourceType": "Observation"
}Chaves Reconhecidas vs. Não Reconhecidas pelo Padrão FHIR
A especificação do FHIR possui um esquema estruturado estrito. O padrão diferencia categoricamente as chaves (propriedades) que um servidor FHIR aceita:
{
"resourceType": "Observation",
"status": "final", ✔️ Chave Reconhecida (Elemento Nativo FHIR)
"cpfPaciente": "12345678900" ❌ Chave Não Reconhecida (Atributo Extra Fora do Padrão)
}| Tipo de Chave | Definição no FHIR | Exemplo | Comportamento do Servidor FHIR |
|---|---|---|---|
| Chave Reconhecida | Propriedade oficial definida na especificação nativa do FHIR para o recurso. | "status": "final" ou "issued": "2026-08-20..." |
Aceita e validada conforme as regras de cardinalidade e tipo de dado do FHIR. |
| Chave Não Reconhecida | Propriedade customizada inventada que não existe na especificação do recurso. | "cpfPaciente": "12345678900" ou "nomePosto": "UBS Centro" |
Rejeitada por parsers FHIR estritos. Dados customizados devem ser inseridos
obrigatoriamente através do elemento nativo extension. |
💡 O Motivo para os Perfis: Embora o JSON mínimo seja válido, ele não possui dados clínicos. E tentar adicionar dados criando chaves diretas gera chaves não reconhecidas que quebram o padrão. Para estender e obrigar campos específicos de forma válida, utilizamos os Perfis FHIR.
O que um Perfil FHIR define?
Restringindo recursos com chaves Obrigatórias, Opcionais e Proibidas
Um Perfil FHIR (StructureDefinition) estende ou restringe o recurso base para um contexto de uso específico (como a RNDS no Brasil). Ele estabelece regras rígidas sobre as chaves do JSON:
{
"resourceType": "Observation", 1..1 Obrigatória
"status": "final", 1..1 Obrigatória
"code": { "coding": [...] }, 1..1 Obrigatória
"subject": { "reference": "..." }, 0..1 Opcional
"effectiveDateTime": "2026-08", 0..1 Opcional
"bodySite": null 0..0 Proibida
}| Tipo de Chave | Cardinalidade | Significado no Perfil RNDS | Exemplo |
|---|---|---|---|
| Obrigatória | 1..1 ou 1..* |
O campo deve obrigatoriamente estar presente no payload. Se ausente, o servidor da RNDS rejeita. | resourceType, status, code |
| Opcional | 0..1 ou 0..* |
O campo pode ser omitido caso o sistema de origem não possua a informação. | subject, effectiveDateTime |
| Proibida | 0..0 |
O campo é expressamente proibido no perfil para evitar redundância ou inconsistência. | bodySite (em certos exames laboratoriais) |
Modelos Computacionais da RNDS
Organização dos Perfis para o SUS
Para construir softwares interoperáveis para o SUS, os perfis da RNDS não ficam soltos; eles são agrupados em Modelos Computacionais (casos de uso de negócio). O modelo BR-Core atua como o núcleo estrutural compartilhado por todos os demais modelos clínicos (RAC, REL, RIA, etc.).
Contém os perfis básicos transversais (Indivíduo, Profissional, Estabelecimento, Lotação) reaproveitados por todos os outros modelos da RNDS.
Modelo BR-Core (Estudo do Matheus)
Mapeamento de Perfis e Dependências Internas
Ao estudar os perfis do BR-Core, descobrimos uma forte dependência em cadeia. Um perfil de Diagnóstico não existe de forma isolada; ele referencia Indivíduo, Estabelecimento, Profissional e Amostra.
Modelo RAC (Estudo do Henrique)
Registro de Atendimento Clínico e Dependência Cruzada com o BR-Core
O modelo RAC (Registro de Atendimento Clínico) é um documento composto
(Composition) que agrega múltiplos eventos de um atendimento.
Ele introduz novos perfis que, por sua vez, herdam e exigem perfis do BR-Core, tornando o gráfico de
dependências ainda mais complexo.
Impacto da Atualização do BR-Core (Julho / 2026)
Mudanças recentes na especificação oficial da RNDS
Atenção: Nova Versão do BR-Core Lançada em Julho de 2026
Durante a elaboração do nosso estudo, a RNDS publicou uma versão atualizada do modelo BR-Core. Como o BR-Core forma a base do RAC e de todos os outros modelos, alterações em cardinalidades ou em referências de ValueSets no BR-Core propagam-se imediatamente para os perfis do RAC.
Consequência no Projeto: Foi necessário revalidar todos os mapeamentos prévios de DTOs e validar se as dependências do RAC ainda utilizam os identificadores canonicals corretos da versão recente.
Definição do Subconjunto Prático de Perfis
Simulador Interativo de Dependências Mínimas para Desenvolvimento
Para viabilizar a implementação do software sem precisar codificar os dezenas de perfis da RNDS de uma só vez, definimos o Subconjunto Mínimo Viável. Marque abaixo quais funcionalidades seu software precisa suportar e veja automaticamente quais Perfis FHIR você precisa implementar: