Table of Contents

maxLevel	3

...

Introduction

This document is an Ancillary Document to support the Catalogue Agreement provides further information in support of the Change Management and Roadmap Content ancillary document and should be read in conjunction with that and the relevant parts of that the Catalogue Agreement. It is in three main sections:

Change Management Process and Roadmap Content Ancillary Document describes the Capabilities and Standards Model.

Change Management Process and Roadmap Content Ancillary Document describes the operating principles and processes by which changes to Standards and Capabilities will be managed, defined and implemented in GP IT Solutions which are already listed on the Catalogue and Framework and through providing opportunities for the wider GP IT System Supplier market.

Change Management Process and Roadmap Content Ancillary Document sets out a view of the GP IT Futures Standards and Capabilities Roadmap ('the Roadmap') which presents the opening and known future new and uplifted Standards and Capabilities to be delivered and implemented in GP IT Systems.

The scope of this description covers the assessment and commissioning of new and uplifted Standards and Capabilities up to the point where a Supplier begins development and assurance. The high level approach to development, assurance, deployment and Supplier initiated changes under GP IT Futures is covered in separate Schedules and Ancillary Documents.

...

Capabilities

The requirements to deliver General Practice IT Solutions have been grouped into Capabilities. Each Capability describes a business need at the highest level. For example, 'Recording Consultations' describes the need for General Practice staff to be able to make a digital record of any consultation with a patient. Capabilities are used as the Solution classification system as operated within the Buying Catalogue.

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.

Capability version

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.

Capability description

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

The ancillary document describes:

the Standards and Capabilities Model within the operation of the Catalogue Agreement
the nature of Catalogue changes and the Roadmap
the manner in which changes will be made to the Roadmap
the management of Urgent Change within the Catalogue
the provisions associated with Managed Capacity
Opportunity Items and associated change.

This page sets out additional detail which builds on these descriptions, in particular regarding the information to be included on the Roadmap, versioning of Standards and Capabilities and the processes of the Catalogue Authority in managing change. The relevant section sand clauses of the ancillary document are referenced accordingly within this document

Standards and Capabilities Model

Capabilities

Info
This section relates to clauses 3-8 of the Change Management and Roadmap Content ancillary document

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.

Capability version

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.

Capability description

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.

Use of Capabilities

Capabilities will be used by:

...

Suppliers do not have to provide a Solution that delivers all Capabilities and are free to design and build solutions that meet one or more of the Capabilities. By looking at the Capabilities, Suppliers can see where their product portfolio fits, either by making tweaks to existing Solutions where required or building new solutions to expand the Capabilities that they provide for. For example, Supplier 'A' may build a solution that delivers 'Document Management', 'Workflow' and 'Patient Information Maintenance' Capabilities, whereas Supplier 'B' may choose to build a system that just delivers Document Management.

Foundation Capabilities

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

...

Info
This section relates to clauses 9-17 of the Change Management and Roadmap Content ancillary document
Standards describe the technical or operating conditions required to achieve Catalogue Compliance. Those which are Effective and are applied to a Capability represent the minimum acceptable conditions pertaining to the performance of services, safety, security and recording practice for any given system performing the functions represented by the Catalogue Solution in question. They include a re-presentation of other applicable NHS Standards, a set of interfaces and technical specifications associated with the transmission of data or integration with national services, or they may be context specific and applied differentially to Catalogue Solutions based on Solution type and risk profile.
Suppliers will have to assess and develop their Solutions against the Effective Standards in order to gain compliance status.
Standards will be made up of a set of requirements.

Classes of Standards

There will be three classes, or types, of standards:

...

Classes of Standards

There will be three classes, or types, of standards:

Overarching Standards (e.g. Information Governance)
These will be applicable to all Supplier Solutions and are NHS Digital Standards reasonably agnostic of care setting.
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.
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.

...

We will stay closely aligned to the Standards publishing bodies and flag the development of new Standards via the Roadmap we publish to Suppliers and Buyers.

Structure of a Standard

Standard ID

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

Standard Version

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.

GP IT Futures will regularly review and update the Standards with an iterative model to ensure they stay relevant and reflect the current needs of General Practice. Suppliers will have to remain compliant with Standards in order to fulfil their obligations on the Catalogue Agreement.

Standard Type

Where applicable this defines the type of standard which includes:

Capability specific Standard
Context specific Standard
Overarching Standard

Effective Date

Those Standards which are mandated under the Catalogue Agreement will have an Effective Date by which suppliers must comply with the Standard. There may be incentives for suppliers to deliver earlier than Effective Dates. There will be remediation enacted if suppliers do not meet compliance levels required by the Effective Date. These details and penalties will be set out in the terms of the relevant Framework Agreement.

Suppliers will need to have achieved compliance against all Effective Standards (see Status below) in order to onboard on to the Catalogue and be awarded a place on the first GP IT Futures Framework

Status

Each Standard will have one of three statuses:

Draft
Published
Effective

These terms and the lifecycle of a Standard are described in more detail in the Change Management Process and Roadmap Content Ancillary Document section below.

Requirement ID

Each requirement within a Standard will have a unique ID so it can be recognised during compliance.

Requirement Level

Each requirement in a Standard will have an associated Level which Suppliers will have to evidence against during compliance. There are three levels as described in RFC 2119.1:

• Must: This word, or the terms “required” or “shall”, means that the definition is an absolute requirement of the specification

• Should: This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

• May: This word means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. Delivery of such requirements is at the discretion of the Supplier. However, it should be noted that NHS Digital has expressed a desire for development in this area.

Use of Standards

Standards will be used by:

NHS Digital to express the business needs at the most granular level when needed
Suppliers to understand what is expected of them in order to be compliant and to onboard onto the Buying Catalogue
NHS Digital Solution Assurance to assess Supplier Solutions against in order to award compliance
Buyers to assess various Suppliers against each other (levels of compliance / functionality) for competitive procurements.

Standards will always be mapped to Capabilities. This mapping will be managed and displayed to Suppliers (via Confluence initially) and inherently in the Buying Catalogue so that Suppliers and Buyers can clearly see compliance of a Solution.

During the Compliance phase of on-boarding to the Buying Catalogue, Suppliers will have to evidence how they will meet all of the Standards applicable to their Solution, dependent on the Capabilities they will provide.

...

The Capabilities and Standards Model represents the scope of the first GP IT Futures Framework. It is represented in a clickable form on the Confluence Overview page in order for all stakeholders to navigate through.

Image Removed

Publication of Capabilities and Standards

Confluence will be used to publish all Capabilities and Standards. This may change in the future.

The live site can be accessed here. (Not yet live)

NB. Supplier Engagement site where Suppliers can access the Capabilities and Standards for now is here.

...

It is recognised that Standards and Capabilities will need to be introduced, uplifted and replaced from time to time to account for requests for change and to ensure they remain up to date, relevant and fit for purpose. New or uplifted Standards and Capabilities could be requested as a result of:

changes in Department of Health and Social Care (DHSC) and/or NHS England policy
changes in legislation relating to Primary Care
new technology and interoperability requirements
feedback from Suppliers and Buyers
the identification of new business needs
the GP IT Futures Technology Strategy and Plan
the planned ongoing and iterative internal review of Standards and Capabilities to ensure they remain relevant, up to date and fit for purpose.

These reviews and requests for change may then result in new or uplifted:

...

needs of General Practice. Suppliers will have to remain compliant with Standards in order to fulfil their obligations on the Catalogue Agreement.

Standard Type

Where applicable this defines the type of standard which includes:

Capability specific Standard
Context specific Standard
Overarching Standard

