Guidance

Data Models for Vulnerability

Updated 8 July 2026

1. About 

This document proposes a Concept Model and a Logical Data Model, to find and support people who may be at risk of a vulnerability.  

The models are designed to 

• facilitate multi-agency data sharing and collaboration 

• promote a componentised and reusable component architecture 

• support lawful, ethical, and transparent use of data 

This revision of the document presents the models as baselined at version 1.0.0. 

The models have been conceived by the SAVVI programme, and scrutinised and refined by the Data Standards Authority Vulnerability Working Group; both are explained later in the document. 

2. Vulnerability defined  

Public services increasingly recognise the importance of prevention; identifying people and households at risk early, and coordinating support before problems escalate. 

However, services often operate in silos. Data is fragmented across organisations, legal interpretations vary, and local innovation is difficult to scale. As a result, people can fall through gaps between services, and prevention efforts are inconsistent. 

The Concept Model defines Vulnerability as the increased risk of a poor outcome.  

This might include: 

• experiencing financial hardship 
• being unsafe during adverse weather such as a flood 
• a child not being ready to start school 
• being economically inactive 
• becoming homeless 

These models are designed to facilitate early identification and smarter intervention by:

• finding people who we otherwise don’t know about, who may be at risk of a vulnerability 
• assessing needs 
• referring to support services 
• reporting on outcomes and impact 

3. The DSA Vulnerability Working Group 

The Data Standards Authority (DSA) has established the Vulnerability Working Group, as a cross government group, to bring forward 

• data standards 
• terminologies 
• information governance and trust 

to encourage a framework for interoperability across organisations taking part in a Vulnerability initiative.  

The working group has reviewed various examples of vulnerability initiatives, and taken the outputs of the SAVVI programme as a starting point. As the group has improved and refined the SAVVI work, the SAVVI programme has folded them back into its outputs. 

With the proposed Data Standards now baselined at version 1.0.0, the working group will continue to develop them as it learns from testing and prototyping. The Government Digital Service encourages representation from across the UK public sector to participate.

4. The SAVVI Programme  

SAVVI is a framework to enable early identification and smarter interventions, for vulnerable people.  

SAVVI, standing for ‘a Scalable Approach to Vulnerability via Interoperability’, is a programme hosted by Tameside Council, developed by iStandUK, and funded by the Ministry of Housing, Communities and Local Government (MHCLG) Local Digital Fund.  

SAVVI provides a practical framework to enable organisations to 

• identify people and households at increased risk of poor outcomes 
• share and reuse existing data lawfully, ethically and transparently 
• coordinate support across organisational boundaries 
• avoid building single-use systems for each new priority 

 The SAVVI website has 

• a five minute video on the home page 
• case studies of examples of Vulnerability 
• the models laid out in this document  

5. Sharing data for Vulnerability  

Often, no single organisation has all the data that could indicate the risk of a vulnerability, and no single organisation has all the support offers that are relevant; so tackling a vulnerability requires multi-agency data sharing and collaboration. In particular:

• matching up risk factors derived from across disparate organisations and datasets 
• creating prioritised cohorts of people who may be at risk 
• assessing needs and referring to a collection of support services 
• consistent cross organisational reporting on outcomes  Privacy and security need to be built in so that 
• only sufficient information is shared at each stage 
• data sharing is lawful and ethical 
• data handling is secure and accountable  

6. A common repeatable process  

The data models have been designed to enable data to flow around a common process that can be applied to any vulnerability.  

View the the phases of the SAVVI Playbook.

• Define the scope, legal remit and outcomes 
• Find people who may be at risk using data 
• Assess their needs and circumstances 
• Support people by addressing unmet needs 
• Report progress through dashboards and outcome frameworks 
• Improve results by reviewing data  

7. Modelling  

The proposed data models are developed at three levels. 

 1. Concept Model: identifying Concepts and how they can be linked. Giving each a precise definition to establish a consistent language

1. Logical Model: defining data entities and structures as a ‘menu’ for transacting data

2. Physical Model: defining data sharing formats tuned to particular use cases

8. The Concept Model

View the entire Concept Model in Digital Service Designer

