.
Efficiency and Transformational Government Division
Crown Copyright eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 1

Efficiency and Transformational Government Division
1.1
1.2
1.3
2.1
2.2
2.3
2.3.1
2.3.2
Purpose
Glossary
References
Purpose of PIA
Privacy and Scottish Government Principles
Approach
Objectives and rationale
Constraints and issues
3.1
3.1.1
3.1.2
3.2
3.2.1
3.2.2
3.3
3.3.1
3.3.2
3.3.3
3.4
3.5
Getting it Right For Every Child Policy
Overview
Core components
The eCare framework
Background
Current position
The inter-Agency Communication Tool (iACT) eCare iACT Requirements
The iACT solution
Alternatives to iACT considered
Stakeholder groups
Benefits
4.1
Data sharing eCare / GIRFEC iACT PIA
Page 2
Version 1.0 Release
17/11/2010
20
13
13
13
14
11
11
12
14
15
16
17
18
9
10
9
10
10
5
7
5

4.4.2.2
4.4.2.3
4.4.2.4
4.4.2.5
4.4.2.6
4.4.2.7
4.4.2.8
4.4.3
Efficiency and Transformational Government Division
4.1.1
Scope and purpose
4.1.2
4.1.3
4.2
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.4
4.4.1
4.4.2
4.4.2.1
Legal basis
Consent
Stakeholder privacy concerns
Information analysis eCare iACT overview iACT information types
Process overview
GIRFEC and national roles and processes
Privacy risk and issues
Introduction
Privacy risk groups 30
Risk that child or families concerns about data sharing may impact
27
29
30
30
23
25
25
26
20
21
22 on their relationship with practitioners
Risk that information is shared with the wrong people
30
30
Risk of inappropriate disclosure of information
Risk that information is accessed inappropriately
Risk of ‘administrative’ staff (system administrator or other non
31
31 professional staff handling data) accessing too much information 32
Risk that information is shared about the wrong person
Risk that information disclosed by one agency is retained or
32 managed inappropriately by others 32
Risk of inappropriate management of personal data through lack of clarity about the interaction between iACT and agency systems 33
Privacy issues and concerns 33
5.1
Introduction eCare / GIRFEC iACT PIA
Page 3
Version 1.0 Release
17/11/2010
34

Efficiency and Transformational Government Division
5.2
Detailed mapping of risks and issues to current and planned controls35
6.1
6.2
Summary and appraisal of current position
Recommendations
46
47
eCare / GIRFEC iACT PIA
Page 4
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
This Report summarise the results of a Privacy Impact Assessment on the Scottish
Government eCare iACT application, which enhances the existing eCare data sharing
Framework with targeted messaging capabilities, to support the data sharing requirements of the Getting It Right For Every Child (GIRFEC) policy.
Privacy Impact Assessment is a cyclical process, and this PIA report may be updated at significant points in the development and implementation of the eCare iACT solution, which is progressing in parallel to the development of the GIRFEC practice model, and following further consultation and engagement activity.
Term
CESG
CLAS
Explanation
Adapter Technology interface solution to enable an application to communicate with the eCare Framework.
Child Protection Messaging (CPM) An eCare service, which enables systems with an index entry for a child to receive alerts relating to formal child protection status
CESG the Information Assurance (IA) arm of GCHQ
Data Sharing Partnership (DSP)
CESG Listed Adviser Scheme - a partnership linking the unique Information Assurance knowledge of CESG with the expertise and resources of the private sector.
A group of local agencies that share data via a single Multi-
Agency Store (MAS – see below) and that share in the governance of that MAS. DSP areas are currently coterminous with the 14 Health Board areas. eCare eCare Index eCare Multi-Agency Store (MAS) the Scottish Government's multi-agency information sharing framework which covers, amongst other aspects, consent, standards, security, procurement, organisational development and technical issues relating to the electronic sharing of personal data
The eCare Index provides a cross-reference between the person identifiers used by different systems.
Multi Agency Store
The shared database which holds eCare person records, to eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 5

Efficiency and Transformational Government Division which eCare partners contribute data. Currently, there are 14
MASs, one for each Data Sharing Partnership.
GIRFEC Getting it right for every child is a programme that aims to improve outcomes for all children and young people.
It promotes a shared approach that:
 builds solutions with and around children and families
 enables children to get the help they need when they need it
 supports a positive shift in culture, systems and practice
 involves working together to make things better iACT iACT Instance
ICO
Matching
PIA
Point to Point / P2P
Web Service (W/S)
Working name for the web application component of the new eCare functionality being developed to support GIRFEC
A copy of iACT that is owned and managed by an organisation or data controller
Information Commissioner’s Office
The UK's independent authority set up to promote access to official information and to protect personal information.
A process through which a person is uniquely identified across the different systems that connect to the eCare
Framework
A process whereby a project's potential privacy issues and risks are identified and examined from the perspectives of all stakeholders and a search is undertaken for ways to minimise privacy concerns. eCare Framework service which allows messages to be targeted to specific agencies, business functions or services connected to eCare.
Software application that makes some or all of its functionality available over the web eCare / GIRFEC iACT PIA
Page 6
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
8
9
10
11
12
6
7
Ref
1
2
3
4
Title
PIA Handbook
Privacy by Design
The Guide to Data Protection http://www.ico.gov.uk/for_organisatio ns/data_protection/the_guide.aspx
Draft Identity management and privacy principles
Authors
Information Commi ssioner’s
Office
Information Commissioner’s
Office
Information Commissioner’s
Office
Scottish Government
5 Initial PIA consultation draft Scottish Government
Getting It Right For Every Child web site
A Guide to Implementing Getting it right for every child: Messages from pathfinders and learning partners http://www.scotland.gov.uk/Publicatio ns/2010/07/19145422/0 eCare website
Scottish Government
Scottish Government eCare Interim Records Management guidance - eCare Multi-Agency Store
(MAS)
Scottish Government http://www.scotland.gov.uk/Topics/G overnment/PublicServiceReform/effic ientgovernment/DataStandardsAnde
Care/irmguidance iACT Outline Business case Scottish Government eCare iACT Baseline Business
Scoping Statement iACT GIRFEC High-level
Architecture Guidance Note
Scottish Government
Scottish Government
0.4
1.1
2.0
Version
2
Date
2009
Nov
2008
Apr
2010
Sep
2009
Dec
2009
Jun
2010
1.0 Jan
2010
Sep
2010
Jun
2010
Nov
2010 eCare / GIRFEC iACT PIA
Page 7
Version 1.0 Release
17/11/2010

19
20
21
Efficiency and Transformational Government Division
13
14
15
16 eCare Programme Gold Standard
Information Sharing Protocol
[This is part of the eCare
Implementation Toolkit
Version 2.0 Feb 2010]
Scottish Government
Data Sharing: Legal Guidance for the
Scottish Public Sector
Scottish Executive
Scottish Executive Legal Framework: Report to the
Scottish Executive Children’s
Hearing Review iACT Scenarios 1-11 Scottish Government
17
18 iACT Functional Specification Scottish Government
Extract from HMG IA Standard No. 1
Business Impact Level tables eCare - iACT Business Impact
Assessment
Terms of Reference for eCare – iACT Accreditation Panel eCare Hub Data Model http://www.scotland.gov.uk/Topics/G overnment/PublicServiceReform/effic ientgovernment/DataStandardsAnde
Care/Hub
Cabinet Office
Scottish Government
Sopra Group
Scottish Government
2004
Sep
2005
1b Draft Sep
2010
2.0 Sep
2010
3.5 Oct
2009
1.0
1.01
1.0
Sep
2010
Sep
2010
Mar
2008 eCare / GIRFEC iACT PIA
Page 8
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
In our today ’s society, large quantities of personal data are routinely shared between agencies and there is an increasing use of surveillance technology, such as CCTV. These trends, coupled with high-profile data losses across the public sector have the potential to threaten individual’s privacy  and damage their trust in the agencies which use personal data and/or communications technologies to deliver services.
Privacy Impact Assessment (PIA) is a vehicle for assessing and managing privacy risks and issues arising from a project or scheme involved in data sharing or use of communications technology, and communicating these with data subjects and other stakeholders , to determine the business justification for privacy intrusion / data sharing; assess the acceptability of the project, provide assurance and support transparency and trust. The Information Commissioner’s Office, as the public body chiefly concerned with Data
Protection and information privacy, has produced guidance on the use of PIA , which draws on previous experience in UK and countries with similar approaches to privacy, such as
Canada and Australia and on ‘Privacy by design’ in relation to ICT systems.
A PIA may vary in scale and scope, depending on the nature of the project or scheme which it is applied to, its potential impact on privacy and the stage the project or scheme is at. For it to be valid, the PIA must be applied at a time where its findings can influence the system or project under consideration and allow privacy features to de designed in. In many cases, the
PIA will be an iterative process, with risks/issues and mitigations, stakeholder engagement and communication being replayed at key stages in the project lifecycle and the PIA report and other documentation updated and disseminated accordingly.
‘ Respect for privacy should be central to public services managing people’s identity information. I want the public to be able to trust and have confidence in Scottish public services that are not only effective and secure but also privacy-friendly .’
John Swinney MSP, Cabinet Secretary for Finance and Sustainable Growth. From ‘ Privacy and Public Confidence in Scottish Public Services:
Draft Identity Management and Privacy Principles: 2009’
In 2009 the Scottish Government consulted on its Draft Identity Management and Privacy
Principles, designed to ensure that ‘…respect for privacy is central to the way public services prove identity or entitlement and to help public service organisations comply with data protection and human rights legislation.’ It is expected that Scottish Government will produce a response to the consultation and a final version of the Principles in 2010. Although they focus on the use of personal data for the purposes of identity management, the principles are applicable to any system which manages personal data and this report uses the draft

Definitions are taken from the ICO PIA Handbook version 2 eCare / GIRFEC iACT PIA
Page 9
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
Principles as a benchmark for analysis (See Appendix K), along with Privacy concerns, risks and issues derived from analysis of similar projects and from stakeholder engagement workshops.
This PIA is being carried out as part of the eCare iACT project, which aims to provide the data sharing capabilities required to support GIRFEC policy objectives of early intervention and better coordinated services for children and families. The PIA has the following main aims:
1. To work with the GIRFEC Team and key GIRFEC stakeholders to identify key privacy risks, issues and concerns in relation to the use of eCare iACT for multi-agency data sharing in support of GIRFEC
2. To assess the balance between benefits delivered through data sharing with eCare iACT and stakeholder privacy concerns
3. To identify and document current features within the eCare iACT system design that address specific concerns and make recommendations on additional system design enhancements, data sharing procedures and processes and compliance activity required
4. To enable the eCare Programme to carry out appropriate activities, including further
PIA iterations, which will ensure that data sharing using eCare iACT can deliver the positive outcomes expected, while maintaining stakeholder confidence and trust through effective communication around privacy issues and good practice in data handling.
This report represents a second iteration of the eCare iACT PIA. The first iteration, based on version 1, of the ICO handbook produced a technically focussed document, which was restructured to support further communication and engagement with stakeholder groups, through workshops and via email. An outline of the PIA process to date is presented in
Appendix A. The privacy workshop engagement sessions with practitioners and representatives from third sector organisations, were productive in enabling risks, issues and mitigations to be discussed. Email consultation proved ineffective and had a very low response.
Resource constraints and challenges around direct engagement with children mean that the data subjects themselves have not been engaged with the PIA process to date. This is being taken forward by the eCare and GIRFEC programmes and will be addressed in the
Recommendations in GIRFEC and the eCare iACT project eCare / GIRFEC iACT PIA
Page 10
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
“There is no more important task than ensuring that we get it right for
Scotland’s children and young people. That is the simple objective of Getting it right for every child, and applies to all work across children’s services, as well as adult services, which have an impact on children. Achieving that objective is a challenge especially at a time of pressure on resources and in the face of the varied needs and risks faced by Scotland’s children and young people.”
Adam Ingram Minister for Children and Early Years
From the Foreword to A Guide to Implementing Getting it right for every child
Getting it right for every child (also known as "Getting it right" or GIRFEC) is a new, national approach to supporting and working with all children and young people in Scotland. It affects all services for children and adult services where children are involved. It is based on research, evidence and best practice and designed to ensure all parents, carers and professionals work effectively together to give children and young people the best start we can and improve their life opportunities.
Getting it right places children's and young people's needs first, ensures that they are listened to and understand decisions which affect them and that they get more co-ordinated help where this is required for their well-being, health and development. It requires that all services for children and young people - social work, health, education, police, housing and voluntary organisations - adapt and streamline their systems and practices to improve how they work together to support children and young people, including strengthening information sharing.
The approach helps those facing the greatest social or health inequalities. It also encourages earlier intervention by professionals to avoid crisis situations at a later date so that children and young people get the help they need when they need it.
Getting it right aims to achieve:

Better outcomes for all children

A common, coordinated framework across all agencies that supports the delivery of appropriate, proportionate and timely help to all children as they need it

Streamlined systems and processes, efficient and effective delivery of services focussed on the needs of the child

A common understanding and shared language across all agencies

A child-centred approach

Changes in culture, systems and practice across services for children

More joined up policy development with GIRFEC in the delivery mechanism of all eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 11

Efficiency and Transformational Government Division policies for children (and policies for adults where children are involved)
Getting it right requires change across all services on three fronts:

Culture change

Systems change

Practice change
Getting it right for every child is founded on 10 core components which can be applied in any setting and in any circumstance. They are at the heart of the Getting it right for every child approach in practice and provide a benchmark from which practitioners may apply the approach to their areas of work.

A focus on improving outcomes for children, young people and their families based on a shared understanding of well-being

A common approach to gaining consent and to sharing information where appropriate

An integral role for children, young people and families in assessment, planning and intervention

A co-ordinated and unified approach to identifying concerns, assessing needs, agreeing actions and outcomes, based on the Well-being Indicators

Streamlined planning, assessment and decision-making processes that lead to the right help at the right time

Consistent high standards of co-operation, joint working and communication where more than one agency needs to be involved, locally and across Scotland

A Lead Professional to co-ordinate and monitor multi-agency activity where necessary

Maximising the skilled workforce within universal services to address needs and risks at the earliest possible time

A confident and competent workforce across all services for children, young people and their families

The capacity to share demographic, assessment, and planning information electronically within and across agency boundaries through the national eCare programme where appropriate. eCare / GIRFEC iACT PIA
Page 12
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
eCare is the name given to the Scottish Government's multi-agency information sharing framework which covers, amongst other aspects, consent, standards, security, procurement, organisational development and technical issues relating to the electronic sharing of personal data. eCare works with partners across the public and voluntary sectors in Scotland to deliver eCare in a way which improves the quality of services for the people of Scotland.
The strategic responsibilities of the eCare Programme are:

To implement a framework which enables secure sharing of sensitive personal information;

To make available to local partners the capability for Child protection Messaging
(CPM) and Single Shared Assessment (SSA,) and to allow local partners to use the infrastructure for similar agreed functions;

To support policies on SSA, Getting it right and Early Years, in line with commitments made to those policy areas;

To explore the scope for wider use of eCare, as directed by the eCare Programme
Board, for individuals who require multi-agency intervention. eCare is delivered through a network of 14 Data Sharing Partnerships (DSPs) across
Scotland
– DSPs are mapped to NHS Board geographies. Each partnership has an eCare
Multi-Agency Store (MAS) database, hosted in the Atos Origin secure data centre In
Livingston. Partner agencies, such as Social Work Education and Health share data under the conditions set out in a local Information Sharing Protocol, based on the Scottish
Government Gold Standard Information Sharing Protocol document. At present, the eCare solution does not support data sharing across DSP boundaries or on a national basis.
Data about an individual is published to the MAS from a partner agency system, following an explicit practitioner decision to disclose - consent will be sought in the in the case of SSA, whereas consent in not required for CPM. This allows participating agencies to contribute a shared record about the individual and for systems with a legitimate interest in the child to receive notifications when new individuals are added or data is changed. Further information about data sharing using eCare is set out in Appendix B
The eCare Framework currently supports SSA, the sharing of assessments between health and social care and CPM, which delivers alerts relating to the formal child protection status to participating agency systems (currently social work, education and health) with a legitimate interest in that child. CPM is currently implemented in Ayrshire & Arran, Outer Hebrides,
Tayside and Borders DSPs. SSA is implemented in Outer Hebrides and Grampian. Further, active implementation is underway in Tayside and Fife. eCare / GIRFEC iACT PIA
Page 13
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
Getting It Right For Every Child requires information sharing, potentially across multiple agencies, to deliver its objectives around better coordinated, earlier intervention, to ensure the every child gets the help they need when they need it. While this may be possible to some extent with without ICT support, an electronic solution is seen as essential to timely, consistent, secure and privacy-friendly information at national level. eCare iACT will provide practitioners with general electronic support to the day-to-day exchanges of case-related information that are necessary for better inter-agency collaboration within Scottish children’s services while also respecting the privacy of children and their families. The initial scope for the production version of eCare iACT is constrained by the following set of statements. Note that implementation schedule is likely to phase the delivery of these requirements – indicative phasing is given below. The statements are in priority order.
1. Provide a secure electronic means through which a practitioner can share relevant information about a child with relevant colleagues in other agencies;
2. Provide practitioners with a secure and quick electronic means of requesting relevant summary information from other agencies where this is related to their own work with a child;
3. Make it easier for practitioners to find out who else is working with a particular child
(or with oth er members of the child’s family);
4. Provide practitioners with a secure method of delivering electronic documents in standard formats (e.g. Word or PDF) – such as specialist reports and other relevant reports/forms – to relevant colleagues in other agencies;
5. Provide practitioners with the ability to: a. manage the information they receive from other agencies regarding a child by structuring and filtering the information; and b. share this information with relevant colleagues (i.e. only those colleagues who need to know the information) within their own agency.
6. When a practitioner, with no access to a Line of Business application, has targeted an electronic communication to another iACT user, and receives responses to their electronic communications from other agencies by telephone or letter as well as electronically, provide them with an easy means of noting and retrieving the information ( not in scope for initial delivery phase ) ;
7. Provide a secure electronic means through which a practitioner can target another practitioner or agency who has had no previous involvement with the child to share a concern or other relevant information about the child, and/or as a means of requesting a specialist assessment of a child’s needs or such other appropriate help eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 14

