Introduction

This document is an Ancillary Document to support the Catalogue Agreement and should be read in conjunction with the relevant parts of that 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 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:

• NHS Digital to express the business needs during the procurement
• NHS Digital for the initial assessment of Solutions for on-boarding to the Buying Catalogue
• Suppliers to categorise their products and to see market opportunities
• Buyers to search for products that meet their needs on the Buying Catalogue

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

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:

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

With regards to the terminology, it is acknowledged that there are formal publishing Standards bodies like ISO, PRSB and NHS Digital. Where possible we will always refer out to existing national and international Standards, but as a Programme will be using the word Standard(s) to refer more broadly to a collection of requirements that ensure a level of safety, security, quality and interoperability that Suppliers will be mandated to comply with in order to maintain compliance with the Catalogue Agreement.  

For new Capabilities we will explore if there is a need for any Standards and if so, these will be developed concentrating predominantly on security, safety and interoperability. 

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:  

• National Standards e.g. ISNs which apply to the whole NHS
• Interoperability Standards (including national programmes)
• Capability specific Standards and Context specific Standards
• Capabilities

Definitions

...

...

...

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. 

...

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.

...

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

...

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.

...

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.

...

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 Document 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.

...

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.

...

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.

...

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.

...

See entry for 'Level' in the Master Glossary.

...

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.

...

This is defined in the Change Management Process and Roadmap Content Ancillary Document section below

...

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

...

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.

Image Removed

If and when a Standard or Capability is replaced or superseded, it will be given a status of 'Retired' and moved to a new area of Confluence such that it is clear that it is no longer current.

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

...

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

Achieving and maintaining compliance with Standards is an obligation of the Catalogue Agreement and is only a condition of the commercial arrangements specified within a Framework or other commercial vehicle. Consequently there is no direct relationship between the Framework Agreements and the addition of Standards to the Roadmap, the setting of Effective Dates and any other part of the Standards development lifecycle.

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

Where a Standard is Published but does not have an Effective Date, Suppliers can choose to implement this as a way to differentiate their product and gain market advantage in advance of any Effective Date which may subsequently be set. These items are included on the Roadmap as they would bring benefits to end users and the wider NHS if implemented, but do not currently fall within the key strategic priorities. Any given Framework Authority or Agreement may however choose to incentivise 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. 

...

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

Image Removed

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. 

Work progressing through this route is published for all relevant Suppliers to implement i.e. the Standard may or may not apply dependent on the Capabilities which a Supplier has selected to support. Where Suppliers are expected to reserve development capacity, it is likely that they will be required to maintain separate delivery channels for big and small changes, such that these can be delivered concurrently. This is to ensure that small, every day changes which can deliver significant benefit with minimal effort are not continually pushed out by large change items which take up a large proportion of available development capacity. The cost of this reserved capacity will need to be incorporated within the agreed List Price for the Framework. Whilst the availability and quantity of this capacity will not be assured Suppliers are expected to make available sufficient capacity to deliver all the work specified via the Standards and Capabilities Roadmap which falls within the lifecycle of the applicable Framework. Capacity issues shall not relieve a Supplier of their obligations to achieve compliance with the relevant Standards by the set Effective Dates. In the scenario where a Standard is both added to the Roadmap and has an Effective Date within the lifecycle of the Framework and the Supplier is not able to absorb this within the capacity available and the List Price agreed at the outset of the Framework, 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.

It is anticipated that changes progressing through this route will be split into big changes and small changes to allow these to run in parallel as described above. When items in the Managed Capacity route are given an Effective Date, they become mandatory and all relevant Suppliers must have achieved compliance by that date. In addition to the distinction between big and small items, there will be four categories within Managed Capacity:

...

Effective Dates, where set, will be objectively justified for the purpose of transparency and will determine the date by which all relevant Suppliers are required to have achieved compliance. The Effective Date will be set in conjunction with Suppliers as far as is reasonably practicable, however for some changes, especially those related to regulatory or legislative change, this may not be possible. Where a Supplier considers that it is unreasonable for them to achieve a given Effective Date, they must notify NHS Digital as soon as is reasonably practicable. Suppliers will have the right to raise disputes in relation to any Effective Date which they consider to be unattainable with regard to the scope or complexity of the work item but valid reasoning will need to be provided.

