Ready for the standards that are still being written
How commvita™ already meets the two frameworks now shaping national digital-health architecture — the WHO reference architecture for Digital Public Infrastructure for Health and the European Health Data Space — and exactly what the bridge looks like when their final technical specifications are published. A design-alignment statement, not a certification or conformity claim.
1 The two frameworks, in one minute
Both are emerging — one is a draft, the other is law whose technical detail arrives via implementing acts. That is precisely why architecture matters more than paperwork right now: a platform either has the building blocks, or it will be re-architecting under deadline.
WHO — DPI for Health
The WHO's blueprint for national digital-health systems, built from reusable building blocks: a client registry / master person index, a shared health record, terminology services, health-worker and facility registries, an interoperability (HIE) layer, digital identity, consent & governance, citizen services, financing, analytics — deployed on DPI principles: federated, sovereign, modular, open standards.
EU — European Health Data Space
Binding EU law with two halves. Primary use: patients access their own data immediately and free; priority categories (patient summaries, e-prescriptions, images, labs, discharge reports) exchanged in a common European format (EEHRxF); EHR systems must ship a harmonised interoperability component and a logging component. Secondary use: health data access bodies, data permits, secure processing environments, and an opt-out.
2 Why commvita™ already fits — five architectural choices
Neither framework asks for a feature. Both ask for a shape — and commvita™ was built in that shape from the start.
One canonical person record, indexed by a real MPI
Every module keys to a single canonical Patient; the EMPI cross-references national identifiers across jurisdictions — including an EHDS NCPeH proxy identifier generator for cross-border identity. The WHO client registry and the EHDS identity layer are the same thing here, already shipped.
Open standards natively — FHIR R4, openEHR, OMOP, SNOMED CT
Records, exports and analytics are already structured in the vocabularies both frameworks bind to. Whatever final format EEHRxF takes, it will be a FHIR-profiled rendering of data commvita™ already holds structured — a mapping exercise, not a data-model rebuild.
Nothing jurisdictional is hardcoded
The versioned, signed-off Jurisdiction Profile carries identifier schemes, terminology bindings, legal provisions and residency rules per jurisdiction, with fail-safe resolution. Adopting a WHO-aligned national profile or an EHDS member-state profile is configuration with governance, not a fork.
Federated and sovereign by deployment model
Self-hosted, cloud-agnostic (Docker / Kubernetes / Helm — any cloud or on-premise); federated analytics where data never leaves the source and only k≥5 aggregates move. That is the WHO DPI sovereignty principle and the EHDS secure-processing posture, as an architecture rather than a promise.
A governance spine that already exceeds the logging ask
Append-only, SHA-256 hash-chained (WORM) access logs re-verified on every read; purpose-and-legal-basis policy-as-code; Caldicott gate for secondary use; opt-out enforcement; patient-visible "who looked at my record" transparency. The EHDS European logging component asks for less than this.
W WHO DPI-H building blocks — where each one lives today
All twelve building blocks of the draft reference architecture, mapped to the shipped platform. 11 aligned · 1 partial.
| Building block | commvita™ today | Where it lives | Status | Alignment |
|---|---|---|---|---|
| Client registry / MPI | EMPI Hub — multi-identifier search across national schemes, merge wizard, dedup queue, 8-source identity federation, NCPeH proxy generator | /empi | ● Live | Aligned |
| Shared health record | Whole Person Record (12 tabs, cross-setting timeline) + Neighbourhood Health Record for cross-org MDTs; PRSB-mapped shared-record dashboards demonstrate ICS-level assurance | /patients/:id/whole-person /nhr | ● + ◍ | Aligned |
| Terminology services | FHIR R4 terminology console (SNOMED CT · ICD-10 · OPCS-4 · dm+d · LOINC, TRUD releases, local|live modes) + legacy-code crosswalk | /terminology-service | ● Live | Aligned |
| Health worker registry | Workforce registration with background checks + professional registers and expiry RAG, resolved per jurisdiction; org chart + ESR sync | /regulatory-engine /hierarchy-builder | ● Live | Aligned |
| Facility / org registry | Live national org lookup (NHS ODS FHIR — no key required), org administration, multi-tier health-system hierarchy builder | /ods-health /health-system-builder | ● Live | Aligned |
| HIE / interoperability layer | EPR Hub (ADT feed, FHIR browser, retry queue) live over 12 seeded EPR connectors; HL7 Engine, FHIR Bulk $export and Transformation Studio as demonstration consoles; IHE profile register | /epr-hub /hl7-engine /fhir-bulk | ● + ◍ | Aligned |
| Digital identity & authentication | OIDC identity federation (Microsoft Entra ID + SCIM provisioning) for workforce; NHS Login-pattern citizen identity on the portal; JWT with revocation + Art.9 step-up re-auth | Settings → OIDC/SSO /portal | ● Live | Aligned |
| Consent & data governance | Digital consent workflows (API-backed) + purpose/legal-basis policy-as-code, Caldicott queue and sharing-preference registry (demonstration surfaces) | /consent-hub /ig-spine /shcr-opt-out | ● + ◍ | Aligned |
| PHR / citizen services | Patient Portal — records, appointments, messages, goals, FHIR export, communication needs, proxy access; kiosk self check-in demonstrated | /portal /digital-front-door | ● + ◍ | Aligned |
| Financing & claims (payments DPI) | Tariff engine (API-backed), activity costing, claims EDI adapter, private invoicing — claims/tariff capability; a national payment rail is the jurisdiction's foundational DPI, deliberately not rebuilt here | /nhs-payment-system /private-charges | ● + ◍ | Partial |
| HMIS / analytics | Population health cohorts + phenotypes, inequalities lenses, OMOP CDM ETL with data-quality dashboard (live), ICS-wide analytics demonstrated | /population-health /omop-cdm | ● + ◍ | Aligned |
| DPI principles — federated · sovereign · modular · open | Self-hosted cloud-agnostic deployment; federated queries with k≥5 aggregation (consoles demonstrated); versioned Jurisdiction Profile (API-backed) so no jurisdiction is hardcoded; openEHR/FHIR/OMOP throughout | /federated-query /jurisdiction-profile | ● + ◍ | Aligned |
E EHDS obligations — where each one lives today
The ten obligations that matter for an EHR platform under Regulation (EU) 2025/327. 6 aligned · 3 partial · 1 designed to align.
| EHDS obligation | commvita™ today | Where it lives | Status | Alignment |
|---|---|---|---|---|
| Patient access to own data | Portal record access + one-click FHIR R4 Bundle export (GDPR Art.20 portability), proxy/carer delegated access with transparency | /portal · Privacy tab | ● Live | Aligned |
| Priority categories & EEHRxF | FHIR R4 International Patient Summary generator live; prescriptions, labs, letters and imaging held as structured FHIR-exportable data — EEHRxF binding applied when the implementing acts fix the format | /ehds · IPS /clinical-letters | ● + ◍ | Partial |
| European interoperability component | Open FHIR R4 API surface + machine-readable OpenAPI contract, packaged for conformity self-assessment once harmonised specs are adopted | /ehds /fhir-bulk | ◍ Demonstrated | Designed to align |
| European logging component | SHA-256 hash-chained WORM access logs re-verified on read (live account-access chain), plus access-justification log with patient transparency and challenge workflow (demonstrated) | /login-audit /legitimate-access-log | ● + ◍ | Aligned |
| MyHealth@EU / NCPeH | NCPeH proxy identifier generation in the EMPI; MyHealth@EU connector surface — live exchange requires onboarding with each member state's national contact point | /empi /ehds · MyHealth@EU | ● + ◍ | Partial |
| Rectify · restrict · object (primary use) | Consent capture & GDPR Art.7 withdrawal (API-backed); category-level sharing opt-outs propagated as FHIR Consent with override audit (demonstrated) | /consent-hub /shcr-opt-out | ● + ◍ | Aligned |
| Secondary use — HDAB & data permits | Research governance with approval packs, DSA register and lawful-basis capture (API-backed); external research request pipeline; EHDS permit register surface | /clinical-studies /research-portal | ● Live | Aligned |
| Secure processing environments | Three-tier anonymisation, token-vault separation, k≥5 disclosure control with export blocking, immutable extract ledger with file hashes, real OMOP CDM ETL with DQD | /clinical-studies | ● Live | Aligned |
| Secondary-use opt-out | National-opt-out enforcement modelled in the IG spine's secondary-use flows and the sharing-preference registry | /ig-spine /shcr-opt-out | ◍ Demonstrated | Aligned |
| Data quality & utility label | OMOP Data Quality Dashboard attached to every CDM extract (live); DQMI-style data-quality dashboards (demonstrated) — label format follows the implementing acts | /omop-cdm /data-quality | ● + ◍ | Partial |
→ The bridge — what happens when the standards are finished
Every remaining gap is a dependency on an external specification or onboarding process that does not exist yet — none needs new architecture. When each one publishes, the bridge uses a pattern commvita™ has already proven in production code.
EEHRxF — bind the European exchange format the day it publishes
Today: the IPS generator is live and every priority category is held as structured FHIR. The bridge: pin the published EEHRxF profiles into a schema file and validate every emitted record against them — the exact pattern already shipped for the NHS FDP Canonical Data Model, where the real published OpenAPI (16 objects / 507 fields) is pinned into fdp_cdm_object_schema.json and every extract is conformance-scored per object. Same emitter, different pinned spec.
Interoperability component — a conformity declaration over an existing API
Today: the open FHIR R4 surface and OpenAPI contract exist. The bridge: run the Chapter III conformity self-assessment against the harmonised specs when adopted and publish the declaration — assembled the way commvita™ already assembles DTAC and DSPT evidence packs, and staged through the existing assurance-ring model (Ring 3 = regulated deployments).
MyHealth@EU — one credential-driven adapter per national contact point
Today: NCPeH proxy identity and the connector surface. The bridge: onboard each member state's NCPeH as a credential-driven adapter — the same env-only-secret pattern as the seven NHS national adapters (e-RS, LFPSE, screening systems…), where adding an endpoint is a config entry with honest demo-mode queueing until credentials are provisioned, then a guarded live transmit. No browser-side secrets, ever.
Data quality & utility label — a rendering of metrics that already run
Today: every OMOP CDM extract carries a Data Quality Dashboard summary (completeness · plausibility · conformance per table) and DQMI-style monitoring exists. The bridge: map those measures onto the label format the implementing acts define — a presentation-layer mapping over live machinery.
WHO final guidance — tracked by a living, in-product register
Today: the draft's twelve building blocks are mapped in-product (below). The bridge: when the final guidance publishes, the same register is re-mapped against the final building-block list — any delta becomes a scoped backlog item rather than a discovery exercise.
6 This mapping is shipped in-product
The alignment register is not a slide — it is a component on the platform's Architecture page (Standards tab, Build B-359), so the mapping is versioned with the code and updated as the frameworks move.