Efficiency and Transformational Government Division for a child or family as may be provided by another ( not in scope for initial delivery phase ); and
8. Provide electronic support for the arrangement of cross-agency meetings regarding a child, including the circulation of papers prior to or subsequent to a meeting.
9.
Provide access to be able to view the ‘Child’s Plan’ and other shared records stored within the Multi Agency Store ( not in scope for initial delivery phase )
To address the GIRFEC information sharing requirements, the current eCare Framework is being enhanced with the eCare with the following:
1. the ability to target communications to individuals and business functions, using a new eCare Framework message routing service (P-2-P) and the iACT application
2. the ability to share documents and other file attachments
3. the ability for an organisation without a current line of business application connect to eCare to participate in information sharing, including viewing of eCare MAS content
( not in scope for initial delivery phase ) eCare iACT will provide users with the capability to send communications to other users or services that have an interest in a child and who may or may not decide to respond depending upon appropriateness and reason. As a system it will facilitate secure and targeted information sharing but will not replace the need for an individual to consider and assess what information should be shared and with whom. iACT will not retain data as a persistent store but will act as a means by which to share data appropriately iACT will enhance existing methods of information sharing by providing a means of targeting individuals or services, reducing the risk that information is being shared inappropriately with persons or services. It will protect the privacy of individuals whilst providing a mechanism to securely share information as required to meet the needs of children and young people.
There is a dependency on local availability of the eCare Framework index (including associated "matching" processes) but there is no direct dependency on a Multi-Agency Store
(MAS).
In the first phase of the project, iACT will be delivered to a limited pilot, in one or more partnership areas, with an agreed scope of data sharing capabilities. This will deliver:

A new version (1.1.4) of the eCare Framework with enhanced index and routing capabilities

the initial iACT web-based application

A secure, pilot hosting infrastructure
Further development will be progressed through partnership with the pilot site and will be determined by business priority, costs and effort required. A change management regime will be established to assess and control further development requirements, taking the pilot sites experience and needs and testing them in a wider, preferably national environment. eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 15

Efficiency and Transformational Government Division
Key to further decision points on functionality will be the measurement of likely benefit, which will be used to assess any likely return of investment resulting from change requests. Further technical details of the iACT application are provided in Appendix G.
In relation to privacy, the eCare iACT pilot will allow:
1. The effectiveness of the current technical privacy controls and the balance between current privacy controls and the functionality and usability of the application to be evaluated
2. Initial information governance and procedural controls to be developed further with stakeholder input, to ensure fitness for national roll-out
1. Implement GIRFEC without ICT support for information sharing. Some existing mechanisms for information exchange, such use of couriers / postal services for physical exchange of files or documents or use of email may be adequate for limited implementations of GIRFEC and practitioners will still need to pick up the phone. .
The use of iACT should deliver information sharing capabilities which are more secure, privacy-friendly, auditable and scalable than existing mechanisms. Without such capabilities, consistent, national implementation of GIRFEC would be more difficult to achieve and would carry the significant risks associated with current data handling mechanisms which have led to high-profile data breaches over the last few years.
2. Continue with ad-hoc ICT support for GIRFEC information sharing. It was felt that this would make a national approach more difficult, both in providing the ability to share across exiting agency / DSP boundaries and in ensuring consistency of national approach. In addition, the ad-hoc approach could result in multiple procurements, leading to potentially costly duplication, given that current agency systems do not meet GIRFEC requirements.
3. Use existing eCare Framework and commission enhancement to vendor applications.
As with 1. above, this was felt to be impractical in relation to the time and complexity in procuring and delivering modification to existing eCare adapters. In addition, this would preclude participation from agencies without current eCare connections, such as voluntary organisations and the Police
4. Use Commercial Off The Shelf packages, such as email or document collaboration software. Risks and issues were identified in relation to security, access / disclosure control, scalability, reliable citizen identification across agency systems and the potential need to share persistent identifiers across systems (see Draft SG Privacy
Principles) eCare / GIRFEC iACT PIA
Page 16
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
A detailed listing of eCare iACT stakeholders is provided in Appendix C. The purpose of the
PIA is to analyse and engage around the privacy impact of eCare iACT on these stakeholders. To establish a consistent approach to the analysis of privacy impacts and concerns, stakeholders have been grouped into the following categories:
1. GIRFEC Partner Agencies – who may implement and use eCare iACT to deliver
GIRFEC and information sharing and will be data controllers for iACT data.
2. eCare Data Sharing partnerships – who ‘own’ existing Information Sharing
Protocols and currently share data about children at risk and adults using the current eCare Framework
3. Data subjects - individual children and young people whose data is shared using iACT and their families and carers
4. Scottish Government Safer Children, Stronger families Division – owners of
GIRFEC policy
5. Scottish Government Efficiency and Transformational Government Division
– owners of eCare Programme and privacy policy
6. Regulators and scrutiny bodies – oversee, regulate and inspect aspects of organisational performance and practice, including data handling and sharing.
This includes the Information Commissioner’s Office.
7. Professional and representative bodies - supervise, coordinate and administer professional standards, training and registration
8. Data Processor – (Atos Origin) responsible for processing data in accordance with instructions from the Data Controller(s). General instructions are set out in the NHS NSS / Atos Origin contract, in which Atos Origin is identified as data processor to NHS Boards and other public bodies eCare / GIRFEC iACT PIA
Page 17
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
The iACT Outline Business Case identifies some of the principal benefits which should be delivered through the use of iACT to facilitate information sharing across the agencies involved in GIRFEC. These are summarised in the table below, along with an initial mapping to the main stakeholder groups benefitting, to allow analysis against privacy risks, issues and concerns.
Benefit
No
1
Benefit
2
3
4
5
6
Main stakeholder Groups Benefiting
Improved quality of information leading to more appropriate/focused and targeted intervention and support
Reduction in time from identification of concern to decision on appropriate action
Improved assessment process reducing the need to re-tell the story to numerous colleagues
Full and effective use made of the range of professional expertise across the public/private and voluntary sector
Data subjects
GIRFEC Partner Agencies
Scottish Government (SCSFD)
Scottish Government (ETGD) – more efficient service delivery
Data subjects
GIRFEC Partner Agencies
Scottish Government (SCSFD)
Scottish Government (ETGD)
Reduction in administration in particular relating to referrals
Quality auditing is achieved as a outcome of practice change and not required separately
Data subjects - children and families get better coordinated help and support
GIRFEC Partner Agencies – better, more coordinated service delivery
Scottish Government (SCSFD) – better outcomes for children and families
Data subjects
GIRFEC Partner Agencies
Scottish Government (SCSFD)
GIRFEC Partner Agencies
Scottish Government (SCSFD)
Scottish Government (ETGD)
Data subjects
GIRFEC Partner Agencies
Scottish Government (SCSFD) eCare / GIRFEC iACT PIA
Page 18
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
7
8
Use of shared tools and language engenders trust between professionals resulting in less process duplication
Local joint agency management groups jointly manage and pool resources targeting their use more effectively
GIRFEC Partner Agencies
Scottish Government (SCSFD)
Scottish Government (ETGD)
GIRFEC Partner Agencies
Scottish Government (SCSFD)
Scottish Government (ETGD)
9
10
Increased consistency, security and transparency when information is shared
Greater awareness of agencies involvement with a child
Data subjects
GIRFEC Partner Agencies
Scottish Government (SCSFD)
Scottish Government (ETGD)
GIRFEC Partner Agencies
Scottish Government (SCSFD)
Data subjects
In summary, successful implementation and use of eCare iACT in GIRFEC should deliver benefits of:

More secure, transparent and auditable data sharing processes and more timely interventions and decisions and more efficient process to GIRFEC partners

More transparent information sharing and quicker access to more appropriate services, for children and families. eCare / GIRFEC iACT PIA
Page 19
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
Effective and efficient data sharing across relevant agencies is key to achieving the better outcomes for children expected from GIRFEC. The National Practice Model places gathering information and analysis at the centre of GIRFEC.
The overall purpose of the information sharing in a GIRFEC context is to provide the support and help that a child needs where there is a concern or issue about their well-being, in relation to the key attributes described in the Practice Model (Safe, Healthy, Achieving,
Nurtured, Active, Respected, Responsible and Included). Data sharing may occur when a practitioner in one agency needs to involve another professional. This may be because:-
1.
2.
They need to identify agencies and/or individuals working with a particular child
They need to request assistance from another professional for a specific purpose.
E.g. Education requesting information or input from a specialist NHS service. eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 20

Efficiency and Transformational Government Division
3. They would like to view information from other agencies and/or individuals who will help them make an informed decision on what support the child needs.
4.
5.
They may have information that would assist another practitioner delivering the most appropriate support.
The Child may need additional support on an ongoing basis. (an inter agency case) i.e. a child with complex needs.
Currently, there is no specific Primary legislation relating to inter-agency cooperation, in support of GIRFEC. Statutory agencies which participate in GIRFEC, such as NHS Boards,
Local Authority Social Work and Education Departments and the Police Forces and voluntary agencies, with which they collaborate, will cooperate and work jointly to deliver GIRFEC outcomes for children and families under their existing powers and statutory obligations and functions. Relevant legislation relating to data sharing in this context includes:









Access to Health Records Act 1990
Antisocial Behaviour etc. (Scotland) act 2004
Children (Scotland) Act 1995 - Section 53(1)
Children Act (2004)
Community Care and Health (Scotland) Act 2002
Education (Additional Support for Learning) (Scotland) Act 2004 Section 13
Local Government (Scotland) Act 1973 Section 69
The Local Government in Scotland Act 2003 - Section 20, Section 57
Social Work (Scotland) Act 1968
Agencies and individual practitioners involved in managing and sharing personal data must ensure compliance with the Data Protection Act 1998 and must balance the need to share data against the right to Privacy in Article 8 of the Human Rights Act 1998 and the common law obligation of confidence.
A general discussion of data sharing issues for the public sector is provided in Data Sharing:
Legal Guidance for the Scottish Public Sector . Specific issues relating to data sharing relating to children are covered in Legal Framework: Report to the Scottish Executive
Children’s Hearing Review. eCare / GIRFEC iACT PIA
Page 21
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
GIRFEC aims to put children, families and young people at the centre of processes and decision-making. This applies to data sharing and consent – ‘ A common approach to gaining consent and to sharing information where appropriate ’ is one of the core components of
GIRFEC as discussed in section. The guidance in the GIRFEC Information Sharing models and process (Appendix F) is specific on consent:
“…Discuss with Child and/or parent/carer. If the situation is such that consent is required, seek consent to share and/or request information from and with other agencies, specifying the purpose.
– Consent to share and/or request information from other agencies should always be sought unless this would potentially place the child at risk or there is a
legal duty to share information without consent. This consent would specify a purpose for sharing information in relation to all the communications. At this point the Type of
Communication to be sent should be discussed and permission sought. When one agency wishes to share personal information with another agency, the person that the information is about will need to be informed as to what the information is, why it is to be shared, who it is to be shared with, and how it will be used .”
The importance of the involvement of the child and family in data sharing decisions is further emphasised in the GIRFEC Evaluation Themed Briefing: Briefing 3 Record Keeping and
Assessment of Children's Needs , which notes (referring to the Pathfinder work carried out in the Highland Partnership):
“In the early stages of the implementation of the pathfinder phase in Highland there was some anxiety about confidential information being shared between services. A Data Sharing
Partnership was established to clarify the issues and determine an agreed position across all the relevant services and agencies. The agreed position was that priority should be given to obtaining informed consent by the child or young person and his or her parents or carers except in circumstances where consent was withheld but there was clear risk of significant harm to the child and this risk had been fully evidenced by the professionals concerned. The agreed approach also emphasised the importance of professionals talking to children and families about why they (the professionals) have become involved, why an assessment and
Child’s Plan is or is not needed, what this would entail and what the intended outcomes might be. “
The report goes on to note some specific consent issues.
“While the work of the Data Sharing Partnership has helped to resolve some of the interagency concerns about the sharing of sensitive information there still appear to be some concerns about what constitutes informed consent when the person being asked for that consent is under considerable stress and may also be confused. “
“There are also some residual tensions between those services and agencies which regard information sharing – with or without the consent of the child or family – as part of their duty of care to the child and those who will withhold information from other services if they believe eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 22

Efficiency and Transformational Government Division they have a duty of confidentiality to the child, parent or victim. Where disputes over consent and confidentiality arise and cannot be resolved through informal contacts between professionals or their line managers then the issue is referred to formal arbitration within the
Data Sharing Partnership. However, there is evidence that the residual tensions are reducing as staff become more used to the Getting it right approach to multiagency working.”
It is important that these aspects of consent are addressed and evaluated as part of the initial iACT pilot activity.
The potential benefits of the eCare iACT solution to stakeholder groups identified in 3.2 above must be balanced against potential privacy impacts. Particular stakeholder perspectives and concerns in relation to data sharing and privacy aspects of the eCare iACT solution are summarised in the table below. These are derived from the PIA risk and issue workshops (see section below), discussion with the eCare iACT team and analysis of available documentation. The privacy concerns listed below are not exhaustive and the table may be supplemented by further stakeholder engagement, particularly with children and families and feedback from piloting of the eCare iACT solution.
Stakeholders
1. GIRFEC Partner Agencies
2. eCare data sharing partnerships
Privacy concerns
Will the introduction and use of eCare iACT impact on:
 The trust between an agency’s’ staff (particularly front-line staff) and the children and families they work with?

The trust between different partner agencies?
 An agency’s ability to manage data appropriately or the likelihood of a data breach?

The individual responsibilities and professional liabilities of the agency’s staff?
Will the eCare iACT operational and technical privacy controls conflict with efficient and effective working?
Will the introduction and use of eCare iACT impact on:

The capabilities of the current eCare Framework and the services and policies which it supports

Access to existing eCare data

Current eCare governance and security eCare / GIRFEC iACT PIA
Page 23
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
3. Data subjects
4. Scottish Government Safer
Children, Stronger families Division
5. Scottish Government Efficiency and Transformational Government
Division
6. Regulators and scrutiny bodies
7. Professional and representative bodies
8. Data Processor – (Atos Origin)
Will the introduction and use of eCare iACT change the relationship I have with the agencies and people who work with me and the services they provide?
Will the introduction and use of the eCare iACT impact on my rights?

My consent has been sought, where appropriate, and the purpose for sharing my data presented clearly;

My data is handled appropriately and for agreed purposes;

My Wishes regarding confidentiality, sharing and handling of personal data are respected;

I can identify what personal data is held, by which agencies and with whom it has been shared;

I can challenge and correct inaccurate data
Will the introduction and use of eCare iACT support the goals and outcomes of GIRFEC in a manner which is consistent with the principles and ethos of Getting It Right?
Will the introduction and use of eCare iACT impact on the ability of agencies involved in sharing data in support of
Scottish Government Policy to do so in a manner consistent with Scottish Government Data Handling review recommendations and Identity management and Privacy
Principles?
Will the introduction and use of eCare iACT impact on the ability of agencies involved in managing and sharing personal data to comply with relevant legislation, regulations and adopt appropriate good practice?
Will the introduction of eCare iACT impact on the ability of relevant staff to manage and share information in a manner which is consistent with their individual and professional responsibilities, training and ethics?
Will the introduction of eCare iACT present any significant challenges to the Data Processor’s ability to deliver its contractual responsibilities to the Data Controllers? eCare / GIRFEC iACT PIA
Page 24
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
The following sections give an overview of GIRFEC business scenarios, showing the use of iACT and key decision points and information transfers. A technical overview of more detailed description of the main data flows relating to eCare iACT is presented in Appendix
G. This section introduces some basic eCare iACT concepts, to allow the information flows to be placed in context. eCare iACT messaging overview
Agency A
Business
App iACT eCare Framework eCare Index
Indexing
Services
Index
GIRFEC Specific Services
P2P
Services
Transitory
Store
1
Person Matching
Matching
Services
Match
Requests
Agency X iACT
The diagram above illustrates some key elements of the eCare iACT system:
1. The Child & parent or guardian, with whom services interact and who will be data subjects in eCare iACT
2. Practitioners working in agencies , which need to share information to deliver services to the child or family.
3. The business system which contain the agency’s formal records relating to the children with whom the agencies interact. Agencies may choose to integrate their caseload (basic demographic data, such as name, address and gender) with iACT or re-key client data. Where an agency does not have an existing business application, it must still have local provision for files, records and documents.
4. The iACT application - iACT is a centrally hosted web application, but is ‘federated’ in the sense that each agency which uses iACT will control its own ‘instance of the application. The agency will act as data controller for the data and messages held in their instance of iACT. Each user of iACT will have an inbox for messages. Every eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 25

