FHIR

1. O que é o FHIR, em palavras simples

O **Fast Healthcare Interoperability Resources (FHIR)** é um standard criado pela HL7 para facilitar a troca eletrónica de dados em saúde, de forma **estruturada, segura e interoperável**.

Ao contrário dos standards anteriores (HL7 v2 ou CDA), o FHIR foi desenhado para funcionar com **tecnologias web modernas**: utiliza formatos como **JSON ou XML**, é compatível com **REST APIs** e facilita a **integração entre sistemas clínicos, aplicações móveis e plataformas digitais**.

Em vez de enviar documentos longos e fechados, o FHIR organiza a informação em **recursos independentes e reutilizáveis**. Cada recurso representa uma entidade clínica (ex: um utente, um exame, uma prescrição), e pode ser transmitido, modificado ou consultado de forma autónoma.

Exemplo simples de recurso FHIR do tipo Patient:

<syntaxhighlight lang="json"> {

 "resourceType": "Patient",
 "id": "f001",
 "name": [{
   "family": "Smith",
   "given": ["John"]
 }],
 "gender": "male",
 "birthDate": "1990-01-01"

} </syntaxhighlight>

Este exemplo mostra como um utente pode ser representado digitalmente com uma estrutura clara e partilhável entre sistemas diferentes. **A simplicidade e flexibilidade desta abordagem tornam o FHIR particularmente relevante para a transformação digital da saúde.**

2. Porque é que o FHIR está no centro das atenções

O FHIR ganhou destaque por responder a um problema central da saúde digital: **a dificuldade em partilhar dados clínicos de forma estruturada e interoperável entre instituições, sistemas e países**.

Nos últimos anos, a interoperabilidade deixou de ser apenas uma exigência técnica. Tornou-se uma **prioridade política**. O regulamento do **Espaço Europeu de Dados de Saúde (EHDS)**, aprovado em 2025, obriga os Estados-Membros a garantir a partilha transfronteiriça de dados de saúde com base em standards abertos. O FHIR é, em grande parte, a tecnologia escolhida para dar resposta a esse desafio.

Além do contexto europeu, o FHIR destaca-se por apresentar uma solução alinhada com a prática atual da engenharia de software:

- **Utiliza formatos web nativos** como JSON, XML e protocolos REST - **Integra-se facilmente com aplicações móveis, APIs públicas e sistemas cloud** - **É modular e extensível**, permitindo adaptações nacionais ou institucionais - **Tem suporte ativo de comunidades técnicas, académicas e institucionais**, incluindo HL7 International, HL7 Europe e HL7 Portugal

Esta combinação de apoio político, flexibilidade técnica e adoção crescente nas principais infraestruturas de saúde faz do FHIR **o standard mais promissor e realista para construir um ecossistema europeu de dados de saúde verdadeiramente interoperável.**

Mais do que uma especificação, o FHIR representa uma **infraestrutura de referência para a arquitetura da informação clínica do futuro.**

3. Como funciona o FHIR

O FHIR organiza a informação em saúde através de **recursos estruturados**. Cada recurso representa uma entidade clínica ou administrativa — como um utente, um diagnóstico, uma consulta, uma prescrição — com campos bem definidos, extensíveis e reutilizáveis.

A base do FHIR assenta em três princípios técnicos fundamentais:

3.1 Recursos: unidades modulares de informação

Em vez de enviar um único documento com toda a informação, como num PDF ou num CDA, o FHIR parte os dados em **blocos reutilizáveis e relacionáveis** chamados *resources*. Exemplos de recursos:

- `Patient` (utente) - `Observation` (resultado de medição) - `Condition` (diagnóstico) - `Encounter` (episódio de contacto clínico) - `MedicationRequest` (prescrição)

Cada recurso tem um **identificador único**, uma **estrutura interna clara** e pode ser enviado ou consultado isoladamente.

3.2 API RESTful: ler, escrever e consultar

O FHIR foi desenhado para funcionar com **REST APIs**, o modelo mais comum de comunicação entre aplicações na web. Isso significa que os dados podem ser acedidos através de URLs simples:

<syntaxhighlight lang="bash"> GET /Patient/123 # obter dados do utente com ID 123 POST /Observation # criar nova observação PUT /Condition/456 # atualizar condição existente DELETE /Medication/789 # remover prescrição </syntaxhighlight>

Esta abordagem facilita a integração com plataformas clínicas, apps móveis e sistemas analíticos, de forma leve e escalável.

3.3 Formato: JSON legível e normalizado

A representação mais comum dos dados em FHIR é o **formato JSON**, que é:

- **Legível por humanos** - **Fácil de validar** - **Suportado por todas as linguagens de programação modernas**

