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, and document sending.
- 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.
Update Record is a GP Connect capability with a MESH / ITK3 / FHIR STU3 messaging pattern, but this page treats it as an adjacency to the Standards Directory cluster rather than proof that Send Document, Access Record, or generic MESH evidence covers pharmacy write-back. 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 entry and current NHS API/service context for structured GP record access. | 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, 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 entry and NHS API context for a production document-send route using MESH, ITK3, and FHIR STU3 payloads. | Current NHS supplier-progress evidence maps IRIS for Health (Middleware) to Send Document (Send) v2.0.1. |
Product/customer evidence, MESH mailbox, workflow ID, certificates, ITK3/FHIR STU3 payload validation, sender/recipient workflow, 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 adjacency | NHS API evidence frames Update Record as a specific community-pharmacy structured write-back route using MESH, ITK3, and FHIR STU3 payloads. | Useful as an architecture analogue for MESH/ITK3/FHIR message handling; not evidence that any InterSystems product supports generic GP record write-back. | Supplier assurance for the specific Update Record route, pharmacy use-case scope, payload tests, clinical governance, and GP supplier support 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. |
| 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 entry or NHS API/service page applies: ARS, HTML, Access Document, Appointment Management, Send Document, 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 a separate community-pharmacy write-back capability and cannot be inferred from Send Document or Access Record evidence.
- 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.
- 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.