commvita / Architecture / TOGAF ADM Documentation
TOGAF® v10.2 openEHR · FHIR R4 ISO 42010
P
Preliminary Phase
Establishing the architecture capability, its principles and its governance
Architecture PrinciplesGovernance FrameworkArchitecture Repository
ⓘ
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.
#DoctrineWhat it forbids
1Everything variable must be modelledHard-coded country logic, SQL-embedded KPIs, payment rules in application code
2Everything changeable must be versionedUnversioned configs, undocumented rule changes, manual database edits
3Everything releasable must be testable automaticallyUntestable workflows, hand-waived compliance evidence, "it worked in staging" sign-offs
4Everything safety- or compliance-relevant must be traceableUnlinked hazard mitigations, unrecorded clinical rule changes, anonymous overrides
5Humans review exceptions, not run the machineManual deployments, manual evidence packs, hand-crafted release notes
6Local flexibility must never become local codeTenant-specific branches, schema overrides, one-off patches to tenant production
  • 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
  • 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 RepositoryTraceability MatrixStandards Register
↻
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.
InstrumentGovernsBinding on
Person-First Data Lineage & Drill-Through StandardDropdown binding, tile drill-through, person identity banners, reconciliation of countsAll new and modified UI
Jurisdiction Profile PRDIdentifier validation, terminology binding, workflow gating, residency, legal provisionsAll jurisdiction-variant behaviour
Incident-to-Risk Golden Thread PRDEvent → Theme → Systemic Issue → Risk → Board objective, with evidence carriedIncident, risk, board and quality modules
Clickable-Tile-by-Default standing orderEvery count tile drills to exactly the set it countsAll new and modified UI
Partner-Integration Removability standing orderOne enablement switch, isolated block, normalised adapter, documented excision costAll partner-specific functionality
Simplify-UX programme flagA single reversible seam; flag off restores prior behaviour exactlyEnd-user navigation and home surfaces
  • 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
  • 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
Statement of Architecture WorkValue ChainArchitecture Vision
🎯
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.
  • 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 — 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
  • 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
EditionBasis of chargeArchitectural scope
Commvita Flow Edition£1 per instance, perpetualSelf-hosted platform base on open standards, with FDP-parity operational products
Governance & AssurancePer employee, banded by sizeBoard, risk, incident, IG and AI governance. Holds no patient records, so no clinical certification gate and no integration programme
Population PlatformPer head of covered populationThe 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
Business Capability ModelOrganisation ModelValue Streams
⚠
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.
LayerRoleWorked examples
STEWARDSHIPSets policy, legally accountable, stewards resourceEngland: DHSC → NHS regions · US: HHS / CMS with states · Oman: Ministry of Health
COMMISSIONERPlans, funds and contracts for servicesEngland: 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
PROVIDERDelivers secondary and tertiary careEngland: trusts and foundation trusts · US: hospitals, IDNs, ACOs · Caribbean: national medical centres and hospital boards
PRIMARY_CAREThe front door for patientsEngland: 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.
  • 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
  • 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
Application PortfolioData ArchitectureTerminology Bindings
📊
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.
RepresentationPurposeStandard
Canonical clinical recordThe record of care as authoredopenEHR archetypes and templates
Interoperability projectionExchange with EPRs and national servicesFHIR R4 UK Core, HL7 v2 where required
Analytical projectionSecondary use, research, federated cohortsOMOP CDM v5.4, materialised by a real ETL with a data-quality report
National platform projectionOperational analytics parityNHS FDP Canonical Data Model, DAPB4121, schema-validated on emit
  • 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
  • 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 StandardsDeployment TopologyNon-Functional Requirements
LayerCurrentTarget, 12 to 18 months
FrontendReact 18, Vite, TypeScript, Fluent UI v9Same, plus PWA for offline and mobile
BackendFastAPI, SQLAlchemy 2.0FastAPI modularised by domain
DatabasePostgreSQL 15PostgreSQL per cell with read replicas
EventsSynchronous onlyKafka or Redpanda event backbone
SearchPostgreSQL full textOpenSearch
Policy engineIn-applicationOpen Policy Agent sidecar
SecretsEnvironment injectionVault or Key Vault with rotation
ObservabilityApplication loggingOpenTelemetry to Grafana and Jaeger
Infrastructure as codeHelm and AnsibleTerraform, Helm, ArgoCD
CI/CDGitHub Actions to GHCR, Helm, FluxSame, plus ring promotion bots
  • 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
  • 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.
