Evidence Matrix

Rows marked Source required are deliberate evidence gaps, not validated support.

Use Source and Evidence Domain Map, NHS England Digital Primary Care Evidence Domain, HealthShare Components Evidence Domain, and Standards and Interoperability Evidence Domain for domain-level slices. This page remains the canonical claim-to-source register.

This matrix is source-ID-first. Add reader-facing source-layer links only when a claim row is itself defining a reusable route or synthesis boundary; otherwise keep dense proof labels traceable through Source IDs and the related synthesis page.

Claim	Evidence Type	Confidence	Limits	Next Evidence Needed
ScotAccount authentication and England's National Data Opt-Out checking are documented system-to-system routes with distinct purposes.	Official integration and service guidance	High for documented exchange; access remains scoped	ScotAccount is an onboarded OIDC beta for eligible Scottish public services, not generic GP/proxy entitlement. NDO MESH filters NHS-number lists for applicable data uses; it does not set the patient's choice or govern individual-care sharing.	The named application onboarding and intended data-use scope for an implementation.
England's CP-IS, FGM-IS and reasonable-adjustment services have documented system-to-system interfaces, separate from NCRS portal access.	Official API catalogues, OpenAPI specification and onboarding guidance	High for documented operation/status; migration completion unresolved	Healthcare CP-IS queries and local-authority uploads differ. Legacy FGM is deprecated read-only production. New Patient Flags remains internal/beta with external first-of-type limits; generic retirement wording conflicts with specific legacy catalogues.	Confirm the selected flag, operation and production interface during supplier onboarding; no universal cutover inferred.
Scottish child protection sits within GIRFEC, while the child’s plan, Child Protection Plan, local-authority register and digital alert remain distinct. England CP-IS and FGM-IS have different purposes and permissions.	Official national policy, practice and service guidance	High for stated roles and functions; API comparison is a bounded synthesis	GIRFEC does not establish a Scottish NHS CP-IS/FGM-IS endpoint. The 2023 police iVPD flag reference is not evidence of current GP integration. A child’s plan does not itself establish registration for child protection.	Named local access/interface specification only for a concrete integration or deployment claim; no new request pack.
Urgent-care access, triage, service discovery, referral, appointment arrangements and GP notification are separate functions across the four nations.	Official national/local service evidence and comparative synthesis	High for defined routes; incomplete interface coverage	Same number, supplier or FHIR label does not establish shared APIs. Referral delivery is not appointment confirmation or clinical acceptance.	Selected sender/receiver interface, service scope, acceptance/failure workflow and appointment owner.
England uses distinct UEC DoS, e-RS directory and public DoHS services; newer DoS Search does not yet replace all clinical discovery functions.	NHS service, API catalogue and current OpenAPI specification	High for documented operation availability	HealthcareService/triage-search operations are published but unavailable in UAT/production; existing UEC SOAP/REST remain production under deprecation review. DoHS legacy retirement text is inconsistent.	Operation-specific onboarding and lifecycle confirmation before replacing a live interface.
Current DSIC urgent-care requirements distinguish NHS 111 receiver obligations, GP-to-pharmacy BaRS roles and community-pharmacy UEC DoS scope.	Current effective DSIC pages and NHS service guidance	High for catalogue requirement; not supplier rollout	S33 v2.0.5 effective 18 September 2026; S93 v2.0.3/S107 v1.0.3 effective 10 September. GP Connect booking onboarding and deployed supplier coverage remain separate.	Applicable capability, contracting vehicle, sender/receiver role and version for the named solution.
BaRS supplier assurance, live application use and NHS 111 SOAP/CDA report handling are distinct evidence.	NHS supplier matrix, service and adaptor documentation	High for dated register/API facts	Nervecentre App 1/2 receiver is supplier-assured; this does not establish Trust deployment. No named InterSystems row found. FHIR conversion by the Report adaptor is not BaRS or MESH transport.	Named product/application version, endpoint pairing and live customer evidence.
Scotland combines NHS 24, board FNCs, local appointment ownership and separate clinical-platform evidence, while newer navigation arrangements remain planned.	NHS operations, procurement and government evaluation/plan	High for scoped operations and commitments	Public app/directory functions are not booking APIs; handoff payload and end-to-end acknowledgement unverified. NHS Pathways assurance discussions demonstrate learning, not software adoption.	NHS 24/board interface contract and dated implementation evidence for the new navigation model.
Wales has its own CPSS/ECNS and DoS arrangements, dated OOH handoff/booking evidence and documented England/Wales border referral routing.	NHS service guidance, operational papers and data definitions	High for named workflows; qualified current interface scope	All-Wales DoS development and defined booking queues are not universal live endpoints. Border referrals do not establish England NHS Pathways/DoS/BaRS adoption; historical Adastra evidence does not prove current transport.	Current health-board receiving contract, directory service and booking coverage.
NI Phone First and GP OOH remain locality-specific routes; a regional 111 service was absent in the February 2026 ministerial answer and later proposals are not a launch.	Ministerial/Assembly and current Trust guidance; dated implementation report	High for dated status and locality differences	Belfast central/local age scope conflicts; older Southern hours differ from current contacts. Historical Adastra/CCG work and encompass availability do not identify current urgent-care transport.	Current Trust source reconciliation and regional-service acceptance/interface evidence if claimed.
The expanded UK Core Services Matrix uses England DSIC as a functional and assurance lens while separating directly mapped standards, adjacent national services and actual devolved adoption.	Official catalogue plus comparative synthesis	High for catalogue model; bounded for national equivalence	An effective document is not universal rollout, supplier implementation or UK-wide applicability. No dedicated S-ID established here for SDS, NRL or national flags.	Named supplier role, capability/standard version, applicable contracting vehicle and onboarding proof for an implementation.
Current DSIC identity and registration requirements distinguish staff authentication, patient login, provisioning, validated relationships, registration intake, list transactions and event signals.	Current official standards/capability pages	High	C13/S114 effective 23 September 2026; S125/S103–105 effective 9 September. The patient-facing APIs dispense with GP Linkage Keys, but legacy IM1 and Welsh NHS login adoption have separate scopes.	Deployment-specific migration and nation-specific interface evidence.
GP read, document delivery, structured updates, booking, IM1, vaccination reporting and extraction are distinct supplier roles and workflows.	Official standards and service availability	High for specified roles	Closed new-developer onboarding for three GP Connect routes coexists with effective standards; S116 separates new-solution FHIR at recording from existing daily MESH. GPES/CQRS and pharmacy claims are different.	Exact approved workflow, provider/consumer pairing and supported data coverage.
Wales reuses NHS login and PCRM registration/reporting; FPPS is supplied to Wales by NI BSO under a service agreement with a Welsh-specific environment.	Government identity standard and Audit Wales system audit	High for named reuse and dated Welsh replacement	Welsh NHAIS replacement completed July 2024. These sources do not establish all England GP APIs, DSIC timetables or all current NI payment flows.	Interface and authorisation scope for a selected Welsh deployment.
Scotland has nation-specific NDP access, CHI registration, KIS/plan, screening, child-health and reporting services alongside real NHSCR and terminology exchange across borders.	Official national services, guidance and operational documents	High for described function; qualified coverage	NHSCR movement linkage is not full clinical-record access. CHS replaced CHSP/SIRS early/mid-2026; PCIS follows SPIRE retirement in August 2023. NDP vaccination is internal-user scope; ReSPECT board coverage is bounded.	New-interface or current board deployment evidence only when a named integration needs it.
Welsh and NI prevention/reporting systems require programme-specific reading rather than inference from national portals or encompass.	Public health, DHCW, government and BSO sources	High for dated functions; incomplete transition coverage	Welsh CSIMS/DEWIS/WIS/CYPrIS have distinct roles; Audit+ later replacement unverified. NI GPIP/QOF replaced PCAS July 2022, while child-health operational cutover and cervical-screening replacement remain unverified.	Current service acceptance/interface evidence for NI transitions; Welsh Audit+ replacement decision where needed.
UK Core is collaborative standards development; shared terminology, common fit-note functions and UK Yellow Card do not imply shared clinical APIs. England National Data Opt-Out is a separate care/data-scope service.	Official standards, government and service sources	High for scope; synthesis for reuse taxonomy	Balloted and development FHIR packages differ. Digital fit-note implementation varies; England extract is distinct. National Data Opt-Out is not direct-care consent or a residency-only rule. Device reporting has a separate Scottish route.	Agreed profile/package, terminology release and purpose-specific permissions for a concrete connection.
GP extraction, achievement verification and payment administration are separate four-nation functions: England GPES/CQRS/PCSE; Scottish PCIS and contractor finance; Welsh Audit+/FPPS; NI GPIP/QOF.	Official service, audit and user guidance	High for scoped roles; incomplete current estate	Aggregated reporting does not establish direct-care record access; same payment-platform provenance does not establish shared national payment rules or every current NI workflow.	Current data-extraction and payment interface contracts for the selected nation and supplier.
InterSystems UK positions its healthcare offering around off-the-shelf care-management software and healthcare-specific data platforms for solution development.	Official vendor industry page	High for vendor positioning	Does not independently validate market adoption or effectiveness.	Add non-vendor market/procurement sources if the wiki later covers market position.
The core official UK healthcare portfolio includes IRIS for Health, HealthShare, and IntelliCare; the wider product navigation also exposes FHIR Services, TrakCare, HealthShare components, and TrakCare/IntelliCare modules.	Official vendor product/navigation pages	High for product taxonomy	Website navigation can change; confirm before procurement or implementation planning.	Recheck official product pages during each major research pass.
IRIS for Health is positioned as a cloud-first healthcare data/application platform for FHIR-based healthcare application development and healthcare data management; current IRIS for Health documentation also carries NHS ITK material in the historical accreditation context. The 2026-06-20 product-map audit separates this platform/documentation evidence from current NHS conformance, GP Connect supplier-progress, programme/customer use, and live deployment proof.	Official vendor product page and product documentation	High for product positioning and documentation presence; boundary for implementation proof	Technical depth, licensing constraints, current conformance, GP Connect/MESH/ITK/ITK3 onboarding, customer architecture, safety, governance, and operational status require separate evidence.	Add current product/version conformance records, implementation-specific assurance artefacts, and customer deployment evidence.
HealthShare is positioned as an interoperability, connected-care, and analytics suite; Unified Care Record aggregates, normalises, and deduplicates data into a shared longitudinal record. The 2026-06-20 UCR high-risk audit separates this product capability from PRSB section coverage, Clinical Viewer behaviour, DSIC / GP Connect adjacency, customer architecture, safety, governance, and live-status proof.	Official vendor product pages and wiki audit synthesis	High for product positioning; boundary for implementation proof	Implementation architecture, identity matching, role/access configuration, data governance, and operational responsibility vary by customer.	Add technical architecture docs, PRSB scope details, Clinical Viewer configuration evidence, and customer deployment details.
HealthShare Clinical Viewer is a HealthShare clinical presentation component, listed separately from Unified Care Record in InterSystems documentation, positioned in UCR material as the user-facing route for viewing HealthShare/UCR longitudinal-record information, and named in a historical H&W ICWR DPIA data-flow design. The 2026-06-20 high-risk audit separates presentation/access positioning from SSO/RBAC/audit configuration, AI Assistant / Navigation Application adjacency, clinical-safety/governance artefacts, and current deployment proof.	Official vendor product page, resource page, documentation index, AI Assistant launch/material, published DPIA, and current documentation/sample/product-term boundaries	High for vendor taxonomy and positioning; moderate-high for AI Assistant adjacency and historical DPIA deployment-context evidence	HealthShare 2026.1 documentation exists but is WRC-login gated, and the AI Assistant sample/product terms do not expose full Clinical Viewer configuration. Licensing boundary, deployment architecture, SSO/RBAC/audit configuration, current live status, clinical-safety artefacts, and local clinical-view templates still need current product documentation or customer evidence.	Add accessible Clinical Viewer documentation, access-control evidence, clinical-safety/governance artefacts, and deployment-specific examples.
HealthShare 2026.1 documentation and current product pages split the suite into distinct components including Unified Care Record, Clinical Viewer, EMPI, Provider Directory, Health Insight, Personal Community, Care Community, and HealthShare AI Assistant.	Official documentation index, product pages, technical documentation, and vendor resources	High for component taxonomy; high for Provider Directory public product-feature boundary; high for Care Community / Personal Community integration mechanics; moderate-high for AI Assistant launch and Lincolnshire Care Community positioning	Current documentation availability is confirmed, but much detailed 2026.1 content is account-gated. The Provider Directory fact sheet is product-feature evidence, not NHS implementation proof. The accessible Care Community technical source is a Personal Community integration guide, not a complete Care Community implementation manual, and vendor-published Lincolnshire material is not independent customer assurance.	Add direct component technical documentation where accessible, customer-side deployment evidence, clinical-safety/governance artefacts, and configuration evidence.
Care Community has current accessible technical evidence for patient contribution workflows through Personal Community integration: care plans can be viewed and completed in Personal Community when Care Community is integrated, with Unified Care Record service-registry and Workbench configuration steps. InterSystems also publishes a Care Community resource naming Lincolnshire NHS care-plan use.	Official product page, official technical documentation, and vendor-published resource/PDF	High for product and integration mechanics; moderate for Lincolnshire customer signal	This does not prove current live status, local care-plan templates, clinical-safety ownership, RBAC design, DPIA/DSA, or independent Lincolnshire customer assurance.	Add Lincolnshire ICS/NHS customer source, direct Care Community configuration documentation where available, DPIA/DSA, DCB0129/DCB0160, role/access model, and current operational owner evidence.
The HealthShare Components Evidence Domain provides a structured wiki slice for HealthShare component taxonomy, connected-care deployment context, standards relevance, AI Assistant boundary, and DSIC adjacency, while keeping product family, component, customer deployment, legacy signals, current successor-service signals, and supplier-assurance claims separate. The 2026-06-21 consistency pass adds a component assurance snapshot and selects EMPI / Provider Directory identity and directory assurance as the next non-Care target; the subsequent PDS/ODS source pass strengthens the national-service dependency boundary but does not prove EMPI or Provider Directory implementation. The 2026-06-28 Provider Directory pass adds stronger public product-feature / version evidence and a historical Coordinate My Care signal without closing current implementation proof; the current UCP check points to Better / Valida / London Care Record / UCP web portal / National Record Locator routes, not a current Provider Directory claim.	Wiki synthesis backed by official vendor documentation, PRSB material, customer/deployment-side records, NHS supplier-progress evidence, NHS PDS/ODS evidence, DSIC sources, Provider Directory fact/advisory evidence, historical CMC/UCP evidence, current UCP access/platform evidence, and Care Community technical/vendor resource evidence	High as an internal navigation and due-diligence aid; not supplier conformance or customer implementation evidence	The domain page is a navigation/synthesis layer and should not be used as a substitute for source IDs, evidence-matrix rows, or implementation-specific artefacts. PDS/ODS evidence defines requirements; Provider Directory product features, the historical CMC signal, and current UCP access/platform evidence do not prove current HealthShare EMPI or Provider Directory implementation.	Add component-specific supplier, implementation, safety, governance, and deployment evidence as it becomes available; do not continue Care Community unless a specific customer-confirmation requirement is opened.
The Standards and Interoperability Evidence Domain provides a structured wiki slice for standards surfaces, NHS Standards Directory routing, PRSB and DUAA supplier-role boundaries, GP Connect / MESH / ITK3 role splits, GP2GP separation, Update Record separation, Read-to-SNOMED and terminology-service governance, a reusable standards-conformance evidence request pattern, and implementation-proof limits.	Wiki synthesis backed by official NHS, DHSC, PRSB, ICO, standards-directory, NHS API/service, TRUD, HL7, SNOMED, NHSBSA, regional terminology-service, and codelist-management sources	High as an internal navigation and due-diligence aid; not supplier conformance or customer implementation evidence	The domain page routes proof questions and provides a reusable request model. It does not replace named source IDs, supplier-progress rows, PRSB conformance listings, product documentation, safety artefacts, GP2GP route evidence, terminology-service deployment proof, mapping validation, or customer deployment evidence.	Add product/version documentation, current conformance rows, validation-scope packs, terminology package/version evidence, local-code governance artefacts, supplier responsibility matrices, and customer deployment packs for specific standards claims.
Read Version 2 and CTV3 are retired or deprecated for active NHS England clinical content management; official Read / CTV3 to SNOMED CT migration artefacts exist, but generic Read Version 2 to SNOMED CT mapping tables are static after the final April 2020 TRUD release and should be treated as migration / analytics aids requiring source-code provenance, map-version handling, and clinical review. Current coded clinical and medicines data should be handled through SNOMED CT UK Edition, dm+d, NHS England Terminology Server / FHIR terminology resources, and governed local CodeSystem / ValueSet / ConceptMap handling for non-standard or extension codes.	Official NHS England Digital, TRUD, NHS Standards Directory, NHSBSA, HL7, SNOMED International, regional terminology-service, and OpenSAFELY / OpenCodelists sources plus wiki synthesis	High for standards and mapping model; not product/deployment proof	Mapping artefacts, Terminology Server availability, and examples such as OneLondon, NHS Scotland, Australia NCTS, and OpenCodelists do not prove any InterSystems product or customer deployment has implemented a terminology service, loaded specific releases, validated local mappings, or completed safety/governance assurance.	Add deployment-specific source terminology releases, Read / CTV3 map versions, SNOMED CT UK Edition and dm+d package evidence, local CodeSystem / ValueSet / ConceptMap artefacts, terminology-service architecture, clinical validation, inactive-code handling, provenance design, DCB0129/DCB0160 where applicable, and customer deployment proof.
The Requesting Adapter bridges a receiving FHIR-oriented GP system to a legacy HL7 GP2GP sender; standards, catalogue maturity and software versions are separate facts.	Official catalogue, standards and repository documentation	High for documented roles; bounded for current release and deployment	No current image digest/HEAD or named deployment verified; requesting catalogue still development-labelled.	Supported build and supplier-specific assurance statement.
The sender must check that PDS names the requesting practice as current GP before releasing the GP2GP EHR; a mismatch requires NACK 19. Separating the adapter call from the registration update does not remove this check.	S94 Step 10 and documented adapter API	High for specified protocol; not live supplier verification	An adapter 202 response is not record-release success; an existing registered-requester resend is distinct from third-party read access.	Named sender/build acceptance test in an approved test environment when designing an implementation.
GP2GP FHIR depends on GP Connect migration operations; its current solution assurance follows R9.	Official standards, roadmap and onboarding guidance	High for documented dependency and route	Component assurance, effective standards and MI reporting do not establish a complete live GP foundation solution.	Agreed supplier assurance toolkit, role split and acceptance evidence.
Receiving-system clinical controls, mapping limits and restricted-data handling must be assessed beyond HTTP success.	Current requirements, historical incorporated specification and implementation documentation	High for documented responsibilities; not an execution test	Clinical data fidelity, defaults, placeholders and redactions remain release/receiver specific. Header, timing and retention wording conflicts are unresolved.	Contract clarification and source-to-import/onward-transfer validation against a pinned build.
Live ORC and Medicus GP2GP workflow evidence do not identify the NHS Requesting Adapter's deployed build or an InterSystems GP2GP role.	Official service and supplier workflow documentation	High for stated adjacent functions; boundary for adapter attribution	ORC routing and specific adapter deployment remain unverified.	Named deployment architecture, runtime inventory and NHS/customer acceptance evidence.
GP2GP is a GP-practice record-transfer workflow; its England FHIR implementation reuses GP Connect migration operations without inheriting ordinary consumer assurance. It adds electronic movement of GP records when a patient changes practice; England has NHS England service/API/Standards Directory evidence, Wales has DHCW primary-care GP2GP evidence, Scotland has NHS Scotland / NSS GP record-transfer evidence for within-Scotland electronic moves plus cross-UK paper fallback, and Northern Ireland GP IT Modernisation material includes GP2GP as an electronic notes/records transfer objective. Current public evidence found no InterSystems GP2GP implementation, GP2GP adaptor, or complete DSIC GP foundation-provider proof.	Official NHS England, DHCW, NHS Scotland / NSS / SCIMP, BSO / HSCNI, DSIC, and Standards Directory evidence plus wiki synthesis	High for GP2GP / record-transfer route definition and four-nation boundary; low/no public support for InterSystems implementation	GP2GP is adjacent to PDS, NHAIS, Spine/MHS, registration, DSIC foundation capability, and migration, but adjacency does not prove HealthShare, Health Connect, IRIS for Health, EMPI, Provider Directory, or GP Connect support. Northern Ireland Caché / NHAIS licensing is a separate GP-registration infrastructure fact, not GP2GP proof.	Product/version evidence, supplier role split, GP2GP HL7 V3 / Spine / FHIR-adaptor scope, conformance/onboarding evidence, customer deployment proof, migration/cutover pack, clinical-safety case, DSA/DPIA, and operating RACI.
The UK legal and professional position on recording healthcare information and healthcare delivery is layered: UK GDPR and DPA 2018 govern personal data relating to identifiable living people, including special-category health data; PECR governs electronic communications and storage/access technologies; common law confidentiality, Caldicott, and NHS Act 2006 section 251 govern confidential patient information; Health and Social Care (National Data Guardian) Act 2018 provides statutory National Data Guardian governance context; professional regulators require clear, accurate, prompt, attributable, secure records; England CQC-registered providers must keep secure, accurate, complete, contemporaneous records and candour records; nation-specific records-management codes and public-records frameworks govern retention, disposal, archive, transfer, and records-management discipline; AHRA / NI Order govern deceased-record access; and digital standards add terminology, provenance, clinical-safety, and information-standard obligations.	Primary legislation, regulator guidance, professional standards, NHS/devolved records-management guidance, public-records / archival guidance, terminology / mapping standards, and wiki synthesis	High for the assurance model; not legal advice or implementation proof	Duties vary by jurisdiction, profession, provider type, public-authority status, record type, direct-care versus secondary-use purpose, terminology release / mapping model, and local deployment workflow. The National Data Guardian Act supports governance authority context; it is not product or supplier conformance proof. PECR is not the general clinical-record law; it applies where electronic communications, cookies, storage/access, marketing, or communications-service privacy are engaged. Public-records law, AHRA, FOI, and AMRA are not interchangeable access routes.	Add deployment-specific legal basis, special-category condition, confidentiality route, PECR controls where applicable, National Data Guardian / Caldicott governance mapping, retention/archive/transfer route, living SAR and deceased-record request procedures, amendment/export/search procedure, source terminology package/version evidence, access-control/audit design, and local professional workflow evidence.
The healthcare-recording legal alignment model is a separate synthesis for record creation and maintenance: a deployment must prove it can lawfully and professionally create, update, preserve, share, correct, retrieve, audit, retain, archive, transfer, and dispose of healthcare records before the wiki treats record handling as supportable.	Wiki synthesis from primary legislation, regulator guidance, professional standards, provider-governance guidance, records-management codes, public-records / archival sources, terminology / mapping standards, and digital-standards sources	High as a general assurance model; not legal advice, product conformance, or deployment proof	The model is general and must be translated to the actual workflow, nation, provider type, public-record status, record type, supplier role, direct-care or secondary-use purpose, and terminology/source-code handling. It does not prove DSIC, GP Connect, HealthShare, Health Connect, DMICP, devolved-nation, patient-facing, analytics, AI, or terminology-service deployment compliance by itself.	For each deployment, add workflow design, lawful basis and Article 9 condition, confidentiality route, PECR assessment where relevant, Caldicott / National Data Guardian governance mapping, professional workflow evidence, records-management schedule, public-record / archive-transfer handling where relevant, source-code provenance, terminology release/mapping evidence, provenance/audit design, DCB0129/DCB0160, supplier RACI, and local assurance artefacts.
Public-records law, deceased-record access, public-information access, and medical-report access are adjacent but distinct healthcare-record routes: public-records statutes and archive bodies govern public-sector records management, preservation, selection, transfer, and custody; Access to Health Records Act 1990 and the Northern Ireland Order govern deceased health-record access; living-patient access remains under UK GDPR / DPA subject access; FOIA / EIR routes do not override personal-data or confidentiality protections; and Access to Medical Reports Act 1988 is a specific employment/insurance medical-report route.	Primary legislation, official archive/public-records guidance, regulator guidance, records-management codes, and wiki synthesis	High for route separation; not legal advice or implementation proof	Exact public-record body status, transfer route, place of deposit, record-set retention, AHRA requester entitlement, FOI exemption handling, and AMRA applicability are organisation- and record-specific.	For deployments, add local records-management policy, archive/transfer procedure, SAR procedure, deceased-record access procedure, FOI/EIR procedure, AMRA procedure if relevant, redaction/exemption workflow, correspondence record, and audit evidence.
Healthcare-record source-layer labels now have a canonical routing model: repeated table labels such as GMC, NMC, HCPC, GPhC, CQC, NICE, PRSB, provider governance, data-protection rights, DSA/DPIA, Caldicott, candour, records-management code, NHS information standards, terminology, and DCB0129/DCB0160 clinical safety should resolve to maintained source-layer pages or sections rather than remaining unexplained acronyms.	Wiki synthesis from regulator, professional, standards, terminology / mapping, records-management, clinical-safety, and public-records/access-route sources	High for navigation and evidence discipline; not a substitute for Source Register provenance	The source-layer map explains reusable evidence layers. It does not replace source IDs, external source review, legal advice, local implementation proof, terminology package evidence, or supplier/customer artefacts. Dense register rows should remain source-ID-first unless the row is defining a route or synthesis boundary.	Continue linking visible synthesis tables to canonical source-layer pages where labels recur or affect decisions; avoid creating new pages for one-off labels.
England health and adult social care digital-recording standards have a statutory chain: Health and Social Care Act 2012 section 250 provides the information-standard base; Health and Care Act 2022 amendments move applicable standards from "have regard" toward mandatory compliance and monitoring/enforcement; DUAA 2025 section 121 / Schedule 15 extends information-standard analysis to IT, IT services, and information-processing service providers used or intended for health/adult social care in or in relation to England.	Primary legislation, official NHS/DHSC/ICO guidance, and wiki synthesis	High for statutory-chain interpretation; implementation proof remains standard and deployment specific	The chain identifies how standards can apply; it does not identify any InterSystems product, supplier, or deployment as compliant. Wales, Scotland, and Northern Ireland should not be described as DSIC/DUAA section-121 compliant without a future official source.	Map each claim to named NHS Standards Directory entries, DSIC/GP Connect/onboarding artefacts, clinical-safety standards, supplier role, product/version, and customer deployment evidence.
The InterSystems Standards Product Map supports product capability and standards-positioning analysis, but product-page, documentation, or conformance-listing evidence should remain separate from current NHS assurance, onboarding, validation-scope, presentation/access configuration, AI-adjacent governance, and customer deployment proof. Health Connect, IRIS for Health, FHIR Services, HealthShare Unified Care Record, HealthShare Clinical Viewer, and HealthShare / PRSB CIS now have explicit high-risk row audits.	Wiki synthesis backed by vendor product pages, technical documentation, PRSB standards-body records, vendor AI material, and deployment-context DPIA evidence	High for internal evidence-handling boundary; not implementation proof	Product documentation, conformance listings, AI launch material, and historical deployment clues can support mechanics, plausibility, or named conformance facts, but proof of local compliance, access-control design, safety/governance, or deployment needs register, supplier-progress, standards-body scope detail, assurance, procurement, customer, or deployment artefacts.	Add current conformance rows, validation-scope packs, customer deployment packs, SSO/RBAC/audit evidence, clinical-safety packs, and supplier-responsibility matrices where product standards or access claims are used in assurance.
HealthShare AI Assistant is positioned as a generative-AI capability operating within HealthShare Clinical Viewer and the Navigation Application, with source traceability, configurable data profiles, RBAC, and audit tracking claims; InterSystems also publishes sample deployment configuration artefacts and product-term boundaries for AI Model Services.	Official vendor launch news, product terms, AI guidance, official sample repository, and a vendor-published customer AI case story	Moderate-high for vendor launch positioning, public sample artefact boundary, and AI Model Services boundary	The sample repository and terms support deployment artefact/runtime-service existence but do not independently validate UK deployment, clinical-safety case, customer-specific model choice, prompt governance, or runtime terms. Healthix is US-specific and vendor-published.	Add UK product documentation, clinical-safety/governance material, model/prompt-control detail, and customer evidence.
Health Connect offers managed-cloud and self-managed deployment. Its integration functions include high-volume transaction support, process management, monitoring, and support for standards including HL7 v2, HL7 FHIR, DICOM, IHE profiles, APIs, cloud-based data exchange, cloud connectivity, common healthcare standards in Health Connect Cloud, and InterSystems cloud-service deployment mechanics. The 2026-06-20 product-map audit keeps this capability evidence separate from current NHS conformance, onboarding, deployment, and managed-service assurance.	Official vendor product page, cloud-services documentation, and cloud-hosted services overview	High for product positioning and cloud-service boundary; boundary for NHS implementation proof	Customer-specific service levels, UK hosting region, regulated-hosting details, contract terms, GP Connect/MESH/ITK/ITK3 onboarding, conformance rows, and deployment artefacts still need standards-body, NHS, contract, or customer documentation.	Add current conformance/onboarding evidence naming product/version plus customer-specific commercial, UK-region, trust/security, safety, and customer architecture evidence.
Health Connect documentation lists standards including FHIR, HL7 v2/v3, IHE XDS.b/XCA/PIX/PDQ/MHD, CDA/C-CDA, DICOM, and X12, and describes built-in FHIR, HL7 v2, C-CDA, SDA, and CDA transformation patterns.	Official product documentation	High for technical transformation evidence	Does not prove a specific customer mapping, clinical-safety case, or local data-quality result.	Add implementation-specific mapping/test artefacts and current transform coverage.
TrakCare is positioned as a flexible EHR/healthcare information system with unified UI/code/data platform and built-in interoperability capabilities.	Official vendor product page	High for product positioning	Product availability is outside the United States, but local modules and deployment models require confirmation.	Add current regional availability and module documentation.
Public PHC/community-health TrakCare evidence exists outside the UK, with support from Gateway Health's Australian community-health implementation and customer-side annual-report / CEO corroboration, Nexus Primary Health provider-level evidence in Victoria, historical and contemporary sector evidence for Victorian community-health TrakCare use, official Chilean SSMS APS / referral-workflow evidence plus current SSMS-network hospital, public-account, procurement, municipal-health, and direct InterSystems Chile supplier context, reported DHAMAN primary-healthcare-centre and outpatient-care evidence with primary-source network context, and historical Qatar primary-care clinic evidence.	Vendor launch page, customer annual report, customer executive social post, vendor case study, sector policy paper, provider-level vendor/trade evidence, official Chilean health-service, hospital, procurement, municipal-health, purchase-order, and procurement-data mirror sources, trade/press-release material, DHAMAN official network page, academic article, and current PHCC boundary sources	Moderate-high for Gateway Health, Victoria, and Chile evidence; moderate for DHAMAN; historical only for Qatar	Gateway's formal customer publication is still missing for the 2026 go-live; Nexus is provider-level but historical 2019 evidence unless current provider status is found; Victoria's contemporary source is a sector paper rather than a government system inventory; newer Chile sources support SSMS workflow relevance, hospital context, and direct InterSystems Chile supplier context but not named current El Bosque APS live status or Chile-wide deployment, and the mirror-reported 2026 SSMS direct award still needs official Mercado Publico detail-link validation; DHAMAN's official site confirms current PHC/hospital network scope but does not name TrakCare; current PHCC sources do not support a current Qatar TrakCare claim; none of these establish UK applicability.	Add formal Gateway Health go-live evidence, current Nexus or Victorian Government / provider-level TrakCare scope, named El Bosque / SSMS APS live-status evidence, official SSMS direct-award detail-link validation, and DHAMAN primary source naming TrakCare.
Northern Territory Acacia uses InterSystems TrakCare, but the August 2026 parliamentary inquiry limits completed scope to read-only records and patient administration; remote/urban primary-care rollout remains deferred.	Official NT programme pages and parliamentary inquiry report	High for product basis and dated inquiry findings	Older whole-programme ambition is not completed PHC deployment; recommendations do not prove government implementation.	Assess government response, functional-group completion and operational outcomes before relying on broader scope.
IntelliCare combines EHR functions with GenAI and ambient documentation on TrakCare and IRIS for Health foundations.	Official vendor product and regulatory material	High for positioning; boundary for regulatory scope	Product features and EU MDR statements do not prove local availability, deployment or clinical-safety approval.	Obtain release/module, certificate/intended-use and deployment-specific AI/data-flow evidence.
InterSystems FHIR Services are positioned as managed FHIR computing infrastructure to help organisations use FHIR data without building their own infrastructure, with public documentation for FHIR Server cloud deployment, supported operations, OAuth/security configuration, Network Connect, cloud-service deployment settings, and managed-service positioning. The 2026-06-20 high-risk audit keeps managed-service mechanics, FHIR package/profile support, and cloud settings separate from NHS profile conformance, customer tenancy, healthcare assurance, and deployment governance.	Official vendor product page and official cloud-services documentation	High for product positioning and technical documentation; boundary for customer/NHS assurance	Named hosting region, customer-specific tenancy model, commercial terms, service levels, healthcare compliance guarantees, NHS/UK Core profile configuration, test results, safety artefacts, and customer deployment evidence are still not established.	Add customer-specific managed-service hosting, tenancy, compliance, service-level, commercial, profile-validation, assurance, and customer documentation.
InterSystems FHIR Server is documented as a cloud SaaS FHIR repository and as an out-of-box FHIR server architecture using the Resource Repository as the default storage strategy, with customization, optional production-routing patterns, OAuth security configuration, secure cloud connectivity options, and cloud-service deployment settings.	Official cloud-services and product documentation	High for technical architecture	Does not establish named UK tenancy, managed-service terms, licensing, contract service levels, customer-specific security controls, or customer deployment.	Add customer-specific UK hosting/security/service-level docs and customer evidence.
InterSystems FHIR endpoint customization supports FHIR packages, profiles, conformance resources, multiple packages per endpoint, and CapabilityStatement discovery, while documentation states both that profile conformance is not automatically verified just because a resource declares a profile and that profile validation is currently designed for FHIR R4.	Official cloud-services documentation	High for profile/package behaviour and validation boundary	Does not prove any specific UK, NHS, or GP Connect profile is installed, assured, or actively validated.	Add implementation-specific profile/package and validation configuration evidence.
Bulk FHIR Coordinator mediates bulk-data export interactions between clients and FHIR resource server endpoints and can be configured for authentication, FHIR server access, storage, ndjson output, direct ingestion, and credentialed cloud-FHIR interactions.	Official cloud-services and product documentation	High for technical role and configuration concepts	Does not prove product licensing, customer use, scale, deployment security model, or governance in a named deployment.	Add licensing, operational, and customer implementation evidence.
InterSystems OMOP is documented as a cloud SaaS service that transforms FHIR data in cloud storage into a cloud-hosted OMOP CDM repository; documentation maps 14 FHIR resources to 10 OMOP tables and sits within InterSystems cloud-service deployment mechanics.	Official cloud-services documentation	High for service positioning, cloud-service shape, and mapping scope	Does not establish terminology completeness, data-quality outcomes, pseudonymisation, UK research governance, or customer use.	Add security, terminology, data-quality, and customer evidence.
InterSystems UK positions HealthShare and TrakCare as NHS/government connected-care and EPR solutions.	Official vendor industry page	High for vendor positioning	Does not prove current NHS deployment breadth.	Add NHS procurement, trust, and programme sources.
InterSystems claims UK NHS Interoperability Toolkit accreditation for its ITK implementation, and current IRIS for Health documentation still describes the 2010 ITK accreditation context; NHS England's ITK conformance-process and conformance-catalogue routes exist, but the 2026-06-20 current-source recheck did not find a current public InterSystems, HealthShare, Health Connect, or IRIS for Health row in the rendered ITK catalogue or targeted public search.	Official vendor standards/documentation pages plus NHS conformance-process, conformance-catalogue, and compliance-catalogue boundary sources	Moderate for vendor claim; boundary for independent current accreditation	Current public non-vendor evidence was not found in this pass. The ITK conformance catalogue is useful but historical after 31 May 2026, and the NHS Solution Assurance compliance catalogue explicitly excludes ITK Accreditation even where it names Healthshare rows.	Add NHS or standards-body accreditation row/certificate source naming product/version, certificate type, message/profile scope, date, and status.
North West London ICS used HealthShare Health Connect Cloud as a cloud interoperability service connecting multiple acute trusts and serving a stated population of 2.1 million; North West London acute-trust recruitment evidence separately supports Health Connect / TIE technical context.	Official vendor customer success story, independent trade report, AWS partner blog, independent TIE list, and official acute-trust recruitment evidence	Moderate	Digital Health and AWS corroborate the partnership narrative, 6B lists several NW London trust TIEs, and Trac recruitment evidence supports trust-level Health Connect interface/TIE work. These are still not official ICB/customer programme or procurement sources for current ICS-level cloud scope, service levels, or outcomes.	Add North West London ICB, trust board, contract-award, procurement, or customer programme source naming the current operating model and supplier role.
eConsult selected InterSystems IRIS for Health for interoperability and integration across its platforms in an NHS triage context; current InterSystems material also says eConsult, part of Huma, chose Health Connect Cloud for NHS integration, and current public Digital Front Door signals name InterSystems & eConsult in NHS urgent and emergency care.	Vendor success story, customer-side press release, marketplace listing, current company acquisition/platform context, current InterSystems HCC partner evidence, awards/public deployment signals, and public procurement notice evidence for eConsult eTriage	Moderate-high for historic selection and current InterSystems role signal; high for eTriage service/procurement scope; boundary for current live architecture	Current evidence still lacks a Huma, NHS, customer-approved, or technical architecture pack confirming product versions, component responsibilities, clinical-safety ownership, DCB0129/DCB0160 artefacts, interface specifications, service levels, and live site-by-site scope. Public procurement notices support eConsult Digital Front Door scope but do not name InterSystems.	Add current Huma/eConsult/NHS/customer technical or procurement source naming product versions, interface architecture, safety artefacts, and deployment scope.
North Tees and Hartlepool NHS Foundation Trust used InterSystems TrakCare as its EPR platform, with trust strategy, quality-account, board, and trust news sources naming TrakCare, describing EPMA/ePMA2, eObs, sepsis, medication-safety, interface, customer-reference, and TrakCare-related digital programme work.	Vendor news plus trust strategy, quality-account, board, and news material	High for trust-side TrakCare use	Impact claims are not formal outcome evaluations; quantified benefits from award/communications material need independent evaluation before being treated as measured outcomes.	Add formal outcome evaluations and procurement/contract evidence.
West Midlands health and social care providers have started integrating cancer registry data into InterSystems HealthShare; UHB is named as project lead in vendor and independent trade reporting, and Birmingham/Solihull ICS separately describes the eMDT information-sharing project context.	Vendor news, local programme page, and independent trade report	Moderate	No official UHB or West Midlands Cancer Alliance source currently names the HealthShare component; current live status and outcomes remain unvalidated.	Add UHB, West Midlands Cancer Alliance, and affected-trust publications.
The MERIT project involved Birmingham and Solihull Mental Health NHS Foundation Trust plus three other West Midlands mental health trusts using an integrated care record / HealthShare-based data-sharing approach for crisis care across more than 3 million patients. BSMHFT FOI records support that the MERIT system was provided by Intersystem and list an Intersystems HSSF Contract for MERIT from 01/04/2021 to 31/03/2026; Black Country Healthcare FOI material separately lists MERIT as an InterSystems integrated care system with cross-trust PAS integrations and no replacement plans as of 2023.	Vendor resource plus BSMHFT and Black Country Healthcare FOI records	Moderate-high for supplier/contract/integration trail; moderate for outcomes	Current post-31 March 2026 status and operational outcomes need validation.	Add current BSMHFT/MERIT status source and outcome evidence.
The Royal Orthopaedic Hospital selected InterSystems as EPR partner; customer-side ROH pages state selection on 23 October 2025 and contract signature on 13 March 2026; Contracts Finder OCDS data records an EPR award to InterSystems Corporation valued at GBP 13,147,716 for 2026-02-26 to 2036-02-25; InterSystems identifies the intended move as TrakCare EPR; and ROH medicines-strategy evidence adds planning context for an integrated EPR supporting closed-loop medicines, DMS referrals, EPS prescriptions, reporting, and patient-facing navigation.	Vendor news, customer trust news pages, official procurement API record, and official ROH strategy PDF	High for selection, contract, supplier, value, term, and adjacent implementation-planning context; outcomes not established	The medicines strategy does not name InterSystems or TrakCare and does not prove go-live status, implementation scope, clinical-safety approval, or outcomes.	Add programme update, go-live announcement, clinical-safety material, and post-implementation evidence.
GP Connect supports approved direct patient care and a bounded medical-examiner use case for reviewing deceased patients' records within 28 days after death through approved supplier systems. The service page checked 8 September 2026 closes new-developer GP Connect onboarding for Update Record, Send Document and Appointment Management; existing consumer suppliers can still onboard end users.	Official NHS service/API and medical-examiner guidance	High for stated service purpose and onboarding boundary	Effective DSIC standards, production status and older onboarding invitations do not establish an open new-developer route or InterSystems deployment.	Confirm the current supplier/product/use-case route with the service owner and obtain implementation-specific assurance evidence.
Summary Care Record is an NHS England direct-care summary-record service derived from GP records and accessed by authorised staff through national or local care-record access routes; it is not GP Connect, not a full GP record, not the same as a shared-care-record platform, and not InterSystems implementation proof by itself.	Official NHS England Digital SCR and NCRS service pages	High for England direct-care summary-record context	SCR establishes an England national-service baseline but does not prove product role, local configuration, supplier assurance, or customer deployment.	Pair with NCRS/local access-route evidence, supplier role, access-control, audit, safety, DSA/DPIA, and deployment artefacts before using in implementation analysis.
"NDR" is an acronym collision. NHS England public sources include the National Document Repository for digital patient documents and separate commissioning-flow material using centralised national data repository language; Wales uses National Data Resource / Care Data Repository for DHCW national data-platform work.	Official NHS England Digital, NHS England, DHCW, and Social Care Wales pages	High for terminology split; not implementation proof	This does not identify one UK-wide NDR platform and does not prove any InterSystems role.	State the administration and source-defined NDR meaning before making any architecture or supplier claim.
NHS England's Federated Data Platform is an operational/data platform with local and national components including the National Data Integration Tenant; it is distinct from SCR direct-care summary access and from the emerging Single Patient Record programme.	Official NHS England FDP programme, privacy/governance, uptake, and contract-context pages	High for FDP / NDIT programme context	FDP evidence does not prove a direct-care record viewer, SPR delivery model, or InterSystems supplier role.	Add official NHS, procurement, customer, supplier-approved, or architecture evidence before linking InterSystems to any FDP work.
NHS England's Single Patient Record is a current programme and future record-access direction, not a live implementation proof. The public SPR page says prototype testing included InterSystems, Oracle Health, and Orion Health shared-care-record suppliers and that this does not guarantee future involvement.	Official NHS England SPR page and GOV.UK Health Bill context	High for programme direction and prototype signal; boundary for award/deployment claims	Prototype participation is not procurement, conformance, implementation, or customer deployment evidence.	Track the SPR full business case, standards set, procurement/award route, supplier roles, product/version scope, DSA/DPIA, clinical-safety, and live deployment evidence.
InterSystems stated in 2019 that NHS FHIR-profile components for Health Connect included support for GP Connect and that Health Connect supported the FHIR version used by GP Connect and Transfer of Care at that time; current Health Connect Cloud documentation supports the broader standards/integration-engine boundary but does not confirm current GP Connect conformance.	Official vendor news page and official cloud-services documentation	Moderate for GP Connect-specific vendor claim; high for current Health Connect Cloud standards/cloud-service boundary	The GP Connect-specific evidence remains dated 2019; current documentation found in this pass supports healthcare standards generally, not a current GP Connect assurance claim.	Add current GP Connect-specific Health Connect documentation and NHS conformance evidence.
InterSystems stated in 2025 that HealthShare 2024.1 achieved PRSB Core Information Standard Level 2 conformance and that PRSB validation included support for GP Connect alongside FHIR, HL7 v2, DICOM, and IHE profiles.	Official vendor news page	Moderate-high	Vendor-published announcement; certification should be checked against PRSB or NHS records.	Add PRSB certification record and current HealthShare documentation.
PRSB's conformant partner register and Core Information Standard page list InterSystems Healthshare as Core Information Standard Version 2, Level 2 conformant, valid until 17.06.2028. The 2026-06-20 high-risk audit keeps that strong conformance fact separate from validation-scope detail, every HealthShare component, GP Connect/FHIR/HL7/DICOM/IHE support, DSIC compliance, local role views, clinical safety, and customer deployment evidence; the 2026-06-21 checklist audit keeps the generic request pattern in the standards domain and the PRSB page focused on PRSB-specific assurance scope.	Official PRSB register and standards page	High for PRSB conformance listing	This confirms PRSB Core Information Standard conformance, not every claimed interoperability capability in every deployment.	Add PRSB certificate/scope detail, product-level technical conformance documentation, and implementation-specific evidence only when the PRSB fact is being used for assurance.
PRSB is a UK health and care record-content standards body. Its standards define information content for shared care records, transfer of care, person-authored information, care planning, pharmacy, maternity, child health, specialty pathways, provenance, and related settings, while technical transport/API implementation remains a separate layer.	Official PRSB organisational, guidance, catalogue, and standards-family pages	High for PRSB standards taxonomy and content/technical boundary	PRSB standards relevance does not prove a named system has implemented any standard unless a conformance or implementation source says so.	Add implementation-specific PRSB mappings and conformance records where needed.
PRSB conformance is a supplier/product assessment process using conformance packs, self-assessment, assessor review, test cases, and quality-mark levels.	Official PRSB conformance guidance	High for conformance-process description	Process guidance is not the same as proof of conformance for a named product.	Pair each conformance claim with a PRSB register or certificate.
PRSB states that Core Information Standard Version 3.0 is in review and final approval, while this wiki treats Version 2.01 / Version 2 conformance as the current published evidence point until the next release is published.	Official PRSB standard, update, and support pages	High for version/status boundary	A pending release does not supersede the existing InterSystems Healthshare conformance to CIS Version 2.	Recheck PRSB/NHS Standards Directory after CIS v3 publication.
PRSB member and CISS transition statements say NHS England funding / the CISS contract ends in December 2025 while NHS England establishes a new standards operating model; PRSB says it will continue standards and supplier conformance work, and Digital Health reports a revised 2026 funding model.	PRSB official statements plus trade press follow-up	High for PRSB-stated contract/funding caveat; moderate for trade-press future funding model	This is a stewardship and future-maintenance caveat, not evidence that published PRSB standards or current conformance listings are withdrawn.	Recheck PRSB, NHS England, and NHS Standards Directory pages before relying on future release ownership or conformance-process details.
NHS England's broader standards stance remains active: information standards are legal requirements, DAPB/DAB governance remains the approval route, current standards collections and the NHS Standards Directory remain published, and the Health Bill proposes transfer of NHS England digital/data functions to the Secretary of State through the restructured DHSC.	Official NHS England Digital and GOV.UK policy/fact-sheet pages	High for current public standards-governance and Health Bill direction	This does not prove the future PRSB role; it supports a central NHS England/DHSC standards inheritance model rather than cessation of standards.	Recheck after Health Bill enactment and after any NHS England/DHSC standards-operating-model publication.
The NHS Standards Directory contains directly relevant standards-directory entries for FHIR/UK Core, GP Connect APIs and dependency entries, MESH, ITK3, PDS/events, GP2GP/NHAIS, SNOMED CT, dm+d, clinical safety, transfer of care, Core Information Standard, life-stage content, DICOM, and pathology.	Official NHS Standards Directory pages	High for standards-surface mapping	Standards Directory presence shows NHS-recognised standards context, not InterSystems conformance or a live local implementation.	Expand item-level pages only when a product claim or deployment needs standard-specific proof.
Digital Services for Integrated Care is NHS England's England-specific digital primary-care model for assured GP and integrated-care digital services, evolved from GP IT Futures and organised around frameworks, the Buying Catalogue, capabilities, standards, assurance, and procurement routes.	Official NHS England Digital, NHS England operating-model, DSIC Confluence, buyer-guide, and procurement notice sources	High for DSIC scope and current operating-model framing	Public DSIC Confluence access can be partial; framework names and procurement routes are versioned and should be rechecked before procurement use.	Track Digital Primary Care replacement framework award and catalogue updates.
NHS England Digital Primary Care is the wiki parent domain for DSIC, GP Connect, GP foundation capabilities, national-service dependencies, procurement/migration, and InterSystems HealthShare compliance mapping.	Official NHS England Digital, NHS England operating-model, DSIC Confluence, and GP Connect sources	High for domain grouping; not a separate NHS product or programme name beyond the wiki synthesis	The parent page is a wiki synthesis layer and should not be cited as an official NHS brand without source wording.	Keep the parent aligned with DSIC and GP Connect source changes.
The DSIC GP foundation capability model covers core GP software/service components such as patient information maintenance, appointments, consultation, prescribing, referral, document, task, reporting, scanning, citizen/patient-facing services, and shared/integrated care capabilities including personal health record and unified care record contexts.	Official operating-model and DSIC capability pages	High for visible capability taxonomy; moderate for full capability detail because anonymous Confluence access may hide material	Capability presence does not mean a supplier or product is accredited for it.	Capture structured capability pages and catalogue entries for suppliers in scope.
The DSIC Capability-to-Standard Crosswalk provides a structured wiki map from GP software/service components to national-service and standards checks, including explicit PDS and ODS/SDS treatment after the identity-directory pass, but it remains a synthesis of public DSIC/NHS sources rather than an official assurance artefact.	Wiki synthesis backed by official NHS/DSIC and standards sources	High as an internal navigation and due-diligence aid; not supplier conformance evidence	Needs exact DSIC page capture and supplier-specific evidence before procurement-grade use. ODS/SDS dependency evidence does not prove Provider Directory implementation.	Add supplier rows when InterSystems or partner entries are found.
DSIC capability compliance is tied to national-service and standards dependencies including PDS, NHAIS, GP2GP, SCR, GP Connect, GPAD, GPES, MESH/MNS, eMED3, Yellow Card, EPS, e-RS, NHS login, ITK, National Data Opt-Out, NEMS, and related NHS England services.	Official DSIC interoperability relationship pages and NHS developer standards/service guidance	High for NHS-side dependency mapping	The exact set of dependencies varies by capability, role, and supplier service.	Keep the local crosswalk aligned with DSIC page changes and add supplier rows when evidence is found.
NHS England's current GP digital-services operating model says the DSIC catalogue of frameworks, or successor, is the default route for procuring digital services for general practice and PCNs, and that foundation solutions must be accredited through DSIC catalogue standards.	Official NHS England operating model, buyer guidance, and procurement notice	High for current procurement route framing	Procurement route and framework status are time-sensitive; GP IT Futures continuity and replacement-framework status need monitoring.	Recheck procurement notices and catalogue guidance at each commercial pass.
The clinical system migration guide makes DSIC-adjacent compliance operational: GP clinical-system change needs planning, data migration, national-service continuity, training, post-go-live support, and migration between established foundation suppliers rather than treating migration as a simple software replacement.	Official NHS England Digital migration guide	High for migration lifecycle guidance	The guide is generic and does not validate any specific supplier migration tooling.	Pair with supplier migration pack, safety case, and local cutover evidence for named deployments.
InterSystems HealthShare can support DSIC-aligned integrated-care architecture through UCR, Clinical Viewer, EMPI, Provider Directory, Health Insight, Health Connect, IRIS for Health, and FHIR Server components, but current public evidence does not prove HealthShare alone is a complete DSIC GP foundation clinical system. The Provider Directory follow-up pass adds stronger public product-feature / version evidence and a legacy Coordinate My Care usage signal, but not current DSIC assurance. The current UCP breadth check does not change that because public UCP sources now point to Better / Valida / London Care Record / UCP web portal routes rather than a current InterSystems Provider Directory role.	Official InterSystems product/docs, PRSB, NHS supplier-progress, NHS operating-model, DSIC capability/standards sources, partner case-study evidence, current UCP access/platform evidence, and UCP transition sources	High for InterSystems component relevance and Provider Directory public product-feature boundary; moderate for historical CMC component signal; moderate-high for current UCP access/platform boundary; boundary for DSIC foundation-system compliance	HealthShare PRSB CIS conformance, GP Connect supplier-progress row presence, Provider Directory product features, the legacy CMC signal, and current UCP access/platform sources are not full DSIC foundation-system accreditation or current Provider Directory deployment assurance.	Find DSIC catalogue/supplier entries or customer deployment artefacts naming InterSystems capability scope, especially NHS number/PDS, ODS/SDS, matching/stewardship, directory governance, synchronisation, audit, safety ownership, and current deployment artefacts for EMPI / Provider Directory roles.
The EMPI / Provider Directory identity-directory source pass found stronger NHS dependency evidence but not direct current HealthShare EMPI or Provider Directory implementation proof. PDS FHIR technical conformance creates local-copy sync, sensitive-record, invalid/superseded NHS-number, warning, back-office, and de-coupling requirements; ODS guidance creates organisation-code lookup, relationship, succession, validation, and local-synchronisation requirements; PDS integrated-products evidence names Intersystems HealthConnect 2020.1 for North West Anglia NHS Foundation Trust, not EMPI or Provider Directory. Provider Directory now has public evidence for data stewardship, source trust / survivorship, FHIR Plan Net and REST APIs, managed-service deployment, and a 2026.1 fix boundary; Coordinate My Care is a historical London signal that reportedly used Provider Directory for a clinician registry before CMC transitioned to UCP in 2022. Current UCP public evidence points to Better / Valida / London Care Record / UCP web portal / National Record Locator routes and does not name InterSystems or Provider Directory as the live platform, directory, or ODS/SDS owner.	Official InterSystems product pages, official NHS England Digital PDS/ODS service, API, conformance, and integrated-products pages, partner implementation evidence, current UCP access/platform evidence, and UCP transition evidence	High for national-service requirements, Provider Directory public product features, HealthConnect PDS row, and current UCP legacy boundary; moderate for historical CMC Provider Directory signal; boundary for current EMPI / Provider Directory implementation	National PDS/ODS evidence defines what an England identity/directory implementation must prove. Product-feature evidence is mostly US-regulatory and API-oriented. Historical CMC evidence is not current customer architecture, EMPI matching configuration, Provider Directory ODS/SDS mapping, DCB0129/DCB0160, local DPIA/DSA, or DSIC catalogue evidence. Current UCP evidence does not close that gap.	Seek current customer product/version, PDS FHIR onboarding, ODS/SDS mapping, matching/stewardship, directory-governance, sync/audit, safety-ownership, DSA/DPIA, DCB0129/DCB0160, and deployment artefacts before using EMPI / Provider Directory as assured implementation evidence.
Defence Medical Services is a PRSB member and public MOD healthcare organisation, but no public evidence in this pass showed a defence-specific PRSB standard or Programme CORTISONE PRSB conformance certificate.	Official PRSB member page and GOV.UK organisation page	High for DMS membership and public DMS scope; low/none for CORTISONE-specific conformance	DMS membership means PRSB stakeholder involvement, not product conformance. No further Defence information is expected in the current project context.	Treat Programme CORTISONE / UK Defence as contained unless a new primary source appears or the user explicitly reopens the trail.
NHS England Digital's GP Connect developer material separates GP Connect into Access Record, Access Document, Patient Facing APIs, Send Document, and Update Record capabilities, each with distinct API or messaging patterns.	Official NHS England Digital developer, API, service, and architecture pages	High	Capability availability and live use vary by supplier, care setting, onboarding status, and approved use case.	Add supplier-specific GP Connect assurance/progress records where relevant.
GP Connect Access Record Structured uses NHS infrastructure and controls including HSCN access, Spine Secure Proxy, local RBAC, JWT assertions, TLS MA, clinical testing, technical testing, and onboarding by approved use case.	Official NHS England Digital API catalogue page	High	This describes NHS API requirements, not whether a specific InterSystems deployment is assured.	Map InterSystems product documentation and customer deployments to these controls.
GP Connect Update Record has two evidence layers that must remain separate. Current NHS API evidence supports a controlled community-pharmacy structured write-back integration using MESH, ITK3, and FHIR STU3 payloads; the June service-facing snapshot is historical because its URL now returns 404. The current service closes new-developer onboarding for this route while existing consumer suppliers may onboard end users. The effective DSIC S102 v1.0.3 standard is listed across GP IT Futures, Tech Innovation, Community Pharmacy Clinical Services, and Digital Primary Care and requires both sender and receiver implementations. The broader catalogue applicability does not make Update Record a generic approved write-back route for DMICP or every GP Connect consumer.	Official NHS England Digital API/service pages and official DSIC standard page	High for the standard, dependency, and current assured-use boundaries	The DSIC standard defines catalogue roles and dependencies; it does not prove a DMICP/CORTISONE approved use case, InterSystems support, supplier onboarding, or a named deployment.	Add the approved use case, supplier role, current onboarding/assurance, product/version implementation, payload tests, clinical-safety/IG evidence, and customer deployment artefacts by route.
Contemporary NHS GP Connect roadmap evidence is distributed across supplier progress, utilisation snapshots, specification releases, historical Update Record service guidance, current service onboarding policy, NCRS roadmap/pilot material, NHS App roadmap material, and wider Single Patient Record / Connecting Care Records programme pages.	Official NHS England Digital and NHS England roadmap, service, supplier-progress, utilisation, and programme pages	High for NHS-side direction	These sources define NHS service direction and point-in-time supplier-progress/utilisation snapshots; they do not prove InterSystems implementation or local go-live.	Recheck supplier progress and roadmap pages regularly, then pair with InterSystems product documentation and customer-side deployment evidence.
The 3 September 2026 NHS supplier table retains HealthShare’s four populated structured-consumer cells; the IRIS middleware Send Document row recorded in June is absent on recheck.	Official NHS supplier table and structural HTML check, 2026-09-08	High for dated table contents; current IRIS status unconfirmed	Specification versions are not product versions. A missing row does not prove withdrawal or discontinued support; a populated row does not prove local deployment or complete capability coverage.	Resolve current IRIS status and named product/version, use-case, onboarding, safety and customer scope before using the historical row for assurance.
NHS England GP Connect material provides official national Medicus context: supplier-progress rows identify Medicus provider and consumer capability status, the service page edited 1 September 2026 says Patient Facing APIs are live with Medicus and Access Document is FoT ready, while the supplier table edited 3 September labels its Access document development. The earlier GP Connect DPIA names Medicus as a new NHS market entrant for GPs. Preserve this source-specific status discrepancy.	Official NHS England Digital service, supplier-progress, and DPIA pages	High for national GP Connect / Medicus evidence	This does not prove the West Midlands HealthShare integration route, local GP Connect/MESH/ITK3 onboarding, or customer deployment artefacts.	Add local West Midlands ICB/customer architecture, onboarding, DSA/NDSA adoption, DPIA, DCB0129/DCB0160, MESH mailbox, endpoint/certificate, and operating-model evidence.
GP Connect is currently NHS England service evidence, not UK-wide NHS capability evidence. Scotland, Wales, and Northern Ireland are evidenced through their own national digital-health, interoperability, portal, record-sharing, and procurement sources.	Official NHS England Digital, Scottish Government / COSLA, PHS, DHCW, Sell2Wales, DHCNI, Department of Health NI, and procurement sources	High for evidence boundary	This is a source-backed boundary, not proof that GP Connect could never be adopted outside England. Recheck if procurement or roadmap evidence changes.	Monitor Scotland, Wales, and Northern Ireland digital-health roadmaps for explicit GP Connect references.
NHS England Spine is a national infrastructure context that should be compared by function, not by name, when looking at devolved systems. The England baseline includes Spine, PDS, SCR, EPS, e-RS, SDS, GP Connect, MESH, the National Document Repository, and related API/service routes.	Official NHS England Digital service and technical pages	High for infrastructure baseline and stated national scope	The current Spine service includes Wales and the Isle of Man; Welsh EPS is a documented reuse case. Shared infrastructure does not establish shared service eligibility, APIs, DSIC status or InterSystems involvement.	Maintain a function-by-function crosswalk rather than forcing product equivalence.
Scotland's functional routes include ECS/KIS, SCI Gateway, CHI, NDP, ePharmacy and MyCare.scot; official June 2026 evidence advances MyCare from plan to national initial service availability.	Official NHS Scotland and Scottish Government sources	High for named services and dated MyCare rollout	National initial availability does not imply all planned features, GP Connect or InterSystems involvement.	Validate service-specific architecture and delivered features where the comparison is used.
Wales's closest GP Connect-like and Spine-like routes are Welsh GP Record, Welsh Clinical Portal, Welsh Clinical Communications Gateway, NHS Wales App, NDR/CDR, and the WDS/PDS relationship.	Official DHCW, Social Care Wales, and NHS England Digital PDS API sources	High for named services and PDS/WDS relationship; moderate for detailed architecture until DHCW technical sources are added	These are Welsh national routes, not NHS England GP Connect. Current InterSystems Wales evidence remains LIMS/TCLE.	Add richer DHCW technical material for WGPR, WCP, WCCG, CDR/NDR, PC EPS, and Shared Medicines Record.
Northern Ireland's closest GP Connect-like and Spine-like routes are NIECR, encompass, EpicCare Link, My Care, Health and Care Number, Digital Identity Service, NHAIS, and ePharmacy.	Official DHCNI, Department of Health NI, BSO, nidirect, procurement, and data-dictionary archive sources	High for named services and current encompass boundary; moderate for HCN archive definition and NIECR post-encompass transition	NIECR and ePharmacy need current technical detail; Caché / NHAIS licensing is not care-record or GP Connect-equivalent evidence.	Confirm post-encompass NIECR status and add technical sources for Digital Identity Service, HCN, EpicCare Link, and ePharmacy.
Scotland evidence supports a nation-specific interoperability reading around digital-health strategy, common standards, GP record transfer, InterSystems Edinburgh presence, broad TrakCare Patient Management System use across NHS Boards, NHS Shetland TrakCare ED / Ensemble evidence, and historical/current vendor TrakCare context; it does not currently prove GP Connect capability, live GP Connect use, or InterSystems GP2GP involvement in Scotland.	Official Scottish Government / COSLA strategy, NHS Scotland / NSS / SCIMP pages, InterSystems office pages, Public Health Scotland, NHS Shetland FOI, and vendor Scotland evidence	High for Scottish strategy, record-transfer, office, Public Health Scotland, and NHS Shetland facts; moderate for vendor programme/outcome claims	Public Health Scotland is a data-quality source, not a deployment inventory; TrakCare Patient Management System and TrakCare ED are source/local system labels for TrakCare in specific patient-management and emergency-department settings; vendor sources are partly historical; GP2GP / GP record-transfer sources do not name InterSystems; current national integration-platform and board-by-board status still need validation.	Add NHS Scotland / board publications, NSS material, contract registers, current integrated-care-record sources, and any supplier artefacts before making GP2GP or GP Connect product claims.
Wales evidence supports a nation-specific connectivity reading around DHCW FHIR / National Data Resource work, Welsh primary-care services including GP2GP and Welsh Clinical Communications Gateway, and all-Wales InterSystems LIMS / TrakCare Lab Enterprise evidence, including documented WCP booking and WRRS result interfaces; it does not currently prove GP Connect capability or InterSystems GP2GP involvement in Wales.	Official DHCW pages, NHS Wales board paper, Sell2Wales contract award, and vendor all-Wales TCLE announcement	High for Welsh national-service, board-paper, and procurement evidence; moderate for vendor-stated national scale	Evidence is LIMS/pathology and Welsh connectivity taxonomy, not general EHR, HealthShare, GP2GP implementation by InterSystems, or GP Connect evidence. Existing laboratory interfaces do not establish national-service ownership or completed interface migration.	Add DHCW technical docs, Welsh Clinical Portal / Care Data Repository material, GP2GP supplier evidence if it appears, and LIMS 2.0 implementation updates.
Northern Ireland evidence supports a nation-specific encompass / EpicCare Link / My Care reading, a GP IT Modernisation GP2GP objective, and a separate InterSystems Caché / NHAIS licensing fact: encompass is the regional single digital care record across HSC Trusts; GPs use EpicCare Link for read-only record viewing and limited actions; the dated FAQ excludes primary care; My Care excludes GP records, GP-arranged tests, pre-encompass historical data and social-care records; Caché underpins NHAIS applications used primarily for GP registrations; and BSO / HSCNI material identifies GP2GP as an electronic GP-practice records-transfer route. No TrakCare, HealthShare, Health Connect, GP2GP, or GP Connect InterSystems claim is supported.	Official DHCNI programme pages, Department of Health NI news, official procurement notice, official BSO / HSCNI GP IT material, and Rhapsody vendor boundary source	High for official Northern Ireland, GP2GP objective, and NHAIS Caché facts; moderate for Rhapsody vendor integration context	Caché / NHAIS licensing does not prove an InterSystems care-record or GP2GP deployment. Future primary-care inclusion may change the encompass boundary.	Recheck DHCNI roadmap, BSO/eTendersNI procurement, HSC Trust evidence, and GP IT Modernisation sources for future primary-care scope and any InterSystems involvement beyond NHAIS.
DMICP is an established Defence source-system baseline for the executive-summary connectivity question: official sources describe it as the Armed Forces electronic patient record system, an MOD digital primary healthcare record for most personnel leaving service since 2010, and an integrated primary Health Record plus pseudo-anonymised central data warehouse used for Defence primary healthcare and some MOD specialist care providers.	Official MOD/GOV.UK statistics background-quality report, official parliamentary answers, and vendor historical implementation context	High for DMICP baseline definition and rollout history; moderate for vendor implementation detail; boundary for current interface architecture	These sources do not expose the current DMICP extract/API design, source data model, full coding/free-text/scanned-record handling, migration route into CORTISONE, or Health Connect / HealthShare interface implementation. CGI material is vendor historical context, not current official architecture.	Add DMICP interface catalogue, source data model, extract/API capability, migration status, coding/free-text/scanned-record handling, mapping, data-quality controls, clinical-safety artefacts, and operational runbook evidence.
Programme CORTISONE is an MOD / DMS medical information services programme intended to deliver an integrated ecosystem with common/open standards, NHS interfaces across the four UK nations, an Integration Platform, EMPI, clinical portal, and integrated electronic healthcare record. In 2025, MOD said CORTISONE was stabilising current Medical Information Services / DMICP while introducing new capabilities, with procurement ongoing and rollout planned over the next two years. The later 23 January 2026 MOD announcement confirms the TPP EHR award, with benefits expected by 2027.	Official GOV.UK programme page, MOD programme vision, and official parliamentary answer	High for programme existence, intent, architecture themes, and current status signal	Vision/programme/status material does not prove full deployment, detailed architecture, or current live status of every capability.	Add current MOD programme delivery updates, technical architecture, rollout milestones, migration plan, and service catalogue.
Public evidence supports active DMICP replacement activity, but not a complete migration route: Defence said in 2018 that it was in the process of replacing DMICP; in 2025 it described CORTISONE stabilising current MIS / DMICP while introducing new capabilities; MOD announced the TPP EHR award in January 2026; and a separate Primary Dental Care notice concerns the DMS dentistry slice.	Official parliamentary answers and official procurement notice	High for replacement and dental-procurement signals; boundary for full replacement scope	The dental procurement notice is not evidence for whole-DMICP replacement, and none of the sources provides the complete migration, data conversion, decommissioning, or interface plan.	Add CORTISONE migration/decommissioning plan, replacement-system award notices, Primary Dental Care procurement outcome, data-conversion strategy, offline/deployed operation design, and clinical-safety / IG transition artefacts.
InterSystems has a supported Programme CORTISONE role: vendor evidence says MOD selected HealthShare and IRIS for Health, MOD performance files name INTERSYSTEMS CORPORATION for Programme CORTISONE IP and EMPI measures in FY24/25, and Contracts Finder OCDS data records an active FY25-30 HealthShare / IRIS for Health licence award to Intersystems Corporation valued at GBP 6,173,707.	Vendor announcement, official MOD transparency ODS rows, and official procurement API record	High for supplier, named licence package, value, and term; moderate-high for wider programme-role evidence	Evidence does not expose full live clinical configuration, interface catalogue, implementation status, or service-level terms.	Add full contract schedule/text and current programme-delivery architecture evidence.
The Executive Summary proposes Health Connect mediation and HealthShare shared-care functions for DMICP/CORTISONE, with nation-specific adapters. The contracted architecture must also account for the TPP EHR award. England route selection depends on current GP Connect supplier-entry policy as well as DSIC standards; Welsh EPS demonstrates shared Spine infrastructure under distinct governance.	Wiki synthesis from product, NHS, MOD, procurement and national-service evidence	High for underlying source facts; proposed architecture remains an inference	Does not establish DMICP interfaces, component/build scope, live CORTISONE routes, DSIC compliance, approved GP Connect use, local safety/IG, migration or devolved InterSystems deployments. The DUAA England health-standard boundary is separate from UK-wide data-protection law.	Obtain source/target architecture, TPP/InterSystems responsibilities, feasible supplier/use-case routes, product/build and mapping scope, migration plan, onboarding, DSA/DPIA, DCB0129/DCB0160 and nation-specific approvals.
DMS / DPHC care scope includes serving Armed Forces personnel and some family/dependant/under-18 contexts, but current public evidence does not support routine DMS/DPHC healthcare for elderly former service members after service. NHS England says primary healthcare reverts to the local NHS GP when personnel leave the armed forces.	Official DMS/DPHC notices, NHS England policy guidance, and CQC DMS inspection report	High for the bounded care-scope reading	Entitlement varies by location, status, and policy; source wording supports only bounded statements about children, families, dependants, veterans, and former service members.	Add JSP 950 or DMS entitlement policy if deeper entitlement mapping is required.
HQ Defence Medical Services became Defence Medical Command on 20 May 2026; use DMedC for Defence Medical Command in current UK Defence usage.	Official GOV.UK news page	High for naming transition	Older documents may still use HQ DMS or DMS Group wording.	Monitor full operating capability update planned for May 2027.
No public source found in this pass confirms InterSystems tooling used elsewhere in UK Defence for non-healthcare purposes. Outside UK Defence, a U.S. DoD contract notice supports InterSystems Caché support for Defense Health Agency infrastructure through Four Points Technology.	Official MOD CORTISONE transparency rows and official U.S. DoD contract notice	High for the evidence boundary; high for US DHA contract notice	The MOD rows found here are CORTISONE-specific, not non-healthcare evidence; U.S. DHA evidence is outside UK Defence and outside CORTISONE.	Add any MOD non-healthcare programme source explicitly naming InterSystems if found.
The June 2026 Update Record service-facing snapshot described technically and clinically assured pharmacy-to-GP workflows for Pharmacy First, Blood Pressure Check and Pharmacy Contraception with named suppliers. Its URL returned 404 on repeated 8 September checks; the current API catalogue still describes community-pharmacy production use, subject to the main service's new-developer onboarding restriction.	Official NHS API, service and transparency sources plus historical service snapshot	High for API definition and historical source scope; current named supplier status requires confirmation	Do not describe the unavailable historical page as current or infer generic clinical write-back approval from S102.	Pair the current service route, approved use case, supplier progress, product/version and deployment artefacts.
The NCRS roadmap edited 23 July 2026 reports April-June GP Connect Access Document pilots with two ambulance services and GP practices across selected ICBs. The NCRS service page edited 24 August still limits GP Connect information to pilot users.	Official NHS service and roadmap pages	High for reported pilot activity and stated availability	Reported pilots are not universal access, evaluated outcomes or named InterSystems implementation.	Obtain pilot outcomes, named deployment scope and current user/cohort access evidence for an implementation claim.
The NHS App roadmap edited 22 July 2026 retains GP Connect patient-facing API work for linked profiles and record-access improvements; GP-record download/share remains work planned next.	Official NHS roadmap	High for dated roadmap direction	Planned record functionality does not establish delivered features, supplier-by-supplier adoption or InterSystems support.	Pair released-feature and current onboarding evidence with any patient-facing deployment claim.
Birmingham and Solihull Shared Care Record brings together local health and care records across participating organisations including GP practices, BSMHFT, UHB, BCHC, ROH, Birmingham City Council, Solihull Council, Birmingham Children's Trust, and West Midlands Ambulance Service.	Official Birmingham and Solihull ICS page	High for local programme scope	Page does not name InterSystems as supplier. 25 September update: NHS FOIs independently confirm HealthShare, three-area scope and contract facts; signed schedules and exact March/April 2029 end remain separate.	Pair with supplier, DPIA, contract, or procurement evidence for platform claims.
Published Collaborative Shared Care Record and H&W ICWR DPIAs say partners procured InterSystems as software/system supplier, cloud hosting, and processor; the solution connects local provider systems through a central Information Exchange/HealthShare environment, includes a shared regional HealthShare instance, identifies UHB hosting, and describes Clinical Viewer display.	Published DPIA PDFs	Moderate-high for architecture and processor role	Verify final contract, live operating model, live participant list, and current status before use in procurement analysis. 25 September update: NHS FOIs independently confirm HealthShare, three-area scope and contract facts; signed schedules and exact March/April 2029 end remain separate.	Add final data-sharing agreement, contract award/procurement notice, and current programme update.
Birmingham / West Midlands public pages provide partial shared-care-record governance evidence: three-area direct-care sharing, participating organisations, subject-access/objecting routes, sensitive-information exclusions under a data-sharing agreement, and Coventry/Warks contract/data-sharing/legal-basis/information-governance alignment work.	Official local programme and NHS CSU case-study pages	High for public governance statements; moderate for artefact-pack completeness	Public pages do not expose the signed DSA, controller matrix, DPIA review history, clinical-safety artefacts, endpoint pack, or supplier responsibility matrix.	Add signed DSA, current DPIA, DCB0129/DCB0160, controller/processor matrix, and programme governance artefacts.
Birmingham Community Healthcare states that data shared under the BSOL CCC agreement will be retained in the Shared Care Record until the contract with InterSystems ends on 31 March 2029.	Official BCHC privacy notice	High for BCHC privacy/retention statement	It is not a complete contract record and does not define all Shared Care Record suppliers or functionality.	Add contract/procurement source and current programme governance documents.
NHS England Digital's National Record Locator 2024 change history names InterSystems sites, including Birmingham and Solihull ICB, Coventry and Warwickshire ICB, and Herefordshire and Worcestershire ICB, as live with International Patient Summary PDF pointers and a first-of-type direct consumer.	Official NHS England Digital roadmap	High for NRL change-history statement	Does not describe the full local shared-care-record operating model.	Add local NRL implementation notes or customer programme documentation.
HL7 UK lists OIDs for InterSystems connectivity from Cerner HIE to InterSystems HealthShare West Midlands and for InterSystems Care Community - Birmingham and Solihull CCG.	Official HL7 UK OID catalogue	High for OID existence	OID entries do not prove current operational status or data flows.	Add implementation and deployment records if using these identifiers in architecture analysis.
The Data (Use and Access) Act 2025 was introduced in the House of Lords on 23 October 2024 and received Royal Assent on 19 June 2025 as Data (Use and Access) Act 2025 (c. 18).	Official Parliament and GOV.UK Act/passage evidence	High for dates and title	Royal Assent is not the same as every provision being operationally in force.	Track commencement regulations and updates when using provision-level claims.
DUAA is being brought into force in stages: initial technical and ICO-objective provisions from 20 August 2025, specified online-safety/law-enforcement provisions in later 2025 stages, digital verification services statutory footing from 1 December 2025, and the majority of Part 5 data protection/privacy provisions from 5 February 2026, with longer-lead measures still staged.	Official GOV.UK commencement guidance	High for staged-commencement reading as of accessed date	The commencement page is time-sensitive and explicitly illustrative rather than a complete provision-level legal table.	Recheck GOV.UK and legislation.gov.uk commencement regulations before relying on a specific provision.
DUAA does not replace the UK GDPR, Data Protection Act 2018, or PECR; it amends them and adds wider data-use, digital verification, Smart Data, ICO/Information Commission, health/adult social care information-standard, online safety, biometric, trust-service, and related provisions.	Official GOV.UK guidance and explanatory notes	High for broad scope	GOV.UK factsheets are reference summaries and not legal advice or regulatory guidance.	Pair with ICO topic guidance and legal review for implementation decisions.
DUAA section 121 and Schedule 15 clarify that health and adult social care information standards in England can include IT and IT services, and can apply to providers of IT, IT services, or information-processing services used or intended for health/adult social care in or in relation to England.	Official explanatory notes	High for statutory-context interpretation	This is an England health/adult social care information-standard point; it does not identify a named standard, product, supplier, or deployment as compliant.	Map to named NHS information standards, Standards Directory entries, DSIC standards, supplier roles, and customer artefacts.
DUAA adds a statutory standards and data-governance layer to InterSystems NHS England analysis, but it does not itself prove InterSystems DSIC compliance, GP Connect assurance, NHS Standards Directory conformance, PRSB conformance, clinical safety, or local information-governance approval.	Synthesis from official NHS standards, DSIC, GOV.UK, Parliament, and explanatory-note evidence	High for evidence-boundary claim	Requires careful separation between statutory context, standards applicability, product capability, supplier assurance, and customer deployment.	Add product/version, named-standard, supplier-responsibility, and deployment evidence for any specific compliance claim.
As of 19 June 2026, the ICO says all DUAA data-protection provisions are now in force and its organisation guidance has been updated to point to new or updated topic guidance.	Official regulator guidance	High for current regulator status on data-protection provisions	This does not mean every DUAA provision outside data protection is operational, and it does not prove implementation readiness for any supplier or deployment.	Keep provision-level checks with GOV.UK, legislation.gov.uk, ICO topic guidance, and legal review.
ICO topic guidance now replaces GOV.UK factsheet-only treatment for DUAA complaint handling, lawful basis / recognised legitimate interests / purpose limitation, PECR storage and access technologies, subject access, and parts of international transfers. The 8 September planning check lists Right of Access in brief as published, SARs Q&A as drafting for autumn 2026, general research guidance as redrafting despite its elapsed summer target, research anonymisation/pseudonymisation as open consultation, and ADM/profiling as drafting after consultation closed; the latter two target final guidance in winter 2026. Transfer/enforcement tracker details retain their earlier check dates. Special-category health data retains tighter significant-automated-decision restrictions.	Official regulator guidance and planning pages	High for topic status; boundary for draft/planned guidance	Some topic guidance is final or updated, while other topics remain planned, draft, or in consultation. Subject-access implementation and international-transfer mechanism evidence remain customer-specific.	Replace queued GOV.UK-only rows topic by topic as final ICO guidance and deployment artefacts are published.
Applying the DUAA supplier artefact checklist to the Birmingham / West Midlands shared-care-record evidence pack gives partial support for a HealthShare shared-care-record and integration deployment: official local, DPIA, privacy, NHS supplier-progress/status, standards, regulator, regional support, and current trade/vendor signal sources support regional scope, InterSystems supplier/processor/hosting references, HealthShare / Information Exchange architecture, Clinical Viewer display, InterSystems contract-retention wording, NRL InterSystems site references, HL7 UK OIDs, GP Connect supplier-progress relevance, national NHS Medicus status, and a current Medicus integration signal. It still does not prove full DSIC foundation compliance, complete current operating status, final data-sharing agreement terms, DCB0129/DCB0160 safety evidence, or current local GP Connect / MESH / ITK3 onboarding.	Official local programme/privacy sources, DPIAs, official NHS supplier-progress/service-status/HL7 identifiers, statutory/regulator sources, regional support material, trade/vendor current signal, and wiki synthesis	Moderate-high for partial deployment evidence; boundary for DSIC/DUAA compliance	The available artefacts are public fragments, not a complete procurement, legal, safety, operational, or supplier-responsibility evidence pack. The Medicus integration source is not an official NHS/customer assurance artefact.	Add final DSA/DPIA update, DCB0129/DCB0160 artefacts, supplier responsibility matrix, national-service onboarding evidence, official current live-status source, and customer deployment architecture.
Official FOI and information-request routes have been identified for the public authorities most likely to hold recorded evidence about the West Midlands Medicus / HealthShare route, including ICB programme bodies, UHB hosting/operational context, and participating-provider trust implementation records.	Official FOI and information-request pages plus wiki validation-pack synthesis	High for locating request routes; not evidence that the requested deployment artefacts exist	FOI/source-target pages identify where to ask for evidence, not the answer to the deployment question. Supplier-side Medicus and InterSystems material is not FOI evidence and must be treated separately unless customer-approved.	Submit targeted requests for route architecture, DSA/NDSA, DPIA, DCB0129/DCB0160, MESH/ITK3, endpoint/certificate, supplier RACI, current live status, and operating-model evidence.
IRIS for Health and Health Connect 2026.2 are generally available Continuous Delivery software; IRIS for Health release notes add FHIR Explorer, authentication/search changes and optional structural-validation bypass.	Official vendor release notices and product documentation	High for released version and documented mechanics	Does not establish managed-service tenant rollout, customer upgrade, NHS profile validation, or local correction status; structural-validation bypass can admit malformed data.	Obtain deployed build, release-stream choice, tenant rollout statement, validation settings and endpoint test evidence for a named architecture.
Public July 2026 HealthShare / IRIS for Health / Health Connect alerts identify specific permission, FHIR audit/access, federated SSO, upgrade, consent and fetch-operation checks.	Official vendor support alerts	High for published alert and affected-version scope	The summaries and broad ranges are not evidence that a customer is currently affected or corrected; detailed conditions and corrections require the vendor alert/WRC record and deployed build.	Map exact component/build/configuration to applicable notices and record correction, access/consent/audit tests and upgrade evidence in the existing deployment assurance pack.
An InterSystems advisory reports incorrect NRL pointer labels during a HealthShare implementation, with unexpected data returned in Clinical Viewer.	Official vendor support advisory	High for reported vendor implementation issue; boundary for customer/assurance scope	Supports a specific UCR / Clinical Viewer and NHS NRL integration signal, not named customer, current NHS assurance, local exposure or remediation proof.	For a claimed NRL route, obtain pointer-type catalogue, customer/version scope, NRL onboarding and correction/validation evidence.
A configured Clinical Viewer OtherAddresses element can cause the patient banner to disappear; InterSystems identifies HSEUA-3021 in 2026.1 and WRC patches for older releases.	Official vendor support advisory	High for documented defect and correction boundary	Customer layout, build and correction evidence are needed; do not infer a live patient-safety incident from the notice.	Check the named deployment's layout and correction record, then verify patient-context display through the affected navigation path.
InterSystems states that IntelliCare and TrakCare achieved EU MDR Class IIa certification in May 2026.	Official vendor news and regulatory-positioning pages	Moderate-high for vendor certification claim	Certificate, intended use, covered versions/modules and jurisdiction applicability were not independently validated; this does not establish NHS DCB0129/DCB0160, UK adoption or local deployment approval.	Obtain the certificate and intended-use/version scope, then map covered functionality to the named deployment and its separate clinical-safety/AI governance pack.
HealthShare's ODS autoload advisory describes excessive patient caching following MPI events in specified UCR versions and identifies HSDD-2364 correction.	Official vendor support advisory	High for product/version correction boundary	HealthShare ODS here is not NHS Organisation Data Service; the notice does not prove NHS directory integration or customer exposure/remediation.	Check UCR build, autoload/MPI configuration, correction record and storage/operational evidence for a deployment relying on that component.
IRIS for Health profile validation has a separately configured runtime; cloud operations documentation retains R4, snapshot and explicit-profile boundaries.	Official product and cloud-services documentation	High for validation mechanics	Package installation, structural checking and core-schema validation do not by themselves establish UK Core/GP Connect profile conformance or validation-runtime operation.	Obtain endpoint packages, profile versions/snapshots, runtime configuration, validation mode and positive/negative test evidence.
Welsh EPS exchanges prescriptions through NHS Spine and uses PDS pharmacy nominations; DHCW reports active but incomplete April 2026 rollout. Cardiff and Vale encounter data also flows into Wales CDR through national FHIR mapping.	Official NHS England and DHCW service/programme material	High for specified routes and dated programme reports	Welsh infrastructure reuse does not establish Welsh GP Connect, DSIC applicability, InterSystems involvement, full EPS rollout or complete CDR coverage.	Check completion against the EPS target and validate additional CDR feeds using named implementation records.
NHS Golden Jubilee reports completion of its TrakCare version 2024 upgrade and full system adoption in its February 2026 monitoring paper.	Official board monitoring paper	High for the reported local milestone	The quarter-one update is not a board-wide Scotland inventory or outcome evaluation.	Use board-specific implementation and outcome evidence for wider Scottish claims.
DHCW's January 2026 accountability paper records LIMS technical readiness and a first cellular-pathology go-live, with other clinical tranche completion dates forecast or under review.	Board/procurement evidence plus official programme accountability paper	High for contract and dated rollout status	Revised forecast dates do not establish completed all-Wales deployment or measured benefits.	Obtain completed tranche go-live, acceptance and safety evidence.
London North West University Healthcare NHS Trust's July 2024 recruitment advert names InterSystems Health Connect for interface development.	Official NHS Jobs advert	Moderate-high for historical technical context	Closes the independent list's unknown trust signal, not current ICS cloud scope, contract or outcomes.	Retain current customer/procurement validation gap.
Medicus's own integration catalogue lists the Birmingham and Solihull Shared Care Record across the three regional areas.	InterSystems/trade signal plus first-party Medicus catalogue	Moderate-high for supplier-stated regional connection	Does not name HealthShare or the transport and does not supply NHS/customer local assurance artefacts.	Retain existing local architecture/onboarding/safety evidence gap without creating a new trail.
NHS Standards Directory CIS v2.01 release notes identify the April 2026 minor release, demographic model changes, hazard log v2.2 and safety case v1.8.	Official PRSB and NHS standard/release evidence	High for released standard and artefact versions	HealthShare's CIS Version 2 Level 2 listing does not by itself establish a particular software build's v2.01 adoption or local safety assessment.	Obtain release-specific product mapping, presentation behaviour and clinical-safety change evidence where CIS conformance is used for assurance.
Northern Ireland's Being Open Framework was published in February 2026, with implementation from April 2026. The official FAQ explicitly says it creates no new statutory/legal duty and treats proposed legislation separately.	Official Department of Health publication and FAQ	High for published policy and implementation boundary	Policy publication is not proof of statutory enactment or local implementation.	Map relevant HSC governance and incident-record workflows to the published framework; use separate legislation evidence for statutory claims.
EMC customer reporting states that IntelliCare was implemented across all its hospitals.	Customer investor and sustainability reporting	High for reported implementation	Sustainability disclosures are not externally assured; enabled features and causal benefits remain separate.	Obtain site/module activation and evaluation methods/results.
Medcare UAE has announced IntelliCare adoption covering six hospitals and 25 medical centres.	Vendor announcement and customer-owned post	High for agreement scope	Future deployment wording does not establish completed clinical go-live.	Obtain dated live-site and clinical-feature confirmation.
King's Jeddah signed an IntelliCare agreement; September announcements describe intended EMEA go-live.	Customer and vendor public posts	High for adoption status	Intended regional-first go-live is not completed implementation.	Obtain go-live date, operational scope and acceptance evidence.
RedSalud has announced an IntelliCare transition from its TrakCare estate.	Vendor announcement quoting customer executive	High for announced transition	The June source does not establish completed rollout.	Obtain customer-side implementation milestones and operating scope.
Public descriptions map IntelliCare retrieval, drafting, Actions and coding to TrakCare clinical and financial workflows with human review.	Vendor feature descriptions and wiki functional synthesis	High for described features; inferred workflow correspondence	Not an internal API map or verified local approval/automation configuration. Dated brochure availability footers need later market-specific evidence.	Validate one named workflow's release, data flow, review, record update and downstream execution.
The EMC completeness figure belongs to earlier TrakCare work; the click example concerns IntelliCare laboratory-result retrieval.	Customer interview and vendor publicity reconciled by timing	High for attribution; limited for general benefit	Neither supplies a controlled incremental AI outcome estimate.	Obtain metric-specific denominators, baseline, comparator, task timing and errors.
EMC pilot research and Grha Kedoya digital-maturity assessment are reported, without an independent incremental IntelliCare effect estimate in the reviewed sources.	Group research disclosure and maturity reporting	High for reported activities; outcome boundary	Research activity and maturity scores are different from AI effectiveness results.	Obtain the pilot protocol/results and identify evaluator independence.
TrakCare Lab Enterprise has a distinct laboratory-management scope and can connect to other EHRs.	Official vendor product page	High for product scope	Does not establish a wider TrakCare EHR rollout.	Use the existing Wales page for dated implementation evidence.
HAPI FHIR and Azure Health Data Services provide sourced examples for comparing FHIR implementation and service models.	Official project and vendor documentation; wiki comparative synthesis	High for documented scope; no comparative performance finding	Different operating models; not an equivalent EHR or NHS assurance comparison.	Compare the same workload and operating scope before ranking products.
NHS Ayrshire and Arran awarded InterSystems a 2026 TrakCare software-update technical-assistance contract.	Official procurement notice	High for award	Does not prove hosted migration or measured clinical benefits.	Keep support procurement separate from delivery milestones.
FHIR resources, terminology, profiles and exchange methods, and IHE workflow profiles describe complementary interoperability rules.	Published HL7 specification and official IHE overview	High for definitions; wiki synthesis for the layered explanation	Standards definitions do not establish configured product behaviour.	Use the standards overview to connect content, codes, exchange and service rules.
Public documentation illustrates Health Connect tracing, FHIR Explorer, Bulk FHIR configuration, FHIR SQL Builder, FHIR Server settings and the shared DTL editor.	Official documentation screenshots	High for the visible example workflows	Release context belongs to the documentation; cloud screenshots may be unversioned. The DTL example is generic, not a CDA-to-SDA mapping.	Use a deployment's own version and configuration for operational guidance.
Public HealthShare material illustrates Clinical Viewer search, Health Insight dashboards, AI Assistant prompt settings, Care Community care plans and Personal Community mobile access.	Vendor brochures, product material and dated demonstration	High for published examples	Clinical Viewer is the illustrated UCR access surface. Screens and displayed figures do not establish live deployment, enabled features or measured outcomes.	Check current release and local configuration before treating examples as user instructions.
Dated public tutorials and customer training material illustrate FHIR package selection, OMOP monitoring, EMPI search, Provider Directory navigation and TrakCare bed search.	First-hand developer tutorials, community question and NHS training guide	High for the displayed historical screens; limited for current appearance	Provider Directory is a small 2019 example; TrakCare is a local T2022.4 configuration. Package selection is not profile validation, and synthetic OMOP data is not production performance.	Replace historical examples when a verified current public screen is available; retain date and product scope.
InterSystems' SantExpo 2025 IntelliCare demonstration shows a mobile encounter-recording interface with timer and pause/stop controls.	Official demonstration video, timestamp 9:39	High for the visible demonstration	Projected screen with limited fine detail; product build unstated. This does not establish a customer's active feature set, clinical workflow controls or outcomes.	Prefer a direct current product screenshot when publicly available.
The whole-UK connectivity map compares network, patient/staff/system identity, exchange, records and content layers, with separate national and supplier evidence.	Official national services and wiki synthesis	High for named service roles; synthesis for the layer model	There is no asserted single UK clinical backbone or one-to-one equivalent; service reuse does not confer common API access or DSIC scope.	Implementation evidence only for the specific country, service and customer route selected.
England connectivity includes HSCN and internet routes; Spine's published transition retains HSCN support, while CIS1 staff authentication is scheduled for retirement by end February 2027 in favour of CIS2.	Official service and migration guidance	High for current guidance and stated target	Network transition, staff authentication and clinical-service lifecycle are separate. A target is not completed migration; check each API's access rules.	Service-specific migration/acceptance evidence before describing a particular implementation as migrated.
MESH supplies UK-used asynchronous store-and-forward delivery through API, client and web routes; SSP brokers supported GP Connect FHIR access using SDS lookup and mutual TLS.	Official transport and architecture documentation	High for service behaviour	Delivery acknowledgement is not clinical acceptance or review; a proxy route does not establish supplier implementation or universal GP Connect onboarding.	Named workflow/profile, receiving application processing and current onboarding evidence for an implementation decision.
Scotland's connectivity landscape separates SWAN network transport, CHI identity, ECS/KIS summaries, SCI Gateway referrals, local SCI Store information, ePharmacy/GP transfer, NDP components and MyCare patient access. PSD Scotland succeeds NES/NSS from April 2026; older service documentation retains predecessor branding.	Government, NHS service and provider documentation	High for the functional map and documented governance transition	Functional comparisons do not establish shared England APIs, national onboarding approval or product implementation.	Add interface/version and current service-owner evidence only for the specific route being implemented.
SWAN offers PSN/HSCN gateway services; a Scottish Government FOI identifies BT as its SWAN Internet/MPLS provider and a March 2026 SWAN2 migration target for its own estate.	Operator catalogue, government FOI and NHS board status report	High for catalogue and dated estate-specific statements; unconfirmed for completion	FOI answered November 2025; government estate target is not national NHS completion. December board report records ongoing transitions/possible extension. Network connectivity does not grant clinical-service access.	Dated national or relevant board/estate acceptance and migration-completion report before asserting cutover.
SCI Gateway remains an operational referral/clinical-communication route with local-board access support and maintained national directory data; a diabetes digital-service procurement distinguishes SWAN sign-in/referral access from later technical integration.	NHS product/access/reference data and procurement requirements	High for service existence and specified access requirements	The procurement's implementation target and optional later phase are not completed integration proof; current full interface specs were not located.	Current interface catalogue, message/profile version, onboarding conditions and customer implementation evidence for a named use.
NHS Lothian's August 2025 SOP describes scanned eCasenotes held in SCI Store and viewed through TrakCare.	Direct provider/university operating procedure	High for this local document-storage/presentation workflow	Does not show InterSystems national ownership of SCI Store, universal board configuration, or API/transport details.	Technical specification and operational scope only if the integration must be assessed beyond the documented local viewing workflow.
NDP Data Access retrieves ECS medication/allergy information using CHI for MyCare without local storage; Integration is in production; Demographics documents an HL7 FHIR representation with internal-use and permission limits. Data Storage has a separate persistence role.	Official component service documentation	High for stated roles and specific statuses	Live retrieval from ECS does not prove immediate upstream GP updates. FHIR is not established for all services. Data Storage page includes copied DAS status text; listed platform uses do not establish nationwide patient-facing functionality.	Public endpoint/profile/version and onboarding specifications; service-status clarification only if a DSS production claim is needed.
NHS 24 and the Scottish Ambulance Service describe ECS/KIS access for direct care, while the NHS digital dermatology pathway connects CHI lookup, Consultant Connect/PhotoSAF, NDP storage and SCI Gateway attachments.	Current service information and NHS implementation guidance	High for named workflows	Summaries are not complete GP records; the dermatology flow is pathway/configuration-specific and Docman delivery is conditional.	Site-specific configuration/coverage evidence if extrapolating beyond the documented pathway.
Scotland's PACS procurement milestone and transition preparation are separate from implementation cutover; NHSGGC publishes a board-administered image-transfer workflow.	Government plan, NHS board report and local operational guidance	High for the dated distinctions; limited for current cutover and universal workflow	December 2025 report still recorded implementation issues; NHSGGC guidance's review date elapsed July 2026. No national DICOM/IHE profile or universal cross-border API is established.	Current national PACS programme/board acceptance report and updated transfer guidance before asserting replacement completion or universal interface support.
Wales has separate network, identity, clinical-access and referral services: PSBA provides the WAN; WDS supports demographics and has a PDS relationship; WCP/WGPR provide record access; WCCG supports named electronic referrals.	Official network programme, service directory, annual report, API documentation and clinical-service instructions	High for the identified functions and named operating routes	These functional comparisons do not establish England GP Connect/e-RS API compatibility, complete access scope, or an InterSystems role in these national services.	Use the country service map to select a route, then obtain its actual access and interface requirements for a proposed connection.
Wales's InterSystems LIMS replacement and Philips RISP are distinct diagnostic systems. Early 2026 sources report TCLE technical/initial clinical milestones and named RISP deployments, with remaining rollout work.	NHS board/committee evidence and official contract award	High for supplier scope and dated reported milestones; boundary for later completion	RISP award is supplier scope, not all-sites go-live. TCLE technical go-live does not establish every discipline/interface accepted. March escalation milestones are draft targets.	Keep LIMS discipline acceptance, WCP/WRRS interface migration and RISP organisation completion separately dated; update only against completed customer milestones.
Northern Ireland NIDIS Phase 1 is an operational identity-distribution service; Phase 2 targets GP-registration replacement. NHAIS support and cervical-screening continuity are separately evidenced.	Official go-live report, programme page, identifier definition and procurement notices	High for Phase 1 and the replacement/continuity distinction	No verified Phase 2 acceptance or complete NHAIS retirement. The February 2026 earliest-May forecast is not a go-live. Caché licensing for NHAIS does not identify the NIDIS supplier or database.	Resolve actual Phase 2 acceptance and residual screening functions when making a legacy-system retirement or supplier-continuity claim.
Northern Ireland's HSC Wide Area Network is a separate infrastructure layer with BSO ITS regional security responsibilities.	Official annual report	High for the stated infrastructure and responsibility	Does not establish current carrier/site inventory, external connection approval, application access or an InterSystems role.	Identify the actual network connection and application onboarding separately when planning a named exchange.
Northern Ireland has distinct regional diagnostic systems: BSO reports CoreLIMS rollout with Clinisys and NIPACS+ regional deployment with Sectra.	Official customer programme/go-live/closure reports	High for named supplier and rollout statements; boundary for completed July 2026 handover	June NIPACS+ source announces July close/operations transition prospectively; it is not retrospective handover evidence. CoreLIMS rollout does not validate every downstream interface or measured outcome.	Use programme go-live evidence for scope; require retrospective handover or interface acceptance only where that claim is needed.
England pathology exchange is transitioning from production EDIFACT/MESH to the Pathology and Laboratory Medicine Reporting FHIR API; the new route is alpha/pilot, with assurance targeted for April 2027 before wider rollout.	Official NHS England implementation and API documentation	High for stated status and route	No completed national migration or legacy retirement date; the DAPB4101 deadline will be extended.	Updated conformance date and supplier rollout milestones when published.
Pathology IG 0.5.0 uses FHIR R4 document Bundles with Composition, SNOMED PBCL/PaLM and mixed NHS England/European laboratory/UK Core profiles; it is not the separate DSTU3 Lab Results adaptor.	Official NHS England versioned implementation guide and catalogue	High for versioned specification	Active development; transport/error/acknowledgement elements partly unresolved. Package and API versions differ from IG version.	Final transport/acknowledgement specification and later released IG versions.
National Imaging Registry supports federated diagnostic-record discovery and report/image retrieval; current API is production beta using SOAP/XCA and XCA-I, while FHIR/MHD and WADO-RS are planned.	Official NHS England service, API and roadmap	High for current published interface and limited beta use	Service reports three networks; roadmap targets and broad capability wording do not prove national coverage. No central clinical-image archive or new viewer.	Dated network rollout milestones and release evidence for planned interfaces.
NIR aims to reduce reliance on IEP, but the reviewed primary sources do not establish a national IEP shutdown or a completed England-wide replacement.	Official NHS England service and roadmap	High for stated IEP-reduction objective; bounded for replacement status	A procurement or roadmap milestone alone does not establish operational replacement.	An explicit official IEP retirement or replacement-completion notice if that claim is needed.
NCRS is a professional application combining multiple national services; SCR is one source alongside PDS, NRL documents, Patient Flags, birth notifications, OVM/chargeable-status functions and vaccination information.	Official NHS service, application and feature guidance	High for published service composition	An application feature is not a separate SCR section, a complete national patient record or a supplier implementation claim.	The source/launch diagrams distinguish existing approved local-system-to-NCRS launch from the prospective reverse shortcut to a Shared Care Record. Neither establishes copied source records or specific supplier/customer deployment.
NCRS includes selected updates as well as viewing. Published activities distinguish SCR access, NRL pointer/document access, CP-IS viewing with or without notification, RA flag existence/details/management, FGM view/manage and OVM record/status editing. Birth notifications require a named role plus B1610.	Official permissions and onboarding guidance	High for stated actions and permission separation	Basic NCRS access grants neither every function nor every edit; no field-by-field demographic update contract was verified. CP-IS viewing/notification is distinct from editing a protection plan.	Current role/activity and field-level specification where an actual access or integration design requires it.
NCRS GP Connect access remains restricted to pilot users, Shared Care Record shortcuts remain prospective/pilot features, and the dedicated COVID vaccination view has announced retirement with COVID vaccination status still available through the Summary Care Record.	Official service, roadmap and dated feature guidance	High for stated pilot and retirement boundaries	Live overall NCRS status does not imply universal feature availability. No exact COVID-view withdrawal date or completed withdrawal was found.	Dated feature release or retirement notice before promoting a pilot or planned withdrawal to completed status.
NHS App patient access requires NHS login and identity verification for personal services; GP/provider settings and separately authorised family/carer profiles determine available information and actions.	Official NHS patient service/help guidance	High for published access and feature limits	A verified login does not guarantee full records, every hospital connection or professional NCRS permissions. The public eligibility guide excludes users while registered with DMS.	Use the England patient-access section for comparison with devolved patient portals; check the relevant provider when assessing a particular feature.
WCP is the professional portal for combined clinical information and selected workflows; WGPR supplies a limited GP-derived summary; WCCG carries GP/hospital communications and referrals.	Official service descriptions, patient leaflet, customer referral instructions and programme reporting	High for function separation; boundary for detailed access configuration	Public sources do not establish a complete current WCP/WGPR/WCCG permission catalogue. The undated WGPR leaflet is linked to 2021 FAQ material. New WCP Workflow Action List and Operation Note features have trial/early-adopter scope.	Use local authorised-access and workflow specifications when implementing a connection; do not infer common roles, write permissions or blanket rollout from national branding.
NHS Wales App availability is feature-specific: GP practices control record/appointment access, hospital display depends on the health board, and GP-record test results differ from the currently limited health timeline.	Official application help and dated government roadmap	High for currently published feature limits	GP detailed-coded-record results do not imply hospital-results availability or timeline support. Initial hospital outpatient appointments exclude follow-ups; current help excludes English-hospital appointments/referrals for Powys patients. Authorised access remains in development.	Recheck the specific help page or named rollout announcement before promoting a feature to generally available; retain source and service-scope dates.
MyCare.scot offers initial national patient access through verified ScotAccount; appointment and letter viewing had already launched for the initial Lanarkshire dermatology cohort. National availability and feature availability must be stated separately.	Government programme and service guidance; NHS implementation announcement	High for named initial features and dated cohort delivery	January cohort announcement does not prove national appointment coverage or booking; programme ambitions do not prove delivery. Older indexed support/terms pages still contain pre-national-launch wording.	Current release or board implementation evidence before widening any feature-availability claim.
Scottish professional access combines board clinical portals and separately governed services such as ECS/KIS, SCI Store and SCI Gateway. The government described varying board permissions in March 2025.	Government briefing, NHS service documentation and local operational procedure	High for documented routes; dated for board access coverage	No current nationwide portal feature/permission matrix or single national NCRS-equivalent application is established. Local Lothian viewing and research-upload permissions do not establish universal SCI Store access.	Current board-specific access guidance only where a deployment or role-access claim depends on it.
General practice remains outside core encompass programme scope, while GPs can view Trust information and perform defined functions through EpicCare Link, including referrals and imaging requests. Department testimony in June 2025 also describes blood-test orders and messages without core-record write access.	Official service pages and Department parliamentary evidence	High for functional separation and dated actions	“Read-only” viewing does not remove every workflow action; not all user roles are shown to have identical permissions. Older rollout wording is superseded by completed Trust deployment.	For an actual connection, obtain the applicable organisation/role configuration; no additional evidence needed for this overview distinction.
My Care exposes an optional patient/proxy subset of encompass, with secure communication and specified contact edits, while excluding GP records, GP appointments, GP-requested results and pre-encompass history; social-care display remains future.	Official service page and patient guidance	High for published functions and exclusions	Result release, proxy clinical versus scheduling/messaging permissions, and MSK appointment self-service are scoped; MSK scheduling is introduced service by service. Temporary address/mobile/Trust email edits do not establish unrestricted clinical editing or changes to nidirect login identity.	Revisit coverage when DHCNI publishes a changed service scope; no inferred launch date for social-care display.
NIECR's 2023 transition guidance retains historical access pending archiving while directing live-Trust information to encompass/EpicCare Link; BSO still publishes NIECR access/support references in August 2026.	Official migration guidance, deployment evidence and current operational webpage	High for dated plan and continued published reference; bounded for current transition state	Does not establish archive completion, final decommission date, or completeness of residual/current feeds. The 2023 optometry guide is not a universal current permissions specification.	A BSO archive/decommission decision or current service/data-flow statement if this transition becomes an implementation dependency.
PHS National Reference Files, Welsh WRTS and DHCNI organisation data distributed through ODS provide national organisation/site reference-code routes.	Official reference-data catalogues and service descriptions	High for the named datasets and responsibilities	Reference codes are not patient-demographic services or system-endpoint directories; the NI entry covers specified organisation classes.	Verify dataset/class and interface scope for an actual consuming system.
Wales provides national ETR/GPTR requesting and WRRS results access through WCP; pathology/radiology requesting and EPS adoption remain phased.	Official accountability and annual-report evidence	High for named national functions and published rollout status	National service scope and health-board participation do not establish all-practice/site enablement. ETR requests, WRRS reports and PACS/RISP images are different functions.	Keep the simple matrix linked to the country service/status detail; obtain site-specific scope only for a concrete implementation question.
SCI Store has historical national adoption and supplier-documented distributed pathology-result delivery; current national completeness and a single endpoint are not established.	Historical government strategy, local NHS procedure and primary supplier documentation	High for dated adoption and documented mechanics; boundary for current coverage	2015 adoption is not 2026 coverage. Board repositories and configured GP software access do not prove a central national exchange or common permissions.	Current national commissioning/coverage evidence if a stronger national service claim is needed.
Scottish PACS supports image availability across health boards; report return and replacement status remain separate questions.	Official NHS service explanation and government/programme evidence	High for described national image function	Cross-board image viewing does not establish a separate national report-delivery service, automatic cross-border API or completed replacement.	Retain dated programme and interface boundaries in the Scotland and diagnostics pages.
NIPACS+ covers imaging reports as well as images, with distinct RIS, PACS and VNA roles.	Official privacy/scope notice and deployment programme evidence	High for data categories and documented deployment scope	June 2024 notice establishes functions, not subsequent go-live or completion of the announced July 2026 operations handover.	Use current programme evidence for delivery claims and the notice for report/image scope.
England clinician-to-laboratory pathology requests use local ordering/LIMS routes; UHB also documents provider-based imaging requesting. NPEx serves a separate laboratory-to-laboratory function.	National technical architecture and Trust workflow guidance	High for described roles; bounded for individual implementations	Trust/laboratory delivery is not an absent function. Local product examples do not establish a uniform national or regional platform.	For an actual connection, identify the receiving provider, ordering route and supported interface.
Scottish diagnostic ordering has health-board/laboratory implementations; radiology reports return through provider workflows and professional portals have board-specific access.	Government access briefing and official NHS service guidance	High for documented examples; bounded for whole-country coverage	Lothian illustrates ordering, Fife describes report return, and portal permissions are dated. Do not relabel every route as a uniform regional service.	Confirm board/provider and permissions for any concrete implementation.
NI public guidance documents ECS/KIS through NIECR, and BSO procurement describes EDT carrying most hospital-to-GP correspondence.	Official public guidance, transition guidance and procurement notice	High for named functions; current NIECR feed completeness remains unverified	A national functional counterpart can exist while current coverage remains uncertain. EDT is a scoped document workflow; Docman10X procurement is not rollout completion.	Seek a current GP-summary feed/transition specification when current completeness becomes a dependency.

