commvita
Connected care platform
Jurisdiction & Deployment

Building your commvita health system for your jurisdiction — configure, don't hardcode

How one platform becomes your health system: every jurisdiction-specific behaviour — identifier validation, terminology, workflow gating, residency, legal provisions — is read from a versioned, source-cited, signed-off Jurisdiction Profile, not written into the code. A jurisdiction goes live only when its mandatory domains are signed off and unexpired — and a missing value fails safe, never silently borrowing another jurisdiction's answer.

Live vs demonstrated: Live — real, API-backed platform logic (wired end-to-end today) Demonstrated — representative control surface with seeded data / illustrative UI mock-up
The standing principle. No jurisdiction-specific behaviour is hardcoded anywhere in commvita. Identifier formats, terminology binding, workflow gating, data residency and legal provisions are all resolved at runtime from the Jurisdiction Profile — a declarative, governed model where every value is a sourced, effective-dated, versioned entry with an owner and an assurance status. Move to a new country and you configure a profile and pack; you don't fork the code.

Three places you build it

Standing up a jurisdiction is three cooperating surfaces: define the variance (Profile), assemble the capability set (Packs), and configure the org & governance model (Wizard + Builder).

Jurisdiction Profile

The single source of jurisdictional truth

A versioned, governed model of variance across 14 domains. Nearest-wins inheritance resolves sovereign → sub-jurisdiction → org, and a missing or expired value fails safe — never defaulting to another jurisdiction's value.

Where in commvita /jurisdiction-profile — Profile Register · Resolution Tester · Deployability Board · Identifier Validator. API /jurisdiction-profile/.

Pack Registry

The capability set you install

Jurisdiction Packs bundle the modules a market needs — NHS England Core, NHS Community, US ACO Core, Crown Dependencies, Enterprise Analytics. Catalogue, per-jurisdiction installations map with update badges, and a pack builder.

Where in commvita /pack-registry · /jurisdictions/:code/packs. API /packs/.

Wizard & System Builder

The org & governance model you configure

The 10-step Jurisdiction Wizard captures identity, identifiers, landscape and governance model; the Health System Builder configures the multi-tier hierarchy (national → regional → ICS → PCN → practice → team) with a self-serve onboarding checklist.

Where in commvita Jurisdiction Wizard api.jurisdictionWizard · Health System Builder /health-system-builder.

1 Define the variance — the Jurisdiction Profile

Everything that differs between countries lives here as sourced, effective-dated, versioned entries — governed the same way regardless of jurisdiction, per docs/COMMVITA-PRD-jurisdiction-profile.md.

1

14 domains, every value governed

The Profile Register holds entries across 14 domains — each carries an owner, an assurance status (draftsourcedsigned_offexpired), a citation, an effective-from date and a review cadence. Admins add entries; a named signatory signs each one off.

/jurisdiction-profile · Profile Register
2

Nearest-wins inheritance

A value resolves along the hierarchy sovereign → sub-jurisdiction → org, and the nearest defined level wins — so UK-wide law can be inherited while England, a Crown Dependency or a single trust override only what they must. The Resolution Tester shows the winning level, version, effective-from and citation as provenance chips.

Resolution Testersovereign → sub-jurisdiction → org
3

Fail-safe on missing or expired values

If no value resolves — or the nearest one has expired — commvita returns an explicit fail-safe reason and the dependent capability declines to run. It never silently defaults to another jurisdiction's answer. This is the load-bearing safety rule (PRD §4.6).

fail-safe · never borrowPRD §4.6
4

Not deployable until signed off

The Deployability Board tracks domains-present / 14, a by-status breakdown, and a per-mandatory-domain sign-off ✓/✗, resolving to a hard DEPLOYABLE / NOT DEPLOYABLE verdict plus overdue-review flags. A jurisdiction is not live until every mandatory domain is signed_off and unexpired (PRD §10).

