Background

The GEN2 changes outlined below are part of the evolution of the existing relevant Digital Services for Integrated Care (DSIC) Capabilities and Standards Model into a new format. The intention of the new format is to provide a more flexible requirements model that reduces barriers to innovation as Suppliers can build iteratively to meet user needs. 

The Authority’s goal is to have restructured the relevant DSIC Capabilities and Standards so that they conform to the below principles:

1. A more permissible model with a minimum number of MUST Epics in each Capability to cover:

   1. Scope of Capability generally (may be more than 1, but keeping to a minimum)

   2. Serious Clinical Safety implications if not a MUST and there isn’t a safe alternative

   3. Covers Legal Requirements for Practices

   4. Supports the Practice meeting their obligations under the GP Contract

   5. Any mandated national Interoperability Standards mapped to that Capability

   6. To cover any other Standards that map specifically to that Capability e.g. Management Information Reporting Standard or eMED3 Standard (this does not include Overarching Standards)

2. Majority of existing MUST Epics will change to be MAYs and new MAY Epics will be added in some cases to replace requirements from within Capability Specific Standards

   1. This allows the Supplier to choose which MAY EPICs to implement and evidence. We expect the Suppliers to recognise the need to provide a comprehensive product based on their user feedback and their desire to be competitive against other solutions

3. Mandatory Overarching Standards will remain

4. A number of Standards are planned to be removed as part of the GEN2 transition, including Capability Specific Standards (e.g. Appointments Management - Citizen - Standard) once the requirements within have been reviewed and one of the following actions taken: 

   1. Requirement is removed and re-written as part of the Epics and Acceptance Criteria within the associated Capability (i.e. as a completely new Epic or as amendments to an existing Epic)

   2. Requirement is removed and the important details added as Additional Implementation Details against an Epic within the associated Capability

   3. Requirement is removed and the important details added as Supporting Information against an Epic within the associated Capability (this could be directly against the Epic or on a Reference Page referenced from the Supporting Information against the Epic)

   4. Requirement is removed entirely (i.e. because it is a duplicate requirement and doesn’t specify anything that isn’t already covered by an Epic or it is deemed non-essential and too low level for the Epics)

   5. Requirement is moved into another Standard

Outline Plan

N/A

Summary of Change

Full Specification

Caseload Management v1.0.2

Please note, the scope of the Capability has not increased as a result of the changes made.

Assurance Approach

For Suppliers with Solutions already on the Buying Catalogue: 

• The results of previous Capability Assessments will be carried over from GEN1 to GEN2 for Epics and Acceptance Criteria that have not changed 

• For new Epics or Epics that have been amended as a result of the Capability Specific Standard being retired, the results of previous assurance will be carried over and no further evidence or assurance will be required

For New Suppliers: 

• These Epics will be assessed as part of the Capability Assessment phase and this will be a high level assessment based on the Acceptance Criteria defined

• These Epics are not intended to replace the full assurance process for any related Standards (e.g. assessing the Epic does not negate the need for the Interoperability Standard to be fully assured by the appropriate team)