Serviços

A integração com a RNDS acontece por serviços web REST sobre FHIR R4. Os caminhos abaixo são relativos ao host do ambiente que muda entre homologação e produção, e em produção varia por UF. Veja em ambientes.

Segurança

Obtenção de token e de contexto assistencial.

Método	Caminho	O que faz
POST	/api/contexto-atendimento	Contexto de atendimento Obtém o token de autorização de contexto de atendimento, exigido para acessar dados clínicos de um indivíduo sob um vínculo assistencial.
GET	/api/token	Obter token de acesso Troca a autenticação mútua TLS (mTLS, com certificado ICP-Brasil A1) por um token de acesso JWT. É a primeira chamada de qualquer integração.

Saúde

Consulta de entidades e envio de documentos clínicos.

Método	Caminho	O que faz
POST	/api/fhir/r4/Bundle	Atualizar documento clínico Substitui um documento enviado anteriormente. Documentos clínicos são imutáveis por conceito: a correção não edita o original, gera um novo que o substitui.
POST	/api/fhir/r4/Bundle	Submeter documento clínico Envia um documento clínico como Bundle do tipo `document`. É o serviço central da integração, a primeira entrada do Bundle precisa ser obrigatoriamente um Composition.
GET	/api/fhir/r4/Organization	Consultar estabelecimento Obtém informações sobre o estabelecimento de saúde ou organização, tipicamente a partir do CNES.
GET	/api/fhir/r4/Patient	Consultar paciente Obtém informações sobre o indivíduo (paciente).
GET	/api/fhir/r4/Practitioner	Consultar profissional Obtém informações sobre o profissional de saúde.
GET	/api/fhir/r4/PractitionerRole	Consultar papel do profissional Obtém informações sobre os papéis desempenhados pelo profissional de saúde, incluindo o vínculo com o estabelecimento e a ocupação (CBO).

Conferido em 26/08/2026.

A ordem das chamadas

Toda integração segue a mesma sequência:

1. GET /api/token apresentando o certificado A1 em mTLS → devolve um JWT
2. POST /api/fhir/r4/Bundle com o token no header X-Authorization-Server → envia o documento

Para acessar dados clínicos de um indivíduo, entra um passo a mais: o POST /api/contexto-atendimento, que produz o token de autorização de contexto assistencial. A RNDS não entrega dado clínico sem vínculo de atendimento declarado.

O header não é Authorization

O barramento espera X-Authorization-Server. Usar o Authorization convencional é o erro mais comum da primeira tentativa, e a mensagem de erro resultante costuma ser genérica e não apontar o header. Veja autenticação.

Documento clínico é imutável

Repare que “atualizar” também é um POST de Bundle, não um PUT. Isso não é descuido de API: conceitualmente, um documento clínico é um instantâneo assinado. Correção não edita o documento original, gera um novo que substitui o anterior.

Se o seu modelo de dados assume atualização em campo, essa é uma diferença de desenho que vale acertar antes de escrever código.

Onde está o contrato completo

Esta página é um índice. Os contratos de serviço detalhados, os códigos de erro e o comportamento de cada operação estão no Manual de Integração do Barramento, publicado em PDF aberto pelo DATASUS:

SOA-RNDS_ManualIntegracaoBarramento_vSite.pdf

Confira a data no cabeçalho antes de confiar: circulam versões antigas do mesmo arquivo.

Para ver a forma exata das requisições antes de ter acesso, a coleção Postman do kyriosdata/rnds é excelente material de leitura.