<syntaxhighlight lang="json"> {

 "resourceType": "Observation",
 "id": "oximetria01",
 "status": "final",
 "code": {
   "coding": [{
     "system": "http://loinc.org",
     "code": "59408-5",
     "display": "Oximetria de pulso"
   }]
 },
 "valueQuantity": {
   "value": 98,
   "unit": "%",
   "system": "http://unitsofmeasure.org",
   "code": "%"
 }

} </syntaxhighlight>

Este exemplo representa uma oximetria de pulso com 98%, codificada em LOINC.

---

• • Resumindo:** o FHIR não é apenas um standard técnico. É uma arquitetura pensada para **comunicar informação clínica com estrutura, flexibilidade e semântica clara**, adaptável a diferentes sistemas e escalável em diferentes contextos.

4. Como interpretar um recurso FHIR

A compreensão de um recurso FHIR exige familiaridade com a sua **estrutura interna**, **campos principais**, e com a **forma como é descrito na documentação oficial**.

Nesta secção, utilizamos como exemplo o recurso `Patient`, um dos mais simples e frequentemente utilizados.

4.1 Anatomia básica de um recurso

Todo recurso FHIR é representado num **formato estruturado** (habitualmente JSON), e inclui:

- `resourceType`: indica o tipo de recurso (ex: "Patient") - `id`: identificador único dentro do servidor - `meta`: metadados técnicos - `text`: descrição legível (opcional) - Campos clínicos e administrativos (ex: `name`, `gender`, `birthDate`, `address`, `telecom`)

<syntaxhighlight lang="json"> {

 "resourceType": "Patient",
 "id": "john-smith-001",
 "name": [{
   "use": "official",
   "family": "Smith",
   "given": ["John"]
 }],
 "gender": "male",
 "birthDate": "1990-01-01"

} </syntaxhighlight>

4.2 Como ler a página oficial de um recurso

A documentação oficial de cada recurso FHIR está disponível em: https://hl7.org/fhir/R4/

