Skip to content

Executive Summary

Exam Question

How can InterSystems Health Connect and HealthShare enable Defence Medical Information Capability Programme (DMICP) connectivity with NHS England against Digital Services for Integrated Care (DSIC) compliance, and how can the same architecture be extended to Wales, Scotland, and Northern Ireland connectivity?

Short Answer

Health Connect and HealthShare can support the architecture, but they do not by themselves prove DSIC compliance or four-nation connectivity.

The strongest evidence-backed position is:

  • DMICP is an existing Defence electronic primary health record and data warehouse source for Defence primary healthcare and some MOD specialist care.
  • Programme CORTISONE is the Defence Medical Services (DMS) programme context for a wider integrated ecosystem with NHS interfaces across all four UK nations, an Integration Platform, Enterprise Master Patient Index (EMPI), clinical portal, and integrated electronic healthcare record.
  • InterSystems has supported CORTISONE evidence: HealthShare and IRIS for Health were selected for CORTISONE, MOD performance files name InterSystems for CORTISONE IP and EMPI, and Contracts Finder records a FY25-30 HealthShare / IRIS for Health licence award.
  • Health Connect is the best-fit mediation layer for DMICP feeds, CORTISONE integration, national-service adapters, message routing, transformation, monitoring, and operational support.
  • HealthShare is the best-fit shared-care layer for longitudinal record, clinical viewer, EMPI, provider directory, and shared-record functions.
  • DSIC is England-specific. Wales, Scotland, and Northern Ireland should be handled through functionally equivalent national-service mappings, not by describing them as DSIC-compliant (SRC-019, SRC-105 to SRC-147, SRC-198, SRC-199, SRC-202, SRC-203).
  • Healthcare-recording assurance is a separate decision layer: use the UK Healthcare Recording Legal and Professional Position and Healthcare Record Source Layers for UK GDPR, Data Protection Act 2018, PECR, common law confidentiality, Caldicott, NHS Act 2006 section 251, Health and Social Care Act 2012 section 250, Health and Care Act 2022, DUAA 2025, Health and Social Care (National Data Guardian) Act 2018, professional record duties, provider governance, candour, records-management codes, clinical safety, provenance, and workflow proof (SRC-241 to SRC-258).

DUAA decision boundary

The Data (Use and Access) Act 2025 should be treated as an England statutory data and information-standard governance layer, not as a compliance badge. It supports asking whether a named NHS England information standard applies to an IT supplier or IT-service provider in the DMICP / Health Connect / HealthShare route. It does not prove DSIC catalogue status, GP Connect assurance, PRSB conformance, clinical safety, local information governance, or InterSystems product compliance by itself.

Healthcare-recording assurance boundary

The UK Healthcare Recording Legal and Professional Position is the decision anchor for recorded care, patient information, and healthcare delivery evidence. Its legal alignment model covers healthcare-record creation, maintenance, sharing, correction, retention, provenance, audit, and disposal in general. It separates data-protection, PECR, confidentiality, section 251, professional duties, provider governance, candour, records management, National Data Guardian governance context, clinical safety, provenance, and the Health and Care Act 2022 / DUAA information-standard chain. It does not prove any Health Connect or HealthShare deployment is compliant without local artefacts (SRC-241 to SRC-258).

Use these proof tables to move from the answer to the evidence boundaries:

Use Health Connect as the mediation layer and HealthShare as the shared-care-record layer. Use Summary Document Architecture (SDA) only as an internal InterSystems transformation/canonical-intermediary pattern where HealthShare or IRIS for Health processing requires it; do not treat SDA as the external compliance interface. Use the SDA/CDA page for the fuller definition of SDA and related InterSystems transformation routes including CDA/C-CDA, FHIR, HL7, DTL, XSLT, Health Connect transformations, and IRIS for Health CDA libraries.

