DSIC Standards and National Services
DSIC compliance depends on standards and national-service connectivity as much as on user-facing GP workflow. The public DSIC standards pages split the model into overarching standards, non-overarching standards, capabilities, supplementary-care capabilities, and pages that show which standards apply to which capabilities.
Use DSIC Capability-to-Standard Crosswalk for the structured view of capability dependencies.
Standards Model
| Standards category | Meaning | Examples visible in the current DSIC/NHS evidence set |
|---|---|---|
| Overarching standards | Baseline obligations that apply broadly to supplier services, regardless of an individual capability. | Clinical safety, information governance, hosting, business continuity and disaster recovery, data migration, training, service management, testing, non-functional requirements, interoperability, and commercial obligations. |
| Non-overarching standards | Specific national services, APIs, message patterns, data standards, or integration routes. | GP Connect, PDS, ODS/SDS, GP2GP, SCR, EPS, e-RS, MESH, ITK, NHAIS, NHS login, NEMS, GPAD, GPES, NHS 111, Yellow Card, eMED3, National Data Opt-Out, pathology/diagnostics, Dictionary of Medicines and Devices, and Directory of Services. |
| Capability-linked standards | Standards attached to a DSIC capability, sometimes conditionally by service role or care setting. | Patient information maintenance links to PDS, ODS/SDS, GP2GP, NHAIS, SCR, GP Connect, GPES, NEMS, NDO, and related routes; appointments link to GP Connect appointment management and GPAD; consultation links to eMED3 and Yellow Card. |
| Supplier-specific assurance | Testing, onboarding, conformance, clinical safety, first-of-type deployment, and supplier-progress status. | GP Connect supplier progress records by capability and supplier, ITK conformance routes, and DSIC catalogue agreement obligations. |
National-Service Dependency Map
The following table groups the NHS England services most relevant to DSIC GP system and software components. It is a practical architecture map, not a claim that every DSIC service must use every route.
| Service or standard | Role in DSIC GP software | InterSystems relevance | Evidence boundary |
|---|---|---|---|
| PDS | National demographics and patient identity checks. | EMPI and integration tooling can support local identity matching and PDS integration patterns; PDS integrated-products evidence names Intersystems HealthConnect 2020.1, not EMPI. |
PDS use still requires NHS onboarding, API/security controls, local-copy synchronisation, invalid/superseded NHS-number handling, local back-office workflow, safety warnings, and local demographic governance. |
| ODS / SDS | Organisation identity, reference data, endpoint/addressing context, and organisation-code validation. | Provider Directory and integration tooling are relevant to provider and organisation data patterns. | ODS/SDS use still requires product/version evidence, authoritative-source choices, local synchronisation, directory stewardship, audit, and role/organisation governance. |
| GP2GP | Electronic transfer of GP records when patients move practices. | Health Connect/IRIS could route or transform if designed for the pattern. | No current public evidence proves InterSystems GP2GP DSIC provider capability. |
| SCR | Summary Care Record creation/access in England. | Shared-care and viewer platforms may consume or present national-record information where approved. | SCR provider/consumer status is service-specific and not automatic from HealthShare branding. |
| GP Connect Access Record | Read-only GP record access through approved systems. | HealthShare is plausible as a shared-record consumer/presentation layer; NHS supplier-progress evidence maps HealthShare to Access Record: Structured Medications, Allergies, Immunisations, and Uncategorised. | Capability and version status in the NHS table does not prove product configuration, local onboarding, Access document support, or customer deployment. |
| GP Connect Send Document | MESH-based sending of consultation summaries into GP practices. | NHS supplier-progress evidence maps IRIS for Health (Middleware) to Send Document (Send) v2.0.1. |
This does not prove all GP Connect capabilities or a HealthShare implementation. |
| GP Connect Update Record | Structured pharmacy-to-GP update route using MESH/ITK3/FHIR STU3 in defined approved service workflows. | Integration tooling could support message handling if assessed and onboarded. | It is not a generic write-back API and no current InterSystems-specific support is proven. |
| MESH | Message exchange used by GP Connect Send Document, Update Record, and other NHS messaging patterns. | Health Connect/IRIS are architecturally relevant as messaging and integration engines. | MESH connectivity needs mailbox, workflow, endpoint, clinical-safety, and operational assurance. |
| ITK / ITK3 | Messaging and distribution standards used by some NHS workflows. | InterSystems has vendor ITK accreditation claims and current IRIS documentation references historical ITK context. | Current public NHS catalogue evidence naming InterSystems is still missing. |
| EPS and dm+d | Electronic prescribing, medicines identity, and medication-data safety. | HealthShare can aggregate medicines data; Health Connect/IRIS can integrate medicines messages. | A GP prescribing module still needs DSIC capability and EPS-specific assurance. |
| e-RS / Directory of Services | Referral service selection, referral creation, and referral workflow. | Integration tooling can connect referral workflows. | A full GP referral module or route must be assessed and onboarded. |
| NHS login / NHS App / patient-facing APIs | Citizen access, patient-facing record, prescription, appointment, and proxy workflows. | Personal Community is relevant as a patient digital-front-door product, and HealthShare can provide record data. | NHS login, patient-facing GP Connect, NHS App integration, proxy access, and consent rules remain separate assurance tasks. |
| GPAD and GPES | Appointments and extraction/reporting routes. | Analytics and data-platform components can process approved extracts or reporting feeds. | Reporting must respect data-sharing, extraction, and supplier-specific obligations. |
| NEMS / NRL / events | Event and record-pointer patterns for wider interoperability. | HealthShare and Health Connect have strong shared-care/integration relevance; NHS NRL already names InterSystems sites in West Midlands context. | Event or pointer use is specific to approved deployments and does not imply DSIC foundation status. |
Source IDs: SRC-019, SRC-025, SRC-026, SRC-027, SRC-028, SRC-038, SRC-039, SRC-040, SRC-041, SRC-045, SRC-047, SRC-057, SRC-099, SRC-132, SRC-183, SRC-184, SRC-185, SRC-194, SRC-206, SRC-207, SRC-234, SRC-235.
Capability to Standard Relationships
The DSIC interoperability relationship material is important because it prevents a supplier from treating a capability as purely local software. Public examples include:
| Capability | Standards relationship reading |
|---|---|
| Patient Information Maintenance - GP | Links to national identity, registered-practice and organisation context, registration, record transfer, record access, data extraction, update/document flows, patient-facing controls, and event/message routes including PDS, ODS/SDS, NHAIS, GP2GP, SCR, GP Connect, GPES, NDO, NEMS, MESH/MNS, DMP, and related national services. |
| Appointments Management - GP | Links to GP Connect appointment management and GP Appointment Data, with patient-facing appointment access where in scope. |
| Consultation Management - GP | Links consultation workflow to Yellow Card, eMED3, GP Connect, and extraction/reporting dependencies where applicable. |
| Prescribing | Links to medicines, EPS, dm+d, safety, record content, patient-facing prescription visibility, and downstream medication-sharing needs. |
| Document and messaging capabilities | Link to MESH, ITK, GP Connect Send Document, Access Document, transfer-of-care FHIR, and local document-management obligations. |
Developer Integration Context
NHS developer guidance for GP software explains the national-service integration landscape for GP suppliers and integrators. It groups GP software integration around services such as PDS, GP2GP, EPS, e-RS, GP Connect, MESH, ITK, NHS login, NHS App and patient-facing routes, National Data Opt-Out, and reporting/extraction services. This is the developer-side complement to the DSIC capability and standards catalogue.
Use NHS Standards Directory GP Connect, MESH, and ITK3 for the detailed Standards Directory dependency chain and role split where a HealthShare, Health Connect, IRIS for Health, or partner deployment touches GP Connect messaging or record-access standards.
The practical implementation pattern is:
- Identify the DSIC capability being offered.
- Identify every DSIC standard attached to that capability.
- Determine whether the product is a provider system, consumer system, broker/integration component, viewer, patient-facing product, or analytics/reporting component for each standard.
- Complete NHS onboarding, assurance, conformance, certificate, endpoint, mailbox, clinical-safety, data-protection, and operational requirements for that role.
- Prove capability in the DSIC catalogue, supplier-progress page, customer architecture, or programme documentation.
InterSystems Connectivity Interpretation
InterSystems has strong product evidence for standards-capable integration components:
- Health Connect supports common healthcare standards including FHIR, HL7 v2/v3, IHE profiles, CDA/C-CDA, DICOM, and X12 in current documentation.
- IRIS for Health is positioned as a FHIR-based healthcare data and application platform.
- InterSystems FHIR Server supports FHIR storage and REST API access, with OAuth security and cloud-service deployment patterns documented.
- HealthShare UCR supports longitudinal record aggregation, normalisation, deduplication, analytics, FHIR applications, and clinical-viewer access.
Those product facts are relevant, but DSIC compliance still requires role-specific proof. A HealthShare deployment consuming GP Connect is a different assurance problem from a GP foundation system providing GP Connect, GP2GP, EPS, PDS, SCR, and prescribing functionality. A middleware route handling MESH or ITK messages is different again.
Follow-up Evidence
- Capture a structured export or stable snapshot of DSIC capability-standard relationships for all core GP capabilities.
- Confirm whether public catalogue entries show InterSystems products against DSIC standards beyond current GP Connect supplier-progress evidence.
- Add product-specific implementation guides for PDS, ODS/SDS, MESH, ITK3, GP Connect, EPS, e-RS, NHS login, and GP2GP where InterSystems or a partner product claims support, then connect them to the GP Connect / MESH / ITK3 Standards Directory child page where applicable.