The Department for Work and Pensions (DWP) is one of Whitehall’s largest departments and is responsible for services that people need at some of the most critical or vulnerable points in their lives - including everything from pensions, welfare, to child maintenance.
Like most government departments, DWP has a mixed history when it comes to successful technology projects. However, the department’s digital group - DWP Digital - is undertaking some very interesting work that will hopefully make it easier for citizens to engage with the department.
APIs may not sound very sexy, but if you think about an API strategy in the context of DWP building a single service for citizens to interact with - that becomes very interesting. We got the chance to speak with Jacqui Leggetter, DWP Digital’s Head of Integration, about some of the department’s early API work, as well as its future ambitions.
For example, Leggetter believes that citizens should be able to approach DWP with a variety of needs, talk to one service, and then the department figures out which services they need. At present, that same citizen would have to navigate a variety of systems, depending on whether they are applying for child maintenance, benefits, or other welfare services.
However, ground work is currently underway to enable the department to get to this point. Leggetter notes that APIs have been around for a long time, in some form or another, but DWP began seriously thinking about them as a useful enabler approximately 18 months ago.
She states that DWP wasn’t building services - or components of services - that were granular or reusable. Bespoke services and duplication was the norm. The Department has signed a deal with MuleSoft to make use of its platform and change this.
The first project involves working with the NHS on streamlining its free prescription service. Leggetter explains:
When you get a prescription from your doctor, you take it to the pharmacist and you make a declaration on the back on whether you pay for it, or whether you’re entitled to a free prescription. That’s all done at the point of sale on trust at the minute. The rules around free prescriptions are also very confusing for citizens. Some people also don’t collect their prescriptions because they can’t afford it, not knowing that they’re entitled to it free of charge.
One of the qualifying conditions for a free prescription is if you’re in receipt of a particular amount of benefit, or if your benefit rates are below a certain rate. But the NHS does that check after the prescription has been dispensed. That results in a huge loss of funds for the organisation - not just in the loss of payment for prescriptions, but in the cost of recovery. Leggetter adds:
So what we’ve done is connect to the NHS IT suppliers - we went live just before Christmas - where the pharmacist can now type in the citizen’s details and do a real-time check on whether they’re entitled to a free prescription. It will call our API, which then calls our back-end systems and does a sweep across all of our benefit systems. We pull that back and give the pharmacist a yes, no or don’t know - although the ‘don’t know’ outcome is a very small percentage.
That enables the pharmacist to confirm to the citizen about their entitlement. If there’s any debate they just go back to the clerical process. But what we see is a powerful service and accepting the response that they get back.
The service is now live in five pharmacies and plans are being drawn up to roll-out the service to approximately 22,000 pharmacies up and down the country, which will be calling that API.
A layered service
Leggetter explains that the service has been built with reusability in mind and consists of multiple layers. She says that she likes to think of it like a triangle.
At the top of the triangle - the tip - is the NHS microservice, which is a bespoke layer to the NHS and has the NHS business rules.
Below that is DWP’s service, or experience layer, which is called the ‘Passport Benefit’ layer. This calls multiple APIs below it and is reusable. For example, there are other services that have the same qualifying conditions as free prescriptions - such as free school meals or blue badge schemes for disabled parking - which could make use of this.
The Passport Benefit API then calls DWP’s source API, which includes requests such as ‘get name’, ‘get date of birth’, ‘get national insurance number’, etc.
Finally, at the very bottom of the triangle are the source systems. The source systems hold the citizen information and includes DWP’s benefits systems and Universal Credit. Leggetter says:
The further down the triangle you go, the more reusable things become. So we’ve got things like ‘get name’ being used by the Scottish Government and the Home Office. You can use any of the APIs in isolation, you don’t have to come through the triangle.
That’s kind of our strategy for driving reuse. Removing duplication, enabling faster delivery of services. So as a developer you can come and really quickly rule in or rule out if it’s going to work for your service, really quick testing. I call the Amazon of APIs, we’ve got an Amazon API supermarket.
Those that want to make use of any of the API layers will connect with the data owner, to make sure that all the data sharing agreements are in place and in lined with GDPR. Leggetter adds:
We’ve taken the MuleSoft API platform and hosted it in our own AWS cloud environment. We’re up and running and live and now in an accelerated adoption mode to get more APIs on and to get more people onboarded. It’s just giving people the tools and changing the mindset to see if there’s something there first. There’s no glory in building something that’s already been built.”
Challenges and future vision
DWP’s Digital Group is based across six major digital hubs in the UK and has approximately 3,000 members of staff. That number doubles if you include contingent labour, augmented labour and suppliers. Leggetter notes that DWP does not have a central team building all of the APIs, but instead is encouraging an approach where the APIs are easily discoverable, easily testable and linked to real business outcomes.
She says that the key challenge, in this respect, has been changing the culture away from ‘build it yourself’ to ‘reuse’.
In the broadest terms, the challenges haven’t really been in technology. We’ve been learning new skills and how to use the MuleSoft product, but the biggest challenge we’ve had is the culture change. It’s getting engineers to look for reuse. There is a general belief that ‘if I didn’t build it, it’s not good enough’.
Or you find that sometimes engineers and architects can be in the details of stuff - and they find one line of code that they wouldn’t have written, or would have used Python instead of Java - when actually the outcome is exactly the same. The wheel is always round. It’s getting people to buy into that culture change, removing those barriers and enabling that reuse. Give them no excuse for not reusing.
Finally, as noted above, this strategy is forming the basis for a much more ambitious DWP programme to get citizens just interacting with the department once, even if they have a wide array of needs. Leggetter explains:
We’ve developed a lot of great digital services, but we’ve developed them in customer silos. That’s been driven by our policy groups and customer need. We’ve got loads of different channels, but what we are looking at now is creating single channels for customers.
Because if I’m a mother who is separated from her husband who is refusing to maintenance and am now looking for a job and have a disability, I may be interacting with a bunch of services at the same time. But as a citizen, I want to interact once. So that’s the vision for the business. We want citizens to tell us their information and for us to work out what help that they need at this point in time.