Page Comparison

...

Capabilities are the distinct functions a business needs, and often directly map to modules or functions which a Solution may provide. This is a step change away from having Principal and Subsidiary systems. The introduction of Capabilities for GP IT Futures is intended to allow Suppliers to innovate by being less prescriptive and also to segment the requirements in a way to allow more flexibility and choice for buyers. The scope of what historically made up the Principal Clinical Systems has now been broken down into Capabilities.

Structure of a Capability

Each Capability will have an ID, title, description, outcomes, epics and acceptance criteria and then potentially other elements to give more detail as necessary. This section describes the structure of a Capability and the information within it.

Capability ID

Each Capability has a unique identifier composed of one letter followed by a number. The letter C indicates a Capability. The number is arbitrary and does not have any additional meaning such as priority, sequence or inter-relationships. This allows for the identification of Capabilities in a consistent manner.

...

Each Capability has a version number. Version numbers will iterate depending on the nature of the change (e.g. major, minor, patch) impacting the Capability. There is no relationship between the version numbers of different Capabilities and Standards.

...

A concise description of the purpose of the Capability.

Outcomes

This describes the main users of the Capability and the outcomes they want to achieve from using the Solution.

Epics and acceptance criteria

These describe the requirements of the Capability at a high level and will be used to assess the suitability of Solutions from suppliers at the Capabilities Assessment stage of onboarding.

The Epics are written as high level user stories with Acceptance Criteria describing the conditions which can be demonstrated for the user stories to be considered achieved.  The collection of Epics which make up the qualifying component of each Capability description, simply describe the minimum functions that a Catalogue Solution must be able to demonstrate in order to be classified as achieving the Capability in question.

Suppliers will be assessed against 'Must' Epics only. 'May' Epics may be detailed for information.

...

A set of Foundation Capabilities have been identified which will be the access point for GMS funding. These are a subset of the wider set of Capabilities mandated in the NHS England GP IT Operating Model.  The Foundation Capabilities are clearly identified on the Capability and Standards Model.  Suppliers do not have to supply any of the Foundation Capabilities and can choose to provide one or more.  Buyers will have to take all of the Foundation Capabilities in order to access central funding.

Standards

...

1. Overarching Standards (e.g. Information Governance) 
   These will be applicable to all Supplier Solutions and are NHS Digital Standards reasonably agnostic of care setting.
2. Capability Specific Standards (e.g. Appointments Management - GP)
   These are only applicable to Supplier Solutions delivering a particular Capability and may contain business rules, data items and best practice.  
3. Context Specific Standards - these Standards are only applicable to some Supplier Solutions depending on the implementation and scope of Capabilities they are supporting.  Suppliers will have to go through compliance against these Standards per Solution offering.  These include:
   1. Interoperability Standards (e.g. GP Connect APIs, IM1, PDS, eRS and ePS integration etc.). These cover various mechanisms for interoperability and national integration.  Each entry will be mapped to one or many Capabilities. 
   2. Common Reporting - applicable to any Solution providing a Capability that has reporting requirements.
   3. Management Information Reporting - supports the collection and submission of information to NHS Digital.
   4. Citizen Access - applicable to any Solution providing Citizen facing Capabilities.

...

Each Standard has a version number. Version numbers will iterate depending on the nature of the change (e.g. major, minor, patch) impacting the Standard. There is no relationship between the version numbers of different Capabilities and Standards.

...

Given that many Capabilities have linked Standards, when a Standard is to be introduced or uplifted as the result of a change request, an assessment will need to be undertaken to determine if the change to the Standard has a significant impact on the scope of the Capability and hence when it can become Effective. This is known as the Materiality assessment and the details of this are set out below. 

Anchor
Change routes Change routes

Routes of change REVIEW FROM HERE

There are four key routes by which change will be progressed and commissioned following assessment, as shown by the diagram. In addition to these key routes of change, Suppliers will be required to respond to RFI / Analysis only items and may also initiate change themselves based on internal development and delivery plans. Further detail on each of these stages and the assessment processes is set out beneath the diagram. It is possible that these routes may be used in parallel or consecutively for a single change. For example there may be a change request which is a standalone feature or perhaps a new messaging interface specification which is best progressed initially as an Opportunity Item, before being Published and mandated for development and implementation by all relevant Suppliers via the Managed Capacity route. A Feasibility Assessment may be used as an aspect of elaborating the specification and detailing the parameters of a change prior to it progressing into one of the other change routes.

...