NHS Standards Directory GP Connect, MESH, and ITK3
This child page sits under NHS Standards Directory and DHSC Standards Direction. It keeps the GP Connect / MESH / ITK3 standards relationship detailed without overloading the parent standards map.
Current Reading
GP Connect, MESH, and ITK3 should be treated as distinct standards and service surfaces:
- GP Connect defines NHS England API/service capabilities for GP-practice record access, document access, appointment management, patient-facing prescriptions, document sending, and structured record update.
- MESH is the message/file exchange route used by several NHS workflows, including GP Connect Send Document and Update Record style patterns.
- ITK3 is a messaging-distribution FHIR API standard used with MESH and FHIR payloads for relevant document/message routes.
A Standards Directory entry proves that the standard is recognised in the NHS England health and adult social care technology landscape. It does not prove that InterSystems, HealthShare, Health Connect, IRIS for Health, a customer deployment, or a partner service implements that standard.
The public DSIC catalogue was rechecked on 11 August 2026. It shows three separate effective GP-record exchange standards: S99 Access Record Structured v1.0.4 for structured read, S101 Send Document v1.0.3 for document delivery, and S102 Update Record v1.0.3 for structured write-back. Each has its own mandatory supplier roles and dependencies.
Update Record remains separate from Send Document and Access Record. Its effective DSIC standard is listed for GP IT Futures, Tech Innovation, Community Pharmacy Clinical Services, and Digital Primary Care, while current public service-facing assurance evidence remains the named community-pharmacy workflows. Treat the first as catalogue applicability and the second as deployed-use evidence; neither proves a DMICP/CORTISONE route or InterSystems support. Use GP Connect Update Record for the capability boundary and GP Connect Update Record Due Diligence for implementation questions.
DUAA section 121 / Schedule 15 changes the supplier due-diligence question because information standards 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 England. That still does not create a generic "DUAA-compliant" product claim. It makes supplier role, named-standard applicability, product/version, and customer artefacts more important.
Standards Surface Map
| Surface | Directory / NHS evidence | Likely InterSystems relevance | Proof needed before using as implementation claim |
|---|---|---|---|
| GP Connect Access Record: Structured | Active Standards Directory/API context plus effective DSIC S99 v1.0.4, which requires provider and consumer implementations and depends on PDS or Spine Mini Services. | HealthShare may consume structured GP record data for UCR / Clinical Viewer use; IRIS for Health or Health Connect could broker, validate, transform, or route data depending on architecture. | Supplier-progress row mapping, approved use case, consumer/provider role, endpoint/security evidence, FHIR profile/version conformance, PDS/Spine dependency evidence, clinical testing, data-sharing agreement, and customer deployment artefacts. |
| GP Connect Access Record: HTML | Standards Directory entry for HTML view access to GP record information. | Clinical Viewer or shared-care portals may be adjacent where a deployment uses GP Connect content for direct-care viewing. | Approved use case, user role/access model, rendering/display policy, audit, clinical-safety case, and evidence that HealthShare or another component is the configured consumer. |
| GP Connect Access Document | Standards Directory entry and NHS roadmap/pilot context for document access. | Relevant to shared-care record and viewer patterns if the deployment retrieves GP documents into a care-record view. | Pilot/status evidence, supplier onboarding, document retrieval architecture, provenance/display rules, audit, and local clinical-safety evidence. |
| GP Connect Appointment Management | Standards Directory entry for GP appointment functions. | Relevant only if an InterSystems-backed service offers, consumes, or brokers appointment functions; HealthShare alone is not a GP appointments book in current public evidence. | Supplier capability listing, GP foundation or partner role, appointment workflow, RBAC, audit, testing, and patient-facing policy if exposed to patients. |
| GP Connect Send Document | Active Standards Directory/API context plus effective DSIC S101 v1.0.3. Sender and receiver implementations are MUST requirements; ITK3 and MESH are dependencies, with Generic FHIR Receiver also required for receiver solutions. | Current NHS supplier-progress evidence maps IRIS for Health (Middleware) to Send Document (Send) v2.0.1. |
Product/customer evidence, approved use case, sender/receiver role, MESH mailbox, workflow ID, certificates, ITK3/FHIR payload validation, Generic FHIR Receiver scope where relevant, error handling, monitoring, and clinical-safety case. |
| GP Connect Patient Facing Prescriptions | Standards Directory entry for patient-facing prescriptions context. | Relevant to Personal Community or patient-facing components only if a deployment explicitly integrates patient-facing GP Connect routes. | NHS login / patient identity route, proxy/safeguarding model, patient-facing API assurance, accessibility, content controls, and local controller approval. |
| MESH API | Standards Directory entry for Message Exchange for Social Care and Health. | Health Connect and IRIS for Health are relevant middleware candidates for message routing, monitoring, transformation, and operational support. | MESH mailbox ownership, certificates, endpoint design, workflow IDs, message validation, retry/failure handling, monitoring, service desk responsibilities, and incident process. |
| ITK3 Messaging Distribution FHIR API Standards | Standards Directory dependency for FHIR messaging distribution in relevant routes. | Relevant to IRIS for Health and Health Connect where they generate, validate, transform, or route ITK3 FHIR messages. | Implementation guide, FHIR version/profile mapping, message header/workflow handling, validation results, conformance evidence, and supplier support model. |
| GP Connect Update Record | Effective DSIC S102 v1.0.3 requires sender and receiver implementations and depends on ITK3, MESH, and PDS or Spine Mini Services. It is listed across four contracting vehicles, while NHS API/service evidence currently supports named community-pharmacy assured workflows. | Useful as a defined structured-write architecture route if a use case is approved; not evidence that any InterSystems product supports generic GP record write-back or that DMICP may act as sender. | Exact approved use case, contracting vehicle, sender/receiver supplier assurance, PDS/Spine dependency, MESH/ITK3/FHIR payload tests, clinical governance, GP supplier support, and customer deployment evidence. |
Role Split For HealthShare And InterSystems Components
Do not collapse GP Connect, MESH, ITK3, and HealthShare into one generic "connectivity" claim. The compliance reading changes by role.
| Role | What it means | HealthShare / InterSystems reading | Key artefacts |
|---|---|---|---|
| GP foundation provider system | The system of record for GP practice workflows and national-service obligations. | Current public HealthShare evidence does not prove full GP foundation-system coverage. A partner GP foundation supplier may own this role. | DSIC capability listing, GP2GP/NHAIS/EPS/e-RS/PDS/SCR evidence, migration/training pack, DCB0129, and catalogue status. |
| GP Connect consumer | A system consumes GP practice information for approved direct-care use. | Strong fit for HealthShare UCR / Clinical Viewer where GP data is surfaced in a shared-care record, if approved and onboarded. | GP Connect onboarding, approved use case, security, RBAC, audit, data-sharing agreement, display policy, and deployment safety case. |
| GP Connect document sender | A system sends documents into GP practice workflows. | Strongest current InterSystems signal is IRIS for Health (Middleware) for Send Document (Send) v2.0.1. |
MESH/ITK3/FHIR STU3 implementation, workflow ID, mailbox/certificate evidence, payload validation, monitoring, and customer deployment proof. |
| GP Connect structured-update sender or receiver | A system sends structured data for addition to a GP EPR, or receives and files that data, under the approved Update Record route. | Health Connect or IRIS could be relevant middleware, but no current source proves InterSystems S102 support or a DMICP/CORTISONE role. | Approved use case, S102 sender/receiver assurance, PDS/Spine dependency, MESH/ITK3/FHIR implementation, clinical workflow and filing rules, safety/IG evidence, and deployment proof. |
| Middleware / integration service | A component transforms, routes, monitors, or validates messages and APIs. | Health Connect and IRIS for Health are the relevant InterSystems components. | Interface catalogue, message maps, conformance tests, monitoring, alerting, service ownership, and incident response. |
| Shared-care viewer / UCR | A regional shared record or viewer displays aggregated data for direct care. | HealthShare UCR and Clinical Viewer fit this pattern, but they need GP Connect consumer and information-governance evidence where GP data is used. | Data-sharing agreement, DPIA, clinical-safety case, access model, audit, provenance, source-system mapping, and display controls. |
| Patient-facing component | A patient or proxy sees data or interacts through a portal/app. | Personal Community may be relevant, but NHS login, patient-facing GP Connect, safeguarding, and consent/access rules are separate. | NHS login/patient identity, proxy policy, accessibility, PECR/storage analysis, patient transparency, and controller approval. |
DUAA Supplier Artefact Checklist For This Standards Cluster
Use this checklist when GP Connect, MESH, or ITK3 appears in a HealthShare, Health Connect, IRIS for Health, or partner deployment.
| Artefact | Question to answer |
|---|---|
| Named standard | Which exact Standards Directory, DSIC, or NHS API/service page applies: ARS, HTML, Access Document, Appointment Management, Send Document, Update Record, Patient Facing Prescriptions, MESH API, or ITK3? |
| Supplier role | Is InterSystems provider, consumer, middleware, viewer, document sender, hosting provider, processor, subprocessor, or only platform vendor? |
| Product/version | Which component and version is in scope: HealthShare, Health Connect, IRIS for Health, FHIR Server, Clinical Viewer, UCR, Personal Community, or partner product? |
| Conformance | What proves the standard is implemented: supplier-progress row, NHS onboarding, test pack, CapabilityStatement, payload validation, MESH mailbox, certificate setup, or assurance certificate? |
| Security | How are HSCN/SSP, TLS mutual authentication, JWT, RBAC, NHS CIS2, smartcard/SSO, NHS login, mailbox certificates, or other identity/security controls handled? |
| Clinical safety | Who owns DCB0129 supplier safety and DCB0160 deployment safety for each route, and how are hazards split between the GP supplier, middleware, viewer, and care organisation? |
| Information governance | Which controller/processor model, DSA, DPIA, privacy notice, subject-access workflow, complaint route, audit, and retention rules apply? |
| Operations | Who owns monitoring, retries, message failures, endpoint downtime, release change, incident response, service desk, fallback, and business continuity? |
Evidence Boundary
The current evidence supports these conclusions:
- GP Connect and MESH/ITK3 are NHS England standards/service surfaces, not InterSystems product names.
- GP Connect Update Record shares the MESH/ITK3/FHIR messaging pattern, but it remains separate from Send Document and Access Record. Its broader effective DSIC standard surface must not be confused with the narrower public evidence for assured community-pharmacy workflows.
- HealthShare is plausible and evidenced as a shared-care-record / Clinical Viewer component, and current supplier-progress evidence maps HealthShare to Access Record: Structured Medications, Allergies, Immunisations, and Uncategorised; other structured cells and Access document are blank.
- IRIS for Health (Middleware) has the strongest current InterSystems-specific public signal for GP Connect Send Document, but still needs product/customer deployment evidence.
- Health Connect and IRIS for Health are relevant middleware candidates for MESH/ITK3/FHIR message handling, but middleware capability does not equal NHS onboarding.
- No current public source makes DMICP/CORTISONE an approved S99 consumer/provider, S101 sender/receiver, or S102 sender/receiver.
- DUAA strengthens supplier-role analysis for named standards in England, but it does not replace supplier-progress, DSIC catalogue, conformance, safety, or customer deployment evidence.
Follow-up Evidence
- Add InterSystems product documentation that explicitly maps HealthShare, Health Connect, or IRIS for Health to current GP Connect, MESH, and ITK3 requirements.
- Add a named customer deployment pack with GP Connect onboarding, MESH/ITK3 mailbox/certificate evidence, DCB0129/DCB0160, DSA/DPIA, and operating model.
- Recheck NHS Standards Directory entries if GP Connect, MESH, ITK3, or Update Record standards move status or change dependencies.
- Recheck NHS supplier-progress rows after any edit later than 5 June 2026.