Efficiency and Transformational Government Division child in iACT will have a folder , in which relevant messages will be stored. Only users with appropriate permissions (assigned by the local agency), will be able access a spe cific child’s folder. Each folder will have a folder manager , who will determine who may access the folder and a default recipient , who will receive communications about the child. The ability to delegate message receipt will address the risk of messages not being picked up because of annual leave or staff changes.
5. Communications , which will be sent between agencies using iACT. These may contain attachments , such as documents or other files containing relevant information. The recipient agency will become the data controller for the communication and attachments on receipt. A communication may be targeted at an individual practitioner [with an iACT address] or a business function or role - for example an Area Social Work Team or a Head teacher. Business function will be locally determined and published to a central Directory.
6. The eCare Framework . This is hosted in a highly resilient, secure data centre and is managed by Atos Origin, which is the Data Processor . iACT uses some of the central eCare Framework services – a. the eCare index provides the means of reliably identifying the child/data subject across different agencies; b. the P-2-P service ensures that messages are routed and delivered to the right instance of iACT. This means that iACT information will be held, transiently, within the eCare framework
There are two main categories of personal data which will be handled by eCare iACT:
1. Basic demographics – each child in iACT will have a basic set of structured data, consisting of Name , Date of Birth , Gender and Address . This is the minimum required for identification. In circumstances where a child is at risk of harm, their address may be highly sensitive and may be subject to a Non-Disclosure Order. Only the name is routinely shared as part of the iACT communication.
2. iACT communications
– an iACT communication has three parts: a. The communication envelope – ‘metadata’ about the communication, including Sender , Data subject’s name ; Addressees ; Subject and Brief description of the communication, Respond by date and Sharing guidance .
This provides the recipient with sufficient information to determine if the message is relevant to them, how to handle/route the message and whether to view the message content b. The communication content – this is opened as an explicit, audited action by the message recipient, having viewed the communication envelope. This contains: the Message – free text , potentially sensitive professional opinions/observations/comments; Child/Family Awareness of the communication and whether the Child/ Family Agrees with the communication c. Document / file attachments – including Police concern forms, assessment forms and plans, which may include highly sensitive personal information: eCare / GIRFEC iACT PIA
Page 26
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
The diagram below illustrates a general usage scenario for iACT messaging and some key aspects of the information flows.
General iACT communication process
Agency A
Electronic
Communication sent to
all practitioners with involvement
Identify need for multiagency
Discuss with
Child / Parent
Identify
Agency
Involvements
1.
2.
3.
6.
Request
Additional Info
9.
Analyse & assess
Agency B
Assess
Request
Confirm
Involvement
Assess
Request
Provide
Information
4.
5.
7.
8.
Practitioner makes active decision to respond / share information
1. A practitioner in agency A has a concern about a child they are involved with and may need to get information from other agencies, however, the practitioner does not know which other agencies are involved. Other GIRFEC scenarios involve cases where the involvement of other agencies is known
2. The concern is discussed with the child/family and consent to identify involvement is requested, unless doing so would place the child at risk. Information relating to consent is stored locally, as part of the agency’s records.
3. The practitioner decides to send a broadcast message – Request for Involvement to other iACT users. The coverage of the broadcast message may be refined further by selecting a specific sector(s) or geographical area(s). This will contain a brief reason for the request, sufficient for the recipients to decide whether to disclose involvement.
The message will only be sent to iACT users with a legitimate involvement (eCare index entry) with that child.
4. Agency B has an index entry for the child and receives the message. A practitioner, allocated to the child, assesses the Request for involvement , to decide whether to respond. All iACT message exchanges involve explicit, audited practitioner decisions.
5. In this case, the Practitioner decides that it is appropriate to confirm involvement and responds with a targeted message containing the minimum information necessary. If
Agency B had decided not to respond, this decision would have been recorded in their instance of iACT, for audit purposes. eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 27

Efficiency and Transformational Government Division
6. The Practitioner in Agency A receives the confirmation and, following discussion with the child/family (unless this would place the child at risk), decides that further information from Agency B is required. A [ targeted ] request for information , containing background information to the request and a statement on the involvement /consent of the child or family, is sent to Agency B
7. The Practitioner in Agency B assess the request and decides what, if any, further information to provide
8. The Practitioner in Agency B responds with appropriate background information, including document attachment(s), if relevant.
9. The initiating Practitioner in Agency A analyses and assesses the information received and discusses with the child/family, before deciding on appropriate action.
Steps 6, 7, 8 & 9 may continue as collaboration between the two (or more) agencies continues
The steps described above show some the main business functions which iACT supports. As discussed earlier in the document, iACT functionality is restricted to the basic messaging exchanges required to support data sharing for GIRFEC early intervention. Many aspects of the application are generic, to allow the information/messaging to interact appropriately with different local processes. These same iACT capabilities could be deployed to support other policies or processes. At present, four main person-centred message types are planned for iACT:
1. Involvement enquiry – a broadcast communication, delivered to any iACT instance with a match for the subject child, to enable a practitioner to determine which, if any agencies are involved with the child. The enquiry may be filtered by agency type or geographical area
2. Communication with Involved Practitioner or Agency – a targeted communication, which supports the one or two-way exchange of information between two or more agencies with a legitimate interest/index entry for the child
3. Request for assistance / Unconditional communication ( not in scope for initial delivery phase ) – a targeted communication, through which an agency with a current index entry for a child can share information with an individual practitioner or a bu siness function in another agency which doesn’t have an index entry for the child
4. Request for Agency Identification ( not in scope for initial delivery phase ) - this communication type be used when a statutory agency has a legal right and duty to be informed which other agencies are, or have been involved with a child. However, in the eCare iACT system, there would be no automatic disclosure unless there has been prior agreement with the agencies that would receive this type of communication. For example, where the Police and social work department are carrying out a child protection investigation and it has been agreed beforehand by participating agencies that a request from the police, for a specific purpose, would automatically disclose their details. This would be an opt-in function, as agencies must have the right to decide their responses to all communications.
eCare / GIRFEC iACT PIA
Page 28
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
A Guide to Implementing Getting it right for every child shows what needs to be done by people at every level across all agencies and sectors to bring about the changes that are necessary to implement Getting it right for every child. It identifies essential culture, systems and practice changes and sets out what different people in organisations need to do to progress this agenda successfully. It provides strategic managers, operational managers and practitioners with examples of what works in practice gleaned from the experience of pathfinders and learning partners and summarises the features that make for successful implementation. Although partnerships and agencies may adopt different approaches and models for GIRFEC delivery, two key roles are identified which will be significant in the implementation and use of iACT:
The Named Person
Every child will have a Named Person , in health or education, depending on the age of the child, who will act as the first point of contact for children and families. Through children and families knowing who to contact, their access to help is made easier. This is an essential feature of a child centred approach. The named person will take initial action if a child needs extra help, formalising the activities universal agencies are undertaking routinely in their dayto-day work. The difference is that the Named Person will use the National Practice Model to help decide what actions to take and work more efficiently with others. Experience from the pathfinders and learning partners has shown that, in spite of anxieties, the role of the Named
Person has not created additional work. Rather, the new processes have sharpened existing roles.
The Lead Professional
Where a child needs help from two or more agencies, the Lead Professional is the person who co-ordinates multi-agency planning and makes sure that the different services provide a network of support around the child in a seamless, timely and proportionate way. They have a critical role in ensuring children and families are active contributors. Families have reported that this role has helped them understand what is happening, and has made them feel part of a team that works together.
Both the above roles will have substantial requirements to coordinate and use information from other agencies and significant responsibilities for ensuring that information is used appropriately across agencies. The successful implementation of iACT will require local system administration manage iACT users and their roles and access, but it is likely that the
Lead Professional would have a role in managing access and use of iACT folders. The initial piloting of the application will provide further clarification of how these roles will use and interact with iACT. eCare / GIRFEC iACT PIA
Page 29
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
The information analysis in 4.3 above presents a view of generic information flows which will be supported by eCare iACT in support of GIRFEC. Internal eCare/GIRFEC risk analysis, detailed in Appendix H, has informed the initial system design. Subsequent external stakeholder workshops held with statutory and third sector stakeholder groups have allowed different perspectives on key privacy risks and issues, relating to the use of the eCare iACT, to be gathered. The detailed risk and issue logs derived from these sessions are included in
Appendix F. The main risks and issues are summarised below, with risks grouped, where possible, into high-level risk categories.
It is worth emphasising that some of children about whom information may be shared using eCare iACT will be vulnerable &/or at risk of harm. An eCare iACT security Business Impact
Assessment (BIA), carried out with practitioner stakeholder representatives, has identified the potentially severe consequences to the safety or such children and the prevention or investigation of crime of breaches of confidentiality or unauthorised modification of the information which will be handled by iACT. Conversely, the information sharing which iACT supports is intended to improve coordination and delivery of services to children, including those at risk and should provide a means of doing so which is significantly more secure, consistent and transparent that current ad-hoc practices.
4.4.2.1 Risk that child or families concerns about data sharing may impact on their relationship with practitioners
Risk Description
The trust between the child / family and the agencies which provide services and support is fundamental to successful delivery of GIRFEC principles and practice. If the data subjects are not clear about the scope and purpose of the data sharing which will be supported by eCare iACT, there is a risk that consent may be withheld &/or trust undermined, leading to poor implementation and delivery of GIRFEC.
4.4.2.2 Risk that information is shared with the wrong people
Risk Description
Getting it right has identified a set of information sharing needs; these include the ability to identify organisations and people involved with a child and the ability to share specific information around concerns. iACT provides a mechanism for sharing information via eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 30

Efficiency and Transformational Government Division communications, potentially with large numbers of iACT users.
There is a significant risk that information about an individual is shared with people who do not have a legitimate need to know, leading to harm and distress to the individual, reputational damage and possible enforcement action against partner agencies and loss of confidence and trust in GIRFEC. iACT must minimise the risk that information is shared with the wrong people.
4.4.2.3 Risk of inappropriate disclosure of information
Risk Description
There is a significant risk that information about a citizen may be disclosed inappropriately, leading to leading to harm and distress to the individual, reputational damage to, and possible enforcement action against, partner agencies and loss of confidence and trust in
GIRFEC. This is a complex risk that can arise in a number of situations including:

Lack of understanding by the recipient as to how information can be re-used e.g. the recipient may subsequently disclose the information to a wider audience, either electronically or via traditional mechanisms.

Accidental disclosure of information through providing users with enough information to infer something about a citizen, such as a particular agency’s involvement with a citizen - e.g. is it appropriate for a teacher to always know a child has an involvement with a sexual health clinic?

Disclosure of information without an appropriate reason for sharing.

Disclosure of information without appropriate consent or data subject involvement

Excessive information disclosure.
Through introduction of the eCare iACT solution, it would be easy, in theory, to disseminate information across a wide audience, at the click of a button. The solution must ensure that there are adequate safeguards in place to prevent this.
4.4.2.4 Risk that information is accessed inappropriately
Risk Description
There is a significant risk that a solution which provides access to shared information about children may be accessed for inappropriate reasons, leading to harm and distress to the individual, reputational damage to, and possible enforcement action against, partner agencies and loss of confidence and trust in GIRFEC. The solution must put in place an appropriate level of control to ensure only valid users are accessing the information in an appropriate manner .
eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 31

Efficiency and Transformational Government Division
4.4.2.5 Risk of ‘administrative’ staff (system administrator or other non professional staff handling data) accessing too much information
Risk Description
In the routine operations of the centrally hosted eCare iACT solution and the normal processes of the local agencies which use the solution, it may be necessary for
“administrative” staff (i.e. system administrators or other non professional staff handling data) to access to iACT records to fulfil their daily operational roles. This creates the risk that admin. Staff may inadvertently or deliberately access sensitive information about a child, which is not necessary or appropriate, leading to harm and distress to the individual, reputational damage and possible enforcement action against partner agencies and/or the data processor and loss of confidence and trust in GIRFEC. Whilst it may be appropriate for these staff to have access to some citizen information, the solution must ensure that the amount of information disclosed is appropriate .
4.4.2.6 Risk that information is shared about the wrong person
Risk Description
There is a risk that information shared may be attached to the wrong child. This could result in incorrect actions and plans being put in place for the child, leading to leading to harm and distress to the individual, reputational damage and possible enforcement action against partner agencies and/or the data processor and loss of confidence and trust in GIRFEC. This risk could arise at a number of points in the information sharing lifecycle:

During matching, if incorrect linkages are created between citizen records in different iACT instances, resulting in information originally recorded against one citizen being attributed to a different citizen.

During capture of information in iACT where a user is accessing the wrong citizen record when recording information or creating a communication.
4.4.2.7 Risk that information disclosed by one agency is retained or managed inappropriately by others
Risk description
Given the multi-agency nature of the information sharing it is likely that the different agencies involved will have different policies relating to the retention and management of data. This creates the risk that policies applying to the data controlled by an agency sending a communication, with attachments(s) may not be implemented by the recipient agency and information being retained longer than is necessary, leading to leading to reputational damage and possible enforcement action against partner agencies and/or the data processor and loss of confidence and trust in GIRFEC. eCare / GIRFEC iACT PIA
Page 32
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
4.4.2.8 Risk of inappropriate management of personal data through lack of clarity about the interaction between iACT and other agency systems
Risk description
The eCare iACT application may be integrated with an agency’s existing business / case management system ( not in scope for initial delivery phase ). This will allow synchronisation of basic demographic data, to avoid rekeying and ensure data consistency. In the case of document and other attachments, there is a risk that iACT is used a secondary data repository, rather than a means for communicating and sharing documents, with sensitive information being retained in iACT folders. This could lead to multiple copies or versions of key documents existing in iACT and the agency’s substantive record store and risks of key documents being retained or deleted inappropriately (as in 4.4.2.7 above) or decisions being based on out of date or inaccurate information.
Privacy issues are captured through as part of eCare iACT issue management processes. A privacy issues log will be extracted and published and will be updated through further engagement activity with children and families and during the planned controlled piloting of eCare iACT, as specific privacy issues arise. Key open issues include:
Impact of iACT on existing data sharing protocols
Currently, multi-agency data sharing across takes place between the agencies involved under the principles set out in an Information Sharing Protocol (ISP). This is based on the
Scottish Executive Gold Standard ISP document and is currently agreed on a regional basis
– either the current eCare data Sharing Partnerships (DSPs) or Community Planning
Partnerships. iACT will support data sharing across partnership boundaries and ISPs and information governance arrangements revised accordingly. eCare iACT information risk ownership
While the risk ownership and data controller role for a specific iACT instance clearly lies with the agency which uses that instance, overall ownership of information risk required for security accreditation of the eCare iACT solution cannot lie with one single entity, given the multi-agency nature of the system.
Sharing data where child does not have a CHI number
Currently, reliable identification of an individual across partner agencies is assured by agencies ‘matching’ a child against the NHS CHI as a demographic reference source (see
Appendix G for brief overview). For any communication to be possible, a child must have been allocated a CHI number and at least one agency must have matched the child. There are likely to be circumstances where information needs to be shared about a child who does not have a CHI number. If a workaround is introduced, this must be balanced against the risk of misidentification. eCare / GIRFEC iACT PIA
Page 33
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
Section 5.1 maps the risks, issues and concerns identified at the internal and stakeholder privacy workshops, along with specific issues related to alignment with Scottish Government
Privacy Principles and maps these to current and planned features, mitigations and controls
– further details of these are set out in the Appendix I. An action plan for implementing features with Recommended status is discussed in 6.2. Key current privacy design features are:
1. Point to Point Information Sharing and Federated Database - The Point to Point communication approach avoids data being stored in a single, central database. A federated database model allows access (searching) only to locally stored data - you physically cannot search across the full, national dataset.
2. Legitimate Relationship - The system only allows access to information where a
‘legitimate relationship’ (i.e. that the agency has the child on their caseload and that the user has permissi on to access the child’s iACT folder) exists between a user and the child, reducing the risk of inappropriate information access or sharing.
3. Broadcast Communications - This enables users to actively decide to reveal involvement / information based on the specific merits of each request.
4. Targeted Communications - This ensures that information is only shared with specific known parties.
5. Communication Envelope - This provides users with a mechanism to reduce the risk of accessing information inappropriately and provides a privacy friendly method of rerouting communication.
6. Data Minimisation - By only sharing a summary of information known about a citizen the scope, impact and risk of data leakages is reduced.
7. Information Audit - Robust audit functionality provides a mechanism for identifying inappropriate access to citizen’s information and tracing key data sharing decisions.
8. Information Security Framework - A comprehensive security risk assessment process will ensure that a secure environment for information sharing is deployed.
9. Information governance & privacy assurance framework - A robust privacy governance framework should ensure that roles and responsibilities are clear, protocols, policies and procedures are in place, that staff are trained and that a compliance approach is deployed.
10. Information Usage Guidance and Licensing - The sender of a communication has the option to add guidance notes that describes how the information within the communication can be used by a recipient. These notes will form part of the individual communication envelope and will remain attached to the communication.
eCare / GIRFEC iACT PIA
Page 34
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
Mapping of privacy risk & issues to current / required features mitigations and controls
No Risk, issue, concern
Source
1 Risk that child or family’s concerns about data sharing may impact on their relationship with agencies and practitioners
Stakeholder workshops
Key
Stakeholders
Priority of risk/issue
Feature / mitigation / control
Data subjects;
GIRFEC partner agencies
SG: GIRFEC
High 1.1 Communication package for children and parents – will describe
GIRFEC processes and the use of eCare iACT
2 Risk that information is shared with the wrong people
Initial privacy analysis;
Stakeholder workshops
Data subjects;
GIRFEC partner agencies
SG: GIRFEC;
SG: eCare eCare / GIRFEC iACT PIA
High
Status
Version 1.0 Release
17/11/2010
Type
Recommended for pilot
Communication
& business change
1.2 Review of fair processing / privacy notices - agencies using eCare iACT for GIRFEC purpose will be expected to ensure that
2.1 The Legitimate relationship ensures that a communication can only be delivered to an instance of iACT where the organisation that owns the instance has a relationship with the citizen at some level. On receipt of the communication only a user who has a relationship with the citizen, established
Recommended for pilot
Information governance & privacy assurance
For delivery to Technical pilot
Page 35

