Nos dois primeiros artigos, tratamos do FHIR em nível conceitual: o problema que ele resolve e como consegue ser lido tanto por desenvolvedores quanto por profissionais de saúde. Chegou a hora de começar a descer um degrau em direção ao técnico — e o ponto de partida mais natural é entender como, afinal, um recurso FHIR é efetivamente representado quando trafega entre sistemas.
Três formatos, uma mesma especificação
A especificação FHIR não define um único formato de serialização. Ela suporta três: JSON, XML e RDF/Turtle. Isso costuma gerar uma dúvida comum em quem está começando — “afinal, qual eu devo usar?” —, e a resposta depende bastante do contexto em que a integração acontece.
JSON: o formato dominante em implementações modernas
Na grande maioria das implementações atuais, JSON é a escolha de fato. As razões são bastante práticas: é o formato nativo de comunicação de APIs REST modernas, é mais leve para transporte do que XML (menos caracteres de marcação, sem tags de fechamento redundantes), e praticamente qualquer linguagem de programação moderna tem suporte de primeira classe para gerar e consumir JSON sem bibliotecas adicionais. Quando você olha para um serviço gerenciado de nuvem ou para uma implementação de referência como o HAPI FHIR (que veremos em detalhe mais adiante neste guia), o padrão de resposta default quase sempre é JSON.
XML: a herança que ainda aparece em integrações legadas
XML tem uma relação mais antiga com o mundo HL7. Ele é herdeiro direto da tradição do HL7 v3 e do CDA (Clinical Document Architecture), que representavam documentos clínicos inteiros em XML muito antes do FHIR existir. Por isso, XML ainda aparece com frequência em contextos regulatórios que exigem validação contra esquemas XSD rígidos, ou em integrações com sistemas legados que já falam XML nativamente e para os quais migrar para JSON não é uma prioridade imediata. Não é incomum encontrar, no Brasil e fora dele, integrações governamentais ou institucionais que ainda pedem XML como formato de troca — geralmente por continuidade histórica, não porque XML ofereça alguma vantagem técnica exclusiva sobre JSON no contexto do FHIR.
RDF/Turtle: para quando o dado precisa “significar” algo além de si mesmo
O terceiro formato, RDF (Resource Description Framework), serializado tipicamente em Turtle, é o menos usado no dia a dia — e também o mais mal compreendido por quem está começando. Ele existe para cenários de dados vinculados (linked data), onde a informação não é só transportada, mas também relacionada semanticamente a ontologias e vocabulários formais, permitindo consultas via SPARQL (a linguagem de consulta do mundo RDF). Esse cenário costuma aparecer em pesquisa acadêmica, em iniciativas de dados abertos governamentais mais avançadas, ou em contextos onde se quer inferir relações entre dados de saúde além do que a própria estrutura FHIR expõe diretamente. Para a grande maioria dos projetos de integração comerciais e institucionais, RDF/Turtle não entra no radar — mas vale saber que ele existe e por que a HL7 o incluiu na especificação.
O ponto que mais confunde: a estrutura lógica não muda
Aqui está o detalhe mais importante deste artigo, e também o que mais gera confusão em quem está aprendendo FHIR: o formato de serialização é só a “embalagem” do dado — a estrutura lógica do recurso é idêntica nos três formatos. Os mesmos elementos existem, com a mesma cardinalidade, seguindo as mesmas regras de validação da especificação, independentemente de você estar olhando para um JSON, um XML ou um Turtle. Nada no significado do recurso muda; muda apenas a sintaxe usada para representá-lo.
Para tornar isso concreto, veja o mesmo recurso Patient simplificado — um paciente chamado Maria, com um identificador de nascimento — representado nos três formatos:
JSON:
{
"resourceType": "Patient",
"id": "exemplo-1",
"name": [
{ "text": "Maria Aparecida da Silva" }
],
"birthDate": "1985-03-22"
}
XML:
<Patient xmlns="http://hl7.org/fhir">
<id value="exemplo-1"/>
<name>
<text value="Maria Aparecida da Silva"/>
</name>
<birthDate value="1985-03-22"/>
</Patient>
Turtle (RDF):
[] a fhir:Patient ;
fhir:Patient.id [ fhir:value "exemplo-1" ] ;
fhir:Patient.name [
fhir:Patient.name.text [ fhir:value "Maria Aparecida da Silva" ]
] ;
fhir:Patient.birthDate [ fhir:value "1985-03-22" ] .
Repare: o recurso é Patient, o identificador é exemplo-1, o nome é o mesmo texto, a data de nascimento é a mesma — em todos os três casos. O que muda é exclusivamente a sintaxe de representação. Um sistema que recebe esse recurso em JSON e outro que recebe em XML estão, na prática, recebendo exatamente a mesma informação clínica, só que empacotada de formas diferentes.
Conclusão prática
Na dúvida sobre qual formato usar em um projeto novo, JSON costuma ser a escolha segura e mais alinhada ao que o ecossistema FHIR atual pratica — é o que a maioria dos servidores, bibliotecas e serviços de nuvem trata como padrão. XML entra em cena quando alguém do outro lado da integração exige por motivos legados ou regulatórios. RDF/Turtle é a exceção, reservada a cenários semânticos avançados que a maioria dos times de engenharia atuando com saúde não vai encontrar no trabalho do dia a dia — mas que vale reconhecer como parte legítima da especificação.
