Fiona Caryl, Technical Data Lead at the Improvement Service, discusses why person, residence and household matter for public service data sharing.
Across public services, we collect vast amounts of data about people but struggle to connect it when it matters.
Why connecting data systems is difficult
Although public services operate in different ways, they all revolve around the same basic concepts: people and the places they live. Everyone understands these ideas intuitively.
We know what a person is. We know what a residence is. We understand the idea of people living together in a household. However, inside public sector systems these concepts are often represented many times over.
Each system duplicates “person” and “address” but defines them in its own way. In doing so, they often blur the distinction between underlying entities — combining information about a person, their identifiers, and their residence into a single record. The information types may look similar (names, dates of birth, addresses), but the formats and values often differ. As a result, systems use different identifiers and data structures to represent the same underlying entities.
In other words, public services repeatedly represent the same underlying entities, people and places, but without clearly separating or structuring them consistently. The same person, and the same place, can therefore appear multiple times across systems in slightly varying ways.
Why matching records is difficult
A name, on its own, is not unique. Even the combination of name and date of birth still carries a small (but non-zero) chance of referring to more than one person. Adding address can increase uniqueness but introduces a different problem: addresses are notoriously inconsistent in how they are recorded and formatted across systems.
In practice, this means we are often trying to link records using attributes that were never designed to reliably and consistently identify someone or somewhere.
When organisations then try to share or link data, they often hit a wall because identifiers do not align. Linking records then becomes reliant on ‘fuzzy matching’ or complex reconciliation processes to determine whether two records refer to the same person (is Jim actually James?) or the same place (is Flat 3/03 Highview the same as 96 Highview?).
The challenge isn’t a lack of data — it’s that the same people and places are represented differently in every system.
A shared way to describe core entities
One way to address this is to step back and agree how we describe the core entities that appear across public services.
The SAVVI standards provide a useful starting point for thinking about this. In the SAVVI concept model, three entities sit at the centre of many public service use cases:
- Person
- Residence
- Household
A person lives at a residence, and a household is a grouping of people associated with a shared residence.
What this looks like in practice
The difference is not just in the data itself, but in how it is structured.
In many operational systems, information about a person, their identifiers, and their address is stored together in a single record. This means that the same real‑world entities, people and places, are represented multiple times across systems, rather than being defined once and reused. 
In contrast, the SAVVI model separates these concerns — defining person, residence, and their attributes as structured entities, and allowing multiple identifiers to be associated with each.
This means that a person or a place can be defined once, and then referenced consistently across different systems and services, rather than being recreated in each system.
If entities are consistently represented, services can attach their own information to them without redefining them each time. Social security can attach benefits information. Health services can attach patient information. By separating person and residence, this structure makes it much easier to link data consistently across systems.
Why identifiers matter
Identifiers provide a stable way to anchor these entities across systems. In Scotland and the wider UK, we already have important building blocks in place:
- UPRN (Unique Property Reference Number) provides a unique identifier for properties and residences.
- UCRN (Unique Citizen Reference Number) provides a unique identifier for individuals within Scotland. It is created from the NHS Central Register and is used to support population-level linkage across services.
- CHI (Community Health Index) provides a unique identifier for individuals within NHS Scotland.
- NINO (National Insurance Number) provides a unique identifier for individuals interacting with DWP and HMRC systems.
These identifiers are used within different domains, but they all share an important characteristic: they are designed to uniquely and persistently identify the same person or place over time.
They are typically used within those domains, rather than across them, even though they provide a strong foundation for linking data more widely. (UCRN is a notable exception, having been designed to support linkage across organisations.)
The challenge is therefore not the absence of identifiers — it is that they are used separately within different systems , and are underused as a means of interoperating between them.
This model not only supports reliable linkage, but also enables additional insights to be derived from the relationships between entities. Households, for example, can be derived directly from the relationship between people and residences — by identifying all individuals linked to the same UPRN. This allows collective characteristics of people to be associated with a residence. For example, “family with three children” or “person with disability living alone”.
This shift is already visible in practice. For example, UK Government guidance highlights the use of UPRNs to improve data linkage across services, particularly where address matching has historically been unreliable. There are also increasing uses of UPRN within health and research contexts to support more accurate linkage to place.
Not all identifiers are equal
It is important to distinguish between different types of identifiers. Some identifiers are descriptive, such as name, address, or date of birth. These can help describe a person or place, but they are not guaranteed to be unique, can vary in format, and may change over time.
Others are designed to be unique and persistent — such as UPRN, UCRN, CHI, or NINO — and are intended to consistently represent the same entity over time. This distinction matters because it directly affects how reliably data can be linked. 
When we rely on descriptive information like names and addresses, we often need to use probabilistic matching — comparing multiple fields and estimating whether two records are likely to refer to the same entity. This can be complex to implement and rarely produces perfect results.
In contrast, unique identifiers enable deterministic matching — a simple and reliable way to link records based on an exact match.
In practice, this is also technically simpler. Deterministic matching can often be done with straightforward tools such as lookup functions in spreadsheets, whereas probabilistic matching typically requires more advanced tools or programming approaches.
This shift from probabilistic to deterministic matching is a key part of making data sharing more reliable and scalable — reducing ambiguity, simplifying implementation, and increasing confidence in the results.
By focusing on shared entities such as person, residence, and household, and using appropriate identifiers to anchor them, we can create a clearer structural foundation for public service data.
This blog has focused on foundational concepts behind this approach. A follow-up post will explore how to apply these ideas in practice, including where organisations can start and how existing tools and identifiers can support incremental change.