This document presents the Concepts from the Concept Model as they are introduced at each phase of the SAVVI Process, and then, shows the whole model.  These views of the Concept Model are also shown at the SAVVI website together with various machine readable formats including

• RDF Schema (RDFS)
• comma separated values (CSV)

8.1 The Purpose phase

View the Purpose phase in Digital Service Designer

• a lead organisation will establish that it has a purpose that gives it a remit to act on one or more vulnerabilities

• where the purpose gives the basis for data sharing and data reuse throughout the initiative

• some metrics may be used as statistics to demonstrate that each type of vulnerability is an imperative, and which could subsequently be used to track the impact of the whole initiative

• will set out types of unmet needs, which, if addressed by smart interventions, could lead to improved outcome

Concepts introduced in the Purpose phase

Term	Definition
Lead organisation	An organisation responsible for coordinating a vulnerability initiative, and with remit for the purpose
Metric	A statistic that evidences the imperative for a vulnerability to be addressed
Need	An unmet requirement of a person or household that can be addressed
Outcome	A result that has been achieved by addressing the needs of a person or household
Purpose	The remit that an organisation has to carry out an initiative covering one or more vulnerabilities
Vulnerability	The increased risk of a poor outcome

8.2 The Find phase

View the Find phase in Digital Service Designer.

• a vulnerability initiative will establish a risk model for a vulnerability

• which sets out the rules by which risk factors will be used

• to generate and prioritise a cohort

• of persons or households

• with potential needs

Concepts introduced in the Find phase

Term	Definition
Cohort	An initial prioritised list of people and households that may have a risk of a vulnerability
Household	A collection of persons who live together at the same residence
Person	An individual who may be vulnerable
Residence	A home of a person
Risk factor	A single fact about a person or household that can be combined with others to categorise the risk of a vulnerability, and predict needs
Risk model	The rules by which risk factors will be used to prioritise vulnerability risk and predict needs

8.3 The Assess phase

View the Assess phase in Digital Service Designer.

In the Assess phase

• a responsible organisation may choose to raise a case about a person or household, for example, if
  • they appear in a cohort
  • they present themselves as vulnerable
  • they are referred by another organisation or professional

• an assessment will capture new circumstance information and identify one or more needs

• each need can then have a referral to a service

• offered by a delivery organisation

Concepts introduced in the Assess phase

Term	Definition
Assessment	An understanding of needs and circumstances
Case	A container for information recording the history of events for a person or household who may have needs
Referral	A decision to direct a need to a support service
Responsible organisation	An organisation who is made responsible for a case
Service	The ability for a delivery organisation to carry out one or more predetermined methods designed to deliver an outcome

8.4 The Support phase

View the Support phase in Digital Service Designer.

In the Support phase:

• a need may have a referral
• to a service provided by a delivery organisation
• which may:
  • create a plan
  • record individual actions
• which can be recorded on the case
• each need will reach an outcome which may have been achieved via a referral

Concepts introduced in the Support phase

Term	Definition
Action	An action that has been carried out as a part of responding to a need
Delivery Organisation	A service provider who delivers actions that respond to a need
Plan	A set of planned actions designed to respond to a need over a period

8.5 The Report phase

View the Report phase in Digital Service Designer.

In the Report phase

• a dashboard can be created that can report on caseload information such as:
  • how many items are in a cohort
  • how many cases have had an assessment
  • how many of each type of unmet need have been found
  • how many referrals have been made to each service
  • what outcomes have been achieved
• the report can be split by place of the residence of households
• when limited to a time period, this information can produce an Outcomes Framework

Concepts introduced in the Report phase

Term	Definition
Place	A geographic area

8.6 The Improve phase

View the Improve phase in Digital Service Designer.

In the Improve phase

• having used data to find and support vulnerable people
• there is an opportunity to review anonymised case data
• to create insights as to how the process could be improved
• in particular, improvements could be made to:
  • the rules and weightings in the risk model
  • the use, and data quality of risk factors
  • prediction of needs
  • the referrals of needs to services that lead to good outcomes

Concepts introduced in the Improve phase

No new concepts are introduced for the Improve phase, as this is about analysing data already collected during the operation of the process.