Suppliers will be able to determine the highest priority items based on the categories described above, but must also consider the Effective Date as well as any incentive payments offered for delivery of the change under the terms of the Framework Agreement. Where no incentive payment is being offered, all capacity and costs for development are expected to have been incorporated within the List Price set at the start of the Framework. The lack of availability of capacity does not relieve a Supplier of their obligations to remain compliant with Standards by the given Effective Dates.

Suppliers will generally be able to select and develop items in the Managed Capacity route in a manner to suit their development plans and approach, but must ensure that they deliver all the key strategic priorities identified by the NHS England SRO group and achieve compliance by the set Effective Dates.  Suppliers are expected to work with their Account Manager to share and agree delivery plans and development milestones such that progress can be tracked.

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:

Alpha, Definition and First of Type. Opportunities for Suppliers to bid via fully open or constrained competitions to collaborate and co-produce specifications and to develop these up to the First of Type stage before the specification is published for all other relevant Suppliers to implement through the Managed Capacity route. These opportunities allow a Supplier to assist in defining the specification and to undertake the pilot development of a change as an early adopter.  Although there would be an open competition for any eligible Supplier to bid for these opportunities, it is likely that in most cases only one or two Suppliers would be awarded this for each change that comes through this route. Additional funding is expected be available for these opportunities. NB. It is recognised that Suppliers have different architectures and therefore in defining a specification with a limited set of Suppliers, there may be bias towards a particular Supplier. The intention of GP IT Futures is to move to more open and standardised architectures so any Supplier specific elements will be avoided as far as is reasonably possible for that particular work item.   

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:

• 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

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.

Change Management Process 

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.

Image Removed

The change process is triggered by the submission of a change request to the GP IT Change team, including changes coming out of the Tech Strategy and the ongoing internal review of Standards and Capabilities.  The change request process will be open for submissions at any time and changes will be submitted via a standardised form template giving the key information required regarding the change.

The change assessment process will analyse the details and background of the request to determine the most efficient and effective route for it to be progressed. It is made up of two key aspects:

• Entry Assessment. An internal assessment of the fundamental details and reasons behind the change request and consideration of the validity and necessity of the change to determine whether it should be progressed and added to the Roadmap. The intention of this stage is to filter out any requests which are not deemed to be necessary, are already in train with other work requests or which are not in a sufficient state of readiness to be progressed, such that Suppliers and other key stakeholders are not engaged in the work unnecessarily.
• Full Assessment. Analysis of the finer detail of the change request to consider the most appropriate change route and set the parameters for delivery and how the change will be commissioned.

Further definition of these stages is included in the processes below.  There are three main outcomes following these initial assessments, although they may need to be repeated to refine the details of the request prior to a final decision being made:

• Rejected. Determined by the assessment team that the change should not be progressed. This may mean it is covered by or merged with other work, the request is not ready to be progressed or that it is in some way not suitable for the GP IT Futures change process i.e. it is not relevant to GP IT Suppliers or may be better progressed via an alternate mechanism
• Withdrawn. Change requestor opts to withdraw the change following assessment and feedback
• Added to the Roadmap and assigned to a change route
  • RFI / Analysis only (may be progressed under terms of the Catalogue Agreement)
  • Urgent Change
  • Opportunity Item
  • Managed Capacity

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

Full Assessment

...

Image Removed

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 Document
• 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:

...

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

...

As described in the Change Management Process and Roadmap Content Ancillary Document 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:  

Image Removed

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

...

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

...

Image Removed

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

Supplier selects work item

Opportunity Item

...

Image Removed

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

Urgent Change

...

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

• a = major version
• b = minor version
• c = patch version

Some key principles regarding these version numbers are set out below:

• 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/.

