Standards and Interoperability Evidence Domain
This domain page groups standards, interoperability, conformance, statutory data, and supplier-role evidence. It is a working slice of Sources and Evidence Matrix, not a replacement for either canonical register.
Domain Boundary
Standards and Interoperability includes product standards positioning, NHS England / DHSC standards governance, NHS Standards Directory surfaces, PRSB record-content standards, GP Connect, Message Exchange for Social Care and Health (MESH), Interoperability Toolkit 3 (ITK3), clinical-safety standards, terminology, FHIR, DUAA statutory standards context, UK healthcare-recording legal/professional position, healthcare-record source-layer pages, and UK interoperability assurance evidence.
It excludes:
- Customer deployment outcomes unless the source is customer-side, procurement-side, DPIA, FOI, programme, or implementation evidence.
- Product capability claims unless the source is InterSystems product documentation or supplier-progress / conformance evidence naming the relevant product or component.
- DSIC GP foundation compliance unless the evidence maps a named capability, national service, standard, supplier role, and deployment artefact.
- West Midlands or other local deployment trails unless they are used as examples of standards evidence type, not as the main standards-domain backlog.
- Scotland, Wales, Northern Ireland, Defence, or international evidence unless the source clarifies standards equivalence or a named InterSystems standards role.
Source Clusters
| Cluster | What they support |
|---|---|
| InterSystems product standards positioning | Product-level positioning for HealthShare Unified Care Record, HealthShare Clinical Viewer, shared-record content relevance, FHIR, HL7, DICOM, IHE, API exchange, FHIR Server, FHIR packages/profiles, OAuth/security, Network Connect, Health Connect Cloud, Cloud Services Portal, Bulk FHIR Coordinator, OMOP, SDA/CDA transformation, IRIS for Health ITK-documentation context, AI Assistant / Navigation Application adjacency, historical Clinical Viewer deployment clues, and the PDS FHIR integrated-products row for Intersystems HealthConnect 2020.1. |
| UK interoperability and ITK evidence | InterSystems NHS ITK accreditation claims, IRIS for Health ITK documentation, the NHS ITK conformance-process route, the NHS conformance-catalogue route, and the Solution Assurance compliance-catalogue exclusion boundary; still boundary evidence until a current public non-vendor row naming InterSystems is found. |
| PRSB and record-content standards | PRSB standards scope, PRSB Core Information Standard conformance for InterSystems Healthshare, and the CISS funding / future-maintenance caveat. |
| NHS England / DHSC governance and Standards Directory | NHS information-standard governance, DAPB/DAB, Standards and Collections, NHS Standards Directory discovery, FHIR/UK Core, GP Connect, MESH, ITK3, PDS/events, ODS organisation data, GP2GP/NHAIS, terminology, medicines, clinical safety, transfer of care, shared-record/life-stage, imaging, and diagnostics standards surfaces. |
| GP Connect and supplier-progress standards evidence | GP Connect service/capability definitions, Access Record, Access Document, Send Document, Update Record, Patient Facing APIs, supplier-progress mapping, NHS API context, roadmap material, and the difference between NHS service evidence and InterSystems implementation proof. |
| DUAA and ICO standards-adjacent governance | Data (Use and Access) Act 2025 statutory context, section 121 / Schedule 15 health/adult social care information-standard implications, staged commencement, ICO data-protection-provision status, topic guidance, and remaining guidance-tracker items. |
| UK healthcare recording legal and professional position | UK GDPR, DPA 2018, PECR, Access to Health Records Act, public-records and access-route boundaries, common law confidentiality, Caldicott, NHS Act 2006 section 251, provider governance, professional record-keeping, candour, devolved records-management codes, SNOMED CT, PRSB/provenance, DCB0129/DCB0160, Health and Care Act 2022 mandatory information-standard changes, National Data Guardian context, and DUAA supplier/IT-service extension. |
| Programme and identifier context | HL7 UK InterSystems OIDs and Programme CORTISONE open-standards / NHS-interface relevance, without converting identifiers or programme vision into specific product conformance. |
Evidence Claims
| Claim | Evidence status | Canonical detail |
|---|---|---|
| Standards Directory entries are standards-surface evidence, not product implementation proof. | High for the evidence boundary. | NHS Standards Directory and DHSC Standards Direction |
| GP Connect, MESH, and ITK3 are distinct NHS England service or standards surfaces and should not be collapsed into one "connectivity" claim. | High for the role split; supplier/customer implementation remains deployment-specific. | NHS Standards Directory GP Connect, MESH, and ITK3 |
| GP Connect Update Record is a distinct community-pharmacy structured write-back capability. It uses a MESH / ITK3 / FHIR STU3 messaging pattern, but it is not the same thing as GP Connect Send Document, Access Record, or a generic GP record write API. | High for NHS API/integration definition; boundary for supplier rollout and InterSystems support. | GP Connect Update Record, GP Connect Update Record Due Diligence |
| PRSB Core Information Standard evidence currently supports an InterSystems Healthshare conformance fact, while wider PRSB and transfer-of-care standards remain applicability evidence unless product or customer proof maps them to a deployment. | High for the named PRSB CIS listing; boundary for other standards. | PRSB Core Information Standard (PRSB CIS), PRSB Standards |
| DUAA section 121 / Schedule 15 strengthens supplier-role questions for England health/adult social care IT and IT-service providers, but it does not replace DSIC catalogue evidence, GP Connect supplier-progress evidence, PRSB conformance, DCB0129/DCB0160 safety evidence, or customer deployment artefacts. | High for statutory-context boundary; implementation claims still need named-standard and deployment evidence. | Data (Use and Access) Act 2025, NHS Standards Directory and DHSC Standards Direction |
| UK healthcare recording is a layered legal, professional, provider-governance, records-management, and digital-standards question. UK GDPR, DPA 2018, PECR, confidentiality, section 251, professional record duties, candour, records-management codes, SNOMED CT, PRSB/provenance, DCB0129/DCB0160, Health and Care Act 2022, and DUAA should not be collapsed into a single compliance label. | High for the assurance model; not legal advice or implementation proof. | UK Healthcare Recording Legal and Professional Position |
| Repeated healthcare-record source-layer labels should resolve to canonical source-layer pages rather than remaining as unexplained table text. The source-layer map routes GMC, NMC, HCPC, GPhC, CQC, candour, NICE, data-protection, DSA/DPIA, records-management, PRSB, NHS standards, DCB0129/DCB0160, and public-records/access-route labels to maintained pages or sections. | High for wiki navigation and evidence discipline; not a replacement for source IDs. | Healthcare Record Source Layers |
| InterSystems product documentation supports technical plausibility for standards-oriented integration, presentation, and access patterns, but customer deployment, assurance, onboarding, and operational status require separate evidence. Health Connect, IRIS for Health, FHIR Services, HealthShare Unified Care Record, HealthShare Clinical Viewer, and HealthShare / PRSB CIS now have high-risk product-map audits separating product capability or conformance facts from NHS conformance, onboarding, managed-service assurance, programme/customer evidence, validation scope, profile support, presentation/access configuration, AI-adjacent governance, identity/directory dependency evidence, and deployment proof. | High for product-mechanics, presentation/access, identity/directory dependency, and conformance-scope boundaries. | InterSystems Standards Product Map, FHIR Services, Health Connect, IRIS for Health, HealthShare Unified Care Record, HealthShare Clinical Viewer, PRSB Core Information Standard (PRSB CIS) |
Routing Decisions
Use this page for source/evidence orientation and proof-boundary decisions. Keep detailed synthesis in the existing module pages:
| Question | Route first to | Why |
|---|---|---|
| Which standards families are relevant to InterSystems? | Standards and Interoperability | The overview already summarises standards evidence areas and links detail pages. |
| Which NHS Standards Directory entries matter? | NHS Standards Directory and DHSC Standards Direction | The parent map keeps standards families and DUAA crosswalk together. |
| How do GP Connect, MESH, and ITK3 split by role? | NHS Standards Directory GP Connect, MESH, and ITK3 | The child page carries the item-level standards surface and role split. |
| How should Update Record be separated from other GP Connect capabilities? | GP Connect Update Record | Update Record has a narrower pharmacy write-back scope and should not be inferred from Send Document or Access Record evidence. |
| What does DUAA change for standards analysis? | Data (Use and Access) Act 2025 | DUAA is statutory context for supplier-role questions, not standalone conformance. |
| What is the UK legal and professional position on recording healthcare information and delivery? | UK Healthcare Recording Legal and Professional Position | The page separates UK GDPR, DPA 2018, PECR, confidentiality, section 251, professional duties, provider governance, candour, records management, and digital standards before any product or deployment claim is assessed. |
| Where should a source-layer acronym or shorthand label route? | Healthcare Record Source Layers | The page maps repeated labels such as GMC, NMC, HCPC, GPhC, CQC, NICE, PRSB, DSA/DPIA, DCB0129/DCB0160, records management, and public-records access routes to canonical pages or sections. |
| How should a standards or conformance claim be turned into an evidence request? | This page's reusable standards-conformance evidence request pattern | The pattern is generic and can be reused by sibling projects without depending on the PRSB CIS page. |
| How has the reusable pattern been applied outside PRSB? | GP Connect InterSystems Supplier Progress | The GP Connect supplier-progress request pack converts NHS row evidence into product/version, validation-scope, exclusion, component, adjacent-standard, and deployment-artefact requests when those rows are being relied on for assurance. |
| What is proven for InterSystems implementation? | Evidence Matrix and product/customer module pages | Implementation claims need product documentation, supplier-progress, conformance, procurement, DPIA, customer, or deployment evidence. |
Implementation-Proof Slice: NHS ITK
Use NHS Interoperability Toolkit (ITK) as the first narrow implementation-proof slice for this domain. The current evidence is enough to preserve the historical InterSystems ITK claim and the current NHS conformance-process and conformance-catalogue routes, but not enough to claim current independent accreditation or customer deployment status for a named product/version.
The 2026-06-20 current-source recheck found no current public NHS or standards-body row naming InterSystems, HealthShare, Health Connect, or IRIS for Health in the rendered ITK catalogue or targeted public search. The NHS Solution Assurance compliance catalogue is useful as a boundary source because it explicitly excludes Interoperability Tool Kit Accreditation; Healthshare-named rows there are not ITK proof.
| Proof layer | Evidence required | Why it matters |
|---|---|---|
| Current register or certificate | NHS or standards-body record naming InterSystems, product, version, ITK standard, certificate type, certificate date, and status. | Converts vendor/history evidence into current non-vendor conformance evidence. |
| Product/version scope | InterSystems documentation naming the component and version that implements the ITK route, such as IRIS for Health, Health Connect, or a partner packaging. | Prevents a historical corporate accreditation claim from becoming a generic product-family claim. |
| Message/profile scope | The specific ITK interaction, message profile, transport, payload, endpoint, workflow, and dependency standards in scope. | Keeps ITK separate from GP Connect, MESH, PRSB, or general FHIR/HL7 positioning. |
| Assurance and testing pack | Test results, conformance pack, implementation guide, sample payloads, validation evidence, and release/change-control notes. | Shows how the standard is implemented and maintained rather than only marketed. |
| Deployment artefacts | Customer architecture, DSA/DPIA where applicable, DCB0129/DCB0160 if patient-care workflow is affected, operational support model, monitoring, incident process, and go-live/current-status evidence. | Proves local use and operational responsibility in a named deployment. |
Reusable Standards-Conformance Evidence Request Pattern
Use this pattern for any standards, certificate, register, validation, supplier-progress, or conformance claim where a product, supplier, component, or deployment could be over-read from a headline evidence point. It is the canonical wiki pattern for sibling projects; pages such as PRSB Core Information Standard should point back to it and keep only standard-specific assurance scope. Do not request patient-identifiable information, credentials, private keys, endpoint certificates, or non-disclosable operational details.
| Request area | Ask for | Why it matters |
|---|---|---|
| Certificate or register record | Current certificate, public register extract, certificate reference, issuing body, supplier name, product/component name, product version or build, standard/profile/capability, issue date, expiry date, current status, and any withdrawal or supersession note. | Confirms the headline fact and prevents a stale, renamed, or differently scoped row becoming current proof. |
| Validation and test scope | Validation report summary, standard version, profiles or capabilities assessed, test method, criteria, assessment date, test environment, evidence-pack index, and assessor or standards-owner role. | Shows what the conformance or supplier-progress claim actually covered. |
| Exclusions and caveats | Explicit exclusions, optional sections not assessed, unsupported data items, local-configuration assumptions, third-party dependencies, customer prerequisites, and conditions attached to the claim. | Prevents over-reading conformance into complete standard coverage or every possible workflow. |
| Component coverage | Named components or modules assessed directly, indirectly, as supporting infrastructure, or out of scope; include product packaging and customer-licensed-scope boundaries where available. | Keeps supplier/product evidence separate from component-level or module-level evidence. |
| Adjacent standards | Separately evidenced related standards, APIs, national services, clinical-safety standards, information-governance artefacts, and onboarding routes tied to the same product/version or deployment. | Distinguishes independent proof from standards only mentioned beside the headline claim. |
| Deployment artefacts | Customer-approved architecture summary, data-flow or interface map, role/view model, RBAC/SSO/audit configuration, DSA/DPIA references, DCB0129/DCB0160 responsibility split where patient-care workflow is affected, operational owner, support model, go-live date, and current-status statement. | Converts product-level or standards-level evidence into deployment-specific assurance without exposing sensitive implementation detail. |
Open Evidence Work
- Current public non-vendor NHS ITK accreditation or conformance-catalogue record naming InterSystems; use the evidence request template on the NHS ITK Accreditation page when contacting suppliers, customers, NHS England, or standards bodies.
- Deployment-specific healthcare-recording evidence packs that show legal basis, special-category condition, confidentiality route, PECR controls where applicable, record amendment/export/search procedure, retention/disposal policy, access-control/provenance/audit design, clinical-safety case, information-standard applicability, supplier RACI, and local professional/provider workflow support.
- Project-wide linking passes for source-layer labels should start from the Healthcare Record Source Layers map and link visible synthesis tables to the canonical page or section; do not create duplicate pages for one-off labels.
- Manual acquisition or official confirmation of any detailed ITK catalogue spreadsheet row if the public download cannot be reliably retrieved from the rendered page.
- Use the reusable standards-conformance evidence request pattern on this page when a certificate, register, validation, supplier-progress, or supplier claim needs conversion into product/version, scope, exclusions, component coverage, adjacent standards, and deployment evidence.
- Use the GP Connect InterSystems supplier-progress request pack as a worked example when a supplier-progress row is being used as assurance rather than only as source-register evidence.
- Product documentation that explicitly maps HealthShare, Health Connect, IRIS for Health, FHIR Services, or other components to named NHS Standards Directory entries.
- Customer deployment packs proving GP Connect, MESH, ITK3, PDS/events, ODS/SDS, terminology, medicines, clinical safety, or transfer-of-care standards in a named implementation.
- Rechecks when NHS Standards Directory entries, GP Connect supplier-progress rows, PRSB CIS Version 3, DHSC standards operating model, or final ICO DUAA guidance products change.
- Standards-specific supplier responsibility matrices that separate GP foundation provider, GP Connect consumer, document sender, middleware, shared-care viewer, hosting/processor, and patient-facing roles.