Table of Contents | ||
---|---|---|
|
...
Anchor | ||||
---|---|---|---|---|
|
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.
...
Each Capability has a version number. Version numbers will iterate depending on the nature of the change (e.g. major, minor, patch) impacting the Capability. There is no relationship between the version numbers of different Capabilities and Standards.
...
A concise description of the purpose of the Capability.
Outcomes
This describes the main users of the Capability and the outcomes they want to achieve from using the Solution.
Epics and acceptance criteria
These describe the requirements of the Capability at a high level and will be used to assess the suitability of Solutions from suppliers at the Capabilities Assessment stage of onboarding.
The Epics are written as high level user stories with Acceptance Criteria describing the conditions which can be demonstrated for the user stories to be considered achieved. The collection of Epics which make up the qualifying component of each Capability description, simply describe the minimum functions that a Catalogue Solution must be able to demonstrate in order to be classified as achieving the Capability in question.
Suppliers will be assessed against 'Must' Epics only. 'May' Epics may be detailed for information.
...
A set of Foundation Capabilities have been identified which will be the access point for GMS funding. These are a subset of the wider set of Capabilities mandated in the NHS England GP IT Operating Model. The Foundation Capabilities are clearly identified on the Capability and Standards Model. Suppliers do not have to supply any of the Foundation Capabilities and can choose to provide one or more. Buyers will have to take all of the Foundation Capabilities in order to access central funding.
Standards
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.
...
- Overarching Standards (e.g. Information Governance)
These will be applicable to all Supplier Solutions and are NHS Digital Standards reasonably agnostic of care setting. - Capability Specific Standards (e.g. Appointments Management - GP)
These are only applicable to Supplier Solutions delivering a particular Capability and may contain business rules, data items and best practice. - Context Specific Standards - these Standards are only applicable to some Supplier Solutions depending on the implementation and scope of Capabilities they are supporting. Suppliers will have to go through compliance against these Standards per Solution offering. These include:
- 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.
- Common Reporting - applicable to any Solution providing a Capability that has reporting requirements.
- Management Information Reporting - supports the collection and submission of information to NHS Digital.
- Citizen Access - applicable to any Solution providing Citizen facing Capabilities.
...
Each Standard has a version number. Version numbers will iterate depending on the nature of the change (e.g. major, minor, patch) impacting the Standard. There is no relationship between the version numbers of different Capabilities and Standards.
...
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.
...
Term | Definition |
---|---|
Horizon | Changes which are on the Horizon will be represented in a separate section of the overarching Roadmap and are included for information purposes. A Horizon item is a potential change which NHS Digital are aware of, but it has either not been formally submitted into the change process and/or is only an idea or high level concept with little or no specification in place. It indicates items which are further into the future and for which it is yet to be determined whether it will progress and if so which of the change routes it will progress through. |
Managed Capacity | The main route for progressing new and uplifted Standards which apply to all relevant Suppliers and which are likely to have a Published specification. Where these have an Effective Date, all relevant Suppliers will be obliged to have achieved compliance with these items by the given date as per the terms of the Catalogue Agreement. Changes in this route will be separated into big and small items and will fall into one of four categories:
These items will only be commissioned via the Roadmap and Suppliers are expected to incorporate any development cost within their agreed List Price. |
Opportunity Item | Opportunities for Suppliers to bid via open competitions to engage with NHS Digital and the change requestor to collaborate on the definition of specifications and to deliver certain changes early ahead of publication to the wider market where applicable. Changes in this route will fall into one of three categories:
|
Feasibility Assessment | Opportunities for Suppliers to collaborate with NHS Digital and/or the change requestor to provide information and analysis to assess the feasibility of a new change request before it progresses through another route |
Urgent Change | Change requests which impact Standards and Capabilities which need to be progressed quickly outside of the usual change management principles. These will be commissioned separately, will likely have separate funding and will account for only a highly restricted volume of change meeting one of two criteria:
|
Draft | This is the status associated with specifications for a new or uplifted Capability or Standard which are still going through definition and elaboration with stakeholders.
At Draft status there will be a Supplier facing Roadmap page on which detail of the specification is released as it becomes available. |
Open Competition | An open competition is the mechanism used to initiate an Opportunity Item. It may be run against Lot 2 of the GP IT Futures Framework or progress via an alternative mechanism. It is a way of engaging Suppliers in change and the parameters and characteristics of each competition will be defined on a case by case basis It will also be used as a 'status' on the Roadmap to indicate to Suppliers that a particular change item will be subject to an open competition procedure which they may wish to bid for. The date given against these items will indicate the anticipated date of when the open competition will be released. |
Published | This is the status associated with specifications for a new or uplifted Capability or Standard which are fully defined, agreed and signed off and are not expected to change. Where there is a need for minor or patch uplift, this will be handled as described in the Change Management Process and Roadmap Content Ancillary 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. |
Effective | This is the status associated with Standards with which all relevant Suppliers are required to have achieved compliance. It is the status associated with Capabilities which have been included within the scope of a Framework request and hence which Suppliers are able to onboard Solutions against and sell via a Framework. When the Effective Date is reached, the old Effective page will be replaced by the new one with an uplifted version number. The old one will be given a status of Retired and moved to a specific location on Confluence. |
All relevant Suppliers | This term is used to indicate that Suppliers have the choice as to which Capabilities they choose to offer through the GP IT Framework and as such there are different Standards with which they will need to be compliant. Therefore if a change to a Standard is not applicable to the products the Supplier is offering, then that change is not relevant to them |
Achieved compliance | This means that a Supplier has been awarded a DevMAC for the Roadmap item. |
Effective Date | The date on which the Standard or Capability becomes Effective. An Effective Date will be given as a month and a year (rather than a specific day) and will always mean the last day of the given month i.e. an Effective Date of September 2019 means 30th September 2019. It is the date by which all relevant Suppliers will need to have achieved compliance with the change item. It is recognised that in the case of some legislative or regulatory changes, there may be a specific date on which it comes into force. Where this is the case, this will be reflected accordingly in the materials released. |
Backstop Date | This term means the same as Effective Date and should not be used. |
Retired | This is the status associated with old versions of a Capability or Standard which have been uplifted or replaced. These pages may be superseded by a new Published or Effective specification. These pages will remain available for reference in a specific location on Confluence. |
Closed | This is the status associated with a change request which will not be progressing. It is recognised that some change requests are submitted into the process and then are not taken forward at some point for a variety of reasons, therefore this status will be used to indicate to Suppliers that a change which had previously appeared on the Roadmap is now no longer required and they should not continue work on it. Changes at this status will remain on the Roadmap for a period of time to ensure awareness. |
Mandated | This term describes a Standard within the Managed Capacity route which Suppliers must deliver and which has been given an Effective Date by which all relevant Suppliers must have achieved compliance. Use of this term should be avoided where possible, instead referring to the Effective Date. |
Must / Should / May | See entry for 'Level' in the Master Glossary. |
Day 1 Standard | This term describes the Standards with which a Supplier will need to have achieved compliance in order to onboard on to the Catalogue and be awarded a place on Framework 1. Due to the way in which the procurement, onboarding and the compliance process will work, the date on which Suppliers will actually join Framework 1 will differ. It is anticipated that the earliest date that Suppliers could join the first Framework is July 2019, therefore this is the earliest possible Effective Date of a Day 1 Standard. As there are Standards with Effective Dates at any point beyond this, Suppliers will need to have achieved compliance with these as a condition of joining Framework 1 i.e. if there are Standards with Effective Dates in July 2019, September 2019 and December 2019 and the Supplier is due to join the Framework in January 2020, then all these Standards are Day 1 Standards. |
Versioning | This is defined in the Change Management Process and Roadmap Content Ancillary Document section below |
Roadmap | The GP IT Futures Standards and Capabilities Roadmap, known simply as 'the Roadmap', serves two primary purposes:
|
Priority Standard | This term is used to identify those changes to Standards and Capabilities which have been identified by the NHS England SROs group as the most important and top priority items for the forthcoming period. The Priority Standards may progress through any of the defined change routes, but once in the Managed Capacity route will have an Effective Date. Wherever possible, these items and the associated Effective Dates will be issued for Supplier feedback and agreed in advance of a Framework opportunity. |
...
Field name | Field content |
---|---|
Title | A unique name for the change |
Description | A very brief summary of the change |
Date added | The date the item was added to the Roadmap |
Type | As per the Capabilities & Standards - IDs and Versioning page, the type of Standard or Capability this change relates to whether Overarching, Interoperability, Context Specific, Capability Specific or a Capability only. For all items on the Roadmap , this entries will be set to a type of 'Roadmap' NB. Once the change specification is Published, the equivalent field on the page for the Published specification will be updated to one of the other options (i.e. Overarching, Interoperability, Capability Specific, Context Specific) to reflect the type of entity the change relates to e.g. if it is a change to the Prescribing Standard, this entry would then become 'Capability Specific Standard' |
Standards/Capabilities | List of the existing Standards and/or Capabilities which are impacted by the change |
Change Route | Which of the designated change routes the item is going through or Horizon if not yet determined. Options for:
NB. This is likely to be represented in a different format on the overarching Roadmap view rather than in a separate field |
Change Type | An indication as to the type of change this is:
|
Status | The status of the change item, which also includes the status of the specification within that. Options to be:
NB. This field will be marked as 'n/a' for Horizon items. There will only be one Status entry for each Roadmap item |
Effective Date | The Effective Date of the change NB. This will not be set for some items in Managed Capacity and does not apply to Opportunity Items or Horizon |
Incentives / Funding | An indication of whether additional incentives or funding will be available for this change |
Incentive Dates | The dates during which the incentive applies |
ID | As per the Capabilities & Standards - IDs and Versioning, a unique ID for the Roadmap entry in the format "RMXX" NB. Once the change specification is Published, the equivalent field on the page for the Published specification will be updated to reflect the type of entity that this is e.g. if it is a change to the Prescribing Standard, this entry would become 'S14' ; if this is a new or replace item, then a new ID in the same format will be created. |
Version | The version number of the Roadmap entry in the format a.b.c to indicate when changes have been made to the Roadmap entry. These will always be 0.x.x for Roadmap pages, such as a new draft specification being issued or an amendment to one of the parameters associated with the change. NB. Once the change specification is Published, the equivalent field on the page for the Published specification will be updated in alignment with the version number of the Standard or Capability which is being uplifted or be set to 1.0.0 if this is a new or replace item. |
Additional notes | Any other general free text notes regarding the change. This might include any other aligned/dependent Roadmap items, reason for closure, more information on incentives, any other information regarding the change e.g. anticipated date of open competition |
...