Major: Change has a material impact on Capability or Standard and Suppliers will need to update their Solutions to remain compliant AND/OR a version when breaking or incompatible (i.e. not backwards compatible) changes are made.

Minor: Change does not have a material impact on Capability or Standard, but indicates a Supplier may need or wish to update their Solution AND/OR a version when larger non-breaking changes or a significant number of smaller non-breaking (i.e. backwards compatible) changes are made; or an unsubstantive breaking change is made.

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.

There may be scenarios where a specification which has been Published in the Managed Capacity route and given an Effective Date needs to be amended for some reason and changes what a Supplier is required to deliver, or may already have delivered. It is hoped that this will not be a common scenario, although it is more likely to apply to some things (e.g. APIs and messaging specifications) than others.  The following mechanisms and principles will be used to manage this:

Major changes: Any revisions which are assessed as major changes will be reassessed through the Change Management Process and the Effective Dates and other parameters associated with the change adjusted accordingly to account for the work required from Suppliers. The Roadmap would be updated as necessary to reflect this change.

Minor or patch changes: There will be items on the Roadmap in the Managed Capacity route with Effective Dates every three months to cover minor and patch uplifts to a range of existing specifications which are either Effective or Published. Suppliers will be expected to allow capacity for this within their List Price. For example, each entry on the Roadmap could cover possible uplifts to GP Connect interfaces, IM1, GP2GP or other APIs or messaging specifications etc. but there would not be an uplift to all of these within each and every entry on the Roadmap. These are intended to be small changes, therefore the scope of what is included within these will be carefully managed and monitored. Some guidelines around the number of patch and/or minor changes which could be included within each particular entry are being developed to ensure some consistency in the volume of work such that Suppliers can plan and price accordingly and to inform what is and is not included if several change requestors want patch or minor uplifts at the same time.  If it did happen that there were no uplifts within a particular regular entry, Suppliers would then be able to use that "spare" capacity to target incentive payments or pick up items in the Managed Capacity - Other route for example.

Taking this approach sets a regular rhythm for Suppliers in keeping up to date with the latest versions of specifications and allowing them to plan for this, but also for Programmes in managing their specifications and knowing when they can release patch or minor uplifts and when they can expect that they will be developed. Whilst there is no set or specified amount of time ahead of the Effective Date that the patch or minor uplift to the specification needs to be Published, it is expected that this would be a minimum of 3 months and likely longer than this for minor changes. 

This approach may be used for the scenario where a specification needs to be uplifted between the Published and Effective Dates or where the uplifted specification is being Published for the first time following the Full Assessment process and progressing into Managed Capacity. 

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.

...

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.

Wherever possible, Standards with an Effective Date within the lifecycle of a Framework will be added to the Roadmap in advance of the commencement of that Framework to ensure Suppliers:

• have sufficient notice to be able to plan and complete development activities and achieve compliance
• can calculate the amount of capacity they will need to reserve and set a List Price for that Framework accordingly

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

Introduction

This document 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 the Catalogue Agreement.

The ancillary document describes:

• the Capabilities and Standards 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. 

Change Management

Definitions

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.

Image Added

If and when a Standard or Capability is replaced or superseded, it will be given a status of 'Retired' and moved to a new area of Confluence such that it is clear that it is no longer current.

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

Principles

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

• A single gated point of entry point for all change requests relating to Digital Care Services Solutions 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 Suppliers with a greater market share
• 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

Standards

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

Where a Standard is Published but does not have an Effective Date, Suppliers can choose to implement this as a way to differentiate their product and gain market advantage in advance of any Effective Date which may subsequently be set. These items are included on the Roadmap as they would bring benefits to end users and the wider NHS if implemented, but do not currently fall within the key strategic priorities. Any given Framework Authority or Agreement may however choose to incentivise compliance.

NHS Digital will generally aim to agree and set the Standards which are to become Effective during the life-cycle of a Framework in advance of that Framework in order that Suppliers can plan and account for any required development capacity and cost within the List Price to be set at the start of any Framework.

