Provenance
Keep source organisation, record identifier, clinical date, retrieval time and status alongside the item.
Reimea Exchange / in development
The source matters.
So does what is missing.
A source-attributed shared-care-record design connecting existing systems. The current experience is a synthetic demonstrator, with production identity and connectivity still to establish.
One view. Distinct sources. Visible gaps.
Synthetic source example
Primary care
Source available
Retrieved 09:12
Synthetic source example
Urgent care
Source available
Retrieved 02:40
Synthetic source example
Hospital record
Source unavailable
Coverage unknown
Illustration of intended source-status behaviour. These are fictional sources and times, not live connections.
Who the design is for.
Participating health and care organisations
The target is an authorised professional reviewing information across agreed participating organisations, beginning with a defined pathway rather than a claim of national coverage.
Information governance and integration teams
Access purpose, patient identity review, source agreements and endpoint-specific validation are part of the design. A Meridian login never grants access to Exchange records.
What the product should preserve.
Uncertainty
Show conflicts and unavailable sources. An empty view must not imply that no history exists.
Access boundaries
Review identity, purpose of use and permissions. FHIR R4 is an interface basis, not proof of an approved NHS connector.
Current status, in plain terms.
Today: synthetic records and demonstrator workflows. No production patient login, approved national retrieval or validated clinical use is established by the supplied review.
Before a live pathway: agree intended purpose, participating organisations, identity and access, connector contracts, source coverage, clinical safety evidence and operational approval.
Meridian and Exchange are separate products with separate access boundaries. Neither a common brand nor a shared sign-in removes that distinction.
From an authorised question to a source-attributed view.
- 01
Establish context
Identify the professional, organisation, purpose and permitted pathway.
- 02
Review identity
Resolve the patient match using approved identifiers and human review where uncertain.
- 03
Request sources
Ask the permitted connectors for agreed record categories and capture availability.
- 04
Preserve provenance
Show source, date, status and disagreements alongside the information.
- 05
Review and account
The professional interprets the view; the deployed service must record authorised access and operational outcomes.
What is in the view?
The target design covers demographics, allergies, medications, problems, encounters, observations and documents. Prescribed, dispensed and reportedly taken medication should remain distinguishable. This is a statement of target design, not a claim of live coverage of those categories across the NHS.
How Exchange is designed to work.
A staged interoperability design, with a synthetic demonstrator today. The following separates implemented demonstration behaviour from the target production architecture.
| Layer | Technical purpose | Current boundary |
|---|---|---|
| Identity and access | The target includes organisation membership, explicit permission, purpose of use and patient identity review before record retrieval. | The supplied review does not establish production patient login or a verified cross-organisation identity path. |
| Connector gateway | Retrieve agreed record categories through endpoint-specific adapters, with source availability and validation kept visible. | Initial connectors are simulated. FHIR R4 support alone is not an approved NHS connection. |
| Record representation | The design preserves source identifiers, author where supplied, clinical date, retrieval time and status, rather than silently combining incompatible facts. | A source-attributed view is not proof that identity matches or clinical interpretations are correct. |
| Persistence | The application includes SQL repository support using SQLite locally or PostgreSQL when configured; some profile paths have an explicit Tables adapter. | Cloud-capable persistence does not create patient authorisation or approve clinical data retrieval. Shared database infrastructure is logical separation, not independent security isolation. |
| Failure semantics | Unavailable sources should be represented as unavailable, with coverage and retrieval status beside the information. | An empty result must not be interpreted as an empty history. Live behaviour needs connector and failure testing. |
| Audit and operations | The target calls for access reasons, policy outcomes, actor, patient reference, source and correlation metadata, plus connector monitoring. | Production completeness, protected retention and emergency-access processes require implementation and evidence. |
Technical questions for an Exchange pathway.
Does an NHS number authenticate a patient?
No. An identifier can support matching; it is not proof of identity, authentication or authority to access a record.
Does FHIR R4 make every system compatible?
No. Profiles, terminology, endpoint contracts, authorisation and source-specific behaviours still require agreement and testing.
Can Meridian bypass Exchange access policy?
No. The shared platform design does not grant clinical-record access. Any permitted context request must pass through Exchange’s own access policy.
Technical source notes
Source: supplied Exchange integration design, platform architecture and data-flow review. Production requirements in that design are not all implemented demonstrator capabilities.
Read the assurance summary