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.

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

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

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

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

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.

Related

• Patient medical record
• Medical app backend and database
• Security, privacy and data residency
• Medical data infrastructure