Effective Date

Those Standards which are mandated under the Catalogue Agreement will have an Effective Date by which suppliers must comply with the Standard.

Suppliers will need to have achieved compliance against all Effective Standards (see Status below) in order to onboard on to the Catalogue and be awarded a place on the first GP IT Futures Framework

Status

Each Standard will have one of three statuses:

Draft
Published
Effective
Retired

These terms and the lifecycle of a Standard are described in more detail in the Change Management Process and Roadmap Content Further Information section below.

Requirement ID

Each requirement within a Standard will have a unique ID so it can be recognised during compliance.

Requirement Level

As defined in RFC 2119.1, the Change Management and Roadmap Content ancillary document and the Master Glossary

Use of Standards

Standards will be used by:

NHS Digital to express the business needs at the most granular level when needed
Suppliers to understand what is expected of them in order to be compliant and to onboard onto the Buying Catalogue
NHS Digital Solution Assurance to assess Supplier Solutions against in order to award compliance
Buyers to assess various Suppliers against each other (levels of compliance / functionality) for competitive procurements.

Standards will always be mapped to Capabilities. This mapping will be managed and displayed to Suppliers (via Confluence initially) and inherently in the Buying Catalogue so that Suppliers and Buyers can clearly see compliance of a Solution.

During the Compliance phase of on-boarding to the Buying Catalogue, Suppliers will have to evidence how they will meet all of the Standards applicable to their Solution, dependent on the Capabilities they will provide.

Anchor
Capabilities and Standards Model
Capabilities and Standards Model
Capabilities and Standards Model

The Capabilities and Standards Model represents the scope of the first GP IT Futures Framework. It is represented in a clickable form on the Confluence Overview page in order for all stakeholders to navigate through.

Image Added

Publication of Capabilities and Standards

Confluence will be used to publish all Capabilities and Standards. This may change in the future.

The live site can be accessed GP IT Futures Capabilities and Standards - Home

Change Management

Info
This section relates to clauses 18-54 of the Change Management and Roadmap Content ancillary document

Anchor
Definitions
Definitions
Definitions

Term	Definition
Horizon	Changes which are on the Horizon will be represented in a separate section of the overarching Roadmap and are included for information purposes. A Horizon item is a potential change which NHS Digital are aware of, but it has either not been formally submitted into the change process and/or is only an idea or high level concept with little or no specification in place. It indicates items which are further into the future and for which it is yet to be determined whether it will progress and if so which of the change routes it will progress through.
Managed Capacity	The main route for progressing new and uplifted Standards which apply to all relevant Suppliers and which are likely to have a Published specification. Where these have an Effective Date, all relevant Suppliers will be obliged to have achieved compliance with these items by the given date as per the terms of the Catalogue Agreement. Changes in this route will be separated into big and small items and will fall into one of four categories: SRO priorities Legislative and Regulatory change Minor and Patch uplifts Other These items will only be commissioned via the Roadmap and Suppliers are expected to incorporate any development cost within their agreed List Price.
Opportunity Item	Opportunities for Suppliers to bid via open competitions to engage with NHS Digital and the change requestor to collaborate on the definition of specifications and to deliver certain changes early ahead of publication to the wider market where applicable. Changes in this route will fall into one of three categories: Alpha/Definition/FoT - opportunities for Suppliers to co-produce specifications before they are Published to all other relevant Suppliers through Managed Capacity and given an Effective date if applicable Other opportunities - opportunities for development of new Capabilities or standalone features which do not have to be delivered by Foundation Solution Suppliers and which may allow a Supplier to bring a new product to market and/or for existing products to be pulled in from specialist Suppliers rather than forcing additional development on a limited number of Suppliers.
Feasibility Assessment	Opportunities for Suppliers to collaborate with NHS Digital and/or the change requestor to provide information and analysis to assess the feasibility of a new change request before it progresses through another route
Urgent Change	Change requests which impact Standards and Capabilities which need to be progressed quickly outside of the usual change management principles. These will be commissioned separately, will likely have separate funding and will account for only a highly restricted volume of change meeting one of two criteria: National information or cyber security incidents as classified by the appropriate body Inappropriate, incorrect or missing drug or patient safety guidelines/alerts and other clinical safety issues and incidents as determined by an appropriate body
Draft	This is the status associated with specifications for a new or uplifted Capability or Standard which are still going through definition and elaboration with stakeholders. Draft specifications will be released to Suppliers for review via the Confluence Roadmap page and iterated as often as possible There will be opportunities for Suppliers to engage in the definition of Draft specifications Suppliers can begin development when a specification is at Draft status, although they do so at their own risk At Draft status there will be a Supplier facing Roadmap page on which detail of the specification is released as it becomes available.
Open Competition	An open competition is the mechanism used to initiate an Opportunity Item. It may be run against Lot 2 of the GP IT Futures Framework or progress via an alternative mechanism. It is a way of engaging Suppliers in change and the parameters and characteristics of each competition will be defined on a case by case basis It will also be used as a 'status' on the Roadmap to indicate to Suppliers that a particular change item will be subject to an open competition procedure which they may wish to bid for. The date given against these items will indicate the anticipated date of when the open competition will be released.
Published	This is the status associated with specifications for a new or uplifted Capability or Standard which are fully defined, agreed and signed off and are not expected to change. Where there is a need for minor or patch uplift, this will be handled as described in the Change Management Process and Roadmap Content Ancillary DocumentFurther Information section. Suppliers would be expected to be working towards achieving compliance with a specification when it is given this status. There may be some Standards and Capabilities which do not progress beyond this stage in which case they would be advisory or reflect some other scenario where it remains optional at that point. A checklist will be in place to ensure that before this status is awarded, the specification is adequately defined and ready for implementation with all necessary assurance, implementation and guidance documentation in place to enable a Supplier to complete development at minimal risk. At this point a full version of the Confluence page will be released. In the case of uplifts to existing Standards and Capabilities, this will be a complete, refreshed version of the page e.g. if there is an uplift to Data Standards, the changes will be on or linked to from the relevant Roadmap page and are likely to only show the specific requirements which are changing until it is Published, when a full updated version of the Data Standards page with a revised version number will be made available and will sit alongside the Effective version.
Effective	This is the status associated with Standards with which all relevant Suppliers are required to have achieved compliance. It is the status associated with Capabilities which have been included within the scope of a Framework request and hence which Suppliers are able to onboard Solutions against and sell via a Framework. When the Effective Date is reached, the old Effective page will be replaced by the new one with an uplifted version number. The old one will be given a status of Retired and moved to a specific location on Confluence.
All relevant Suppliers	This term is used to indicate that Suppliers have the choice as to which Capabilities they choose to offer through the GP IT Framework and as such there are different Standards with which they will need to be compliant. Therefore if a change to a Standard is not applicable to the products the Supplier is offering, then that change is not relevant to them
Achieved compliance	This means that a Supplier has been awarded a DevMAC for the Roadmap item.
Effective Date	The date on which the Standard or Capability becomes Effective. An Effective Date will be given as a month and a year (rather than a specific day) and will always mean the last day of the given month i.e. an Effective Date of September 2019 means 30th September 2019. It is the date by which all relevant Suppliers will need to have achieved compliance with the change item. It is recognised that in the case of some legislative or regulatory changes, there may be a specific date on which it comes into force. Where this is the case, this will be reflected accordingly in the materials released.
Backstop Date	This term means the same as Effective Date and should not be used.
Retired	This is the status associated with old versions of a Capability or Standard which have been uplifted or replaced. These pages may be superseded by a new Published or Effective specification. These pages will remain available for reference in a specific location on Confluence.
Closed	This is the status associated with a change request which will not be progressing. It is recognised that some change requests are submitted into the process and then are not taken forward at some point for a variety of reasons, therefore this status will be used to indicate to Suppliers that a change which had previously appeared on the Roadmap is now no longer required and they should not continue work on it. Changes at this status will remain on the Roadmap for a period of time to ensure awareness.
Mandated	This term describes a Standard within the Managed Capacity route which Suppliers must deliver and which has been given an Effective Date by which all relevant Suppliers must have achieved compliance. Use of this term should be avoided where possible, instead referring to the Effective Date.
Must / Should / May	See entry for 'Level' in the Master Glossary.
Day 1 Standard	This term describes the Standards with which a Supplier will need to have achieved compliance in order to onboard on to the Catalogue and be awarded a place on Framework 1. Due to the way in which the procurement, onboarding and the compliance process will work, the date on which Suppliers will actually join Framework 1 will differ. It is anticipated that the earliest date that Suppliers could join the first Framework is July 2019, therefore this is the earliest possible Effective Date of a Day 1 Standard. As there are Standards with Effective Dates at any point beyond this, Suppliers will need to have achieved compliance with these as a condition of joining Framework 1 i.e. if there are Standards with Effective Dates in July 2019, September 2019 and December 2019 and the Supplier is due to join the Framework in January 2020, then all these Standards are Day 1 Standards.
Versioning	This is defined in the Change Management Process and Roadmap Content Ancillary DocumentFurther Information section below
Roadmap	The GP IT Futures Standards and Capabilities Roadmap, known simply as 'the Roadmap', serves two primary purposes: An overarching, summary view of ALL change requests relating to new and uplifted Standards and Capabilities regardless of which change route they will progress through. This will be published for all interested stakeholders to view. NB. All Roadmap items will also be represented via the pages on Confluence with the ability to sort and order to view those relevant to you. The only method for commissioning mandated change progressing through the Managed Capacity route and therefore showing the standards with which Suppliers are obliged to maintain compliance under the terms of the Catalogue Agreement
Priority Standard	This term is used to identify those changes to Standards and Capabilities which have been identified by the NHS England SROs group as the most important and top priority items for the forthcoming period. The Priority Standards may progress through any of the defined change routes, but once in the Managed Capacity route will have an Effective Date. Wherever possible, these items and the associated Effective Dates will be issued for Supplier feedback and agreed in advance of a Framework opportunity.

