Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Plataforma FHIR: FHIR R4 gerido com consentimento do paciente

Uma plataforma FHIR R4 gerida: 26 tipos de recursos, pesquisa, histórico, transações, $everything, IPS, SMART launch testado por Inferno, consentimento e proveniência, mais uma API REST simples. Sandbox gratuita.

Anpheros é uma plataforma FHIR — uma base de dados FHIR gerida (data store) que as aplicações utilizam como o seu backend FHIR: armazena cada registo de paciente nativamente como recursos HL7 FHIR R4 (4.0.1) e expõe-nos em https://platform.anpheros.com/fhir/R4, com consentimento, proveniência e auditoria adicionados por cima do padrão. As aplicações que já utilizam FHIR podem utilizá-la diretamente; as aplicações que não o fazem podem utilizar a API REST mais simples (/v1), que lê e escreve os mesmos recursos com os mesmos IDs.

Para aplicações de IA, isto torna Anpheros o backend FHIR de onde provém o contexto de um modelo: veja Aplicações LLM e dados de saúde.

26FHIR R4 resource types

22/22Inferno SMART App Launch STU2 standalone-launch tests passed

0 errorsInternational Patient Summary in the official HL7 validator

EUmanaged and hosted in the European Union

O que é HL7 FHIR?

FHIR (Fast Healthcare Interoperability Resources) é o padrão HL7 para a troca de dados de saúde pela web. Define:

• recursos — pequenos documentos JSON (ou XML) tipados para cada conceito clínico: um Patient, um Observation, um Condition, um MedicationStatement;
• referências entre eles ("subject": {"reference": "Patient/123"}), de modo que um registo é um grafo de recursos em torno de um paciente;
• uma API REST para ler, pesquisar, criar, atualizar e eliminar recursos, com parâmetros de pesquisa standard;
• bundles para enviar vários recursos de uma vez (transações) ou como um documento (como um resumo do paciente);
• vinculações de terminologia, para que os valores transportem códigos de sistemas como LOINC ou ICD-10;
• perfis — restrições para um caso de uso ou um país, como o International Patient Summary.

R4 (versão 4.0.1) é a versão mais amplamente implementada atualmente. Utilizar FHIR como modelo de armazenamento — não apenas como formato de exportação — significa que não existe uma camada de tradução entre o que uma aplicação escreve e o que outro sistema FHIR lê.

{
  "resourceType": "Observation",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "4548-4", "display": "Hemoglobin A1c"}]},
  "subject": {"reference": "Patient/…"},
  "effectiveDateTime": "2026-09-01T08:00:00Z",
  "valueQuantity": {"value": 6.4, "unit": "%", "system": "http://unitsofmeasure.org", "code": "%"}
}

Declaração de Capacidades

GET /fhir/R4/metadata devolve a CapabilityStatement: os tipos de recursos suportados, os seus parâmetros de pesquisa e as operações. É pública e constitui a lista autoritativa; a tabela abaixo reflete-a a 28 de setembro de 2026.

Os 26 tipos de recursos

Todos os tipos com âmbito de paciente pertencem ao compartimento do paciente, pelo que Patient/{id}/$everything, os âmbitos OAuth a nível de paciente e os filtros de consentimento aplicam-se a todos eles. Os recursos de diretório (Organization, Practitioner, PractitionerRole) não têm paciente; são legíveis em todos os projetos no mesmo ambiente e alteráveis apenas pelo projeto que os criou.

Interações e operações

• Read, search, create, update, delete em todos os tipos suportados; os parâmetros de pesquisa por tipo estão listados na CapabilityStatement. Parâmetros de pesquisa desconhecidos são recusados com 400 em vez de serem ignorados silenciosamente.
• History: GET /fhir/R4/{type}/{id}/_history retorna todas as versões; as atualizações podem ser condicionais com If-Match (uma incompatibilidade de versão responde com 412).
• Transactions and batches: POST /fhir/R4 com um Bundle do tipo transaction ou batch.
• Patient/{id}/$everything: todo o compartimento de um paciente.
• Patient/{id}/$summary: um documento International Patient Summary (IPS) Bundle, em inglês ou romeno (?lang=).
• Observation/$validate?profile=eu-lab: relata como um resultado de laboratório se compara às regras de relatório de laboratório do HL7 Europe.
• Paging: _count até 200; _revinclude retorna no máximo 1 000 recursos.
• Idempotency: POST requests aceitam um Idempotency-Key; repetir um pedido com a mesma chave retorna a mesma resposta e não cria nada.