Efficiency and Transformational Government Division
3 Risk of inappropriate disclosure of information
Initial privacy analysis;
Stakeholder workshops
Data subjects;
GIRFEC partner agencies
SG: GIRFEC;
SG: eCare
High eCare / GIRFEC iACT PIA through the local iACT folder can view the communication. If there is no folder based relationship, for example where a communication is targeted to the wrong user, the communication will be delivered to the folder owner who can decide how best to process the communication.
2.2 Targeted communications - information is disclosed to a specific set of people based on the decision of the sender
In scope for delivery to pilot
Technical
Design
3.1
Broadcast communications - the involvement enquiry is used to identify which agencies have an involvement with the child. Users who receive a broadcast have the option to decline to respond to the communication. This allows a user to make an active decision to share information (even their involvement) on a case by case basis.
In scope for delivery to pilot
Technical
Design
3.2 Information sharing guidance (at communication level) - The original sender of the information can provide guidance to the recipient as to how the information can be used i.e. if it is acceptable to pass the information on to other relevant parties. The guidance is
In scope for delivery to pilot
Technical
Design
Version 1.0 Release
17/11/2010
Page 36

Efficiency and Transformational Government Division eCare / GIRFEC iACT PIA explicitly attached to the information and will remain even if communications are forwarded to other parties.
Whenever information is shared via a communication it is necessary to record the reason for sharing information.
Whilst this does not prevent sharing for an inappropriate reason it should at least require users to think through their reasons for sharing and does provide an explicit audit record of why the information was shared. The sender may also specify that a communication may not be forwarded - this will be enforced by the recipient’s iACT
3.3 Communication envelope - this is a wrapper around each communication preventing users from automatically viewing the most sensitive information within a communication. The envelope is a failsafe mechanism - allowing the recipient of the information to verify that they are an appropriate recipient.
In scope for delivery to pilot
Technical
Design
3.4 Practice guidance and training - all users must understand how to use the new technology in a secure and privacy friendly manner before gaining access to eCare ACT. They must be fully aware of the potential risks of using the system inappropriately.
Recommended for pilot
Information governance & privacy assurance
Version 1.0 Release
17/11/2010
Page 37

Efficiency and Transformational Government Division
4 Risk that information is accessed inappropriately
Initial privacy analysis;
Stakeholder workshops
Data subjects;
GIRFEC partner agencies
SG: GIRFEC;
SG: eCare;
Data
Processor
High eCare / GIRFEC iACT PIA
3.5 eCare iACT community code of connection – this will be signed off at senior officer/SIRO level within participating agencies and will include a statement confirming that staff have been appropriately trained and are aware of their responsibilities for appropriate handling of iACT information.
4.1
Point to Point Information
Sharing and Federated Database -
There is no single, central database in which all children’s data is stored. This makes it extremely difficult to search for information in anything other than your own local iACT instance. Within iACT further role based access controls ensure appropriate access to information.
Initial draft
Recommended for pilot
Information governance & privacy assurance
In scope for delivery to pilot
Technical
Design
4.2
Legitimate relationship - Each communication received by an iACT instance will be stored within a folder.
This provides a secure wrapper controlling access to the communication and only those users associated with the case can access a communication.
In scope for delivery to pilot
Technical
Design
Version 1.0 Release
17/11/2010
Page 38

Efficiency and Transformational Government Division eCare / GIRFEC iACT PIA
Note that there could be multiple cases associated with a child. Having access to one of a citizen’s cases does not mean you can access all communications related to the child.
4.3
Information Audit - All user actions, including access to information will be fully audited.
4.4
Information security framework -
Appropriate levels of information security must be in place to ensure that all users accessing the system are authenticated and authorised to access the information systems. Whenever information is transmitted between points it will be encrypted. The information security management policies and processes must be defined, implemented (including staff training) and understood by both users of the system and technology operations staff.
Before a new organisation connects to iACT it must sign-up to the Security
Policy and Community code of connection.
In scope for delivery to pilot
Technical
Design
4.5 Information and privacy governance framework - A robust set of practice guidance and training must be put in place; all users must understand how to use the new
Version 1.0 Release
17/11/2010
Page 39

Efficiency and Transformational Government Division
5 Risk of
‘administrative’ staff (system administrator or other non professional staff handling data) accessing too much information
Initial privacy analysis;
Stakeholder workshops
Data subjects;
GIRFEC partner agencies
SG: GIRFEC;
SG: eCare;
Data
Processor
Medium eCare / GIRFEC iACT PIA technology in a secure and privacy friendly manner before gaining access to iACT. They must be fully aware of the potential risks of using the system inappropriately.
5.1
Communication envelope - This provides a wrapper around each communication preventing users from automatically viewing the most sensitive information within a communication.
This can be aligned with the security access controls to either grant or prevent users from seeing the detailed communication content.
In scope for delivery to pilot
Technical
Design
5.2
Information security - The security model must provide a level of granular access control that restricts the information and functions that a user can access. The access controls can be configured based on each organisation’s local policies, subject to adherence to national guidance.
5.3
eCare iACT data policy – will include guidance on what routine operations central administrative staff will carry out on eCare iACT data and the processes and procedures which will apply to exceptional interventions,
In scope for delivery to pilot
Recommended for pilot
Version 1.0 Release
17/11/2010
Technical
Design
Information governance & privacy assurance
Page 40

Efficiency and Transformational Government Division
6 Risk that information is shared about the wrong person
Initial privacy analysis;
Stakeholder workshops
Data subjects;
GIRFEC partner agencies
SG: GIRFEC;
SG: eCare;
Data
Processor; eCare DSPs
High eCare / GIRFEC iACT PIA such a data error correction relating to matching, and the relationship between central and local roles and responsibilities. The policy will be developed for agencies and staff who own and use iACT and the Data
Processor (Atos Origin). This will be referenced in the iACT community code of connection relating to conditions of use of iACT, which agencies will sign up to, prior to implementing the eCare iACT solution
6.1
eCare matching process – This is a mature and established eCare process. For the majority of cases, matches are established by an automated process, reducing the likelihood of incorrect matches due to human error; although a significant number of cases will still require manual intervention to establish the linkages.
However, it must be accepted that matching errors will occur, so existing eCare data correction procedures will be extended to deal with specific iACT requirements to ensure that data is corrected and that the potential impact of information being shared incorrectly is remedied.
In scope for delivery to pilot
6.2
User Interface Design – The iACT application user interface must ensure
In scope for
Version 1.0 Release
17/11/2010
Page 41
Technical
Design
Technical

Efficiency and Transformational Government Division
7 Risk that information disclosed by one agency is retained or managed inappropriately by others
Stakeholder workshops
Data subjects;
GIRFEC partner agencies
SG: GIRFEC;
SG: eCare;
Data
Processor;
Medium eCare / GIRFEC iACT PIA
Page 42 that the current citizen being accessed is prominently displayed at all times.
The system must also require that the user verifies the communication prior to sending, i.e. displays the full communication content and a “please confirm that you wish to send this information” button. While this is not a failsafe, it does reduce the chance of sending incorrect information.
6.3
Training – All users of the system must have undertaken appropriate training prior to accessing the system.
Training must make the user aware of risks and responsibilities of using the system, including how to use the system appropriately and describing procedures to remedy any information sharing errors.
7.1
Information security framework – the formal security risk assessment carried out on the eCare iACT solution will assess the business impact of the categories of information exchanged through iACT and may make recommendations on overall storage and archiving policies, based on security and legal requirements delivery to pilot Design
Recommended for pilot
In scope for delivery to pilot
Information governance & privacy assurance
Information assurance
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division eCare DSPs
8 Risk of inappropriate management of personal data in attachments through lack of clarity about the interaction between iACT on other agency systems
Stakeholder workshops
Data subjects;
GIRFEC partner agencies
SG: GIRFEC;
SG: eCare;
Data
Processor; eCare DSPs
Medium eCare / GIRFEC iACT PIA
7.2
eCare iACT Data policy – will include guidance on information management, storage and retention and the relationship between central and local roles and responsibilities.
7.3
Information usage guidance – the sender of a message may add guidance on specific data handling or management requirements for particular attachment in the Communications envelope and may place restrictions on forwarding of a communication or attachment., which will be applied at the recipient’s iACT
8.1
Information security framework – the security risk assessment may recommend specific controls and mitigations relating to the use and retention of attachments containing highly sensitive personal data within iACT
Recommended for pilot
In scope for delivery to pilot
In scope for delivery to pilot
Information governance & privacy assurance
Technical
Design
Information
Assurance
8.2
eCare iACT Data policy – this will include specific policy and guidance on
Recommended Information governance &
Version 1.0 Release
17/11/2010
Page 43

Efficiency and Transformational Government Division
9 Issue of Impact of iACT on existing data sharing protocols
10
11
Issue of information risk ownership
Issue of sharing data where child does not have a
CHI number
Stakeholder workshops
GIRFEC partner agencies
SG: eCare;
Data
Processor; eCare DSPs
Security
Accreditation
GIRFEC partner agencies
SG: eCare;
Data
Processor; eCare DSPs
Stakeholder workshops
Data subjects
GIRFEC partner agencies
SG: GIRFEC;
Medium
High
Medium information and records management, including storage and retention of files and attachments and the relationship between iACT folders and the agency’s records management. and local roles and responsibilities.
9.1 Update to ISPs - eCare programme should coordinate activity with local DSPs and other partnerships to ensure that there is consistency in the approach to ISP amendment for pilot privacy assurance
Recommended for pilot
Information governance & privacy assurance
10.1 Existing eCare &/or GIRFEC
Governance mechanisms should be extended to ensure Senior business ownership of eCare iACT information risk
Recommended for pilot
Information governance & privacy assurance
11.1 Analysis and option appraisal – eCare programme, in consultation with relevant stakeholders should agree the best long-term approach and short-term workarounds, if required for pilot
Recommended for pilot
Information governance & privacy assurance eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 44

Efficiency and Transformational Government Division
SG: eCare;
Data
Processor; eCare DSPs
12
Compliance / alignment with
Scottish
Government
Privacy Principles
Appendix K
SG: eCare;
SG: GIRFEC;
Regulators and scrutiny bodies
Medium 12.1 Privacy Principles compliance statement will set out the eCare iACT position. Specific actions will be included in overall Information Privacy
Governance workstream planning
Recommended Information governance & assurance eCare / GIRFEC iACT PIA
Page 45
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
This PIA Report examines the eCare iACT web-based communications tool and its use in support of the Getting It Right For Every Child (GIRFEC) policy. The report focuses on privacy concerns related to the use of eCare iACT to enable the exchange of information about children; the possible impacts of these concerns on key stakeholder groups and the way the concerns can be addressed, to build stakeholder trust and ensure appropriate data handling. This report represents a second iteration of the PIA process, the first iteration having fed into the initial eCare iACT system design. It should be noted that while some of the PIA engagement activity has involved organisations which provide advocacy for children and families, no direct engagement with children and families has been carried out. This is addressed in recommendation 3. below.
The ability to share information effectively is seen as essential to successful delivery of
GIRFEC and national consistency in approach is necessary if information is to be shared across partnerships boundaries. If designed and implemented appropriately, eCare iACT should help to deliver significant benefits to GIRFEC stakeholders, in particular:

More secure, consistent, transparent and auditable data sharing and more timely and efficient interventions and processes, for GIRFEC partners

More transparent information sharing and quicker access to more appropriate services, for children and families.
There are inherent privacy risks in multi-agency data sharing and the messaging approach which is being taken. When rolled out on a national basis, eCare iACT could be used to exchange information on large numbers of children and young people across the wide range of partner agencies involved in GIRFEC. In the case of some children, this information may be highly sensitive because of the vulnerable status of the child or the information content of the iACT communications and their attachments This could expose GIRFEC partners, the agency data processors and the data subjects to risks associated with data breach if the appropriate technical and information governance controls are not in place. Equally, negative perceptions of eCare iACT as an intrusive and privacy-threatening tool could impact on the trust between GIRFEC partners and the children and families they deal with and undermine the successful implementation of GIRFEC, unless the scope and purpose of the eCare iACT solution can be communicated clearly and its trustworthiness demonstrated.
The recommendations below should enable both a programme of work to address specific privacy concerns to be delivered and a process to support privacy assurance and management of future iterations of the PIA to be established. These are intended to feed into the relevant aspects of the planning for piloting of eCare iACT, prior to its subsequent roll-out and wider implementation. This should allow stakeholder engagement, information governance and related processes and procedures to be developed in an appropriate and controlled manner, and learning for the pilot on the balance between privacy controls and operational effectiveness (for example relating to the handling of acknowledgements to broadcast messages) to inform planning and influence modifications to the system design. eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 46

Efficiency and Transformational Government Division
To ensure that data sharing in support of Getting it right, delivers the controls outlined in this report and can maintain the level of transparency and openness required to provide iACT users and data subjects with confidence in the system, the following actions are recommended:
1. eCare and the Getting It Right For Every Child team should assign priorities to the mitigations and controls with status of recommended in Section 5 and develop a Privacy work plan . Priority should be given to stakeholder engagement and information governance activities. The plan should be validated with the
Privacy Consultative Group and the iACT Project Board, then published and communicated.
2. Recommended privacy mitigations and controls relating to High priority risks and issues should be implemented before the initial iACT pilot.
3. Further engagement with children and families around privacy concerns and proposed mitigations should take place prior to the initial eCare iACT pilot and the PIA should be updated as appropriate
4. Recommended privacy mitigations and controls relating to Medium priority risks and issues should be implemented before a national roll-out of eCare iACT.
Information governance and communication products related to these recommendations will be required in interim/draft form, to be finalized by learning from the initial iACT pilot.
5. eCare should complete a Data Protection Compliance check, using the template provided in the PIA Handbook version 2, before the initial eCare iACT pilot. This will include an assessment of multi-agency processes and procedures for management of Subject Access Requests, data correction and data breaches.
6. To deliver Stage 5. (Review and Audit) of the PIA, an assessment of the development and implementation of the controls and mitigations in the Privacy work plan should be carried out before full roll-out of the eCare iACT solution and the outcomes of this assessment should be communicated to stakeholders
7. To support recommendation 6, privacy scenarios and specific privacy-related requirements should be included in formal iACT system and user testing.
8. Privacy risk and issues from the consultation and engagement should be consolidated into a privacy issue register and this should be maintained and published on a regular basis
9. A privacy process flowchart should be developed, with key decision points and criteria to enable decisions to be made about what form of privacy assessment/compliance activity is required at key stages in the implementation and further development of the eCare iACT solution in support of GIRFEC
10.eCare and GIRFEC should establish appropriate senior management risk ownership and accountability for the eCare iACT, to ensure the business acceptability of the eCare iACT security controls. eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 47

Efficiency and Transformational Government Division
The approach used for the iACT PIA is based on the five stages proposed in version 2 of the
ICO PIA Handbook. Key aspects are summarised below.
The internal eCare iACT team carried out an evaluation, based on initial project documentation and stakeholder analysis to determine the type of PIA required. The assessment, based on the ICO Handbook screening questions summarised below, determined that a full-scale PIA was required. Further PIA project planning was carried out, resulting in a specific PIA workstream being included in the eCare iACT project documentation.
Question Y / N Rationale
(1) Does the project apply new or additional information technologies that have substantial potential for privacy intrusion?
N
The project aims to develop new eCare messaging capabilities, but will use existing technologies to do so
(2) Does the project involve new identifiers, re-use of existing identifiers, or intrusive identification, identity authentication or identity management processes?
(3) Might the project have the effect of denying anonymity and pseudonymity, or converting transactions that could previously be conducted anonymously or pseudonymously into identified transactions?
N
N
(4) Does the project involve multiple organisations, whether they are government agencies (e.g. in 'joined-up government' initiatives) or private sector organisations (e.g. as outsourced service providers or as 'business partners')?
Y
The project makes use of the existing eCare matching framework, which supports reliable identification across multiple agencies, without the need to expose or share persistent identifiers.
The types of data shared by eCare iACT would always involve identification of the individual child
The Project will facilitate the sharing of identifiable information across the range of agencies which are involved in providing services to children and families. In addition to the agencies already involved in eCare (social work, education and health), this will include the Police and voluntary/3 rd sector bodies eCare / GIRFEC iACT PIA
Page 48
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
Y iACT will facilitate the sharing of potentially sensitive personal data which is currently held within separate agency systems
(5) Does the project involve new or significantly changed handling of personal data that is of particular concern to individuals?
(6) Does the project involve new or significantly changed handling of a considerable amount of personal data about each individual in the database?
(7) Does the project involve new or significantly changed handling of personal data about a large number of individuals?
(8) Does the project involve new or significantly changed consolidation, inter-linking, cross-referencing or matching of personal data from multiple sources?
(9) Does the project relate to data processing which is in anyway exempt from legislative privacy protections?
Y
Y
Y
Y
Only a sub-set of children will have information shared about them using eCare iACT. The information which is shared may be sensitive and may relate to vulnerable children
Although eCare iACT will only share information relating to a sub-set of children, the number of individuals about whom information is shared will rise as implementation progresses eCare iACT will facilitate the coordination and consolidation of information about a child by a
Lead Practitioner or Named Person for the child
(10) Does the project's justification include significant contributions to public security measures?
Y
N
The subjects of the data sharing may be children and other family members who are at significant risk of harm and are subject to statutory protection arrangements.
As part of GIRFEC, iACT may be used to share information to support the care and protection of vulnerable children and their families
(11) Does the project involve systematic disclosure of personal data to, or access by, third parties that are not subject to comparable privacy regulation?
The Privacy Consultative Group (PCG) was set up, the Terms of Reference & initial consultation strategy were established and initial stakeholder analysis was conducted. Initial
(internal) privacy principles were developed to guide the risk assessment and system design.
3.1 Dec 08 – July 09: Initial PIA
The initial PIA analysis was conducted, consisting of:

internal PIA workshops with the development team and Getting right policy/operational representation

mapping of information flows eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 49

Efficiency and Transformational Government Division

risk identification and assessment

