CURRENTLY FOR REVIEW
Yatin Mahandru, head of health and public sector at Cognizant, conveys some ideas about how step up the use of application programming interfaces for the public good
It has now been five years since UKAuthority and Cognizant partnered on a research project on the outlook for application programming interfaces (APIs) in public services.
Since then, there has been significant progress in building up their role in the sector’s digital infrastructure; but there is still a lot more to do. Digital leaders still express frustration at the problems in implementing APIs, such as reluctance by legacy systems suppliers to provide them and the practical challenges of ensuring they work within a wider framework of data standards.
We are beginning to see what measures need to be taken. A recent UKA Live discussion brought together two public sector experts in the field – Stephen Koch, executive director of platforms at NHS England, and Chris North, deputy director integration services at DWP Digital – with myself and UKAuthority publisher Helen Olsen Bedford to explore the relevant issues.
The conversation made clear it is still as significant challenge but that are strong ideas about how it can be overcome.
It also reiterated the benefits that APIs can bring as connectors for data sharing within and between organisations, extending access to real time data, and providing for the better use of common data to support more joined up services.
Indicators of progress
Both of the public sector participants described the progress their own organisations have made. Koch said that in the NHS APIs are being used to facilitate the exchange of key information such as medical records between care settings, and connect tens of thousands users to shared services such as prescribing and dispensing medications.
North said APIs have been included in a strategic reference architecture for the development of services in Department for Work and Pensions, that there is an ‘API first’ approach, and that they have all been placed on the Government’s API catalogue.
Both have run into problems on the way. Koch said the use of APIs becomes more complicated when an application or database is updated by a large number of systems on which the data could be of varying quality, which in turn affects the quality of the updates. This requires that these differences are flagged up when they are developed and serious thought is given to the way they are used.
North said that building an API in isolation does not make it effective; it has to be within the reference architecture. There is also sometimes a reluctance among digital teams to build them because of the effort involved.
DWP Digital has provided support with the latter through generating code, providing automated tools to get them up and running, and a centre of excellence that can help with the testing, iteration and ensuring that the way they function is fully understood.
Cost and time
There have also been issues around the cost and time taken for adoption. In response, DWP Digital has been working on providing simpler APIs and support in onboarding, with the ultimate aim being a catalogue of services and more self-service.
It has also been importance to provide a single source with information on what APIs are available, who supports it, what it does, whether it is supported 24/7/365 or less frequently, and its progress in its lifecycle, such as the phase of development or whether it is due for deprecation.
“Having that broad transparency is incredibly important,” he said. “For people to use the APIs it is important to get the teams that own them to think about it in those ways.”
Other issues were also highlighted, including the relationship of APIs to data standards. Koch said that even a widely used international standard may not cover all the capability required in an API, citing examples of standards for sharing patient data and transfers of care that do not cover everything a relevant API is meant to achieve.
This often derives from subtle differences in processes in different places and there is a need to find a better way of doing it, he said.
Definitions and catalogues
North made the point that there is a need to go beyond data standards into new ones for how to define and catalogue APIs, and to ensure these are easily discoverable so they can be picked up and used when appropriate.
A question arose on whether there is a case for combining all relevant API catalogues in the public sector into a single source. It was agreed that there are pros and cons to this as many APIs would not be right for re-use beyond the processes for which they were developed; but there could be a core collection that is more widely useable.
It would require some close investigations to identify these, and the creation of a body with some level of authority to define them. This could prove to be very difficult, but there could be scope for cross-referencing within a catalogue to show where else an API could possibly be used.
There is also a possibility of dual level APIs, for which there is a granular version for use inside an organisation, and one that is less detailed but more user-friendly for external use. Again, this would require a considerable amount of work in making the distinction, but it could prove to be a useful approach.
Practicalities and joining up
A central feature of all this is that, compared with five years ago, the nature of the discussions around APIs have changed. At that time there was a need to educate people in the public sector about the importance of their potential; now it is much more about educating them on how to deal with the practicalities and ensure they provide the connections between systems to deliver more joined up services.
The challenge has changed its complexion, but the thinking has advanced to the point where there is plenty of cause for optimism.
CALL TO ACTION