RequirementTargetVerified by
API latencyp95 ≤ 200ms, or within 10% of baselinek6 performance gate on every promotion
Error rate≤ 0.1% with no new alert categoriesObservability baseline in the promotion gate
AvailabilityPer-cell, service-level dependentSynthetic probes and integration assurance
Offline operationCommunity and mobile surfaces fully usableIndexedDB queue and sync manager
Security findingsNo critical or high at promotionSAST, DAST and dependency scanning
ResidencyNo schema migration that moves data across a cellMigration dry-run in the gate
E
Opportunities & Solutions
Work packages, solution building blocks and implementation priorities
Solution Building BlocksWork PackagesGap Analysis
EpicScopeStatus
US revenue captureCCM, BHI, TCM, PCM, AWV, RPM, RTM, HCC and RAF, STARComplete
Platform architecturePacks, rings, control plane, assurance dashboardComplete
Clinical depthCondition programmes, AHP, maternity, sexual health, genomicsSubstantially complete
Privacy enhancing technologyAnonymisation tiers, token vault, differential privacyBuilt
Clinical studies platformCohorts, OMOP ETL, extract ledger, evidence packBuilt
International expansionBeyond the configured jurisdictionsIn progress
Infrastructure programmeEvents, cache, OPA, Vault, OpenTelemetry, per-cell databasesNot started
HIMSS maturity intelligenceCCMM, AMAM and O-EMRAM computed from live signalsPartially built
  • 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
  • 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
Implementation RoadmapTransition ArchitectureMigration Plan
Core Dev → Core Test → Core Prod Candidate
    ↳ Jurisdiction Test → Tenant Test → Tenant Prod
RingPopulationPromotion gate
0 — Internalcommvita engineering onlyMerge to a feature branch passes CI
1 — CanaryOne or two opted-in pilot tenants per jurisdiction24 hour soak against an observability baseline
2 — StandardAll non-regulated jurisdictions72 hour soak with no P1 alerts
3 — RegulatedNHS, CMS and MHRA-registered deploymentsExtended 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.
  • 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
  • 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
Architecture ContractCompliance AssessmentAssurance Framework
✅
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.
DomainCovers
A. FunctionalUnit, integration, consumer-driven API contract, workflow regression, UI journey, per-pack regression
B. Non-functionalPerformance and load, resilience and failover, soak, capacity envelope
C. SecuritySAST, DAST, dependency and container scanning, secret detection, RBAC assertion tests
D. Clinical safetyDCB0129 hazard traceability, DCB0160 deployment safety, clinical simulation scenarios
E. Information governanceResidency assertions, opt-out enforcement, audit chain verification, Article 9 step-up
F. ConformanceFHIR profile validation, openEHR template validation, OMOP data quality, FDP CDM schema conformance
  • 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
  • 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
Change Request LogPack LifecycleArchitecture Repository
🔄
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.
ClassExampleRouteTriggers a new ADM cycle?
ConfigurationA threshold, a label, a service catalogue entryTenant layer, no releaseNo
Jurisdiction varianceAn identifier scheme, a legal provision, a regulatorJurisdiction Profile entry, sourced and signed offNo
Pack changeA new pathway, a terminology subset, a return formatVersioned pack, semver, signed, ring promotedNo
Capability extensionA new module inside an existing themeRegistry entry, nav wiring, audit register update, same commitNo
Structural changeA new representation of the record, a new planeArchitecture decision record, then phases B to DYes
Regulatory shiftA new device classification, a new national data regimeVision reassessed, safety case reopenedYes
  • 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
  • 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
