# 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.

Source: https://developers.anpheros.com/guides/fhir

**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](https://developers.anpheros.com/guides/llm-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.

```json
{
  "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.

```bash
# 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](https://developers.anpheros.com/guides/interoperability); the code systems per resource type in [FHIR code systems](https://developers.anpheros.com/guides/fhir-code-systems).

## Related

- [Free FHIR database and sandbox](https://developers.anpheros.com/guides/free-fhir-database)
- [How Anpheros compares with other FHIR servers](https://developers.anpheros.com/guides/fhir-server-comparison)
- [Healthcare data interoperability](https://developers.anpheros.com/guides/interoperability)
- [FHIR code systems](https://developers.anpheros.com/guides/fhir-code-systems)
- [Medical data API](https://developers.anpheros.com/guides/medical-data-api)
- [Build a healthcare app](https://developers.anpheros.com/guides/build-a-healthcare-app)
- [API reference (OpenAPI)](https://developers.anpheros.com/docs)