Skip to content

DSIC HealthShare Compliance Map

This page maps DSIC requirements to InterSystems HealthShare and adjacent InterSystems components. The key conclusion is cautious: HealthShare can support a DSIC-compliant NHS England solution, especially for shared care records and integration, but HealthShare by itself should not be described as a complete DSIC GP foundation clinical system without explicit capability and standards assessment evidence.

Use Data (Use and Access) Act 2025 as the England statutory data and information-standard governance layer. DUAA section 121 / Schedule 15 strengthens the question of whether a named NHS England information standard applies to an IT supplier or IT-service provider in a specific role; it is not a DSIC compliance label and it does not replace DSIC catalogue evidence, GP Connect assurance, PRSB conformance, clinical-safety evidence, or local information-governance approval. ICO guidance now says all DUAA data-protection provisions are in force as of 19 June 2026, so deployments also need current topic-guidance checks for complaints, lawful basis, transfers, storage/access technologies, subject rights, research, and automated decision-making where applicable.

Use the UK healthcare-recording legal alignment model for record creation and maintenance generally. This page only translates that model into the DSIC / HealthShare evidence test.

Use DSIC Capability-to-Standard Crosswalk to test each HealthShare or adjacent InterSystems component against a capability and national-service row.

Compliance Principle

DSIC compliance is solution-level, capability-level, and standards-level. A compliant service must show:

  1. The DSIC capabilities it offers.
  2. The DSIC standards that apply to those capabilities.
  3. The national services it connects to.
  4. The assurance artefacts for those services.
  5. The supplier/catalogue status for the service.
  6. The local deployment configuration and clinical operating model.
  7. The statutory data-protection, privacy, and information-standard obligations that apply to the supplier role and implementation stage.

Product positioning is relevant evidence, but it is not enough. The same HealthShare estate could be deployed as a shared-care record, clinical viewer, GP Connect consumer, integration platform, analytics platform, patient-facing component, or local data hub. Each role has a different DSIC reading.

This section is the DSIC / HealthShare translation of the general UK legal alignment model. The test is whether the named deployment can produce the legal/professional evidence pack alongside DSIC capability, standards, and onboarding proof.

Legal alignment area What it means for a Health Connect / HealthShare route Proof needed before relying on the route
Creation and maintenance of the record The system must support clear, accurate, timely, attributable clinical records, including clinical findings, treatment, decisions, consent, risk, information shared, next actions, updates, amendments, and correction handling. Workflow design, structured/coded capture where needed, author/time/source capture, amendment/versioning model, audit trail, data-quality controls, professional workflow mapping, and local policy evidence.
Confidentiality, Caldicott, and section 251 Confidential patient information sharing must be justified for direct care or another lawful route. Section 251 is a confidentiality support route for specific non-consented medical purposes, not a general product label. Confidentiality assessment, Caldicott review, consent or implied direct-care rationale, section 251 support where needed, data-sharing agreement, access model, break-glass controls, and audit evidence.
Data protection, PECR, and patient-facing access UK GDPR and Data Protection Act 2018 apply to health data. PECR becomes material where portals, apps, cookies, tracking, storage/access technologies, surveys, reminders, or electronic messaging are in scope. Lawful basis, Article 9 condition, controller/processor matrix, DPIA, privacy notice, subject-rights process, complaint workflow, retention schedule, PECR storage/access assessment, consent/preference controls where needed, and processor terms.
Provider governance, candour, and records management Provider records must be secure, accurate, complete, contemporaneous, and retrievable; candour and records-management duties vary by nation and record type. CQC or devolved-provider governance mapping, candour workflow, incident/correspondence record, nation-specific records-management code mapping, retention/disposal/archival procedure, migration/exit plan, and local operational ownership.
Information standards, provenance, and supplier role Health and Social Care Act 2012 section 250, Health and Care Act 2022, DUAA 2025, and named standards govern standards applicability; Health and Social Care (National Data Guardian) Act 2018 provides governance authority context, not product conformance proof. Named-standard applicability note, supplier responsibility matrix, DCB0129/DCB0160, provenance and audit design, PRSB/SNOMED/FHIR/GP Connect/MESH/ITK3/UK Core mapping where applicable, endpoint/onboarding evidence, and product/version scope.

DUAA England Standards-Governance Boundary

DUAA is useful in this DSIC map only when it sharpens a named standards and supplier-role question for England. Avoid writing that a component is "DUAA-compliant". Write instead that DUAA makes the standards-applicability analysis more important for a named standard, product role, deployment, and customer assurance pack.

Decision use Safe wording Evidence needed
DMICP / CORTISONE source data mediated into an NHS England route DUAA may be relevant if the route processes health/adult social care data for an England health or care service and a named NHS information standard applies to the IT or IT-service supplier role. DMICP interface catalogue, CORTISONE architecture, named NHS standard, supplier role, processor/controller matrix, DSA/DPIA, clinical-safety case, and deployment runbook.
Health Connect as mediation, routing, transformation, or national-service adapter layer Health Connect may fall into the supplier-role analysis where it implements or operates GP Connect, MESH, ITK3, PDS, ODS/SDS, FHIR/UK Core, clinical-safety, terminology, or transfer-of-care standards. Product/version scope, adapter/interface design, conformance or onboarding evidence, endpoint/certificate records, monitoring/support model, and customer artefacts.
HealthShare as shared-care, viewer, EMPI, Provider Directory, analytics, or patient-facing layer HealthShare may be assessed against the named standards that match the deployed role, such as PRSB CIS, DCB0129/DCB0160, PDS, ODS/SDS, FHIR/UK Core, terminology, medicines, transfer-of-care, or patient-facing service rules. Component/version scope, role/view configuration, data-source and provenance design, RBAC/SSO/audit, DSA/DPIA, DCB0129/DCB0160, and customer deployment evidence.
DSIC claim DUAA can sit beside DSIC as statutory standards-governance context, but DSIC compliance still has to be proved capability by capability and standard by standard. DSIC catalogue or supplier evidence, DSIC capability scope, standards scope, national-service onboarding, supplier responsibility matrix, migration/training, clinical safety, information governance, and live deployment evidence.

Executive Summary Interface Alignment

Use this table to keep this DSIC map aligned with the Executive Summary. The central distinction is that Health Connect is the mediation and adapter layer, HealthShare is the shared-care / identity / viewer layer, and DSIC compliance is an England solution-level proof question. Defence Medical Information Capability Programme (DMICP) / CORTISONE evidence can frame the source-system and programme question, but it is not DSIC evidence unless the England deployment, capability, standards, supplier, and assurance artefacts are also present.