New and uplifted Standards to be progressed through the Urgent Change or Opportunity Items route may be added to the Roadmap at any time. There are however restrictions regarding the addition of new Roadmap entries in the Managed Capacity route where an Effective Date is set. Refer to the Change Management and Roadmap Content ancillary document for this information.

Capabilities 

New and uplifted Capabilities may be added to the Roadmap at any time as Draft or Published such that Suppliers could develop against it and begin onboarding. However where this is a material change to an existing Capability or the addition of a new Capability, then this cannot become Effective until a subsequent Framework opportunity.  Although in some cases it is likely that the change could be progressed as an Opportunity Item to facilitate quicker delivery prior to a Framework request.

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

Routes of change

There are three 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 RFIs as per the terms of the Catalogue Agreement, may participate in Feasibility Assessments which will be commissioned via the most appropriate Framework or procurement vehicle and may also initiate change themselves based on internal development and delivery plans. 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 given an Effective Date for development and implementation by all relevant Suppliers via the Managed Capacity route. A Feasibility Assessment may be used to engage Suppliers as part of elaborating a specification and/or to understand the parameters of a change prior to it progressing into one of the other change routes.

Image Added

Managed Capacity

Changes progressing through this route are published for all relevant Suppliers to deliver i.e. the new or uplifted Standard may or may not apply dependent on the Capabilities which a Supplier has selected to support. Suppliers are expected to incorporate the cost of the capacity required to deliver items in the Managed Capacity route which have an Effective Date within the life-cycle of the Framework as part of their List Price set for that Framework. Suppliers must ensure that they make available sufficient capacity to deliver all the work specified via the Standards and Capabilities Roadmap which falls within the life-cycle of the applicable Framework. Capacity issues shall not relieve a Supplier of their obligations to achieve compliance with the relevant Standards by the set Effective Dates. 

It is anticipated that the majority of changes in the Managed Capacity route which have an Effective Date within the life-cycle of the subsequent Framework will be discussed and agreed with Suppliers ahead of that Framework in order that Suppliers can set their List Price accordingly. However the Catalogue Authority reserves the right to add items to the Roadmap within the life-cycle of a Framework which will also become Effective during that Framework. Given that the Frameworks are expected to be relatively short, this is not expected to be a common scenario as any given Effective Date is likely to fall within a subsequent Framework, thus allowing a Supplier to re-set their List Price, however any such occurrence will be handled as per the terms set out in the Change Management and Roadmap Content ancillary document. It should also 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.

 There will be four categories of change item within Managed Capacity:

• The key strategic (SRO Priority) changes, as agreed by the NHS England CCIO with the support of the Senior Responsible Owners (SRO) group which will need to be implemented by a set Effective Date within the life-cycle of the Framework. This is the group who are accountable for the prioritisation and delivery of the key Department of Health and Social Care and NHS England strategies and objectives (e.g. Secretary of State Technology Vision). These items will generally be agreed with Suppliers ahead of any Framework opportunity and should be accounted for in the List Price set for the Framework. 
• Regulatory and legislative change which must be delivered by a set Effective Date. These items should be accounted for in the List Price set for the Framework.
• Minor and Patch uplifts to previously Published or Effective specifications which will be regular items on the Roadmap to account for small tweaks to existing specifications with Effective Dates every three months. These could include minor or patch uplifts to a range of Standards or Capabilities but the volume of change in each entry will be carefully monitored. It is anticipated that these uplifted specifications would be published a minimum of three months in advance of each Effective Date. As per the Change Management and Roadmap Content ancillary document, these items should be accounted for in the List Price set for the Framework.
• A list of other changes which deliver benefits to the NHS and which NHS Digital would like to be delivered. These items will have Published specifications and may or may not have Effective Dates. These items should not be accounted for in the List Price set for the Framework, however they may be associated with incentive payments for delivery of the change item within a particular bounded time period.
  
  • For example - the introduction of a new version of the Electronic Prescribing Service (EPS). Plans could be issued by the NHS Digital spine team to retire old versions across the market in four years. The new specification which introduces a change to the existing EPS Standard could be Published alongside the Effective specification. Suppliers are then able to implement either the new Published version or the existing Effective one and both would be deemed as compliant.  However, closer to the retirement date of the existing Effective specification (perhaps two and a half years in), an Effective Date by which Suppliers will need to have achieved compliance may then be set for the new Standard. Therefore until that point there will be a Published Standard which is not Effective. 
    
    