Initial PIA report
The high-level system architecture was revised and a system demonstration tool was produced. The demonstration tool was used in a series of Practitioner system requirements
& privacy workshops, following which, revisions to the system architecture and PIA documentation were made, to feed into the requirements and design phase of the full eCare iACT solution.
3.2 (Aug - Sep 09): Revision and planning
Following the internal workshops, the consultation approach was reviewed and the strategy revised. The next phase of consultation was planned and the PIA documentation updated.
3.3 (Dec 09 – Mar 10): second phase of PIA, with wider consultation
A consultation document, summarising the PIA finding to date and the system privacy features was produced and a twin-track consultation approach delivered. This consisted of:
1. Privacy risk workshops with practice representatives from partner agencies and
Getting it right pathfinders, including a series of three workshops with representatives fro the Third sector.
2. Distribution of the consultation document to privacy/security practitioners, through the NHS IG network and Local Authority SoCITM Security Forum. Response to this consultation was limited to 2 responses from NHS Information Governance network.
New risks identified have been input to the technical system design & development or rolled forward to be addressed through information governance mechanisms, including guidance and training, or subsequent technical development phases. The risk management analysis has been benchmarked against Scottish Government Privacy Principles.
Consultation with PCG, re-drafting of the PIA report and updating of the risk and issue documentation for publication and dissemination.
As party of the eCare iACT piloting activity, the technical and governance systems will be reviewed and audited against the PIA report and risk management recommendations and appropriate compliance assessment will be carried out. This stage may be repeated during further implementation and roll-out of the eCare iACT solution. eCare / GIRFEC iACT PIA
Page 50
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
The following provides a list of stakeholders and their interests in relation to this PIA email and workshop consultees, are highlighted in
Stakeholders Interests
Successful implementation of GIRFEC policy Scottish Government, Safer Children,
Stronger Families Division
Scottish Government, Efficiency and
Transformational Government Division
Scottish Government, Information Services and Information Systems (ISIS) eCare Programme
Highland GIRFEC Pathfinder
GIRFEC pathfinders and learning partners eCHISG [User and Reference Group for development of GIRFEC requirements]
National Practice Forum
Data sharing and privacy policy and PIA implementation
SG Information Assurance and data protection policy and PIA process
Technology, data policy and information governance relating to the GIRFEC solution
Development and Implementation of eCare
GIRFEC solutions to support better outcomes for children and families.
Business change to support GIRFEC implementation.
Governance and management/policy implications of GIRFEC information sharing
Practice implications of GIRFEC data sharing
Safe, secure and effective electronic data sharing eCare Data Sharing Partnership (DSP)
Chairs and Managers
National Child Protection Chairs
Children and families’ advocacy organisations
Information governance, privacy and security practitioners
Information Commissioner’s Office
Child protection policy and practice
Representing and supporting children and families, particularly those who are vulnerable or have additional needs
Validity and completeness of the PIA risk identification and systems design features and their applicability to local policy and practice
Data protection watchdog and PIA process eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 51

Efficiency and Transformational Government Division
The following table summarises the main engagement activities which have fed into this PIA and the organisations involved.
Activity Purpose Dates Agencies involved eCare / GIRFEC privacy workshops
Series of 3 practitioner system design and privacy workshops
To identify key privacy risks and system design privacy approach and principles
To explore electronic information sharing as part of front line
GIRFEC practice and validate the design and build to date of a new practice tool (eCare iACT), including privacy design features
Dec
2008
Jun –
Jul
2009
Members of eCare and GIRFEC
Programmes, including seconded practice representatives and the iACT systems development team,
Aberdeen City
Aberdeenshire Council
Aberlour
ACPOS
Action for Children
Angus Council
Barnardos Scotland
Dundee City Council
East Lothian Council
East Renfrewshire LA
Edinburgh Learning Partner
Falkirk Learning Partner
Fife Council
Highland Council
Highland Pathfinder
Lothian NHS
Lothian Primary Care NHS Trust
Moray Council
NHS Lothian
NHS Tayside
Northern Constabulary
Scottish Borders Council
SCRA eCare / GIRFEC iACT PIA
Page 52
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
Practitioner privacy risk and issues workshop
To:
Validate and extend the current privacy risk assessment
Dec
2009
Critically examine current privacy design features
Capture key comments
/ issues to feed back into the system design eCare / GIRFEC iACT PIA
Page 53
Services for Communities, Edinburgh
Stirling Council
Strathclyde Police
University of Stirling / NHS Highland
University of the West of Scotland
West Lothian
West Lothian Council
Aberdeen City Council
Aberdeenshire Council
ACPOS
Care Commission
Children and Families Department,
City of Edinburgh Council
City of Edinburgh Council
Dundee City Council
East Ayrshire Council
Falkirk Council
Fife Council Social Work Service
Highland Council
Highland Pathfinder
Inverclyde Social Work Service
Lanarkshire Partnership
NHS Ayrshire & Arran
NHS Borders
NHS Fife
NHS GGC
NHS Lothian
NHS Tayside
Royal Aberdeen Children's Hospital
Scottish Children's Reporter
Administration
Scottish Borders Integrated Children's
Services
Scottish Government
Stirling Council
Strathclyde Police
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
Email consultation with security and information governance professionals
Validate approach and risk controls against
NHS and Local
Authority
Dec
2009
Series of 3 workshops with small / medium third sector organisations
To gain a better insight into the data sharing and privacy needs and issues for small / medium voluntary organisations in comparison to the ‘Big
Five’ Scottish voluntary organisations
Dec –
Feb
2010
UWS,
Dumfries & Galloway council
West Dunbartonshire
West Lothian Council
NHS Information Governance network
(responses from NHS Health
Protection Scotland; NHS Fife)
SOCITM security forum
Barnardo’s Scotland
CAIR Scotland
Crossreach
For Scotland’s disabled children
Includem
Leith multi-cultural family base
Penumbra
The Place2Be
Relationship Scotland
Scottish pre-school play association
Shelter Scotland
Voluntary Health Scotland
Who Cares Scotland? eCare / GIRFEC iACT PIA
Page 54
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
1
There are currently 14 eCare Multi Agency Stores (MASs). Local agencies share data in each MAS under joint governance, through the local Data Sharing Partnerships (DSPs), which are based on existing NHS Board geographies. The MASs are hosted in the Atos
Origin Managed Technical Service (MTS), a highly secure, resilient data centre in Livingston, and can be accessed via the secure GSx (Local Government) and N3 (NHS) networks.
Local agencies connect to the MAS data through their existing business application, using a local software ‘adapter’ to allow their local agency system to call the eCare Messaging
Framework (MF) web services. This is summarised in Figure 1.
Figure 1
MAS MAS MAS
N3 or
GSx
Before an agency system can view or contribute MAS data about an individual person, they must ‘match’ 2 against a demographic reference source (currently the NHS CHI), to ensure consistent, reliable identification across agency systems. If matching is successful, an entry will be created in the eCare index. The index does not hold any substantive person data and
1 This is an extract from the eCare Interim records management guidance version 1.0
2 Further detail on the eCare matching and indexing approach is available in the eCare Hub Data
Model Version 1.0
eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 55

Efficiency and Transformational Government Division contains system identifiers and related data only. The identifiers are not exposed to the connecting systems.
Following a successful match, appropriate staff in a given agency will be able to view substantive data about an individual and/or contribute data from their local system to the shared record in the MAS. Currently, all data held in the MAS about an individual person is viewable by any local practitioner with auth orisation to view that individual’s data in their local system. To allow contribution, a competent professional within the local agency must have authorised the disclosure of data. The identity of that professional and the basis for the decision will be recorded. Disclosure of data will require the following conditions to be satisfied:

Either the Subject (or a proxy for the Subject) has given informed consent to the sharing of data or a competent professional within the disclosing agency has taken a considered decision to override the absence of consent; and

It is necessary and relevant to share the data.
Data within the eCare framework falls into 4 categories:
1. Index data – tables linking the identifier(s) used by local agency systems for each person in the MAS;
2. Disclosure data
– the status and history of authorisations and reasons for disclosure of data to the MAS;
3. Substantive person data o Core and extended demographics – structured data covering characteristics of data subjects and associated people, including warning flags. Some entities, such as name and address may have associated histories; o Dynamic data
– processes, events and status episodes; o Semi-structured forms;
4. eCare operation data (data necessary to the operation of eCare, such as user profiles, or data produced during the operation of eCare, such as logs, monitoring data, configuration data, etc.). The management of this data is out of scope for the current document.
This topic is dealt with in more detail in Sections 12 & 13 of the eCare Multi-Agency Store
Data Model Version 2.9.
All data Information held in the eCare framework has been classified as ‘RESTRICTED
MEDICAL’ and as such complies with controls mandated by the NHSS Information Security
Policy. The NHSS Information Security Policy states that RESTRICTED MEDICAL classification is an Impact Level 3 data classification equivalent to HMG RESTRICTED, however does not require compliance to the HMG Security Policy Framework. Each term is equivalent, and is subject to the level of confidentiality that patient data or personal identifiable data is given under the Data Protection Act (1988). eCare / GIRFEC iACT PIA
Page 56
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
Within a local Data Sharing Partnership (DSP), local agencies must have an overarching
Information Sharing Protocol (ISP) in place. This should set out the principles under which data will be shared among the different agencies that are involved in the Partnership. All participants in eCare data sharing must comply with Data Protection Act 1998, Under the definitions in Part I Section 1.(1) of the Act, each individual agency that is a signatory to the
ISP for a given Partnership is a joint and common data controller for the substantive person data held in the Partnership MA S, since the agency is a legal person “who (either alone or jointly or in common with other persons) determines the purposes for which and the manner in which any personal data are, or are to be, processed”, using the tools provided in the eCare Framework.
Atos Origin operates and manages the eCare Framework data and the related technical infrastructure and acts as data processor for eCare data, under terms and conditions set out in the relevant contractual and procedural documents.
Local agencies within a DSP also need to ensure that their use of the eCare framework is aligned with local &/or national records management and retention policies, such as the
Records Management: NHS Code of Practice (Scotland) Version 1.0 and other agencyspecific legal and regulatory requirements. In particular, since eCare uses the NHS CHI as a reference source, specific amendment to the relevant NHS Board’s CHI access protocol will be required prior to live data sharing. This must be authorised by the NHS Board Director of
Public Health. eCare / GIRFEC iACT PIA
Page 57
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
eCare iACT will provide practitioners with general electronic support to the day-to-day exchanges of case-related information that are necessary for better inter-agency collaboration within Scottish children’s services while also respecting the privacy of children and their families. The initial scope for eCare iACT is constrained by the following set of statements. Note that implementation schedule is likely to phase the delivery of these requirements. The statements are in priority order.
1. Provide a secure electronic means through which a practitioner can share relevant information about a child with relevant colleagues in other agencies;
2. Provide practitioners with a secure and quick electronic means of requesting relevant summary information from other agencies where this is related to their own work with a child;
3. Make it easier for practitioners to find out who else is working with a particular child (or with other members of the child ’s family);
4. Provide practitioners with a secure method of delivering electronic documents in standard formats (e.g. Word or PDF)
– such as specialist reports and other relevant reports/forms – to relevant colleagues in other agencies;
5. Provide practitioners with the ability to: a. manage the information they receive from other agencies regarding a child by structuring and filtering the information; and b. share this information with relevant colleagues (i.e. only those colleagues who need to know the information) within their own agency.
6. When a practitioner, with no access to a Line of Business application, has targeted an electronic communication to another iACT user, and receives responses to their electronic communications from other agencies by telephone or letter as well as electronically, provide them with an easy means of noting and retrieving the information;
7. Provide a secure electronic means through which a practitioner can target another practitioner or agency who has had no previous involvement with the child to share a concern or other relevant information about the child, and/or as a means of requesting a specialist assessment of a child’s needs or such other appropriate help for a child or family as may be provided by another; and
8. Provide electronic support for the arrangement of cross-agency meetings regarding a child, including the circulation of papers prior to or subsequent to a meeting.
9. Provide access to be able to view the ‘Child’s Plan’ and other shared records stored within the Multi Agency Store eCare / GIRFEC iACT PIA
Page 58
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
9
2
Agency A
The diagram below shows the principle elements of the eCare iACT solution and the main high-level information flows which take place. iACT is a centrally hosted web application, but is ‘federated’ in the sense that each agency which uses iACT will control its own ‘instance of the application. The agency will act as data controller for the data and messages held in their instance of iACT.
All information sharing using eCare iACT is based on reliable identification of the data subject across agencies. This requires each agency to ‘match’ (see Appendix C) individuals on their case load by comparing basic demographic data with a national reference source - the NHS CHI. If matching is successful, an entry will be created in the eCare index. The index does not hold any substantive person data and contains system identifiers and related data only. The identifiers are not exposed to other instance of iACT; they are used internally by the eCare Framework to link systems which have a match for a specific individual. eCare iACT information flows
Business
App iACT
3
10
1 eCare Framework
GIRFEC Specific Services
P2P
Services
8
11
Transitory
Store
1 eCare Index
Indexing
Services
Person Matching
Matching
Services
Index
Match
Requests
7
Matching Client
Matching
Clients
Matching
Control
6
Reference
Citizen Dataset
(CHI)
Matching
Service
4
5
12
Agency X
1 7 iACT
2
8
9
3
4
10
5
11
6
12
1 eCare / GIRFEC iACT PIA
Page 59
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
To avoid rekeying of basic demographic information, an agency may choose to integrate iACT with its main ‘Line of Business’ (LoB) or caseload system, so that iACT is synchronised with the data in the LoB iACT is integrated with the agency’s own system. iACT may also be used as a standalone system and data entered directly into iACT. Messages sent between one instance of iACT and another may have files or documents attached. eCare / GIRFEC iACT PIA
Page 60
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
The following table summarises the privacy risks identified in the initial technical analysis phase of the PIA, along with system privacy features design mitigations. These are mapped to the iACT Functional requirements to allow specific privacy features to be tested and validated in the iACT testing phase.
Id Title Description Impact
Assessment
Impact
(1-5)
Likelihood
(1-5)
Privacy
Risk
Group
F. Req. Design Options
3 1 iACT User
Access
Controls
Subject case or folder will be linked to practitioner(s). An inappropriate link may be created
Inappropriate staff get access or inappropriate information disclosed - breaks
'need to know'
3 eCare / GIRFEC iACT PIA
4 RQ0021
RQ0026
RQ0182
-Policy / practice guidance needs to be developed to provide guidance as to who can access sensitive information (e.g. only practitioners with a legitimate relationship to the data subject).
-The applications must support the appropriate level of granular access controls to ensure that organisations can operate efficiently and effectively whilst providing the appropriate privacy controls.
Version 1.0 Release
17/11/2010
Page 61

