| 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.
...
| Field name | Field content |
|---|---|
| Title | The name of the change |
| Description | A very brief summary of the change |
| Date added | The date the Roadmap item became ‘Confirmed’ status |
| Standards/Capabilities | List of the existing Standards and/or Capabilities which are likely to be impacted |
| 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:
|
| Effective Date | The Effective Date of the change NB. This will not be set for some items on the Roadmap and will not apply to Opportunity Items |
| Incentives / Funding | Any incentives or funding availability for this change |
| Incentive Dates | The dates during which the incentive applies |
| Additional notes | Any other general free text notes regarding the change. This might include any other aligned/dependent Roadmap items, reason for closure, more info on incentives available, any other information regarding the change e.g. anticipated date of open competition |
The presentation and publication mechanism for the overarching Roadmap is still in elaboration and further information will be provided in due course.
...