Digital Services for Integrated Care
After the Defence mechanism map, use this page to read capability requirements and assurance evidence. It provides the context for the Tech Innovation Framework and the planned GP IT framework.
Research checked: 17 October 2026. Digital Services for Integrated Care (DSIC) is NHS England's wider model for improving digital products across care settings. It combines capabilities, standards, assurance and commercial routes. It evolved from GP IT Futures and extends beyond core GP systems. 111
Where DSIC sits
| Element | Role | Distinction |
|---|---|---|
| DSIC | Defines and supports the wider model for products and services. | It is not the name of a single clinical application or procurement framework. |
| Capabilities and standards | Describe functional needs and technical or operating requirements. | Their applicable versions and contractual status matter. |
| Buying Catalogue | Helps buyers find solutions and examine their assured capabilities. | A listing does not establish that every intended local use is approved. |
| Tech Innovation Framework | A route for modern core GP EPR solutions. | Its requirements must be read within that framework's scope. |
| Digital Primary Care Open Framework | The planned successor procurement, with three proposed lots. | A UK3 notice does not establish supplier appointment or a live purchasing route. |
The programme, buyer guidance and current notice establish these different roles. 111, 113, 109
Read the requirement structure
The supplier introduction gives more precise meanings than a general capability label. 116
| Term | How to read it |
|---|---|
| Capability | A high-level business need. |
| Epic | A functional requirement within a capability. |
| Acceptance criteria | Minimum testable functions for an epic; all associated criteria must pass. |
| MUST epic | Mandatory for the capability assessment. |
| MAY epic | Additional functionality, unless the contracting vehicle or supplementary care standard makes it mandatory. |
| Additional Implementation Details | Mandatory details assessed during assurance. |
| Supporting Information | Explanatory guidance, rather than assessed requirements. |
| Standard | Technical or operating conditions for catalogue compliance. |
| Supplementary Care Standard | Requirements grouped around a particular care service. |
The Lot 2 examples show the practical consequence: a product can cover a capability without implementing every optional workflow. Always record the capability identifier, version, status, applicable contract and relevant epics.
Assurance has stages and boundaries
The buyer guide distinguishes foundation products, which meet six core capabilities, from non-foundation products assessed against their own capabilities. Its Baseline Assurance Standard provides initial assessment against a minimum risk-based set. Remaining overarching compliance must follow within an agreed timeframe. Do not flatten these stages into one unqualified approval label. 115
For an NHS–Defence use, keep four evidence questions separate:
- Does the commercial route cover this buyer and purchase?
- What product, capability, version and assurance status are evidenced?
- Is the intended national-service connection permitted and onboarded?
- Has the local clinical workflow been accepted, with accountable users and operating controls?
This is COPPER TIGER's assessment structure. Procurement and catalogue evidence cannot independently answer all four questions. The GP Connect discussion and legal framework address further boundaries.
Migration and clinical continuity
The clinical system migration guide applies to changes between established foundation suppliers. It is not intended for new-supplier onboarding, although some steps may apply. It is not a complete local project plan. It covers responsibilities and activities such as data checking, cutover and go-live support. 123
Do not merge whole-practice migration, individual GP2GP transfer, GP Connect access and shared-record aggregation into one concept of interoperability. Each has different participants, triggers and failure consequences. See Lot 1 for the record-continuity implications.
Research trail and independent sources
Research began with the local InterSystems, Care Hub and DMICP InterOp wikis and repositories. These supplied taxonomy, procurement and roadmap leads. The statements here were then checked against the original public sources. Local source identifiers were not imported as COPPER TIGER evidence.
One local description treated TIF as a route for modular services alongside a foundation system. The current official TIF page instead requires six core EHR functions. That broader local description has not been adopted here. 112
Start independent research with the DSIC overview, supplier requirement introduction and buyer capability guide. The research log records the local-first sequence; the source register preserves dates and access limitations.
Continue with the Tech Innovation Framework for a bounded example of foundation-system scope, assurance and clinical release.