Term	Definition
Action	An action that has been carried out as a part of responding to a need
Assessment	An understanding of needs and circumstances
Case	A container for information established to manage one or more needs for a person or household, through which events, evidence, activities, and decisions are recorded and tracked over time in order to achieve an intended outcome
Cohort	An initial prioritised list of people and households that may have a risk of a vulnerability
Contact event	A record of an event in which the situation of a person or household was sought
Delivery organisation	A service provider who delivers actions that respond to a need
Household	A collection of persons who live together at the same residence
Lead organisation	An organisation responsible for coordinating a vulnerability initiative, and with remit for the purpose
Metric	A statistic that evidences the imperative for a vulnerability to be addressed
Need	An unmet requirement of a person or household that can be addressed
Outcome	A result that has been achieved by addressing the needs of a person or household
Person	An individual who may be vulnerable
Plan	A set of planned actions designed to respond to a need over a period
Purpose	The remit that an organisation has to carry out an initiative covering one or more vulnerabilities
Referral	A decision to direct a need to a support service
Residence	A home of a person
Responsible organisation	An organisation who is made responsible for a case
Risk factor	A single fact about a person or household that can be combined with others to categorise the risk of a vulnerability, and predict needs
Risk model	The rules by which risk factors will be used to prioritise vulnerability risk, and predict needs
Service	The ability for a delivery organisation to carry out one or more predetermined methods designed to deliver an outcome
Vulnerability	The increased risk of a poor outcome

9. Reference Data, Masterdata and Catalogues

View the Reference Data, Masterdata and Catalogues in Digital Service Designer.

Some of the Concepts indicate a further requirement for

• Terminology: a controlled and shared set of terms and definitions used to ensure consistent understanding and interpretation of concepts across organisations, systems, and services
• Master Data: authoritative core data describing key entities such as people, organisations, or places that is shared and reused across multiple systems
• Catalogues: a structured listing of available resources, such as services or data sources, published so they can be discovered and used

10. Use cases for interoperability

The SAVVI Process suggests various opportunities where data could be exchanged

• between technology components or platforms

• over organisational boundaries

• Access to risk factor data: pulling risk factor data from a data product, for a specified purpose to build a cohort of persons or households who may be at risk of a vulnerability
• Discovering support services: matching assessed needs to look up a shared directory of services
• Making referrals: referring a need to a service, and tracking outcomes
• Shared casework: a single view of a case built from disparate referrals, plans and actions
• Reporting to a shared dashboard: collecting referrals and outcomes data from partners to monitor cohorts and cases

These opportunities have influenced the design of the Logical Model.

11. The Logical Model

View the entire Logical Model at Digital Service Designer.

This document presents the whole Logical Model, and then shows each Entity in detail. These views of the Logical Model are also shown at the SAVVI website together with various machine readable formats including

• RDF Schema (RDFS)
• XML Schema (XSD)
• comma separated values (CSV)

The Logical Model

• is a menu to derive interchange formats for Interoperability
• has no new ideas - these implement the Concept Model
• is not intended for data at rest
• is designed to be extensible, avoiding hard-coded fields for particular vulnerabilities, so that new risk factors, needs, identifier schemes, and so on, can be added without changing the core model

Each Entity in the model is further defined in Appendix B - Entity Definitions.

Domain expert groups

In parallel to this Vulnerability work, the Data Standards Authority (DSA) is also running ‘expert groups’ to look at some entities that commonly occur in shared data, to propose a common data structure to be applied consistently across public sector data.

The Vulnerability Logical Model will adopt those structures as they are issued.

12. Appendix

12.1 Appendix A - common structures

Some data structures are used repeatedly across the Logical Model.

Type

The Type structure records a Term as the type of an Entity. For example

• Risk Factor: Court Action
• Need: Family Counselling

As a minimum, a Term should be provided. Better is to provide a Term within a shared Scheme (Terminology), and best is to provide a URI which can be dereferenced to give a precise definition of the Term.

Attribute		Data Type	Structure	occurs	required
Scheme	To define the scheme that the type is taken from. e.g. ‘LG Inform Circumstance List’	lookup		once
Term	A term that represents a type, eg ‘unemployed’.  Where a scheme has been defined, this should be a term from that scheme.	line		once	yes
URI?	A persistent identifier for the Term. This should be an HTTP Resolvable Identifier - see Persistent resolvable identifiers - GOV.UK (www.gov.uk)	yes/no		once