Executive Summary route DSIC reading InterSystems role Proof required before claiming compliance or implementation
DMICP into CORTISONE / HealthShare Upstream source-system integration. This is outside DSIC unless it becomes part of an England GP or shared-care service claim. Health Connect should mediate the DMICP extract/API/feed into IRIS, SDA/FHIR/HL7/CDA transformation, and HealthShare where approved. DMICP interface catalogue, source data model, CORTISONE architecture, mapping rules, data-quality controls, clinical-safety case, information-governance pack, and operational runbook.
HealthShare shared-care functions Strongest DSIC-adjacent fit when the service is a shared-care record, clinical viewer, identity, provider-directory, analytics, or patient-facing component. HealthShare UCR, Clinical Viewer, EMPI, Provider Directory, Health Insight, Personal Community, and Health Connect. DSIC capability scope, component/version scope, deployment architecture, RBAC/SSO/audit, DSA/DPIA, DCB0129/DCB0160, controller/processor model, and live customer evidence.
NHS England GP and primary-care connectivity DSIC-relevant only when the offered capability and standards scope are named. GP Connect is a national-service route, not the internal DMICP-to-HealthShare interface. HealthShare may be a consumer/viewer; IRIS for Health and Health Connect may provide middleware, Send Document, MESH, ITK3, FHIR, or transformation roles. GP Connect supplier/onboarding proof, SSP/HSCN/RBAC/JWT/TLS MA, MESH mailbox, ITK3 payload validation, PDS/ODS/SDS onboarding, NDSA/DSA, and DSIC catalogue/capability evidence.
EMIS or other GP supplier-specific adapters Tactical route only. Do not use EMIS Open, Interface Mechanism 1 (IM1), or another supplier API as a generic substitute for DSIC, GP Connect, or four-nation connectivity. Health Connect can wrap or mediate a supplier-specific route if the contract and workflow permit it. Supplier contract, API scope, practice/ODS scope, patient/data-sharing basis, clinical-safety case, test evidence, support boundary, and migration/exit route.
Regional, hospital, and four-nation adapters DSIC is England-only. Wales, Scotland, and Northern Ireland need functionally equivalent adapters and governance, not DSIC labels. Health Connect mediates the target interface; HealthShare persists or displays data only where the deployment role requires it. Target interface catalogue, endpoint ownership, payload profiles, terminology, monitoring, retry/failure process, information governance, clinical safety, and administration-specific onboarding.

England Implementation Artefact Map

Use the Executive Summary architecture-boundary row in the Evidence Validation Queue as the single holding item for missing implementation proof. The table below maps that consolidated boundary into the England artefacts that would be needed before claiming DSIC-aligned NHS England connectivity through Health Connect and HealthShare. Each artefact should be proved once for the named deployment, product version, supplier role, and customer operating model; do not create separate queue trails for the same missing pack unless new evidence changes the boundary.

England artefact Role in the Health Connect / HealthShare architecture Minimum proof needed before relying on it
GP Connect National-service route for GP record access, Send Document, and related NHS England GP connectivity; not the internal DMICP-to-HealthShare interface. Supplier-progress/current-status evidence; product and version scope for HealthShare, Health Connect, IRIS for Health, or partner components; consumer/provider role; approved use case; SSP/HSCN/RBAC/JWT/TLS MA setup; clinical and technical test evidence; local onboarding and support ownership.
MESH Message Exchange for Social Care and Health transport for document/message workflows where GP Connect Send Document, ITK3, transfer-of-care, or local routing uses MESH. Mailbox IDs and ownership; certificates; workflow IDs; retry/failure monitoring; endpoint support model; incident process; evidence that the named deployment uses MESH rather than only generic messaging capability.
ITK3 Interoperability Toolkit payload and message-handling layer for relevant document/message flows, including GP Connect Send Document where applicable. Current conformance or validation evidence; payload/profile version; message bundle and workflow scope; transformation and validation rules; release/change control; customer deployment evidence rather than historical or generic product capability alone.
PDS Patient Demographics Service route for NHS number, demographics, sensitive-record handling, invalidated/superseded number handling, and patient-identity synchronisation. PDS FHIR onboarding; local-copy synchronisation design; matching and stewardship policy; warning/back-office process; audit; clinical-safety case; evidence showing whether Health Connect, HealthShare EMPI, or another component owns each identity function.
ODS/SDS Organisation, site, professional, and endpoint directory dependency for organisation codes, provider context, role/endpoint addressing, and local directory synchronisation. ODS/SDS source-of-truth choice; synchronisation rules; directory stewardship; role/endpoint mapping; audit; change process; evidence showing whether HealthShare Provider Directory, Health Connect, or a local directory owns each function.
DSA/DPIA Information-governance and lawful-processing pack for direct-care sharing, controller/processor responsibilities, transparency, retention, subject rights, complaints, and deployment-specific data flows. National Data Sharing Agreement or local Data Sharing Agreement applicability; DPIA and any addenda; controller/joint-controller/processor matrix; supplier/subprocessor terms; transparency material; operational procedure for access, audit, subject rights, complaints, retention, and exit.
DCB0129/DCB0160 Clinical-safety assurance boundary for supplier design responsibilities and local deployment/use responsibilities. DCB0129 supplier clinical safety case; DCB0160 deployment safety case; hazard log; clinical safety officer roles; residual-risk acceptance; release/change-control process; safety ownership for Health Connect mediation, HealthShare record/viewing, GP Connect/MESH/ITK3 flows, and local workflow.

Product Fit Matrix