Anchor
Lifecycle of Standards and Capabilities
Lifecycle of Standards and Capabilities
Lifecycle of Standards and Capabilities

All Standards and Capabilities will go through a lifecycle of Draft to Published to Effective and therefore at any given time (represented by "Day 'X'" on the diagram below) there will be a set of Draft specifications, a set of Published specifications and a set of Effective specifications. The diagram below represents this.

...

Definitions of Draft, Published, Effective and Retired are included in the table above

Anchor
Principles
Principles
Principles

This section describes a set of principles governing the assessment, management and commissioning of changes to Standards and Capabilities. The approach to managing change requests which is being adopted by GP IT Futures includes the following:

A single gated point of entry point for all change requests relating to GP IT Systems in order that Suppliers should only receive requests for system change from a single source
A fair, objective and consistent approach to assessing change requests which includes a balanced and comprehensive set of assessment criteria
A more flexible approach to elaboration, commissioning and delivery of change supported by appropriate commercial mechanisms
Splitting up larger work items into smaller deliverables to ensure that capacity is not wiped out by a single large initiative
More opportunities for innovation and collaboration
More opportunities for the wider market to reduce burden on the Foundation Solution Suppliers
Ensuring that Suppliers and wider stakeholders are engaged throughout the change process
Ensuring that change relating to key strategic priorities and objectives for the wider NHS is delivered in a timely manner
A Standards and Capabilities Roadmap which presents a single overarching view of all changes which need to be delivered and the opportunities available to Suppliers
Consultative governance forums and arrangements to ensure Suppliers are fully engaged in the process, are aware of their ongoing obligations and have the opportunity to support the shaping of wider strategy and process improvement

The approach and principles relating to the introduction and management of change differs between Standards and Capabilities and these are set out below.

Standards

...

and have the opportunity to support the shaping of wider strategy and process improvement

Standards

Draft and Published Standards may be associated with an Effective Date by which all relevant Suppliers are required to have achieved compliance.

...

NHS Digital will generally aim to agree and set the Standards which are to become Effective during the lifecycle of a Framework in advance of that Framework in order that Suppliers can plan for and absorb the required development capacity and cost within the List Price to be set at the start of any Framework. New and uplifted Standards may be added to the Roadmap in Draft or Published state at any point, but it is anticipated that due to the likely length of the Frameworks, any Effective Date set would be within a subsequent Framework and as such capacity and cost for development could be accounted for and priced as part of the processes associated with that subsequent Framework. However in the scenario where a Standard needs to be implemented at shorter notice and the Effective Date does fall within the lifecycle of the current Framework and the Supplier is not able to absorb this within the capacity available and the agreed List Price, then it should be noted that the Catalogue Agreement does not restrict the ad hoc resetting of the List Price subject to the conditions set out in the Commercial Standard and the Framework Agreement.

Capabilities

The scope of a Framework is defined by the Capabilities being requested via that Framework, therefore the Capabilities are a formal part of the Framework. Therefore any material amendment to a Capability can only be implemented in alignment with the start of a new Framework. However, this does not preclude new and uplifted Capabilities being added to the Roadmap and published at any time ahead of a subsequent Framework or the ability to initiate a new Framework request at any time. In many cases, however there are other routes, such as the Opportunity Items (as defined below), through which certain new and uplifted Capabilities could be progressed to facilitate quicker delivery prior to a Framework request. For example, if a new Capability is to be introduced, this could be added to the Roadmap and the specification Published at any point, and a Supplier may begin onboarding, however they would not be able to actually offer and sell their product until the subsequent Framework goes live.

Given that many Capabilities have linked Standards, where there is a new or uplifted Standard, an assessment will 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 be requested. This is known as the Materiality assessment and the details of this are set out below.

Anchor
Change routes
Change routes
Routes of change

There are three 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.

Managed Capacity

Managed Capacity will only be available as a route for commissioning change where the relevant Framework or other procurement vehicle has made suitable provisions for the reservation of development capacity for certain change requests. The terms of the relevant Framework Agreement may include mechanisms by which Suppliers are obliged to set aside capacity and for payment of incentives to motivate delivery. The terms may also include the request for engagement from Suppliers in agreeing the volume and feasibility of the Standards to be specified to become Effective during the lifecycle of that Framework.

...

All changes in the Managed Capacity route will appear on the Roadmap and will not be commissioned via a separate mechanism. The Roadmap will clearly display which of the four categories the item is in, the Effective Date and the availability of incentives where applicable.

Opportunity Items

Development of items in this route is outside any capacity reserved for the Managed Capacity route and additional funding is likely to be available. Changes progressing through this route will offer Suppliers the opportunity to develop and deliver certain changes early and ahead of the wider market (where applicable), to 'get ahead of the game' and increase the marketability of their products or allow for them to move into new markets and offer additional products and services through the Framework. These opportunities will be controlled via fully open or constrained competitions (such as under Lot 2 of the GP IT Futures Framework) and the parameters of each particular competition and Opportunity Item will be determined on a case by case basis. There are three types of item in this route:

...

Other opportunities. There are certain work items such as standalone features, or Capabilities required to meet a newly identified business need, which do not need to be implemented by all relevant Suppliers and could therefore be opened up to the wider Supplier market to deliver. 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

