Short answer: security in a health app answers four questions, in order. Who is this? Identity: a verified user (patient, clinician, system) through OpenID Connect and, for clinicians, the national professional identity; verification level matters more than password strength. What may they do? Authorisation: OAuth 2.0 (moving to 2.1) tokens with scopes in the SMART on FHIR syntax, derived from the patient's consent for a purpose and a duration, enforced at the data layer. What did they do? Accountability: an access log the patient can read and a FHIR AuditEvent trail for the organisation. Is the data safe at rest, in transit and in backups? Protection: encryption, key management, segregation, tested restores. Around them: the baseline of ISO 27001 and 27799, NIS2 and HIPAA's Security Rule, and the specific threats of health data (insider browsing, mis-filing, ransomware).
The map
Security and identity in a health app form seven layers: identity through OpenID Connect and national or professional IDs, authorisation through OAuth 2.0 and SMART on FHIR scopes, consent as the source of every grant, accountability through access logs and FHIR AuditEvent, protection through encryption and backups, a baseline of ISO 27001, ISO 27799, NIS2 and HIPAA, and patient-initiated sharing.
| Layer | Standard or practice | What it gives you | Page |
|---|---|---|---|
| Identity | OpenID Connect; national IDs (eIDAS, NHS login, GesundheitsID); professional identities (eHBA, CPS, UZI) | A verified subject with an assurance level | SMART App Launch explained |
| Authorisation | OAuth 2.0 and 2.1 (PKCE mandatory, no implicit or password grants); SMART on FHIR scopes (patient/Observation.rs); backend services with asymmetric client auth | Tokens bound to a user, a patient context and a scope | SMART App Launch explained, SMART on FHIR backend |
| Consent | FHIR Consent; purpose- and time-bound grants; revocation; break-the-glass with justification and alert | The patient as the source of every authorisation | Patient consent platform, Clinic access requests |
| Accountability | Per-record access logs visible to the patient; FHIR AuditEvent; tamper-evident storage; retention | Who saw what, when, why | Who viewed my medical record? |
| Protection | TLS 1.2+, encryption at rest with managed keys, field-level encryption for identifiers, segregated environments, backups with tested restore | Confidentiality and availability | ISO 27001 vs ISO 27799 |
| Baseline | ISO 27001 ISMS, 27799 health controls, NIS2 measures, HIPAA Security Rule, national schemes (HDS, DSPT, C5) | What hospitals, auditors and regulators expect | NIS2 for hospitals and vendors, HIPAA vs GDPR |
| Sharing | SMART Health Links and Cards; verifiable credentials | Patient-initiated sharing with a link or QR, revocable | SMART Health Links explained |
Identity: assurance over passwords
Identity in a health app depends on assurance rather than password strength: identity assurance levels such as NIST IAL, eIDAS substantial and high, or NHS login P9 describe how strongly a person was verified at enrolment, while multi-factor authentication and passkeys describe each login. Clinicians are identified through professional identities that are revoked when they leave.
A patient app that shows a full record must know it is talking to that patient. Identity assurance levels (NIST's IAL, eIDAS substantial and high, NHS login P9) describe how strongly the identity was verified at enrolment; authentication strength (multi-factor, passkeys) describes each login. Hospitals and national systems increasingly require verified identities from recognised schemes rather than self-asserted sign-ups, and the EU Digital Identity Wallet will become an accepted means. For clinicians, the professional identity (and its revocation when someone leaves) is the system of record for who may act as a clinician at all.
Authorisation: consent becomes scopes
Authorisation in a patient-controlled record translates the patient's consent, such as allowing a clinic to read lab results and conditions for 90 days, into OAuth scopes and patient context on the token, in SMART on FHIR syntax like patient/Observation.rs, enforced at the data layer on every request and revoked when the patient withdraws. Break-the-glass is a separate, audited path.
In a patient-controlled record, the patient's consent is the policy: this clinic may read my lab results and conditions for 90 days. The system translates it into OAuth scopes and context (which patient, which resources, which operations) on the token the clinic's system receives, enforces them on every request at the data layer, and revokes them when the patient withdraws. SMART on FHIR's scope syntax (patient/Observation.rs, patient/Condition.rs) is the lingua franca for this; granular scopes (by category or code) exist in SMART v2 for finer control. Break-the-glass (emergency access without consent) is a separate, audited path with mandatory justification and an alert to the patient, never a default. See Patient consent platform.
Accountability: the log the patient reads
Accountability in a health app means every access to a record, by whom, when, what and under which consent, is written to an append-only log the patient can read in their app and to an organisational audit trail in FHIR AuditEvent. ISO 27799 treats this as mandatory, and a visible log is the strongest deterrent to insider browsing.
Every access to a record, by whom, when, what, under which consent, written to an append-only log that the patient can read in their app, and to an organisational audit trail (FHIR AuditEvent) for security teams. ISO 27799 treats this as mandatory for health information; the GDPR's transparency principle and the EHDS's patient rights point the same way; the biggest real-world deterrent to insider browsing is a visible log. See Who viewed my medical record?.
Protection: the engineering baseline
The engineering baseline for protecting health data is TLS everywhere, encryption at rest with managed, rotated keys, separate encryption or tokenisation for direct identifiers, segregated environments with synthetic data outside production, least-privilege access with multi-factor authentication for administrators, secrets and vulnerability management, encrypted backups tested by restore against ransomware, and incident response within the GDPR and NIS2 clocks.
TLS everywhere, with modern ciphers and certificate pinning in apps where appropriate; encryption at rest with keys in a managed key service and rotation; separate encryption or tokenisation for direct identifiers; segregation of production from development, with synthetic data outside production; least-privilege access for staff, no shared accounts, multi-factor for all administrative access; secrets management; dependency and vulnerability management with disclosure; backups encrypted, tested by restore, and protected against the ransomware that has hit hospitals and laboratories repeatedly (WannaCry in 2017, the Düsseldorf hospital in 2020, Change Healthcare and Synnovis in 2024). Incident response with the 72-hour GDPR and 24-hour NIS2 clocks in one runbook.
Threats specific to health data
The threats specific to health data are insider browsing of acquaintances' records, mis-filing between patients, over-broad sharing granted for too long, advertising SDKs inside apps that handle health data, document-borne injection into AI features, and long retention over decades during which keys, formats and access rules must outlive staff and vendors.
- Insider browsing of records of acquaintances or public figures: relationship-based access and visible logs.
- Mis-filing between patients: identity reconciliation and provenance, not only access control.
- Over-broad sharing: a clinic that was granted "everything" for a year; scopes and durations with sensible defaults.
- Apps with advertising SDKs: no third-party trackers in anything that handles health data.
- Document-borne injection into AI features: content is data, never instructions (RAG on medical records).
- Long retention: records live for decades; keys, formats and access rules must survive staff and vendors.
In Anpheros
Anpheros applies the security map to itself with OAuth 2.0 with PKCE for apps and asymmetric client authentication for backends, consent per purpose and duration as the source of every clinic's access, a per-record access log in the person's app, encryption at rest and in transit, EU hosting, no advertising SDKs, and an ISMS along ISO 27001 and 27799.
Anpheros applies this map to itself: OAuth 2.0 with PKCE for apps and asymmetric client authentication for backends; consent per purpose and duration as the source of every clinic's access, with revocation and no silent break-the-glass; a per-record access log in the person's app; encryption at rest and in transit, EU hosting, no advertising SDKs; an ISMS along ISO 27001 with the 27799 health controls. The developer site documents authentication, consent and security.
Related pages
- SMART App Launch explained
- Patient consent platform
- Who viewed my medical record?
- SMART Health Links explained
- ISO 27001 vs ISO 27799
- NIS2 for hospitals and health-tech vendors
- Platform security (developer site)
- Authentication (developer site)
Sources
- HL7 SMART App Launch
- IETF: OAuth 2.1 (draft)
- OpenID Connect Core 1.0
- HL7 FHIR R4: AuditEvent
- HL7 FHIR R4: Consent
- NIST SP 800-63-4: Digital Identity Guidelines
- ISO 27799:2016
- ENISA: Procurement guidelines for cybersecurity in hospitals
Frequently asked questions
Is OAuth 2.1 different from 2.0?
OAuth 2.1 consolidates 2.0 with its security best practices: PKCE is required for all clients, the implicit and password grants are removed, redirect URIs must match exactly, and refresh tokens for public clients must be bound or rotated. SMART on FHIR v2 already requires most of this.
What is break-the-glass?
Emergency access to a record without the patient's prior consent, by a clinician who asserts a justification. It must be rare, logged, reviewed and reported to the patient; it is never the default access path.
Why should patients see the access log?
Because it is the strongest deterrent to inappropriate access and the clearest expression of control: the person sees which clinic read what and when, and can revoke. ISO 27799 and the EHDS point the same way.
Do I need a separate audit system?
You need an append-only audit trail (FHIR AuditEvent or equivalent) that the application cannot alter, retained per policy, and a patient-facing view derived from it. Whether it is a separate system or a protected store inside the platform is an implementation choice.
Try it free in the sandbox
Your first FHIR call in 5 minutes. An HL7 FHIR R4 API with the patient's consent built in: try it in the sandbox, then connect your own app or clinic system.
Free · 30 synthetic patients · no card
Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.
About Anpheros →
AnpherosThe more you log, the clearer your record
Your health history in one place, under your control.
Free · Works in your browser · No card