DSIC or NHS England need HealthShare / InterSystems fit Out-of-the-box evidence Additional evidence or components needed
Unified care record / shared longitudinal record HealthShare Unified Care Record is directly relevant because it aggregates, normalises, and deduplicates decentralised data into a shared longitudinal record. Strong vendor product evidence and PRSB CIS conformance for HealthShare. DSIC capability listing, local data-sharing model, consent/access controls, implementation-specific mappings, live customer evidence.
Clinical viewer for shared record HealthShare Clinical Viewer is relevant as the direct-care presentation layer for HealthShare/UCR data. Vendor product and documentation-index evidence distinguish Clinical Viewer from UCR and describe browser/mobile/embedded access. SSO, RBAC, audit, role templates, deployment guide, local user provisioning, clinical-safety case, accessibility, and customer evidence.
Patient identity and matching HealthShare EMPI is relevant to enterprise identity resolution and record matching. Vendor product evidence for EMPI as a HealthShare component; NHS PDS evidence now defines the national identity, synchronisation, invalid/superseded NHS-number, local back-office, and safety boundary. Product/version evidence, PDS FHIR onboarding, NHS number handling, local-copy synchronisation, demographic governance, matching algorithm validation, warning/back-office workflow, audit, clinical-safety case, local MPI policy.
Provider and organisation identity HealthShare Provider Directory can support provider master data. Vendor product evidence for provider-data management; NHS ODS evidence defines organisation-code lookup, validation, relationships, succession, and local synchronisation needs. SDS/ODS integration, local role model, authoritative data-source choices, directory governance, data stewardship, synchronisation, audit, and customer deployment artefacts.
Integration engine Health Connect is highly relevant for routing, transformation, monitoring, and healthcare-message processing. Current documentation lists support for FHIR, HL7 v2/v3, IHE, CDA/C-CDA, DICOM, X12, and Health Connect Cloud. Each DSIC interface still needs specific adapters, conformance, endpoint certificates, MESH mailbox, NHS onboarding, testing, and operational support.
FHIR APIs and repository IRIS for Health and InterSystems FHIR Server can support FHIR application and data-service patterns. Product/docs evidence for FHIR-based application platform, FHIR repository, REST APIs, OAuth, packages/profiles, and cloud deployment. NHS profile installation, validation rules, CapabilityStatement evidence, GP Connect or UK Core conformance, information governance, security, and local hosting evidence.
GP Connect consumer access HealthShare could consume GP Connect data for shared-care record or clinical-viewer use. NHS supplier-progress structural capture maps source-spelled InterSytems Healthshare to Access Record: Structured Medications v1.2.6, Allergies v1.2.6, Immunisations v1.5.0, and Uncategorised v1.5.0; other structured cells and Access document are blank. Product implementation guide, SSP/HSCN/RBAC/JWT/TLS MA setup, clinical and technical testing, onboarding, local data-sharing agreement, customer deployment evidence.
GP Connect Send Document / messaging IRIS for Health (Middleware) has the strongest current InterSystems-specific NHS supplier-progress signal for Send Document. NHS supplier-progress structural capture maps InterSystems IRIS for Health (Middleware) to Send Document (Send) v2.0.1. MESH/ITK3/FHIR STU3 implementation, workflow IDs, mailbox operations, clinical-safety case, and customer deployment evidence.
GP foundation clinical record HealthShare is not proven as a full GP EPR foundation system. No current public source in this wiki proves HealthShare provides all GP foundation capabilities. A GP EPR/application layer or assessed foundation supplier components covering patient record, appointments, consultation, prescribing, referrals, documents, tasks, reporting, scanning, national services, migration, and training.
Prescribing and EPS HealthShare can aggregate medicines data; integration tooling can connect medicine data flows. HealthShare/UCR and Health Connect product evidence supports data aggregation and integration. Full GP prescribing UI, prescribing decision support, EPS assurance, dm+d integration, medication-safety workflows, audit, and clinical-safety case.
Patient-facing access HealthShare Personal Community may support patient digital-front-door use; NHS App/NHS login/GP Connect patient-facing routes are separate. Vendor product evidence for Personal Community as patient engagement/record-access product. NHS login, patient-facing GP Connect, proxy access, consent, safeguarding, NHS App route, accessibility, clinical safety, and local governance.
Analytics and population health HealthShare Health Insight and IRIS data services are relevant to reporting, analytics, registries, and insights. Vendor product evidence for Health Insight and InterSystems data platforms. GPAD/GPES or local reporting conformance, data-sharing basis, pseudonymisation, secondary-use governance, data-quality controls.
DUAA / statutory information-standard layer HealthShare, Health Connect, IRIS for Health, FHIR Services, and adjacent managed services may need supplier-role and information-standard applicability analysis when used for health/adult social care in England. Official DUAA and ICO evidence supports the statutory and regulator-guidance context, not product conformance. Named standard applicability, supplier responsibility matrix, controller/processor role, commencement check, ICO topic guidance, local DPIA/DSA, clinical-safety case, and product/version evidence.

Source IDs: SRC-002, SRC-003, SRC-004, SRC-005, SRC-008, SRC-020, SRC-021, SRC-034, SRC-035, SRC-041, SRC-050, SRC-051, SRC-052, SRC-057, SRC-060, SRC-061, SRC-062, SRC-063, SRC-064, SRC-065, SRC-066, SRC-095, SRC-097, SRC-099, SRC-128, SRC-132, SRC-141, SRC-158, SRC-159, SRC-160, SRC-161, SRC-190, SRC-195, SRC-203, SRC-204, SRC-205, SRC-206, SRC-207, SRC-213, SRC-214, SRC-217, SRC-219, SRC-220, SRC-221, SRC-222, SRC-223, SRC-224, SRC-225, SRC-226, SRC-227, SRC-228, SRC-229, SRC-232, SRC-233, SRC-234, SRC-235, SRC-240, SRC-241, SRC-255, SRC-256, SRC-257, SRC-258.

Selected Non-Care Evidence Target

The 2026-06-21 source pass narrowed the identity/directory target but did not close it. EMPI and Provider Directory remain relevant to DSIC-aligned shared-care architecture, but current public evidence is still mostly product positioning plus national-service dependency evidence.

What is now directly supported:

  • PDS is the national patient-demographics and NHS-number service, and PDS FHIR technical conformance creates concrete local-copy synchronisation, sensitive-record, superseded NHS-number, invalidated-record, user-warning, local back-office, and de-coupling requirements.
  • The PDS FHIR integrated-products page lists Intersystems HealthConnect 2020.1 for North West Anglia NHS Foundation Trust as application-restricted, approved 2021-08-25; it does not prove HealthShare EMPI or Provider Directory integration.
  • ODS evidence directly supports organisation-code lookup, validation, relationships, succession, and modified-organisation lists for local synchronisation. ODS/SDS/role-directory evidence remains a national-service dependency, not a Provider Directory deployment proof.

Future source work should prove or bound product/version scope, PDS FHIR onboarding, ODS/SDS mapping, matching/stewardship, directory governance, synchronisation, audit, safety ownership, and customer deployment artefacts before EMPI or Provider Directory are treated as implementation-assured evidence.

What Comes Out of the Box

The current public evidence supports these out-of-the-box or product-native InterSystems strengths:

These are strong components for a DSIC-aligned architecture. They are not enough to claim full DSIC foundation compliance.

What Would Need Additional Components

A full DSIC GP foundation solution would need components or assessed services beyond the current public HealthShare evidence:

Missing or additional component Why needed
GP clinical record application DSIC foundation capability requires practice workflows for patient information maintenance, consultations, problems, observations, coding, documents, tasks, recalls, templates, and audit.
Appointments book and patient appointment services DSIC requires appointments workflow and potentially GP Connect appointment management, GPAD, patient-facing appointment access, and reporting.
Prescribing and EPS module A GP system needs safe prescribing, repeat prescribing, EPS, dm+d, medication warnings, audit, and GP record integration.
Referral and e-RS integration GP referral workflow needs e-RS, Directory of Services, letter/document workflows, attachments, tracking, and status handling.
GP2GP and NHAIS/registration services Patient registration and record transfer are foundation GP functions, not shared-care-record optional extras.
PDS, SDS/ODS, NHS CIS2, RBAC, and smartcard/identity integration National identity, user authentication, authorisation, organisational identity, and audit are central to English NHS connectivity.
MESH and ITK3 operational service Message exchange requires mailbox operations, payload validation, workflow IDs, certificates, monitoring, fallback, and service support.
Clinical safety and information governance pack DCB0129, DCB0160 deployment safety, DPIA, data-sharing agreements, DSPT, access controls, audit, and incident management are deployment requirements.
Data migration and training pack Foundation migration needs source-system extraction, mapping, cutover, reconciliation, training, support, and rollback procedures.
Catalogue and supplier evidence A DSIC claim needs catalogue listing, capability scope, standards scope, and supplier-assurance evidence.

These components could be supplied by InterSystems, a partner, a foundation GP system supplier, local NHS platform components, or a bespoke application built on IRIS for Health. The evidence requirement does not change: each component must be assessed against the DSIC capability and standards scope it claims.

How DSIC Compliance Could Be Achieved with HealthShare

Pattern 1: HealthShare as Shared Care Record Consumer and Viewer

This is the strongest current fit. HealthShare UCR, Clinical Viewer, EMPI, Provider Directory, Health Insight, and Health Connect can support a regional shared-care-record pattern. In DSIC terms, the service would need to show which shared-record, clinical-viewer, identity, integration, analytics, and patient-facing capabilities it offers, then prove GP Connect consumer onboarding, PDS identity integration, ODS/SDS provider and organisation mapping, RBAC, user access, data-sharing, clinical safety, and information-governance controls.

What HealthShare contributes:

  • Longitudinal record.
  • Viewer.
  • Identity matching.
  • Provider directory.
  • Integration and transformation through Health Connect.
  • Analytics through Health Insight.

What must be added or proven:

  • GP Connect consumer implementation and onboarding.
  • PDS/Spine access pattern, including PDS FHIR onboarding, local-copy synchronisation, invalid/superseded NHS-number handling, local back-office process, and safety warnings.
  • ODS/SDS organisation and endpoint mapping, including local directory synchronisation and authoritative-source governance.
  • NHS CIS2/RBAC/user provisioning.
  • Data-sharing agreement and DPIA.
  • Local clinical-safety case.
  • DSIC capability and standards listing for the offered service.

Pattern 2: Health Connect / IRIS as National-Service Integration Layer

Health Connect and IRIS for Health can sit between local applications and NHS national services. This pattern is relevant for GP Connect Send Document, MESH, ITK3, FHIR transformations, HL7 v2, CDA, document routing, monitoring, and audit. NHS supplier-progress evidence structurally maps InterSystems IRIS for Health (Middleware) to Send Document (Send) v2.0.1.

What InterSystems contributes:

  • Integration engine and middleware.
  • FHIR/HL7/CDA transformation.
  • Message routing and monitoring.
  • Platform for custom NHS adapters.

What must be added or proven:

  • Interface-specific conformance.
  • MESH mailbox and certificate operations.
  • ITK3/FHIR STU3 payload validation where relevant.
  • GP Connect workflow and version mapping.
  • Operational support and incident response.
  • Supplier-progress or catalogue evidence.

Pattern 3: Partnered GP Foundation Solution with HealthShare Adjacent

An existing DSIC foundation GP supplier could remain the legal GP record system, while HealthShare provides shared-care, viewer, integration, identity, analytics, or patient-facing adjuncts. This avoids overstating HealthShare as the GP EPR while still using HealthShare to achieve integrated care.

What InterSystems contributes:

  • Shared record and clinical viewer for cross-organisational care.
  • Integration and event/message routing.
  • Analytics and population health.
  • Potential patient engagement through Personal Community.

What the foundation supplier contributes:

  • GP record, appointments, consultations, prescribing, referrals, document workflow, reporting, scanning, GP2GP, EPS, SCR, and other foundation obligations.

What must be jointly proven:

  • Interface contracts between the foundation system and HealthShare.
  • National-service roles split by provider/consumer/middleware responsibility.
  • Clinical-safety hazard ownership and residual-risk governance.
  • Data-controller/processor responsibilities.
  • Service-management boundaries and incident response.

Pattern 4: Bespoke DSIC Application Built on IRIS for Health and HealthShare

This is possible in architecture but highest risk as an evidence claim. A supplier could build a GP or modular-care application on IRIS for Health, use HealthShare for longitudinal record and viewer functions, and Health Connect for national-service integration. To become DSIC-compliant, it would need full DSIC assessment, not just InterSystems platform capability.

The evidence pack would need:

  • Capability-by-capability DSIC mapping.
  • Standards-by-standards implementation evidence.
  • DUAA commencement, ICO guidance, and supplier-role analysis where statutory data/privacy or health/adult social care information-standard obligations apply.
  • GP foundation workflow completeness if claiming foundation status.
  • National-service onboarding and supplier-progress evidence.
  • Migration, training, service management, BCDR, hosting, and information-governance evidence.
  • First-of-type or rollout evidence where required.

NHS England Connectivity Outcomes

Using HealthShare and adjacent InterSystems components can achieve NHS England connectivity where the deployment proves the relevant role:

Connectivity outcome Likely InterSystems route Proof required
Consume GP record data for direct care HealthShare UCR / Clinical Viewer plus GP Connect consumer implementation. GP Connect onboarding, SSP/HSCN/RBAC/JWT/TLS MA, approved use case, data-sharing, and clinical-safety evidence.
Send documents into GP practices IRIS for Health / Health Connect middleware using GP Connect Send Document, MESH, ITK3, FHIR STU3. Supplier-progress mapping, MESH operations, payload conformance, workflow ID, technical and clinical testing.
Maintain shared regional record HealthShare UCR, EMPI, Provider Directory, Health Connect. Local architecture, source-system onboarding, consent/access controls, data-quality rules, clinical viewer configuration.
Expose patient-facing record access Personal Community or NHS App-linked route with patient-facing GP Connect/NHS login where required. NHS login, patient-facing API assurance, proxy/access policy, safeguarding, content controls.
Analytics and reporting HealthShare Health Insight, IRIS, FHIR Server, OMOP where licensed and governed. Data-sharing basis, extraction standards, pseudonymisation, reporting obligations, secondary-use governance.