Flow Recommended approach Executive position Needs to be proven
DMICP into CORTISONE / HealthShare Health Connect mediation from whatever DMICP can expose, then SDA or FHIR / HL7 / CDA transformation where needed for HealthShare / IRIS for Health processing. Prefer Health Connect as the controlled integration layer. SDA is useful internally, not a national external route. DMICP interface catalogue, source data model, extract/API capability, mapping rules, data-quality controls, clinical-safety case, and operational runbook.
DMICP to HealthShare shared-care functions Health Connect maps DMICP data into HealthShare UCR, EMPI, Provider Directory, and Clinical Viewer patterns where approved. HealthShare is suitable for longitudinal record, identity, provider data, and direct-care viewing. HealthShare component/version scope, EMPI matching design, provider-directory source of truth, RBAC/SSO/audit, display/provenance rules, DSA/DPIA, DCB0129/DCB0160.
NHS England GP and primary-care connectivity GP Connect where the workflow fits; MESH / ITK3 for document or message flows; PDS and ODS/SDS for identity and organisation data; DSIC capability/standards evidence for any GP software service claim. GP Connect is an England national-service route, not the internal DMICP-to-HealthShare interface. DSIC compliance is solution-level and role-specific. GP Connect supplier/onboarding proof, SSP/HSCN/RBAC/JWT/TLS MA where applicable, MESH mailbox, ITK3 payload validation, PDS/ODS/SDS onboarding, DSIC catalogue/capability evidence.
EMIS or other GP supplier-specific routes Use EMIS Partner APIs / Interface Mechanism 1 (IM1) only as tactical supplier adapters where a named workflow requires them. EMIS Open / IM1 is not the strategic four-nation interoperability layer. It may be needed where GP Connect does not cover a workflow or where a supplier-specific integration is the only approved route. Supplier contract, API scope, practice/ODS scope, data-sharing basis, clinical-safety case, test evidence, support boundary, and migration/exit route.
Regional and hospital systems Use the interface contract each target system actually supports: HL7 v2, FHIR, CDA, IHE XDS/MHD, DICOM/IHE, local APIs, MESH/ITK3, NRL pointers, or local event feeds. Health Connect should mediate and normalise; HealthShare should present or persist only where the deployment role requires it. Target system interface catalogue, endpoint ownership, payload profiles, terminology, monitoring, retry/failure process, clinical safety, and information-governance artefacts.
Wales, Scotland, and Northern Ireland Build nation-specific adapters and governance mappings. Reuse Health Connect / HealthShare architecture, not DSIC or DUAA labels outside England. The four-nation strategy is common architecture with different national-service adapters. Nation-specific API/message routes, identifiers, portal/shared-record interfaces, governance, onboarding, safety, and customer deployment artefacts.

Reference Architecture

flowchart TB
    DMICP["DMICP"] --> HC["Health Connect"]
    HC --> IRIS["IRIS / SDA / FHIR"]
    HC --> ENG["England adapters"]
    HC --> SCO["Scotland adapters"]
    HC ----> HS["HealthShare"]
    HC --> WAL["Wales adapters"]
    HC --> NI["NI adapters"]
    HC --> REG["Regional / hospital"]
    HS --> UCR["UCR"]
    HS --> EMPI["EMPI"]
    HS --> VIEW["Clinical Viewer"]
    HS --> PD["Provider Directory"]
    click DMICP "../knowledge-base/modules/programme-cortisone-uk-defence-healthcare/" "DMICP and Programme CORTISONE evidence" _self
    click HC "../knowledge-base/modules/health-connect/" "Health Connect mediation layer" _self
    click IRIS "../knowledge-base/modules/sda-cda-transformation/#iris-sda-fhir-landing" "IRIS, SDA, and FHIR transformation route" _self
    click ENG "../knowledge-base/modules/nhs-england-digital-primary-care/#england-adapter-landing" "NHS England digital primary-care adapters" _self
    click SCO "../knowledge-base/modules/scotland-connectivity-equivalents/" "Scotland connectivity equivalents" _self
    click HS "../knowledge-base/modules/healthshare/" "HealthShare shared-care layer" _self
    click WAL "../knowledge-base/modules/wales-connectivity-equivalents/" "Wales connectivity equivalents" _self
    click NI "../knowledge-base/modules/northern-ireland-connectivity-equivalents/" "Northern Ireland connectivity equivalents" _self
    click REG "../knowledge-base/modules/dsic-healthshare-compliance-map/#executive-summary-interface-alignment" "Regional and hospital adapter evidence boundary" _self
    click UCR "../knowledge-base/modules/healthshare-unified-care-record/" "HealthShare Unified Care Record" _self
    click EMPI "../knowledge-base/modules/healthshare-empi/" "HealthShare EMPI" _self
    click VIEW "../knowledge-base/modules/clinical-viewer/" "HealthShare Clinical Viewer" _self
    click PD "../knowledge-base/modules/healthshare-provider-directory/" "HealthShare Provider Directory" _self