Efficiency and Transformational Government Division
2 Central case creation
3 Access by administrative staff
A central agency that creates a child's case may transfer ownership to a local agent or function. If changes to basic data are required, this could compromise controls access to sensitive case information.
What about
"administrative" staff
- what level of access do they require? Can they see all children's records?
Inappropriate staff get access or inappropriate information disclosed - breaks
'need to know'
Inappropriate staff get access or inappropriate information disclosed - breaks
'need to know'
3
3
2
4
4 RQ0022
RQ0023
4 RQ0062
RQ0130
The issue can be reduced by ensuring only minimal information is recorded within iACT, e.g. data subject contact phone numbers and supplementary addresses are not recorded in iACT but existing agency systems.
This also has the benefit of minimising any need for rekeying
View auditing - in your face who has viewed record
Administrators must select a user they are representing when capturing information on their behalf.
Training etc
Strong rules, guidance, management etc
-Other option is to only allow practitioners to maintain records - not realistic in all scenarios - but should be enforceable / configurable option eCare / GIRFEC iACT PIA
Page 62
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
4 Inappropriate access to sensitive information iACT hosting environment enables users to search / browse across information held by other agencies
Inappropriate access to multiple client records
5 2
5 Risk of unauthorised access to information across agency boundaries iACT messaging could result in data being disclosed to external agencies that is outwith scope of data sharing agreements or to inappropriate units / individuals within those agencies
Inappropriate disclosure - breach of DPA and ISPs and professional ethics eCare / GIRFEC iACT PIA
4
Page 63
2
3
3
RQ0208
RQ0256
RQ0256
The risk can be mitigated through a number of approaches:
- Highly federated data architecture - ensuring only the local data store can be physically searched (no central database)
- Access to search functionality is restricted.
- Returned results are based on legitimate relationships existing between the data subject and the user. This prevents users from searching across all data subjects.
- If administrative staff require the need to search iACT data must select the practitioner as part of the search. This will be audited.
- Appropriate information sharing protocols / contracts need to be in place before information can be shared
- Electronic systems must support the agreed protocols
- iACT must allow practitioner judgement over what to share and with whom;
Appropriate staff training and
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division development;
Information Governance regime
6 Demographic /
Personal
Information
Granularity
7 Manual
Matcher iACT demographic data not scoped appropriately
The manual matcher
(if required) would be aware of a match requirement from an agency - this reveals information about a person. This depends upon the granularity of the agency - e.g. may be NHS Board or may be "mental health".
There is a risk that sensitive information is being shared with the manual matcher.
This is a potential issue with the
Excessive data held on subject - data controller in breach of DPA
There is a risk that sensitive information is being shared with the manual matcher. This is a potential issue with the existing framework, but could be extenuated within iACT where there may be a more granular set of organisational units identified.
If there is no problem with matching, then there is no need to eCare / GIRFEC iACT PIA
3
3
Page 64
3
2
3
4
RQ0097
RQ0007
RQ0082
RQ0018
RQ0019
Apply principle of data minimisation to basic demographic data required for reliable identification
- By implementing a central matching service - there is a lower risk of the matching team knowing the data subjects. Also a small central team is easier to manage and put in place appropriate compliance controls reducing risk.
- There is no need for the manual matching tool to automatically display the agency requesting the match unless there is a problem with performing the manual match - reducing the amount of information revealed, even then it may suffice to reveal only a contact name and phone number.
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division existing framework, but could be extenuated within iACT where there may be a more granular set of organisational units identified. reveal the agency to the matcher - protecting privacy.
If there are problems performing match some manual intervention may be required (e.g. person not on CHI or cannot match uniquely).
- In principle the manual matcher could provide a mechanism to communicate anonymously with the requesting agency to provide clarification - though this may not be practical (Note that when a match goes to query status a notification is sent to the requestor - may be possible to move onus on requestor to get in touch) eCare / GIRFEC iACT PIA
Page 65
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
8 Risk of implementing a central index of
Person
Identifiers
To enable information sharing a central database of personal identifiers has been created to enable matching of data from multiple systems.
In principle the central index could allow aggregation of data from multiple sources.
In practice this is not possible within the secure communication context as no data is persisted in a central store.
Controls are also implemented to restrict access to the Index (see
Design
Options).With the introduction of
Secure
Communications requirements the
Index functionality is extended to enable the
CENTRAL P2P
Services within the eCare Framework to lookup all identifiers for a specified person to support the broadcast eCare / GIRFEC iACT PIA
4
Page 66
1 2 RQ0009 - No person information (e.g. name, address etc) is stored in the Index other than the identifiers used by agency applications (incl. iACT) - No public interfaces are provided to the index, and it is not possible to extract information from the index- the personal identifiers are never revealed to any users- the personal identifiers never leave the confines of the eCare Framework and only the eCare Framework can access the index.
- There is no search capability within the index (as no person information is stored)- the Index can only be accessed by the eCare
Framework - no direct access is provided to client applications (e.g. iACT)
- Agencies do not need to reveal public identifiers, if preferred they can use an
"random" alias that has no publicly understood meaning
- If the Index was to be used for multiple purposes (e.g. non-eCare purposes) then it would be desirable to provide
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division message requirements.
Note that no personal identifiers used by other systems are ever revealed. further partitioning of the index and identifiers to prevent cross-matching and aggregation of data. eCare / GIRFEC iACT PIA
Page 67
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
9 Broadcast message routing within iACT
Message are routed to users of an iACT instance dependent upon the involvements recorded - there may be scenarios where no current, valid relationship exists
There is a risk that communications are sent to default recipients that are and the information is not handled appropriately at the receiving agency
3
11 Message
Content -
Request for
Information
12 Should a default user see the content of a message to forward?
Message content is largely free text (with attachments). There is a risk that excessive information is shared.
Risk that the default user is exposed to inappropriate sensitive information
Breaks 'need to know' -
Inappropriate staff get access - breaks 'need to know'
3
2 eCare / GIRFEC iACT PIA
Page 68
3
3
2
2
2, 4
RQ0089
RQ0245
RQ0189
RQ0080
RQ0226
RQ0060
RQ0113
RQ0078
RQ0247
RQ0062
RQ0201
- Note that currently only
Agency Identification messages are broadcast.
- No sensitive information is provided within the content of the Request Agency
Identification Message
- This is a bigger issue for targeted messages which may be delivered to a default recipient. In this case the concept of an envelope should be used. All sensitive information is stored within the envelope and opening the envelope is an audited action and requires a reason to be recorded
Ensure that appropriate training and support is provided during implementation; data handling procedures and processes; support for
Protective Marking
Envelope concept - all sensitive information is stored within the envelope and opening the envelope is an audited action and requires a reason to be recorded
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
13 "Consent" sent to recipient
14 Is there a need to capture consent details in iACT?
Need to capture situation regarding awareness and consent. E.g. one parent may agree other may not, or may agree under certain circumstances.
It is essential that practitioners are aware of the consent status with regard to information sharing when they share information. This does not necessarily require the iACT application to record the status of consent
- however, each message sent should provide a guidance / awareness status describing the level of consent. It is important to remember that consensual status is a complex matter,
There is a risk that the practitioner may not be able to evaluate whether consent has been given - and will exercise judgement that may open to query and may expose the org to risk
There is a risk that the system may not be trusted by
Organisations as there is no explicit consent model, leading to low uptake and undermining the value of the application eCare / GIRFEC iACT PIA
3
3
Page 69
3
3
2 RQ0125
RQ0242
Child and families involvement in the decision to share will be recorded and included in the message to ensure that consent circumstances are understood
2 RQ0125
RQ0242
Child and families involvement in the decision to share will be recorded and included in the message to ensure that consent circumstances are understood;
Further engagement with key stakeholders may be necessary
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division especially in children's scenario where one parent may agree other may not, or may agree under certain circumstances. iACT may need a richer consent model where it is used as an agencies core system.
15 Who has received broadcast message?
With a Broadcast
Message there is a risk that the originator does not know who the recipients of the communication are.
Information may be sent to inappropriate individuals.
4 3 eCare / GIRFEC iACT PIA
2 RQ0033
RQ0189
RQ0080
- Risk can be reduced by restricting the information included in a Broadcast
Communication - Even if information is minimal there is a risk that through the use of broadcast communication it may be possible for the recipient to infer something from the name or organisational unit of the sender. It may be appropriate to provide an alias for the sender that does not reveal the specific sensitive information, e.g. sender may appear as
"Social Work" as opposed to
"Social Work - Substance
Version 1.0 Release
17/11/2010
Page 70

Efficiency and Transformational Government Division
Abuse".- It may be necessary to filter the target broadcast to reduce the range of recipients who may receive the broadcast, again reducing the chance that recipients (who have no direct interest) infer something from the communication eCare / GIRFEC iACT PIA
Page 71
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
16 Risk of inappropriate disclosure of personal information
By avoiding a central database that a user can search against there is a need to provide a more targeted approach to sharing information.
That is to say that only the minimum information is shared, and it is only shared when required and with appropriate individuals. This is achieved through the use of a point to point communication approach. The message recipient(s) is identified either by the sender selecting a specific user / service to receive the message or through use of a broadcast message that is sent to all organisations that have an involvement with the child (based on an index existing for the organisation).
Where a user manually selects the recipient of the communication there is always a chance of addressing the message to the incorrect person, leading to information being disclosed to inappropriate recipients eCare / GIRFEC iACT PIA
4
Page 72
2 2 RQ0090 - Incorrect recipient can to some extent be minimised by only allowing delivery of communications to those individuals with A legitimate relationship with the subject of the communication.
- Broadcast communications only contain minimal information. There is only one message type supported
- Request Agency
Involvement. No information is revealed except for the requesting Agency
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
There is a risk that the communication may be sent either to the wrong person
(through inaccurate selection) or to an organisation that has a relationship with the data subject, but who are not appropriate recipients of the message (e.g. due to its sensitive content). eCare / GIRFEC iACT PIA
Page 73
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
17 Forwarding of
Messaging
There is a risk that allowing communication to be forward increases the chance of information being shared inappropriately.
Can forward messages within instance of iACT.
Privacy controls would enforce controls around message forwarding.
Need to understand the controls that could be enforced - how many times can a message be forwarded, what happens if a message is sent to the wrong recipient?
Should originator receive notification of forward (not if broadcast message as they do not know recipient anyway).
Inappropriate staff get access or inappropriate information disclosed - breaks
'need to know'
4 eCare / GIRFEC iACT PIA
Page 74
2 2 RQ0096
RQ0207
RQ0126
RQ0124
There should be minimal restrictions around forwarding of messages as this would prevent practitioners from operating efficiently. However some controls are required:
- If the originator of the message has included a "No
Forward" restriction of the communication (e.g. too sensitive) then the system must enforce this. In this case the recipient must reply to the originator asking them to resend it to their colleague.
- There must be an explicit audit of who forwarded a comm. to who and the reason for forwarding
- There should be no automated notification to the originator of the communication when forwarded as this may reveal information that is not appropriate (e.g. for a
Request Involvement message this may reveal involvement, even though the practitioner did not wish this)
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
- A guidance note may be provided by the originator of the communication to indicate the terms under which information can be used (e.g. Happy for you to use as you see fit, to be shared with great care) - this is more guidance than something that can be enforced by the system.
18 Other mechanisms for further use of information
Once information is received by an iACT user, it may be used outside iACT -
Verbal / nonelectronic communication, printing, copying/saving, eCare / GIRFEC iACT PIA
4 3 2 RQ0061
RQ0083
Differentiate between a
"system licence" and "human readable" licence. The system licence may be capable of restricting how communications are used
(e.g. preventing printing or forwarding). The human licence will provide visual clues and guidance notes on usage, e.g. for your eyes only.
Version 1.0 Release
17/11/2010
Page 75

Efficiency and Transformational Government Division
19 Disclosure of sensitive involvement
The fact that a particular agency is involved with a client
(i.e. social work,
CAMH...) is itself sensitive
If this is revealed inadvertently or automatically, this could lead to inappropriate disclosure and breach of 'need to know'
4 2
21 Practitioner
Privacy
How much of the practitioner information should be stored in the central directory, as opposed to the local instance.
Risk that inappropriate levels of information are available in the directory, undermining its purpose and compromising user privacy
2 1 eCare / GIRFEC iACT PIA
RQ0220
RQ0153
RQ0229
2 RQ0251
RQ0043
RQ0090
RQ0187
RQ0035
A broadcast "Request for
Agency Identification" is sent to all iACT instances with a relationship to the data subject (based on Index entries). Users do not need to respond to this message - requester has no visibility of broadcast targets. Revealing the involvement is an active choice of the user. They requester has no visibility of progress (e.g. number of targets - as the fact that not everyone has replied implies something)
If practitioner information is shared across organisations then local practice should ensure that practitioners consent to this sharing.This would reveal their P2P address. May be no need to reveal personal P2P addresses as it could work off function based addresses; minimal data held in directory - only that which is necessary to identify practitioner or service
Version 1.0 Release
17/11/2010
Page 76

Efficiency and Transformational Government Division
22 Communication
Management
If communications aren't managed in a consistent manner, related to a specific
'case' there's a risk that access controls and or information management may be inadequate
Information may be accessed inappropriately, breaking 'need to know' or retained longer that is necessary, leading to breach in DPA compliance
3
24 Automatic
Response to
Request for
Identification
There is a risk that if automated responses to
Request for
Identification are allowed it may reveal information that a practitioner may choose to not reveal.
Agencies or practitioners may lose confidence in iACT, impacting on uptake and use.
3
3
2
2, 6
2
RQ0252
RQ0256
RQ0155 + requirements in Folders section
RQ0176
RQ0222
RQ0221
All communications are stored in a "folder" associated with a data subject.
The case provides a level of access control ensuring only those users with a legitimate relationship with the data subject can view the information.
All access and manipulation of information within the case will be audited.
It may be appropriate to provide more granular levels of control within a case.
Automated responses are only supported where there is a statutory requirement on practitioners to reveal their involvement. eCare / GIRFEC iACT PIA
Page 77
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
25 Involvement
Probing
26 Manipulation of message
Attachments
If a communication is targeted at an organisation that has not matched with the data subject, the system could automatically reply to state no match exists and the communication will not reach its intended recipient.
There is a risk that this would allow probing to indentify relationships (or lack of) - this is a significant privacy risk.
If attachments aren't secured to appropriate forensic standards, they could be tampered with, altering the content
Organisations may lose confidence in iACT; audit and traceability of decision could be compromised
2
3 eCare / GIRFEC iACT PIA
2 2 RQ0116
RQ0205
RQ0037
RQ0216
If no match exists in an instance for a targeted message then no response is sent to indicate "no match". Effectively the message disappears into the ether. It is not appropriate to send a no match response as this would allow people to probe to identify agencies that have a match (e.g. is the child known to the police).
Page 78
3 1, 2 RQ0113
RQ0078
RQ0211
RQ0247
RQ0248
-iACT must not allow a user to alter the content of an attachment that has been received in a communication.
-It should be possible for the sender of the communication to describe a level of access control around the attachment (e.g. do not allow printing or saving). This may require the use of a technology such as PDF, though it will always be dependent upon practitioner
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division training and guidance to respect the controls.
27 Non-
Requested
Despatch of
Information
The solution should support the ability to push free-text or information or attachments to an agency, that the sender believes they should be aware of
Information may be revealed inappropriately to the wrong recipient, breaking
'need to know'
3 3 1, 2 RQ0215
RQ0073
RQ0124
The recipient of the information must have a legitimate relationship with the data subject, this greatly reduces the chance of information going to the wrong recipient (e.g. if the wrong target is selected and they have no relationship with the data subject the message will not reach them).
The use of the Envelope concept would also reduce the risk of revealing too much info eCare / GIRFEC iACT PIA
Page 79
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
28 Request for
Action
With the Request for
Action message, iACT may push the matching criteria to the recipient (where no match exists) and provides the recipient with the ability to automatically populate the receiving system.
Information may be revealed inappropriately to the wrong recipient, breaking
'need to know'
2 2
29 Delegation of roles / permissions iACT provides the capacity to delegate access to another member of an organisation if this is not controlled properly,
Information may be revealed inappropriately to the wrong recipient, breaking
'need to know eCare / GIRFEC iACT PIA
3
Page 80
2
1, 2 RQ0205
RQ0102
RQ0085
The risk is reduced by transmitting no sensitive information in the message other than the request for assistance. However the basic matching information will potentially be revealed.
- Some potentially sensitive information will be included, specifically the involvement of the sending agency and the details of the request for action. It may be appropriate to not display the details of the data subject until the user "accepts" the request - in practice we are suggesting that they must not be shown the details of the data subject by default and must explicitly take an option to display them, thus avoiding revealing the data subject details unless the recipient actually needs to use them.
User guidance and training; 1, 2 RQ0051
RQ0227
RQ0129
RQ0164
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
30 Targeted
Message
If targeted recipient has no involvement with the case then message routed to the Lead
Professional / default user
Information may be revealed inappropriately to the wrong recipient, breaking
'need to know'
3 2 1, 2 RQ0250
RQ0101
RQ0086
RQ0179
RQ0243
User guidance and training; eCare / GIRFEC iACT PIA
Page 81
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
iACT does not utilise a central database through which information is shared.
Information is actively pushed from one user to another user through the use of messages or communications .
Communications contain semi-structured information. There are a number of different communications types, each
Org. A iACT eCare
Framework
Org. B iACT reflecting a different business need, each containing different information and governed by different business rules.
Send
Communication
Point to
Point
W/S
Receive
Communication
There is an instance of iACT per organisation. It is not possible to search for people or data across instances of iACT. Communications are stored within an organisation’s iACT instance and not in a central store. Note that whilst communications are transmitted between instances of iACT, using the eCare Framework Point To Point
Communication Web Services, they will be temporarily stored in a central database. It is not possible to search this central database, and communications are deleted from the central database once they have been downloaded by the iACT instance.
When sharing information it is necessary for the recipient to have a legitimate relationship with the child / data subject. If this relationship can be validated it greatly reduces the chances of information being delivered to the wrong recipient. In this context the technology establishes two levels of legitimate relationship, firstly that the organisation and
Org. A eCare
Framework
Org. B iACT iACT secondly that the individual user of iACT Folder
R
Point to
Point W/S
Folder has a legitimate relationship with the
Child XYZ
[Jo Bloggs]
Child ABC
[J. Bloggs] child.
Index
XYZ = ABC
The first level of relationship is established through the eCare Index. The Index provides a cross-reference between identifiers for a child / data eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 82

Efficiency and Transformational Government Division subject in the different systems that are participating in eCare data sharing. The Index is internal to eCare and only the eCare Framework (not iACT) can access the Index. Where the same child exists on multiple instances of iACT there will be a separate unique identifier for the child in the context of that iACT instance. The Index will cross-reference these identifiers, allowing each iACT instance to use / know only its own identifier when sending communications. The recipient iACT instance of the communication will not receive the sender’s identifier for the child, but its own identifier (based on the mapping in the Index).
The second level of relationship (i.e. user to child) is established through the concept of a
“ folder ”. A folder is an information container within an iACT instance. A folder is associated with one or more children who may be the subject of information sharing. Users of iACT can be associated with a folder, through their relationship with the child, e.g. as lead professional.
A user can only view a communication if there is a relationship established with the child in this way.
Getting it right information sharing model describes a practitioner need to identify other people who have an involvement with a child. Technically it would be possible to utilise the eCare Index to identify those relationships, however, this would reveal all relationships the child has, whether that is relevant to a specific concern or not. The
Broadcast communication enables a user of iACT to actively decide to reveal their involvement based on the merits of each
Child
Org. X
3. Decline to reveal involvement
2. Decline to
Agency X reveal involvement request. Broadcast communications are not sent to
2. Request
Organisation
Identification
4. No
involvement specific users, but to all iACT users with a legitimate
Org. A
Org. Z involvement with the child / citizen. The sender of the
5. Reveal involvement
Agency Z communication does not know
(automatically) who the recipients
Org. Y of the broadcast communication are. The broadcast communication only supports one communication type, Request for
Agency Identification; it does not support the other information sharing communication types.
Each broadcast communication is transmitted via the eCare Framework P2P service. When
P2P receives a broadcast communication it identifies those organisations (strictly, instances of iACT) that have an entry in the eCare Index (i.e. some sort of relationship with the citizen).
The message is sent to each iACT instance that has an involvement. Upon receiving a broadcast communication the iACT instance identifies the most appropriate user to receive the communication. As described in the “legitimate relationship” section above iACT establishes relationships between citizens and iACT users through the folder concept. The broadcast communication is delivered to each folder owner (i.e. the senior professional with an involvement). Up to this point the sender is not aware of who receives a communication.
The recipient now makes an informed choice to either reveal their involvement with the eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 83