Identifier

The Identifier structure records an identifier from a scheme.  For example,

• unique pupil number:A123456789001A
• UPRN: 100021064336

Entities often have an array of Identifiers, so that many can be recorded.

Attribute		Data Type	Structure	occurs	required
Scheme	The name of a controlled set of identifiers	lookup		once
Reference	A reference to uniquely identify a thing	line		once	yes
Pseudonymised?	To indicate that the reference is pseudonymised	yes/no		once

Coordinates

Attribute	Description	Data Type	Structure / Terminology	Occurs	Required
Latitude	The latitude of a position expressed using the WGS84 datum.	number		once	yes
Longitude	The longitude of a position expressed using the WGS84 datum.	number		once	yes

12.2 Appendix B - entity definitions

Action

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Type	The type of action, eg food parcel or debt advice		Type	once
Date	The date of the Action.	date		once	yes
Description	A description of the Action.	text		once

Assessment

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Situation	A record of the situation to be assessed.	text		once
Findings	A judgement of the Needs arising from the Situation.	text		once
Date	The date of the Assessment	date		once

Attribute

Implements the ‘Risk Factor’ concept.

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Type	To describe the Attribute. e.g. In receipt of Universal Credit, Living Alone.		Type	once	yes
Set	To indicate if the presence of the Attribute is true or false.	yes/no		once	yes
Value	An optional value associated with an Attribute, e.g. if the Type is ‘%
attendance’, the Value may be 60.	line		once	no
DateFrom	The date from which the Attribute is true.	date		once
DateTo	The date from which the Attribute may no longer be true, or is expected to end.	date		once

Case

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Reference	The Case Reference.	line		once	yes
Status		lookup	Case Statuses	once
Date Raised	The date that the Case was started.	date		once
Date Closed	The date that the Case was closed.	date		once
Case Outcome			Case Outcome	once

Structures

Case Outcomes

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Code		lookup		once	yes
Description		text		once

Contact Event

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Date	The date of the contact.	date		once
Person	The name of the contacted person	line		once
Role	The role of the contacted person eg - Vulnerable Person - Friend - Relative - Public - Professional - Community Group - Elected Representative	lookup		once
Method	The method used to make the contact eg - phone - home visit - digital	lookup		once
Contact Direction	To indicate who initiated the contact.	lookup	Contact Directions	once
Notes	Notes of the Contact Event	text		once

Household

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Identifier			Identifier	many
FromDate	A date from which the Household is known to be formed.	date		once
ToDate	A date after which the Household may not be formed.	date		once

Need

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Type			Type	once	yes
Rationale	The reasoning for the Need.	text		once
Date	The date that the Need is established.	date		once
End Date	The date that the Need was resolved.	date		once
Target Date	The date that the Need should be resolved by, for it to be effective.	date		once

Organisation

Implements the ‘Lead Organisation’, ‘Responsible Organisation’ and ‘Delivery Organisation’ concepts.

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Name		line		once	yes
Department		line		once
Contact Person		line		once
Contact Point			Contact Point	many
Identifier	Reference by which the organisation is known, eg - GDS Register of Local Authorities - Companies House Number - Charity Number		Identifier	many

Structures

Contact point

Name	Description	Data Type	Structure / Terminology	Occurs	Required
System	Telecommunications form for contact point	lookup	Contact System Types	once
value		line

Outcome

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Type			Type	once	yes
Description	A description of the Outcome.	text		once
Date	The date that the Outcome was achieved.	date		once

Person