Certain change requests require an assessment involving input, analysis and feedback from Suppliers to assist in determining the feasibility, scope, sizing/complexity and nature of the request prior to it progressing through one of the other change routes. 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 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:

...

Urgent Changes may be commissioned at anytime, including within the lifecycle of a Framework, via an 'Urgent Change Statement of Works' and Suppliers will be separately and specifically funded for development and implementation of these requirements where appropriate. Timescales for the implementation of an Urgent Change will be agreed on a case by case basis according to their size and priority and Suppliers will be consulted on this to the extent possible. Urgent Changes will appear on the Roadmap and will be marked as such. Information on the terms and payments associated with Urgent Changes will be set out in the Framework Agreements and the 'Urgent Change Statement of Works'.

RFI / Analysis only

Under the terms of the Catalogue Agreement, Suppliers are required to satisfy any information requests submitted to them by the Authority within five working days of receiving the request, unless agreed otherwise. Where the Supplier feels that providing an adequate response to the query will take greater than 16 hours of effort and can demonstrate that this is the case, then the Supplier should inform the Authority by way of their response to the RFI. The same request will then be progressed via an alternative route such as the Feasibility Assessment in order to facilitate this more in depth response. These mechanisms will be used to engage Suppliers in the assessment of change requests and definition of specifications as necessary for each particular change.

Supplier Initiated Change

Supplier initiated changes are included on the diagram to reflect the fact that Suppliers have their own internal plans and roadmaps for product development and delivery which also require capacity and their own release cycles. NHS Digital will not usually be involved with these, but the outcomes from Supplier development may lead to Supplier initiated changes and product releases which NHS Digital will need to be informed about in order that Catalogue Solutions and compliance evidence can be updated if required. The details for how these will be handled are set out in the Commercial and Service Standards and schedules. There is some expectation that Suppliers will make their plans available to NHS Digital to facilitate alignment of work items between these plans and the Standards and Capabilities Roadmap.

...

Info

title	Supplier obligations

As per clause 47.4 of the Change Management and Roadmap Content ancillary document, Suppliers are obliged to share their delivery plans setting out when and how they intend to meet their Roadmap obligations with NHS DigitalDelivery Plans in relation to items on the Roadmap with the Catalogue Authority. This should include as a minimum:

detail of which items they are currently working on
target delivery and implementation dates
any risks or challenges in meeting Effective Dates set
information regarding which items they intend to develop next
information regarding which Opportunity Items they intend to bid for
some detail regarding alignment to the wider technology strategy of the Supplier and the NHS.

The earlier these plans are made available and the more detail they contain, then the development and delivery of the change should be more efficient and effective enabling the Supplier to meet Effective Dates and achieve incentives where available.

Change Management Process

Info
This section is additional to any information contained within the Change Management and Roadmap Content ancillary document. It describes the proposed processes for managing the request, assessment and commissioning of change within the Authority and the addition of that change to the Roadmap.

The GP IT Futures Change Management process has been set up as a high level overarching process flow shown and explained below, and a series of sub processes which are detailed in the expandable sections beneath. Some of these sub-processes are covered in other documents or are determined on a case by case basis. This is primarily a process internal to NHS Digital, but Suppliers will be involved at various points and it is being shared for transparency as to how change requests will be handled.

...

Rejected or Withdrawn end the change process for that submission. Adding the change to the Roadmap triggers further processes which are detailed below.

Entry Assessment

Expand

The first aspect of the Change Management Process is the Entry Assessment which considers the fundamental details of the request to assess the validity and necessity of the change to determine whether it should be progressed and added to the Roadmap. The first part of this is for the GP IT Change team to confirm that the form submitted has been adequately completed and contains sufficient information for this assessment to be undertaken. If it has not been, then it will be returned to the requestor for further detail to be provided to allow for assessment. Following this, there will be a brief meeting of relevant internal subject matter experts to consider the following aspects of the change request:

Resource. Has the requestor indicated that they have resource available to elaborate the specification if necessary and deliver the change? If yes, what is that resource? If not, what are the plans for this?
Funding. Has the requestor indicated that they have funding available to pay for the change e.g. fund an urgent change or Opportunity Item or offer delivery incentives etc.? Is there a Business Case in place?
Necessity / Drivers. What are the key reasons behind the change request and why is it needed?
Strategic alignment. How does the change request align with key strategic drivers and other ongoing work?
Standards and Capabilities alignment. An initial view of how this change request might relate to and impact the existing Capabilities and Standards or if it is something completely new.
Readiness. Is the change requestor in a position to be able to progress the change now or is there significant additional groundwork to put in place first? Does the change requestor know clearly what they are asking for?
Timescales. Are there any key delivery milestones, targets or timescales associated with the change and how does this fit with any dependencies etc.? What are the consequences of not meeting these timescales?
Delivery options. What options may be available for the most efficient delivery of this change? This may involve options outside of the GP IT Futures change routes and processes or progressing the change as an RFI to Suppliers.

Consideration of these aspects of the change should enable the assessment team to determine the validity of the change and and provide a response and recommendation regarding whether it should be progressed or not. This may be an iterative process where the requestor is asked to provide additional information to refine their request, but will lead to one of four outcomes:

Rejected
Withdrawn
Add to Roadmap as Horizon and progress to Full Assessment

The first two outcomes end the change process for that request, the other triggers further processes which are detailed below.

Full Assessment

Expand

The Full Assessment process is triggered either by a change passing the Entry Assessment or following completion of an Opportunity Item where a change now needs to be published for all relevant Suppliers to implement. The Full Assessment process determines the route by which the change will be progressed and considers the details and parameters of that change such that it is clear to Suppliers what will need to be delivered and when. Some of the elements of this Full Assessment process have sub-processes and more detailed checklists etc. which are detailed below where applicable. In the case where a change is moving from a First of Type / Alpha or Feasibility Assessment into the Full Assessment process, then a new change form is not required and a discussion will be held between the GP IT Change team and the change requestor to validate the original details given on the form and amend as necessary ahead of completing the Full Assessment.

The Full Assessment process will include analysis of the elements listed below in order to determine the most appropriate change route for this request and the parameters associated with it. This will be completed by the GP IT Change team, engaging the support of the relevant subject matter experts and Suppliers on each of the elements of this as required to ensure a consistent and fully considered assessment. This will include consultation with representatives from Business Analysis, Technical Architecture, Solutions Assurance, Service Management, Information Governance, Finance, Commercial, Buying Catalogue, Clinicians and other system users and other specialist teams as required, as well as Suppliers. Supplier engagement in this process will be managed via the RFI process, the Feasibility Assessment route or an alternate process which is as yet to be defined. It is likely to be optional for Suppliers to engage in this and only the Suppliers to whom this change is expected to apply, based on the alignment to the Standards and Capabilities model and the Solutions currently offered via the Catalogue, will be targeted in most cases.

Align to Change Management Process and Roadmap Content Ancillary DocumentFurther Information
Alignments and Dependencies (with other work)
Consider Dates and Timescales
Consider Incentives and Funding
Sizing and Complexity
Urgent Change assessment
Prioritisation
Materiality
Confirm Effective Date and incentives (if applicable)

Further information regarding the details of each of these aspects of the assessment is included below. At any point of this assessment process, it may be necessary to escalate either by convening a meeting between relevant stakeholders or by sending to a board or other governance group to make a final decision on certain elements of the change assessment. This will be particularly important for prioritisation where the NHS England SRO group will determine the key strategic priorities for the subsequent period. Once all the details are agreed, the Roadmap entry can be updated and the change will progress into one of the defined change routes.

