FHIR: diferenças entre revisões

Fonte: aprendis
Saltar para a navegaçãoSaltar para a pesquisa
Sem resumo de edição
Sem resumo de edição
 
(Há 11 edições intermédias do mesmo utilizador que não estão a ser apresentadas)
Linha 1: Linha 1:
=== 1. Introdução ===
=== 1. O que é o FHIR, em palavras simples ===


A crescente informatização dos sistemas de saúde tem vindo a expor um problema estrutural: os dados clínicos continuam, frequentemente, isolados em sistemas fechados, pouco comunicantes, desenvolvidos em tecnologias desatualizadas. Esta fragmentação prejudica o acesso oportuno à informação, compromete a continuidade dos cuidados e dificulta a inovação digital.
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'''.


É neste contexto que surge o standard '''Fast Healthcare Interoperability Resources (FHIR)''', desenvolvido pela '''HL7 International'''. O FHIR propõe uma nova abordagem para a interoperabilidade em saúde, baseada em princípios modernos da web, como o uso de '''APIs RESTful''' e a representação de dados em '''JSON''' ou '''XML'''.
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**.


{| class="wikitable" style="background-color:#f9f9f9"
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.
| '''Nota de enquadramento:'''
O FHIR é hoje considerado o standard mais promissor na construção de sistemas de saúde verdadeiramente interoperáveis, modulares e adaptáveis a múltiplos contextos — desde grandes hospitais a aplicações móveis.
|}


Ao contrário dos modelos centrados em documentos pesados, o FHIR organiza a informação em '''recursos'''. Cada recurso representa uma unidade fundamental da realidade clínica ou administrativa, como um '''utente''', uma '''observação''', uma '''prescrição''' ou um '''episódio de internamento'''. Estes recursos podem ser consultados, combinados ou atualizados através de chamadas simples a partir de qualquer sistema compatível.
Exemplo simples de recurso FHIR do tipo Patient:


==== 1.1 O que se aprende nesta página ====
<syntaxhighlight lang="json">
{
  "resourceType": "Patient",
  "id": "f001",
  "name": [{
    "family": "Smith",
    "given": ["John"]
  }],
  "gender": "male",
  "birthDate": "1990-01-01"
}
</syntaxhighlight>


Esta página foi concebida como uma introdução estruturada e acessível ao FHIR, destinada a estudantes, profissionais de saúde e técnicos que procuram compreender os fundamentos deste standard.


No final da leitura, espera-se que o leitor:
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.'''
* Conheça o contexto em que o FHIR surgiu
* Compreenda os seus princípios técnicos fundamentais
* Reconheça os principais tipos de recurso
* Visualize casos reais de aplicação
* Perceba a relevância do FHIR em Portugal e na Europa


{| class="wikitable"
=== 2. Porque é que o FHIR está no centro das atenções ===
|+ Em resumo
|-
| '''FHIR''' é um standard criado para facilitar a partilha estruturada de dados clínicos. Usa tecnologias modernas da web e organiza a informação em unidades chamadas '''recursos'''. Está a transformar a forma como os sistemas de saúde comunicam entre si.
|}


=== 2. Porquê FHIR? ===
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'''.


Os sistemas de informação em saúde evoluíram, ao longo das últimas décadas, com o objetivo de permitir a troca estruturada de dados clínicos entre diferentes instituições e plataformas. Para esse fim, foram desenvolvidos vários standards de interoperabilidade pela HL7 International, entre os quais se destacam o HL7 v2, o CDA e o HL7 v3.
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.


Apesar do seu valor histórico, estes standards apresentaram limitações significativas em termos de consistência, complexidade e capacidade de adaptação a novos contextos tecnológicos. O '''FHIR''' surge como uma resposta pragmática a essas limitações, propondo um novo paradigma mais próximo das tecnologias da web, e mais adequado à realidade contemporânea dos sistemas de saúde.
Além do contexto europeu, o FHIR destaca-se por apresentar uma solução alinhada com a prática atual da engenharia de software:


==== 2.1 O legado dos standards anteriores ====
- '''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