Efficiency and Transformational Government Division citizen or not – as their professional judgement dictates.
The sender of a broadcast communication has the option to filter the range of recipients based on simple criteria e.g. only include health and social work organisations in a particular region. This allows a requester to focus the broadcast communication on the appropriate audience.
Information is shared on a targeted basis, i.e. the originator explicitly decides with whom they are sharing information. The target of a communication is either an individual or an organisational unit . An organisational unit is a unit within a larger organisational hierarchy.
For example, there may be a “South Team” within the Social Work department of a local authority. iACT will only deliver a communication to a recipient if they have a legitimate relationship with the child. The need for a legitimate relationship has a significant impact (as well as benefit). If a communication is targeted at a recipient with no relationship the communication must be managed in a controlled way and not simply disappear into the “ether”, as the message content may be
1. Target
Communication to team
2. iACT identifies the appropriate recipient in the team based on relationships in iACT critical to the safety of the
Org. X child. In such a scenario the Specific OU (Team) communication will be delivered to the iACT folder
Agency X
3. Decline to reveal involvement
Org. A owner for the child, as opposed to the intended
3. Target
4. iACT checks user recipient. Being the case holder they will automatically communication to specific user has legitimate relationship with child.
If this exists delivered
Org. Y to inbox have a legitimate relationship
Specific User with the child, but this does not
4. Decline to reveal necessarily mean it is appropriate for them to view the content of the communication. This is handled through the envelope concept, which prevents a user from automatically seeing the full content of the communication but should allow them to forward the communication to the appropriate recipient.
eCare / GIRFEC iACT PIA
Page 84
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
Whenever a user accesses a communication within iACT they will initially be presented with the communication envelope. The envelope is a wrapper around the most sensitive information within the communication. The envelope provides two key benefits:
1. It allows a user of iACT to verify that they are an appropriate recipient of the communication. This is not a failsafe, but does provide an additional layer of information shielding and the user must make an active choice to view the content.
2. Where a communication must be manually rerouted to an appropriate individual, e.g. where the communication was targeted to an inappropriate user or a user may be unavailable to process the communication, the envelope should provide enough information to support the routing to the most appropriate individual.
The envelope will display the least sensitive information required to support the business process, however, it is recognised that this information may still be sensitive in certain scenarios. Examples of the information displayed on the envelope include:
 Citizen’s name
 Sender’s details, including contact information (e.g. phone number)

Type of communication (e.g. Request for Agency Involvement, Request for
Information etc)

Reason (i.e. why I am communicating with you, may include what support the child needs)

Guidance and licensing information (describing how the communication content should be used by a recipient e.g. for your eyes only).
The following information will be stored in the content:

Date of birth

Gender

Address (there may be options to shield address given the potentially sensitive nature of this information in a children context)

Substantive detail of the communication, including any attachments (i.e. documents).
A full audit log of access to communications and the content within the envelope will be maintained. eCare / GIRFEC iACT PIA
Page 85
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
Data minimisation is a core design principle adopted for the iACT development. This is not only about reducing the amount of data shared, but enabling more effective sharing of knowledge, focusing on what is required to deliver the best outcomes to the citizen. If large datasets are shared, not only will the recipient be swamped by the volume of data and potentially miss the salient points, but it is likely that information will be shared that is not appropriate to the purpose for sharing.
Getting it right has identified five explicit scenarios for information sharing, see section. For each scenario there is a dataset describing the information shared. The details of the information shared in each message will be finalised following analysis of recent workshops and other communication activities. The important point here is that only a summary of information is shared. iACT does not support the capture or storage of detailed citizen or case information so it is not possible to transfer large volumes of data from existing case records in line of business applications.
There are two significant caveats to this. iACT does support the concept of communication attachments i.e. it is possible to attach electronic documents, such as PDFs or Word
Documents, to a communication. Also, many of the data fields within a communication are free text. This means that it is impossible for the system to prevent a user sharing information inappropriately. This is a governance issue that requires clear policies and procedures as well as comprehensive and regular training. Note that the envelope concept is also closely linked to the data minimisation approach by restricting the data that is accessible to users.
All information access or manipulation within the system must be recorded within the audit logs. The log must include recording by whom, when and where information was accessed, and in the case of information modification, what has changed. Within each organisation there must be explicit responsibilities allocated for reviewing the audit logs for patterns of inappropriate behaviour.
The most recent audit history may be displayed on screen by default when a citizen’s record is displayed within the system. This would provide a quick visual indication of inappropriate access, and should also act as a deterrent to users attempting to access information inappropriately. eCare / GIRFEC iACT PIA
Page 86
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
The eCare iACT application will handle sensitive information about children, some of whom may be vulnerable &/or at risk. It is essential that appropriate information security measures are in place to ensure the confidentiality, integrity and availability of information. The eCare iACT solution will leverage the existing eCare security architecture, which will be reviewed in light of the specific requirements of iACT and GIRFEC information sharing. This will include a formal security risk assessment, based on HMG IS1 & IS2 Information Assurance standards. To provide assurance to its stakeholders, eCare iACT security will be formally accredited by a panel of representatives from key stakeholder groups, such as NHS, Local
Authorities, Police, Scottish Government, and Atos Origin.
The technical security architecture will cover areas such as:

Security Management

Computer Installations

Networks

System Development

End User Environment.
Key technical security controls for the application may include:

Multi-factor authentication, i.e. using a number of different factors to provide your identity e.g. something you know , such as password and something you have , such as a security token;

Granular access controls, allowing each organisation to put in place controls around the functionality staff can access within iACT;

Strong encryption of information, both when information is transported across networks and when it is stored within databases;

Management of data to ensure that information cannot leak in an uncontrolled manner e.g. data and documents stored on local hard drives or USB sticks. eCare / GIRFEC iACT PIA
Page 87
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
Irrespective of the ways in which sensitive personal information is shared, be it electronic or manual, there is a need to put in place robust information governance arrangements to ensure that those with access to information understand the value and risks associated with the information, are familiar with relevant legal and regulatory requirements and good practice and are supported in applying them consistently in their day-to-day work when sharing personal information through iACT. While most agencies participating in GIRFEC will have exiting information management and information governance frameworks, a multiagency information governance capability is required to ensure that risks are managed in a consistent manner across the different agencies involved in iACT, which may have different approaches and differing legal and regulatory requirements.
To support information sharing there must be privacy governance defined at a number of levels:

National – providing an overarching governance framework with respect to privacy;

Organisational – tailoring and extending the governance model to the local needs of an organisation;

Information or communication level – providing privacy governance at the level of each individual exchange of information.
The governance framework will cover the following areas:

Enhancements to existing Information Sharing Protocols and related documentation, to ensure that GIRFEC information sharing eCare iACT is

An overall eCare iACT Community code of connection , defining the specific responsibilities of an agency and its staff when joining the iACT user community, to ensure that the consistent standards required to support safe, legal and trusted operation of eCare iACT are maintained;

An eCare Privacy strategy, setting out the eCare approach to privacy assurance and management;

Creation or identification of explicit eCare iACT information governance roles at different levels within organisations – to be defined following further consultation;

Common information governance and privacy policies and procedures
– these need to be defined at both national level, to provide an overarching framework within which individual organisations operate, and at the organisation level to provide local guidance on how information should be shared.

User documentation, guidance and training;

A framework for information governance compliance audit and assurance
The content of much of the information and privacy governance work will not be finalised until after the initial system pilot. eCare / GIRFEC iACT PIA
Page 88
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
10. Information Usage Guidance and Licensing per Communication
The sender of a communication has the option to attach licensing and guidance notes that describes how the information within the communication can be used by a recipient. The licensing model will take two forms, firstly a human readable form that will include visual clues such as explicit icons and a free text guidance note, e.g. for your eyes only, and secondly the idea of a system licence that eCare iACT can enforce, e.g. to prevent forwarding of communications. The details of the licensing model need further clarification, e.g. what aspects should they constrain (e.g. forwarding, printing etc). This will not be finalized until after the initial piloting of the system .
In addition to the above usage controls, each communication will include an indication of the level of consent and awareness provided by the citizen or their representative. Note that eCare iACT will not be the formal repository for capturing this information, which should be captured and recorded using the existing business mechanisms. eCare iACT will, however, provide a mechanism for attaching the information to each communication to inform the recipient. eCare / GIRFEC iACT PIA
Page 89
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
The table below presents risks and issues identified and discussed at the PIA workshops, mapped to the solution privacy features (see
Appendix x I).
Number Privacy Concern Addressed by Privacy
Feature No
Public Sector Practitioner workshop - Privacy features grouped by high-level risks
Comment / Action
Risk 1 Risk that information is shared with the wrong people
1 Safe havens
- Relationship with child
- Default Recipient
2, 4
2 What if there is no match and information has to be shared? n/a
The Legitimate Relationship and Targeted
Communications are the main mitigating design features. P2P (1), Information Security Framework
(8) and Information Usage Guidance and Licensing
(10) also contribute here
If there is no match then information cannot be shared in iACT Phase 1. This feature is planned for
Phase 2
This is not a privacy issue.
Risk 2 Risk of inappropriate disclosure of information eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 90

Efficiency and Transformational Government Division
3 Forwarding restricted information
- Could choose to forward
- Must be audited
- Override to be provided - Organisation / Agency to decide
10
4 DoB - culture item, may not be important
Risk 3 Risk of inappropriate access
5 Authorisation
- Do users need e.g. a key to access the system
6 Next person to access record should be able to see who accessed the record last
7 Must have the ability to tighten or slacken access to system
- System must be installed with tight access controls which can be slackened at a later date if required n/a
8
New
8
8 All access permissions to be maintained by systems administrator
Risk 4 Risk of Administrative staff accessing too much data
8, 9
If a communication is flagged as ‘No-Forwarding' the message cannot be forwarded.
New - functionality could be provided to allow the recipient to forward restricted communications but this would have to be approved for a later release
Problem for matching - not a privacy issue
Options will be presented by the iACT Security work stream
New - This could be an auditing enhancement. To be discussed.
For local implementation decision.
The system could be installed with tight security which could be slackened if found to be interfering with the way practitioners need to work ok eCare / GIRFEC iACT PIA
Page 91
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
9 Header to contain non-confidential subject of message
10 The amount of information in the header could be insufficient to perform administrative task
5, 6
11
12
13
Header to be appropriately labelled
Labels could be supplied from dropdown list e.g. Nits
Communications should have a priority rating
5
5
8, 5, 6
5, 6
It is up to the sender to ensure that the communication header does not contain confidential information. However, the sender must provide sufficient detail to enable a default recipient to re-direct the communication without having to open the full message.
The system will be operated by trained staff, who will be following policies and procedures to ensure that sufficient non-confidential information is provided in the header.
Evaluation of the Early Implementation sites will provide extra guidance on this topic.
The communication header will contain the minimum amount of non-confidential information necessary to enable the receiver to process the communication
New - For consideration
Priority ratings do exist; these are linked to the
GIRFEC Wellbeing Indicators. eCare / GIRFEC iACT PIA
Page 92
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
14 The response is not sent in time
Risk 5 Risk that information is shared about the wrong person
15 Wrong match occurs in either automatic or manual matching
16
17
18
One child is mistaken for another (practitioner accidentally choosing the wrong person)
9, 2
Must be an 'Are you sure' type message displayed and responded to before the communication is sent
There must be a process for recalling a communication that has been sent in error n/a eCare / GIRFEC iACT PIA
Page 93
4, 3 n/a
The communication will contain a 'Respond by
Date'. It is the responsibility of the practitioner to respond by this date. This is not a privacy issue.
Note: Each communication also contains an Expiry
Date. This allows P2P to archive the communication after this date if it has not been retrieved by an iACT instance.
Nothing can be done in the application to improve this. Matching is an eCare process that is performed by ISD.There is currently a manual process in the eCare Framework for correcting data issues including matching.
This is an operational / training issue.
However, iACT will stop the intended recipient from receiving the message if it is for the wrong child because the recipient must have a legitimate relationship with the child before they can receive a message about the child.
New - Not privacy issue but the request will be considered for future releases
New - This is an enhancement that could improve privacy. Will be considered for future releases
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
19 It must not be possible to have duplicate records.
20
Public Sector - Privacy features not tied to risks
Matching keys, only CHI?
22 Criteria for legitimate relationship
23 C Updating legitimate relationships
- Local policies to be created re handover periods
24 I Different IT system rules to 'see' children n/a
2
2 n/a
25 Striking balance between role based model and professional judgement
9
26
27 R Removed
28
29
Auditing is very important
Additional controls to improve local systems
Stipulation of rights required eCare / GIRFEC iACT PIA
Not privacy issue eCare Index will not allow more than 1 match for a person therefore it will not be possible to send any communications from a duplicate entry
7 n/a
8, 9
Currently matching on CHI only. This is not a privacy issue
Local and National policies and governance. Could be a privacy issue
Agencies will need policies here iACT is privacy compliant. It does not have a central database. This is a local implementation issue.
Privacy - a compliance based approach must be applied. iACT Phase 1 supports decision making and provides audit. Phase 2 will provide some role based modelling.
Yes
Removed
Not iACT
The iACT system will provide users with permissions and place them in groups.
Tied to 25
Version 1.0 Release
17/11/2010
Page 94

Efficiency and Transformational Government Division
30
31
32
Flexibility related to purpose
Discussions between professionals still required
Controls about Statutory broadcast
- Could be role related
33
34
Guidance preferable to prescription
Standard needed - iterative process
9
6 n/a
3
35 Data minimisation- Attachments issue - content has no control 6
36 Could be useful to store latest assessment
37 Attachments
- Data minimalised
- Where stored
- Where viewed eCare / GIRFEC iACT PIA
Page 95
6
6 iACT must not be too constraining iACT is one of many tools - not privacy
Various types of statutory override can be set up
Need high ranking person to authorise statutory messaging.
Tied to 25
Training material and guidance documentation.
Don't want to impose standards but general policy controls will be available.
There needs to be a common language and set of templates. Any standards must be flexible.
Minimised data but attachments can be added.
Each organisation will have to state if they are going to have rules around attachments. This could be a privacy issue.iACT keeps routine data for each child to a minimum. All data activity is audited.
An attachment could be used to provide this.
However, it may be better to view the assessment in eCare MAS.
This applies to eCare framework and iACT.
Ties back to 35
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
38 Common forms / attachments link to MAS
39
40
Attachments stored in iACT?
Clear about purpose to avoid functionality creep = privacy creep
41 Kite mark approach 9
42 MAS - iACT Attachment need?
Joint
Group
43
Voluntary Sector - Privacy features not tied to risks
What are the hosting arrangements for iACT? Could umbrella/infrastructure bodies (e.g. CVSs) provide hosting role for smaller organisations?
8
MAS will be used to view any common forms. iACT will provide access to MAS.
Linked with 36.
Yes they are stored in iACT. iACT is to be used for sending communications. We depend on the practitioners knowing what not to send
Policies will be developed about privacy principles.
This PIA is one of the clearest records. Also there will be regular reviews with the Information
Commissioners Office (ICO)
Future consideration - In time this may be done but would need rules
A centrally hosted solution is being looked at.We are interested in exploring a range of options and approaches to hosting.We note the suggestion that larger/umbrella bodies may be able to act as host for smaller voluntary bodies. eCare / GIRFEC iACT PIA
Page 96
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
44 Security control: will access to iACT be permissible for home workers and workers on the move/outwith their main office base? What about controls regarding seasonal workers, field workers, administrative staff etc?
8
45 Can third sector organisations be encouraged to take a greater sense of ownership/responsibility for high standards of governance, recording and management of their data on children?
How can the third sector be encouraged/supported to have effective auditing/monitoring of its own data management as part of its risk management?
9
These are valid issues that we will need to consider. Organisations in this sector will need to demonstrate that their own data/information governance arrangements are rigorous.
We will establish minimum standards for physical, technical and personnel security.
We will establish baseline standards and guidance on what these mean.
For all users of iACT we will provide guidance about our minimum standards for governance/recording and management of data as well as procedures for the use of iACT.
We are interested in your own views on how the third sector itself might best address these questions. eCare / GIRFEC iACT PIA
Page 97
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
46 How secure is it for a child’s address being used as a key piece of information to identify a child in iACT? More explanation is needed regarding the use of the child’s postal address as part of the iACT matching process; this is very sensitive information that could lead the wrong person to the child. iACT is about sharing the minimal amount of information required and does not cut across professional judgements about the sharing of sensitive data. For you to use iACT as an information sharing tool with other agencies, you must be prepared to submit some basic data to the iACT system so that the child concerned can be matched and identified. iACT asks you submit the child’s, DOB and postal address to help it match your child. Once the system has matched your child the data you sent is destroyed, i.e. it is only used for matching purposes and nothing else. It is not retained on the system and not broadcast/shared amongst agencies. When you are sharing information with another agency about a child that has already been matched and identified you yourself will determine what information to include or exclude, so there is no need to reveal a child’s postal address to another agency if you deem it inappropriate. eCare / GIRFEC iACT PIA
Page 98
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
47 What are the implications for children and young people who expect a totally confidential and or anonymised service from some voluntary organisations? What about those organisations who may not be able to give complete input in all five fields of information for a child. What is the child being supported by the voluntary organisation is in this country illegally so their data is especially sensitive/confidential?
Remember that iACT may not be the most appropriate communication tool for some agencies; other tools may suit you better. It will be for individual agencies to determine if they want to be part of iACT, it is not mandatory.Practitioners using iACT will ensure that data will only be shared with those who have a legitimate connection with the child, as part of their information governance responsibilities. Building confidence in secure information sharing is an incremental process, and one that needs to involve all stakeholders.
Processes like Privacy Impact Assessment and
Children’s Rights Impact Assessment can help aid stakeholder engagement and communication, through which this type of confidence can start to be built
48 What is the minimum level of standards that an organisation must comply with to be registered as an iACT participant? What verification of organisations’ standing might be used – e.g. verified by local CVS, providing a registered service, evidence of disclosed staff
9, 10
In principle, no organisation will be excluded from iACT provided they meet the minimum standards.
These are still to be determined.
The third sector’s own views on this question are of interest to us. eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 99