The following table sets out some general guidelines for assessing the most suitable change route, however this is not exhaustive and change requests will need to be considered case by case:

Guideline / Criterion	If 'yes', which change route
Meets Urgent Change assessment criteria	Urgent Change
New Capability or standalone feature which does not need to be developed by a Foundation Solution Supplier	Other Opportunity
Programme not ready to progress, further information and Supplier feedback required and/or need to understand the extent to which something is possible	RFI / analysis / Feasibility Assessment
Regulatory or legislative change	Managed Capacity
National or international Standard with clear Effective Date	Managed Capacity
Work item such as a new interface or messaging spec which requires pilot testing or collaboration on development of the specification	Alpha / FoT Opportunity
Change request which has already progressed through Opportunity items route as alpha / FoT (or Other Opportunity) in some cases	Managed Capacity

The Roadmap will be published as a living document for all relevant stakeholders, but is especially important for Suppliers and Buyers. Ahead of each new iteration of the Framework, the content of the Roadmap will be consulted on with the NHS England CCIO and SRO group to determine the key strategic priorities for the next period and the associated Effective Dates. This will also be discussed with Suppliers to assess the achievability of the changes to become Effective during the lifecycle of the Framework. This may result in the need for some reassessment and the adjustment of items on the Roadmap, however Suppliers would be able to account for this in their costing and pricing analysis for the subsequent Framework. Should there be any impact on items within the current live Framework or items which a Supplier has already begun working on, then this would be discussed with the Supplier as required. Appropriate governance forums will be in place to ensure Suppliers are fully informed about amendments to the Roadmap and have the opportunity to provide feedback and challenge regarding this and any other aspect of the change process. It should also be noted that the Catalogue Agreement does not restrict the ad hoc resetting of List Price if required subject to the conditions set out in the Commercial Standard and Framework Agreement.

Align to Standards and Capabilities Model

Expand

The change request will need to be aligned to the Change Management Process and Roadmap Content Ancillary DocumentFurther Information to determine whether it is:

a new Standard or Capability
a change/uplift to an existing Standard or Capability
a replacement of an existing Standard or Capability

This assessment will also consider which of the Capabilities and Standards are impacted by the change request. This is crucial information for Suppliers as it will determine which Roadmap items they need to be most aware of based on the Capabilities which their Solution supports. This information will be set out on the Roadmap and applicable Confluence pages. An additional element of this to be considered alongside the sizing/complexity assessment is the iteration of the version number and whether the change request constitutes a major, minor or patch uplift to the impacted Standards and Capabilities. The definitions and approach to versioning and patch, minor and major changes are set out in the section below.

Alignments and Dependencies

Expand

The change request will need to be assessed against other known work items to consider any alignments and dependencies with other work which is already progressing through the change process. Dependencies may impact the change route and timescales for delivery and commissioning of the change. Alignments may mean that the change request is not required or can be merged with other work to prevent duplication of effort. These details will be provided, where known, by the change requestor in the change request form and will then be validated by the GP IT Change team and a subject matter expert review group. Where applicable, any necessary details will be highlighted via the Roadmap. It may also be necessary to consult with Suppliers via the RFI mechanism on this aspect of the assessment process.

Set Dates and Timescales

Expand

Any key timescales, deadlines and required Effective Dates associated with the change request will be considered along with the reasons for these. The validity of an Effective Date, which determines the date by which Suppliers are required to have achieved compliance with the change, will need to be verified and a objective rationale for the date will need to be provided e.g. legislative or regulatory changes, hard dependencies. This information will be made available to Suppliers where possible.

All mandatory changes in the Managed Capacity route will have an Effective Date. However there will also be items in this route which are Published but do not have an Effective Date by which Suppliers will need to have achieved compliance. Incentives for delivery of the change may be offered for items with or without an Effective Date dependent on the terms of the relevant Framework Agreement. This aspect of the Full Assessment process will be an initial consideration of these dates which will then be confirmed following the completion of the assessment process. For items which are likely to progress via Opportunity Items, then this will consider the timescales and parameters for the open competition and there would then be a reassessment and setting of a final Effective Date for all relevant Suppliers should the change then move into Managed Capacity. Timescales and delivery dates for Urgent Changes are likely to be considered and discussed outside this assessment process on a case by case basis.

An additional part of this may also include the consideration of incentives and if and when they may be applied to the change.

Suppliers will have the opportunity to provide feedback on the achievability of Effective Dates assigned to items in the Managed Capacity route ahead of the Framework in which they are due to become Effective and will be consulted via the appropriate mechanisms in any case.

Determine Incentives and Funding

Expand

Opportunity Items and Urgent Changes are likely to have additional and separate funding beyond the Software as a Service (SaaS) charge (List Price) which will need to be provided by the change requestor. The amount and source of this funding will need to be agreed as part of determining the parameters of the open competition or commissioning an Urgent Change.

Any resource and capacity required by Suppliers for development of Managed Capacity items will need to be covered under the List Price agreed at the start of a Framework, although it should be noted that the Catalogue Agreement does not restrict the ad hoc resetting of the List Price subject to the conditions set out in the Commercial Standard and the Framework Agreement if required. Managed Capacity items will only be commissioned via the Roadmap and may not be funded in any other way, particularly in the case of regulatory or legislative change. However, there will be some items in the Managed Capacity route where incentives are available to Suppliers to encourage delivery of the change. Incentivisation may be offered whether the change has an Effective Date or not. This funding may be sourced from the change requestor or from a pot set aside by GP IT Futures for changes considered to be of particularly high importance and/or which do not fall into the SRO priority or legislation and regulation categories. Whether an incentive can or will be made available will be determined by the mechanisms set out in the relevant Framework Agreement and the details of any incentive to be offered (e.g. amount available and dates/timescales when it applies) will be determined during the Full Assessment process through discussion between the GP IT Change team, the change requestor and commercial/finance representatives and this information will be displayed via the Roadmap.

Some draft guidelines for when an incentive may be attached to a particular change item have been put together.

No incentive are likely to be offered if:

Suppliers have already been funded for the change by an alternate mechanism (with the possible exception of Opportunity Items dependent on the arrangements for the Opportunity Item)
There is insufficient time between the start of the Framework and the Effective Date and/or in the case of the first Framework, the Effective Date is before the Framework must go live (e.g. January 2020)
The change has been mandated via other mechanisms e.g. ISN or legislation/regulation

Incentives may be offered if:

It is an important change with high perceived Supplier difficulty
The Effective Date is well into the future, but significant benefit to the Authority is identified
The item falls into the Managed Capacity - Other category and there is no set Effective Date, but there is significant benefit to the change and the Authority would like to encourage Suppliers to deliver the change during a certain period

Sizing and Complexity

Expand

As per the Change Management Process and Roadmap Content Ancillary DocumentFurther Information diagram, there is an intention to distinguish between big changes and small changes such that these can run in parallel and avoid the risk of large change initiatives preventing the implementation of small changes which can bring significant benefit to the NHS with minimal effort. Further to this, GP IT Futures are looking to avoid commissioning single large change items, instead aiming to chunk up work into smaller deliverables to offer greater flexibility to Suppliers in how they deliver work. Therefore an assessment of the size and complexity of the change is essential. It is recognised that Suppliers have different systems and architectures and therefore what is a small change for one Supplier, may be a big change for another. Therefore it will be necessary to seek Supplier input on this aspect of the assessment process.

