One integrated platform for health and care.
The record, the operations, the governance and the population view as one set of facts — with each component’s real status stated not implied.
One platform, not a suite
Every component reads the same record and the same jurisdiction profile. There’s no integration layer between them, because they aren’t separate products.
Surfaces, applications, the record, integration and the platform base.
What the platform is made of
| Component | What it does | Status |
|---|---|---|
| Whole person record | One record over time, across every setting a person is known to, resolved instead of merged. | Live |
| Clinical applications | Consultation, prescribing, assessments, diagnostics, long-term conditions and specialist pathways. | Live |
| Care coordination | One case with a named key worker and a list of participating organisations, not a case per organisation. | Live |
| Operational flow | Demand and capacity as one managed line — front door, wards, discharge and the constraint that’s actually binding. | Live |
| Referral management | Protocol-gated referral with pre-consultation diagnostics ordered against the pathway’s own criteria. | Live |
| Governance & assurance | Incident to risk to board objective as one traceable chain, on a tamper-evident audit. | Live |
| Population health | Segmentation, risk stratification, inequalities and cohort-to-action. | Live |
… continued
| Component | What it does | Status |
|---|---|---|
| Citizen services | A portal, proxy access, declared communication needs and self-management. | Live |
| Research services | Cohort discovery, de-identified extracts and an immutable extract ledger. | Live |
| Genomics | Referral, consent, pedigree and pharmacogenomic surfaces — with a persistence gap stated below. | Partial |
| Analytics & reporting | Statutory returns, board reporting and a report registry with computed deadlines. | Live |
| Workflow automation | Policy turned into a gated process with quorum approvals and escalating service levels. | Live |
| Open APIs & integration | FHIR, HL7 v2, bulk export, adapters and a message engine. | Live |
The patient portal, and an honest account of it
A portal is where a person exercises rights, so a control that appears to work and doesn’t is worse here than anywhere else on the platform. Four of these aren’t yet what they look like, and the page says which.
Thirteen portal capabilities with their real status. The four amber and red rows are recorded in the platform’s own defect register.
Four controls that don’t yet do what they appear to
The per-study research opt-out and the national data opt-out both render, both move when a person toggles them, and neither writes anything. A person can believe they have opted out and haven’t.
The granted-access list is held in memory, so it’s lost when the system restarts and differs between copies. Removing an entry doesn’t restrict any member of staff, because access is controlled by role and organisation instead.
The data export returns the same demonstration file for every patient. It shows the shape of the data and must never be given to someone as their own record.
We publish these and not quietly fixing them later. A buyer assessing information governance needs the real position, and saying so is the only thing that makes the rest of this site worth believing.
A jurisdiction is a configuration, not a release
The ten setup steps. A value that hasn’t been set falls back to nothing, never to a neighbouring country’s.
Every value cites something
A configuration entry carries its source, the date it took effect and the person accountable for it. An uncited value is a draft.
History stays true
Superseding a value doesn’t overwrite it. Last year’s performance still reconciles against the body that actually held the contract.
Never a borrowed default
An unconfigured jurisdiction gets nothing, not England’s. Coding a discharge in the wrong country’s classification is worse than refusing to code it.