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. The current public introduction says Standards are the technical or operating conditions required for Catalogue Compliance and are used by the Catalogue Authority to assess supplier solutions.
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; see GP2GP Record Transfer for the four-nation and InterSystems boundary. | Health Connect/IRIS could route or transform if designed for the pattern. | No current public evidence proves InterSystems GP2GP DSIC provider, sending, requesting, or complete GP foundation-system capability. GP Connect evidence does not prove GP2GP. |
| 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 Structured | Effective DSIC S99 v1.0.4 structured GP EPR read route. Provider and consumer implementations are MUST requirements, with PDS or Spine Mini Services as a dependency. | 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. | DSIC standard status and NHS supplier-progress cells do not prove an approved DMICP use case, product configuration, local onboarding, complete record-cell support, or customer deployment. |
| GP Connect Send Document | Effective DSIC S101 v1.0.3 document route. Sender and receiver implementations are MUST requirements; the route depends on ITK3 and MESH, with Generic FHIR Receiver also required for receiver solutions. | NHS supplier-progress evidence maps IRIS for Health (Middleware) to Send Document (Send) v2.0.1. |
This does not prove a DMICP document route, every GP Connect capability, Health Connect implementation, or a HealthShare deployment. |
| GP Connect Update Record | Effective DSIC S102 v1.0.3 structured update route. Sender and receiver implementations are MUST requirements; the route depends on ITK3, MESH, and PDS or Spine Mini Services. Current public service-facing assurance remains the named community-pharmacy workflows. | Integration tooling could support message handling if assessed and onboarded. | The broader DSIC contracting-vehicle applicability does not create generic DMICP write-back approval, 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. |
| SNOMED CT, Read migration, and terminology services | Coded clinical content, historical Read / CTV3 migration, primary-care terminology, local-code mapping, and terminology validation. | HealthShare, Health Connect, IRIS for Health, FHIR Services, and TrakCare are relevant where they store, transform, display, validate, translate, or migrate coded data. Use Terminology Code Management and Read-to-SNOMED Mapping before treating this as product proof. | Need source terminology packages, SNOMED CT UK Edition and dm+d versions, Read / CTV3 map versions, NHS Terminology Server or local terminology-service architecture, CodeSystem / ValueSet / ConceptMap governance, clinical validation, provenance, and safety ownership. |
| 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, SRC-263, SRC-278 to SRC-285, SRC-291, SRC-292.
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. The current S101 page makes sender/receiver MUST roles and ITK3/MESH dependencies explicit. |
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 GP2GP Record Transfer when the question is patient registration, GP-to-GP record movement, migration, or foundation GP system responsibility. Use GP Connect pages when the question is approved record access, document send, structured update, patient-facing APIs, or supplier-progress rows. Do not treat one route as proof of the other, and do not treat the broader S102 catalogue applicability as approval for a new clinical use case.
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.
Use Terminology Code Management and Read-to-SNOMED Mapping where a DSIC, GP foundation, shared-care, migration, medicines, analytics, or interface question depends on SNOMED CT UK Edition, dm+d, historical Read / CTV3 content, local codes, or terminology-service operation. This keeps terminology release and mapping governance separate from generic FHIR, database, or integration-engine capability.
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, GP2GP, and terminology services where InterSystems or a partner product claims support, then connect GP2GP claims to GP2GP Record Transfer, terminology claims to Terminology Code Management and Read-to-SNOMED Mapping, and GP Connect / MESH / ITK3 claims to the dedicated Standards Directory child page.