A common data specification to represent a PERSON is currently being developed by a DSA Domain Expert Group.  The Vulnerability Logical Model will take on data structures from that work when it is available.

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Name	The official name of a person.		Person Name	once
BirthDate	The date that a person was born.		Birth Date	once
RegisteredSex	The sex recorded for a person in an official civil registration or legal record, such as the sex recorded at birth. Use an agreed code list such as Codesystem-administrative-gender - FHIR v5.0.0	lookup		once	no
Gender	A social category for the sex that a person self-presents as. Use an agreed code list such as Codesystem-administrative-gender - FHIR v5.0.0	lookup		once	no
Identifier	References by which a person is known, in various schemes. eg NiNo, Health
Number, a local reference.		Identifier	many
PreviousName	Names that a person has previously been known as.		Person Name	many	no
Alias	An assumed or additional name that a Person sometimes uses, or a shortened diminutive version of a name, e.g. Betty, Smithy, by which a Person is generally known by family and friends, or to a Service.	line		many

Structures

Person name

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Title		line		once
Family Name		line		once
Given Name		line		many
Unstructured Name	A rendition of the name that does not attempt to indicate meaning of the parts in the name. e.g. Mr Bert Smith.	line		once

Birth date

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Date		date		once
Estimated	To indicate that the date is an estimate.  If false, or absent, then the date is not at estimate.	yes/no		once	no

Place

Can mean

• a one-of polygon
• a street
• a neighbourhood
• an existing statistical or administrative geography

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Name	The name of the Place	line		once	yes
Extent	A geographic shape expressed using an established data standard such as - the OGC Well-Known Text (WKT) geometry format (POLYGON) - GeoJSON	line		once	no
Identifier			Identifier	once	no

Plan

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Start Date	The date that the plan starts from.	date		once
End Date	The date when the plan has ended, or is expected to end.	date		once
Description	A description of the plan.	text		once
Activity Type	The Activities that the Plan includes.		Type	many

Referral

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Date	The date that a decision was made to make the referral.	date		once	yes
End Date	The date that the referral ended.	date		once
Type	- direct - recommended - signposted	lookup		once	yes
Service Reference	The reference assigned by the Service	line		once

Residence

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Address			Property Address	once
Characteristic	Information about the residence such as the number or bedrooms, condition.		Characteristic	many
Identifier	Properties are known by Identifiers such as the UPRN from GeoPlace.		Identifier	many
Map Pin			Coordinate	once

Structures

Property address

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Line		line		many
Postcode		line		once

Characteristics

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Type	The Type of the Characteristic.		Type	once	yes
Value	An optional value that quantifies the Characteristic. e.g. if the Type is ‘number of bedrooms’, the Value may be 3. Many Types will not need a value.	line		once	no
Date From	The date from which the Characteristic is true.	date		once	no
Date To	The date from which the Characteristic may no longer be true, or is expected to end.	date		once	no

Service

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Name	The name of the Service.	line		once	yes
Identifier	An Identifier that can be looked up, to provide more information about the Service, such as contact information, eligibility, opening times and so on.		Identifier	once
Type	A categorisation of the type of Service		Type	many
URL	A URL to a web page to give more information about a Service	line		once

Vulnerability

Name	Description	Data Type	Structure / Terminology	Occurs	Required
Type			Type	once	yes
Risk Category			Type	many

12.3 Appendix C - data types

Data Type	can contain	xsd data type
line	A single line of text without line breaks, typically used for names, titles, or short labels.	xsd:string
text	A block of plain text that may contain line breaks but no formatting.	xsd:string
markdown	A block of text that may include Markdown formatting for headings, lists, links, and emphasis.	xsd:string
number	A numeric value that may include decimal places.	xsd:decimal
integer	A numeric value that must not include decimal places.	xsd:integer
currency	A monetary value expressed as a decimal number, typically with two fractional digits.	xsd:decimal
date	A calendar date without a time component.	xsd:date
time	A time of day including hours and minutes, optionally including seconds and milliseconds.	xsd:time
datetime	A specific date and time, typically representing when an event occurred.	xsd:dateTime
timestamp	A precise date and time value typically used for system recording or audit purposes.	xsd:dateTime
URI	A Uniform Resource Identifier that uniquely identifies a resource using a valid URI scheme.	xsd:anyURI
URL	A web address that identifies a resource accessible via the web and includes a protocol such as http or https.	xsd:anyURI
URN	A Uniform Resource Name that uniquely identifies a resource using a URN scheme.	xsd:anyURI
yes/no	A logical value indicating true or false.	xsd:boolean
lookup	A coded value whose meaning is defined by a controlled list.	xsd:string