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:

• Full details of all available endpoints

• Message structures

• Code sets

• Intended interface behaviour, including any sequencing of calls, with pseudo code reference exemplars

• Requirements on Consumers

• Error handling

• Authentication and authorisation requirements

• Encryption, transport layer security and certificate requirements

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:

1. They must cover the full scope of behaviour of the interface

2. They must offer sufficient fidelity to the live interface to fully support Consumer development and testing

   1. Test data/scenarios must be publicly documented, e.g. Consumers will be clearly signposted which data they must submit in order to test a particular endpoint, error handling scenario or particular behaviour of the interface

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

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

All

IM1 - Interface Mechanism

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:

• It offered IM1 interfaces under GP IT Futures

• It offers ALL Foundation Capabilities

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

Authentication & Access

Standard for controlling Health or Care Professional access to services or specific resources.

All

NHS Login Service

Standard for confirming the identity of Patients/Service Users.

All

Email

Standard for Health and care systems that send and receive email; to ensure their email service meets the secure email standard.

• GP IT Futures

• Tech Innovation

Generic FHIR Receiver

A component which will receive messages into the GP Practice Solution.