Article 5 — Principles
5(1)(c) Data minimisation
Free text is stripped of identifying detail before it travels anywhere it does not need to go, and the stripping happens close to the source rather than after a copy has spread.
The same identifier always becomes the same pseudonym, so a record stays followable across a care episode without the person being nameable from it.
5(1)(e) Storage limitation
Recordings and their derivatives expire on a clock set by the zone, not by whoever created them, and the same rule applies on an edge appliance as in the cloud.
A deletion is itself an audited event, so "it was removed" is a fact with a record rather than an absence you have to trust.
5(2) Accountability
Every action that touches clinical data is audited by construction — the audit is declared beside the code that acts, so an unaudited path is a build failure rather than an oversight found later.
The trail cannot be edited after the fact, and it is queryable as FHIR so you can answer a question about your own data without asking us.
Article 6 and Article 9 — Lawfulness and health data
The lawful basis for processing, and the Article 9(2) condition that permits health data, are the controller's to establish. We hold the data inside your own boundary and give you the audit trail and the configuration record that evidence how it was handled.
Article 7 — Consent
Where the platform records a consultation, consent is captured in the flow of the visit and written to a ledger per admission, with no identity in the ledger itself.
Consent must be as easy to withdraw as to give, and withdrawal must actually stop the processing rather than only being noted.
Articles 12–14 — Transparency
What a data subject is told, and when, is the controller's obligation. The platform's contribution is that the record shows what happened to their data, so the information you give them can be accurate rather than approximate.
Articles 15–20 — Access, rectification, erasure, portability
A request to be forgotten is an operable request rather than a support ticket: it has a defined path through the platform.
Erasure reaches the audit trail correctly — the personal data goes, the fact that an action occurred remains, because an audit trail that can be emptied is not one.
A patient's own record can be exported in a portable form, as a bundle a person or another provider can actually use.
Restriction of processing — Article 18 — is honoured by the systems that would otherwise read the record.
Article 25 — Data protection by design and by default
Identifying detail is removed before data reaches an inference path, and a zone that cannot state its rules fails closed instead of falling back to a weaker default.
The rules in force for your organisation are visible to you rather than asserted by us.
Article 28 — Processor obligations
The processing agreement, the instructions we act on, the confidentiality undertakings of our staff, and the terms binding any sub-processor are contractual.
What the contract promises, the platform enforces. One organisation cannot read another's data — a cross-organisation read returns nothing rather than an error that hints at what exists. Credentials are scoped to a single organisation, and no privileged credential lives on the machine that serves your data.
Article 28(3)(h) requires that we make audits possible. Our operators cannot read your clinical data, and that is a property of the system rather than a policy we ask you to believe.
Article 30(2) — Records of processing
The categories of processing carried out for each controller, the transfers, and the security measures are recorded. The platform's own contribution is the audit trail and the visible effective configuration; the register itself is a document we maintain.
Article 32 — Security of processing
Clinical data is encrypted at rest under a key belonging to your organisation, not a shared platform key. Secrets are wrapped in the wire form, so they are not readable in transit by anything that merely carries them. Stored blobs describe themselves, so an encrypted object can be identified and rotated without being opened.
Encryption keys can be held so that neither party can act alone.
Wiping an edge appliance leaves a trail in the cloud, so a device disappearing is an event you can see rather than a silence.
Lifecycle transitions that affect an organisation's data are audited on both sides of the transition.
Penetration testing, vulnerability management and the security review cadence are operational practice rather than a property of the code.
Articles 33–34 — Personal data breaches
Article 33(2) requires a processor to notify the controller without undue delay after becoming aware of a breach. The platform must therefore detect and report an incident to you rather than wait to be asked.
Notification to the supervisory authority under 33(1), and to data subjects under 34, is the controller's decision and the controller's clock.
Article 35 — Data protection impact assessment
The assessment is the controller's, for the processing the controller decides upon. What we owe is the material it needs: what is processed, where it is held, who can reach it, and what is proven about each — which is what this page and the audit trail are for.
Article 37 — Data protection officer
Appointment and the DPO's independence are organisational obligations, not system behaviour.
Articles 44–49 — Transfers to third countries
Data is processed within the zone your organisation is bound to, and a child zone cannot weaken what its parent requires. Where processing must stay inside a border, the platform will not silently step outside it.
Residency is not the same obligation as a transfer instrument. Where a transfer does occur, the standard contractual clauses or adequacy decision that permit it are contractual.
Article 82 — Liability
Allocation of liability between controller and processor is contractual.