Interoperability Standard (DSCR)

ID

S80

Version

1.1.0

Type

Interoperability Standard

Status

Published

Effective Date

Mar 31, 2024

Framework(s)

Digital Social Care Records

Traceability Matrix

 

Introduction

This Standard provides information to Suppliers on interfaces they may need to implement and relevant resources. General principles of interoperability and requirements are also introduced.

Future changes to interfaces will be communicated via the Roadmap. 

Interoperability principles

These interoperability principles are a SHOULD and Suppliers are expected to adhere to them wherever possible. Whilst adherence will not be assessed via the Solution Assurance process at this time, the Authority will expect any deviation from these principles to be supported by a valid rationale on delivery of interfaces. The Authority may use adherence to these principles to guide decision making in circumstances of non-compliance or partial compliance against assured Standards.

  1. True interoperability (defined as the ability of two or more 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. 

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. Use a common data model. Health or Care 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.

  7. 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.

  8. 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.

  9. 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

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 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 publicly publish full documentation (location determined by Supplier) 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 make available public, 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 apps

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 framework, 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, 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

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

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 single Capabilities. These are typically (but not exclusively) supporting Standards such as communications protocols or related technical Standards.

Communications

  • Email (DSCR) (system accounts for automated sending for purposes such as notifications)

Roadmap

Items on the Roadmap which impact or relate to this Capability

Â