When items in the Managed Capacity route are given an Effective Date, they become mandatory. Effective Dates will be objectively justified for the purpose of transparency and will determine the date by which all relevant Suppliers are required to have achieved compliance. The Effective Date will be set in conjunction with Suppliers as far as is reasonably practicable, however for some changes, especially those related to regulatory or legislative change, this may not be possible. Where a Supplier considers that it is unreasonable for them to achieve a given Effective Date, they must notify the Catalogue Authority as soon as is reasonably practicable. Suppliers will have the right to raise disputes in relation to any Effective Date which they consider to be unattainable with regard to the scope or complexity of the work item but valid reasoning will need to be provided.

Suppliers will generally be able to select and develop items in the Managed Capacity route in a manner to suit their development plans and approach, but must ensure that they deliver all the key strategic priorities identified by the NHS England SRO group and achieve compliance by the set Effective Dates.  As per the Change Management and Roadmap Content ancillary document, Suppliers are expected to work with the Catalogue Authority to share and agree delivery plans and development milestones to ensure that obligations can be met.

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

Supplier capacity for participation in items in this route is in addition to any capacity or pricing assigned to changes in the Managed Capacity route. Additional funding may be made available for Opportunity Items. 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 commissioned via the most appropriate Framework or procurement vehicle in current operation at the time and the parameters of each particular Opportunity Item, such as outcomes/outputs, timescales, any associated funding and which Suppliers will be eligible, will be determined on a case by case basis. There are two types of item in this route:

Alpha, Definition and First of Type (see the Change Management and Roadmap Content ancillary document). Opportunities for Suppliers to collaborate and co-produce specifications and to develop these up to the First of Type stage and to refine the specification before it is Published for all other relevant Suppliers to implement through the Managed Capacity route.    

Other opportunities (see the Change Management and Roadmap Content ancillary document). Opportunities for the wider Supplier market to deliver changes such as new Capabilities or standalone features which do not necessarily have to be implemented by Foundation Solution Suppliers or Suppliers supporting a particular Capability. These opportunities may allow a Supplier to set their product apart from others and potentially enter new markets and gain market share or offer a product via the Framework which they may have not been able to previously. These are changes which may be more efficiently and effectively delivered by Suppliers who already have existing products to meet the desired business needs rather than commissioning bespoke development from existing Suppliers.

Feasibility Assessment

(See the Change Management and Roadmap Content ancillary document). The Feasibility Assessment process will be controlled in the same manner as the Opportunity Items.  It is to cover change requests requiring an assessment involving input, analysis and feedback from Suppliers to assist in determining the feasibility, scope, sizing/complexity and nature of the change request prior to it progressing through one of the other change routes and also to assist in defining specifications. This is for work which does not require any development, but goes beyond the scope and time required for an RFI as set out in the Catalogue Agreement. Following completion of the Feasibility Assessment, the change may either be withdrawn or progressed via one of the other change routes.

Urgent Change

Please refer to the Change Management and Roadmap Content ancillary document for information regarding Urgent Change. 

RFI / Analysis only

Please refer to the Catalogue Agreement 

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. These will be handled as per the relevant Service Management and Commercial Standards and Schedules. 

Change Management Process 

The Digital Care Services 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.

Image Added

The change process is triggered by the submission of a change request to the Digital Care Services Change team, including changes coming out of the Tech Strategy and the ongoing internal review of Standards and Capabilities.  The change request process will be open for submissions at any time and changes will be submitted via a standardised form template giving the key information required regarding the change.

The change assessment process will analyse the details and background of the request to determine the most efficient and effective route for it to be progressed. It is made up of two key aspects:

• Entry Assessment. An internal assessment of the fundamental details and reasons behind the change request and consideration of the validity and necessity of the change to determine whether it should be progressed and added to the Roadmap. The intention of this stage is to filter out any requests which are not deemed to be necessary, are already in train with other work requests or which are not in a sufficient state of readiness to be progressed, such that Suppliers and other key stakeholders are not engaged in the work unnecessarily.
• Full Assessment. Analysis of the finer detail of the change request to consider the most appropriate change route and set the parameters for delivery and how the change will be commissioned.

Further definition of these stages is included in the processes below.  There are three main outcomes following these initial assessments, although they may need to be repeated to refine the details of the request prior to a final decision being made:

• Rejected. Determined by the assessment team that the change should not be progressed. This may mean it is covered by or merged with other work, the request is not ready to be progressed or that it is in some way not suitable for the Digital Care Services change process i.e. it is not relevant to the current scope of Digital Care Services or may be better progressed via an alternate mechanism
• Withdrawn. Change requestor opts to withdraw the change following assessment and feedback
• Added to the Roadmap and assigned to a change route
  • RFI and/or Feasibility Assessment
  • Urgent Change
  • Opportunity Item
  • Managed Capacity

Rejected or Withdrawn end the change process for that submission, although it is expected that some of these changes may be resubmitted into the process down the line. Adding the change to the Roadmap triggers further processes which are detailed below.

Entry Assessment

Full Assessment

Managed Capacity

Opportunity Item

Urgent Change

Standards and Capabilities Versioning 

As per Section 1 of this document, all Capabilities and Standards will have a version number. These version numbers will be in the format "a.b.c", where:

• a = major version
• b = minor version
• c = patch version

Some key principles regarding these version numbers are set out below:

• 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.
• 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. 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 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/.

Major: Change has a material impact on Capability or Standard and Suppliers will need to update their Solutions to remain compliant AND/OR a version when breaking or incompatible (i.e. not backwards compatible) changes are made.

Minor: Change does not have a material impact on Capability or Standard, but indicates a Supplier may need or wish to update their Solution AND/OR a version when larger non-breaking changes or a significant number of smaller non-breaking (i.e. backwards compatible) changes are made; or an unsubstantive breaking change is made.

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.

There may be scenarios where a specification which has been Published in the Managed Capacity route and given an Effective Date needs to be amended for some reason and changes what a Supplier is required to deliver, or may already have delivered. It is hoped that this will not be a common scenario, although it is more likely to apply to some things (e.g. APIs and messaging specifications) than others.  The following mechanisms and principles will be used to manage this:

Major changes: Any revisions which are assessed as major changes will be assessed through the Change Management Process and the Effective Dates and other parameters associated with the change adjusted accordingly to account for the work required from Suppliers. The Roadmap would be updated as necessary to reflect this change and this may be subject to the restrictions set out in the Change Management and Roadmap Content ancillary document.

Minor or patch changes: There will be items on the Roadmap in the Managed Capacity route with Effective Dates every three months to cover minor and patch uplifts to a range of existing specifications which are either Effective or Published. For example, each entry on the Roadmap could cover possible uplifts to GP Connect interfaces, IM1, GP2GP or other APIs or messaging specifications etc. but there would not be an uplift to all of these within each and every entry on the Roadmap. The scope of what is included within these will be carefully managed and monitored. Suppliers will be expected to allow capacity for these items within their List Price.

Taking this approach sets a regular rhythm for Suppliers in keeping up to date with the latest versions of specifications and allowing them to plan for this, but also for Programmes in managing their specifications and knowing when they can release patch or minor uplifts and when they can expect that they will be developed. It is expected that the details of what is to be included in each 3 monthly Roadmap entry and the specifications will be published a minimum of 3 months ahead of each Effective Date. 

Digital Care Services Standards and Capabilities Roadmap

The Digital Care Services 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 may include 'Horizon' items which Digital Care Services 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 in the Change Management and Roadmap Content ancillary document, but will still be displayed on the Roadmap. .

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 such 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 pageThe Roadmap area of Confluence presents the details of the items on the Roadmap.