PRaP - going pear-shaped?

Rumours abound that the Provider Referrals and Payments system to automate SL2s in Flexible New Deal delivery has, um, a few issues. I've put together some thoughts, but I've got a limited knowledge to work from. Contributions welcome!

Background - why an electronic referrals system would be nice

The current paper-based SL2 system for referrals to provision is, to say the least, a bit ancient. Five part forms are posted to and fro across the country. Nominal rolls are printed out on ancient Jobcentre printers in a font size too small to fax, then faxed anyway so that providers know who to expect on a Monday morning, often to fax machines in public areas. The volume of paperwork leaves providers with rooms full of cardboard boxes containing personal details.

Given that this paperwork has full names, addresses, national insurance numbers, and phone numbers, it's safe to say that the current system isn't terribly secure. It's also incredibly inefficient - when I was working on the frontline of delivery, we were averaging one person who spent all day signing bits of paper for each person actually helping customers. This has improved a bit in recent years, but there are still hundreds of people across the country whose job, paid for by government money, is taking difficult-to-read bits of paper and typing in personal details on a huge variety of provider-owned databases and spreadsheets. The security of all of these systems is impossible for the government to police - there is no licensing system governing the software.

The problem with PRaP

To my mind, the biggest flaw in PRaP is that it doesn't play nicely with provider's own software. According to the FND Q&A on the topic (pdf), the web-based interface does not allow providers to export information into their own software. This does not make people's information more secure. Quite the opposite.

Providers will still have to keep their own databases of each customer they work with, and to keep them they will need to manually transfer customer details from the DWP database. This means that all the data will leave the DWP database anyway, but the DWP won't be able to see where it goes to or require the provider's software to meet a specific certification. It also means that there will be many, many rooms full of people updating from one database to another, with print-outs and security clearance and all the other things that can lead to data leaks. With the size of FND contracts being awarded, a single leak could easily expose data on tens of thousands of people.

Of course, it's not just about security. Those rooms full of people manually transferring data also represent a significant cost, and potentially a significant source of errors and confusion if they mistype a customer's details. Imagine if they could spend their time actually helping people instead.

Stand and deliver

So, the conception of PraP is less than perfect. What about the delivery? Well, since the announcement of its development, the timetable has been put back. Stories about the development have started to circulate. For example, a set of beta-testers drawn from the various stakeholders were asked to come and try out the software. However, nobody bothered to give them office space, desks or computers in the building they were meant to be testing the software in. And nobody spotted this until they actually arrived.

There's still a fair amount of time before FND goes live. The project manager will be posting regular updates on the DWP website, and hopefully the issues encountered so far will be resolved.

A better world

'It would not be practical to develop a system that integrated with all the different databases that the wide network of providers would have.' - FND Q&A

PRaP is being developed by EDS, who handle most of the DWP's IT systems. Nowadays, integration between different systems is handled through creation of open data exchange standards, usually in a language called XML. This allows programs to communicate with each other in a very easy and practical manner. It's standard practice - the UK government has XML standards for all manner of services. It's easy to make it highly secure. And, amazingly enough, it's probably cheaper than creating a dedicated web application, which is what they're doing instead. It's certainly far, far cheaper and more efficient than paying providers to keep rooms full of data input clerks. If you look at the Q&A, providers have even offered to pay for it out of their own pocket! So why aren't they doing it?*

Providers can do something about this. A program that pretends to be a user and 'scrapes' the DWP's web application into a provider database is a trivial task for web programmers these days. If they can save (or redirect) hundreds of thousands of pounds this easily, surely it's only a matter of time before it becomes the norm?

* - because EDS refused to do it. Seriously. We leave you to speculate on why a software developer might like to keep their customers away from open standards and locked into proprietary systems.