DSIC Standards and National Services
For current laboratory and imaging connections, use Diagnostic Results and Image Exchange: it distinguishes live EDIFACT/MESH, the pathology FHIR pilot and NIR beta from later rollout plans.
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.
Onboarding check (8 September 2026): new developers can no longer onboard through GP Connect for Send Document, Update Record or Appointment Management; existing consumer suppliers can still onboard end users. Apply the current service boundary before treating a capability or DSIC standard as an available integration route.
Use DSIC Capability-to-Standard Crosswalk for the structured view of capability dependencies.
The UK Core Services Matrix uses DSIC as an England comparison lens, including functions that have no verified counterpart in every nation. Its cross-border reuse analysis distinguishes shared services from common standards and functional counterparts; England catalogue applicability does not establish devolved adoption.
Standards Model
The S99/S101/S102 pages were rechecked on 8 September 2026. Their effective versions and mandatory roles remain as below. S99 now lists five contracting vehicles: GP IT Futures, Tech Innovation, Community Pharmacy Clinical Services, Digital Pathways Solution Registry and Digital Primary Care. S101 lists GP IT Futures, Tech Innovation, Digital Pathways Solution Registry and Digital Primary Care. S102 retains the four vehicles including Community Pharmacy Clinical Services. These applicability lists do not establish an award, a supplier listing or an available new-developer onboarding route.
| 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. |
September 2026 Function and Version Check
Checked 29 September 2026. These are effective DSIC document versions, not API versions, deployment status or blanket requirements for every supplier. Apply the capability, contracting vehicle and provider/consumer role before selecting a route.
| Function | Verified catalogue baseline | Role and applicability boundary |
|---|---|---|
| Staff identity, patient identity and proxy access | S54 Authentication 2.0.2 and S68 NHS login 2.0.3, effective 10 September; S125 login Provisioning 1.0.0, 9 September; S114 VRS 1.0.1, 23 September. | CIS2 authenticates staff; NHS login authenticates patients; provisioning lets staff create/upgrade patient accounts; VRS supplies verified relationships/proxy roles. These are separate controls. C13 limits its VRS selection to proxy and patient fully registered at the same practice. |
| Registration and notifications | C13 Patient Information Maintenance 10.0.2, effective 23 September; S53 2.0.4, S113/S111/S112 1.0.1, effective 4 December 2025. | S53 handles registration/demographic transactions; S113 retrieves the registration application's health/lifestyle information; S112 MNS signals a validated registration request; S111 NEMS supplies PDS Record Change events. Neither a signal nor a submitted application proves registration is complete. |
| Professional GP access, updates and booking | S98 HTML 1.0.2; S99 Structured 1.0.4; S100 Appointment Management 1.0.1; S101 Send Document/S102 Update Record 1.0.3; S47 IM1 2.1.1, effective 9 September. | C5 supplies the GP appointment-provider workflow; C23 covers cross-organisation booking consumption. IM1 interfaces are supplier-specific; use the applicable GP Connect interface where available. Effective standards do not reopen closed new-developer onboarding for appointment management, document send or update. |
| Patient-facing GP APIs | S103 Prescriptions, S104 Access Record, S105 User Permissions: all 1.1.0, effective 9 September. | These provider interfaces explicitly do not require GP Linkage Keys. This does not remove legacy IM1 linkage-key obligations. The current GP Connect service page still describes New Market Entrant providers and NHS App consumption, with its additional-consumer restriction dated July 2025. |
| Vaccination and screening flows | S116 Vaccination Extract 3.0.0, effective 30 June; S58 Screening Messaging 1.0.2, effective 4 December 2025. | New vaccination solutions submit supported vaccine events through Immunisation FHIR at recording; existing daily-extract implementations retain their daily MESH route. NHS004 screening-result messages must be distinguished from ordinary pathology. Neither route establishes the whole invitation/recall service. |
| Extraction, verification and appointment reporting | S46 GPES 1.0.1; C10 GP Extracts Verification 1.0.2; S62 GP Appointments Data Reporting 4.0.1. | C10 verifies GPES extracts used by CQRS; GPES supports specified payment, statistical and direct-care collections. S62 is a separate weekly appointment-data flow. Extraction and payment evidence do not establish a payment-execution API. |
| Patient communications | S124 NHS Notify 1.0.0, effective 16 April; C7 Communication Management 1.2.0, effective 15 June. | App messages, email, text and letters via API or MESH are distinct from clinical document filing. S124 currently lists Digital Pathways Solution Registry; it is not a universal mandate on every GP component. |
The current GP Links guide says Items of Service transactions are obsolete. Historical NHAIS descriptions of payments, screening and multi-nation coverage must not be read as proof of current shared backends or supported transaction scope.
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 | Registration-driven GP record transfer; GP2GP Record Transfer covers the four-nation boundary and GP2GP Requesting Adapter the England FHIR receiving route. S43 depends on requesting/sending adaptors, PDS FHIR, SDS FHIR, GP Connect migration operations and GP Registrations MI. | Health Connect/IRIS could route or transform if designed for the pattern. | GP Connect read or messaging evidence does not prove GP2GP migration and filing responsibilities. No current public InterSystems GP2GP implementation or complete GP foundation-system capability is proven. |
| 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. | The June supplier snapshot mapped IRIS for Health (Middleware) to Send Document (Send) v2.0.1; its row is absent in September, so current status is unconfirmed. |
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 and its own Directory of Services | Service selection and referral workflow within e-RS. | Integration tooling can connect assessed referral workflows. | The e-RS directory is distinct from UEC DoS and public DoHS service listings. |
| UEC DoS, BaRS and NHS 111 reports | Separate discovery, booking/referral and report-receiving functions; apply S107, S93 and S33 to the relevant capability and role. | Integration tooling may route or transform messages, subject to product and route assurance. | S107 is currently scoped to community pharmacy; S93's GP/care-navigation mapping is pharmacy-referral sending; S33 covers 111 receivers. Generic FHIR/ITK support proves none of these implementations. |
| 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.
Urgent-Care Requirements and Role Boundaries
Checked 29 September 2026 against the current DSIC content, including its public Confluence API. These are effective DSIC document versions. They do not establish UK-wide mandates, universal route availability or supplier deployment. See England's routing stages and the four-nation matrix.
| Standard | Current requirement | Scope to preserve |
|---|---|---|
| S33 NHS 111, 2.0.5, effective 18 September 2026 | Receive 111 messages using the NHS 111 Report adaptor or a direct V2.1 RC1 implementation. | C13 Patient Information Maintenance – GP maps to primary GP and copy-recipient CDA reports. Only 111 providers implement sender requirements, outside this receiving-solution standard's scope. |
| S93 BaRS, 2.0.3, effective 10 September 2026 | Implement the applicable BaRS core/application mapping. | C11 Referral Management – GP and C67 Care Navigation map to sending referrals into pharmacy; C69 Referral Management – Community Pharmacy maps to receiving them. This does not require every GP component to implement every urgent-care BaRS application. |
| S107 UEC DoS, 1.0.3, effective 10 September 2026 | Implement the UEC DoS REST API. | Its current contracting vehicle is Community Pharmacy Clinical Services. This is distinct from 111's SOAP-based clinical service selection and is not a universal GP-system mandate. |
| S100 GP Connect Appointment Management, 1.0.1 | Apply the provider/consumer requirements with the relevant appointment capability. | C5 provides the GP appointment workflow; C23 consumes cross-organisation booking. National service status and effective DSIC requirements do not reopen new-developer onboarding. |
The active NHS 111 API uses synchronous ITK SOAP with CDA, while the Report adaptor converts the received content to FHIR. Keep this distinct from GP Connect document/update routes that use ITK3/MESH, and from BaRS FHIR workflow exchange. A report receipt, booked slot, clinical referral and referral outcome require separate workflow evidence.
The newer DoS Search API is a staged replacement: the checked specification provides organisation/endpoint lookup but marks HealthcareService and triage-code searches unavailable in UAT/production. A published endpoint schema or production/beta label is therefore insufficient evidence for replacing the live UEC SOAP/REST route.
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 for patient registration, GP-to-GP record movement and foundation GP system responsibility. Its Requesting Adapter page explains the reuse of GP Connect migration operations. Use GP Connect pages for other record-access, document-send, structured-update, patient-facing and supplier-progress questions. Assurance for one workflow does not prove another; broader S102 catalogue applicability does not approve a new clinical use case.
Current S43 directs FHIR implementation assurance to the DSIC onboarding guidance: engage the Supplier Manager for a tailored technical and clinical assurance approach. NHS-assured adaptor components do not remove integrating-supplier assurance; a bespoke implementation requires additional assurance.
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.