All registers, irrespective of the legislative base from which they came into existence, share a common set of functions, that are agnostic indeed to the purpose of the register. These could be described in simple terms: to file, to store, and to publish the entries on the register. In computer terms this would translate to the operations of create, read, update, and delete (CRUD) that are the four basic operations of persistent storage. However, the complexity of a statutory register does go beyond the simple maintenance of such operations.
Statutory registers are the constructs that store the data of government. They are singularly the most important element or construct in the provision of Digital Public Services.
Good practice in terms of data exchange across government, inherently means interoperability between these registers or what the European Commission (EC) through the Directorate General of Informatics (DG-DIGIT) describes as base registers vi. Registers can vary significantly in form and type.
In terms of understanding the modes of interoperability that can and do exist between registers, it is important to define the characteristics of registers that form the end points of this exchange. These characteristics exist in some registers, but they do apply to all types of registers.
The general characteristics of a register, irrespective of the domain that it governs, are as follows vii:
- Registers are canonical and have a clear reason for their existence
A register is the only authoritative list of a specific type of thing. It is the source of that information, kept accurate and up to date. For example, a business register administered by a business registration authority should be the single, authoritative place to go to find data directly related to legal entities within that authority’s jurisdiction. The purpose of a register should fall within the bounds of a registrar’s public task, that is its core role or function.
- Registers represent a ‘minimum viable dataset’
A register only holds the data it was created to record, and nothing else. It never duplicates data held in other registers. Registers should be linked to data in other registers to avoid the need for any duplication (e.g., Corporate or Companies Registers integrated to Beneficial Ownership Registers to Land Registers integrated with Ownership Transparency Registers). It is our contention that this is the primary reason for interoperability. In order that registers can exchange information they must be able to uniquely identify their own entities, and ideally update information, on their registers. The register should always use available and accepted references such as ISO standard list conventions. Registers by their very nature are long-lived because the services they expose and the other registers within their ecosystem, depend on them. The register is always just the data persisted and it is the services extrapolated to present this data in an intuitive manner to the registers’ stakeholders that is the differentiating factor.
- Registers are live lists, not simply published data
Registers are living constructs that must continually represent the domain to which they were created. It is our contention that a static list is not a register. Making changes to a register shouldn’t take long and should only be the elapsed times for the custodian to validate a new entry and guard the register against fraud and error. A modern register will employ all the automation techniques available to remove any manual intervention in terms of maintaining the register relevant. Registers should have a standard interface for reading and querying their contents, which follows the Application programming interface (API) principle.viii There should be a clear process for challenging data held in a register with high standards for transparency, adjudications, and the processing of other issues discovered by users with register data. A register API should be highly available. Public register data should be cacheable by intermediaries and web clients to enable the incorporation of the register directly in live services, as well as being easily downloaded in bulk for offline applications, and updated using a streaming API.
- Registers use standard names consistently with other registers
Wherever possible a register reuses standard names for fields to enable discovery. The data held in a register may evolve over time: new fields may be added to new entries in a register so long as they have a sensible default value for entries, and existing field names are not used for a new, different purpose. Again, this is consistent with the canonical principle.
- Registers are able to prove integrity of record
Each individual entry in a register is immutable, addressable using a ‘fingerprint’ which may be used by a user as a digital proof of record – Source of Truth. A record in a register is a series of entries sharing the same identifier. The latest entry being the current value for a record. Older entries for a record must remain addressable, but their contents may be removed if instructed by legislation. The record of changes made to a register should be transparent and independently verifiable.
- Registers are clearly categorised as open, shared or private
The privacy of a register should be clear, and either open, shared or private: open registers are public. The data may be accessed, copied, and derived freely, by anyone, either as single register entries or as a complete register, with clear licensing terms designed for reuse, and shared registers allow access to a single register entry. Private registers contain sensitive information which cannot be accessed directly by services. Public registers should not reference private registers.
- Registers contain raw not derived data
Data held in a register should be factual raw data, not informational content, or counts, statistics, and other forms of derived data.
- Registers must have a custodian
A register should directly meet a user-need or legal obligation. A custodian is appointed that confers trust and is responsible for the register. In describing the characteristics of the constructs that form the end points between which the interoperability exists, it is also equally important to determine what makes a register more complex than other forms of registers. The authors seek to determine whether a more complex register infers more complexity at the interoperability layer.
This post is an excerpt from our white paper Enabling Digital Government: Interoperability and Data Exchange Between Registries where we examine the foundational constructs of public registers, the necessity of data exchange between registers, and the evolution and modes of interoperability.
The paper investigates key developments in Canada and the EU, and outline some of the key foundational building blocks towards achieving successful register interoperability in support of our digital government agendas.
View White Paper
References
vi https://joinup.ec.europa.eu/collection/access-base-registries
vii https://gds.blog.gov.uk/2015/10/13/the-characteristics-of-a-register/
viii https://www.gov.uk/service-manual/technology/application-programming-interfaces-apis