Last month we launched the new online electoral registration service. This is the digital part of the wider Individual Electoral Registration (IER) policy. Pete has already blogged about how we engaged with lawyers while developing the service.
In this post I’ll give an overview of how the service itself works, and the three main data flows through the system - applications that are made online, applications that are made on paper and people who move house.
The electoral register
There’s no central electoral register in the UK. It’s divided up into local chunks, with an Electoral Registration Officer (ERO) responsible for assessing ‘register to vote’ applications for that area.
EROs use Electoral Management Software (EMS) to manage their electoral register, check registrations, add and remove people from the register and so on. There are 6 different software systems in place across the 380 plus EROs in England, Scotland and Wales. The majority are provided by private sector suppliers.
What we at GDS have built is essentially an Individual Electoral Registration (IER) ‘hub’. The idea is to make sure that EROs can receive and assess 'register to vote' applications as quickly as possible. To show how it works I’ll step through the 3 main journeys data takes through our system, using whiteboard sketches for illustrations.
1. Applications using the ‘register to vote’ online service
When a user hits the ‘send my application’ button, their application goes to the IER hub. The hub identifies the ERO that covers their address (using the full address rather than just the postcode, because some postcodes straddle ERO boundaries). The application is encrypted and persisted.
This application is immediately available for the ERO to download, enabling offline processes to begin. However in most cases the ERO will wait until the results of the data matching to be available before the application will be fully processed.
How data matching works
Every day at 11pm the IER system packages up all the applications it has received and sends them to the data matching service. This is done using FTPS over the Government Secure Intranet (GSi). Currently there is no API to allow us to do this in real time. There are existing services however they were not deemed extensible enough for us to use them for this project within the timeframes we had.
The automated data matching service checks whether the applicants’ National Insurance number relates to a record with the provided date of birth. Then this found record is compared with the full name of the application. The results of this are a hierarchical series of boolean statements indicating a type of match. For example "first name last name exact" or "first name initials last name exact" and so on.
This data is returned to the IER hub at 7am the next day, and the match result is appended to the relevant application. The results from the matching algorithm are processed into a version for the ERO to use - an overall red/green status , date of birth/national insurance number result, plus the indication of the strength of the name match.
The relevant electoral officer uses their local system to pull this data down from the IER hub, and once they have it saved locally they send a ‘delete’ message to the IER hub. Once it’s been marked to delete, data is physically deleted within 48 hours (the 48 hour window is there so data can re-download if there’s an error).
The ERO uses the data matching results to help them to decide whether someone should be be added to the electoral register. Making this information available to EROs should help them make decisions more quickly, and increase the accuracy of the electoral register.
Connecting EROs to the IER hub
To connect the EMS systems to the IER hub we built an API (Application Programming Interface) which is accessible via the Public Services Network (PSN), working closely on its functionality with the vendors of EMS systems. The API allows EROs to upload, download and delete applications.
2. Applications using a paper form
IER is not digital only, we don’t exclude those who cannot use the internet for whatever reason. People can still register to vote using a paper form or in person. This is one of the ways we are meeting our responsibilities around assisted digital. As mentioned above the IER API allows the ERO to upload data: this is so EROs can use the data matching service to verify applications made directly to them as well as those made online.
The ERO scans the paper form into their EMS system and then the details are submitted to the IER hub. They are then packaged up with the online applications and verified against the matching algorithm and downloaded by the ERO as described above.
3. Changes of address
The final journey is slightly different. When someone moves house they have to be added to the register at their new address and removed from the register where they used to live. This process was previously slightly ad hoc, relying on the new ERO getting in touch with the previous ERO directly.
The IER hub helps by routing these messages automatically. When an ERO receives an application with a previous address, they know that this citizen also needs to be removed from the register at this old property.
When an ERO finishes processing an application, a message is sent - via more endpoints on the same API - to the IER hub. The hub maintains a queue of these remove requests for each ERO. The previous ERO can download and process these notifications in the same way as new applications. No matching algorithm is needed here, because it’s essentially a message from one ERO to another.
Helping EROs make decisions
The digital aspects of the IER system are basically a conduit - a way of creating queues that make it quicker and easier for EROs to process applications accurately. It doesn’t store data for any longer than it has to, and it doesn’t place people onto the electoral register directly.
The last important point to mention here is that the legal responsibility for placing somebody onto the register remains with the ERO, the IER hub does not say that a person should or should not be on the register it just provides further evidence for the application.
Using the PSN and a series of APIs, the IER hub lets the full network of EROs in local government talk directly to central government. This is incredibly important as it shows the potential that PSN has to help us join up services across the different levels of government. The system provides connectivity to enable the ERO to have swift access to improved data to better enable them to manage the electoral role, the basis of the electoral process.
Whiteboard pictures transformed by: https://gist.github.com/lelandbatey/8677901
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.