# Digital medical record infrastructure

> The infrastructure a digital medical record needs — structure, history, documents, isolation, consent, audit, exchange — and why it is kept separate from the patient-facing application.

Source: https://developers.anpheros.com/guides/digital-medical-record

**A digital medical record needs two different things: a patient-facing application that people use every day, and the infrastructure underneath that stores, protects and shares the record.** Anpheros provides the second: the storage, versioning, identity, consent, audit and exchange of the record, through an API. The patient-facing application can be Anpheros Daily, or one you build.

## Application versus infrastructure

| | Patient-facing application | Medical data infrastructure |
|---|---|---|
| What it is | screens, notifications, reminders, charts, an assistant | the record itself and the rules around it |
| Changes often | yes — design, features, platforms | rarely — it must stay stable and compatible |
| Examples of work | a symptom diary, a medication reminder, a family calendar | FHIR storage, version history, consent, provenance, audit, lab import, webhooks |
| In Anpheros | Anpheros Daily (Android, macOS, web) | Anpheros Platform (`platform.anpheros.com`) |

Keeping them apart is what lets a record outlive any single application and be shared between several. Anpheros Daily follows this split: what people record in the app is written to the platform through the same public API that any other application uses, so it is available — with the patient's consent — to other applications in the same FHIR form.

## What the infrastructure has to provide

### Structure
A record is only useful if other software can understand it. Anpheros stores it as HL7 FHIR R4 resources — 26 types — with standard codes (LOINC, ICD-10, ATC, UCUM) and keeps the original text next to every code. [FHIR platform](https://developers.anpheros.com/guides/fhir)

### History
Medical data is corrected, not overwritten. Every update creates a new version, readable through `/fhir/R4/{type}/{id}/_history`; conditional updates with `If-Match` prevent two writers from overwriting each other (a stale version answers `412`).

### Documents
Scans and PDFs are stored as `DocumentReference` with the original file: uploaded through the platform or directly to storage, then finalised with a SHA-256 checksum and size. After finalisation the original cannot be changed; values extracted from it point back to it (`derived_from`). Files are kept in an EU storage bucket encrypted with a customer-managed key, up to 25 MiB each.

### Identity and isolation
Each application works inside a project and sees only its own patients (plus those that granted it access), under its own pairwise identifiers. A record outside its reach does not exist for it (`404`).

### Consent
A patient grants an application access for a period (30–365 days), to specific resource types and actions, optionally limited to a category. Grants are mirrored as FHIR `Consent` resources and can be revoked at any time. [Consent and access model](https://developers.anpheros.com/guides/consent)

### Provenance and audit
Every write records who wrote it (patient, practitioner, device, import or AI), for which organisation and from which system. Every read is logged and shown to the patient per application.

### Exchange
The record can be exported as a whole (`Patient/$everything`), summarised in the International Patient Summary format (`Patient/$summary`), fed by laboratories (CSV, HL7 v2 ORU^R01, JSON) and watched through signed webhooks. [Healthcare integrations](https://developers.anpheros.com/guides/healthcare-integrations)

### Residency and deletion
Data is stored and processed in the European Union. Deleting a patient deletes every resource of the record.

## Building your own patient-facing application

If you are building the application layer, you can concentrate on the experience and use Anpheros for the record:

1. create a patient for each user (`POST /v1/patients`) or ask an existing Anpheros user for consent;
2. write what the user records (`/v1/patients/{id}/observations`, `/conditions`, `/medications`, `/documents`);
3. read it back as lists or a timeline (`/v1/patients/{id}/timeline`);
4. subscribe to webhooks to refresh the screens when a lab or clinic adds something.

The full walkthrough is in [Build a healthcare app](https://developers.anpheros.com/guides/build-a-healthcare-app).

## Related

- [Patient medical record](https://developers.anpheros.com/guides/patient-medical-record)
- [Medical app backend and database](https://developers.anpheros.com/guides/medical-app-backend)
- [Security, privacy and data residency](https://developers.anpheros.com/guides/security)
- [Medical data infrastructure](https://developers.anpheros.com/guides/medical-data-infrastructure)