We’ve mentioned registers a few times on this blog, most recently in relation to the work of the Land Registry building on the steel thread, the brilliant new Companies House public beta, and their importance for building platforms.
For the past few months we’ve been exploring what is meant by “register”. That means we’ve been:
- conducting user research
- talking to colleagues across government who manage data (in organisations like the Food Standards Agency, the Land Registry, Companies House, MoJ, DVLA)
- processing lessons learnt building services during the digital transformation programme, and
- testing hypotheses by experimenting with software
We’ll show some of the things we’ve been doing in future posts, but here are some of the things we’ve discovered so far about registers.
Why we need registers
A register is an authoritative list of information you can trust. A canonical source of truth. Registers are important, and there are already many of them. A search of “register” on GOV.UK finds nearly 11,000 pages, and a similarly high number of documents on legislation.gov.uk contain the word “register”.
There are different kinds of register:
- open registers contain public data, and are open to everyone
- closed registers ask you to do something before you can access the data, for example pay a fee (as with seeing a Land Registry title) or provide a token (such as your driver number when using the view my driving record service)
- private registers contain sensitive information, but may be able to provide answers to simple questions, such as “Is this person registered as a potential organ donor?”, or “Is the registered keeper of this vehicle over 21 years of age?” without revealing further details about the individual
Many registers are kept by government because the law instructs it to “establish”, “maintain” or “keep” a register. A typical example is the Gangmasters (Licensing) Act 2004 which says:
The Authority shall establish and maintain a register of persons licensed under this Act.
Registers can also emerge to meet the operational needs of service providers. For example, because a visa may be sponsored by one of a number of different types of organisation, UK Visas and Immigration publish lists of sponsors such as sports governing bodies on GOV.UK in a PDF document.
Teams building digital services
We’ve spent a lot of time looking at a large number of such lists, and what’s become apparent is that they’re all held and maintained quite differently.
That causes problems.
Services have no standardised way of accessing the data in these lists so they need to develop bespoke software to do it. Where a snapshot of a list is periodically published, a service may need to notice there’s a new list, and then download and process a copy. Not having direct access to the data through an API introduces potential errors, and a lag between a change to the data being available to users of the service.
More importantly, a service team needs to be able to trust the integrity of the data. They need to know that the list will be kept up to date, and not disappear or change shape, breaking their service. Understandable documentation including clear licensing can help people use the data, but registers demand an owner, a registrar. That’s a person responsible for maintaining the list, with a clear process for quickly fixing issues with the data.
People providing services shouldn’t have to worry about data integrity. That’s the registrar’s job. That means registers should be designed so that data is always maintained and fixed at source, simplifying the design of services.
To reduce errors and reduce duplication, data in a register should reference other registers. To make that possible, registers should use standard names and formats, and each register entry should have a unique, stable identifier. Ideally, a register of limited companies should be able to trust Companies House to be the canonical source of company directors, and cite the Companies House company number rather than just a company name, which may change and can be easily misspelt (or spelled in different ways).
A registrar, responsible for a register
Maintaining an authoritative, canonical register can be quite onerous. Currently, this often means building or procuring an ill-suited product or bespoke system, or having to remember to periodically upload documents to GOV.UK.
We want to change that. We have started thinking about what a register product might look like. It should support registrars, providing them with a standard way to establish and maintain a register and assure them that it’s being kept in good order. In particular, it should be able to prove the data hasn’t been tampered with.
Here’s a screenshot of an entry in a basic prototype (this will change as we iterate further):
Simplifying and standardising how the data is stored frees registrars to concentrate on tasks specific to their domain, such as assessing and processing requests to change their register, or monitoring data quality.
Registers are for everybody
It’s not just people building services, or those in charge of data who are users of registers. A register should store a history of changes to itself and be open to independent scrutiny.
Government issues lots of artifacts, certificates, licences and other totems for information held in registers, which we should be able to check should things go wrong. We call these digital proofs: a digital register may supersede or expire your permission to do something, but it shouldn’t be able to later refute that permission was ever issued to you. Every change to a register is recorded with a digital fingerprint, and every fingerprint can be verified independently.
We believe moving from periodically publishing data to operating more standardised, open data will help everyone build better services – cheaper and faster, and across government, not just within a single organisation. We’ll continue to work with colleagues in departments and beyond, and we’ll blog regularly about what we are learning along the way.