Evidence Status

Confidence is high that HealthShare and related InterSystems products are relevant to DSIC integrated-care and interoperability architecture. Confidence is moderate-to-boundary for current InterSystems GP Connect capability because NHS supplier-progress material names InterSystems products and now maps exact populated cells, but current product documentation, assurance evidence, and customer deployment artefacts are still required for capability implementation claims.

Confidence is not sufficient to claim that HealthShare alone is DSIC foundation-compliant for English general practice. That claim would require explicit DSIC catalogue/capability evidence, national-service implementation proof, and customer deployment artefacts.

DUAA Supplier Artefact Checklist

Use this checklist when a HealthShare-backed or InterSystems-backed service is assessed against DSIC, GP Connect, NHS Standards Directory, or wider NHS England information-standard obligations. It is deliberately artefact-led: a DUAA-aware position is only useful if it names the supplier role, standard, product/version, deployment, commencement status, current ICO topic guidance, and local evidence.

Artefact area What must be captured Why it matters for HealthShare / InterSystems
Scope and commencement note Which DUAA provision is relevant, whether it is commenced, and whether ICO topic guidance has replaced GOV.UK summary material. Avoids treating Royal Assent or a factsheet as implementation-ready law for a specific service.
Supplier role and responsibility matrix Whether InterSystems is supplier, processor, subprocessor, controller, joint controller, system integrator, hosting provider, middleware provider, or product/platform vendor. DUAA section 121 / Schedule 15 can raise IT supplier questions, but responsibility depends on the actual role and contract.
Named-standard applicability statement The NHS information standard, DSIC standard, GP Connect capability, PRSB standard, clinical-safety standard, or Standards Directory entry that applies. Prevents generic "DUAA compliant" language and ties the claim to a testable standard.
Product, version, and component mapping HealthShare UCR, Clinical Viewer, EMPI, Provider Directory, Health Insight, Personal Community, Care Community, Health Connect, IRIS for Health, FHIR Server, or partner component in scope. HealthShare is a product family; each component has different data, interface, display, safety, and access implications.
Controller / processor and data-sharing pack Data-processing agreement, data-sharing agreement, controller/joint-controller analysis, subprocessor list, retention, audit, and incident responsibilities. Required to separate supplier processing from care-organisation decision-making and regional shared-care governance.
DPIA and transparency pack DPIA, privacy notice wording, patient transparency route, opt-out/objection treatment where applicable, and data-flow diagrams. Shared-care records, portals, analytics, and integration hubs need visible data-use boundaries.
Data-subject-rights and complaints workflow Subject access, rectification, restriction, objection, disclosure, audit-search, export, stop-clock/escalation, and complaint-handling procedures. DUAA changes make these operational workflows part of readiness, not only legal-policy text.
Clinical-safety evidence DCB0129 supplier safety case, DCB0160 deployment safety case, hazard log, safety officer roles, residual-risk acceptance, and change control. HealthShare and integration services can affect direct-care decisions even when they are not the system of record.
Interface and conformance evidence GP Connect onboarding, MESH/ITK3, PDS/NEMS, FHIR/UK Core, PRSB CIS, terminology, medicines, imaging, diagnostic, and local interface tests. Proves the named standard is actually implemented and tested for the deployment role.
Identity and access-control evidence NHS CIS2/NHS login, RBAC, smartcard or SSO integration, PDS identity use, EMPI matching policy, provider/organisation directory governance, and audit. Separates digital verification, NHS identity, patient matching, and provider identity functions.
AI / automated decision-making pack Model/prompt governance, human review, clinical-safety assessment, transparency, challenge/override route, logging, and evidence that unsupported autonomous clinical decisions are not made. Relevant to HealthShare AI Assistant, IntelliCare, risk scoring, triage, and workflow automation.
Research, analytics, and secondary-use pack Lawful basis, special-category condition, approvals, pseudonymisation/anonymisation, minimisation, data-access committee controls, retention, and export audit. Relevant to HealthShare Health Insight, OMOP, Bulk FHIR Coordinator, FHIR Server exports, registries, and population-health analysis.
International transfer and cloud support pack Hosting region, support access, subprocessor geography, transfer mechanism, encryption, logging, disaster recovery, AI runtime service boundary, and customer-specific service terms. Product capability evidence does not prove the managed-service, support, or cloud transfer position.
PECR / patient-facing service evidence Cookie/storage classification, consent model, analytics tags, direct-care versus marketing message boundary, SMS/email preference handling, and proxy/safeguarding controls. Relevant to Personal Community, patient portals, reminders, surveys, and web front doors.
Migration, training, and operating model Data migration, reconciliation, training, service desk, incident response, rollback, release management, and business-continuity evidence. DSIC compliance is operational as well as technical; local go-live readiness must be proved.

Worked Example: Birmingham / West Midlands Evidence Pack

This applies the DUAA supplier artefact checklist to the current public Birmingham / West Midlands shared-care-record evidence. The conclusion is deliberately bounded: the evidence supports a HealthShare shared-care-record and integration deployment reading, and current NHS/Medicus signals strengthen the GP-system integration narrative, but it is not a complete DSIC GP foundation compliance pack and it is not enough to claim end-to-end DUAA readiness.

Current Birmingham / West Midlands Artefact Pack Status

The public artefact pack is partial. It supports regional shared-care-record scope, older/current DPIA-style evidence, a DSA-sensitive-information boundary, supplier/processor indications, public GP Connect progress rows, official NHS GP Connect/Medicus status context, and current Medicus/HealthShare integration signalling. It does not expose the final signed data-sharing agreement, current full local DPIA, DCB0129/DCB0160 safety cases, endpoint/certificate pack, MESH mailbox pack, GP Connect onboarding artefacts, or supplier-responsibility matrix.

