Last updated: June 2026 — eIDAS Article 26 sole control, consent & evidence capture
The AES Portal is designed to produce legally compliant advanced electronic signatures for prescriptions in England and Wales, meeting the requirements of both electronic prescription regulations and broader health and social care digital standards.
The Human Medicines Regulations 2012 (SI 2012/1916) govern the prescribing, supply and administration of medicines in the UK. Electronic prescriptions issued through an AES-compliant system satisfy the signature requirement under these regulations, provided the signature:
The AES system meets all three requirements through:
| Requirement | How Met |
|---|---|
| Identifies the prescriber | Keycloak sub UUID + preferred_username + registered GMC/GDC/NMC number captured at signing time |
| Uniquely linked | Clinician's own OIDC access token (password + MFA) used for signing, not a shared service account. MFA acr claim + auth_time stored as evidence |
| Tamper detection | PAdES-B-LTA PDF embeds X.509 certificate + TSA timestamp. SHA-256 hash computed and stored alongside signing evidence |
Additional compliance measures implemented (June 2026):
The AES Portal serves as a replacement for the NHS Electronic Prescription Service (EPS) FHIR-based signing infrastructure. Where EPS relied on NHS Smartcards and the Spine, the AES Portal provides:
The UK's retained version of the eIDAS Regulation (Electronic Identification and Trust Services Regulation) establishes two key requirements for advanced electronic signatures:
Article 25(1) — Legal admissibility:
"shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements for qualified electronic signatures."
This means an AES signed prescription is legally admissible as evidence.
Article 26 — Sole control (implemented June 2026):
An advanced electronic signature must meet four requirements:
| Article 26 Requirement | AES Implementation |
|---|---|
| (a) Uniquely linked to the signatory | Keycloak sub UUID stored with every signing; user JWT verified via multi-realm JWKS |
| (b) Capable of identifying the signatory | preferred_username + Keycloak sub + professional registration number + browser IP/UA captured |
| (c) Created using means under sole control | Clinician's own OIDC token (password + MFA), NOT a shared service account. MFA acr claim proved via Keycloak |
| (d) Linked to data in detectable way | PAdES-B-LTA PDF + SHA-256 hash in evidence + hash-chained audit log |
In the booking app integration, the AES system uses a two-tier token approach:
Priority 1 — User's OIDC access token (from request.session['oidc_access_token']): The clinician's own JWT issued by Keycloak after MFA login. Provides full Article 26 compliance evidence (sub, acr, auth_time, IP, UA, consent).
Priority 2 — Service account token (fallback): Used if the user JWT is unavailable or from an unrecognised realm. Reduced evidence but preserves signing functionality.
| Requirement | How AES Portal Satisfies It |
|---|---|
| Signer identity verified | Keycloak authentication (multi-realm support — each clinic operates in its own realm) with clinician role verification; JWT signature verified via realm-specific JWKS |
| Signature under sole control | User's own OIDC access token with MFA (not a shared service account); explicit consent checkbox with timestamp; real client IP + browser UA captured |
| Document integrity | Cryptographic hash chain; PAdES-B-LTA embeds X.509 + TSA; any post-signing modification invalidates signature |
| Non-repudiation | Digital certificate binds signature to clinician identity; Keycloak sub UUID + acr claim stored |
| Long-term verifiability | PAdES-B-LTA format embeds timestamp + OCSP/CRL data; PDF SHA-256 hash stored for independent verification |
| Consent & intent | Explicit consent statement signed by clinician before each signature; consent text + timestamp stored in evidence |
| Evidence export | Downloadable Evidence Summary JSON containing all seven data pillars (cryptographic, identity, forensic, intent, temporal, chain-of-custody, tamper evidence) |
| Audit trail | Every signature, download, and delivery action logged to hash-chained audit trail (audit_chain.jsonl) with SHA-256 links between entries |
| Data protection | Signed PDFs transmitted via HTTPS; encrypted SMTP fallback; patient data minimised (AES stores prescription references only) |
The AES Portal supports compliance with the DSPT requirements by providing:
/data/audit/) with SHA-256 hash chaining.The system has been designed with DTAC standards in mind:
| Criterion | Coverage |
|---|---|
| Clinical Safety | Prescription content validated before signing; consent checkbox required before AES signing; signature field prevents unsigned modifications |
| Data Protection | Privacy notice displayed at /privacy; data minimisation in signed PDFs; patient data never stored in AES Portal |
| Evidence Capture | SHA-256 hashing, forensic IP/UA, consent timestamps, hash-chained audit trail — all downloadable as Evidence Summary JSON |
| Technical Security | HSM-backed key storage; RFC 3161 timestamping; CRL distribution; multi-realm JWT verification |
| Interoperability | PAdES-B-LTA standard format; REST API for booking apps; NHS ODS Pharmacy Directory API integrated |
| Accessibility | Booking app UI follows standard accessibility practices; prescription detail view includes all evidence for audit |