Na página de cada recurso (ex: https://hl7.org/fhir/R4/patient.html), encontras:

- **Descrição funcional do recurso** - **Tabela com os elementos**, organizados por ordem hierárquica - Para cada elemento:

 - Nome  
 - Tipo de dado  
 - Cardinalidade (quantas vezes pode aparecer)  
 - Obrigatoriedade  
 - Comentários

Exemplo de linha interpretada:

| Elemento | Tipo | Card. | Descrição | |----------------|------------|-------|-----------------------------------------| | `name` | HumanName | 0..* | Nome(s) do paciente, podendo haver mais do que um | | `birthDate` | date | 0..1 | Data de nascimento, se conhecida | | `gender` | code | 0..1 | Sexo biológico (valores possíveis: male, female, other, unknown) |

4.3 O que significam os campos técnicos?

- **Cardinalidade**: define o número de ocorrências possíveis. Ex: `0..1` (opcional, único), `0..*` (lista opcional) - **Tipo**: o tipo de dado esperado (ex: string, date, boolean, Quantity, CodeableConcept) - **Binding**: quando o campo deve usar um conjunto de códigos predefinidos (ex: SNOMED, LOINC) - **Extensões**: permitem adicionar novos campos sem modificar o core do recurso

4.4 Referências entre recursos

Recursos podem referenciar outros recursos. Por exemplo, um `Observation` pode referir um `Patient` e um `Practitioner`. Isto cria **uma rede de dados relacionais**, com ligações explícitas:

<syntaxhighlight lang="json"> "subject": {

 "reference": "Patient/john-smith-001"

} </syntaxhighlight>

4.5 Ferramentas para explorar recursos

- [FHIR Resource Index](https://hl7.org/fhir/resourcelist.html): lista completa de recursos - [FHIR JSON Validator](https://simplifier.net/validate): validação técnica de instâncias - [FHIR Models](https://build.fhir.org): versão de desenvolvimento com comentários adicionais

---

• • Conclusão:**

Compreender um recurso FHIR é essencial para interpretar, validar ou construir soluções baseadas neste standard. Esta secção oferece as bases necessárias para navegar com segurança na documentação oficial e analisar qualquer recurso, mesmo os mais complexos.

5. Perfis e Implementation Guides: o que são e onde estão

Embora o FHIR forneça uma especificação base para representar entidades clínicas, cada país, instituição ou sistema pode ter requisitos específicos. Para acomodar essa diversidade, o FHIR introduz dois conceitos essenciais:

- **Perfis (Profiles)** - **Guias de Implementação (Implementation Guides, IGs)**

5.1 Perfis: adaptação da estrutura a contextos específicos

Um **perfil FHIR** define como um recurso padrão deve ser usado num determinado contexto. Pode:

- Tornar certos campos obrigatórios - Restringir os valores possíveis de um campo - Fixar terminologias (ex: SNOMED, ICD-10) - Adicionar extensões permitidas

Exemplo: um hospital pode definir que todo recurso `Observation` referente a glicemia deve sempre incluir a unidade `mg/dL`, codificada em LOINC.

Os perfis garantem **coerência, interoperabilidade e validação técnica** dentro de contextos nacionais ou institucionais.

5.2 Implementation Guides: conjuntos estruturados de perfis e regras

Um **Implementation Guide (IG)** é um documento técnico que:

- Reúne vários perfis organizados por tema - Define fluxos de informação (workflows) - Estabelece regras de validação e compatibilidade - Contém exemplos práticos e casos de uso

Os IGs são a principal forma de **especificar formalmente como o FHIR será usado numa realidade concreta**: desde um hospital, a um país, a um projeto europeu.

5.3 Onde encontrar perfis e IGs

Os principais repositórios públicos incluem:

- [Simplifier.net](https://simplifier.net) – comunidade global com milhares de perfis e IGs - [HL7 FHIR Registry](https://registry.fhir.org) – registo oficial de artefactos FHIR - [HL7 Portugal](https://hl7.pt) – documentos em português e adaptações nacionais - [EU X-eHealth FHIR IG](https://build.fsh-eu.dev) – guia europeu para interoperabilidade transfronteiriça

---

• • Resumo:**

Perfis e IGs são ferramentas fundamentais para tornar o FHIR aplicável ao mundo real. Permitem adaptar a especificação à realidade concreta dos cuidados de saúde, **garantindo interoperabilidade prática e orientada por contexto**.

6. FHIR e o futuro da interoperabilidade em saúde

A adoção de standards abertos para a interoperabilidade de dados em saúde deixou de ser apenas uma necessidade técnica. Tornou-se um imperativo político e institucional, com implicações estratégicas a nível nacional e europeu.

6.1 Interoperabilidade no centro da política europeia

O **Espaço Europeu de Dados de Saúde (EHDS)** foi oficialmente regulamentado a 26 de março de 2025, através do Regulamento (UE) 2025/914, publicado no Jornal Oficial da União Europeia. O EHDS estabelece uma estrutura legal para a partilha segura, eficiente e interoperável de dados de saúde em toda a União Europeia, tanto para fins assistenciais como secundários (investigação, políticas públicas, inovação).

O regulamento define que os Estados-Membros devem adotar **standards abertos e internacionalmente reconhecidos**. O FHIR, desenvolvido pela HL7, é identificado como uma das tecnologias preferenciais para operacionalizar esta interoperabilidade, particularmente na camada de transporte e representação de dados clínicos estruturados.

6.2 FHIR, openEHR e a arquitetura da saúde digital

Embora o FHIR tenha sido concebido como um standard flexível, baseado em tecnologias web, a sua aplicação a longo prazo tem sido objeto de análise comparativa com outros modelos, nomeadamente o **openEHR** e o **OMOP**.

Estudos recentes propõem uma arquitetura híbrida:

- O **FHIR** funciona como *camada de interoperabilidade*, orientada à troca de dados em tempo real, com uso extensivo de REST APIs, JSON e XML. - O **openEHR** é proposto como *camada semântica persistente*, dedicada à modelação clínica detalhada e armazenamento longitudinal de dados com integridade semântica. - O **OMOP CDM** (Observational Medical Outcomes Partnership Common Data Model) é sugerido como *camada analítica*, orientada a estudos populacionais e reutilização secundária de dados clínicos.

Este modelo trino tem sido defendido por autores como Kalra et al. (2022) e por diversas iniciativas europeias de interoperabilidade técnica e semântica.

6.3 A evolução da adoção em Portugal

Em Portugal, a interoperabilidade tem sido abordada por entidades como a **SPMS** e a **HL7 Portugal**, com iniciativas de formação, definição de perfis nacionais e desenvolvimento de protótipos de Guias de Implementação.

Está disponível publicamente um **Implementation Guide nacional** desenvolvido em FHIR: o *Community Health IG*, publicado no GitHub oficial da HL7 Portugal (hl7-pt.github.io). Este guia define perfis adaptados à realidade nacional em áreas como episódios comunitários, planeamento de cuidados e indicadores de saúde pública.

Apesar destes avanços, a **adoção efetiva do FHIR nas Unidades Locais de Saúde (ULS)** é ainda desigual. Algumas instituições já utilizam partes da especificação, outras mantêm sistemas proprietários com baixa interoperabilidade. O EHDS poderá ser um catalisador decisivo para harmonizar esta transição, desde que acompanhado por medidas de capacitação técnica, normalização semântica e financiamento sustentável.

6.4 Infraestrutura digital com base no FHIR

O FHIR destaca-se por:

- **Alinhamento com as práticas modernas de desenvolvimento web** - **Capacidade de extensão e adaptação a diferentes contextos** - **Elevado suporte comunitário, técnico e institucional** - **Facilidade de integração com sistemas existentes através de APIs**

Estes fatores tornam o FHIR um **elemento central da arquitetura digital da saúde na próxima década**, especialmente em ambientes onde é necessário interoperar entre sistemas heterogéneos, serviços em nuvem e aplicações móveis.

O seu sucesso dependerá da forma como for integrado em ecossistemas mais amplos de governação de dados, ontologias clínicas, repositórios semânticos e ambientes analíticos. A coexistência e articulação com modelos como o openEHR e o OMOP deverá ser encarada como uma oportunidade estratégica para a Europa — e para Portugal — construir infraestruturas digitais sustentáveis, seguras e cientificamente robustas.

7. Glossário e ferramentas para aprender mais

7.1 Glossário essencial

Termo técnico	Significado
**Resource**	Unidade modular de informação no FHIR (ex: Patient, Observation, Encounter)
**Bundle**	Conjunto de recursos agrupados e enviados juntos, geralmente numa transação
**Reference**	Campo que aponta para outro recurso (ex: uma Observation refere um Patient)
**Profile**	Conjunto de restrições e especificações adicionais aplicadas a um recurso FHIR
**Implementation Guide (IG)**	Documento técnico que reúne perfis, fluxos, terminologias e exemplos práticos
**CodeableConcept**	Tipo de dado usado para representar conceitos com codificação e termos legíveis
**Extension**	Mecanismo oficial do FHIR para adicionar campos fora da especificação base
**Cardinalidade**	Número de vezes que um elemento pode ocorrer (ex: 0..1, 0..*)
**REST API**	Interface de programação baseada em HTTP usada para aceder, criar e modificar recursos FHIR

7.2 Ferramentas úteis

- **Documentação oficial HL7 FHIR**

 [1](https://hl7.org/fhir)

- **FHIR Resource Index** (lista de todos os recursos)

 [2](https://hl7.org/fhir/resourcelist.html)

- **Validadores de recursos**

 - [3](https://validator.fhir.org)  
 - [4](https://simplifier.net/validate)

- **Repositórios de perfis e IGs**

 - [5](https://simplifier.net)  
 - [6](https://registry.fhir.org)  
 - [7](https://hl7-pt.github.io)

7.3 Exercício prático sugerido

• • Objetivo:** compreender a articulação entre diferentes recursos FHIR num episódio clínico simples.

• • Tarefa:** representar em JSON simplificado um cenário em que:

- Um paciente realiza uma consulta (Encounter) - É registada uma medição de tensão arterial (Observation) - Ambos os recursos estão ligados por referência ao mesmo Patient

• • Desafio adicional:** validar os recursos criados num dos validadores disponíveis online.

8. Fontes e referências

Documentos oficiais e institucionais

- Comissão Europeia. *Regulamento (UE) 2025/914 do Parlamento Europeu e do Conselho, de 26 de março de 2025, relativo ao Espaço Europeu de Dados de Saúde*. Jornal Oficial da União Europeia, L 2025/914.

 [8](https://eur-lex.europa.eu/legal-content/PT/TXT/?uri=CELEX:32025R0914)

- HL7 International. *FHIR R4 – Especificação Oficial*.

 [9](https://hl7.org/fhir)

- HL7 Portugal. *Community Health Implementation Guide*.

 [10](https://hl7-pt.github.io/community-health-ig)

- HL7 Europe e IHE-Europe. *Joint Initiatives for the EHDS*.

 [11](https://hl7europe.org)

- SPMS. *Registo de Saúde Eletrónico Unificado (RSE)*. Serviços Partilhados do Ministério da Saúde.

 [12](https://www.spms.min-saude.pt)

Artigos científicos e técnicos

- Kalra D, Beale T, et al. *Interoperability Architectures: FHIR, openEHR and OMOP Compared*. JMIR Med Inform. 2022;10(6):e37545.

 [13](https://www.jmir.org/2022/6/e37545)

- Benson T, Grieve G. *Principles of Health Interoperability: SNOMED CT, HL7 and FHIR*. Springer, 4.ª ed., 2021.

Ferramentas e recursos comunitários

- Simplifier.net — Repositório comunitário de perfis e exemplos

 [14](https://simplifier.net)

- FHIR Validator — Validador oficial da HL7

 [15](https://validator.fhir.org)

- FHIR IG Registry — Repositório de Implementation Guides oficiais

 [16](https://registry.fhir.org)