ID
S32
Version
| Page Properties | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| Excerpt | ||
|---|---|---|
| ||
Defines a comprehensive set of Standards, interfaces and protocols that Solutions and systems will use when interoperating. |
| Table of Contents | ||
|---|---|---|
|
Introduction
This Standard replaces General Practice Systems of Choice (GPSoC) requirements relating to integration and interoperability. It provides a single place for system Suppliers to find out which interfaces they need to implement and to access the required documentation.
Future changes to interfaces will be communicated via the Roadmapthe Roadmap.
Notes on quality and consistency of interface documentation
There are a large number of interfaces that GP systems 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 GP systems market (no new entrants needing to implement) 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
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, e.g. where the replacement of existing VUAexisting VUA/OSA/LOSA based LOSA based Patient accounts by NHS login could impact an interface implementation
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 NHS Digital team at gpitfutures@nhsat gpitfutures@nhs.net to net to resolve any documentation issues which block them from delivering compliant implementations.
Interoperability principles
These interoperability principles are a SHOULD and Suppliers are expected to adhere to them wherever possible. Whilst adherence will not be assessed at onboarding, NHSD will expect any deviation from these principles to be supported by a valid rationale on delivery of interfaces. NHSD may use adherence to these principles to guide decision making in circumstances of non-compliance or partial compliance against assured Standards.
True interoperability (defined as the ability of two or systems to work together unchanged, even if they weren't designed to work together) rather than integration (change is required to make the systems connect) should be achieved wherever possible - Integration takes work, interoperability just works. Although the term interoperability is in widespread use within the NHS, what is meant is rarely well defined and the terms interoperability and integration are frequently used interchangeably. In our experience, the NHS uses a weak definition where two systems are said to be interoperable if they can exchange data in any way - even if that exchange is via a bespoke, point-to-point integration. True interoperability reduces the integration burden and allows systems to communicate more readily.
Interoperability is more important than supporting customisation. Use the base definition of Standards wherever possible. Extend only by addition and by exception. Do not view integration as a source of competitive advantage.
Use open design. The effectiveness of security components included in a Solution design should not be compromised by any visibility of that design, i.e. should not rely on obscurity.
Use open and government standards. Design systems up front to support information sharing. This covers both alignment with Open Standards and the use of Open APIs. Use open Standards (including from outside healthcare), and common government platforms (eg GOV.UK, identity assurance, shared services) where available.
Make data open by default. Whilst minimising and securing personal data, or data restricted for national security reasons. Public data should be made available by default in both human and open machine-readable formats. Users should have access to, and control over how their own personal data is shared.
Use a common data model. Healthcare systems are connected in a many-to-many fashion. In this scenario, the use of a common data model ensures that each system only has to be able to translate to and from the common model and does not need system-specific knowledge of myriad other connected systems.
Messages should always be structured. Adding preformatted ‘human readable’ text or formats such as HTML to messages increases coupling with the source system and reduces the reusability of the message while increasing the risk of a system receiving inappropriate data which cannot be detected. Receiving systems are responsible for transforming structured message into appropriate formats (e.g. HTML, PDF or images etc.). It's always preferable to store the structured data and render to a display format on demand.
Interfaces must be system agnostic and semantically standardised. Systems must not expose their internal complexity and data structures on interfaces, nor should they expect systems they interface with to understand their internal data encodings and semantics.
Use decoupled integration patterns wherever possible. Decoupling should be achieved using appropriate integration patterns such as publish-subscribe and event-based architectures.
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.
Req ID | Requirement Text | 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 the Change Management Process |
| ||||||
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 IG requirements and specific message flow requirements to ensure that support desks have access to the required information when investigating incidents/issues. |
| ||||||
ISNFR03 | Suppliers will publicly publish full documentation for all currently live or in development and available-to-consumers interfaces, under a Creative a Creative Commons Attribution-NoDerivatives 4.0 International License. Documentation must include, but is not limited to:
|
| ||||||
ISNFR04 | For all currently live or in development and available-to-consumers interfaces, Suppliers will make available public, mock versions of the interfaces to support consumer development and testing. Mocks must meet the following criteria:
|
| ||||||
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 |
| ||||||
ISNFR06 | Discrepancies discovered between ISNFR03 documentation and actual interfaces will be rectified within 5 working days of first notification to the interface provider |
| ||||||
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 apps. |
| ||||||
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 framework, but they should offer only one technical API for each purpose. |
|
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, GP Connect the following requirements apply to the production implementation. For requirements relating to performance and availability Suppliers should refer to the Service Level Agreement.
Req ID | Requirement Text | 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. |
| ||||||
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. |
|
Capability-independent interoperability Standards
This section lists the interoperability requirements which are not linked to single capabilities. These are typically (but not exclusively) supporting Standards such as communications protocols or related technical Standards.
Spine
The NHS Spine provides Spine provides national interoperability infrastructure as well as specific national services, for example the Personal Demographics Service (PDS) listed further below under Dependencies.
Two specific Spine Spine components are key supporting Standards for a number of the interop Standards, and are listed multiple times within the 'Dependencies' column below. They are:
External Interface Specification (EIS) describes how to connect to NHS Spine services
NHS Messaging Implementation Manual (MIM) describes the message formats used for Spine interactions
IM1 - Interface Mechanism
IM1 - Interface Mechanism is a mechanism for accessing data held in GP Systems (Systems providing one or more Capabilities as part of the GP IT Futures Framework). The interface mechanism facilitates three use-cases (Patient, Bulk and Practice) which are detailed within the IM1 page.
A system or application may wish to consume IM1 interfaces where they have a requirement to access data held in GP Systems.
A system or application is required to provide IM1 interfaces if ANY of the following are true:
It offered IM1 interfaces under GPSoC
It offers ALL Foundation Capabilities
Authentication and authorisation
Standards for confirming the identity of service users and controlling their access to services or specific resources.
Authentication and Access
NHS login service
Communications
Email Email (system accounts for automated sending for purposes such as notifications)
Generic FHIR Receiver
Generic FHIR Receiver Receiver (a component which will receive messages to the GP Practice)
Capability-specific interoperability Standards
This section details the interoperability requirements which are associated with each Capability.
Some interdependencies between individual interface Standards exist. Creating a compliant implementation requires implementing all the required dependent interface Standards, as detailed in the 'Dependencies' column.
Suppliers need to comply with all of the requirements that are associated with the Capability/Capabilities which the Supplier is offering.
Foundation Capabilities
Patient Information Maintenance - GP
Interoperability Requirement | Dependencies |
|---|---|
IM1 - Interface Mechanism Provider requirements (if offering all Foundation capabilities) |
|
NHAIS HA/GP Links |
|
Personal Demographics Service (PDS) | PDS FHIR APIFor Suppliers of new services or applications:
2018 PDS Integration Requirements – v1.0 or olderFor Suppliers of services which ARE currently deployed into an operational environment:
|
GP2GP | GP2GP FHIR ImplementationFor Suppliers of new services or applications:
GP2GP HL7For Suppliers of services which ARE currently deployed into an operational environment:
|
Summary Care Record (SCR) | Summary Care Record FHIR APIFor Suppliers of new services or applications:
NHS Summary Care Record Service - GP Summary Requirements v5.8.3For Suppliers of services which ARE currently deployed into an operational environment:
|
GP Connect Access Record HTML (Provider requirements) |
|
GP Connect Access Record Structured (Provider requirements) |
|
GP Connect Send Document (Receiver requirements) |
|
GP Connect Update Record (Receiver requirements) |
*May be sourced indirectly by existing PDS interface provided by a Patient Information Maintenance - GP (PIM) Solution, either via API to this Solution, or as a shared application resource if delivered as part of the same Solution. |
111 | Without Using NHS 111 Report Adaptor
|
GPES Data Extraction |
|
Secure Electronic File Transfer (SEFT) (in order to meet Primary Care Clinical Terminology Usage Report) | |
Digital Medicines and Pharmacy FHIR Payload |
|
National Data Opt-Out |
|
GP Data for Planning and Research |
*May alternatively use AWS Direct S3-S3 transfers as the secure transport mechanism |
Transfer of Care FHIR Payload |
|
Consultation Management - GP
Interoperability Requirement | Dependencies |
|---|---|
IM1 - Interface Mechanism Provider requirements (if offering all Foundation capabilities) |
|
Electronic Yellow Card Reporting Reporting | |
Messaging Exchange for Social Care and Health (MESH) (in order to meet eMED3 Fitnotes) |
Appointments Management - GP
Interoperability Requirement | Dependencies |
|---|---|
IM1 - Interface Mechanism Provider requirements (if offering all Foundation capabilities) |
|
GP Connect Appointment Management (Provider requirements) |
*May be sourced indirectly by existing PDS interface provided by PIM Solution, either via API to PIM Solution, or as a shared application resource if delivered as part of the same Solution. |
Messaging Exchange for Social Care and Health (MESH) Or Secure Electronic File Transfer (SEFT) (in order to meet General Practice Appointments Data Reporting) | |
GP Data for Planning and Research |
*May alternatively use AWS Direct S3-S3 transfers as the secure transport mechanism |
Prescribing
Interoperability Requirement | Dependencies |
|---|---|
IM1 - Interface Mechanism Provider requirements (if offering all Foundation capabilities) |
|
Electronic Prescription Service (EPS) - Prescribing | EPS FHIR API - Prescribing APIFor Suppliers of new services or applications:
EPS Prescribing Systems Compliance Specification v6.11 or olderFor Suppliers of services which ARE currently deployed into an operational environment:
*May be sourced indirectly by existing PDS interface provided by PIM Solution, either via API to PIM Solution, or as a shared application resource if delivered as part of the same Solution. |
Referral Management - GP
Interoperability Requirement | Dependencies |
|---|---|
IM1 - Interface Mechanism Provider requirements (if offering all Foundation capabilities) |
|
e-Referral Service (eRS) | e-Referral Service FHIR API - Primary Care ReferrerFor Suppliers of new services or applications:
NHS e-Referrals Service - Referrer Compliance Document v1For Suppliers of services which ARE currently deployed into an operational environment:
*May be sourced indirectly by existing PDS interface provided by PIM Solution, either via API to PIM Solution, or as a shared application resource if delivered as part of the same Solution. |
Resource Management
Interoperability Requirement | Dependencies |
|---|---|
IM1 - Interface Mechanism Provider requirements (if offering all Foundation capabilities) |
|
Non-foundation capabilities
Communication Management
Interoperability Requirement | Dependencies |
|---|---|
Appointments Management - Citizen
Interoperability Requirement | Dependencies | ||
|---|---|---|---|
IM1 - Interface Mechanism (Patient interface Consumer) | IM1 - Interface Mechanism | IM1 - Interface Mechanism | |
| nopanel | true | NHS login service |
Prescription Ordering – Citizen
Interoperability Requirement | Dependencies | ||
|---|---|---|---|
IM1 - Interface Mechanism (Patient interface Consumer) | IM1 - Interface Mechanism | IM1 - Interface Mechanism | |
| nopanel | true | NHS login service |
View Record - Citizen
Interoperability Requirement | Dependencies | ||||
|---|---|---|---|---|---|
IM1 - Interface Mechanism (Patient interface Consumer) | IM1 - Interface Mechanism | IM1 - Interface Mechanism | nopanel | trueNHS login service
Digital Diagnostics
Interoperability Requirement | Dependencies | ||
|---|---|---|---|
Digital Diagnostics & Pathology Messaging | Digital Diagnostics & Pathology Messaging | Digital Diagnostics & Pathology Messaging | |
| nopanel | true |
| Screening messaging | Screening messaging |
| nopanel | true | ||
Screening messaging | Messaging Exchange for Social Care and Health (MESH |
Communicate with Practice - Citizen
Interoperability Requirement | Dependencies | ||||
|---|---|---|---|---|---|
IM1 - Interface Mechanism (Patient interface Consumer) | IM1 - Interface Mechanism | IM1 - Interface Mechanism | nopanel | trueNHS login service
Capabilities to support new ways of working
Cross-organisation Appointment Booking
Interoperability Requirement | Dependencies |
|---|---|
GP Connect Appointment Management (Consumer requirements) |
*May be sourced indirectly by existing PDS interface provided by PIM Solution, either via API to PIM Solution, or as a shared application resource if delivered as part of the same Solution. |
Unified Care Record
Interoperability Requirement | Dependencies |
|---|---|
Or
|
*May be sourced indirectly by existing PDS interface provided by PIM Solution, either via API to PIM Solution, or as a shared application resource if delivered as part of the same Solution. |
Medicines Optimisation
Interoperability Requirement | Dependencies |
|---|---|
|
*May be sourced indirectly by existing PDS interface provided by PIM Solution, either via API to PIM Solution, or as a shared application resource if delivered as part of the same Solution. |
Deprecated Standards
There are currently no Deprecated Standards.
Roadmap
| Page Properties Report | ||||||||
|---|---|---|---|---|---|---|---|---|
|