# Medical data infrastructure

> What medical data infrastructure is and where Anpheros fits: a patient-controlled HL7 FHIR R4 record, an API, consent, provenance and audit as shared building blocks for healthcare applications and AI.

Source: https://developers.anpheros.com/guides/medical-data-infrastructure

**Medical data infrastructure is the layer that stores patient health data in a structured, standard form and makes it available to applications under rules the patient controls.** Anpheros is interoperable medical-data infrastructure: it keeps one HL7 FHIR R4 record per patient and exposes it through an API, with consent, provenance and an audit built in, so that healthcare applications, medical software and AI services can be built on top of it instead of each one building its own medical database.

In practice, developers use Anpheros as the medical data layer of their product — the FHIR backend and patient-record store of a healthcare app, a clinic integration or an AI application. It is reached through an API (REST and FHIR R4), not as a general-purpose SQL database, and it does not host AI models.

## Why it is a separate layer

Every application that handles health data needs the same foundations, and none of them are the application's actual product:

- a **data model** for observations, diagnoses, medications, documents and the rest of a medical record;
- **identity and isolation**, so one application cannot see another's patients;
- **consent**, so a patient decides which application sees what, and for how long;
- **provenance and history**, so every value can be traced to who recorded it and nothing is silently overwritten;
- **integration** with laboratories, clinics, devices and other applications;
- **standards**, so the data can leave the application and still be understood;
- and, increasingly, a safe way to hand the right part of a record to an **AI model**.

When each application builds these on its own, patient data ends up fragmented across incompatible silos. Medical data infrastructure turns them into shared, tested building blocks.

## The chain Anpheros implements

```
Medical data          measurements, lab results, diagnoses, medications, documents, visits
     ↓
HL7 FHIR R4           stored as standard resources — 26 types, versioned
     ↓
API                   /fhir/R4 (strict FHIR) and /v1 (simplified REST), same ids
     ↓
Patient record        one record per person, isolated per application (pairwise ids)
     ↓
Consent               OAuth 2.1 / SMART on FHIR grants: scopes, duration, revocation
     ↓
Applications          patient apps, clinic and lab systems, third-party apps
     ↓
AI                    context API: the relevant part of the record for a model, with sources
```

## The building blocks, and where each is documented

| Building block | In Anpheros | Read more |
|---|---|---|
| Data model | 26 HL7 FHIR R4 resource types; LOINC, ICD-10, ATC, UCUM | [FHIR platform](https://developers.anpheros.com/guides/fhir) |
| Record | one FHIR record per patient; family members have their own records | [Patient medical record](https://developers.anpheros.com/guides/patient-medical-record) |
| Storage and history | every update is a new version; documents immutable, encrypted with a customer-managed key in the EU | [Digital medical record infrastructure](https://developers.anpheros.com/guides/digital-medical-record) |
| Access | API keys per project, OAuth tokens per patient, `404` for anything outside your scope | [Healthcare API](https://developers.anpheros.com/guides/healthcare-api) |
| Consent | grants for 30–365 days, per resource type and category, revocable at once | [Consent and access model](https://developers.anpheros.com/guides/consent) |
| Provenance and audit | every write records its author and source; every read is visible to the patient | [Security, privacy and data residency](https://developers.anpheros.com/guides/security) |
| Integration | FHIR transactions, lab report import, signed webhooks, SDKs | [Healthcare integrations](https://developers.anpheros.com/guides/healthcare-integrations) |
| Interoperability | FHIR R4, International Patient Summary, SMART on FHIR, HL7 v2 lab messages | [Healthcare data interoperability](https://developers.anpheros.com/guides/interoperability) |
| AI context | a budgeted, source-labelled context for any model you choose | [AI healthcare applications](https://developers.anpheros.com/guides/ai-healthcare) |

## Infrastructure versus application

Anpheros separates the two on purpose. **Anpheros Daily** is an application — screens, reminders, an assistant — for patients and families. **Anpheros Platform** is the infrastructure underneath. Daily writes to the record through the same public API as any other application, which is what makes the record portable: an application built by someone else can read what Daily wrote, with the patient's consent, in the same FHIR form.

## What infrastructure does not decide for you

Anpheros holds and governs the data; it does not make clinical decisions, design your user experience or cover your regulatory obligations. Anpheros does not claim medical-device certification or other regulatory approvals. Production use requires a verified organisation and a signed data processing agreement, and the platform is in private beta (single zone, no contractual SLA).

## Related

- [What is Anpheros?](https://developers.anpheros.com/guides/what-is-anpheros)
- [Healthcare API](https://developers.anpheros.com/guides/healthcare-api)
- [Healthcare software development](https://developers.anpheros.com/guides/healthcare-software)
- [AI healthcare applications](https://developers.anpheros.com/guides/ai-healthcare)
- [Build with Anpheros](https://developers.anpheros.com/guides/build-with-anpheros)