NHS Integration and APIs

Digital technologies have the potential to transform people’s health care and their experiences of NHS services – the biggest benefits being streamlining and efficiency. As well as GP services and prescription apps, the potential for seamless healthcare delivery extends to mobile solutions for people to monitor their own health and get advice on the go.

But getting any new app or service approved by the NHS is complicated, governed by a multi-tiered assurance process. Firstly, because patient data must be protected, and secondly because there are so many people and services involved in the NHS that it can’t move as quickly it wants. The situation is further confused because responsibilities for the use of digital technology in the NHS is split between NHS England, NHS Digital, the Department of Health and Social Care, as well as others.

Yet, despite these difficulties, the adoption of digital technologies remains integral to the government’s long-term plan for the NHS. As a result, there are plenty of NHS resources online to help developers gain compliance for their third-party applications.

For example, the NHS provides APIs to access various data resources, including:

• Data held in GP systems
• Data held in the Spine

The main challenge for app developers remains the minefield of standards and compliance that needs to be navigated for a new app to be successfully deployed - which is where Blueberry can help due to our long experience in the field.

Since medical app features can vary hugely from app to app, how they access the NHS depends on what they do and the information they need to access.

As a starting point, any app that wants to access the NHS needs to integrate with the NHS Spine via one of their APIs ((there are 98 in the NHS Digital API catalogue), and connectivity is usually via an NHS Smart Card.

The HSCN (Health and Social Care Network) connection and setting up of an ODS (unique identification code for organisations that interact with any area of the NHS) can also be complex areas to navigate.

For example, HSCN connectivity requires setting up your servers behind a HSCN enabled server, so that the application has access to the Spine services.

It’s also important that the application supports multiple browsers to access the required NHS services. This is not always trivial, as each browser is different.

Applications requiring access to patient data via the Personal Demographics Service (PDS) and Service Care Records (SCR) usually follow the steps:  

Creation of developer account > setting up the application so that it can access the right spine services > testing > integration.

The most complex part of the process of going live with a new application (around 12 steps) is obtaining the technical conformance certificate from the NHS assurance team, as it involves the process of completing the SCAL (Supplier Conformance Assessment List) technical document for both PDS and SCR, so that they can provide the required sign-off for the certificate to be issued.

One of the criteria for SCAL approval is a successful Pen Test (Penetrating testing), across the NHS platforms to be used by the app. This is performed by a third party.

Prescription-based applications will require integration with the NHS Dictionary of Medicines and Devices (dm+d) database, which is the NHS standard dictionary for medicines licensed in the UK.

Note: Blueberry can host the dm+d database on our own dedicated servers and provide clients with the API calls to fully integrate searches on the medicine name, SNOMED code and so on.

IM1

With IM1, HSCN is necessary for NHS login. IM1 has three different APIs (one for each GP Clinical System: TPP, EMIS and INPS Vision). At Blueberry, we've used EMIS, INPS and TPP Vision APIs for all systems where we need to read a patient’s medical records or understand which medicines have been prescribed. We've also found that its necessary to check each API in turn to find out on which clinical system the person is registered.

GP Connect

GP Connect allows authorised clinical staff to share and view GP practice clinical information and data between IT systems, quickly and efficiently. There is an onboarding process to develop and assure a product that uses GP Connect capabilities. The access route to the NHS Spine is via ASID (Accredited System Identifier).

Personal Demographics Service (PDS)

Applications requiring access to the Personal Demographics Service (PDS) can normally use the internet as their access route. PDS is the national electronic database of NHS patient details such as name, address, date of birth and NHS number (known as demographic information) and medical information. If use of the PDS is for going to be in a restricted capacity (for example a single patient), then it's normally not necessary to require an HSCN line. The PDS FHIR API gives access to the PDS service and can be accessed via the internet using the Spine Security Proxy (SSP).

HL7

Health Level Seven (HL7) is an international healthcare standard. Clinical documents (such as discharge summaries and progress notes) use the HL7 standard and the Clinical Document Architecture (CDA) to make these documents both machine-readable and human-readable using the XML standard. 

SCR

The Summary Care Record (SCR) supports patient care in urgent and emergency care settings, so the SCR FHIR API is used for primary care. Currently, SCR is not available via the FHIR (Fast Healthcare Interoperability Resources) API, but this can be resolved using 1-Click SCR, which is a browser-based extension to local patient record management systems.

Technically, it can be challenging to access PDS and 1-Click SCR at the same time, and we’ve found the best solution is to integrate both CSI1 & CIS2 (Card identity Services for Smart Cards).

There are many challenges to building a software solution for the healthcare sector. Any application requiring NHS integration must meet strict NHS digital technical healthcare standards to gain compliance and approval. Any error in assuring the product during the onboarding process can result in costly delays.

Blueberry has extensive expertise in healthcare application development, so we know first-hand how to build compliant software from the research stage to a ready-to-launch product.

If you’re looking for a healthcare application development company or need advice from professionals on the best way to proceed, please contact us – we'll be happy to help you.

Guide to APIs link:

https://www.blueberry-health.co.uk/nhs-integration/nhs-api-guide/

Integrating with NHS Systems:

https://www.blueberry-health.co.uk/nhs-integration/integrating-with-nhs-systems/

Terminology:

API
APIs are mechanisms that enable two software components to communicate with each other using a set of definitions and protocols. An API is almost always something implemented on a server, that a client can call to obtain data.  We talk about a system "having an API" - it's the server that has this.  

CDA
The Clinical Document Architecture provides an exchange model for clinical documents (such as discharge summaries and progress notes). CDA makes documents both machine-readable and human-readable and guarantees preservation of the content by using the extensible Mark-up Language (XML) standard.

dm+d
The NHS Dictionary of Medicines and Devices (dm+d) is the NHS standard dictionary for medicines licensed in the UK, assigning a unique code to each medicine. The dm+d is a cornerstone of the Electronic Prescription Service, since Pharmacy and GP system suppliers adopt or map to the information included within it. Electronic systems that exchange or share information about medicines relating directly to a patient’s care must adhere to this standard by using dm+d identifiers and descriptions when transferring information.

FHIR
Fast Healthcare Interoperability Resources is a standard for exchanging healthcare information electronically. FHIR is a style of API (and there are many FHIR APIs within the NHS). FHIR resources can be managed in isolation or aggregated into complex documents. FHIR is designed for the web and the resources are based on simple XML or JSON structures, with an http-based RESTful protocol, where each resource has predictable URL. Where possible, open internet standards are used for data representation.

GP Connect
GP Connect is an interface / API which allows applications to talk to GP Systems managed by third parties – in other words, between new applications on one side and GP systems on the other. It’s used to permit authorised clinical staff to share and view GP practice clinical information and data between IT systems.

HL7
Health Level Seven (HL7) is a non-profit organisation involved in development of international healthcare standards. However, most people refer to HL7 as the standards, not the organisation. HL7 is also used to refer to some of the specific standards created by the organisation, such as HL7 version 2.x, version 3.0, HL7 Reference Information Model (RIM).

HSCN
The Health and Social Care Network (HSCN) is a private data network that connects hospitals, GPs and other healthcare organisations, which replaced N3.  Any third-party that wants to electronically access healthcare information needs to connect to HSCN. NHS Digital governs access to HSCN, and connectivity to it can be bought from a choice of suppliers, provided you have registered and obtained an Organisation Data Service (ODS) code from NHS Digital.

IM1
IM1 is an API which allows suppliers to integrate their system with any principal clinical system through an interface mechanism.  It comprises a set of protocols that talk to three GP systems (supplied by EMIS, Vision, TPP), and is specifically used for accessing information on behalf of patients - e.g., to implement mobile apps where a patient requests information on their repeat meds.  IM1 Pairing is an approval process where the NHS tests that applications are working in the right way with IM1.

MESH
Messaging Exchange for Social Care is the main asynchronous messaging service used across health and social care. It works on the Spine infrastructure and is used to transfer electronic messages directly from one application to another, so different organisations can communicate securely. Applications connect to the HSCN network and then use MESH to connect to the Spine infrastructure.

ODS
The Organisation Data Service (ODS) issues and manages unique identification codes and accompanying reference data for organisations that interact with any area of the NHS. ODS codes are used in almost every IT system across the NHS. If your company is interacting with data, you'll need to apply for an ODS code.

PDS
The Personal Demographics Service (PDS) is the national electronic database of NHS patient details such as name, address, date of birth and NHS number (known as demographic information) and medical information. The PDS API provides access to the demographic data held by the NHS Spine.

REST
Representational State Transfer (REST) is a set of architectural constraints designed to ensure interoperability between different Internet computer systems. REST works by putting in place very strict constraints for the development of web services and is typically preferred due to it being “stateless”, so no information about the client session is maintained on the server.

RESTful
Interfaces are often referred to as being “RESTful” when they follow principles of “REST” – in other words, a RESTful interface is one that doesn't store state.

SCR
The Summary Care Record (SCR) supports patient care in urgent and emergency care settings. The SCR stores a defined set of key patient data for every patient in England except those who elect not to allow it to be disclosed. The data provides a summary record created from information held on GP clinical systems. The SCR FHIR API is used for primary care.

SOAP
Simple Object Access Protocol (SOAP) is a technical standard used when sending information to APIs. SOAP allows processes running on disparate operating systems (such as Windows and Linux) to communicate using Extensible Markup Language (XML).

SNOMED CT
SNOMED CT is a clinical vocabulary readable by computers. Used in electronic health records. It gives clinical IT systems a single shared language, which makes exchanging information between systems easier, safer and more accurate. It contains all the clinical terms needed for the whole NHS, from procedures and symptoms through to clinical measurements, diagnoses, and medications.

Spine
The NHS central ‘Spine’ is a collection of national applications, services and directories which support the health and social care sector in the exchange of information in national and local IT systems. Clinical information is held in the Personal Spine Information Service (PSIS) and demographic information is held in the Personal Demographics Service (PDS). The Spine also supports other systems and services such as the e-Referral Service and the Electronic Prescription Service.

SSP
Spine Secure Proxy is a system within the Spine used to securely broker API calls between external systems.