Interoperability Standard
- Jonathan Telfer (Unlicensed)
- Victoria Bussey
- Imran Majid (Deactivated)
ID | S32 |
Version | 18.1.1 |
Type | Interoperability Standard |
Status | Effective |
Effective Date | Dec 16, 2024 |
Contracting Vehicle(s) |
Introduction
Defines overarching Interoperability requirements and interfaces to be implemented, including quality and principles to be followed for Supplier Solutions.
Notes on quality and consistency of interface documentation
There are a large number of interfaces that Solutions need to implement. These interfaces, and their documentation have been created over a very long period of time by a number of different organisations and programmes. The static nature of the Solutions market means that historically there has been limited justification and appetite for modernising or standardising existing documentation. This means that the format, quality and consistency of interface documentation is currently extremely variable.
Until these issues can be addressed Suppliers and system implementers should expect to encounter issues with interface documentation. These could include:
Inconsistencies in how optionality of requirements is expressed, e.g. MoSCoW ratings (Must Have/Should Have/Could Have/Won’t Have)
References to obsolete or outdated externalities, e.g. in-force legal frameworks, organisations or systems
Descriptions of 'upcoming' or planned future phases which may or may not have actually occurred
Broken links
Referenced documents that have been included elsewhere in this Standard rather than in the indicated location
Referenced documents that interface owners have advised are no longer relevant
Unavailable information relating to the impact of upcoming roadmap changes
Verbose and/or difficult to follow documentation compared to modern best practices for interface documentation
Unavailable sample files or test data
Suppliers should contact the Authority at gpitfutures@nhs.net to resolve any documentation issues which block them from delivering compliant implementations.
Interoperability principles
Suppliers are expected to adhere to the interoperability principles wherever possible. Whilst adherence will not be assessed in Onboarding, the Authority will expect any deviation from these principles to be supported by a valid rationale on delivery of interfaces.
Detailed guidance is available from gov.uk Technology Code of Practice, API Technical & Data Standards Guidance & API Design Guidance
Interoperability non-functional requirements
The following overarching requirements apply to all interfaces in the scope of the Interoperability Standard which are offered by a Solution.
ID | Requirement | Level |
ISNFR01 | Suppliers will implement uplifts to the message & API specifications included within the interoperability Standard as agreed & directed by the ‘Minor or patch changes’ section of the Change Management Process. | MUst |
ISNFR02 | The system will provide comprehensive audit facilities for ALL messages, including acknowledgements, over ALL transports and using ALL message types/syntax in order to satisfy general Information Governance requirements and specific message flow requirements to ensure that support desks have access to the required information when investigating incidents/issues. | MUst |
ISNFR03 | Suppliers will provide the full documentation for all currently live or in development and available-to-consumers interfaces, under a Creative Commons Attribution-NoDerivatives 4.0 International License. Documentation must include, but is not limited to:
| MUst |
ISNFR04 | For all currently live or in development and available-to-consumers interfaces, Suppliers will provide mock versions of the interfaces to support Consumer development and testing. Mocks must meet the following criteria:
| MUst |
ISNFR05 | Discrepancies discovered between ISNFR04 test mocks and behaviour of live interfaces will be rectified within two working days of first notification to the interface Provider. | should |
ISNFR06 | Discrepancies discovered between ISNFR03 documentation and actual interfaces will be rectified within 5 working days of first notification to the interface Provider. | MUst |
ISNFR07 | Within the scope of interfaces specified within the Standard, Suppliers must not offer differential service, e.g. all API functionality and behaviour will be equally available to all API Consumers, including the API Provider's own applications. | MUst |
ISNFR08 | Suppliers should not offer multiple APIs for the same purpose, e.g. there should not be multiple, different Appointments Booking APIs. Suppliers are free to offer APIs to different Consumers under different commercial terms if permitted by the contract and Contracting Vehicle, but they should offer only one technical API for each purpose. | should |
Minimum non-functional requirements for interfaces built to the Authority's specifications
Where an interface/extract is built to the Authority's functional specifications, e.g. IM1 - Interface Mechanism or GP Connect, the following requirements apply to the production implementation. For requirements relating to performance and availability Suppliers should refer to the Service Levels.
ID | Requirement | Level |
ASNFR01 | Data currency. Updates to systems made through non-API mechanisms (e.g. user interface) should be available on APIs in real time, i.e. as soon as the update transaction is committed. | should |
ASNFR02 | Data currency. Updates made through APIs must be available on APIs in real time, i.e. as soon as the update transaction is committed. | MUst |
Capability-independent interoperability Standards
This section lists the interoperability requirements which are not linked to specific Capabilities. Where a requirement mandates compliance with specific Interoperability Standard(s), there is no alternative implementation. These are typically (but not exclusively) supporting Standards such as communications protocols or related technical Standards.
Applicable Contracting Vehicle(s) | Interoperability Standard | Description |
All | IM1 - Interface Mechanism is a mechanism for accessing data held in GP Systems (Systems providing one or more Foundation Capabilities). The interface mechanism facilitates three use-cases (Patient, Bulk and Practice) which are detailed within the IM1 page. A system or application is required to provide IM1 interfaces if:
Where a GP Connect interface capability is available, Provider Suppliers would be expected to develop against that, rather than developing a new bespoke or proprietary interface. A system or application may wish to consume IM1 interfaces where they have a requirement to access data held in GP Systems and the Provider Solution does not offer a GP Connect interface. | |
All | Standard for controlling Health or Care Professional access to services or specific resources. | |
All | Standard for confirming the identity of Patients/Service Users. | |
All | Standard for Health and care systems that send and receive email; to ensure their email service meets the secure email standard. | |
| A component which will receive messages into the GP Practice Solution. |
Capabilities with Interoperability Relationships
See Capabilities with Interoperability Relationships for guidance on the interoperability requirements which are associated with each Capability.
Note: this page is for guidance only and does not supersede what is mandated in the individual Capabilities and Standards.
Deprecated Standards
There are currently no Deprecated Standards.
Roadmap
Items on the Roadmap which impact or relate to this Standard