The precise way in which sizing/complexity will be assessed and classified by Suppliers is still to be determined, but initially is likely to involve a higher level t-shirt sizing estimate which may then be refined further into the process and prior to publication once a specification is more defined. Suppliers will be engaged using the RFI and Feasibility Assessment routes and/or any other appropriate commercial mechanism as required to gain input on this aspect of the assessment process.

Urgent Change Assessment

Expand

The Catalogue Agreement and applicable Framework Agreement set out the broad criteria for assessing what will be classed as an Urgent Change. This ancillary document refines these and currently urgent changes are for change requests which specifically meet one of the following criteria:

National information or cyber security incidents as classified by the appropriate body e.g. National Cyber Security Centre
Inappropriate, incorrect or missing drug or patient safety guidelines/alerts and other clinical safety issues and incidents as determined by an appropriate body e.g. MHRA

If it is determined that the change request can appropriately be classified into one of these criteria and that is agreed by relevant stakeholders, then the work will progress into the Urgent Change route as set out below.

Prioritisation

Expand

The high priority strategic changes for the next period and in particular the next Framework will be identified by the NHS England CCIO with the support of the NHS England Senior Responsible Owners (SRO) group. This will set the most important changes for the subsequent time period and set the Effective Date by which Suppliers will need to have achieved compliance. The SRO priorities form one of the categories of work items within the Managed Capacity change route and this information will be given via the Roadmap. Suppliers must always be working on one or more of these items until they have completed delivery. Change requests progressing through the Opportunity Items route may also be identified as SRO priorities and this will indicate that the open competitions for these items are likely to be progressed as a priority.

The details of how and when the NHS England SRO group will be engaged to set their priorities remain under discussion and further information about this and the membership of the group will be released if applicable and appropriate. An indication of these priorities will certainly be agreed and published via the Roadmap in advance of a Framework opportunity being issued to allow for Suppliers to analyse the ask, assess the feasibility and set a suitable List Price to account for the development work required. Where Suppliers wish to challenge these items and the dates given against them, then this will be taken on board and fed back to the SRO group where the reasoning is justifiable and material.

Materiality

Expand

As described in the Change Management Process and Roadmap Content Ancillary DocumentFurther Information section, changes impacting Standards will be handled differently to those impacting Capabilities due to the way in which they are linked to the Catalogue Agreement and Frameworks. As such and given that Standards and Capabilities are linked, it is necessary to assess whether a change to a Standard has a significant impact on the scope of one or more Capabilities. This is known as the Materiality assessment. The focus of this is more around the impact of the change on the specification itself rather than the size or complexity of the work for Suppliers. To summarise:

Standards are linked directly to the Catalogue Agreement and Suppliers must maintain compliance with Standards as per the terms of that agreement. As such, Standards can be introduced independently of the Frameworks with reasonable notice of the change
Capabilities are linked directly to the Frameworks, therefore any change which alters the scope of a Capability in a significant manner can only be introduced along with a new Framework, although may be published at any point.

The majority of Standards are linked to Capabilities (and vice versa), therefore a key part of the change assessment process is to establish which Standards and Capabilities the change will impact (as set out above) and hence if there is a material impact on the scope of one or more Capabilities such that it may only be possible for the change to be introduced when the subsequent Framework opportunity is issued, or an alternate change route will need to be pursued. The main principles of the Materiality assessment are as follows:

Each change will be treated independently with respect to the Materiality assessment process i.e. if there have been previous changes impacting the same Capability within the lifecycle of the Framework, this is of no consequence
If changes are merged for some reason then this should be reassessed as a whole as a new work item

The Materiality assessment is only applicable to items in the Managed Capacity change route. It is anticipated that only a limited number of changes would be considered as material and the Opportunity Items route could be used as an alternative for delivery in some cases to progress the delivery of a Capability prior to a new Framework. This is a subjective assessment in which stakeholders will be involved as required, but the following diagram sets out some guidelines and key aspects which should be considered as part of this:

The table below summarises the content of the process set out above.

Test	Materiality Assessment likely outcome
New Capability or Feature	Material (or to Opportunity Item route)
Only impacts Overarching Standard or Interoperability Standard	Not Material
Fully covered by existing Epics and Acceptance Criteria	Not Material
One or more Epics or Acceptance Criteria to be REMOVED	Not Material
One or more Epics or Acceptance Criteria to be ADDED	Material
Change to Epics or Acceptance Criteria which required changes to Epic(s) and/or DOES impact what a Supplier has to do	Material
Change to Epics or Acceptance Criteria which only impact Acceptance Criteria and/or DOES NOT impact what a Supplier has to do	Not Material

The consequences of these outcomes are as follows:

If the change DOES NOT have a material impact on the scope of a Capability, then it can be introduced at any point irrespective of Framework lifecycles with fair warning, likely via the Managed Capacity route
If the change DOES have a material impact on the scope of a Capability, then it can only be introduced when a subsequent Framework opportunity is made available for Suppliers. Although it may be that the change could follow the Opportunity Items route ahead of this and there is no restriction on developing and issuing a Published specification such that Suppliers can begin working towards it in advance of supporting it via the next Framework if they wish to do so.

Managed Capacity

Expand

A change will enter the Managed Capacity route having been through the Full Assessment process and it may already have progressed as an Opportunity Item before the change is published for all relevant Suppliers to implement. The first consideration is to confirm whether the change is fully specified and agreed or not. This will include the requirements for Suppliers to develop against, but also all the necessary approvals, assurance documentation, plans for Business as Usual operations and any other implementation guidance or associated documentation which might be required. If this is not in place then it will be necessary to engage Suppliers and also other stakeholders in order to define and agree the change specifications and other related documentation. Suppliers will be engaged in this work via the RFI / Analysis only process, the Feasibility Assessment route or other commercial mechanisms as required. Change requestors are expected to make arrangements for any necessary resource required for any activities needed to engage stakeholders and Suppliers in order to elaborate the change specification. The role of the GP IT Change team is to facilitate and oversee the process rather than define the change or be directly involved in these activities.

Once all the necessary documentation is defined and agreed, a checklist to validate the quality and completeness of the specifications will be applied by the GP IT Change team to confirm that it is suitable for publication and Supplier implementation. Details of this checklist will be provided below once confirmed. Should the change specifications not meet the requirements of the checklist, then there would be a need for the specifications to be refined prior to be being Published. Once this checklist has been passed, the parameters of the change such as the Effective Date, prioritisation, sizing, timescales, incentives etc. will then be verified prior to publishing the specification and ensuring the Roadmap is updated with all the necessary details.

Suppliers can then select to begin development on the work when they are ready and have capacity to do so and some guidelines regarding the selection of work items are set out below. When an item is selected, this starts an iterative cycle of development and assurance as per the mechanisms and terms set out in the change specification and the GP IT Futures compliance and assurance approach documentation until the work is complete and a Development Milestone Achievement Certificate (DevMAC) is awarded. This process will be overseen by the Supplier Account manager.

Once the DevMAC has been awarded, it is necessary to consider the award of any compliance or incentive payments which may be available for that work item as per the terms of the relevant Framework Agreement. If there is an Effective Date associated with the change and this has not been met, the the Remediation Process as set out in the relevant sections of the Framework and Catalogue Agreements will be initiated. If the Effective Date has been met then the Supplier will be eligible for the award of the monthly compliance payment assuming they have met all other relevant obligations. Some items in the Managed Capacity route, whether they have an Effective Date or not, may be incentivised for delivery. If any incentive which was available has not been achieved or there was no incentive available, then this completes delivery of the change. If there is an incentive associated with the change and this has been achieved, then the amount to be paid will be calculated and awarded to the Supplier as per the Charging and Invoicing schedule and this would then complete the change.