Artefact Current public evidence Readiness status Still needed
DSA, ownership, and controller model Birmingham/Solihull and Coventry/Warks public pages describe direct-care sharing across the three-area footprint, participating organisations, neighbouring-area access, objecting, and DSA-based sensitive-information exclusions. Arden & GEM describes Coventry/Warks contract, data-sharing, legal-basis, information-governance, and common-model alignment work. NHS England says the GP Connect National Data Sharing Arrangement sets out data-sharing requirements for GP Connect use. Partial public statement evidence. Final signed local DSA, GP Connect NDSA adoption evidence, controller/joint-controller matrix, processor terms, access-policy annex, sensitive-data exclusion rules, audit responsibilities, and regional governance minutes.
DPIA and transparency Published Collaborative Shared Care Record and H&W ICWR DPIAs describe InterSystems supplier/processor/cloud-hosting roles, HealthShare / Information Exchange architecture, UHB hosting, and Clinical Viewer display; local pages and privacy material provide public transparency and subject-access/objecting routes; NHS England's GP Connect DPIA names Medicus as a new NHS market entrant for GP patient-facing services. Historic-to-current partial pack. Current local DPIA, privacy-notice set, data-flow diagrams, data-subject-rights workflow, complaint workflow, retention/deletion plan, and DPIA review evidence after Medicus or other new GP integrations.
Clinical safety DCB0129/DCB0160 No current public Birmingham / West Midlands Shared Care Record DCB0129/DCB0160 artefact was found in this pass. Missing public evidence. Supplier DCB0129 clinical-safety case, deployment DCB0160 safety case, hazard log, clinical safety officer ownership, residual-risk sign-off, release/change control, and safety-case update for new GP-system integrations.
Supplier responsibilities DPIA material names InterSystems supplier/processor/cloud-hosting roles; BCHC privacy material links Shared Care Record retention to an InterSystems contract end date; current HTN/InterSystems social material says Medicus GP systems have been connected into the West Midlands Shared Care Record running on HealthShare. Partial role evidence, not a complete responsibility matrix. Supplier/service responsibility matrix covering InterSystems, any hosting/support subprocessors, UHB/host role, ICBs/controllers, participating providers, Medicus/foundation GP supplier responsibilities, operational support, incident handling, and data-export duties.
GP Connect provider/consumer progress NHS supplier-progress structural capture maps Medicus provider and consumer rows, InterSystems IRIS for Health (Middleware) Send Document (Send) v2.0.1, and HealthShare Access Record: Structured Medications, Allergies, Immunisations, and Uncategorised cells. NHS GP Connect status separately says Patient Facing APIs are live with Medicus, Access Document is FoT ready for Medicus, and several ARS sections are FoT ready for Medicus. High for NHS table/status mapping; boundary for local West Midlands onboarding. Named deployment onboarding pack, use-case approval, SSP/HSCN/RBAC/JWT/TLS MA evidence, tests, endpoint/certificate artefacts, and proof that the Birmingham / West Midlands HealthShare deployment uses those rows.
MESH and ITK3 NHS Send Document context uses MESH, ITK3, HL7 FHIR STU3 payloads, and workflow ID GPFED_CONSULT_REPORT; the IRIS for Health row maps to Send Document (Send) v2.0.1. Partial interface-context evidence. Local MESH mailbox configuration, certificates, workflow IDs, payload validation, monitoring, fallback, incident process, sender/receiver responsibilities, and service-management evidence.
DSCR / adult social-care GP Connect access WMCA care-provider support says DSCR suppliers can be asked to enable GP Connect, ODS codes are needed, and GP Connect/DiSC contact routes exist. Adjacent regional onboarding support, not HealthShare assurance. Care-provider system list, DSPT status, ODS-code onboarding evidence, supplier configuration, data-sharing/access approval, and any HealthShare-specific adult-social-care access route.
Current Medicus integration signal HTN reported on 15 May 2026 that InterSystems UKI connected Medicus GP systems within the West Midlands Shared Care Record; InterSystems UKI's LinkedIn post says the shared care record runs on HealthShare and mentions a Norfolk/Suffolk deployment. Useful current signal; not official NHS/customer assurance. Official NHS/customer confirmation, technical architecture, GP Connect/MESH/ITK3 route used, safety and IG artefact updates, live-status evidence, and impact/outcome evidence.

Medicus / West Midlands Deployment-Evidence Checklist

Use this row pack for a specific Medicus GP system connection into the West Midlands Shared Care Record. It should be read as an evidence request list, not as a conclusion that the route is fully assured. The current public position is: NHS England evidence supports Medicus GP Connect status nationally, and trade/vendor evidence says Medicus has been connected into the West Midlands Shared Care Record running on HealthShare; official local West Midlands artefacts for the specific deployment remain missing.

Route-Specific Architecture Table: Medicus / HealthShare / GP Connect

This table defines the route that must be proved before any DSIC, GP Connect, DUAA, or local assurance conclusion can be used. It deliberately separates components, interfaces, legal artefacts, and safety artefacts because each is owned and evidenced differently.