A tabela seguinte resume as principais características dos standards que antecederam o FHIR, destacando os seus contributos e limitações.
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.'''


{| class="wikitable"
Mais do que uma especificação, o FHIR representa uma '''infraestrutura de referência para a arquitetura da informação clínica do futuro.'''
! Standard !! Ano !! Estrutura principal !! Força principal !! Limitações mais relevantes
|-
| HL7 v2 || 1989 || Mensagens segmentadas || Elevada difusão mundial || Ambiguidades, falta de uniformidade, difícil validação
|-
| CDA || 2001 || Documentos XML estruturados || Normalização de relatórios clínicos || Monolitismo, fraca granularidade dos dados
|-
| HL7 v3 || 2005 || Modelos rigorosos baseados em RIM || Formalismo conceptual || Complexidade elevada, fraca adoção
|-
| FHIR || 2014 || Recursos modulares e APIs RESTful || Simplicidade e flexibilidade || Requer maturidade digital dos sistemas
|}


Apesar dos avanços, verificou-se que os standards anteriores não conseguiam responder de forma eficaz aos novos desafios da saúde digital: integração de aplicações móveis, interoperabilidade em tempo real, desenvolvimento ágil, e envolvimento de equipas multidisciplinares.
=== 3. Como funciona o FHIR ===


==== 2.2 Uma proposta mais moderna e orientada para a prática ====
O FHIR organiza a informação em saúde através de '''recursos estruturados'''. Cada recurso representa uma entidade clínica ou administrativa, como por exemplo um utente, um diagnóstico, uma consulta, uma prescrição, com campos bem definidos, extensíveis e reutilizáveis.


O '''FHIR''' introduz uma abordagem técnica mais acessível, baseada em tecnologias abertas amplamente utilizadas fora do setor da saúde. Utiliza chamadas HTTP (como GET, POST, PUT, DELETE) para interagir com '''recursos''', que representam unidades discretas de informação clínica ou administrativa.
A base do FHIR assenta em três princípios técnicos fundamentais:


Cada recurso, como por exemplo '''Patient''', '''Observation''' ou '''Encounter''', é uma entidade autocontida que pode ser consultada, atualizada ou combinada com outros recursos, promovendo uma lógica modular e reutilizável.
==== 3.1 Recursos: unidades modulares de informação ====


{| class="wikitable" style="background-color:#f2f2f2"
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'''. 
| '''Exemplo de chamada a um recurso Patient:'''
Exemplos de recursos:
<syntaxhighlight lang="bash">
GET /fhir/Patient?name=Sousa
</syntaxhighlight>
|}


Ao adotar este modelo, o FHIR permite acelerar a implementação de soluções interoperáveis, facilitar a integração entre sistemas distintos e abrir a porta à inovação por parte de equipas técnicas com diferentes origens, incluindo o desenvolvimento web e mobile.
- `Patient` (utente) 
- `Observation` (resultado de medição) 
- `Condition` (diagnóstico) 
- `Encounter` (episódio de contacto clínico) 
- `MedicationRequest` (prescrição)


==== 2.3 FHIR como mudança de paradigma ====
Cada recurso tem um '''identificador único''', uma '''estrutura interna clara''' e pode ser enviado ou consultado isoladamente.


Mais do que uma evolução técnica, o FHIR representa uma mudança de paradigma. Substitui estruturas pesadas por componentes leves e combináveis, aproxima-se da lógica da programação orientada a objetos e introduz um modelo mais compatível com os princípios da transformação digital.
==== 3.2 API RESTful: ler, escrever e consultar ====


Esta arquitetura torna o FHIR particularmente relevante no contexto atual, em que se exige maior interoperabilidade entre unidades de saúde, maior transparência para os cidadãos e maior eficiência na utilização dos dados clínicos.
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, como nos exemplos abaixo:


{| class="wikitable"
{| class="wikitable plainrowheaders" style="text-align:left; width:90%"
|+ Em resumo
! Método HTTP !! URL do recurso !! Ação realizada
|-
| '''GET''' || /Patient/123 || Obter dados do utente com ID 123
|-
| '''POST''' || /Observation || Criar uma nova observação (ex: oximetria de pulso)
|-
| '''PUT''' || /Condition/456 || Atualizar um diagnóstico existente com ID 456
|-
|-
| O '''FHIR''' representa uma resposta consciente aos limites históricos da interoperabilidade em saúde. Combina simplicidade técnica com profundidade semântica, promovendo uma nova geração de sistemas interoperáveis, modulares e centrados no utente.
| '''DELETE''' || /MedicationRequest/med789 || Remover uma prescrição ativa
|}
|}