UK Clinical Platform Estate — 25 September 2026

See estate hub for the synthesis and source-linked observation tables. Dataset rows preserve finer supplier/site/date boundaries.

Claim	Evidence Type	Confidence	Limits	Next Evidence Needed
The UK clinical platform baseline contains independently scoped shared-record, EPR/PAS, external-portal and diagnostic observations, mapped to 36 current English ICBs and all devolved territorial regions.	Official geography; source-linked observation dataset	High for baseline geography; variable for individual deployment status	193 observations are not unique installations or a complete trust/site census. All tables and map downloads derive from one dataset; no supplier territory or market-share inference.	Extend missing trust/site coverage with dated provider evidence; retain unknowns.
HealthShare has documented programme associations with six current English ICBs, including partial Central East and Norfolk/Suffolk footprints.	NHS FOI, programme and roadmap; supplier corroboration	High for named programme facts; current breadth varies	West Midlands contract covers three areas; Bedfordshire/Luton and Norfolk/Waveney do not establish whole-successor ICB coverage. NRL target is not interface completion.	Signed schedules, current participating providers and legacy-to-successor coverage.
London Care Record uses Oracle HIE; selected other regions use Graphnet, Orion, Interweave or Black Pear, while some suppliers and migrations remain unverified.	Customer/programme, supplier and procurement evidence	Variable by source and date	Health Connect middleware is not HealthShare. Dorset membership and Gloucester award do not establish completed cutovers. Use each programme row and direct source for narrower scope.	Resolve Lancashire supplier and Dorset/Nottinghamshire/Gloucestershire/Cheshire transition milestones.
Hospital EPR/PAS and EpicCare Link observations require separate deployment and access scope.	Provider/programme evidence	High for explicitly reported milestones	Epic EPR does not establish EpicCare Link, Beaker or Radiant. ESNEFT portal is pilot; Nervecentre modules are not whole-EPR completion; future deployments retain planned/implementation status.	Complete trust coverage and confirm role-specific portal/referral/order workflows.
Scottish TrakCare PMS and Welsh WPAS coverage is administrative evidence, not proof of a complete national clinical EPR.	PHS and DHCW official evidence	High for stated PMS/PAS coverage	Dumfries/Galloway, Western Isles and Cardiff/Vale alternative core estates remain explicit unknowns; specialist national providers do not increase territorial-board counts.	Board-specific current clinical module and alternative PAS/EPR evidence.
Diagnostic front ends, departmental backends and exchange platforms can have different suppliers at the same provider.	Provider, national programme and procurement evidence	High for stated scopes; rollout and dated guidance limits retained	Devon Epic does not prove Radiant; Lothian GP ICE differs from hospital TrakCare; ABUHB transfusion WinPath is a Welsh LIMS exception; NI Epic/WinPath/Sectra are separate.	Site/discipline acceptance, current older-guidance validation and mapped interface contracts.
MKUH reports Oracle Millennium/HIE with selected shared content and incomplete external connections; InterSystems has a separate middleware role.	Official trust response to coroner	High for 23 September 2025 statement	A window into selected record content is not a full-record copy. Cross-provider links and regional shared-record preferences differ.	Current connection and content coverage before an access or integration decision.