NHS leaders are expected to be comfortable with tech-speak, so Jon Shaw explains some key concepts that underpin an “internet-first” approach
The latest exhortation from Matt Hancock in his role as secretary of state for health and social care is “internet first” – the NHS has until March 2021 to move away from private networks like N3 and HSCN in favour of running digital services over the internet.
Sponsored by
Strong statements like this are just what the NHS needs – the technologies that enable today’s digital services require an internet first approach to work effectively.
From day one in post, Matt Hancock has promised a “tech revolution” and has used the language of the techie. He is comfortable talking about interoperability, APIs and FHIR.
The expectation is that NHS leaders, in particular those commissioning or procuring services, should be equally so.
I thought it might be useful to cut through the jargon and agree exactly what it is we are all talking about:
APIs
APIs help you compare the best prices for flights, make payments, log in to Instagram via Facebook, order a takeaway – you get the picture. API stands for Application Programming Interface.
It is basically a way that one software “application” can talk to (or “interface”) with another through what can be thought of as an easy-to-read template.
As long as the sending application sends information in a format that matches that template (and is authorised to do so), the requesting application will process it and respond.
This process typically takes place over the internet as an “http request”.
Interoperability
APIs can be used within the same system (eg private APIs) or between different supplier systems (eg public APIs).
Public APIs in healthcare are all the talk right now and rightly so. Looking up my, or my patient’s, healthcare record should be just as easy as finding all the possible insurers and their quotes for my car.
For a long time, healthcare systems have relied on a set of messaging standards from Health Level 7 International (HL7) that either use codes and characters in linear messages to push information from one system to another, or use documents that look like more traditional medical records but supplemented with extra data.
API stands for Application Programming Interface. It is a way that one software “application” can talk to with another through an easy-to-read template. APIs can be used within the same system (eg private APIs) or between different supplier systems (eg public APIs)
HL7 messages are quite complicated to map and maintain, often inconsistent between implementations and require an integration engine sitting in the middle. This has made integration harder and more expensive than it now needs to be.
Modern APIs make communication between applications easier and more assured. A new standard has emerged for healthcare interoperability, based on web APIs, called Fast Healthcare Interoperability Resources.
It was born from, and is curated by, HL7 but belongs to the healthcare community.
While public APIs do not have to comply with the FHIR standard in order to support interoperable data exchange, when APIs are FHIR-compliant, it will make existing healthcare applications easier to swap out and new healthcare applications faster to build and deploy.
Microservices
Breaking down the functioning of software into smaller, more testable and independently deployable parts, is known as a “microservice” architecture. It helps complex software become more “agile”.
Software can be decentralised, running on different servers, using different types of technology without being held back by older technologies and design choices.
Apps and services that work together can be released independently, freeing NHS organisations from the cost and burden of deploying or updating monolithic applications.
Cloud
Cloud computing is essentially the delivery of services over the internet, running from shared data centers.
While in theory, software can be lifted and shifted from an on-premise server to a cloud server, what I call “native cloud” is when software has been designed specifically to take advantage of cloud, using microservices and APIs.
Additional microservices from the cloud provider themselves can also be used (such as machine learning or cyber threat detection technology).
Conclusion
When we deployed CareFlow Connect on the cloud in 2011 and then released public APIs in 2013, very few NHS customers had the skills to work with them and Information Governance departments struggled to accept that a service outside N3 could actually be more secure, not less.
Now we are adopting a cloud and internet-first strategy across all the System C products and are delighted that this is aligning our customers with the NHS’ own agenda.
An internet-first NHS, which can harness cloud computing, through software built on microservices and API-based architecture, will be an NHS better able to deliver the services patients and clinicians need and expect.
For more information click here.
