We have detected that you are using Internet Explorer to visit this website. Internet Explorer is now being phased out by Microsoft. As a result, NHS Digital no longer supports any version of Internet Explorer for our web-based products, as it involves considerable extra effort and expense, which cannot be justified from public funds. Some features on this site will not work. You should use a modern browser such as Edge, Chrome, Firefox, or Safari. If you have difficulty installing or accessing a different browser, contact your IT support team.
Sometimes, one local system needs to talk to another local system - for example to get a patient's records from their GP.
Often, local systems communicate via an intermediary, also known as a 'proxy'. The intermediary makes sure the communication goes to the right place.
Intermediaries are usually national systems that can route traffic to any local system in the country. For this to work, all the local systems must talk the same language, so the intermediary includes an API specification that all sending and receiving systems must follow.
We has been developing APIs for quite some time. We always aim to adopt the latest standards for new APIs. But it’s costly to rebuild APIs when technology changes. As a result, our APIs use a variety of technologies, including:
This is where two applications are coupled together very loosely in the user interface. There are two main variants.
The first variant is a simple hyperlink between two web applications, linking the user from one app to another. In some cases, the link is a 'deep link' - meaning the URL includes some contextual information, such as patient's NHS number.
The second variant is where one web application's user interface is embedded within another application, sometimes using a web browser 'frame'. Occasionally, we call the embedded panels 'widgets'.