The architecture should be treated as a target pattern until DMICP, CORTISONE, national-service, and customer deployment artefacts prove the actual route. Diagram nodes link to the relevant evidence or synthesis landing pages.

The compact Mermaid labels are intentional. Use the strategy and four-nation tables for the detailed route names, standards, onboarding artefacts, and governance dependencies.

NHS England And DSIC Route

NHS England connectivity can be achieved where the deployment proves the relevant role:

Area What InterSystems tooling can support What is already evidenced What still needs proof
DSIC-aligned shared-care architecture HealthShare UCR, Clinical Viewer, EMPI, Provider Directory, Health Insight, Health Connect, IRIS for Health, and FHIR Server. High product relevance for shared-care, integration, identity, provider-data, viewer, analytics, FHIR, and transformation patterns. DSIC catalogue/supplier entry, capability scope, standards scope, deployment architecture, clinical-safety case, information-governance pack, supplier responsibility matrix.
GP Connect consumption or messaging HealthShare as consumer/viewer where approved; IRIS for Health / Health Connect as Send Document or messaging middleware where assessed. NHS supplier-progress evidence maps IRIS for Health (Middleware) to Send Document (Send) v2.0.1 and HealthShare to selected Access Record Structured cells. Current product/version implementation guide, onboarding, customer deployment proof, interface test pack, MESH/ITK3 artefacts, NDSA/DSA, DCB0129/DCB0160.
PDS / NHS number and demographics Health Connect integration and HealthShare EMPI can support identity and matching patterns. PDS evidence defines local-copy, invalid/superseded NHS-number, warning/back-office, and synchronisation requirements; one PDS integrated-products row names Intersystems HealthConnect 2020.1 for North West Anglia. HealthShare EMPI product/version use, PDS FHIR onboarding, matching/stewardship design, local safety and audit artefacts.
ODS / SDS and provider or organisation data HealthShare Provider Directory and Health Connect can support organisation/provider-data patterns. ODS evidence defines organisation-code lookup, relationships, succession, validation, and local synchronisation requirements. ODS/SDS integration, authoritative-source decisions, directory governance, synchronisation, audit, and deployment proof.
DSIC GP foundation system InterSystems components can contribute to a solution, especially integration and shared-care roles. Current evidence supports component relevance. Not proven: full GP foundation capability coverage, prescribing/EPS, GP2GP, registration, appointments, consultation, document/task/reporting/scanning, migration, training, catalogue status, and supplier assurance.

Four-Nation Extension

The extension model is to reuse the Health Connect / HealthShare pattern while swapping national adapters and governance by administration.

Administration Connectivity route What InterSystems can enable What is not yet proven
England DSIC, GP Connect, Spine services, PDS, ODS/SDS, MESH, ITK3, EPS, e-RS, NHS App / NHS login, NCRS and NRL context. Strong fit for integration, shared-care, GP Connect consumer/middleware, identity/directory, FHIR, and messaging patterns. Full DSIC compliance, customer deployment, GP foundation status, complete onboarding and assurance artefacts.
Scotland CHI, ECS/KIS, National Digital Platform, SCI Gateway, ePharmacy, MyCare.scot, and board/local routes. Health Connect can mediate Scottish national or local interfaces; HealthShare can support shared-record/viewer patterns if commissioned and integrated. No current evidence proves GP Connect use in Scotland or an InterSystems national Scottish integration role beyond separate TrakCare/Ensemble evidence.
Wales Welsh GP Record, Welsh Clinical Portal, Welsh Clinical Communications Gateway, National Data Resource / Care Data Repository, Welsh Demographic Service, NHS Wales App, and all-Wales LIMS context. Health Connect can mediate Welsh national or local interfaces; HealthShare can support shared-care patterns if a Welsh deployment exists. Current InterSystems Wales evidence is strongest for LIMS / TrakCare Lab Enterprise, not general HealthShare or GP Connect-equivalent connectivity.
Northern Ireland encompass, EpicCare Link, My Care, Health and Care Number, Digital Identity Service, ePharmacy, and legacy NHAIS / GP-registration context. Health Connect could mediate local HSC interfaces where contracted; HealthShare could support shared-record patterns only if separately procured and evidenced. Current InterSystems NI evidence is limited to Caché / NHAIS licensing; no HealthShare, Health Connect, TrakCare, or GP Connect-equivalent claim is supported.