Route element Current evidence-based role Route-specific question Artefact needed to prove it
Medicus GP system Official NHS material supports Medicus nationally as a GP Connect supplier/provider and patient-facing API context; trade/vendor material says Medicus GP systems were connected into the West Midlands Shared Care Record. Which Medicus product/version, GP practices, PCNs, ODS codes, and ICB footprint are live in the West Midlands route? Customer-approved deployment note, practice/cohort scope, Medicus version, endpoint registration, go-live date, supplier RACI, and national-service onboarding evidence.
HealthShare shared-care platform Regional DPIAs describe a HealthShare / Information Exchange architecture, Clinical Viewer display, UHB hosting, and InterSystems supplier/processor roles; NHS supplier-progress material maps HealthShare to selected ARS consumer cells. Is HealthShare the approved GP Connect consumer/viewer for the Medicus route, or is data reaching HealthShare through another interface? Current architecture diagram, HealthShare component/tenant list, GP Connect consumer approval if used, display/provenance/audit design, and customer-side implementation guide.
GP Connect Access Record / Access Document NHS evidence supports national Medicus status and selected HealthShare ARS supplier-progress cells, but not the local route. Does the West Midlands connection use GP Connect Access Record: Structured, Access Record: HTML, Access Document, Patient Facing APIs, a local feed, or some combination? Approved use case, supplier-progress match, SSP/HSCN/RBAC/JWT/TLS MA evidence where applicable, endpoint/certificate records, test evidence, and local data-flow diagram.
MESH Send Document and Update Record use MESH-style messaging routes in NHS service/API evidence; the IRIS for Health row maps to Send Document (Send) v2.0.1. Is MESH actually part of the West Midlands Medicus / HealthShare route, or is the route read-only GP Connect access without MESH messaging? MESH mailbox IDs, workflow IDs, sender/receiver ownership, payload validation, monitoring, retry/failure process, certificate setup, and service desk runbook.
ITK3 NHS Standards Directory and Send Document context make ITK3 relevant to GP Connect messaging dependencies, not to every GP Connect read route. If Send Document or Update Record is in scope, who implements and supports ITK3 message distribution? ITK3 conformance evidence, FHIR STU3 payload test artefacts, workflow ID mapping, supplier responsibility split, and release/change-control evidence.
National Data Sharing Arrangement (NDSA) NHS GP Connect material says the NDSA sets GP Connect data-sharing requirements; this is national context, not local adoption proof. Has the local deployment adopted the GP Connect NDSA for the relevant provider/consumer roles and use case? NDSA participation/adoption evidence, role mapping, approved use case, controller/joint-controller interpretation, patient transparency wording, and access-policy annex.
Local data-sharing agreement (DSA) Birmingham / Coventry sources support DSA-sensitive-information and shared-care governance context, but not the signed local route terms. What local DSA governs Medicus data in the West Midlands Shared Care Record, and how does it interact with the NDSA if GP Connect is used? Signed local DSA or redacted extract, controller/joint-controller matrix, sensitive-data exclusion rules, access/audit obligations, retention terms, and participating-organisation schedule.
DPIA and privacy pack Historic regional DPIAs describe HealthShare/Information Exchange and InterSystems roles; NHS GP Connect DPIA names Medicus in national context. Has a current local DPIA or DPIA addendum assessed the Medicus connection and any GP Connect/MESH/ITK3 route? Current DPIA/addendum, privacy-notice update, data-flow diagram, risk mitigations, SAR/complaint workflow, residual-risk owner, and review date after the Medicus change.
DCB0129 / DCB0160 clinical safety NHS Standards Directory lists DCB0129 and DCB0160 as clinical-safety standards; no public local safety artefact has been found for this route. Who owns supplier safety and deployment safety across Medicus, InterSystems/HealthShare, middleware, UHB/host, ICBs, and participating providers? Medicus supplier DCB0129, InterSystems/middleware safety case if applicable, West Midlands deployment DCB0160, hazard log, clinical safety officer roles, residual-risk acceptance, release/change-control process, and safety-case update for route changes.
Supplier and service-management boundary Public evidence supports a multi-supplier regional pattern but not the route-level operating model. Who monitors, supports, changes, and incidents the route when Medicus, HealthShare, GP Connect, MESH, or ITK3 fails? Supplier RACI, operational runbook, service desk model, incident/escalation process, BCDR/fallback design, maintenance windows, audit-log access, and data-export responsibilities.
Deployment evidence row Current public evidence What it supports now What would close the row
Named deployment identity Trade/vendor material says Medicus GP systems have been connected into the West Midlands Shared Care Record; no official West Midlands NHS/customer page found in this pass names the live Medicus practices, ODS codes, ICB deployment scope, or HealthShare tenant/component. Current-signal only. It justifies a targeted evidence pack, not a local assurance claim. Official ICB/customer deployment note naming practices or cohort, ODS codes, go-live date, HealthShare environment, Medicus version, source systems, and responsible organisations.
Route architecture Existing regional DPIAs describe HealthShare / Information Exchange, UHB hosting, Clinical Viewer display, and InterSystems supplier/processor roles. NHS supplier-progress rows identify relevant Medicus, IRIS, and HealthShare GP Connect cells. Plausible route model: Medicus GP provider/source, HealthShare shared-care consumer/viewer, and possible IRIS/Health Connect middleware. Current architecture diagram showing whether the route uses GP Connect ARS, GP Connect Send Document, MESH/ITK3, NRL pointers, local feed, or another interface.
Supplier and responsibility split Published DPIAs identify InterSystems as supplier/processor/cloud-hosting provider for earlier shared-care-record architecture; NHS supplier-progress evidence identifies Medicus rows separately from InterSystems rows. A multi-supplier split is likely and must not be collapsed into a single HealthShare or Medicus claim. RACI/supplier-responsibility matrix covering Medicus, InterSystems, any middleware/hosting provider, UHB/host role, ICB/controller or joint-controller role, practices, and care organisations.
GP Connect provider role NHS supplier progress maps Medicus provider status, including full-rollout approval for Access Record: HTML, Appointment Management, and Send Document receive, plus FoT-ready ARS provider sections except Access document in development. Strong official national supplier-progress evidence for Medicus provider capability status. Evidence that the West Midlands deployment uses those Medicus provider capabilities, including use-case approval, endpoint registration, SSP/HSCN/RBAC/JWT/TLS MA setup, testing, and live-use records.
GP Connect consumer / viewer role NHS supplier progress maps HealthShare to ARS Medications, Allergies, Immunisations, and Uncategorised, and maps Medicus v1 as a consumer for Access Record HTML, Appointment Management, and Send Document (Send). Strong official table evidence for supplier-progress cells, not a local route claim. Local proof that HealthShare, Medicus, or another component is the approved consumer/viewer for the West Midlands route, plus display/provenance/audit rules.
Patient-facing GP Connect route NHS GP Connect status says Patient Facing APIs are live with Medicus; NHS GP Connect DPIA names patient-facing services using NHS App and Medicus as a new NHS market entrant for GPs. Official national Medicus context for patient-facing GP Connect, not West Midlands SCR proof. Local statement whether patient-facing APIs are in or out of scope for this West Midlands route, plus NHS App/NHS login/proxy/safeguarding evidence if in scope.
MESH / ITK3 messaging NHS Send Document context uses MESH, ITK3, HL7 FHIR STU3 payloads, and workflow ID GPFED_CONSULT_REPORT; IRIS for Health (Middleware) maps to Send Document (Send) v2.0.1. Interface-context evidence only. It does not prove local MESH mailbox or ITK3 operation. MESH mailbox IDs, certificates, workflow IDs, payload validation evidence, monitoring, retry/failure handling, sender/receiver ownership, incident process, and service desk model.
Data-sharing pack Regional public pages and Arden & GEM evidence support DSA-sensitive-information and governance work; NHS GP Connect page points to the NDSA as the data-sharing requirement set for GP Connect. Partial legal/governance context. Signed local DSA, NDSA adoption evidence, controller/joint-controller analysis, processor terms, patient transparency updates, restriction/objection handling, audit access, and data-retention rules for the Medicus route.
DPIA and privacy pack NHS GP Connect DPIA names Medicus in a national patient-facing context; older regional DPIAs describe HealthShare/Information Exchange and InterSystems roles. National GP Connect DPIA plus historic regional SCR DPIA evidence. Current local DPIA or DPIA addendum specifically covering Medicus integration, GP Connect/MESH route, changed data flows, patient transparency, risk mitigations, and residual-risk owner.
Clinical safety pack NHS supplier-progress status implies development/assurance/FoT routes, but no public local DCB0129/DCB0160 artefact was found for the Medicus / West Midlands HealthShare route. Absence of public safety artefacts is a key boundary. Medicus DCB0129 supplier safety case, InterSystems/middleware safety case if applicable, West Midlands DCB0160 deployment safety case, hazard log, clinical safety officers, residual-risk acceptance, and release/change controls.
Operations and service management Existing public sources do not expose the Medicus route operating model. No safe operational conclusion. Runbook covering monitoring, alerting, downtime/fallback, message rejection/replay, endpoint changes, incident escalation, support hours, BCDR, release process, and clinical/business continuity.
DUAA / data-subject workflow ICO subject-access guidance is updated; local Birmingham / West Midlands public material points to subject-access/privacy routes, but no Medicus route workflow was found. General regulator and local transparency context. Local procedure for SAR search/export, third-party redaction/withholding, audit-log retrieval, complaints, controller/processor handoff, and records affected by GP Connect or HealthShare display.
Checklist area Public evidence now available Compliance interpretation Evidence still missing
Deployment scope Birmingham and Solihull ICS describes the Shared Care Record as joining records from GP practices, BSMHFT, UHB, BCHC, ROH, Birmingham City Council, Solihull Council, Birmingham Children's Trust, and West Midlands Ambulance Service. Strong for local shared-care-record scope and participating-organisation context. Current operating model, live participant list, current architecture, final programme governance, and proof that every listed organisation is currently live.
Supplier role and processor boundary Published DPIA material says partners procured InterSystems as software/system supplier and processor, describes cloud hosting and a central Information Exchange / HealthShare environment, and identifies UHB hosting in the H&W ICWR material. Supports a HealthShare/InterSystems supplier and processor role for shared-care-record evidence, not a controller role or GP foundation-system role. Final contract, processor terms, subprocessor list, support-access model, service levels, supplier-responsibility matrix, and current hosting/managed-service terms.
Product and component mapping DPIA evidence references HealthShare / Information Exchange architecture and Clinical Viewer display; HL7 UK lists West Midlands InterSystems HealthShare and Care Community OIDs. Supports HealthShare UCR / Clinical Viewer / integration architecture plausibility for regional shared care. Product version, licensed component list, Clinical Viewer configuration, EMPI/matching settings, Provider Directory usage, Care Community role if any, and local implementation guide.
Retention and contract timing BCHC privacy material says BSOL CCC Shared Care Record data will be retained until the InterSystems contract ends on 31 March 2029. Strong public signal that InterSystems contract timing is tied to local shared-care-record retention wording. Full contract, renewal/extension status, retention schedule, deletion/archiving process, controller approval, and exit/migration plan.
National-service and identifier evidence NHS NRL change history names InterSystems sites including Birmingham and Solihull ICB, Coventry and Warwickshire ICB, and Herefordshire and Worcestershire ICB as live with International Patient Summary PDF pointers; HL7 UK OIDs provide identifier evidence; NHS GP Connect supplier progress maps InterSystems and Medicus rows structurally. Supports national-service adjacency, standards identifiers, and supplier-progress relevance for West Midlands shared-care connectivity. NRL onboarding artefacts, use-case approval, endpoint/certificate details, payload standards, GP Connect consumer/provider role in this deployment, MESH/ITK3 role, operational monitoring, and local fallback process.
NHS information-standard applicability DUAA section 121 / Schedule 15 makes supplier applicability a live question where named health/adult social care information standards apply to IT or IT services in England. The Birmingham pack should be assessed standard by standard rather than described generically as DUAA-compliant. Named-standard applicability note covering GP Connect, MESH/ITK3, FHIR/UK Core, PRSB CIS, DCB0129/DCB0160, terminology, medicines, imaging, diagnostics, and any DSIC capability standards in scope.
ICO topic guidance and data-subject workflows ICO says all DUAA data-protection provisions are now in force; current ICO guidance exists for complaints, lawful-basis/RLI/purpose limitation, storage/access technologies, subject access, and parts of international transfers, while research and automated decision-making/profiling remain tracked for final guidance and IDTA/Addendum updates remain planned. A Birmingham/West Midlands readiness pack now needs current ICO topic checks, not GOV.UK factsheet-only treatment. Local subject-access search/export procedure, complaint workflow, transparency and privacy notices, restriction/objection handling, research/secondary-use governance, transfer analysis, PECR/storage classification, and AI/ADM statement if AI is in scope.
Clinical safety Shared-care-record viewing, matching, integration, and document/reference presentation can affect direct-care decisions. DCB0129/DCB0160 should be treated as mandatory deployment artefacts when the service influences clinical workflow, even where HealthShare is not the GP system of record. Supplier DCB0129 case, deployment DCB0160 case, hazard log, clinical safety officer roles, residual-risk acceptance, release/change controls, and incident process.
DSIC / GP foundation status Current public evidence is strongest for shared-care record, viewer, integration, and national-service adjacency. It supports Pattern 1 and Pattern 2 above. It does not prove HealthShare is a complete DSIC GP foundation system. Buying Catalogue / DSIC capability listing, GP foundation supplier split, appointments, prescribing, referrals, document/task/reporting/scanning coverage, GP2GP/NHAIS/EPS/e-RS evidence, migration and training packs.

