P
Preliminary Phase
Establishing the architecture capability, its principles and its governance
Scope. commvita is a global health platform factory, not a customised health IT product. 615 modules (571 live at build B-525) span primary care, community, mental health, social care, acute and governance across 16 configured jurisdictions, on one record and one codebase. Every architectural decision is evaluated against the factory distinction: variance is modelled and versioned, never forked into local code.
The Six Doctrines
| # | Doctrine | What it forbids |
|---|---|---|
| 1 | Everything variable must be modelled | Hard-coded country logic, SQL-embedded KPIs, payment rules in application code |
| 2 | Everything changeable must be versioned | Unversioned configs, undocumented rule changes, manual database edits |
| 3 | Everything releasable must be testable automatically | Untestable workflows, hand-waived compliance evidence, "it worked in staging" sign-offs |
| 4 | Everything safety- or compliance-relevant must be traceable | Unlinked hazard mitigations, unrecorded clinical rule changes, anonymous overrides |
| 5 | Humans review exceptions, not run the machine | Manual deployments, manual evidence packs, hand-crafted release notes |
| 6 | Local flexibility must never become local code | Tenant-specific branches, schema overrides, one-off patches to tenant production |
Architecture principles in force
- Person first — no orphaned representations; every record resolves to a person
- Open by default — openEHR archetypes, FHIR R4, SNOMED CT, OMOP; open exit
- Configuration over code — jurisdiction variance is data, not a branch
- Fail safe — a missing or expired value never defaults to another jurisdiction
- Evidence by construction — assurance artefacts generated, not assembled
- Removable partners — every partner integration behind one flagged seam
Governance bodies and instruments
- Clinical Safety Officer — DCB0129 / DCB0160 hazard and safety case sign-off
- Caldicott Guardian — non-direct-care access decisions, written to the WORM audit
- Change Advisory Board — Ring 3 (regulated) promotion approval
- Jurisdiction accountable signatory — per-domain sign-off in the Jurisdiction Profile
- Architecture Decision Records — append-only, versioned in the repository
- Assurance Dashboard — ring readiness surfaced as a product capability
Anti-patterns explicitly banned: country-specific code branches; tenant-specific schema changes; hard-coded KPI logic in SQL; compliance logic buried in application code; local UI labels in source; manual production deployment; manual evidence packs; shared super-admin accounts without separation of duties; urgent one-off fixes applied directly to tenant production.
R
Requirements Management
The continuous process at the centre of the ADM cycle — every phase reads from and writes to it
Requirements Management is not a phase; it is the hub every phase touches. In commvita the requirements repository is the set of governing PRDs and binding standards held in the repository alongside the code, so a requirement, its implementation and its test are versioned together.
| Instrument | Governs | Binding on |
|---|---|---|
| Person-First Data Lineage & Drill-Through Standard | Dropdown binding, tile drill-through, person identity banners, reconciliation of counts | All new and modified UI |
| Jurisdiction Profile PRD | Identifier validation, terminology binding, workflow gating, residency, legal provisions | All jurisdiction-variant behaviour |
| Incident-to-Risk Golden Thread PRD | Event → Theme → Systemic Issue → Risk → Board objective, with evidence carried | Incident, risk, board and quality modules |
| Clickable-Tile-by-Default standing order | Every count tile drills to exactly the set it counts | All new and modified UI |
| Partner-Integration Removability standing order | One enablement switch, isolated block, normalised adapter, documented excision cost | All partner-specific functionality |
| Simplify-UX programme flag | A single reversible seam; flag off restores prior behaviour exactly | End-user navigation and home surfaces |
Traceability chain
- Requirement recorded in a governing PRD or standard
- Acceptance criterion expressed as an automated test
- Implementation referenced to the criterion in the commit
- Hazard linked where clinically relevant (DCB0129)
- Audit register entry updated in the same commit
- Evidence pack assembled automatically at release
Living audit registers
- Standard audit register — person-first conformance, Phase 2
- Jurisdiction audit register — retrospective hardcoding removal
- Tile-clickability audit register — drill-through retrofit
- FDP CDM alignment register — canonical model gaps
- Hazard log — DCB0129 hazards and mitigations
- Architecture decision records — this document, section ADR
A
Architecture Vision
The high-level aspirational view of the target enterprise architecture
Vision. One open longitudinal record carrying clinical, operational and governance data for a whole population, self-hosted by the organisation that owns the data, on openEHR, FHIR R4 and SNOMED CT. Every surface — from a nurse on a home visit to a board assurance framework — reads and writes that same record in real time, so the integration burden that normally falls on people is removed rather than automated.
Strategic drivers
- NHS 10 Year Plan — the digital, community and prevention shifts
- Mandated consolidation and post-EPR optimisation
- National data platform first-term decision point
- Commissioner reorganisation — 42 ICBs to 36 from 1 April 2026, with a stated intent to align boundaries with the new strategic authorities
- Gulf health transformation programmes at national scale
- EHDS and WHO digital health guidance for cross-border care
Outcomes, in Quadruple Aim terms
- Outcomes — intervention chosen on the whole record, not a fragment
- Access and equality — need visible by cohort and deprivation
- Value for money — ambition of 80% off total cost of ownership
- Workforce — one record, one login, one worklist
- Real-time decision support rather than retrospective reporting
- Assurance generated from live operations, not re-keyed
Architecture goals
- openEHR as the canonical clinical record, not a bolt-on
- FHIR R4 UK Core conformant API surface
- OMOP CDM v5.4 for secondary use, with a real populated ETL
- NHS FDP Canonical Data Model (DAPB4121) interoperability
- Jurisdiction variance modelled in a signed, versioned profile
- Open exit — portability as a designed property
Commercial architecture — three editions on one platform
| Edition | Basis of charge | Architectural scope |
|---|---|---|
| Commvita Flow Edition | £1 per instance, perpetual | Self-hosted platform base on open standards, with FDP-parity operational products |
| Governance & Assurance | Per employee, banded by size | Board, risk, incident, IG and AI governance. Holds no patient records, so no clinical certification gate and no integration programme |
| Population Platform | Per head of covered population | The full clinical platform, governance included for the same scope, no double charge |
Why the editions matter architecturally: Governance & Assurance is deliberately separable — it consumes the same spine but stores no patient identifiable data, which is what allows it to be deployed inside one financial year while the clinical platform follows on its own assurance timetable.
B
Business Architecture
Organisation model, capabilities, value streams and information flows
A simple hierarchy fails. Health systems are not uniformly tree-shaped: the United States runs payers in parallel rather than stacked, Crown Dependencies subsidise private primary care they do not own, and Kenya devolves to counties. The organisation model is therefore four typed layers plus an independent referral pathway, not a single parent-child chain.
Four-layer organisation model
| Layer | Role | Worked examples |
|---|---|---|
| STEWARDSHIP | Sets policy, legally accountable, stewards resource | England: DHSC → NHS regions · US: HHS / CMS with states · Oman: Ministry of Health |
| COMMISSIONER | Plans, funds and contracts for services | England: 36 ICBs from 1 April 2026, boundaries expected to align with strategic authorities · US: Medicare, Medicaid and commercial in parallel · Kenya: 47 county health departments |
| PROVIDER | Delivers secondary and tertiary care | England: trusts and foundation trusts · US: hospitals, IDNs, ACOs · Caribbean: national medical centres and hospital boards |
| PRIMARY_CARE | The front door for patients | England: GP practices in PCNs · US: PCPs and FQHCs · Crown Dependencies: subsidised private practices · Kenya: community health services |
The layers are stable; the occupants are not. England has replaced its commissioning tier twice in a decade — 211 clinical commissioning groups in 2013, 106 by 2021, 42 integrated care boards in 2022, 36 from April 2026 — with a stated intent to align boundaries with the new strategic authorities, and its national arm’s-length body is being wound into the department. Every one of those is a change of instances at the COMMISSIONER layer. None is a change to the layer model. That is the architectural claim this phase makes: the typed four-layer model, plus organisational structure held as effective-dated configuration rather than as schema, is what allows a reorganisation to be a data migration of hours rather than a programme of years. An enterprise architecture that has to be redrawn every time a commissioner merges is not an architecture.
Business capabilities — the five layers of the map
- People-facing — portal, referral and access, pre-hospital, front door
- Care delivery — clinical core, community, mental health and social care, allied health, condition programmes
- The spine — person and record, interoperability and EPR
- Running the organisation — flow, governance, board, workforce, analytics, finance
- Shared services — platform and AI, communications, jurisdiction and config
Value streams
- Access → triage → care → outcome (person journey)
- Referral → diagnostics → decision to treat → theatre → recovery
- Arrival → assessment → admission → discharge to assess → community
- Event → theme → systemic issue → risk → board objective
- Cohort → phenotype → recall or social prescription → measured outcome
- Policy → process → authority matrix → audited decision
C
Information Systems Architecture
Application portfolio, data architecture and clinical terminology binding
Portfolio. 615 modules in the registry, 571 live at build B-525; the remainder await external credentials rather than development. One React front end and one FastAPI service over a single PostgreSQL logical model — deliberately not a suite of acquisitions, which is why every module can read the same record without an exchange step.
Data architecture — four representations of one record
| Representation | Purpose | Standard |
|---|---|---|
| Canonical clinical record | The record of care as authored | openEHR archetypes and templates |
| Interoperability projection | Exchange with EPRs and national services | FHIR R4 UK Core, HL7 v2 where required |
| Analytical projection | Secondary use, research, federated cohorts | OMOP CDM v5.4, materialised by a real ETL with a data-quality report |
| National platform projection | Operational analytics parity | NHS FDP Canonical Data Model, DAPB4121, schema-validated on emit |
Terminology and coding
- SNOMED CT UK Edition, weekly dm+d, OPCS-4, ICD-10 via NHS TRUD
- FHIR R4 terminology server proxy, local or live mode
- LOINC for measurement, RxNorm for cross-border medication
- Read v2 and CTV3 crosswalk with an unmapped-code queue
- Versioned SNOMED refsets, bound only against a TRUD release
- Jurisdiction terminology binding read from the profile
Identity and access
- EMPI with multi-identifier search and probabilistic matching
- Per-jurisdiction identifier schemes; unknown schemes fail safe
- Role hierarchy of seven roles, org-scoped by ODS code
- Groups grant scope only, never a role (ADR-015)
- Article 9 step-up re-authentication for special category data
- Tamper-evident hash-chained login and access audit
D
Technology Architecture
Platform, deployment topology, control and data plane separation, non-functional requirements
Technology choices, current and target
| Layer | Current | Target, 12 to 18 months |
|---|---|---|
| Frontend | React 18, Vite, TypeScript, Fluent UI v9 | Same, plus PWA for offline and mobile |
| Backend | FastAPI, SQLAlchemy 2.0 | FastAPI modularised by domain |
| Database | PostgreSQL 15 | PostgreSQL per cell with read replicas |
| Events | Synchronous only | Kafka or Redpanda event backbone |
| Search | PostgreSQL full text | OpenSearch |
| Policy engine | In-application | Open Policy Agent sidecar |
| Secrets | Environment injection | Vault or Key Vault with rotation |
| Observability | Application logging | OpenTelemetry to Grafana and Jaeger |
| Infrastructure as code | Helm and Ansible | Terraform, Helm, ArgoCD |
| CI/CD | GitHub Actions to GHCR, Helm, Flux | Same, plus ring promotion bots |
Control plane — central, single instance
- Platform administration and tenancy provisioning
- Release orchestration: ring promotion and rollback
- Policy enforcement and pack registry, signed artefacts
- Feature flags per jurisdiction, tenant and role
- Observability aggregation across all cells
- Security control management, secret and certificate rotation
Data plane — per cell
- Runtime API services and local integration adapters
- Local data store honouring jurisdiction residency
- Local configuration cache and search index
- Local dashboards
- Cells bound blast radius, not just capacity
- No cross-cell patient data movement by default
Cell topology. Cells are drawn on residency and regulatory boundaries: NHS nations in one production cell, Crown Dependencies in another, CMS and ACO customers in a third, Gulf ministries in sovereign in-country cells. Data residency is a deployment property, not an application concern.
Non-functional requirements
| Requirement | Target | Verified by |
|---|---|---|
| API latency | p95 ≤ 200ms, or within 10% of baseline | k6 performance gate on every promotion |
| Error rate | ≤ 0.1% with no new alert categories | Observability baseline in the promotion gate |
| Availability | Per-cell, service-level dependent | Synthetic probes and integration assurance |
| Offline operation | Community and mobile surfaces fully usable | IndexedDB queue and sync manager |
| Security findings | No critical or high at promotion | SAST, DAST and dependency scanning |
| Residency | No schema migration that moves data across a cell | Migration dry-run in the gate |
E
Opportunities & Solutions
Work packages, solution building blocks and implementation priorities
Epic status against the target architecture
| Epic | Scope | Status |
|---|---|---|
| US revenue capture | CCM, BHI, TCM, PCM, AWV, RPM, RTM, HCC and RAF, STAR | Complete |
| Platform architecture | Packs, rings, control plane, assurance dashboard | Complete |
| Clinical depth | Condition programmes, AHP, maternity, sexual health, genomics | Substantially complete |
| Privacy enhancing technology | Anonymisation tiers, token vault, differential privacy | Built |
| Clinical studies platform | Cohorts, OMOP ETL, extract ledger, evidence pack | Built |
| International expansion | Beyond the configured jurisdictions | In progress |
| Infrastructure programme | Events, cache, OPA, Vault, OpenTelemetry, per-cell databases | Not started |
| HIMSS maturity intelligence | CCMM, AMAM and O-EMRAM computed from live signals | Partially built |
Solution building blocks — reusable across modules
- Person and record spine (EMPI, whole person record)
- Jurisdiction Profile resolver with nearest-wins inheritance
- Golden thread promotion engine with evidence carriage
- commvita Sign — signature ceremony and WORM audit chain
- Communications CRM — one logging helper for every channel
- AI provider seam — single active provider, server-side keys
- Partner adapter contract — normalised, partner-agnostic
- Notification writer — one helper for in-app alerts
Principal gaps to close
- Event backbone — currently synchronous only
- Policy engine externalisation to OPA
- Per-cell database separation for residency at scale
- Distributed tracing and unified observability
- Secret management with automated rotation
- Terraform and ArgoCD to complete the IaC chain
- Clinical outcome evidence at scale — needs live deployments
F
Migration Planning
Transition states, sequencing and the release ring model
Environment chain
Core Dev → Core Test → Core Prod Candidate
↳ Jurisdiction Test → Tenant Test → Tenant Prod
↳ Jurisdiction Test → Tenant Test → Tenant Prod
Release rings
| Ring | Population | Promotion gate |
|---|---|---|
| 0 — Internal | commvita engineering only | Merge to a feature branch passes CI |
| 1 — Canary | One or two opted-in pilot tenants per jurisdiction | 24 hour soak against an observability baseline |
| 2 — Standard | All non-regulated jurisdictions | 72 hour soak with no P1 alerts |
| 3 — Regulated | NHS, CMS and MHRA-registered deployments | Extended soak, clinical safety sign-off, change advisory board approval |
Ring 3 is the only gate a human holds. Promotion is automated unless a change is flagged safety-relevant, in which case the clinical safety officer signs before it can reach a regulated deployment. This is doctrine 5 in practice: humans review exceptions, they do not run the machine.
Transition sequence for a new jurisdiction
- Jurisdiction Profile authored, sourced and effective-dated
- Mandatory domains signed off by a named local signatory
- Identifier scheme and terminology binding validated
- Pack composed, conflicts and gaps detected and cleared
- Ring 1 canary with a single pilot tenant
- Ring 2 or Ring 3 depending on regulatory status
Rollback and safety
- Emergency rollback is a control plane action, not a redeploy
- Feature flags kill a capability without a release
- Kill switches scoped global, jurisdiction or tenant
- Pack versions are semver and signed; provenance verified on load
- Schema migrations are dry-run against residency rules first
- No forward-only migration without a tested down path
G
Implementation Governance
Assurance, clinical safety and the gates that hold the architecture to the specification
Absent from the previous edition. Phase G is where the doctrines become enforceable. Assurance runs as six automated domains, and the promotion gate is the architecture contract in executable form — a change that cannot satisfy it cannot reach a regulated deployment.
Six assurance domains
| Domain | Covers |
|---|---|
| A. Functional | Unit, integration, consumer-driven API contract, workflow regression, UI journey, per-pack regression |
| B. Non-functional | Performance and load, resilience and failover, soak, capacity envelope |
| C. Security | SAST, DAST, dependency and container scanning, secret detection, RBAC assertion tests |
| D. Clinical safety | DCB0129 hazard traceability, DCB0160 deployment safety, clinical simulation scenarios |
| E. Information governance | Residency assertions, opt-out enforcement, audit chain verification, Article 9 step-up |
| F. Conformance | FHIR profile validation, openEHR template validation, OMOP data quality, FDP CDM schema conformance |
Promotion gate — every item automated
- Unit, integration and API contract tests pass
- UI journey tests pass
- FHIR profile validation passes
- p95 API latency within budget
- No critical or high security findings
- Data residency respected in migration dry-run
- Jurisdiction pack compatibility confirmed
- Observability baseline held
- Pack provenance signature valid
Clinical safety governance
- Hazard log with DCB0129 hazard identifiers and mitigations
- Safety case report assembled from live hazard state
- DCB0160 deployment workflow per receiving organisation
- Clinical safety officer sign-off routed through commvita Sign
- AI governance: ATRS model cards, NICE ESF tier, MHRA AIaMD status
- GDPR Article 22 override log for any automated decision support
Non-SaMD posture. Decision support surfaces recorded data and computed indicators for a human to act on. Where a capability would cross into a medical device function, it is either scoped out or carries an explicit MHRA AIaMD assessment. This boundary is asserted per module and reviewed at Ring 3.
H
Architecture Change Management
How the architecture absorbs change without forking, and when a change triggers a new ADM cycle
Absent from the previous edition. Phase H answers the question the factory model depends on: when a jurisdiction, tenant or regulator wants something different, what changes? The answer must never be a branch.
Change classification
| Class | Example | Route | Triggers a new ADM cycle? |
|---|---|---|---|
| Configuration | A threshold, a label, a service catalogue entry | Tenant layer, no release | No |
| Jurisdiction variance | An identifier scheme, a legal provision, a regulator | Jurisdiction Profile entry, sourced and signed off | No |
| Pack change | A new pathway, a terminology subset, a return format | Versioned pack, semver, signed, ring promoted | No |
| Capability extension | A new module inside an existing theme | Registry entry, nav wiring, audit register update, same commit | No |
| Structural change | A new representation of the record, a new plane | Architecture decision record, then phases B to D | Yes |
| Regulatory shift | A new device classification, a new national data regime | Vision reassessed, safety case reopened | Yes |
Pack lifecycle
- Authored against the pack schema with required provenance fields
- Validated: schema, terminology binding, conflict and gap detection
- Signed and published to the registry with a semver version
- Ring promoted like code, with per-pack regression tests
- Superseded rather than edited — versions are immutable
- Deprecation carries an effective date and a migration path
Repository and versioning discipline
- Configuration as code, held beside the implementation
- Policy as code, evaluated rather than interpreted
- Append-only audit chains, verified on read, no update or delete path
- Architecture decision records are additive, never rewritten
- Module registry and this document updated in the same commit as the change
- Build label is the single source of version truth
ADR
Architecture Decision Records
Decisions taken, the rationale, and what was rejected
| ID | Decision | Rationale | Rejected alternative |
|---|---|---|---|
| ADR-001 | openEHR as the canonical clinical record | Vendor-neutral archetypes make the record portable by construction, which is what makes an open exit credible rather than rhetorical | FHIR resources as the system of record — adequate for exchange, weak as a longitudinal store |
| ADR-002 | One codebase, jurisdiction variance as data | A branch per country multiplies assurance cost by the number of countries and guarantees drift | Per-jurisdiction forks with shared libraries |
| ADR-003 | Single FastAPI service over one logical model | At current scale the coupling cost of microservices exceeds the benefit; module boundaries are enforced by convention and test, not by network | Microservice-per-domain from the outset |
| ADR-004 | Control plane and data plane separated | Residency and blast radius are deployment properties; keeping orchestration central lets cells stay sovereign without duplicating governance | Fully independent per-country deployments with no central plane |
| ADR-005 | Append-only hash-chained audit for governance records | Tamper evidence must be verifiable by the reader, not asserted by the vendor; chains are re-verified on every read | Conventional audit tables with administrative delete |
| ADR-006 | OMOP as a materialised ETL, not a view | Research use needs a stable, quality-reported extract with a provenance ledger, not a live query surface | On-demand OMOP projection over the operational store |
| ADR-015 | User groups grant scope only, never a role | Coupling group membership to privilege creates silent elevation paths; role stays explicit and audited | Groups carrying role assignments, as most RBAC products do |
| ADR-016 | Partner integrations behind a single flagged seam | A partnership ending must be a configuration change and a deletion, not a refactor | Partner logic woven into the modules that consume it |
| ADR-017 | One AI provider seam with server-side keys only | Browser-held keys cannot be governed; a single active provider makes the audit answerable | Per-feature provider configuration with client-side credentials |
RISK
Architecture Risk Register
Identified architecture risks, exposure and mitigation
| ID | Risk | Impact | Likelihood | Mitigation |
|---|---|---|---|---|
| AR-01 | Single-service backend becomes a scaling and change bottleneck | High | Medium | Domain modularisation on the roadmap; module boundaries already enforced by test |
| AR-02 | No event backbone — cross-module reaction is synchronous | Medium | High | Kafka or Redpanda in the infrastructure epic; notification writer already abstracts delivery |
| AR-03 | Clinical outcome evidence is not yet available at scale | High | High | Explicitly not claimed. Ring 1 canary deployments are the route; assurance dashboard tracks readiness |
| AR-04 | Jurisdiction profile incompleteness blocks deployability | Medium | Medium | Fail-safe by design — unsigned mandatory domains block go-live rather than defaulting |
| AR-05 | Secret management is environment-injected, not vaulted | High | Medium | Vault or Key Vault with rotation in the infrastructure epic; keys never reach the browser today |
| AR-06 | Observability gaps slow incident diagnosis across cells | Medium | Medium | OpenTelemetry to Grafana and Jaeger; control plane already aggregates |
| AR-07 | Regulatory reclassification of a decision-support capability | High | Low | Non-SaMD boundary asserted per module and reviewed at Ring 3; AIaMD assessment where borderline |
| AR-08 | Partner dependency becomes structural despite the seam | Low | Low | Removability is a standing order with a documented excision cost per partner |
| AR-09 | Documentation drift between the registry, this document and the code | Medium | High | Same-commit rule for registry and audit registers; this document is generated, not hand-maintained |
STD
Standards & Compliance Catalogue
Standards, regulations and frameworks the architecture is held to
Interoperability and terminology
- openEHR — archetypes and templates
- HL7 FHIR R4, UK Core profiles
- HL7 v2.x ADT and ORU
- SNOMED CT UK Edition, dm+d, OPCS-4, ICD-10
- LOINC, RxNorm
- OMOP CDM v5.4, OHDSI conventions
- NHS FDP Canonical Data Model, DAPB4121
- IHE PIX, PDQ, XDS, MHD, ATNA, BPPC
- NHS e-RS, GP Connect, NRL v3, MESH, BaRS
- TEFCA v1.1, US Core v6, SMART Backend Services
Clinical safety, quality and AI
- DCB0129 — manufacturer clinical risk management
- DCB0160 — deploying organisation clinical risk
- DTAC 2021
- MHRA AIaMD guidance, June 2025
- NICE Evidence Standards Framework, tiers A to C
- ATRS — algorithmic transparency records
- NHS AI Ethics Framework
- PSIRF, CQC Single Assessment Framework
- NQB safe staffing, NICE NG94
- HIMSS CCMM, AMAM, O-EMRAM
Information governance and security
- UK GDPR, Articles 5, 6, 9, 15, 22, 26, 30, 32, 89
- Caldicott Principles, all eight
- National Data Opt-Out
- DSPT 2024/25
- Cyber Essentials Plus, ISO 27001 Annex A
- NCSC Cloud Security Principles
- ISO/IEC/IEEE 42010:2011 — architecture description
- Data (Use and Access) Act 2025
- EHDS, Regulation (EU) 2024/2987
- HIPAA, ONC HTI-1, CMS-9115-F and CMS-0057-F
Jurisdiction-specific instruments — electronic signature law, background-check schemes, professional registers, care regulators and billing regimes — are not listed here. They are resolved at runtime from the Jurisdiction Profile, which is the point: a standard that varies by country is data, not documentation.
VIEW
Architecture Views
The layered view, the ADM cycle and the deployment topology
Layered architecture — five layers binding to one spine
Application & Data View
TOGAF ADM cycle as operated
Process View
Preliminary — capability, principles, governance
↳ A Vision → B Business → C Information Systems → D Technology
↳ E Opportunities → F Migration → G Governance → H Change
↳ Requirements Management sits at the centre, touched by every phase
A structural change or a regulatory shift re-enters at Phase B.
Everything else is absorbed as configuration, profile or pack.
↳ A Vision → B Business → C Information Systems → D Technology
↳ E Opportunities → F Migration → G Governance → H Change
↳ Requirements Management sits at the centre, touched by every phase
A structural change or a regulatory shift re-enters at Phase B.
Everything else is absorbed as configuration, profile or pack.
Deployment topology — control plane and cells
Technology View
CONTROL PLANE (single instance)
release orchestration · pack registry · flags · policy · observability
DATA PLANE (per cell, residency-bound)
nhs-prod NHS England, Scotland, Wales, Northern Ireland
cd-prod Crown Dependencies
us-cms-prod CMS and ACO customers
gulf-sov in-country sovereign, ministry deployments
No cross-cell patient data movement by default.
release orchestration · pack registry · flags · policy · observability
DATA PLANE (per cell, residency-bound)
nhs-prod NHS England, Scotland, Wales, Northern Ireland
cd-prod Crown Dependencies
us-cms-prod CMS and ACO customers
gulf-sov in-country sovereign, ministry deployments
No cross-cell patient data movement by default.