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á 24 revisões intermédias de 3 utilizadores que não estão a ser apresentadas)
Linha 1: Linha 1:
{{Terminologias e Standards
=== 1. O que é o FHIR, em palavras simples ===
|Designação Terminologia/Standard=Fast Healthcare Interoperability Resources
|Entidade Criadora Terminologia/Standard= Health Level Seven (HL7)
|Entidade Gestora Terminologia/Standard= Health Level Seven (HL7)
|Versão atual Terminologia/Standard=1.0
|Área(s) de Aplicação Terminologia/Standard= Interoperabilidade
}}


=Fast Healthcare Interoperability Resources=
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**.


Fast Healthcare Interoperability Resources ('''FHIR''', pronunciado como "Fire"), é um standard para a troca de informações electrónica na prestação dos cuidados de saúde. Apresenta-se como a próxima geração de standards criada pela '''Health Level Seven''' ([[HL7]]).
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.
Combina as melhores aptidões do HL7 v2.x, v3 e CDA, agrupando estas caraterísticas com as novidades de web standards e aplicando um foco maioritário na sua implementação. Esta facilidade de implementação deve-se principalmente ao fato do '''FHIR''' utilizar uma tecnologia API(Application programming interface[http://en.wikipedia.org/wiki/Application_programming_interface]) baseada na web, que inclui serviços de protocolos RESTful[http://en.wikipedia.org/wiki/Representational_state_transfer] baseados em HTTP, na interface de integração usa HTML e CSS, permite a escolha entre JSON e XML para a representação dos dados, e o uso do OAuth[http://oauth.net/2/] para a autorização.


==Background==
Exemplo simples de recurso FHIR do tipo Patient:


Os '''Registos Clínicos Eletrónicos''' ([[Registo de Saúde Electrónico]]), cada vez mais são a realidade das instituições prestadoras de cuidados de saúde, com a facilidade e necessidade de movimentação dos pacientes dentro das instituições de saúde, o seu processo clínico, também tem de estar disponível e compreensível em qualquer instância. Mas também, para suporte das decisões clínicas automatizadas e processos automáticos de aprendizagem (machine-learning), por isso estes dados devem ser estruturados e estandardizados.
<syntaxhighlight lang="json">
A '''Health Level Seven''' ([[HL7]]) tem vindo a trabalhar nesta temática nos últimos 20 anos, através da produção de troca de informação na área da Saúde como na modelação da informação em standards.
{
'''FHIR''' é uma nova especificação baseada na indústria emergente (smartphones, tablets, etc), mas mais informada através dos anos de experiência e lições em volta dos requerimentos e dos desafios ganhos pela definição e implementação das metodologias já existentes, como o HL7 v2, v3 e CDA, tendo assim um vasto conhecimento já nesta temática que agora se acopla com o surgir do '''FHIR'''.
  "resourceType": "Patient",
  "id": "f001",
  "name": [{
    "family": "Smith",
    "given": ["John"]
  }],
  "gender": "male",
  "birthDate": "1990-01-01"
}
</syntaxhighlight>


==Desenho do FHIR==


O FHIR pode não resolver os desafios mais árduos da interoperabilidade na saúde, como políticas diferentes entre instituições, variabilidade nos dados capturados e o contexto em que estes são descobertos. No entanto, aponta como objetivo principal fazer da implementação da troca de dados o mais simples possível, para abrir caminho para a resolução destes árduos desafios da interoperabilidade.
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.'''
 
* '''Foco na Implementação''' - Fácil de entender para quem desenvolve, muita variada de ferramentas disponíveis(API's).
* '''Tecnologia web transversal a muitas industrias''' - é o exemplo da utilização de XML, JSON, HTTP.
* '''Requer interpretação humana como base da interoperabilidade''' - Quando as aplicações são incapazes de interpretar dados estruturados, lição aprendida do CDA.
* '''Conteúdo disponível''' - FHIR possui licença ''open source'' v1.0
* '''Suporta múltiplas arquitecturas'''.


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


As principais estruturas do '''FHIR''' são os ''Resources'', ''References'' e ''Profiles''.
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'''.


===Resources===
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.
São pequenas unidades lógicas de trocas com um comportamento e significado definido. São a mais pequena unidade de transação. Os 150 diferentes tipos de ''resources'' cobrem a área da Saúde por inteiro. Exemplos : Paciente; Historial Familiar; Alergias; etc..


Consiste em 3 partes:
Além do contexto europeu, o FHIR destaca-se por apresentar uma solução alinhada com a prática atual da engenharia de software:
# '''Dados estruturados''' - Regra dos 80/20, Só incluem elementos que sejam utilizados nas implementações na sua maioria - ''“We only include data elements if we are confident that 80% of implementations maintaining that resource will make use of the element.”'' Outros conteúdos vão para as extensões.
# '''Narrativa''' - Texto Sumário do conteúdo do ''resource''.
# '''Extensões''' - Atributos que suportam os casos não-comuns.


- '''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


[[Ficheiro:Fhir_resources.JPG]]
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.'''


===References===
Mais do que uma especificação, o FHIR representa uma '''infraestrutura de referência para a arquitetura da informação clínica do futuro.'''
São Ligações de um ''resource'' para outro. Usando as ''references'', os ''resources'' combinam-se de modo a criar uma rede de informação que representa um registo de saúde, os sistemas podem assim navegar nestas ligações e decidir quais os ''resources'' que precisam para uma determinada tarefa.


[[Ficheiro:Fhir_references.JPG]]
=== 3. Como funciona o FHIR ===


===Profiles===
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.
Os ''resources'' não tem regras em como devem ser usados, esta tarefa recai nos ''Profiles''. Quando existe a troca de dados, ambos os parceiros que a executam é que definem como querem usar os ''resources'' e quais as suas relações através do uso dos ''Profiles''.  
Exemplo: Num determinado hospital pediátrico podem existir regras quanto á requisição de uma cirurgia, que pode pedir informação como, nome dos pais, idade da criança, género, etc. Se alguma dessa informação não está presente, não é considerada uma referencia válida para esse hospital. Os ''Profiles'' definem assim perguntas como: Quais os elementos que são requeridos, que códigos de terminologia são utilizados neste sistema e adicionais extensões


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


As vantagens do '''FHIR''' sobre standards já existentes:
==== 3.1 Recursos: unidades modulares de informação ====


*Foco forte na implementação, rápida e fácil de implementar.
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'''.
*Múltiplas ''libraries'' de implementação.
Exemplos de recursos:
*Não existe restrições para quem usar, ''free-to-use'' até ao momento.
*Desenvolvimento evolucionário do caminho do HL7 Versão 2 e CDA - standards podem coexistir.
*Forte fundação em web standards - XML, JSON, HTTP, OAuth, etc.
*Suporte para uma arquitectura RESTful.
*Para facilidade dos ''developers'', um formato facilmente legível é garantido.
*Flexibilidade causada pelos diversos processos dos cuidados de saúde.


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


=Ligações úteis=
Cada recurso tem um '''identificador único''', uma '''estrutura interna clara''' e pode ser enviado ou consultado isoladamente.


Para mais informações sobre o tema, recomenda-se as seguintes ligações:
==== 3.2 API RESTful: ler, escrever e consultar ====


**FHIR Wiki [http://wiki.hl7.org/index.php?title=FHIR]
O FHIR foi desenhado para funcionar com '''REST APIs''', o modelo mais comum de comunicação entre aplicações na web. 
**HL7 FHIR [http://hl7.org/fhir/]
Isso significa que os dados podem ser acedidos através de URLs simples, como nos exemplos abaixo:
**BlogFHIR [http://fhirblog.com/]
 
**FHIRTwitter [http://twitter.com/FHIRnews]
{| class="wikitable plainrowheaders" style="text-align:left; width:90%"
! 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: [https://hl7.org/fhir/R4/](https://hl7.org/fhir/R5/)
 
Na página de cada recurso (exemplo: [https://hl7.org/fhir/R4/patient.html](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:
 
<pre>
- Nome
- Tipo de dado
- Cardinalidade (quantas vezes pode aparecer)
- Obrigatoriedade
- Comentários
</pre>
 
Exemplo de linha interpretada (resumo visual):
 
{| class="wikitable"
! 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 ====
 
{| 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
|}
 
==== 7.2 Ferramentas úteis ====
 
- '''Documentação oficial HL7 FHIR'''
  [https://hl7.org/fhir](https://hl7.org/fhir)
 
- '''FHIR Resource Index''' (lista de todos os recursos) 
  [https://hl7.org/fhir/resourcelist.html](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. 
[https://eur-lex.europa.eu/legal-content/PT/TXT/?uri=CELEX:32025R0914 Link para o documento]
 
HL7 International. ''HL7 FHIR Specification''. 
[https://hl7.org/fhir Link para o site oficial do HL7 FHIR]
 
HL7 Europe e IHE-Europe. ''Joint Initiatives for the EHDS''. 
[https://hl7europe.org 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.
[https://www.spms.min-saude.pt 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.

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.