DSIC Capability-to-Standard Crosswalk
This page turns the DSIC capability-to-standard relationship into a structured crosswalk for analysis. It is not a replacement for the public DSIC pages; it is the wiki's working map for asking what a supplier or product must prove before a DSIC capability claim is safe.
The crosswalk uses existing source IDs and should be read with DSIC GP Foundation Capabilities, DSIC Standards and National Services, and DSIC HealthShare Compliance Map.
The 29 September 2026 function and version check adds current identity, registration, patient-facing, vaccination and reporting distinctions. Use these as the England DSIC lens for the UK Core Services Matrix; verify actual cross-border reuse separately from similar functions or common technical standards.
Crosswalk
| Capability or service component | Main DSIC / NHS standards and services to check | InterSystems relevance | Proof needed for compliance claims |
|---|---|---|---|
| Patient Information Maintenance - GP (C13) | PDS, NHS number handling, ODS/SDS context, NHAIS/GP Links, GP2GP, SCR, GP Connect provider routes, GPES, National Data Opt-Out and vaccination submission. S113 retrieves registration application data; S112 signals validated registration requests; S111 supplies PDS record-change events. S33 separately covers receiving primary/copy NHS 111 reports. | HealthShare EMPI can support identity matching; HealthShare Provider Directory can support provider/organisation data; Health Connect/IRIS can support integration; HealthShare UCR can consume and present patient-record data. | C13 capability listing, PDS onboarding, registration completion and reconciliation, GP2GP/provider obligations, correct event subscriptions, GP Connect role, demographic governance, audit and clinical safety. A received application or event does not itself complete registration. |
| Appointments Management - GP (C5) / Cross-organisation Appointment Booking (C23) | S100 GP Connect Appointment Management: GP provider and cross-organisation consumer roles; S62 appointment activity reporting is a separate flow. Patient-facing appointment access and local appointment workflow have their own controls. | HealthShare can present integrated context; Health Connect/IRIS can integrate appointment data where approved. | Provider/consumer role, applicable onboarding route, local booking/cancellation workflow, appointment reporting and patient-facing permissions. Effective S100 status does not reopen new-developer GP Connect onboarding. |
| Consultation Management - GP | GP clinical record content, coded/uncoded entry, eMED3, Yellow Card, GP Connect record exposure, reporting/extraction, clinical-safety controls. | HealthShare can consume/present consultation data; Health Connect/IRIS can route and transform; FHIR Server can expose FHIR resources where governed. | Foundation consultation workflow, coding/terminology controls, clinical-safety case, GP Connect provider/consumer role evidence, record-amendment and audit rules. |
| Prescribing | EPS, dm+d, medicines standards, patient-facing prescription visibility, medication-safety workflows, repeat prescribing, audit, downstream record-sharing. | HealthShare can aggregate medicines views; Health Connect/IRIS can integrate medication messages/data. | GP prescribing module, EPS assurance, dm+d integration, decision-support/safety controls, repeat workflow, audit, clinical-safety case. |
| Referral Management - GP (C11) / Care Navigation (C67) | e-RS and its referral directory; S93 BaRS for the mapped GP-to-pharmacy sender role. England UEC DoS and public DoHS listings are separate directories. Referral letters, attachments, advice and guidance and status handling retain their own workflow. | Health Connect/IRIS can integrate referral messages/documents; HealthShare can show referral context. | e-RS onboarding or the applicable BaRS application/sender assurance, receiving service readiness, referral workflow, attachments, status reconciliation and safety evidence. S107 UEC DoS currently applies through Community Pharmacy Clinical Services; it is not a blanket GP requirement. |
| Document Management - GP | GP Connect Send Document, GP Connect Access Document, MESH, ITK3, ODS/SDS sender/receiver and endpoint context, transfer-of-care FHIR, document filing, coding, attachment handling, workflow queues. | Health Connect/IRIS are strongly relevant as message/document integration layers; Provider Directory may support local organisation/provider context where configured; HealthShare can show filed documents in context. | MESH mailbox and certificates, payload conformance, workflow IDs, ODS/SDS mapping, filing rules, exception handling, audit, supplier-progress/customer evidence. |
| Task and Workflow Management | Work queues, delegation, reminders, review, completion, audit, clinical-safety and service-management standards. | HealthShare Care Community may support care-management workflows; HealthShare viewer can support direct-care action context. | Role model, queue ownership, escalation, audit, safety case, local operating procedure, service-management evidence. |
| Reporting and Extraction / GP Extracts Verification (C10) | S46 GPES and C10 verification of extracts used by CQRS; S62 appointment activity reporting; local reporting, data quality and secondary-use governance. | Health Insight, IRIS, FHIR Server, OMOP, and UCR data can support analytics and reporting patterns. | Named collection specification, extraction approval, verification/payment-calculation boundary, lawful data handling, data quality and customer reporting evidence. Analytics capability does not establish a national extraction or payment service. |
| Scanning and Filing | Document scanning, classification, patient-record linkage, workflow distribution, audit, retention. | Health Connect/IRIS can integrate scanned-document flows; HealthShare can present documents once indexed and governed. | Scanning workflow, indexing and matching rules, retention, audit, exception handling, local operational evidence. |
| Patient-facing services | S68 NHS login, S125 account provisioning, S114 verified relationships and S103/S104/S105 GP prescription/record/permission APIs; appointments, NHS App, communications and safeguarding. | Personal Community may support digital-front-door patterns; HealthShare can supply record data where governed. | New versus deployed solution requirements, permitted provider/consumer route, proxy/access policy and clinical authorisation. Current patient-facing GP Connect APIs do not require linkage keys; this does not remove legacy IM1 requirements or prove additional patient-facing consumer onboarding is open. |
| Personal Health Record | Patient record presentation, patient-contributed data, messaging, questionnaires, access/proxy controls, NHS login or patient identity route. | Personal Community and HealthShare can support record access and patient engagement patterns. | DSIC capability listing, identity proofing, consent/proxy rules, data provenance, write-back boundaries, safety and IG evidence. |
| Unified Care Record | PRSB Core Information Standard, GP Connect consumer access, PDS/identity, ODS/SDS provider and organisation identity, NRL/events where applicable, shared-care governance, viewer access, consent/RBAC/audit. | HealthShare UCR, Clinical Viewer, EMPI, Provider Directory, Health Insight, and Health Connect are directly relevant. | DSIC capability scope, PRSB/CIS evidence, source-system mappings, GP Connect onboarding, PDS FHIR onboarding where used, ODS/SDS mapping, data-sharing agreement, DPIA, RBAC, audit, local go-live evidence. |
| Online consultation, video consultation, advanced telephony, and digital pathways | DSIC non-foundation service frameworks, Tech Innovation Framework, patient messaging, NHS 111/pathway dependencies where applicable, clinical triage and routing. | HealthShare can provide record context; Health Connect/IRIS can integrate pathway outputs; partner products may provide the front-end workflow. | Framework/catalogue listing, triage model, clinical-safety case, integration contract, record update/document route, operational support evidence. |
Source IDs: SRC-020, SRC-021, SRC-026, SRC-027, SRC-038, SRC-039, SRC-040, SRC-041, SRC-047, SRC-057, SRC-061, SRC-062, SRC-063, SRC-064, SRC-065, SRC-095, SRC-099, SRC-132, SRC-184, SRC-185, SRC-186, SRC-194, SRC-202, SRC-203, SRC-204, SRC-205, SRC-206, SRC-207, SRC-208, SRC-209, SRC-210, SRC-211, SRC-234, SRC-235, SRC-291, SRC-292.
The September additions use SRC-600 to SRC-604; S99/S101/S102 continue to use SRC-292. Catalogue requirements apply according to the capability, contracting vehicle and supplier role. They do not establish every component's mandatory scope, deployment status or use outside England.
The urgent-care requirements add the current S33 receiver, S93 pharmacy-referral and S107 directory roles. Preserve an actionable referral, informational GP notification and confirmed appointment as distinct outcomes. A report adaptor producing FHIR does not establish BaRS transport or new GP Connect booking eligibility.
How to Use This Crosswalk
For any supplier or product claim:
- Identify the exact DSIC capability.
- Identify whether the product is acting as a foundation provider system, consumer system, shared-care platform, integration middleware, patient-facing service, analytics service, or workflow adjunct.
- Check the standards and national services in the row.
- Require supplier/catalogue evidence for the capability and implementation evidence for the national-service role.
- Record any gap in the Evidence Validation Queue.
InterSystems Boundary
This crosswalk strengthens the component interpretation:
- HealthShare maps most strongly to Unified Care Record, clinical-viewer, identity, provider-directory, shared-care, and analytics roles.
- Health Connect and IRIS map most strongly to integration and middleware roles.
- FHIR Server maps to FHIR repository/API infrastructure roles.
- Current DSIC pages distinguish structured read (S99 Access Record Structured), document send (S101 Send Document), and structured write-back (S102 Update Record). Select the route by approved workflow and supplier role; one standard is not evidence for another.
- ODS/SDS is explicit in this crosswalk after the PDS/ODS identity-directory pass, but it remains national-service dependency evidence. It does not prove Provider Directory implementation unless a source names product/version, mapping, synchronisation, stewardship, audit, and deployment scope.
- None of those roles automatically proves foundation GP clinical-system compliance.
Follow-up
- Capture exact DSIC page references for each capability if a procurement-grade crosswalk is needed.
- Add supplier-specific rows if InterSystems or a partner appears in DSIC/Buying Catalogue evidence.
- Keep this page aligned with DSIC public-page changes and Digital Primary Care replacement-framework updates.