# latest HbA1c results of one patient, strict FHIR
curl "https://platform.anpheros.com/fhir/R4/Observation?patient=$PID&code=http://loinc.org|4548-4&_sort=-date" \
     -H "Authorization: Bearer $KEY"

# the patient's International Patient Summary
curl "https://platform.anpheros.com/fhir/R4/Patient/$PID/\$summary?lang=en" -H "Authorization: Bearer $KEY"

FHIR e a API REST mais simples

/v1 existe para programadores que não querem trabalhar diretamente com recursos FHIR. Cobre pacientes, observações, condições, medicamentos, documentos, uma linha cronológica e proveniência, mais as funcionalidades da plataforma (contexto, importação de laboratório, webhooks, terminologia). Cada objeto /v1 carrega a sua referência fhir, pelo que uma aplicação pode começar com /v1 e mudar para FHIR para as partes onde necessita do modelo completo.

Padrões em torno do FHIR

O $summary produz um Resumo Internacional do Paciente validado com o validador oficial HL7 (0 erros); os resultados laboratoriais são verificados em relação às regras laboratoriais da HL7 Europe (atualmente consultivas); aplicações de terceiros conectam-se através do lançamento autónomo SMART on FHIR; mensagens laboratoriais HL7 v2 ORU^R01 são aceites como entrada. Os formatos, níveis e padrões de intercâmbio são descritos em Interoperabilidade de dados de saúde; os sistemas de código por tipo de recurso em Sistemas de código FHIR.

Perguntas frequentes

O que é uma plataforma FHIR?

Um serviço que armazena dados de saúde como recursos HL7 FHIR e os expõe através da API REST FHIR padrão, adicionando o que as aplicações necessitam em torno do padrão: autorização, consentimento, auditoria, histórico e operações como $everything e $summary. Anpheros é uma plataforma FHIR R4 gerida: chama-a em vez de executar um servidor FHIR.

Qual é a diferença entre um servidor FHIR e uma plataforma FHIR?

Um servidor FHIR implementa a API FHIR sobre uma base de dados. Uma plataforma FHIR executa-a para si e adiciona a camada em torno dela — consentimento do paciente, proveniência, registos de acesso, SDKs, webhooks, importação de laboratório e uma sandbox — para que as aplicações não tenham de construir essas partes.

Que versão FHIR é suportada pelo Anpheros?

FHIR R4 (4.0.1), com 26 tipos de recursos listados na CapabilityStatement pública em /fhir/R4/metadata.

A plataforma FHIR Anpheros é testada independentemente?

O grupo "Standalone Launch" da SMART App Launch STU2 do kit de testes de código aberto Inferno passa 22 de 22 testes (execução de 28 de setembro de 2026), e o International Patient Summary valida com 0 erros no validador oficial HL7. O lançamento de EHR e a exportação de dados em massa ainda não são suportados.

Posso usar a plataforma FHIR gratuitamente?

Sim. A sandbox é gratuita e inclui 30 pacientes sintéticos por projeto; a produção começa em €99 por mês com o primeiro mês gratuito.

Tenho de usar FHIR para usar Anpheros?

Não. Uma API REST mais simples (/v1) lê e escreve os mesmos recursos com os mesmos IDs, pelo que uma aplicação pode começar com JSON plano e mudar para FHIR onde necessitar do modelo completo.

Relacionado

• Sandbox FHIR: um servidor de teste FHIR R4 privado e gratuito
• International Patient Summary (IPS) em FHIR
• Proveniência de dados médicos explicada: quem escreveu o quê e como registar
• Como armazenar registos médicos usando FHIR R4: tutorial passo a passo com curl
• FHIR vs. uma base de dados médica personalizada: quando projetar as suas próprias tabelas e quando usar FHIR
• Base de dados e sandbox FHIR gratuitos
• Como o Anpheros se compara com outros servidores FHIR
• Interoperabilidade de dados de saúde
• Sistemas de código FHIR
• API de dados médicos
• Criar uma aplicação de saúde
• Referência da API (OpenAPI)
• DICOM vs FHIR: onde o FHIR termina e a imagem médica começa

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card