Deployability BoardPRD §10
Jurisdiction Profile / Deployability Board · a Crown Dependency (Health & Community Services) admin
DEPLOYABLE — 14 / 14 domains present · all mandatory domains signed-off & unexpired. 1 review due soon
Identifiers mandatory ✓ signed_off
Terminology binding mandatory ✓ signed_off
Legal provisions mandatory ✓ signed_off
Data residency mandatory ✓ signed_off
Workflow gating ✓ signed_off
Currency (ISO 4217) ✓ signed_off
Regulatory frameworks ✓ signed_off
Consent & opt-out ✓ signed_off
Org hierarchy ✓ signed_off
Provider directory ✓ signed_off
Screening schedule ◷ review due
Immunisation schedule ✓ signed_off
Safeguarding provisions ✓ signed_off
Funding model ✓ signed_off
Screening schedule — signed off, review cadence reached on 30 Jun 2026. Re-attestation by the named signatory keeps the jurisdiction deployable.
Contrast: any mandatory domain at ✗ (draft / sourced / expired) flips the verdict to NOT DEPLOYABLE and blocks go-live.
Representative UI — illustrative

2 Assemble the capability & governance model — Packs + Wizard

With variance defined, you choose what runs (Jurisdiction Packs) and configure how the organisation is shaped and governed (the 10-step Wizard).

Install a Jurisdiction Pack

The Pack Registry catalogues capability bundles — NHS England Core, NHS Community, US ACO Core, Crown Dependencies, Enterprise Analytics. The installations view maps which packs each jurisdiction runs and flags updates available. A pack builder assembles bespoke sets for a new market.

/pack-registry/packs/

Run the 10-step Jurisdiction Wizard

Identity → Modules → Identifiers → Landscape (org hierarchy / payers / provider types / funding) → Governance & Org Model → Term Overrides → Frameworks → Compliance → Currencies (ISO 4217) → Review. Each step writes to the jurisdiction config via api.jurisdictionWizard.

api.jurisdictionWizard

Pick the governance model — not one shape for all

The Governance & Org Model step sets a model_typecommissioning_hierarchy · multi_payer · insurance_based · universal_coverage — with pre-built templates for NHS England, US ACO, HSE Ireland, a Crown Dependency HCS and Saudi MOH. A US multi-payer model disables the commissioning hierarchy view and enables a payer panel.

model_typeNHS England · US ACO · HSE · Crown Dependency HCS · Saudi MOH

Shape the tiers & onboard

The Health System Builder configures the multi-tier hierarchy (national / regional / ICS / PCN / practice / team) and drives a self-serve onboarding checklist plus a certified-partner ecosystem — while RBAC maps 18 roles × 16 domains onto that structure, and the JurisdictionFlag component flies each region's correct national/regional flag.

/health-system-builder/rbacJurisdictionFlag
Jurisdiction Wizard · Step 5 of 10 / Governance & Org Model admin
Governance model type
commissioning_hierarchy
Template: NHS England — ICB → provider trust → PCN → practice → team. Board: ICB Board · Regulator: CQC.
multi_payer
Template: US ACO — CMS MSSP + commercial MA plans. Commissioning hierarchy off · Payer Panel on.
insurance_based
Payer-led coverage & claims model.
universal_coverage
Templates: HSE Ireland · Crown Dependency HCS · Saudi MOH.
Hierarchy preview — NHS England
ICB→ Provider trust→ PCN→ Practice→ Team
Board: ICB Board · Regulatory body: CQC.
If US ACO selected — Payer Panel
CMS MSSPCommercial MAMedicaid MCO
model_type: multi_payer · commissioning hierarchy view disabled.
Back Next — Term Overrides
Representative UI — illustrative

3 Runtime resolution — configuration doing its job

Once the profile and pack are in place, jurisdiction-specific behaviour is looked up, not branched. The Identifier Validator is the clearest example: the same code validates any scheme by reading the profile — and an unknown scheme fails safe.

Identifier validation by profile, not by code

NHS Number is checked with the Modulus-11 algorithm; a Crown Dependency JH-###### and Scotland CHI by their own formats; the US uses MBI + MRN. The validator reads the format from the jurisdiction's identifier domain — an unknown scheme fails safe rather than passing a value it can't verify (PRD J-06).

