Imagine a seguinte cena: um médico e um desenvolvedor sentados lado a lado, olhando para os mesmos dados de um paciente. O médico precisa entender rapidamente o histórico clínico para tomar decisões. O desenvolvedor precisa processar essas informações em um sistema automatizado. Tradicionalmente, esses dois profissionais precisariam de representações completamente diferentes dos mesmos dados – uma interface gráfica amigável para o médico, e estruturas de dados complexas para o desenvolvedor.
O FHIR (Fast Healthcare Interoperability Resources) quebra esse paradigma de forma elegante, pois foi projetado não apenas para permitir o processamento computacional dos dados, mas também para garantir que humanos em ambas as pontas da troca de informações consigam ter uma visão completa do que está acontecendo.
Neste artigo, vamos explorar como o FHIR consegue essa façanha: ser simultaneamente compreensível para médicos que nunca viram uma linha de código e para desenvolvedores que precisam processar milhares de registros automaticamente.
A Dualidade do FHIR: Máquina e Humano
O grande diferencial do FHIR está em sua abordagem dual. Os Resources do FHIR são projetados para compartilhar dados de maneira computável – permitindo apoio à decisão, análise de tendências e processamento automatizado – mas também incluem uma narrativa legível por humanos que garante que pessoas possam compreender completamente o contexto clínico.
Essa narrativa (chamada de “narrative” na especificação) deve existir para a maioria dos Resources. Em alguns casos, ela é gerada automaticamente a partir dos dados estruturados. Em outros, pode ser texto livre inserido diretamente por um profissional, como cartas de encaminhamento ou laudos de patologia.
Resources como Formulários Universais
Continuando com a metáfora apresentada na especificação oficial: pense nos Resources como formulários de papel. Cada tipo de informação clínica tem seu próprio formulário – um para alergias, um para prescrições, um para sinais vitais. Mas diferente de formulários tradicionais, os Resources do FHIR têm duas seções principais:
- A parte narrativa: Um resumo em linguagem natural, como se fosse anotado à mão
- A parte estruturada: Campos organizados que computadores podem processar
Essa dupla representação é o que torna o FHIR único e poderoso.
A Linguagem Comum: JSON e XML Legíveis
O FHIR utiliza formatos amplamente conhecidos – JSON e XML – mas de uma forma especialmente legível. Os nomes dos campos são descritivos e intuitivos. Mesmo alguém sem conhecimento técnico profundo consegue identificar elementos como “name” (nome), “birthDate” (data de nascimento) ou “status” (status).
Exemplo 1: Lendo Dados de um Paciente
Vamos começar com um exemplo real de como os dados de um paciente aparecem no formato FHIR. Este é um Resource do tipo Patient:
{
"resourceType": "Patient",
"id": "exemplo-paciente-001",
"text": {
"status": "generated",
"div": "<div xmlns='http://www.w3.org/1999/xhtml'>
<p><b>Maria Silva Santos</b> (nome social: Maria Santos)</p>
<p>Identificação: CPF 123.456.789-00</p>
<p>Telefone: (85) 98765-4321 (celular)</p>
<p>Sexo: Feminino | Data de nascimento: 15/03/1985 (39 anos)</p>
<p>Endereço: Rua das Flores, 123, Apto 45 - Centro, Fortaleza, CE, 60000-000</p>
</div>"
},
"identifier": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "TAX",
"display": "CPF"
}
]
},
"value": "12345678900"
}
],
"name": [
{
"use": "official",
"family": "Silva Santos",
"given": ["Maria"]
},
{
"use": "usual",
"family": "Santos",
"given": ["Maria"]
}
],
"telecom": [
{
"system": "phone",
"value": "(85) 98765-4321",
"use": "mobile"
}
],
"gender": "female",
"birthDate": "1985-03-15",
"address": [
{
"use": "home",
"type": "physical",
"line": ["Rua das Flores, 123, Apto 45"],
"city": "Fortaleza",
"state": "CE",
"postalCode": "60000-000",
"country": "BR"
}
]
}
Como um médico lê isso:
Se esse médico receber apenas esses dados (sem uma interface gráfica), ele pode imediatamente olhar para a seção text e encontrar um resumo formatado e legível: “Maria Silva Santos, CPF 123.456.789-00, 39 anos, feminino, residente em Fortaleza”. Todas as informações essenciais estão ali, em português claro, sem necessidade de entender estruturas de dados.
Como um desenvolvedor lê isso:
O desenvolvedor olha para os mesmos dados e vê estrutura: o campo gender pode alimentar estatísticas demográficas, birthDate permite cálculos de idade automatizados, identifier possibilita buscar outros registros desse paciente em diferentes sistemas. Os dados estão padronizados e prontos para processamento.
A mágica: Ambos estão olhando para exatamente o mesmo arquivo. Não há tradução necessária.
Exemplo 2: Compreendendo Resultados de Exames
Agora vejamos um exemplo mais complexo: resultados de exames laboratoriais. Este é um Resource do tipo Observation:
{
"resourceType": "Observation",
"id": "hemoglobina-glicada-001",
"text": {
"status": "generated",
"div": "<div xmlns='http://www.w3.org/1999/xhtml'>
<p><b>Hemoglobina Glicada (HbA1c)</b></p>
<p>Paciente: Maria Silva Santos</p>
<p>Data da coleta: 10 de outubro de 2025</p>
<p>Resultado: <b>7.8%</b></p>
<p>Valor de referência: 4.0 - 6.0% (Normal)</p>
<p><b>Interpretação: ACIMA DO VALOR DE REFERÊNCIA</b></p>
<p>Observação: Resultado sugere controle glicêmico inadequado.
Avaliar ajuste terapêutico.</p>
</div>"
},
"status": "final",
"category": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/observation-category",
"code": "laboratory",
"display": "Laboratory"
}
]
}
],
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "4548-4",
"display": "Hemoglobin A1c/Hemoglobin.total in Blood"
}
],
"text": "Hemoglobina Glicada"
},
"subject": {
"reference": "Patient/exemplo-paciente-001",
"display": "Maria Silva Santos"
},
"effectiveDateTime": "2025-10-10T08:30:00-03:00",
"issued": "2025-10-10T14:20:00-03:00",
"valueQuantity": {
"value": 7.8,
"unit": "%",
"system": "http://unitsofmeasure.org",
"code": "%"
},
"interpretation": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation",
"code": "H",
"display": "High"
}
],
"text": "Acima do valor de referência"
}
],
"referenceRange": [
{
"low": {
"value": 4.0,
"unit": "%"
},
"high": {
"value": 6.0,
"unit": "%"
},
"text": "Faixa normal para adultos não diabéticos"
}
],
"note": [
{
"text": "Resultado sugere controle glicêmico inadequado. Avaliar ajuste terapêutico."
}
]
}
Perspectiva do médico:
Ao abrir esse arquivo, o médico vai direto à seção narrativa e lê: “Hemoglobina Glicada de 7.8%, acima do valor de referência (4.0-6.0%), resultado sugere controle glicêmico inadequado”. Ele tem todas as informações clínicas relevantes para tomar uma decisão, incluindo a interpretação e a recomendação.
Perspectiva do desenvolvedor:
O desenvolvedor vê que valueQuantity.value contém 7.8, interpretation indica “H” (High), e code.coding usa LOINC “4548-4” – um código padronizado internacionalmente. Isso permite que o sistema:
- Compare automaticamente com valores de referência
- Agrupe todos os exames de HbA1c do paciente ao longo do tempo
- Acione alertas se valores estiverem críticos
- Gere gráficos de evolução
A convergência: Quando médico e desenvolvedor discutem esse caso, ambos podem referenciar os mesmos elementos. O médico pode dizer “o valor está em 7.8%” e o desenvolvedor sabe exatamente onde encontrar isso nos dados. O desenvolvedor pode mencionar “o código LOINC 4548-4” e o médico, mesmo sem conhecer LOINC profundamente, vê na narrativa que é Hemoglobina Glicada.
Exemplo 3: Prescrição Médica
Vejamos como uma prescrição se parece no FHIR, usando o Resource MedicationRequest:
{
"resourceType": "MedicationRequest",
"id": "prescricao-metformina-001",
"text": {
"status": "generated",
"div": "<div xmlns='http://www.w3.org/1999/xhtml'>
<p><b>Prescrição de Medicamento</b></p>
<p>Paciente: Maria Silva Santos</p>
<p>Medicamento: <b>Metformina 850mg - comprimidos</b></p>
<p>Posologia: Tomar 1 comprimido por via oral, 2 vezes ao dia,
durante as refeições (café da manhã e jantar)</p>
<p>Quantidade: 60 comprimidos</p>
<p>Refil: Permitido 3 refis</p>
<p>Prescritor: Dr. João Oliveira (CRM-CE 12345)</p>
<p>Data: 10 de outubro de 2025</p>
<p>Justificativa: Controle de diabetes mellitus tipo 2 com
HbA1c elevada (7.8%)</p>
</div>"
},
"status": "active",
"intent": "order",
"medicationCodeableConcept": {
"coding": [
{
"system": "http://www.whocc.no/atc",
"code": "A10BA02",
"display": "Metformin"
}
],
"text": "Metformina 850mg"
},
"subject": {
"reference": "Patient/exemplo-paciente-001",
"display": "Maria Silva Santos"
},
"authoredOn": "2025-10-10T14:30:00-03:00",
"requester": {
"reference": "Practitioner/medico-joao-001",
"display": "Dr. João Oliveira (CRM-CE 12345)"
},
"reasonCode": [
{
"text": "Diabetes mellitus tipo 2 com controle glicêmico inadequado"
}
],
"dosageInstruction": [
{
"sequence": 1,
"text": "Tomar 1 comprimido por via oral, 2 vezes ao dia, durante as refeições",
"timing": {
"repeat": {
"frequency": 2,
"period": 1,
"periodUnit": "d"
}
},
"route": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "26643006",
"display": "Oral route"
}
]
},
"doseAndRate": [
{
"doseQuantity": {
"value": 1,
"unit": "comprimido",
"system": "http://unitsofmeasure.org"
}
}
]
}
],
"dispenseRequest": {
"numberOfRepeatsAllowed": 3,
"quantity": {
"value": 60,
"unit": "comprimido"
},
"expectedSupplyDuration": {
"value": 30,
"unit": "dias"
}
}
}
Como o médico interpreta:
Lendo a narrativa, o médico vê imediatamente: “Prescrição de Metformina 850mg, 1 comprimido 2x ao dia durante refeições, para Maria Silva Santos, com justificativa de diabetes com HbA1c elevada”. É como ler uma receita tradicional, mas em formato digital.
Como o farmacêutico processa:
O farmacêutico (que também não é programador) consegue ver todas as informações necessárias para dispensação: quantidade (60 comprimidos), número de refis (3), posologia clara. Não precisa de sistema especial para entender.
Como o sistema automatiza:
O sistema de farmácia pode automaticamente:
- Verificar interações medicamentosas usando o código ATC “A10BA02”
- Validar se a quantidade prescrita está adequada à posologia (60 comprimidos para 30 dias, 2x ao dia = correto)
- Alertar quando os refis estiverem esgotados
- Conectar a prescrição ao diagnóstico do paciente
A comunicação fluida: Durante uma discussão sobre o caso, o médico, o farmacêutico e o desenvolvedor do sistema podem todos referenciar esses mesmos dados. O médico fala “prescrevi 2x ao dia”, o farmacêutico confirma, e o desenvolvedor sabe que isso está em dosageInstruction.timing.repeat.
A Ponte da Compreensão Mútua
O que torna o FHIR especial não é apenas ter dados estruturados ou apenas ter texto legível – é ter ambos, juntos, no mesmo lugar. Como explica a especificação oficial, a narrativa é esperada para a maioria dos Resources, podendo ser omitida apenas em circunstâncias limitadas.
Isso cria um ambiente onde:
Médicos podem auditar sistemas: Se um médico desconfia que o sistema interpretou algo incorretamente, ele pode olhar os dados brutos e verificar. Não há “caixa preta”.
Desenvolvedores entendem o contexto clínico: Ao ver a narrativa junto com os dados estruturados, desenvolvedores compreendem o significado clínico real do que estão processando.
Reguladores podem fiscalizar: Auditores e reguladores podem verificar tanto a precisão técnica (dados estruturados) quanto a clareza clínica (narrativa) sem precisar de ferramentas especializadas.
Pacientes podem compreender seus dados: Com acesso crescente aos próprios registros médicos, pacientes podem ler a narrativa e entender o que está documentado sobre sua saúde.
Conclusão
O FHIR resolve um problema fundamental que existia há décadas na área de saúde: a desconexão entre a representação de dados para humanos e para máquinas. Ao unir narrativa legível e estrutura processável no mesmo artefato, o padrão cria uma linguagem comum que técnicos e não-técnicos podem compartilhar.
Principais benefícios dessa abordagem:
- Transparência total: Não há informações “escondidas” em formatos proprietários
- Redução de erros de interpretação: Todos veem os mesmos dados da mesma fonte
- Facilita colaboração: Médicos e desenvolvedores podem discutir casos específicos usando a mesma referência
- Empoderamento do paciente: Dados de saúde tornam-se compreensíveis para quem mais importa
- Auditabilidade: Processos de conformidade e qualidade podem verificar tanto aspectos técnicos quanto clínicos
Considerações importantes:
- A narrativa é essencial: Implementações que negligenciam a parte narrativa perdem grande parte do valor do FHIR
- Contexto cultural: Narrativas devem ser localizadas adequadamente para cada idioma e contexto
- Equilíbrio entre automação e compreensão: O ideal é que narrativas sejam geradas automaticamente quando possível, mas permitam enriquecimento manual quando necessário
O verdadeiro poder do FHIR não está apenas em ser um padrão técnico robusto – está em ser uma ponte de comunicação entre mundos que historicamente falavam línguas diferentes. Quando um médico e um desenvolvedor podem sentar lado a lado, olhar para os mesmos dados JSON, e ambos entenderem o que estão vendo – cada um em seu próprio nível de profundidade – algo fundamental mudou no ecossistema de saúde digital.
Para explorar mais sobre FHIR, recomendo começar pelos Resources mais comuns (Patient, Observation, MedicationRequest) disponíveis na especificação oficial, sempre observando como a narrativa e os dados estruturados trabalham juntos para criar essa compreensão universal.
Referências
- HL7 FHIR Specification v5.0.0 – FHIR Overview – Clinicians. Disponível em: https://www.hl7.org/fhir/overview-clinical.html
- HL7 FHIR Specification v5.0.0 – FHIR Overview. Disponível em: https://www.hl7.org/fhir/overview.html
- HL7 FHIR Specification v5.0.0 – Narrative Documentation. Disponível em: https://www.hl7.org/fhir/narrative.html