If there is any disagreement regarding whether the Effective Date or the parameters of any available incentives have been met, then the Dispute Resolution Procedure will be followed.

Specification Checklist

Expand

This is the checklist to ensure that the specifications for a change are adequately defined, implementable and in a suitable format, as well as being supported by the relevant accompanying documentation, such as assurance processes/approach, implementation guidance and plans for business as usual operations, ahead of it being given a status of Published. This is to ensure that Suppliers can select the item with full information available to them and that any delays to address clarifications with the specification or to agree and set up assurance processes is minimised.

The detail of this checklist is still in elaboration and will be added in here in due course. However given that draft specifications will have been made available for Suppliers ahead of this point and some items will have progressed through the Opportunity Items route ahead of being published via Managed Capacity plus the fact that the GP IT Change team will have been monitoring the progress and development of the change, it is anticipated that this should be a fairly light touch process.

Supplier selects work item

Expand

These are the guidelines which govern which items a Supplier can select from the items listed under Managed Capacity on the Roadmap. The key principles here include the following:

Suppliers must ensure they are meeting their obligations with respect to the Catalogue Agreement and any Effective Dates set and must ensure they have capacity and resource available to do so
Suppliers must prioritise work on those items categorised as 'SRO priority'
Suppliers must share their delivery plans detailing how and when they will meet their Roadmap obligations with NHS Digital
Suppliers can choose to target incentives for early delivery and Opportunity Items should they wish to do so, on the basis that it will not compromise their ability to meet Effective Dates and remain compliant with the Catalogue Agreement. Account managers should be informed of any intention to target these items
Big and small items should be worked on in parallel and items can be selected individually or in groups based on Supplier development plans, capacity and methodologies
Suppliers must inform their account manager at the earliest opportunity when they are selecting a new work item, changing what they are working on and/or where delivery timelines and the ability to meet Effective Dates is at risk.

These guidelines are not yet confirmed and will be elaborated and uplifted in due course if required.

Opportunity Item

Expand

The Opportunity Item process is triggered by the identification of a change request as an Opportunity Item, either as a First of Type / Alpha phase, a wider market opportunity or as a Feasibility Assessment. There are some common elements to this process before it splits based on which type of opportunity it is. Suppliers should only bid for work in the Opportunity Items route where they can make resource and capacity available without compromising the delivery of the key strategic work items and mandated changes specified under Managed Capacity. Any capacity for Opportunity Items will not be included in that reserved for Managed Capacity or within the List Price.

Once a change request is identified as an Opportunity Item, it is first necessary to establish the parameters of the Opportunity Item and the open competition which will be issued to engage Suppliers and commission the work. These will be agreed on a case by case basis and will include consideration of:

Number of Suppliers to be engaged
Which Suppliers the competition should be issued to
Scope of the opportunity
Desired outcomes
Amount and source of funding available
Timescales for completion of the opportunity and running the open competition
Criteria for submitting and assessing bids
Anticipated change journey following completion of the Opportunity Item

Once these details have been established between the change requestor, the GP IT Change team and Commercial team, the open competition can be issued to the market and eligible Suppliers can submit a bid as per the terms set. These bids will then be reviewed and assessed under the terms of the competition issued and offers will be made. Following acceptance of the offers, final terms of the Opportunity Item will be agreed. This will be a process which is primarily led by the Commercial team with input from the change requestor and the GP IT Change team. Some of these open competitions may be run against Lot 2 of the GP IT Futures Framework, but other suitable mechanisms may also be used depending on the scope of the opportunity and the Suppliers to be targeted. Further details of this will be set out in the relevant Framework Agreement, but the precise details of each competition and opportunity will be agreed on a case by case basis. Opportunity Items will also appear on the Standards and Capabilities Roadmap highlighting the issue date of the open competition where known.

Those items which are First of Type / Alpha projects will then progress into an iterative cycle of collaborative requirements elicitation, development, assurance, pilot deployment and gathering feedback in a manner agreed between the parties involved until a final specification is agreed and First of Type deployment can be completed. Any resource required for this will need to be arranged by the change requestor. The GP IT Change team is only responsible for facilitating, overseeing and monitoring the process. Once First of Type deployment has been successfully completed, this will trigger the award of any payment available as per the terms of the opportunity. The specification will then go back through the Full Assessment process to set the parameters of the work before it moves into the Managed Capacity route and is Published for all relevant Suppliers.

Those items which are Other Opportunities for the wider market will then progress to development and assurance as per the terms agreed with the selected Suppliers. The development aspect of this would be expected to be fairly minimal in this case as the intention is to commission Suppliers with products which already support a significant proportion of the desired functionality rather than requiring bespoke development. Once this has been completed, the product will need to be signed off by the relevant parties as per the agreed assurance approach and a DevMAC can be awarded. In some cases, these products may then need to be integrated with the Foundation Solutions. Where this is not the case, the new product will be added to the Catalogue and deployed to users as required. Where integration is required, this is likely to require work from the Foundation Solution Suppliers and therefore this work will go back into the Full Assessment process and move in to Managed Capacity to be Published for all relevant Suppliers to implement once the parameters have been agreed.

Those items which require a Feasibility Assessment prior to definition and delivery of the change will also progress through this route. These are items which may already have been through an RFI / Analysis only process to gather information from Suppliers, as per the terms of the Catalogue Agreement, but have been determined to be beyond the scope of that route and require additional effort from Suppliers. Therefore they will be subject to an open competition or other suitable mechanism which may be accelerated and simplified to appoint Suppliers to undertake the feasibility analysis and provide feedback to determine how best to progress the change request. Once this assessment has been completed and returned to NHS Digital, the responses will be analysed and the change requestor will decide whether they wish to progress with the change request in which case it will move back into the Full Assessment process, or if they will withdraw and reconsider the request.

Open Competition

Expand

This is the process for determining the scope and parameters of an open competition, the procedure for issuing the open competition to the market, how bids are submitted and the assessment criteria and process to award the opportunities to Suppliers. The details regarding how these competitions will be run will be determined on a case by case basis and led by the Commercial team, but further information will be set out in the Framework Agreement. These open competitions may be run against Lot 2 of the GP IT Futures Framework or via an alternative commercial mechanism.

Urgent Change

Expand

When an Urgent Change is identified as per the criteria outlined above, the Urgent Change process will begin. These changes need to be defined and implemented quickly so engagement with stakeholders and Suppliers will be minimal, but will still be undertaken as far as possible.

An Urgent Change Statement of Works which outlines the high level ask will be issued to the applicable Suppliers (i.e. those Suppliers who support the Capabilities which are impacted by the change) to engage them in the process doe definition and delivery of the change. The required delivery timescales will then be agreed and the specification will be elaborated. Once this is confirmed the Statement of Works will be updated with these timescales and the conformed parameters of the change to formally commission the work.

More specific details regarding the issue, format, assessment and approval of the Urgent Change Statement of Works are covered in the Catalogue Agreement and related ancillary documents. Once Supplier responses to the statement of Works are approved Suppliers can begin development and assurance activities as per the agreed specification and the GP IT Futures assurance approach, although in many cases it is anticipated that Suppliers may start the work in advance of this. When compliance is achieved and approved, the change will need to be deployed and payment (if available) can be awarded and the change will be complete.

The specification will be worked into the Standards and Capabilities model to ensure that any Supplier who may wish to onboard a product against that particular Capability on a future Framework supports this Urgent Change work item.

Anchor
Versioning
Versioning
Standards and Capabilities Versioning