=== 3. Como o FHIR funciona por dentro: princípios estruturais ===
Esta abordagem facilita a integração com plataformas clínicas, apps móveis e sistemas analíticos, de forma leve e escalável.


Até aqui, vimos o FHIR como uma resposta moderna aos desafios da interoperabilidade em saúde. Mas o que torna este standard verdadeiramente inovador não é apenas a sua proposta — é a forma como foi construído.
==== 3.3 Formato: JSON legível e normalizado ====


O FHIR não é apenas um conjunto de regras. É uma arquitectura pensada para comunicar informação clínica com elegância técnica, legibilidade semântica e flexibilidade controlada. Nesta secção, exploramos os seus princípios estruturais com uma pergunta em mente: por que razão o FHIR escolheu este caminho e não outro?
A representação mais comum dos dados em FHIR é o '''formato JSON''', que é:


==== 3.1 Porquê REST, e não SOAP? ====
- '''Legível por humanos'''
- '''Fácil de validar'''
- '''Suportado por todas as linguagens de programação modernas'''


Ao adotar APIs RESTful, o FHIR afasta-se das abordagens mais pesadas baseadas em SOAP (como o HL7 v3) e aproxima-se das tecnologias utilizadas em milhões de aplicações web. REST oferece simplicidade, previsibilidade e uma curva de aprendizagem muito mais suave.
<syntaxhighlight lang="json">
 
