To that end, we have:

• built an API platform, which has become the national API platform for NHS England
• built an exemplar API, the Personal Demographics Service FHIR API
• built a number of other APIs on the platform
• sunsetted older APIs in line with our policy
• created an API and integration catalogue which lists all our APIs, old as well as new
• developed a digital onboarding service to enable easier access to APIs

We have made lots of progress, but there is more to do.

Quality is an ongoing challenge. We have had a lot of great feedback from API consumers, so we know what a good API looks like, and have a clear set of API principles.

But each API is built and run by a different team, and making sure everybody plays by the same rules is never easy. Making the case to improve existing APIs is especially tough. Change must be funded, and funding requires a business case.

To help API teams build that case, we’ve published a set of API policies and best practice guidelines to ensure our APIs provide a consistent user experience and give API consumers the confidence that they are built to a high quality. All new and existing NHS England APIs must comply with these policies.

The policies might not be what you would expect. You might think they would focus solely on technical aspects of APIs, such as REST, OAuth 2.0 and FHIR. But conforming to technical standards is only one of the 9 policies.

Defining these policies also allows us to measure progress against them for our existing APIs, some of which pre-date the API platform. For example:

• 67% of our APIs are internet-facing
• 31% of our APIs have self-service testing
• 22% of our APIs use digital onboarding
• 45% of our APIs have an empowered product owner

As you can see, we are doing better on some measures than on others.

It is our intention that by publishing these figures, and working with our API delivery teams and those who build healthcare software, we will continue to drive change. And that by working with our empowered product owners, we will improve the experience of those software development organisations wanting to integrate with us.

The above statistics might be somewhat reductionist, but hopefully we can use them to drive positive change from within. We want to avoid producing complex dashboards that are time-consuming to maintain and ultimately don’t help us measure our progress.    

Feedback from API consumers is also essential, so if there is anything specific you would like to see us do, tell us about it via our interactive product backlog.