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.

...

Other opportunities (see clause 51.3 of the Change Management and Roadmap Content ancillary document). There are certain work items such as standalone features, or Capabilities required to meet a newly identified business need, which do not need Opportunities for the wider Supplier market to deliver changes such as new Capabilities or standalone features which do not necessarily have to be implemented by all relevant Suppliers and could therefore be opened up to the wider Supplier market to deliver. These Foundation Solution Suppliers or Suppliers supporting a particular Capability. These opportunities may allow a Supplier to set their product apart from others and potentially enter new markets and gain market share or offer a product via the Framework which they may have not been able to previously. Whilst these are work items which need to be delivered to meet a business need, it is not necessarily important who delivers them, on the assumption that suitable APIs and interoperability are available. These opportunities will be managed via fully open or constrained competitions which are open for all eligible parties to bid for, including Suppliers of Foundation Solutions. However changes in this route do not need to be delivered by the Foundation Solution Suppliers, unless they choose to bid for them, and in many cases may be better delivered by specialist Suppliers from the wider market who may already have products to deliver the desired outcome. This should reduce the burden on Foundation Suppliers by placing the emphasis on pulling in products which may already be in existence rather than forcing additional development which Foundation Suppliers may not wish to or be able to undertake given their other obligations. This therefore ought to increase the speed and efficiency of delivery. Additional funding is likely to be available for this work.

Feasibility Assessment

...

changes which may be more efficiently and effectively delivered by Suppliers who already have existing products to meet the desired business needs rather than commissioning bespoke development from existing Suppliers.

Feasibility Assessment

(See clause 51.1 of the Change Management and Roadmap Content ancillary document). The Feasibility Assessment process will be controlled in the same manner as the Opportunity Items.  It is to cover change requests requiring an assessment involving input, analysis and feedback from Suppliers to assist in determining the feasibility, scope, sizing/complexity and nature of the change request prior to it progressing through one of the other change routes and also to assist in defining specifications. This is for work which does not require any development, but goes beyond the scope and time required for an RFI / Analysis only item for which Supplier engagement is required under the relevant clauses of as set out in the Catalogue Agreement. Items in this route will be subject to an accelerated competition process to engage as many Suppliers as the change requestor may wish to appoint based on the bids made. Following completion of the Feasibility Assessment, the change may either be withdrawn or progressed via one of the other change routes. Additional funding may be available for this in some cases. This route may be the mechanism used to engage Supplier in changes progressing as an Urgent Change or through Managed Capacity where specifications need to be defined.

Urgent Change

It is recognised that there are some changes which need to be introduced quickly, outside of the regular principles of change management and the Roadmap to mitigate serious issues in the health and care system.  This will only account for a very limited amount of change. Urgent Change is defined in the Catalogue Agreement where some broad criteria for classifying a change request as urgent are set out. This ancillary document further defines these criteria, specifying the precise nature of the changes which may be classed as urgent in the first GP IT Futures Framework These are as follows:

...