{
A comunicação é feita através de chamadas HTTP simples, que espelham ações básicas como consultar (GET), criar (POST), atualizar (PUT) e apagar (DELETE).
  "resourceType": "Observation",
 
  "id": "oximetria01",
```wiki
  "status": "final",
<syntaxhighlight lang="bash">
  "code": {
GET /fhir/Patient/123
    "coding": [{
      "system": "http://loinc.org",
      "code": "59408-5",
      "display": "Oximetria de pulso"
    }]
  },
  "valueQuantity": {
    "value": 98,
    "unit": "%",
    "system": "http://unitsofmeasure.org",
    "code": "%"
  }
}
</syntaxhighlight>
</syntaxhighlight>


==== 3.2 Recursos: a gramática modular da informação ====
Este exemplo representa uma oximetria de pulso com 98 por cento, codificada em LOINC.


A unidade fundamental no FHIR é o recurso. Cada recurso representa uma entidade discreta do mundo clínico ou administrativo, com atributos bem definidos e uma estrutura consistente.
=== 4. Como interpretar um recurso FHIR ===


Um recurso pode representar um utente, uma medicação, um resultado clínico ou uma intervenção. Estes recursos são autocontidos, mas podem referenciar outros. A informação torna-se assim legível, reutilizável e interconectada.
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'''.


{| class="wikitable"
Nesta secção, utilizamos como exemplo o recurso `Patient`, um dos mais simples e frequentemente utilizados.
|+ Exemplos de recursos FHIR
! Nome do recurso !! O que representa
|-
| Patient || Informação de identificação do utente
|-
| Observation || Medição ou resultado clínico
|-
| Encounter || Episódio de cuidados
|-
| MedicationRequest || Prescrição de medicamento
|-
| Condition || Diagnóstico ou problema clínico
|}


==== 3.3 Formatos interoperáveis com intenção semântica ====
==== 4.1 Anatomia básica de um recurso ====


O FHIR utiliza JSON e XML como formatos de serialização. Estes formatos são abertos, legíveis por humanos, compatíveis com múltiplas linguagens de programação e fáceis de integrar em APIs modernas.
Todo recurso FHIR é representado num '''formato estruturado''' (habitualmente JSON), e inclui:


O exemplo seguinte mostra um recurso Patient representado em JSON, com campos identificáveis por qualquer sistema compatível.
- `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">
<syntaxhighlight lang="json">
{
{
   "resourceType": "Patient",
   "resourceType": "Patient",
   "id": "example",
   "id": "john-smith-001",
   "name": [
   "name": [{
     {
     "use": "official",
      "use": "official",
    "family": "Smith",
      "family": "Sousa",
    "given": ["John"]
      "given": ["Carlos"]
  }],
    }
  ],
   "gender": "male",
   "gender": "male",
   "birthDate": "1990-01-01"
   "birthDate": "1990-01-01"
Linha 140: Linha 141:
</syntaxhighlight>
</syntaxhighlight>


Esta estrutura assegura que os dados possam ser partilhados e processados sem perda de significado.
==== 4.2 Como ler a página oficial de um recurso ====
 
==== 3.4 Extensões: como crescer sem romper ====


O FHIR define um conjunto base de recursos e atributos, mas permite que sejam criadas extensões adicionais, desde que estruturadas e documentadas segundo regras definidas. Um sistema que não reconhece uma extensão pode ignorá-la sem comprometer a leitura do restante conteúdo.
A documentação oficial de cada recurso FHIR está disponível em: [https://hl7.org/fhir/R4/](https://hl7.org/fhir/R5/)


Esta abordagem permite adaptar o FHIR a diferentes realidades sem fragmentar a interoperabilidade global.
Na página de cada recurso (exemplo: [https://hl7.org/fhir/R4/patient.html](https://hl7.org/fhir/R5/patient.html)), encontras:


==== 3.5 Modularidade sem redundância ====
- '''Descrição funcional do recurso''' 
- '''Tabela com os elementos''', organizados por ordem hierárquica. Para cada elemento são apresentados:


O desenho modular do FHIR permite representar dados clínicos diversos sem necessidade de múltiplos modelos paralelos. Um único recurso Observation pode servir tanto para uma glicemia capilar como para uma tomografia computadorizada.
<pre>
- Nome
- Tipo de dado
- Cardinalidade (quantas vezes pode aparecer)
- Obrigatoriedade
- Comentários
</pre>


Esta lógica evita redundância, promove a reutilização e contribui para uma linguagem clínica comum entre sistemas distintos.
Exemplo de linha interpretada (resumo visual):


{| class="wikitable"
{| class="wikitable"
|+ Em resumo
! Elemento !! Tipo !! Card. !! Descrição
|-
| `name` || HumanName || 0..* || Nome(s) do paciente, podendo haver mais do que um
|-
|-
| O FHIR organiza-se segundo cinco princípios estruturais que articulam leveza técnica e profundidade clínica. Utiliza REST como modelo de comunicação, estrutura a informação em recursos autocontenidos, adota formatos interoperáveis legíveis por humanos e máquinas, permite extensões controladas e aposta numa modularidade que favorece a reutilização.
| `birthDate` || date || 0..1 || Data de nascimento, se conhecida
|-
| `gender` || code || 0..1 || Sexo biológico (valores possíveis: male, female, other, unknown)
|}
|}


=== 4. Anatomia de um recurso FHIR ===
==== 4.3 O que significam os campos técnicos? ====


Há quem olhe para um recurso FHIR como quem vê um ficheiro técnico. Mas um recurso é mais do que um bloco de dados. É uma unidade semântica que carrega significado clínico. E quando bem construído, é também uma narrativa: organizada, modular, interoperável.
- '''Cardinalidade''': define o número de ocorrências permitidas. 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 externos (ex: SNOMED, LOINC) 
- '''Extensões''': permitem adicionar novos campos sem modificar o core do recurso


Tomemos o exemplo mais simples, mas também mais central de todos — o recurso Patient.


==== 4.1 Comecemos pela superfície ====
==== 4.4 Referências entre recursos ====


Um recurso FHIR começa sempre por se apresentar. O seu primeiro campo é resourceType. É como se dissesse: “sou um Patient”.
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:


Depois, vem o seu identificador (id). Um código único dentro do sistema, que permite distinguir este recurso de todos os outros.
E logo a seguir surgem os campos que realmente interessam ao cuidado clínico: nome, género, data de nascimento. Cada um destes atributos está estruturado, normalizado, pronto a ser compreendido por qualquer sistema que fale FHIR.
```wiki
<syntaxhighlight lang="json">
<syntaxhighlight lang="json">
{
"subject": {
  "resourceType": "Patient",
   "reference": "Patient/john-smith-001"
  "id": "example",
  "name": [
    {
      "use": "official",
      "family": "Sousa",
      "given": ["Carlos"]
    }
  ],
   "gender": "male",
  "birthDate": "1990-01-01"
}
}
</syntaxhighlight>
</syntaxhighlight>


==== 4.2 Cada campo é uma decisão ====


No FHIR, nada é gratuito. O campo '''name''', por exemplo, é uma lista de objetos, não uma simples string. Isto permite representar múltiplos nomes com diferentes usos, como official, usual, maiden ou nickname.
'''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 ====


O campo '''gender''' segue um conjunto fechado de valores possíveis. O formato da '''birthDate''' está normalizado segundo o padrão ISO. A tipificação protege a interoperabilidade.
Um '''perfil FHIR''' define como um recurso padrão deve ser usado num determinado contexto. Pode:


Cada campo é cuidadosamente desenhado para ser validável, extensível e semanticamente inequívoco. E, acima de tudo, cada um pode ser omitido sem comprometer a integridade do recurso.
- Tornar certos campos obrigatórios
- Restringir os valores possíveis de um campo
- Fixar terminologias (ex: SNOMED, ICD-10)
- Adicionar extensões permitidas


==== 4.3 Referências: o Patient não está sozinho ====
Exemplo: um hospital pode definir que todo recurso `Observation` referente a glicemia deve sempre incluir a unidade `mg/dL`, codificada em LOINC.


Um recurso '''Patient''' raramente está isolado. Pode referenciar profissionais ('''Practitioner'''), episódios ('''Encounter'''), observações ('''Observation''') ou condições clínicas ('''Condition'''). A ligação entre recursos faz-se através de referências. São apontadores, não duplicações.
Os perfis garantem '''coerência, interoperabilidade e validação técnica''' dentro de contextos nacionais ou institucionais.


<syntaxhighlight lang="json">
==== 5.2 Implementation Guides: conjuntos estruturados de perfis e regras ====
"generalPractitioner": [
 
  {
Um '''Implementation Guide (IG)''' é um documento técnico que:
    "reference": "Practitioner/123"
  }
]
</syntaxhighlight>


Esta referência não transporta o conteúdo do recurso '''Practitioner'''. Apenas o localiza. É uma ligação semântica, que reduz redundância e aumenta a coesão entre entidades clínicas.
- 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


==== 4.4 Um recurso é sempre incompleto ====
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.


O FHIR assume a incompletude como princípio. Um recurso pode conter apenas o essencial ou crescer com extensões, metadados e perfis personalizados.


Essa elasticidade permite que o mesmo modelo suporte tanto uma aplicação de registo mínimo como uma infraestrutura nacional de interoperabilidade. O núcleo mantém-se. O contexto é que se adapta.


{| class="wikitable"
'''Resumo:'''
|+ Em 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'''.
|-
| O recurso '''Patient''' ilustra a filosofia do FHIR: equilibrar simplicidade com expressividade. É um objeto estruturado, flexível e interoperável. Representa não só um utente, mas uma forma moderna de descrever dados clínicos com intenção, contexto e precisão.
|}


=== 5. Recursos mais comuns no FHIR ===
=== 6. FHIR e o futuro da interoperabilidade em saúde ===


Os recursos são os blocos fundamentais da arquitetura FHIR. Cada um representa uma entidade com significado clínico ou administrativo. A compreensão dos recursos mais utilizados é essencial para interpretar e construir sistemas interoperáveis baseados neste standard.
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.


Embora o FHIR inclua mais de 150 tipos de recurso, a maioria das aplicações clínicas recorre a um subconjunto bem definido. Estes recursos podem ser agrupados segundo a sua função no ciclo de cuidados: identificação do utente, episódios clínicos, diagnósticos, intervenções, terapêutica e resultados.
==== 6.1 Interoperabilidade no centro da política europeia ====


{| class="wikitable"
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).
|+ Recursos FHIR organizados por domínio clínico
! Domínio !! Recurso !! Finalidade
|-
| Identificação || Patient || Informação demográfica e administrativa do utente
|-
| Identificação || Practitioner || Identificação de profissionais de saúde
|-
| Episódios clínicos || Encounter || Representação de um episódio de cuidados (consulta, internamento, urgência)
|-
| Diagnóstico || Condition || Representação de diagnósticos, problemas ativos ou antecedentes
|-
| Diagnóstico || Observation || Resultados de exames, sinais vitais, escalas clínicas
|-
| Intervenções || Procedure || Procedimentos realizados ou planeados
|-
| Terapêutica || MedicationRequest || Prescrições de medicamentos
|-
| Terapêutica || MedicationAdministration || Registo da administração de terapêutica
|-
| Registos complementares || DocumentReference || Referência a documentos clínicos externos
|-
| Registos complementares || AllergyIntolerance || Registo de alergias ou intolerâncias conhecidas
|}


==== 5.1 Relações entre recursos ====
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.


Os recursos não existem isoladamente. A riqueza do FHIR emerge das ligações entre elementos. Por exemplo, um recurso '''Observation''' pode referir um '''Patient''', um '''Practitioner''', um '''Encounter''' e uma '''Condition''', dependendo do contexto.
==== 6.2 FHIR, openEHR e a arquitetura da saúde digital ====


Esta rede de relações cria um modelo clínico distribuído, flexível e altamente expressivo.
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'''.


==== 5.2 Perfis nacionais e contextuais ====
Estudos recentes propõem uma arquitetura híbrida:


Muitos países e instituições definem subconjuntos específicos de recursos obrigatórios, conhecidos como '''perfis'''. Estes perfis estabelecem regras adicionais, como campos obrigatórios, terminologias aceites e validações semânticas adaptadas à realidade local.
- 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.


Em Portugal, a adoção formal de perfis FHIR está ainda em fase inicial, mas o alinhamento com as diretrizes do Espaço Europeu de Dados de Saúde (EHDS) prevê uma maior normalização dos recursos utilizados.
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.


{| class="wikitable"
==== 6.3 A evolução da adoção em Portugal ====
|+ Em resumo
|-
| O FHIR disponibiliza uma vasta biblioteca de recursos, mas a prática clínica exige sobretudo um núcleo comum que inclui Patient, Practitioner, Encounter, Condition, Observation e MedicationRequest. Estes recursos, interligados, permitem representar com precisão o percurso clínico de um utente num sistema interoperável.
|}


=== 6. Operações básicas com FHIR ===
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.


O FHIR foi desenhado para ser utilizado através de interfaces baseadas em HTTP, o mesmo protocolo usado para navegar na internet. Isso significa que interagir com dados FHIR é conceptualmente semelhante a interagir com páginas web, mas em vez de visualizar conteúdos, o objetivo é aceder, criar, modificar ou eliminar dados estruturados.
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.


Cada tipo de operação corresponde a um verbo HTTP. A combinação do verbo com um endpoint FHIR permite realizar uma ação sobre um recurso ou um conjunto de recursos. Os sistemas que implementam o FHIR devem respeitar esta semântica.
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.1 Consulta de dados (GET) ====
==== 6.4 Infraestrutura digital com base no FHIR ====


A operação GET permite obter dados de um recurso específico ou pesquisar recursos com determinados critérios.
O FHIR destaca-se por:


```wiki
- '''Alinhamento com as práticas modernas de desenvolvimento web'''
<syntaxhighlight lang="bash">
- '''Capacidade de extensão e adaptação a diferentes contextos'''
GET /fhir/Patient/123
- '''Elevado suporte comunitário, técnico e institucional'''
</syntaxhighlight>
- '''Facilidade de integração com sistemas existentes através de APIs'''


Esta chamada devolve o conteúdo do recurso Patient com identificador 123.
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.


Também é possível realizar pesquisas parametrizadas:
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.


<syntaxhighlight lang="bash">
GET /fhir/Patient?name=Sousa
</syntaxhighlight>


Esta chamada devolve todos os recursos Patient cujo nome inclua “Sousa”.
=== 7. Glossário e ferramentas para aprender mais ===


==== 6.2 Criação de dados (POST) ====
==== 7.1 Glossário essencial ====


A operação POST é utilizada para criar novos recursos. O conteúdo do recurso é enviado no corpo da chamada, geralmente em formato JSON.
{| class="wikitable"
! 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
|}


```wiki
==== 7.2 Ferramentas úteis ====
<syntaxhighlight lang="bash">
POST /fhir/Patient
</syntaxhighlight>


O servidor responde com o recurso criado, atribuindo-lhe um identificador único.
- '''Documentação oficial HL7 FHIR'''
  [https://hl7.org/fhir](https://hl7.org/fhir)


==== 6.3 Atualização de dados (PUT) ====
- '''FHIR Resource Index''' (lista de todos os recursos) 
  [https://hl7.org/fhir/resourcelist.html](https://hl7.org/fhir/resourcelist.html)


A operação PUT substitui por completo um recurso existente com uma nova versão enviada pelo cliente.


```wiki
<syntaxhighlight lang="bash">
PUT /fhir/Patient/123
</syntaxhighlight>


A nova versão do recurso Patient com o identificador 123 irá substituir a anterior.
== 8. Fontes e referências ==


==== 6.4 Remoção de dados (DELETE) ====
=== Documentos oficiais e institucionais ===


A operação DELETE remove um recurso do sistema, utilizando o seu identificador.
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. 
[https://eur-lex.europa.eu/legal-content/PT/TXT/?uri=CELEX:32025R0914 Link para o documento]


```wiki
HL7 International. ''HL7 FHIR Specification''. 
<syntaxhighlight lang="bash">
[https://hl7.org/fhir Link para o site oficial do HL7 FHIR]
DELETE /fhir/Patient/123
</syntaxhighlight>


Esta ação elimina o recurso Patient com o identificador 123, caso exista.
HL7 Europe e IHE-Europe. ''Joint Initiatives for the EHDS''. 
[https://hl7europe.org Link para o site do HL7 Europe]


==== 6.5 Outras operações ====
SPMS. ''Registo de Saúde Eletrónico Unificado (RSE)''. Serviços Partilhados do Ministério da Saúde. 
[https://www.spms.min-saude.pt Link para a SPMS]


O FHIR permite também operações mais complexas, como PATCH (atualização parcial), transações em lote, operações condicionais e invocação de operações personalizadas. Estas funcionalidades são particularmente úteis em sistemas de larga escala ou em contextos onde há múltiplas instâncias do mesmo recurso.
=== Literatura de referência ===


{| class="wikitable"
Benson T, Grieve G. ''Principles of Health Interoperability: SNOMED CT, HL7 and FHIR''. Springer, 4.ª ed., 2021.
|+ Em resumo
|-
| O FHIR utiliza a semântica dos verbos HTTP para interagir com recursos. A simplicidade das operações GET, POST, PUT e DELETE permite uma implementação clara e previsível, sem comprometer a robustez das aplicações clínicas. Esta abordagem aproxima o desenvolvimento em saúde das práticas comuns no desenvolvimento web moderno.
|}

Edição atual desde as 19h16min de 5 de julho de 2025

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 por exemplo 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, como nos exemplos abaixo:

Método HTTP URL do recurso Ação realizada
GET /Patient/123 Obter dados do utente com ID 123
POST /Observation Criar uma nova observação (ex: oximetria de pulso)
PUT /Condition/456 Atualizar um diagnóstico existente com ID 456
DELETE /MedicationRequest/med789 Remover uma prescrição ativa

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 por cento, codificada em LOINC.

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: [1](https://hl7.org/fhir/R5/)

Na página de cada recurso (exemplo: [2](https://hl7.org/fhir/R5/patient.html)), encontras:

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

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

Exemplo de linha interpretada (resumo visual):

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 permitidas. 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 externos (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>


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.


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 

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

- FHIR Resource Index (lista de todos os recursos) 

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


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. Link para o documento

HL7 International. HL7 FHIR Specification. Link para o site oficial do HL7 FHIR

HL7 Europe e IHE-Europe. Joint Initiatives for the EHDS. Link para o site do HL7 Europe

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

Literatura de referência

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

Obtida de "https://aprendis.med.up.pt/index.php?title=FHIR&oldid=8746"