FHIR platform

HL7 FHIR R4 explained and how Anpheros implements it as a managed FHIR database: 26 resource types, search, history, transactions, $everything, the International Patient Summary and the simpler REST view of the same data.

Anpheros is a FHIR platform — a managed FHIR database (data store) that applications use as their FHIR backend: it stores every patient record natively as HL7 FHIR R4 (4.0.1) resources and exposes them at https://platform.anpheros.com/fhir/R4, with consent, provenance and an audit added on top of the standard. Applications that already speak FHIR can use it directly; applications that do not can use the simpler REST API (/v1), which reads and writes the same resources with the same ids.

For AI applications this makes Anpheros the FHIR backend a model's context comes from: see LLM applications and healthcare data.

What is HL7 FHIR?

FHIR (Fast Healthcare Interoperability Resources) is the HL7 standard for exchanging health data over the web. It defines:

resources — small, typed JSON (or XML) documents for each clinical concept: a Patient, an Observation, a Condition, a MedicationStatement;
references between them ("subject": {"reference": "Patient/123"}), so a record is a graph of resources around a patient;
a REST API for reading, searching, creating, updating and deleting resources, with standard search parameters;
bundles for sending several resources at once (transactions) or as a document (such as a patient summary);
terminology bindings, so values carry codes from systems such as LOINC or ICD-10;
profiles — constraints for a use case or a country, such as the International Patient Summary.

R4 (version 4.0.1) is the release most widely implemented today. Using FHIR as the storage model — not only as an export format — means there is no translation layer between what an application writes and what another FHIR system reads.

{
  "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": "%"}
}

Capability statement

GET /fhir/R4/metadata returns the CapabilityStatement: the supported resource types, their search parameters and the operations. It is public and is the authoritative list; the table below reflects it on 28 September 2026.

The 26 resource types

Area	Resource types
Patient and people	`Patient`, `RelatedPerson`
Measurements and results	`Observation` (vital signs, laboratory, symptoms, wellbeing, daily activity and sleep), `DiagnosticReport`
Problems and care	`Condition`, `EpisodeOfCare`, `Procedure`, `CarePlan`, `Goal`, `ServiceRequest`, `CareTeam`, `FamilyMemberHistory`
Medication and prevention	`MedicationStatement`, `MedicationAdministration`, `Immunization`, `AllergyIntolerance`
Documents and questionnaires	`DocumentReference`, `QuestionnaireResponse`
Visits	`Encounter`, `Appointment`
Directory	`Organization`, `Practitioner`, `PractitionerRole`
Governance	`Consent`, `Provenance`
Extension point	`Basic`

Every patient-scoped type belongs to the patient compartment, so Patient/{id}/$everything, patient-level OAuth scopes and consent filters apply to all of them. Directory resources (Organization, Practitioner, PractitionerRole) have no patient; they are readable across projects in the same environment and changeable only by the project that created them.

Interactions and operations

Read, search, create, update, delete on every supported type; search parameters per type are listed in the CapabilityStatement. Unknown search parameters are refused with 400 rather than silently ignored.
History: GET /fhir/R4/{type}/{id}/_history returns every version; updates can be made conditional with If-Match (a version mismatch answers 412).
Transactions and batches: POST /fhir/R4 with a Bundle of type transaction or batch.
Patient/{id}/$everything: the whole compartment of one patient.
Patient/{id}/$summary: an International Patient Summary (IPS) document Bundle, in English or Romanian (?lang=).
Observation/$validate?profile=eu-lab: reports how a lab result measures up to the HL7 Europe laboratory report rules.
Paging: _count up to 200; _revinclude returns at most 1 000 resources.
Idempotency: POST requests accept an Idempotency-Key; repeating a request with the same key returns the same answer and creates nothing.

# 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 and the simpler REST API

/v1 exists for developers who do not want to work with FHIR resources directly. It covers patients, observations, conditions, medications, documents, a chronological timeline and provenance, plus the platform features (context, lab import, webhooks, terminology). Every /v1 object carries its fhir reference, so an application can start with /v1 and switch to FHIR for the parts where it needs the full model.

Standards around FHIR

$summary produces an International Patient Summary validated with the official HL7 validator (0 errors); lab results are checked against the HL7 Europe laboratory rules (advisory today); third-party apps connect through SMART on FHIR standalone launch; HL7 v2 ORU^R01 lab messages are accepted as input. The formats, levels and exchange patterns are described in Healthcare data interoperability; the code systems per resource type in FHIR code systems.