Product Role Split

Component Recommended role in the answer Avoid over-claiming
Health Connect Primary mediation, transformation, routing, monitoring, and national/local adapter layer. Do not claim current NHS conformance or CORTISONE live use for every route without product/version and onboarding evidence.
HealthShare UCR Shared longitudinal record and normalised clinical-data layer. Do not describe it as a complete GP foundation system.
Clinical Viewer Direct-care presentation layer over approved shared-record data. Do not infer SSO/RBAC/audit or customer configuration from product positioning.
EMPI Patient identity matching and cross-system person resolution. Do not infer PDS onboarding or matching governance without artefacts.
Provider Directory Organisation/provider master data and directory support. Do not infer ODS/SDS implementation without artefacts.
IRIS for Health Healthcare data platform, FHIR/application layer, and possible middleware/application foundation. Do not treat platform capability as DSIC, GP Connect, or NHS Standards Directory compliance.
SDA Internal InterSystems transformation/canonical intermediary. Do not treat SDA as a national external interface or persistent target model.
GP Connect / MESH / ITK3 / IM1 / supplier APIs External interface routes selected by use case and administration. Do not use one route as a generic substitute for every GP, national, regional, or hospital integration.

Evidence Confidence Snapshot

Claim Current confidence Basis Main proof gap
DMICP is a Defence primary healthcare record/data source. High GOV.UK DMICP description. Current extract/API/interface specification.
CORTISONE needs NHS interfaces across all four nations. High for programme intent CORTISONE programme vision. Live interface catalogue and deployment status.
InterSystems has a CORTISONE role. High for licence/supplier fact; moderate-high for wider role Vendor, MOD performance, and Contracts Finder evidence. Full architecture, configuration, service levels, and live clinical scope.
Health Connect is suitable as mediation layer. High for product capability Product and technical documentation. Named DMICP/CORTISONE Health Connect route and assurance artefacts.
HealthShare is suitable as shared-care layer. High for product capability Product/component evidence and PRSB CIS conformance. Named deployment architecture, role/access configuration, clinical-safety and information-governance proof.
DSIC compliance can be achieved by the solution. Plausible but not proven DSIC model plus InterSystems component relevance (SRC-202 to SRC-209). DSIC catalogue/capability/standards evidence and deployment artefacts.
Four-nation extension can use the same pattern. Plausible architecture Devolved functional-equivalence evidence supports different national routes. Nation-specific interface contracts, governance, onboarding, and customer proof.

Decision-Relevant Gaps

These are the gaps that block a confident answer:

  • DMICP source-interface specification and current data model.
  • CORTISONE architecture showing Health Connect, HealthShare, IRIS for Health, EMPI, clinical portal, and national-interface responsibilities.
  • Product/version scope for Health Connect, HealthShare, IRIS for Health, EMPI, Provider Directory, Clinical Viewer, and any FHIR services.
  • DSIC catalogue, capability, standards, and supplier-role evidence for any England GP software/service claim.
  • GP Connect, MESH, ITK3, PDS, ODS/SDS, NDSA/DSA, endpoint/certificate, testing, and operational onboarding artefacts.
  • DCB0129 supplier safety, DCB0160 deployment safety, DPIA, data-sharing agreement, controller/processor matrix, DSPT, audit, incident, and service-management evidence.
  • Legal/professional record-handling pack: UK GDPR/DPA lawful basis and Article 9 condition, PECR controls where applicable, confidentiality route, section 251 or consent/anonymisation where needed, amendment/export/search procedure, retention/disposal schedule, professional workflow support, provenance, and candour workflow.
  • Wales, Scotland, and Northern Ireland interface catalogues and governance packs for their own national routes.

Where To Go Next