Identifier ValidatorNHS mod-11 · JH-###### · CHI · MBI

One catalogue, many jurisdictions

England · Crown Dependencies (Guernsey · Isle of Man) · Ireland (HSE) · Jamaica (MOHW) · Kenya · Scotland · Wales · Oman · Saudi Arabia (MOH) · Gibraltar (GHA) · commvita Care ACO (US, CMS MSSP) — each a configured profile + pack, not a code fork. Standards follow the jurisdiction: UK GDPR, Saudi PDPL, and so on.

seeded jurisdictionsUK GDPR · Saudi PDPL
Jurisdiction Profile / Identifier Validator admin
England · NHS Number
485 777 3456
Valid · Modulus-11 check digit ok
Crown Dependency · Health Number
JH-204817
Valid · JH-###### format
England · NHS Number
485 777 3457
Invalid · mod-11 check digit fails
Unknown scheme · ZZ-99A
ZZ-99A-0001
Fail-safe · scheme not in profile — rejected, not assumed valid
🛡The validator never borrows another jurisdiction's format. An unrecognised scheme fails safe (PRD J-06) rather than passing an unverifiable identifier.
Representative UI — illustrative
Why this matters for a demo. Standing up a new country in commvita is a governed configuration exercise, not an engineering project. Variance is declared once in the Jurisdiction Profile, capability is installed as a Pack, the org & governance model is set in the Wizard — and the running platform resolves the right behaviour, or fails safe, on every request. Nothing about England, the Crown Dependencies, the US or Saudi Arabia is written into the code.

Where it lives in commvita

Define variance · Profile Install capability · Packs Configure model · Wizard + Builder Resolve or fail-safe · at runtime
CapabilityModuleRouteModel / APIStatus
Declarative jurisdiction variance (14 domains)Jurisdiction Profile/jurisdiction-profileentries · signoff · resolve · summary · validate-identifier● Live/jurisdiction-profile/
Nearest-wins resolution & provenanceJurisdiction Profile · Resolution Tester/jurisdiction-profilesovereign → sub-jurisdiction → org · fail-safe reason● Live (SEEDED fallback badge)
Deployability gate (signed-off / unexpired)Jurisdiction Profile · Deployability Board/jurisdiction-profiledomains-present/14 · per-mandatory sign-off · DEPLOYABLE verdict● Live
Identifier validation (mod-11 · JH · CHI · MBI)Jurisdiction Profile · Identifier Validator/jurisdiction-profilevalidate-identifier · unknown scheme fails safe (J-06)● Live
Jurisdiction Packs (capability bundles)Pack Registry/pack-registry · /jurisdictions/:code/packscatalogue · installations map · pack builder● Live/packs/
10-step configuration (identity → currencies → review)Jurisdiction Wizardapi.jurisdictionWizardlist · get · create · update · setActive · featureLocks● Live
Governance & org model (model_type + templates)Jurisdiction Wizard · Step 5api.jurisdictionWizardcommissioning_hierarchy / multi_payer / insurance_based / universal_coverage● Live
Multi-tier hierarchy & self-serve onboardingHealth System Builder/health-system-buildernational → regional → ICS → PCN → practice → team · onboarding checklist◍ Demonstrated
Role & domain access modelRBAC · RBAC Matrix/rbac18 roles × 16 domains · /rbac/matrix● Live
National / regional flagsJurisdictionFlag componentJurisdictionFlag.tsxinline SVG per code◍ Demonstrated
Jurisdiction dashboards (Ireland · Jamaica · Oman …)Ministerial / national overviews/ireland-minister · /jamaica-healthseeded national datasets◍ Demonstrated
© 2026 Commvita Digital Health Solutions Ltd. All rights reserved. Versioned, signed-off Jurisdiction Profile governanceNearest-wins inheritance · fail-safe on missing/expired ISO 4217 currencyPer-jurisdiction: UK GDPR · Saudi PDPL · et al.NHS Number mod-11 · CHI · Crown Dependency JH-###### · MBINon-SaMD configuration & governance surface