As per Change Management Process and Roadmap Content Ancillary DocumentFurther Information of this document, all Capabilities and Standards will have a version number. These version numbers will be in the format "a.b.c", where:

...

Version numbers for all Standards and Capabilities will be set to v1.0.0 for the first GP IT Futures Framework once the specifications are locked down for procurement and onboarding
When a major version number is updated, the equivalent minor and patch version numbers will be reset to zero (e.g. 2.1.2 becomes 3.0.0)
Version numbers for Capabilities and Standards are independent of any Framework and will therefore carry over if no updates are to be made between Frameworks
Capabilities and Standards (including Capability Specific Standards) will have separate version numbers which will be iterated independently i.e. if the Prescribing Standard moves from v1.0.0 to v1.1.0, this does not always mean that the version number of the Prescribing Capability will also change.
Any time a change is introduced which impacts an existing Capability and/or Standard, the version number will be iterated.
This covers both changes which are progressing through the Change Process for the first time and also those where it has been identified that a specification needs to be uplifted after it has been Published but before the Effective Date.
The iteration of version numbers only applies to changes which impact an existing specification. Specifications for new Capabilities and Standards will always be major changes and will always be set at version 1.0.0 when initially Published.

Definitions

The definitions of major, minor and patch and how it would be determined as to whether a particular change requires a major, minor or patch change to the version number are detailed below. This is more about the scale of the impact on the specification rather than the size or complexity of the work involved for Suppliers. It should be noted that there is not necessarily a 'one size fits all' definition of these terms as what applies to an API for example would likely be very different to what applies to the Epics and Acceptance Criteria which make up a Capability. Therefore these definitions have been deliberately left fairly broad and given two elements in order to reflect this and they would be assessed accordingly as part of the change process. In the case of changes to APIs, these have been based around https://semver.org/.

...

Patch: Change does not have a material impact on Capability or Standard and minimal or no update to Supplier Solutions is required such as the introduction of additional guidance or clarifications, correction of grammatical errors or typos, restructure or reformatting of requirements AND/OR a version when smaller non-breaking changes or backwards compatible bug fixes are made.

How will version uplifts be handled through the Change process?

All changes entering the Change Management Process will be assessed to determine whether they are a patch, minor or major uplift to a specification and the parameters of the change and Effective Dates will be set accordingly as per the processes set out above.

...

Where for some reason the scope of the regular Roadmap entries does not cover the uplift to the specification in question, perhaps for an unanticipated change to a line item in a Capability Specific Standard, then regardless of the perceived scale of the change this would be taken through the Full Assessment process, likely in a more light-touch manner, to reconsider the parameters associated with delivery of the change.

Anchor
Section 3
Section 3
Section 3: GP IT Futures Standards Roadmap

The GP IT Futures Standards and Capabilities Roadmap ('the Roadmap') will provide a single, summary view of all the changes and opportunities for Suppliers regarding new and uplifted Standards and Capabilities, whichever route they are to be progressed through. This includes 'Horizon' items which GP IT Futures are aware of and are expecting to be progressed via the defined change routes at some point further into the future, but which have not yet been formally requested and may not materialise. The Roadmap will be the only mechanism by which changes in the Managed Capacity route will be commissioned. Changes following other routes will be commissioned via separate mechanisms as described above, but will still be displayed on the Roadmap for information purposes and to bring as much information as possible into one place. Further detail regarding the changes specified on the Roadmap, such as the parameters of open competitions, draft and final specifications and the change backlogs will be made available elsewhere, such as on Confluence.

...

However, additional Standards can also be added to the Roadmap at any time throughout the lifecycle of the Framework. If the agreed Effective Date falls within the lifecycle of that Framework there are commercial mechanisms available under the terms of the Catalogue and Framework Agreements for the Supplier to adjust their List Price if required. If the Effective Date falls within the lifecycle of a subsequent Framework, then the capacity required for delivery of that Standard should be accounted for within the List Price set for that Framework. Changes progressing through any of the other change routes may also be added to the Roadmap at any point.

What information will be shown on the Roadmap?

The overarching Roadmap will include a summary of information to ensure Suppliers are fully aware of the changes that are required and the opportunities which are available to them. Some of the data items are common to all change routes, and other data items are specific to a particular change route. The table below sets out the information to be included. Horizon items are not included in this table as they will not have been assigned to a change route and there is likely to be limited information available about the change. Dependent on the final form presentation of the Roadmap, certain information, sch as the change route, may not be given in distinct fields and may instead be represented in an alternate format, such as in labelled swim lanes or with colour coding or sections.

...

In addition to the overarching Roadmap, each Capability and Standard on Confluence contains a Roadmap section linking to a page which details any Roadmap items related to that Capability or Standard and the details of that change. There is also a central Roadmap page on Confluence where a full list of Roadmap items will be available with a summary of information similar to the above.

Roadmap Content

The actual content and change items to be Effective for Day 1 and to be included on the Roadmap in the defined change routes is presented in tabular format on the Standards and Capabilities Roadmap page.

...

Version	Old Version 12	New Version 13
Changes made by	Thomas Hall	Thomas Hall
Saved on	28-03-2019	04-04-2019

Page Comparison

Versions Compared

Key

Capabilities

Structure of a Capability

Capability ID

Capability version

Capability description

Outcomes

Epics and acceptance criteria

Standards and Capabilities Model

Capabilities

Structure of a Capability

Capability ID

Capability version

Capability description

Outcomes

Epics and acceptance criteria

Use of Capabilities

Foundation Capabilities

Standards

Classes of Standards

Classes of Standards

Structure of a Standard

Standard ID

Standard Version

Standard Type

Effective Date

Status

Requirement ID

Requirement Level

Use of Standards

Publication of Capabilities and Standards

Standard Type

Effective Date

Status

Requirement ID

Requirement Level

Use of Standards

AnchorCapabilities and Standards ModelCapabilities and Standards ModelCapabilities and Standards Model

Publication of Capabilities and Standards

Change Management

AnchorDefinitionsDefinitionsDefinitions

AnchorLifecycle of Standards and CapabilitiesLifecycle of Standards and CapabilitiesLifecycle of Standards and Capabilities

AnchorPrinciplesPrinciplesPrinciples

Standards

Standards

Capabilities

AnchorChange routesChange routesRoutes of change

Managed Capacity

Opportunity Items

Feasibility Assessment

Urgent Change

RFI / Analysis only

Supplier Initiated Change

Change Management Process

Entry Assessment

Full Assessment

Align to Standards and Capabilities Model

Alignments and Dependencies

Set Dates and Timescales

Determine Incentives and Funding

Sizing and Complexity

Urgent Change Assessment

Prioritisation

Materiality

Managed Capacity

Specification Checklist

Supplier selects work item

Opportunity Item

Open Competition

Urgent Change

AnchorVersioningVersioningStandards and Capabilities Versioning

Definitions

How will version uplifts be handled through the Change process?

AnchorSection 3Section 3Section 3: GP IT Futures Standards Roadmap

What information will be shown on the Roadmap?

Roadmap Content

Anchor
Capabilities and Standards Model
Capabilities and Standards Model
Capabilities and Standards Model

Anchor
Definitions
Definitions
Definitions

Anchor
Lifecycle of Standards and Capabilities
Lifecycle of Standards and Capabilities
Lifecycle of Standards and Capabilities

Anchor
Principles
Principles
Principles

Anchor
Change routes
Change routes
Routes of change

Anchor
Versioning
Versioning
Standards and Capabilities Versioning

Anchor
Section 3
Section 3
Section 3: GP IT Futures Standards Roadmap