The Process

Purpose

Where a
@Lead Organisation
sets out to find and support people with a particular vulnerability.

Getting Started

The Lead Organisation

The SAVVI Process starts when an organisation decides to take the lead in finding people or households with a vulnerability, so that they can be offered support. We call this the
@Lead Organisation
as they will have to take decisions about how the process will run, and coordinate how partner organisations will share intelligence and provide support.

Setting a Purpose

The Lead Organisation will need to be precise about the vulnerabilities that it is looking to address; this is the SAVVI
@Purpose
. Many of the
@Information Governance
arrangements that cover data sharing and re-use, will rely on this definition.
@Source Organisations
, who control access to data, will expect a clear undertaking about how and why their data is to be used before they are likely to share it.

SAVVI has initially looked at purposes of
access to services during a lock-down (COVID19)
homelessness prevention
... and we intend to explore other purposes such as
poverty/debt
unemployment
criminality/imprisonment
loneliness/social isolation
child taken into care
domestic violence
mental health illness

A
@Purpose
will have a title and one or two paragraphs as a description. Some
@Purposes
have a definition based in law, in which case it can be helpful to refer to a section of an Act.

SAVVI is building a
, and how various
@Lead organisations
have gone about addressing them.

Defining a Risk Stratification Policy

The
@Risk Stratification Policy
is where the
@Lead Organisation
lays out the purpose of the initiative, and the
@Risk Categories
that it will use to decide if and how a
@Person
or
@Household
should be contacted, to find out what support they might need. SAVVI has
.

This need not be a long document. It should capture the key points listed below. For transparency, we recommend that the document is published.

Purpose

The definition of the
@Purpose
.

Jurisdiction

The geographic area that the initiative covers. This is typically the area covered by a Local Authority.

See defining geographic areas for advice on reference schemes that list geographic areas.

Risk Categories

The
@Lead Organisation
will attempt to find people or households at risk by analyzing what we know about them, and grouping them by
@Risk Category
which will determine how how they will be contacted to understand their actual needs.

We have seen
@Risk Categories
such as Red/Amber/Green, or perhaps there is only one category so that people are considered to be either, at risk, or not.

Categories might also group people by other factors such as family type, or locality.

Vulnerability Attributes

The Lead Organisation will want to collect data about people or households from various
@Source Organisations
. Even where the data is held by the
@Lead Organisation
itself, it should treat themselves as if the data was being requested externally. Examples of
@Vulnerability Attributes
might include
living alone
in receipt of a disability award
a current case with Social Services
moved house.

For data minimisation purposes, only the presence of the attribute is required.

SAVVI allows four types of
@Vulnerability Attribute
, namely
circumstance
event
service
risk

See the
for examples of the vulnerability attributes that have been used, against a defined, specific purpose.

Data Sources

For each
@Vulnerability Attribute
, there needs to be at least one
@Source Organisation
, who has the data.

The
lists the typical types of organisations that have certain attributes and the service they provide that allows them to collect that data.

At this stage, the
@Risk Stratification Policy
need only record if the data sharing is in place. Each data share will need agreements, security, data formats, and so on, which we will come on to.

Algorithms

A description of the rules that will be applied to the
@Vulnerability Attributes
to place a person or household into each
@Risk Category
.

Requesting Data from Source Organisations.


Data Sharing Request

The
@Lead Organisation
will request data from each
. Some considerations at this stage include
@Information Governance
- e.g. is there a legal basis for sharing the information and is the
@Source Organisation
happy about how their data will be handled?
Data Quality - e.g. how up-to-date, accurate, complete is the data?
.
Format - e.g. can the data be made available in a format that the Lead Organisation can use.


The request should cover the key points listed below. If the request is accepted, this information will be the basis of various
@Information Governance
steps.

Purpose

The purpose that the data will be used for. This will already have been established in the
step.

The Requested Data

The data will include information about
a
@Person
and/or a
@Household
.
one or more
@Vulnerability Attribute
/s - as listed in the
@Risk Stratification Policy
step.
the
@Provenance
of the data such as when it was extracted and from which system.

The data items that could be requested are described in the SAVVI Standards. See Defining the Data to be Requested.

Pseudonymised?

To indicate if a pseudonymised version of the data is required and the arrangements to achieve that.

Pseudonymisation is discussed in the
part of the SAVVI Process.

Periodicity

The
@Lead Organisation
can specify how often they would like the data to be refreshed. This may be
a one-off request
a regular snapshot
refresh on demand
streaming access to near-real-time information

Legal Basis

The legal basis that the
@Lead Organisation
proposes is relevant to the nature of the data, and the purpose of the vulnerability initiative.

See Defining the Legal Basis for Data Sharing.

The
has examples where a Legal Basis has been proposed to access certain vulnerability attributes for a purpose.

Data Format

The
@Lead Organisation
will prefer to receive information from many
@Source Organisations
in the same, or similar, format, to reduce the amount of transformation necessary and to ease data matching.

Data Formats will be based on the
. SAVVI has

Safeguards

The
@Lead Organisation
can propose the safeguards that they intend to put in place to protect the data, such as where it will be stored, how access will be controlled and monitored, when data will be destroyed.

However, these are points for negotiation and will be determined by the
@Source Organisation
as a part of a later data sharing agreement. There may already be an overarching data sharing agreement that sets behaviours and mechanisms for specifying controls.

Pseudonymisation

@Vulnerability Attributes
are
, and may require further protection if they contain sensitive information such as health conditions or criminality.

A
@Source Organisations
may only allow their data to be shared where a vulnerability has already been established.

@Pseudonymisation
is a technique that allows a
@Source Organisation
to send attributes that cannot be linked to a person or household, but CAN be matched to other data from other sources, about the same household.

A first pass to put pseudonymised households into
@Risk Categories
can then be done. This tells the
@Lead Organisation
that there are vulnerable households, but does not reveal names or addresses. The
@Lead Organisation
can subsequently ask the
@Source Organisation
to provide person-identifiable data for the selected households, by passing back the pseudonymised identifier for the
@Household
.

This is an optional step in the SAVVI
, but may help to get access to data that would otherwise be denied.

Information Governance

Before the
@Lead Organisation
handles information provided by the
@Source Organisation
(even when they are both the same organisation ) , there are some routine Information Governance steps to complete.

The
@Lead Organisation
and
@Source Organisation
s should
publish a

Although these are not different to any other data sharing scenario, SAVVI has some advice about the steps to take, and points to guidance from authoritative sources such as the Information Commissioners Office (ICO).




Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.