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 |
|---|---|---|---|---|
| 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 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 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 Care Community 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, 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. | Wiki synthesis backed by official vendor documentation, PRSB material, customer/deployment-side records, NHS supplier-progress evidence, NHS PDS/ODS evidence, DSIC sources, 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; it does not prove HealthShare EMPI or Provider Directory use. | 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, Update Record separation, a reusable standards-conformance evidence request pattern, and implementation-proof limits. | Wiki synthesis backed by official NHS, DHSC, PRSB, ICO, standards-directory, and NHS API/service 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, or customer deployment evidence. | Add product/version documentation, current conformance rows, validation-scope packs, supplier responsibility matrices, and customer deployment packs for specific standards claims. |
| The UK legal and professional position on recording healthcare information and healthcare delivery is layered: UK GDPR and DPA 2018 govern personal and 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; 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, 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, 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, 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, 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, and direct-care or secondary-use purpose. It does not prove DSIC, GP Connect, HealthShare, Health Connect, DMICP, devolved-nation, patient-facing, analytics, or AI 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, 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, 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, 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, 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 is positioned as a cloud-first managed healthcare integration engine with 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, historical and contemporary sector evidence for Victorian community-health TrakCare use, official Chilean SSMS APS / referral-workflow evidence, 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, official Chilean health-service 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; Victoria's contemporary source is a sector paper rather than a government system inventory; newer Chile sources support workflow relevance but not named El Bosque live status; 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, Victorian Government or provider-level current TrakCare scope, named El Bosque / SSMS APS live-status evidence, and DHAMAN primary source naming TrakCare. |
| Northern Territory Acacia is a TrakCare-based territory-wide public-health electronic patient record with official evidence for remote/community continuity-of-care context. | Official NT Health and NT Government pages | High for official Acacia / TrakCare basis and rollout framing | It is public-health and remote/community-care adjacent evidence, not a standalone TrakCare PHC module claim. | Add current Acacia scope, status, and inquiry outcome material if using for operational assessment. |
| IntelliCare is positioned as a next-generation EHR with built-in GenAI and ambient documentation features. | Official vendor product page | High for product positioning | Clinical safety, regulatory, and deployment details need formal product documentation. | Add regulatory, clinical-safety, and product documentation. |
| 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; moderate for future implementation outcomes | 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 is an NHS service enabling authorised health and care workers in different care settings to access GP record information through clinical or care systems for approved direct patient care; current NHS API pages also define Access Record Structured and Send Document production/service context. | Official NHS England Digital service/API pages and Standards Directory entries | High | This defines the NHS service and current API context, not any InterSystems-specific implementation. | Add supplier-progress row mapping, relevant InterSystems product documentation, and implementation-specific conformance 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 Version 2 conformance evidence. | 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 2026-06-21 component consistency pass selects EMPI / Provider Directory identity and directory assurance as the next non-Care target. | Official InterSystems product/docs, PRSB, NHS supplier-progress, NHS operating-model, and DSIC capability/standards sources | High for InterSystems component relevance; boundary for DSIC foundation-system compliance | HealthShare PRSB CIS conformance and GP Connect supplier-progress row presence are not a full DSIC foundation-system accreditation claim. | 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 deployment artefacts for EMPI / Provider Directory roles. |
The EMPI / Provider Directory identity-directory source pass found stronger NHS dependency evidence but not direct 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. |
Official InterSystems product pages plus official NHS England Digital PDS/ODS service, API, conformance, and integrated-products pages | High for national-service requirements and HealthConnect PDS row; boundary for EMPI / Provider Directory implementation | National PDS/ODS evidence defines what an England identity/directory implementation must prove. It is not customer architecture, EMPI matching configuration, Provider Directory ODS/SDS mapping, DCB0129/DCB0160, local DPIA/DSA, or DSIC catalogue evidence. | Seek product/version, PDS FHIR onboarding, ODS/SDS mapping, matching/stewardship, directory-governance, sync/audit, safety-ownership, 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 is a distinct community-pharmacy structured write-back integration using MESH, ITK3, and FHIR STU3 payloads; it is not a generic write-back capability for all GP Connect consumers. | Official NHS England Digital API catalogue page | High | NHS catalogue evidence defines the API/integration scope and prerequisites, not InterSystems support or supplier rollout in a named deployment. | Add supplier progress, product documentation, and customer deployment evidence by capability. |
| Contemporary NHS GP Connect roadmap evidence is distributed across supplier progress, utilisation snapshots, specification releases, Update Record service guidance, 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 NHS GP Connect supplier progress snapshot edited 5 June 2026 includes structurally parsed InterSystems rows: InterSystems IRIS For Health (Middleware) maps to Send Document (Send) v2.0.1, and source-spelled InterSytems Healthshare maps to Access Record: Structured Medications v1.2.6, Allergies v1.2.6, Immunisations v1.5.0, and Uncategorised v1.5.0, with other HealthShare structured cells blank. The 2026-06-21 evidence request pack converts this supplier-progress claim into product/version, validation-scope, exclusion, component-coverage, adjacent-standard, and deployment-artefact evidence requests. |
Official NHS England Digital supplier-progress page plus local structural HTML table parse and wiki request-pattern application | High for NHS-published supplier-progress presence and cell mapping; boundary for implementation proof | This proves NHS table placement, not product configuration, live deployment, local onboarding, safety case, or DSIC catalogue scope. | Match rows to InterSystems product documentation, assurance artefacts, customer deployments, and the GP Connect evidence request pack; recheck the NHS page after edits later than 5 June 2026. |
| NHS England GP Connect material provides official national Medicus context: supplier-progress rows identify Medicus provider and consumer capability status, the GP Connect service page says Patient Facing APIs are live with Medicus and Access Document is FoT ready for Medicus, and the GP Connect DPIA names Medicus as a new NHS market entrant for GPs. | 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, and related API/service routes. | Official NHS England Digital service and technical pages | High for England baseline | Does not imply that Scotland, Wales, or Northern Ireland use Spine or expose the same APIs. | Maintain a function-by-function crosswalk rather than forcing product equivalence. |
| Scotland's closest GP Connect-like and Spine-like routes are ECS/KIS for GP-derived care summaries, SCI Gateway for primary-secondary communication, CHI for patient identity, the National Digital Platform for common platform/API direction, NSS pharmacy services / ePharmacy context for prescribing, and MyCare.scot for patient-facing access direction. | Official NHS Scotland / NSS / NHS inform / SCI / Scottish Government sources | High for named services; moderate for detailed architecture until deeper technical sources are added | These services are not GP Connect or NHS England Spine, and service similarity is not evidence of InterSystems involvement. | Add current technical architecture, API, governance, and roadmap sources for ECS/KIS, SCI Gateway, CHI, NDP, MyCare.scot, and ePharmacy. |
| 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, 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 or live GP Connect use in Scotland. | Official Scottish Government / COSLA strategy, InterSystems office pages, Public Health Scotland, NHS Shetland FOI, and vendor Scotland evidence | High for Scottish strategy, 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; current national integration-platform and board-by-board status still need validation. | Add NHS Scotland / board publications, NSS material, contract registers, and current integrated-care-record sources. |
| 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; it does not currently prove GP Connect capability 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, or GP Connect evidence. Public DHCW pages expose limited architecture detail. | Add DHCW technical docs, Welsh Clinical Portal / Care Data Repository material, and LIMS 2.0 implementation updates. |
| Northern Ireland evidence supports a nation-specific encompass / EpicCare Link / My Care reading and a separate InterSystems Caché / NHAIS licensing fact: encompass is the regional single digital care record across HSC Trusts; GPs access it via EpicCare Link; primary care is currently outside encompass scope; My Care excludes GP records and GP-arranged tests; and Caché underpins NHAIS applications used primarily for GP registrations. No TrakCare, HealthShare, Health Connect, or GP Connect claim is supported. | Official DHCNI programme pages, Department of Health NI news, official procurement notice, and Rhapsody vendor boundary source | High for official Northern Ireland and NHAIS Caché facts; moderate for Rhapsody vendor integration context | Caché / NHAIS licensing does not prove an InterSystems care-record deployment. Future primary-care inclusion may change the encompass boundary. | Recheck DHCNI roadmap, BSO/eTendersNI procurement, and HSC Trust evidence 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: GOV.UK describes it as an integrated primary Health Record for clinical use plus a pseudo-anonymised central data warehouse, used as the source of electronic, integrated healthcare records for Defence primary healthcare and some MOD specialist care providers. | Official MOD/GOV.UK statistics background-quality report | High for DMICP baseline definition; boundary for current interface architecture | The source does not expose the current DMICP extract/API design, data model, migration route into CORTISONE, or Health Connect / HealthShare interface implementation. | Add DMICP interface catalogue, source data model, extract/API capability, migration status, 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. | Official GOV.UK programme page and MOD programme vision | High for programme existence, intent, and architecture themes | Vision/programme material does not prove full deployment or current live status of every capability. | Add current MOD programme delivery updates and technical architecture. |
| 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 architecture is a plausible but unproven target pattern: DMICP is the Defence source baseline, Health Connect is the preferred mediation/adapter layer, HealthShare is the preferred shared-care/EMPI/viewer target layer, NHS England connectivity must be proven through DSIC, GP Connect, Spine-connected services, PDS, ODS/SDS, MESH, ITK3, and named-standard / supplier-role analysis, and Wales, Scotland, and Northern Ireland require nation-specific adapters rather than DSIC or DUAA labels. | Wiki synthesis backed by official MOD/GOV.UK evidence, InterSystems product/documentation evidence, NHS England Digital service evidence, DSIC/DUAA evidence, PRSB evidence, and devolved-nation source sets | High for architecture relevance and evidence-boundary synthesis; not implementation proof | This does not prove the DMICP interface catalogue, a live Health Connect CORTISONE mediation route, HealthShare component configuration, DSIC compliance, GP Connect onboarding, clinical-safety/IG artefacts, or any devolved-nation HealthShare/Health Connect deployment. | Add DMICP interface specification, CORTISONE architecture, product/version scope, national-service onboarding packs, DSA/DPIA, DCB0129/DCB0160, supplier RACI, and nation-specific deployment 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. |
| GP Connect Update Record is currently framed by NHS England Digital as technically and clinically assured for community pharmacy to general practice in Pharmacy First, Blood Pressure Check, and Pharmacy Contraception service workflows, with named GP and community-pharmacy suppliers assured at the time of the page. | Official NHS England Digital service and transparency pages | High for service-facing scope and constraints | Service-facing page is edited 2024 but still current on the NHS site; supplier-progress and specification pages should be checked for status changes. | Track release notes after Update Record 1.2.1-public-beta and supplier progress after the 5 June 2026 snapshot. |
| The National Care Records Service roadmap identifies GP Connect Access Document pilots, additional GP Connect integrations, and increased interoperability with local Shared Care Records as current or near-term work. | Official NHS England Digital service and roadmap pages | High for NCRS roadmap direction | It is NCRS roadmap evidence, not proof that Access Document is universally available or implemented by a specific supplier. | Add pilot outcome evidence, named ICB/ambulance examples, and supplier-progress updates. |
| The NHS App roadmap links patient-facing GP Connect APIs to GP health-record access, linked-profile work, and future improvements for finding, downloading, or sharing GP record content. | Official NHS England Digital roadmap page | High for NHS App roadmap direction | It does not show supplier-by-supplier implementation or InterSystems support. | Track NHS App release notes and GP Connect patient-facing API supplier onboarding changes. |
| 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. | 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. | 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; research, automated decision-making/profiling, IDTA/Addendum transfer updates, and some companion subject-rights products remain on the guidance tracker until final ICO guidance is published. | 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. |