Decision LogRationaleAlternatives Considered
IDDecisionRationaleRejected alternative
ADR-001openEHR as the canonical clinical recordVendor-neutral archetypes make the record portable by construction, which is what makes an open exit credible rather than rhetoricalFHIR resources as the system of record — adequate for exchange, weak as a longitudinal store
ADR-002One codebase, jurisdiction variance as dataA branch per country multiplies assurance cost by the number of countries and guarantees driftPer-jurisdiction forks with shared libraries
ADR-003Single FastAPI service over one logical modelAt current scale the coupling cost of microservices exceeds the benefit; module boundaries are enforced by convention and test, not by networkMicroservice-per-domain from the outset
ADR-004Control plane and data plane separatedResidency and blast radius are deployment properties; keeping orchestration central lets cells stay sovereign without duplicating governanceFully independent per-country deployments with no central plane
ADR-005Append-only hash-chained audit for governance recordsTamper evidence must be verifiable by the reader, not asserted by the vendor; chains are re-verified on every readConventional audit tables with administrative delete
ADR-006OMOP as a materialised ETL, not a viewResearch use needs a stable, quality-reported extract with a provenance ledger, not a live query surfaceOn-demand OMOP projection over the operational store
ADR-015User groups grant scope only, never a roleCoupling group membership to privilege creates silent elevation paths; role stays explicit and auditedGroups carrying role assignments, as most RBAC products do
ADR-016Partner integrations behind a single flagged seamA partnership ending must be a configuration change and a deletion, not a refactorPartner logic woven into the modules that consume it
ADR-017One AI provider seam with server-side keys onlyBrowser-held keys cannot be governed; a single active provider makes the audit answerablePer-feature provider configuration with client-side credentials
RISK
Architecture Risk Register
Identified architecture risks, exposure and mitigation
Risk RegisterImpact AssessmentMitigations
IDRiskImpactLikelihoodMitigation
AR-01Single-service backend becomes a scaling and change bottleneckHighMediumDomain modularisation on the roadmap; module boundaries already enforced by test
AR-02No event backbone — cross-module reaction is synchronousMediumHighKafka or Redpanda in the infrastructure epic; notification writer already abstracts delivery
AR-03Clinical outcome evidence is not yet available at scaleHighHighExplicitly not claimed. Ring 1 canary deployments are the route; assurance dashboard tracks readiness
AR-04Jurisdiction profile incompleteness blocks deployabilityMediumMediumFail-safe by design — unsigned mandatory domains block go-live rather than defaulting
AR-05Secret management is environment-injected, not vaultedHighMediumVault or Key Vault with rotation in the infrastructure epic; keys never reach the browser today
AR-06Observability gaps slow incident diagnosis across cellsMediumMediumOpenTelemetry to Grafana and Jaeger; control plane already aggregates
AR-07Regulatory reclassification of a decision-support capabilityHighLowNon-SaMD boundary asserted per module and reviewed at Ring 3; AIaMD assessment where borderline
AR-08Partner dependency becomes structural despite the seamLowLowRemovability is a standing order with a documented excision cost per partner
AR-09Documentation drift between the registry, this document and the codeMediumHighSame-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
Standards RegisterCompliance Mapping
  • 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
  • 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
  • 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 ViewADM CycleDeployment View
Layered architecture — five layers binding to one spine
Application & Data View
01PEOPLE-FACINGPatient PortalReferrals & AccessAmbulanceFront Door02CARE DELIVERYClinical CoreCommunityMH & SocialAllied HealthConditions03THE SPINE — one open record, one way inPERSON & RECORD SPINEEMPI · Whole Person Record · Care JourneyopenEHR · FHIR R4 · SNOMED — your data, openINTEROPERABILITY & EPRPulseGrid · HL7 · EPR Hub · GP Connect · NRLThe only place integration is needed — at the edge04RUN THE ORGANISATIONFlow & OperationsGovernance & RiskBoard & AssuranceWorkforceAnalytics & PopulationUS Care ManagementFinance05SHARED SERVICES — one of each, used by everything abovePlatform & AICommunications CRMJurisdiction & ConfigPerson bindingPerson entryFlow orchestrationGolden threadCohort to actionShared services615 modules built · 571 live. Every theme reads and writes the same record — the only integration is at the edge.
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.
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.