Minimum next artefact pack for this deployment:

  • Current local architecture diagram naming HealthShare, Clinical Viewer, source systems, identity, national services, and hosting/support boundaries.
  • DSA, DPIA, processor agreement, subprocessor list, retention/deletion plan, privacy notice, and complaint/subject-access workflow.
  • DCB0129/DCB0160 safety case, hazard log, clinical safety officer ownership, and release/change-control evidence.
  • Interface catalogue covering NRL, GP Connect if present, MESH/ITK3 if present, FHIR/UK Core, PRSB CIS/content standards, OIDs, terminology, and payload validation.
  • Supplier responsibility matrix that separates InterSystems, UHB/host, ICB/controller or joint controllers, participating providers, GP foundation suppliers, and any middleware/hosting subcontractors.
  • DSIC capability note stating whether the service is shared-care / viewer / integration only, or whether any GP foundation capability is actually claimed.

Follow-up Evidence

  • Public DSIC catalogue or supplier records naming HealthShare, Health Connect, IRIS for Health, or an InterSystems-backed service.
  • Current InterSystems implementation documentation for GP Connect, PDS, MESH, ITK3, NHS login, EPS, e-RS, GP2GP, and other DSIC national services.
  • Local HealthShare DSIC deployment artefacts: DPIA, DSA, DUAA supplier-role note, clinical-safety case, architecture, onboarding, endpoint/certificate setup, migration and training packs. Use the Birmingham / West Midlands evidence pack above as the first worked template.
  • Official Birmingham / West Midlands customer evidence confirming the Medicus integration route, updated safety/IG artefacts, and current live-status boundaries.
  • FOI/source-target pack responses for the route architecture, DSA/NDSA, DPIA, DCB0129/DCB0160, MESH/ITK3, endpoint/certificate, and supplier RACI evidence listed in the Evidence Validation Queue.