Efficiency and Transformational Government Division
49 What provision will there be for families accessing and understanding their own records/data held?
50
51
Will data be available for academic research?
Can more be explained about the sharing of data in relation to families, i.e. where an adult’s information is also recorded and relevant, where a child is yet to be born etc?
9
9, 10
Responses from NHS to written consultation
Need for grater clarity around management of consent 9 eCare / GIRFEC iACT PIA
8, 9, 7 We will try to make it easy for organisations to comply with data protection regulations when dealing with ‘subject access requests’.There are specific legal considerations under the Data
Protection legislation for health, social work and education. If a subject, e.g. parent, requests access request to information about a child, any decision to share that information has to be screened by an appropriate person to ensure that no harm may come to the child if it is disclosed to the subject.
No consideration has been given to this yet, but we will develop policies around this question. iACT’s focus is on GIRFEC. The Early
Implementation site will teach us more about the best balance to strike in relation to information sharing about relevant adults.
Each communication sent using the eCare iACT solution will include a statement about the involvement of the child and family with the case and the related data sharing. Guidance on management of consent will be developed by the
Getting it right programme.
Version 1.0 Release
17/11/2010
Page 100

Efficiency and Transformational Government Division
Only identify when necessary
1.1 People should not be asked to prove who they are unless it is necessary. A person making a general enquiry about a service should not need to provide any identifying information.
Ask for as little information as possible
1.2 People should be provided with an effective way of proving their identity or demonstrating entitlement to a service, based on the minimum level of information necessary. Therefore, public service organisations must only ask for the information they need in order to establish entitlement to a service. For example, if all that is needed is to eCare / GIRFEC iACT PIA
Page 101
Citizen identification will be carried out by participating agencies; the eCare matching framework will provide reliable identification across agencies without the need t for personal data to be shared.
Data minimisation – only basic demographic information is stored in iACT
In scope for delivery to pilot
In scope for delivery to pilot
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division know whether a person is retired, or over 18 years old, then no more information should be asked for.
Identify only once
1.3 For services which are used frequently and for which identification is needed, public service organisations should give people a simple way to register once. Thereafter, unless there is a statutory requirement to prove identity, in many cases a person should be able to access the service using a token, such as a bus pass or library card that proves their entitlement without revealing unnecessary personal information. In other circumstances, a user name and a password or elements of a password may be required.
Identify your organisation too
1.4 Public service organisations must provide ways for people to confirm that anyone claiming to represent the organisation, whether in person, by telephone, in writing or online, does in fact do so.
Ensure that authentication is effective and sufficiently reliable
1.5 The authentication methods [1] selected should take into account convenience to the individual and respect for the individual's privacy.
Organisations should also ensure that the means of checking identity are sufficiently reliable. In particular, they should take account of the extent to which the mechanism generates false rejections and acceptances and the consequences of these, including potential prevention of access to services or benefits, or failure to prevent fraud.
Public service organisations must not rely, as the sole means of authentication, on personal information such as mother's maiden name which is quite easily found out, as this may increase the risks of fraud.
Avoid discrimination eCare / GIRFEC iACT PIA
1.3 – 1.7 iACT does not currently support direct access by the public
Version 1.0 Release
17/11/2010
Page 102

Efficiency and Transformational Government Division
1.6 Organisations must take steps to ensure that people are not discriminated against unfairly (for example, on grounds of disability, age or ethnicity) or socially excluded as a result of the approach to identification or authentication.
Offer choice
1.7 As far as possible, people should be offered alternative ways to prove identity and / or entitlement.
Adopt privacy and security policies & procedures
2.1 Public service organisations using personal information on behalf of public authorities should adopt clear, coherent and verifiable policies on privacy and security. This should include policies which will aim to ensure that: a) a Privacy Impact Assessment (PIA) or proportionate equivalent is conducted and published prior to the implementation of a project which involves the collection of personal information; b) only the minimum amount of personal information needed for a specific purpose is collected, used or kept; that appropriate consent is obtained where necessary and that systems used for personal data comply with legal and regulatory requirements; c) the best available techniques are used to ensure the security of personal information throughout its lifecycle including while they are sharing information and through to archiving it; in particular, the organisation must abide by government standards for the use of encryption for the storage and transmission of this information; and that staff follow relevant guidance issued by the Information Commissioner's
Office (ICO) [1] and implement recommendations arising from the 2008 eCare / GIRFEC iACT PIA
Page 103
PIA; Information governance and Privacy framework
Version 1.0 Release
17/11/2010
In scope for delivery to pilot

Efficiency and Transformational Government Division
Scottish Government Data Handling in Government report; [2] d) personal data is only retained as long as is necessary and subsequently destroyed in a secure manner.
2.2 Public service organisations must ensure that the policies and standards are supported by appropriate procedures, control the use of authorisation and identity management systems and can deal effectively with compliance failures and breaches.
2.3 Responsibility and accountability for privacy should be assigned to a named senior management officer who reports to the Board or equivalent.
Audit
2.4 Public service organisations must be able to demonstrate that personal information can only be accessed by staff who need access to it. Organisations must ensure that they keep records of access to personal information, that there are alerts which prevent or identify inappropriate access and that access logs and alerts are reviewed regularly by line managers.
2.5 If a person discloses personal information to prove identity or entitlement, public service organisations should not take or retain copies of that information (such as scans of driving licences or utility bills) unless this is essential for legal or audit purposes. In such cases, it would not normally be necessary to retain a copy of the full document; only the minimum amount of information to fulfil the legal / audit purposes would be required.
Accompany personal information with metadata eCare / GIRFEC iACT PIA
Page 104
Information audit
Information governance and privacy framework
Communication envelope ; Information usage guidance iACT does not currently support direct access by the public
In scope for delivery to pilot
In scope for delivery to pilot
In scope for delivery to pilot
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
2.6 Where personal information is collected or stored, all reasonable steps should be taken to make sure that it is accompanied by information about the source, consent notice, permitted uses, retention period and other relevant metadata (i.e. data about data). Where information is shared within or beyond the public authority, it should be accompanied by this metadata to facilitate proper management of the information at its destination.
Facilitate oversight and reporting
2.7 The Scottish Government should work with the ICO to facilitate spot checks and the use of the ICO's forthcoming inspection powers and should co-operate with existing oversight organisations to include privacy issues in their inspections and reporting.
Apply Principles to contracts
2.8 Where public services are provided by non public sector organisations, organisations must acknowledge their duties in respect of personal information. [3] In particular, where a public body has a contract with the private sector or the third sector, the contractor must be contractually bound to adhere to best practice as outlined in these
Principles and other guidance. Public service organisations should ensure by contract that such organisations are required to permit the
ICO to undertake spot checks on the processing of personal data being carried out in relation to the delivery of public services.
Communication envelope – this accompanies the message and includes information about the content of the message and usage guidance w ;
Information usage guidance – this includes guidance from the initiating agency on the nature of the information and
The PIA and information governance and privacy framework will enable this process
Information governance and privacy framework will ensure that appropriate contractual mechanisms outline the respective roles and responsibilities of Data controller and processor for iACT data
In scope for delivery to pilot
In scope for delivery to pilot
Recommended for delivery to pilot eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 105

Efficiency and Transformational Government Division
Parliamentary scrutiny of privacy impacts by lead committees
2.9 Where new primary or subordinate legislation is proposed, consideration should be given as to whether privacy issues will arise. If so, an appropriate Privacy Impact Assessment should be undertaken and a summary of impacts should be submitted for consideration by the lead committee in the Scottish Parliament.
Carrying out Privacy Impact Assessments (PIAs)
3.1 Public service organisations must carry out an appropriate level of
PIA for any new initiative that enables access to services using IT and involves the collection, storage or use of personal information. Public service organisations must also carry out an appropriate level of a PIA if they are changing existing systems in ways which involve collection, storage or use of personal information.
3.2 Public service organisations should seek early involvement, at the policy development stage, of the ICO in Scotland.
3.3 Public service organisations must make PIA documents publicly available, with easy access, before a new initiative is implemented.
Auditing existing initiatives
3.4 Public service organisations should consider privacy and data protection audits for existing initiatives. [1] eCare / GIRFEC iACT PIA
GIRFEC policy developed prior to
Principles being available
PIA summarised in this report
To be applied to existing eCare Framework elements prior to iACT pilot
Recommended for delivery to pilot
Version 1.0 Release
17/11/2010
Page 106

Efficiency and Transformational Government Division
Acquiring and holding personal information
4.1 Public service organisations must minimise the personal information they hold, only acquire personal information for which they have a defined and specific need and ensure that such personal information is held only as long as is strictly necessary for the purposes for which it has been provided.
Avoid creating centralised databases of personal information
4.2 Organisations should seek to avoid creating large centralised databases of people's personal information. People's personal data should not be acquired and aggregated in a single place but maintained in separate data stores relevant to their specific business purpose.
Organisations or their employees can still draw together personal information held in more than one place, if there is a business need to do so. That presents a lower risk than aggregating and storing all the personal information in a single place.
Storing personal and transactional data separately
4.3 Public service organisations must as far as possible store information about people's access to services separately from their personal data, to minimise the risk of data loss and to ensure that even if one set of information is accessed improperly, this does not allow access to a wider range of information about individuals. This may be achieved through the avoidance of centralised databases (see 4.2 above).
Controlling access
4.4 Public service organisations should ensure that personal data is held
Data minimisation;
Privacy governance framework
Pont to point information sharing and federated database iACT does not currently support direct access by the public
Information security eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
In scope for delivery to pilot
In scope for delivery to pilot
In scope for delivery to
Page 107

Efficiency and Transformational Government Division securely (see 2.1c above), that their employees only have access to the minimum personal information they need and that audit records exist of all accesses to, changes to and uses of that data.
Storing identifying information
4.5 Public service organisations must consider whether identifying information needs to be stored in a database at all. In some cases, it might be preferable for people to hold and manage their own identifying information which can be accessed by the public service organisation when it is needed. This could be achieved, for example, by the information being held on a smartcard and accessed when required through a card reader.
Linking information between systems
4.6 Public service organisations should not share personal information unless it is strictly necessary. If a public service organisation needs to link personal information from different systems and databases, it should avoid sharing persistent identifiers; other mechanisms, such as matching, should be considered. If a public service organisation believes that persistent identifiers should be shared, it must publicly explain why.
Raise public awareness and understanding
5.1 The Scottish Government should work with public service organisations and others to raise the public's awareness and understanding about the issues covered in these Principles.
Educate people about identity management and privacy issues
5.2 Public service organisations must ensure that staff or contractors eCare / GIRFEC iACT PIA
Page 108 framework, communication envelope iACT does not currently support direct access by the public
Point to point information sharing, matching pilot
In scope for delivery to pilot
Lessons learned from iACT development and use of PIA will be written up and shared
Recommended for
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division who handle personal data on their behalf have and maintain a good working knowledge and understanding of identity management and privacy.
5.3 Public service organisations must take steps to ensure that their customers have enough information to make informed decisions about identity management and privacy. [1]
5.4 Public service organisations should remind people (both employees and the public) about the importance of protecting their personal data, including not disclosing their passwords or PIN numbers and not sharing their means of identification with others.
Inform and consult the public
5.5 If a public service organisation is planning or developing a system which involves personal information, it must inform and consult the public and particularly individual users (this is likely to be part of the PIA process). Where children are involved, it will be important to ensure that parents / guardians are also appropriately consulted. [2] Methods of consultation and involvement must match the needs of the audience. [3]
Justify and communicate choices
5.6 Public service organisations must work to build public confidence and trust in their systems and practices. They must explain and communicate why information is needed, how it is handled and where and why it is shared. They should also provide a clear explanation of the expected benefits and pitfalls of their authentication mechanisms.
Provide easy access to own data
5.7 Public service organisations should provide simple, quick and effective means for individuals to access information held about them. eCare / GIRFEC iACT PIA
Information governance and privacy framework;
Communications package
Information governance and privacy framework;
Communications package
Information governance and privacy framework;
Information governance
Version 1.0 Release
17/11/2010 pilot
Recommended for pilot
Recommended for pilot
Recommended for pilot
Recommended for pilot
Recommended for pilot
Page 109

Efficiency and Transformational Government Division
This might include secure electronic access to check and correct the data that is held on them (any such provision would need to be audited and regulated so that the security and accuracy of data is not compromised).
Duty to repair or redress
5.8 Where an individual demonstrates emotional or material harm arising from incorrect or misused personal information held about them, organisations should assume a duty to repair that information and redress the harm as appropriate. eCare / GIRFEC iACT PIA and privacy framework – direct access to data by the public is not currently in scope for iACT. However any data shared will be consented, following discussions between the child/family and the relevant practitioner, unless there is an overriding concern about the safety of the child. As with the current eCare
Framework, GIRFEC partnerships using iACT will develop procedures for coordination and management of Subject
Access requests.
Information governance and privacy framework - as with the current eCare Framework,
GIRFEC partnerships
Version 1.0 Release
17/11/2010
Page 110

Efficiency and Transformational Government Division using iACT will develop procedures for coordination and management of data correction eCare / GIRFEC iACT PIA
Page 111
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
As noted in other parts of this report, the security of the eCare iACT solution will be formally
Accredited, using the standard HMG IS2 Risk management and Accreditation of information systems process. Accreditation will involve risk assessment of the eCare iACT solution by accredited CLAS consultants and Accreditation of the security of the solution by an
Accreditation Panel drawn from key stakeholders. The Accreditation Panel will include representation from:

NHS Scotland

eCare Programme

Scottish Government

ACPOS

SOCITM / Scottish Local Authorities

GIRFEC Programme

Atos Origin (Data processor and hosting provider)
Following its review of the evidence presented in the Risk Management and Accreditation
Document Set (RMADS) and any requirements for the ongoing assessment or evidence of protective controls, the Accreditation panel will make a recommendation to the Senior
Information Risk Owner(s) (SIRO) in order to agree an “Accreditation Statement”, which will form part of the RMADS, confirming one of the following decisions:
1. Full Accreditation: the Panel is satisfied that the identified risks to the information system have been adequately and appropriately addressed, and that the residual risks are understood and accepted by the SRO or SIRO or;
2. Interim Accreditation: the Panel accepts that the information system may be operated within specified limitations (e.g. for a set period of time, or with limited functionality) while outstanding risk treatment work is completed. This decision will require the agreement of the SRO or SIRO or;
3. Refusal of Accreditation: the Panel considers that the residual risks to the information system have not been reduced to a level acceptable to the SRO or SIRO. eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 112

Efficiency and Transformational Government Division
Key products include:
No Name of product
1 Accreditation Panel Terms of
Reference
2
3
4
5
6
7
8
Business Impact Assessment
Statement of Security requirements
IS1 Security Risk assessment
Risk Management Accreditation
Document Set (RMADS) eCare Security Policy
IT Health Check eCare iACT Community Code of
Connection (CoCo)
Brief Description Phase
Outlines the role of the multi-agency
Accreditation Panel in assessment, assurance and formal accreditation of the security of eCare iACT
Required for pilot
Assessment by stakeholder representatives of the business impacts to eCare iACT (GIRFEC) in the event of compromises to Confidentiality,
Integrity and Availability of information stored and processed on the eCare iACT information system
Summarises the privacy and security requirements of GIRFEC and forms a
Statement of Privacy and Security
Requirements that is part of the eCare – iACT
Risk Management and Accreditation Set
HMG standard process for technical risk assessment and risk treatment of information systems.
Required for pilot
Required for pilot
Required for pilot
Standard documentation which supports the risk management and accreditation process and provides justification and accountability for risk management decisions, the basis for risk management in service and a reference for compliance monitoring.
Required for pilot
Required for pilot
Describes an eCare Security Policy for the eCare Framework, including the iACT application and the high level security requirements and procedures required of the agencies which integrate with eCare and/or use eCare iACT. The document also provides a policy framework for management, operational and technical choices related to Information
Security for eCare.
A technical analysis of a system to ensure correct implementation of security functions and the identification of vulnerabilities which may compromise the confidentiality, integrity or availability of information. This will be carried out before piloting of the iACT system and will be carried out on a regular basis during the lifetime of the system.
Agencies taking on eCare iACT will be expected to sign to the CoCo, which will set out
Required for pilot
Initial
Draft eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 113

Efficiency and Transformational Government Division key aspects of the acceptable use of eCare iACT and the security, data handling and related responsibilities of both agencies and individual iACT users.
Required for pilot eCare / GIRFEC iACT PIA
Page 114
Version 1.0 Release
17/11/2010

Efficiency and Transformational Government Division
The role of the Information Governance workstream will be to provide a policy and procedural framework to support appropriate data handling, privacy protection and ongoing legal and regulatory compliance as eCare iACT is piloted and implemented in support of
GIRFEC.
Key products include:
No Name of product
1
2
3
4
4
5
6
Update to local Information
Sharing Protocols (ISPs)
Data policy
IG training materials
PIA Audit and review
Privacy strategy
Brief Description
Extension of existing local ISPs to cover
GIRFEC purposes. This will include the need to share information across existing Data Sharing
Partnership boundaries and the inclusion of new partner agencies.
Sets out policy on key aspects of information management in relation to eCare iACT and the roles and responsibilities of the Data processor and Partners agencies.
Standard operating procedures: Documents and templates outlining key processes for coordination between the Data
Processor and data controllers, including:
Data Correction
Subject Access Requests
Incident and breach management
Privacy communication materials
Phase
Required for Pilot
Initial draft required for pilot
Initial draft required for pilot
Public-facing documentation with key messages, and statements on privacy protection and subject rights in relation to eCare iACT and
GIRFEC
Required for national roll-out
Documents and templates relating to good practice in data handling for use in local agencies’ GIRFEC change management and organisational development activities.
Regular processes for assuring the implementation and effective operation of the technical and procedural privacy controls referenced and the PIA Report.
Will set out the eCare Programme’s strategic approach to ensuring that privacy continues to be at the heart of the eCare approach to multiagency data sharing and the benefits which this brings to the users of eCare and the citizens whose data is managed using eCare. The role of
PIAs will be defined within the privacy strategy
Required for national roll-out
Required for Pilot
Required for national roll-out eCare / GIRFEC iACT PIA Version 1.0 Release
17/11/2010
Page 115

Efficiency and Transformational Government Division and the privacy strategy will be part of the eCare
Programme’s broader strategic planning.
7 Ongoing risk and issue management
Required for Pilot eCare / GIRFEC iACT PIA
Page 116
Version 1.0 Release
17/11/2010