This is a fictional but realistic Solution Architecture Document for Medwick Healthcare Trust’s MyMedwick Patient Portal. It demonstrates the Architecture Description Standard at Comprehensive depth for a Tier 1 Critical clinical system governed by MediCore clinical safety standards and UK data protection law. Every section is completed with realistic content showing what a mature, well-documented SAD looks like for a Trust-class solution where patient harm is a credible risk.
Fictional organisation: Medwick Healthcare Trust – a mid-sized national-health-service-style hospital trust, approximately 12,000 staff, serving 800,000 patients across three acute sites and a network of community clinics.
Fictional solution: MyMedwick Patient Portal – a web and mobile application providing outpatient appointment management, test results, letters, and prescription management to patients, integrated with the Trust’s Electronic Patient Record (EPR), the MediCore Spine, and MediCore e-Referral Service.
This SAD describes the architecture of MyMedwick, Medwick Healthcare Trust’s patient-facing digital service. The portal gives patients secure, self-service access to their outpatient appointments, clinic letters, test results, and repeat prescription requests. It reduces clinic DNA (Did Not Attend) rates, eases the administrative burden on outpatient booking teams, and supports the Trust’s commitment to the MediCore National Digital Health Plan objective of digital-first patient access.
In scope:
MyMedwick web application (React) and mobile applications (iOS, Android)
Azure landing zone resources in UK South (primary) and UK West (DR)
MyMedwick is a web and mobile patient portal that gives patients of Medwick Healthcare Trust secure, real-time access to their outpatient care. Patients can view and reschedule appointments, read clinic letters, see pathology and radiology results released by their clinical team, request repeat prescriptions, update contact preferences, and opt in or out of SMS reminders.
The solution is built on Microsoft Azure (UK South primary, UK West DR) using a layered architecture: React single-page application for the web front end; Ionic/Capacitor hybrid mobile apps; .NET 8 microservices behind Azure API Management; Azure SQL for portal-owned data; and an integration layer that exposes and consumes FHIR R4 APIs against the Trust EPR, the MediCore Spine, and the MediCore e-Referral Service. Patient identity is provided by Azure AD B2C with MediCore-compatible identity proofing; clinician identity (for staff administration functions) is provided by MediCore CIS.
Clinical safety has been assessed under CS-129 (manufacturer) and CS-160 (deployment). A Clinical Safety Officer (Dr Amir Doe) has signed off the clinical safety case; the Hazard Log is actively maintained. The service is included in Medwick’s annual Data Security and Protection Toolkit (DSPT) submission.
MediCore National Digital Health Plan – digital-first patient access
National commitment for every patient to have digital access to their outpatient records, appointments and prescriptions
Critical
Reduce outpatient DNA rate
Trust DNA rate for outpatient appointments is 9.4% (national benchmark 6.7%); target reduction of 2 percentage points through self-service rescheduling and SMS reminders
High
Reduce call centre burden
Outpatient booking team handles approximately 3,200 calls/day, of which 62% are appointment enquiries resolvable via self-service
High
Improve patient experience and CQC Well-Led evidence
Patient survey satisfaction with appointment communications at 58%; target improvement to greater than 75%
High
Replace ageing patient portal (Patient Knows Best pilot)
Existing PKB pilot covers only 40,000 patients, lacks mobile app, and contract expires 2026-Q3
High
Support ICS-wide digital front door objective
Align with Medwick Integrated Care System (MICS) digital strategy for a unified patient-facing channel
Evaluated in ADR-003; rejected in favour of Azure AD B2C due to Trust control over identity proofing journey, faster enrolment, and ability to federate MediCore login as an external IdP later if required
Clinician Identity
MediCore CIS (Clinician Identity Service)
Yes
Mandatory for MediCore staff accessing patient-identifiable data; used for admin / service desk functions
Spine Integration
MediCore Spine (PDS, SCR) via TLS-MA
Yes
National service, mandatory for Patient Demographic Service lookups
e-Referral
MediCore e-Referral Service (e-RS)
Yes
National service, mandatory for outpatient referral lifecycle
SMS / Email
Azure Communication Services (ACS)
Yes
Trust has enterprise Azure agreement; ACS supports UK data residency
Secure Email
MediCoreMail
Yes
Used for clinical correspondence notifications where appropriate
The Trust currently offers limited digital patient access:
A Patient Knows Best (PKB) pilot covering ~40,000 patients across renal and diabetes services, providing records access only (no appointment management, no prescriptions). PKB is contracted until 2026-Q3.
A text reminder service (commercial SMS gateway, Firetext) sending appointment reminders two days before appointment. This has no patient interaction – patients cannot confirm, cancel, or reschedule from the SMS.
An online appointment cancellation form (SharePoint-based) which posts to a shared mailbox and is manually processed by the booking office during working hours.
Key limitations of the as-is:
No unified patient-facing portal; patients must telephone the booking office for all changes
No mobile app; PKB web app is not usable on mobile
DNA rate 9.4% (above national benchmark of 6.7%)
Approximately 62% of booking office calls are resolvable by self-service
No surfacing of test results to patients; results are conveyed by letter (typically 2-3 week delay) or phone call
Patient Knows Best contract ends 2026-Q3 – mandatory replacement
What is being retained: Cerner Millennium EPR (authoritative clinical record); MediCore Spine and e-RS integrations (reused via new FHIR facade); MediCoreMail; MediCore CIS.
What is being replaced: Patient Knows Best pilot (decommissioned 2026-Q3); Firetext SMS (replaced by Azure Communication Services); SharePoint cancellation form.
What is being decommissioned: PKB integration, Firetext contract, SharePoint appointment cancellation form – all after 3-month parallel run.
Trust enterprise Azure agreement; Azure UK South/West provide sovereign UK data residency; ISO/IEC 27018 assurance for cloud PII; NCSC/MediCore Authority pattern alignment
All infrastructure on Azure; no AWS or GCP
All data (including PII and clinical data) in UK regions
UK GDPR, MediCore Data Security & Protection Toolkit, and Caldicott Principle 7 (data sharing)
UK South primary, UK West DR; no data replication outside UK
FHIR R4 as the canonical clinical data contract
MediCore Authority interoperability standards and forward compatibility with ICS-wide data sharing
FHIR facade microservice required; HL7v2 from EPR translated to FHIR
Azure AD B2C for patient identity (not MediCore login)
Trust control over identity proofing, enrolment UX, and MFA policy; MediCore login can be added as federated IdP in a later phase
Custom B2C policies to be maintained; explicit ADR (ADR-003)
CS-129 and CS-160 clinical safety compliance mandatory
MediCore Digital’s mandatory clinical safety standards for any health IT system with clinical impact
Clinical Safety Officer required; Hazard Log maintained; deployment safety case signed before go-live
Two-factor authentication required for all patients
UK GDPR Article 32 and MediCore CIS assurance equivalence
Justification: MyMedwick is a Tier 1 Critical clinical system because failure modes include potential patient harm:
Clinical safety: Incorrect results display, mis-identification of a patient’s record, or silent failure of appointment reminders could contribute to patient harm (missed appointment for time-sensitive oncology follow-up; acting on wrong results). Clinical risk assessed and documented in the Hazard Log (MHT-HAZ-LOG-0208).
Service continuity: At steady state, MyMedwick is the primary digital channel for ~280,000 enrolled patients. Extended outage would substantially increase call centre load (projected x3.5 call volume within 24 hours of outage).
Regulatory exposure: A confidentiality breach of patient data would require ICO notification within 72 hours (UK GDPR Art 33) and trigger mandatory reporting under the MediCore DSPT.
Reputational: Patient trust and Trust Board reputation sensitivity is high; CQC Well-Led and Responsive domains reference digital access.
Financial impact: Not the primary driver, but DNA reduction target (2 pp) represents ~GBP 1.8m/year of recovered clinic capacity.
Yes – processes special category personal data (health) under UK GDPR Article 9. Not a regulated medical device (formally assessed). Subject to MediCore-specific clinical safety standards (CS-129 manufacturer, CS-160 deployment).
Yes — Azure Front Door + CDN cache static assets at the edge (~92% cache hit rate); Azure Cache for Redis (Premium) for session state, API response caching for the patient portal (TTL 60s for non-PII reference data). Spine demographic look-ups cached for the duration of a patient session.
Batch processes consolidated rather than continuously polling
Yes — appointment reminder generation runs as nightly batch (00:30 UTC) rather than per-event; PDS demographic refresh runs weekly per cohort, not on every login; clinical-letter ingestion via webhook from EPR rather than polling.
Async / event-driven patterns to flatten peak load
Yes — Service Bus + Azure Functions for SMS/email dispatch, EPR sync, audit log shipping. Consumer functions auto-scale on queue depth; capacity returns to zero at idle.
Heavy framework choices weighed against lighter alternatives
Considered — .NET 8 / ASP.NET Core retained for the patient portal API (existing Trust skill, AOT compilation reduces start time and memory). Azure Functions Isolated Worker selected over in-process; chosen for clearer dependency isolation and a smaller memory footprint per invocation.
No – production and non-production environments live in separate Azure subscriptions with no VNet peering. Promotion is via Azure DevOps pipelines only. Production data is never copied to non-production; masked synthetic data is used.
Not applicable – no IoT devices are part of this solution. Trust Internet-of-Things programmes (e.g., remote vital signs monitoring) are separate initiatives.
Azure UK South (London) primary and UK West (Cardiff) DR — chosen for data residency and MediCore DSPT requirements. Microsoft has committed to 100% renewable energy matching across UK regions by 2025. UK West’s published grid mix is on average cleaner than UK South.
Non-production environments auto-shutdown
Yes — non-prod App Service plans scaled-in 19:00-07:00 weekdays + weekends via Azure Automation; non-prod Azure SQL auto-paused after 1 hour idle. Estimated saving £800/month (referenced in 4.5).
Compute family chosen for performance-per-watt
Yes — Premium v3 (Pv3) App Service plan SKUs throughout; Microsoft published data shows ~25% better performance-per-watt than Pv2 with faster warm-up. ADLS Gen2 uses latest-generation Microsoft hardware.
Auto-scaling configured to release capacity when idle
Yes — App Service Plan auto-scale: scale-out at >70% CPU 10 min, scale-in at <30% CPU 20 min. Azure Functions consumption plan scales to zero between bursts.
DR strategy proportionate to recovery objective
Active-passive (warm) with Azure SQL geo-replica + ADLS Gen2 RA-GRS + App Service in UK West deployed via IaC on failover. RTO 4 hours, RPO 15 minutes meets clinical-safety RTO. Hot active-active rejected: would have doubled compute footprint without RTO benefit beyond what’s clinically required.
Encrypted at rest (TDE + Always Encrypted for PII fields) and in transit (TLS 1.3); access-controlled (RBAC + PIM); audited; 7-year audit retention
MediCore healthcare data classification: All patient-identifiable data is “Official-Sensitive” with the MediCore handling caveat “PERSONAL”. The Caldicott Principles are applied to every data use.
Patient enrolment (self-service with National Patient ID + PDS verification); clinical data read-through from EPR via FHIR facade; no primary clinical data created in portal
PDS demographics match; National Patient ID validation (Modulus 11); consent captured and logged
Processing
Domain services resolve each request against EPR / Spine in real time, applying results release rules and consent checks
Every patient data access logged with National Patient ID, user session, and purpose; Caldicott justification coded per access type
Storage
Portal-owned data in Azure SQL (TDE + Always Encrypted); immutable audit logs in ADLS Gen2
Customer-managed keys in Azure Key Vault (HSM); automated daily backups; geo-redundant for audit
Sharing / Transfer
To MediCore Spine (TLS-MA), to e-RS, to GP Connect (Phase 2), to ACS (patient contact details for SMS/email delivery only); no third-country transfer
Data minimisation – only send what is required; DPIA DPIA-2025-004 assesses each flow
Archival
Audit log transitions from hot (1 year) to cool (years 2-7) in ADLS lifecycle policy; SQL archival is application-level (mark as archived)
Lifecycle policies, WORM immutability on audit container (7-year legal hold)
Deletion / Purging
On patient request (UK GDPR Art 17 with MediCore records caveats) or at end of retention; pseudo-anonymised research aggregates may be retained
Data Retention Committee approves; tombstone records preserved for audit trail integrity
Production data is never copied into non-production environments. Staging uses a masked dataset derived from EPR test data where all National Patient IDs, names, addresses, dates of birth, and contact details are replaced by realistic synthetic values using a deterministic tokenisation approach. Referential integrity (appointment-to-patient, result-to-patient) is preserved using the tokens. Approved by IG Lead (2025-04-08).
Yes – structural integrity enforced via Azure SQL constraints; clinical data integrity enforced by reading through to the EPR (the authoritative source) for any decision-relevant values; hash verification on audit log blobs (ADLS append-blob with content MD5).
Patient identity integrity is an explicit Hazard Log hazard (HAZ-04 – see 3.6) and is mitigated by PDS demographic verification on every enrolment and on any change to patient demographics.
Yes – all customer data (PII and clinical data) remains within the United Kingdom. Primary in UK South (London); DR in UK West (Cardiff). Azure Policy “Allowed Locations” rejects any resource deployment outside UK. ACS SMS / email uses UK region endpoints. The Microsoft Online Services DPA, combined with Microsoft’s UK data residency commitments for ACS and Azure SQL, is assessed as adequate for UK GDPR purposes. Any future third-country transfer would require a Transfer Risk Assessment (TRA) and Standard Contractual Clauses.
Retention periods minimised to regulator + business need
Yes — patient identifiable data retained per MediCore Records Management Code 2021 (ranges 8 years for adult outpatient records to lifetime+8 for some categories); audit logs 25 years (MediCore DSPT requirement); session data ≤ 24 hours. ADLS Gen2 lifecycle policies enforce automatic expiry; no “indefinite” retention.
Older data tiered to cold/archive storage
Yes — ADLS Gen2 lifecycle: Hot for current year, Cool for years 2-3, Archive for years 4+. Azure SQL longer-term retention (LTR) backups stored in cool tier. ~70% of historical data in Cool/Archive.
Unused or duplicate replicas
Single Azure SQL primary + 1 DR geo-replica; no read replicas (the application is light-read for individual patients). Quarterly review of storage accounts via Azure Advisor recommendations.
Compression applied
Brotli on HTTPS responses (~70% reduction on FHIR JSON payloads); gzip on audit log uploads to ADLS; FHIR resources are stored compressed in cold tiers.
Cross-region replication justified
Azure SQL geo-replica required by clinical-safety RTO. ADLS GRS chosen over LRS specifically to support DR; LRS would not have met the RPO. No cross-region replication outside UK regions.
Large data transfers off-peak
Nightly EPR ingest 02:00-04:00 UTC; weekly Spine batch reconciliation Saturday 03:00 UTC. Both align with low UK grid carbon intensity.
Critical – exposure of patient records would breach UK GDPR, require ICO notification within 72 hours, and cause lasting loss of patient trust; potential fines up to 4% of Trust turnover
Integrity
Critical – incorrect display of results or appointments could contribute to patient harm (missed appointment, acting on wrong result) – see Hazard Log HAZ-02, HAZ-03, HAZ-04
Availability
High – extended outage would increase booking office load ~3.5x and may delay access to clinical information; not life-critical because EPR and clinical services remain available
Non-Repudiation
High – inability to prove a patient’s consent or a specific action (cancellation, prescription request) would undermine clinical and legal accountability
Azure DDoS Standard; Front Door absorbs edge; APIM rate limiting; graceful degradation
Elevation of Privilege
Standard user escalates to admin
Broken access control
Low
Critical
RBAC + ABAC (patient can only see own National Patient ID data, enforced at service layer and re-validated in FHIR facade); pen testing annually (NCC Group)
Quarterly for admin roles; annual for patient accounts (dormant > 18 months auto-suspended)
Segregation of duties
Developers cannot deploy to production (pipeline enforced); admins cannot modify clinical data in EPR from portal; ops cannot read patient clinical data (access to PII columns via Always Encrypted requires explicit Key Vault grant with break-glass logging)
Delegated authorisation
Proxy access (e.g., parent for child aged under 13) is NOT supported in v2.0 – documented limitation; planned for v3.0 subject to IG assurance
Azure Landing Zone hub-spoke; VNet per environment; subnets per tier (app, data, management); NSGs with deny-by-default; Azure Firewall at hub; Private Endpoints for all PaaS; no public network access to SQL, Key Vault, Storage, Service Bus
Ingress filtering
Azure Front Door Premium with WAF (OWASP CRS 3.2 + Microsoft managed rulesets), bot protection, rate-based rules, geo-rules; APIM policies (JWT validation, schema validation, rate limit)
TLS 1.3 enforced for all external; TLS 1.2 minimum internally; private CA for service-to-service mTLS optional; Azure Key Vault + Managed HSM for certificate management
national healthcare secure network boundary
Dedicated national healthcare secure network CN-SP connection (2 links, diverse carriers) with MediCore-approved firewalling
Patient opens app and navigates to “My Appointments”
Pre-conditions
Patient is enrolled, authenticated (Azure AD B2C session valid), has given consent to SMS/email communications, has at least one scheduled outpatient appointment
Main Flow
1. App calls GET /appointments on Patient BFF with Bearer JWT. 2. BFF validates token (JWT signature, audience, not expired). 3. BFF calls Appointments Service with patient context (National Patient ID from session). 4. Appointments Service checks Redis cache (60s TTL) for patient appointments. 5. Cache miss: Appointments Service calls FHIR Facade. 6. FHIR Facade calls Cerner FHIR R4 Appointment search by patient identifier. 7. FHIR Facade normalises to MyMedwick canonical model. 8. Appointments Service filters to outpatient-type only and applies results release rules. 9. Appointments Service caches and returns response. 10. BFF aggregates and returns to app. 11. Audit event emitted to Service Bus.
Post-conditions
Patient sees list of appointments; audit event recorded with National Patient ID, session ID, timestamp, purpose=view-appointments
Views Involved
Logical, Integration & Data Flow, Physical (App Service, SQL, Redis, ExpressRoute to EPR), Data (cache, audit), Security (JWT, RBAC, audit)
UC-02: Patient cancels or reschedules an appointment
Attribute
Detail
Actor(s)
Enrolled patient
Trigger
Patient selects “Cancel” or “Reschedule” on an appointment
Pre-conditions
UC-01 pre-conditions; appointment is within the 24-hour-plus-before cut-off; the appointment type permits self-service (some oncology appointments are flagged “clinician-managed only”)
Main Flow
1. App calls POST /appointments/{id}/cancel with reason. 2. BFF validates JWT and business rules (cut-off, type). 3. Appointments Service writes intent (status=cancel-requested) to SQL and emits event to Service Bus (Outbox pattern). 4. FHIR Facade consumes event and issues Appointment.status=cancelled to Cerner via FHIR R4. 5. Cerner acknowledges; FHIR Facade records success. 6. Notification event emitted. Notification Service sends SMS + in-app notification: “Your appointment on DATE has been cancelled.” 7. Booking office worklist updated (Cerner handles downstream).
Post-conditions
Appointment cancelled in EPR; patient notified; immutable audit event recorded
Views Involved
Logical, Integration & Data Flow, Security (authentication, step-up MFA not required for cancel; required for repeat Rx), Scenarios, Reliability (Outbox ensures durability)
UC-03: Appointment reminder SMS – with delivery failure handling
Attribute
Detail
Actor(s)
Notification Service, Azure Communication Services, Patient
Trigger
48-hour-pre-appointment scheduler job runs
Pre-conditions
Patient has an active appointment; patient has opted in to SMS reminders; mobile number verified at enrolment
Main Flow
1. Scheduler publishes “send-reminder” event for each qualifying appointment. 2. Notification Service retrieves patient’s preferences. 3. Notification Service calls ACS SMS with message. 4. ACS returns delivery status within 60 seconds (typical). 5. If delivered: audit success. 6. If failed / undelivered: Notification Service schedules retry after 15 min (max 3 retries with exponential back-off). 7. If all retries fail OR patient has no valid mobile: fall back to email. 8. If email also fails OR patient has no valid email: add to booking office exception worklist for manual follow-up call (hazard mitigation for HAZ-02). 9. Patient app shows “reminder sent at TIME” on the appointment card for transparency.
Post-conditions
Patient reminded via one or more channels OR appointment added to manual-call worklist; audit trail complete
1. Session JWT contains patient_nhs_number (verified at enrolment via PDS). 2. Every call to FHIR Facade asserts patient_nhs_number as both HTTP header and query parameter. 3. FHIR Facade verifies patient_nhs_number exists in PDS cache (TTL 24h) and has not been merged/retired. 4. FHIR Facade calls Cerner FHIR with National Patient ID as identifier – never with Cerner internal IDs. 5. Returned resources are verified to have matching patient identifier; mismatched responses raise MHT-HAZ-04 alert, block the request, and log to Sentinel. 6. If PDS returns “merged”, Facade fetches new identifier, updates enrolment, logs clinical-safety event, and forces patient re-verification on next login.
Post-conditions
Patient receives only their own data; any mismatch is blocked and raises a clinical safety event
Views Involved
Security (identity binding), Data (identity controls), Scenarios, Governance (Hazard Log)
UC-05: Results release and view
Attribute
Detail
Actor(s)
Patient; Clinician (via EPR, out of band)
Trigger
Clinician releases a pathology or radiology result via EPR workflow (not via MyMedwick)
Pre-conditions
Clinician has reviewed result and clicked “Release to Patient Portal” in Cerner; result is at least 24 hours old (safety delay per policy)
Main Flow
1. Cerner emits ORU message with MyMedwick-release flag. 2. FHIR Facade ingests ORU, normalises to FHIR DiagnosticReport. 3. Results Service stores metadata and release flag in SQL. 4. Notification event published. 5. Notification Service sends SMS / push notification to patient. 6. Patient logs in and views result. 7. First view triggers a “patient-has-seen-result” audit event back to EPR (via outbound FHIR Facade call).
Post-conditions
Patient sees result; clinical team can see patient-viewed status in EPR; Caldicott-compliant audit trail maintained
ADR-001: Microsoft Azure over AWS as hosting platform
Field
Content
Status
Accepted
Date
2025-02-05
Context
The Trust has a sovereign UK cloud hosting requirement and operates an enterprise agreement with Microsoft. A technology choice was made between Microsoft Azure (UK South / UK West) and AWS (London / Ireland). Evaluation criteria: UK data residency assurance, alignment with MediCore Authority patterns, existing Trust skills, identity integration (Entra ID already Trust standard), regulatory attestations (ISO/IEC 27018), and cost.
Decision
Adopt Microsoft Azure with UK South (primary) and UK West (DR).
Alternatives Considered
AWS: Strong services and mature UK presence. Rejected because: (a) Trust existing Entra ID / Intune investment favoured Microsoft stack for identity; (b) Existing staff skills heavily Azure-weighted (migration from on-premises to Azure for non-clinical systems); (c) AWS UK regions do not yet have the same UK sovereignty contractual commitments as Azure’s UK regions for Trust’s specific workloads; (d) ISO/IEC 27018 certification and MediCore alignment patterns more mature on Azure. Google Cloud: insufficient UK coverage and Trust skills at decision time. On-premises: inconsistent with Trust “cloud-first-where-appropriate” policy for non-clinical-record workloads.
Consequences
Positive: unified identity stack (Entra ID, B2C, CIS2 federation pattern); mature MediCore landing zone patterns; Trust staff skills aligned; integrated Sentinel SIEM. Negative: Azure-specific skills required for deep ops; Moderate lock-in to Azure AD B2C and APIM (see 3.1.6).
Quality Attribute Tradeoffs
Operational Excellence: positive (tooling alignment). Security: positive (unified IAM). Cost: neutral (comparable to AWS). Portability: neutral-to-negative (B2C is high lock-in, mitigated by IdP facade pattern).
ADR-002: FHIR R4 over HL7v2 as the canonical clinical data contract
Field
Content
Status
Accepted
Date
2025-02-20
Context
Downstream clinical systems (Cerner, WinPath, JAC) historically integrate via HL7v2 messaging (MLLP). MediCore Authority’s Interoperability Strategy mandates FHIR R4 for new clinical APIs. The FHIR Facade pattern allows both in parallel. The decision is whether MyMedwick’s internal clinical data model should be HL7v2 (the data’s native form) or FHIR R4.
Decision
Use FHIR R4 as the canonical internal model; the FHIR Facade performs HL7v2-to-FHIR mapping at the ingestion boundary.
Alternatives Considered
HL7v2 as canonical: Lower impedance with legacy systems but rejected: (a) Inconsistent with MediCore Authority standards for new systems; (b) HL7v2 is poorly suited to JSON/REST consumption by modern web clients; (c) Would lock MyMedwick out of the ICS-wide FHIR-based data sharing roadmap. Bespoke domain model: Rejected – reinvents the wheel; FHIR R4 is a recognised MediCore standard and has mature .NET SDKs (Firely).
Consequences
Positive: standards-aligned; forward-compatible with ICS Shared Care Record; strong tooling (Firely SDK); easier external audit. Negative: HL7v2-to-FHIR mapping is non-trivial for edge cases (address types, telecom systems) and must be clinically validated; FHIR conformance testing added to CI.
Quality Attribute Tradeoffs
Operational Excellence: positive (single internal model). Performance: neutral (mapping overhead marginal). Reliability: positive (tested mapping layer isolates EPR changes). Cost: slight increase in initial development, net positive over 3-year life.
ADR-003: Azure AD B2C over MediCore login for patient authentication
Field
Content
Status
Accepted (revised 2026-03-28; supersedes v1 which had proposed MediCore login)
Date
2026-03-28
Context
Patient authentication choice. MediCore login is the national patient identity service; Azure AD B2C is Microsoft’s customer identity. National policy encourages MediCore login adoption but does not mandate it for Trust patient portals. Evaluation criteria: control over enrolment UX, MFA options, verification journey speed, ability to step-up MFA for sensitive actions, future optionality.
Decision
Use Azure AD B2C as the primary patient IdP; design the architecture to allow MediCore login to be federated in as an additional IdP in a future phase (target 2026-Q4).
Alternatives Considered
MediCore login as primary: Recognised national identity; would avoid duplicate enrolment. Rejected for v2.0 because: (a) Trust requires explicit control over the enrolment UX to reach 800,000 patients quickly (including digitally-excluded patients who fail MediCore login’s identity proofing); (b) MFA method flexibility (SMS + TOTP + FIDO2) is richer in B2C; (c) Patients who fail MediCore login verification would be blocked whereas Trust can provide an “in-person at the Trust” fallback verification through its service desk. A facade (AuthGateway) is in place so MediCore login can be federated without breaking downstream services. Bespoke Trust IdP: rejected – reinventing identity is high-risk.
Consequences
Positive: faster enrolment path for patients; Trust controls verification journey (including in-person fallback); future-proofed for MediCore login federation. Negative: risk of fragmented identity between MediCore login and Trust portal (mitigated by later federation); Trust bears responsibility for identity proofing to MediCore-equivalent standard (documented in DPIA-2025-004).
Quality Attribute Tradeoffs
Operational Excellence: neutral (extra policies to maintain). Security: positive (step-up MFA richer in B2C). Cost: negligible difference. Patient experience: positive (faster, more forgiving enrolment journey).
ADR-004: Outbox pattern for EPR-affecting write operations
Field
Content
Status
Accepted
Date
2025-03-12
Context
Patient actions (cancel appointment, prescription request) must result in a reliable write to the EPR and a reliable notification to the patient. Naive implementation (call EPR then publish event) introduces a dual-write problem – either can fail.
Decision
Write intent to SQL and to a local outbox table in the same transaction; a background dispatcher publishes events to Service Bus once committed.
Alternatives Considered
Distributed transactions (MSDTC): not supported with Azure SQL + Service Bus. Saga (compensating actions): feasible but over-engineered for these flows. Event-first (publish before write): risks publishing events without persistent state.
Consequences
Positive: at-least-once delivery guarantee; idempotent consumers handle duplicates; resilient to partial failures. Negative: outbox table requires cleanup; small latency added (typically less than 200ms).
App Service CPU/memory/instance count, SQL DTU/CPU/storage, Service Bus queue depth/active messages, APIM request count, FHIR Facade outbound latency, Redis hit ratio
Full auto-scaling (App Service autoscale rules on CPU + queue depth; SQL vCore elastic; APIM unit scaling)
Scaling details
App Service: 2-10 instances per service, scale-out in 90 seconds. SQL Business Critical: vertical scale in minutes. Front Door: unlimited edge. ACS: managed throughput.
Dependencies adequately sized
Yes – ExpressRoute 1 Gbps (25% utilised at peak); EPR interface tested at 3x projected peak.
Dependency details
MediCore Spine: national service, published SLA; EPR: tested to 5,000 concurrent sessions; GP Connect: limited per MediCore national throttles.
Component failures: All services 2+ instances, zone-redundant within UK South.
Graceful degradation: If EPR is unavailable, portal shows cached appointments (read-only) with staleness warning; writes (cancel/reschedule) are queued and shown as “pending” to the patient. If Spine is unavailable, enrolment is blocked but existing users continue to function.
Circuit breakers (Polly): EPR (5 consecutive failures -> open 30s), Spine (3 -> 60s), GP Connect (3 -> 60s).
Health checks: Liveness + readiness endpoints; App Service built-in plus custom health that checks SQL and Redis connectivity and EPR smoke call.
Testing practices: Quarterly DR drill (failover to UK West and back); monthly chaos test (Azure Chaos Studio – EPR outage simulation, Spine timeout, SMS provider outage); annual game day.
Some options more expensive chosen for non-cost reasons
[x]
SQL Business Critical Zone Redundant selected over General Purpose (approximately 2.8x cost) for zone redundancy and faster failover, justified by Tier 1 Critical rating; dedicated ASEv3 chosen over shared App Service plan for isolation; Premium Key Vault HSM chosen over standard for FIPS 140-2 Level 3.
Yes – detailed cost modelling performed using Azure Pricing Calculator; TCO compared with maintaining PKB pilot + building new in-house solution shows 35% reduction over 5 years.
Hosting location chosen to reduce environmental impact?
No – chosen for data residency. Azure UK South’s carbon intensity is moderate; Microsoft’s 2025 commitment to 100% renewable matching will improve this further.
Workload demand pattern
Variable predictable – daily peak 07:30-09:00 and 18:00-20:00; lulls overnight
Phased rollout: Trust staff (dogfooding) -> invited cohort 5,000 patients -> public beta -> general availability. PKB decommissioned after 3-month parallel run.
Data migration mode
Continuous sync – MyMedwick reads through to EPR; no bulk migration from PKB; PKB patient enrolment list used to invite PKB users to re-enrol in MyMedwick
Data migration method
Azure Data Factory one-time extract of PKB user list (National Patient IDs only) for invitation mailing
Data volume
Approximately 40,000 National Patient IDs
End-user cutover
Phased – patients invited in cohorts over 3 months
External system cutover
Phased – PKB interface disabled after final patient migrated
Max acceptable downtime
Zero (parallel run)
Rollback plan
PKB remained live throughout; any issue could route traffic back to PKB via Trust web-site banner and direct link
Acceptance criteria
≥ 95% of active PKB users re-enrolled in MyMedwick or formally opted out; CSG sign-off on post-live clinical safety case
Transient infrastructure
Yes – ADF pipeline for PKB extract (decommissioned post-migration)
Azure Automation runbook scales-in non-prod App Service plans 19:00-07:00 weekdays + weekends; Azure SQL auto-pause on non-prod databases. Azure Policy “deny on tag missing” prevents new non-prod resources without an auto-shutdown tag.
Right-sizing review cadence
Quarterly via Azure Advisor + Application Insights metrics. Last review (2026-Q1) downgraded the staging Pv3 from P1v3 to P0v3, recovering ~£140/month.
Unused / orphaned resource reclamation
Monthly review of orphaned managed disks, unattached public IPs, stale storage account containers; deleted after 30 days idle without recorded exception.
Carbon footprint reported alongside cost
Yes — Azure Emissions Impact Dashboard reviewed monthly alongside cost; reported quarterly to Trust Sustainability Committee against the MediCore Net Zero target (2040).
Azure PaaS resources are always running (App Service, SQL, APIM).
On deployment, App Service slot-swap is the activation step; health checks verify all dependencies.
After any DR failover, startup sequence: promote SQL secondary -> scale up App Service in UK West -> update Front Door origin -> verify EPR connectivity via ExpressRoute backup path -> enable external traffic. Full cold-start ~25 minutes.
.NET: within 90 days of LTS release; SQL: minor patches in monthly maintenance window; mobile OS support: last 2 major versions per Apple/Google policy
Certificate management
Azure Key Vault + Front Door managed certificates; auto-renewal; alerts at 30/14/7 days
Dependency management
Mend + Dependabot; quarterly review
MediCore Spine / e-RS / GP Connect interface updates
MediCore Digital issues are tracked via the Digital Assurance Manager; change windows coordinated
Domain services are standard .NET 8 containers; SQL is standard SQL Server; FHIR facade and contract are portable; audit is object storage; identity (B2C) is highest lock-in
Data portability
SQL bacpac; ADLS standard object storage export; FHIR data re-exposable through another facade
Vendor lock-in
Overall Moderate. Primary lock-in: Azure AD B2C (High) and APIM policies (Moderate). Exit effort: approximately 4-6 months for a similar-sized team.
Yes – introduces a new patient-facing external surface and new data processing. Evaluated with Risk Committee; risk appetite confirmed. DPIA DPIA-2025-004 and Clinical Safety Case v3 signed.
This SAD was assessed at Comprehensive depth. The scores below reflect a mature, well-documented architecture for a Tier 1 Critical clinical system under MediCore clinical safety and information governance standards.
Section
Score
Justification
0. Document Control
5
Full version history, multiple clinical and IG contributors/approvers, clear scope, related documents referenced
1. Executive Summary
5
Business drivers with priority; strategic alignment; reuse assessment; current-state documented; Tier 1 Critical criticality justified by patient-harm analysis
2. Stakeholders & Concerns
5
Comprehensive register including Caldicott Guardian, CSO, CCIO and external regulators; concerns matrix fully mapped; twelve applicable regulations
3.1 Logical View
5
Full component decomposition; design patterns with rationale; lock-in assessment for all components; service-to-capability mapping
3.2 Integration & Data Flow
5
All internal and external integrations documented with protocol/auth; ten API contracts versioned; end user access patterns; national healthcare secure network and MediCore national services modelled
3.3 Physical View
5
Deployment diagram; compute fully specified (ASEv3); full networking including ExpressRoute, national healthcare secure network, Private Endpoints; six environments; security agents
3.4 Data View
5
All data stores classified with retention and encryption; Always Encrypted for PII; UK data sovereignty; two DPIAs; data integrity and patient identity controls
3.5 Security View
5
STRIDE threat model with eleven threats including two explicit clinical safety threats; comprehensive IAM (patient, clinician, service); HSM-backed CMK; Sentinel with clinical-safety analytics
3.6 Scenarios
5
Five architecturally significant use cases including a clinical-safety control scenario (UC-04); four ADRs with alternatives and tradeoffs
4.1 Operational Excellence
5
Centralised logging with Sentinel; Azure Monitor/App Insights; PagerDuty with clinical safety escalation; dedicated clinical-safety workbook
4.2 Reliability
5
Zone-redundant primary with warm-standby DR; RTO 1h / RPO 15min validated through quarterly drill; chaos testing; Outbox for durability
Non-prod auto-shutdown; efficient SKUs; Brotli compression; rightsizing. Score reduced from 5: no carbon metrics baselined; formal sustainability KPIs still in development
5. Lifecycle
5
CI/CD with SAST/DAST/SCA and FHIR conformance; phased migration (PKB replacement); clinical safety regression; fortnightly release with CSO sign-off; exit plan
6. Governance
5
Six constraints; five assumptions with evidence; twelve risks with mitigations (incl. clinical safety); nine dependencies; three issues; fifteen-item compliance traceability
7. Appendices
5
Domain glossary (healthcare-specific); fourteen reference documents; ten standards; full approval sign-off with CSO and Caldicott Guardian
Overall
4.9
Comprehensive depth achieved. Exemplary documentation for a Tier 1 Critical MediCore Trust clinical system.
