Transformational Technologies Division
Transformational Technologies Division
eCare Multi-Agency Store Data Model
Version 2.9
001-11334N-087
Document Version 1.4
Release
Copyright of the Scottish Ministers.
.
Transformational Technologies Division
Document Control
Document Configuration
Title
eCare Multi-Agency Store Data Model Version 2.9
Status
Release
Filename
eCare MAS Data Model 2.9
Author(s)
John Wilson
Issuer
Scottish Government, Transformational Technologies Division
Issue Number
1.4
Issue Date
28/03/2008
Classification
Release
Supersedes
Version 1.3 of eCare Multi-Agency Store Data Model Version 2.8
Document Approvals
Name
Position
Signature
Kerr Donaldson
Head of eCare Design
Authority, Scottish
Government
Date
28/03/2008
Document History
Version
Date
Author
Description
0.1
18/02/2005
JW
0.2
21/04/2005
JW
Amendments as detailed in section 1.11.1
1.0
22/08/2005
JW
Amendments as detailed in section 1.11.2
1.1
14/02/2006
JW
Amendments as detailed in section 1.11.3
1.2
22/11/2006
JW
Amendments as detailed in section 1.11.4
1.3
05/03/2007
JW
Amendments as detailed in section 1.11.5
1.4
28/03/2008
JW
Amendments as detailed in section 1.11.6
Document Review
Name
Position
Company
Robbie Harris
Senior Technical Architect
Scottish Government
Calum Sutherland
Senior Technical Architect
Atos Origin
Kerr Donaldson
Head of eCare Design Authority
Scottish Government
Document Distribution
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 2
Transformational Technologies Division
Name
Position
Company
Gary Johnston
eCare Policy Officer
Scottish Government
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 3
Transformational Technologies Division
Table of Contents
1.
Introduction
10
1.1
Objectives
10
1.2
Background
10
1.3
Document Context
10
1.4
Overview
11
1.4.1
The core Data Model
12
1.4.2
Disclosure conditions for personal data
12
1.4.3
Processes, Events and Status Episodes
12
1.4.4
Forms
13
1.4.5
Security and Auditing
13
1.4.6
Notifications
13
1.4.7
Child Protection Messages
13
1.5
Stakeholders
14
1.6
Stakeholder Concerns
14
1.7
Scope
18
1.8
Out of Scope
19
1.9
References
20
1.10
Terminology
21
1.11
Amendment History
21
1.11.1
Amendments made in Version 0.2 Draft
21
1.11.2
Amendments made in Version 1.0 Release
22
1.11.3
Amendments made in Version 1.1 Release
23
1.11.4
Amendments made in Version 1.2 Release
24
1.11.5
Amendments made in Version 1.3 Release
25
1.11.6
Amendments made in Version 1.4 Release
25
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 4
Transformational Technologies Division
2.
Core MAS Data: General Principles
27
2.1
A modular description of the MAS Data Model
27
2.2
Person data
29
2.3
Indexing
30
2.4
Controlled Vocabularies
31
2.5
Organisations
31
2.6
Temporal data
31
2.7
Boolean attributes and flag entities
32
2.8
Logical Data Model for Core MAS Data
33
3.
Core MAS Data: The data model in detail
35
3.1
The Indexing system
35
3.2
Controlled Vocabularies
35
3.3
Names
37
3.4
Addresses
38
3.5
Contact details
39
3.6
Persons, Subjects and Professionals
40
3.6.1
Person references
41
3.6.2
Subordinate Subject entities
42
3.6.3
Warning flags
42
3.6.4
Link entities
44
3.7
Organisations
44
3.8
Local identifiers for core data
45
4.
Disclosure Conditions for Personal Data
47
4.1
The conditions for sharing personal data
47
4.2
Logical Data Model for Disclosure Conditions
48
4.3
The Consent and Disclosure entities in detail
49
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 5
Transformational Technologies Division
4.4
Updating and viewing Subject data in the MAS
51
5.
Dynamic Entities: Processes, Status Episodes and Events
53
5.1
Background
53
5.2
The three dynamic entities
54
5.3
Processes versus Events
55
5.4
Processes
56
5.5
Events and Chronologies
60
5.6
Status Episodes
62
5.7
Extension attributes
63
5.8
Logical Data Model for Dynamic Entities
64
6.
Dynamic Entities: The data model in detail
66
6.1
Processes
66
6.2
Events
68
6.3
Status Episodes
69
6.4
The Extension Set
70
6.5
A shared overview of case-related activity
71
6.6
Local identifiers for dynamic entities
72
7.
Children’s Services Phase 1
74
7.1
The scope of Children’s Services Phase 1 requirements
74
7.2
The two SCDS2 Children’s datasets
76
7.3
The Children’s High-level (General) Assessment Dataset
78
7.3.1
Social Work Legal Status (Children’s)
78
7.3.2
Current Child Protection Registration and Child Protection History 78
7.3.3
Child potentially at risk from a specific individual
79
7.3.4
Child affected by disability
80
7.3.5
Education establishment details
80
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 6
Transformational Technologies Division
7.3.6
Children Reporter’s Administration involvement
81
7.3.7
Concern(s) expressed about a child
81
7.3.8
Looked After or Accommodated Episodes
82
7.4
The Integrated Children’s Service Record Dataset
82
7.4.1
Student stage
82
7.4.2
Difficulty in learning
82
7.4.3
Request for assistance / referral
82
7.4.4
Current and previous assessment details
84
7.4.5
Record of home visits by professionals
84
7.4.6
Record of appointments and visits to establishments
84
7.4.7
Developmental factors and significant health conditions
85
8.
Forms
86
8.1
The handling of Forms within the MAS Data Model
86
8.2
Recent evolution of the Forms component
86
8.3
Logical Data Model for Forms
87
8.4
The Forms component entities
88
8.4.1
Forms, FormTypes and FormVersions
88
8.4.2
FormStates
89
8.4.3
Sections and FormSections
90
8.4.4
QuestionGroupings and FormGroupings
90
8.4.5
Questions and Responses
91
8.4.6
Visual presentation
92
8.4.7
Mandatory questions
93
8.4.8
Question flow control
93
8.4.9
Calculations
94
8.4.10
Form Locking History
95
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 7
Transformational Technologies Division
9.
Security and Auditing Requirements
96
9.1
Background
96
9.2
Security
96
9.2.1
System Authentication
96
9.2.2
Classification of Interface Systems
97
9.3
Auditing
97
9.3.1
The eCare Audit Framework
97
9.3.2
Updates not mediated through the Messaging system
99
9.3.3
Impact on the MAS Data Model
100
9.4
Logical Data Model for Auditing
101
10.
eCare Notifications
102
10.1
Background
102
10.2
Definition
102
10.3
Potential uses for notifications
103
10.4
MAS Update Notifications
104
10.4.1
Principles governing update notifications
104
10.4.2
Granularity of update notifications
105
10.4.3
Presentation of notifications
106
10.5
Alerts
107
10.5.1
Alerts as to risk
107
10.5.2
Other types of alert
107
10.6
Matching Notifications
108
10.7
Logical Data Model for Notifications
108
11.
Child Protection Messages
109
11.1
Background
109
11.2
CPMs in the national Multi-Agency Store
110
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 8
Transformational Technologies Division
11.3
Information required for Child Protection Messages
111
11.3.1
CPMs for the “primary” child
111
11.3.2
CPMs for a “linked” child
114
11.4
Logical Data Model for Child Protection Messages
114
11.5
Update of Child Protection Messages
115
12.
Data Dictionary
116
12.1
Introduction
116
12.2
Data Dictionary for Core MAS Data
116
12.3
Data Dictionary for Disclosure Conditions
123
12.4
Data Dictionary and Extension Attributes for Dynamic Entities
125
12.4.1
Data Dictionary for Dynamic Entities
125
12.4.2
Extension Attributes for Dynamic Entity Types
129
12.4.3
Summary Relationship of SCDS2 Datasets to Data Model
134
12.5
Data Dictionary for Forms
137
12.6
Data Dictionary for Auditing
143
12.7
Data Dictionary for Notifications
144
12.8
Extension attributes for Subject Warning Flags (CPMs)
145
13.
Controlled Vocabularies
146
13.1
Current CVs
146
13.2
Deprecated CVs
189
Appendix A - Derived Requirements
192
Appendix B - The SCDS Data Item Summary
196
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 9
Transformational Technologies Division
1.
Introduction
1.1
Objectives
This document describes the Data Model for the eCare Multi-Agency Store (MAS), a
component of the national data sharing framework for Scotland, managed by the
Transformational Technologies Division of the Scottish Government (see 1.2 below).
The Scottish Government acknowledges the contribution of Atos Origin to the production of
this document.
1.2
Background
The eCare Programme was originally conceived to support the objectives of the 21st Century
Government and Joint Future agendas, and was a fundamental part of the Modernising
Government Fund – Round 1 (MGF-1). MGF Round 2 sought to maximise the benefit of the
MGF-1 outcomes, by rolling out the framework to other areas of Scotland and to other client
groups (e.g. children). In this way, the programme continued to support the long-term
objectives of service modernisation and improvements in the citizen’s experience. eCare,
and its sister programme, the Social Care Data Standards Project, have evolved to become
the Transformational Technologies Division of the Scottish Government’s Public Service
Reform Directorate. The Division supports better outcomes for citizens by enabling data
sharing through a federated network of 14 Data Sharing Partnerships across Scotland.
The purpose of the eCare Framework is to enable information to be shared securely across
agency boundaries. As a part of the MGF-2 round, the eCare Programme created the data
architecture for a nationally defined Multi-Agency Store implementation that contains the data
entities all agencies, regardless of geographical location, will need to share. This document
describes this architecture by providing and documenting a logical data model for the
nationally defined entities in the MAS.
1.3
Document Context
Based on the Architecture Reference Model described in the eCare Conceptual Solution [1],
the context of this document in relation to the other architectural documents required for this
project is as follows:
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 10
Transformational Technologies Division
Architectural
Description
Conceptual Architecture
Logical Architecture
Physical Architecture
Security
Architecture
Infrastructure
Architecture
Data
Data Architecture
Architecture
Application
Architecture
Support
Architecture
Data Policy
Common
Data Model
The Architectural Description itself covers the Conceptual, Logical and Physical layers of the
Reference Model. These will cover the fields of Security, Infrastructure, Applications, Data
and Support. These fields will individually deliver Implementation layer specific detail. In
addition each field will itself document its conceptual, logical and physical architecture.
This document forms part of the data architecture for eCare and documents the Dataset and
Model for the eCare MAS Data Architecture.
1.4
Overview
This document proposes a Logical Data Model for the eCare Multi-Agency Store. The model
is based on the national data standards for information sharing initially developed by the
Scottish Social Care Data Standards Project (SCDS2). These data standards were designed
to be compliant with the e-Government Interoperability Framework (e-GIF), the eGovernment Metadata Standard (e-GMS), the Government Data Standards Catalogue
(GDSC) and the Openscotland Information Age Framework (OSIAF). Data and technical
standards for the MAS are now managed by the Standards Branch of the Transformational
Technologies Division.
This document forms part of the systems architectural description of the eCare Project. IEEE
Standard 1471-2000 "IEEE Recommended Practice for Architectural Description of SoftwareIntensive Systems", which has informed this document, states that the "[q]uality of an
architectural description refers to its capability to meet the needs and concerns of the
stakeholders for whom it was constructed." The stakeholders and their concerns for this
document are listed in sections 1.5 and 1.6 below.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 11
Transformational Technologies Division
The MAS Data Model contains six principal elements, together with a more recent and
relatively minor addition that provides the basis for a Child Protection Messaging service.
1.4.1 The core Data Model
The first element in the eCare Multi-Agency Store Data Model is the central “core” of the
Data Model, which encompasses the entities that are most fundamental to information
sharing about persons. The scope of the core model extends to names, addresses,
demographic data and other key items of personal data. These key items include the
relationships of the primary subjects of information sharing to the professionals who are
involved in their care, and to other “associated persons” such as carers about whom some
limited information may need to be shared. The core model formerly included the entities that
support the indexing of the persons about whom information is shared, but these have now
(Version 1.4 of this document) been transferred to the Hub Data Model document [11]; it
continues to encompass the entities that support the storage and management of controlled
vocabularies (CVs). The core model is described in sections 2 and 3 of this document.
Note that the “persons” who constitute the primary subjects of information sharing through
the Multi-Agency Store may be either adults or children. This unitary approach enables
intelligible relationships to be established across traditional service boundaries – e.g.
between a parent with needs that are met through Community Care and a child who is the
subject of a Children’s Services concern. It should also provide the basis for a better
transition when a child progresses to adulthood.
1.4.2 Disclosure conditions for personal data
The second element in the Data Model comprises the small number of entities that are
required to record the operational basis for sharing data about a particular person through
the MAS. These supplementary entities encompass both the person’s own consent to
sharing (if this has been given) and the authorisation of disclosure by each of the interface
systems contributing to the data holding for that person on the MAS. This element is
described in section 4 of this document.
1.4.3 Processes, Events and Status Episodes
The subject-matter for the third Data Model element is the cluster of “dynamic” entities –
Processes, Events and what are here termed Status Episodes – which encapsulate the
stream of on-going, service-relevant activity that relates to a particular subject of information
sharing. In data model terms, these entities – particularly processes – provide a kind of
connecting link between the subject and the detailed information that is typically recorded in
a form. The three dynamic entities are described in generic terms, with a view to providing a
clear but flexible basis within the Data Model for any future extension of eCare business
requirements. At the same time, provision is made for extending the standard attribute set for
a specific type of process, event or status episode about which additional data items need to
be recorded and shared in a standard way.
This third element in the Data Model is designed to support a chronological outline view of
the main activity surrounding a subject. It will also allow different dynamic entities to be linked
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 12
Transformational Technologies Division
together in an easily comprehensible way. The general features of dynamic entities are
described in sections 5 and 6.
Section 7 is addressed to the specific information sharing requirements of Children’s
Services. Children’s Services Phase 1 (CSP1) covers all the requirements for the eCART /
MAS Children’s High-level (General) Assessment Dataset [6] together with a first tranche of
the requirements for the Integrated Children’s Service Record dataset [7]. So far as the MAS
Data Model itself is concerned, the CSP1 requirements are now fully met through the first
and third data model elements described in this document (i.e. the main “core” and “dynamic
entities” elements). They do however require the introduction of a number of additional
“extension attributes” for those Process Types, Event Types and Status Episode Types that
are specific to Children’s Services. Section 7 includes a detailed review of the two children’s
datasets that form the basis of CSP1 and explains how their data items are reflected within
the Data Model.
1.4.4 Forms
The fourth element adds a Forms component to the model for the eCare MAS. The effect of
this is to support a locally configurable question and answer format for the capture of
shareable information where there is no requirement to express this through the fully
structured medium of defined entities and attributes. The Forms component is designed to be
flexibly applicable both to nationally standard forms and to any forms that are in purely local
use. It is described in section 8.
1.4.5 Security and Auditing
The fifth element formerly added necessary Security and Auditing features to the model for
the eCare MAS, but is now (Version 1.4 of this document) restricted to the Auditing features.
Both an Audit Log and a Message Log are introduced into the model. Two attributes are
added to all entities that are liable to update by Partner or Agency Systems. This element is
described in section 9.
1.4.6 Notifications
The sixth element sets out the current understanding of eCare notifications and alerts
relating to the Multi-Agency Store. It is now (Version 1.4 of this document) restricted to a
general discussion of notifications, the model itself having been transferred to the Hub Data
Model document [11]. This element is described in section 10.
1.4.7 Child Protection Messages
Finally, a small enhancement has been introduced with a view to supporting a Child
Protection Messaging service. This is described in section 11.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 13
Transformational Technologies Division
1.5
Stakeholders
Stakeholder
Representative(s)
eCare Programme,
Transformational Technologies
Division
Robert Forman, eCare Programme Manager
eCare Design Authority,
Transformational Technologies
Division
Kerr Donaldson, Head of eCare Design Authority
Atos Origin
Richard Lockwood, Programme Manager
1.6
Stakeholder Concerns
This document is based on the following stakeholder concerns. All stakeholder concerns are
assumed to be at ‘Not Yet Agreed’ status with no priority. Where such concerns are based
on assumptions or logical derivations of stated visions, this will be noted. References
prefaced by RC0.3 are taken from the eCare Programme Requirements Catalogue Version
0.3 [4].
Reference
Description
Stakeholder
RC0.3 / 32
Develop generic solutions wherever possible
eCare Technical
PID v1.1
RC0.3 / 35
Provide a single shared view of patients’/clients’ data across
health, social work and education, all communication to
occur via the central repository (which acts as the hub, with
the co-operating end point systems as the ‘spokes’)
eCare Technical
PID v1.1
RC0.3 / 36
Store client/patient entry for each source system
eCare Technical
PID v1.1
RC0.3 / 37
Establish and maintain a single patient/client index
eCare Technical
PID v1.1
RC0.3 / 38
Patient/client index to be populated with demographics from
all collaborating systems and supported by the NHS UPI/CHI
system to maintain GP / Practice and demographic details
eCare Technical
PID v1.1
RC0.3 / 40
eCare should allow users to search, view and amend client
assessment data
Assessment structures that can be customised and shared
between partners in a controlled manner
eCare Technical
PID v1.1
RC0.3 / 44
Provide a technical product set made up of components
suitable for use by all MGF2 partners
eCare Programme
PID
RC0.3 / 45
Provide a Technical Product Set made up of components
suitable for use by all MGF2 partners
eCare Programme
PID
RC0.3 / 41
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
eCare Technical
PID v1.1
Version: 1.4 Release
28/03/2008
Page 14
Transformational Technologies Division
Message and notification types to be determined but may
include:
 patient/client details
 patient/client addresses
 consent status
 basic documents
 referral core data set
 allocation to health / social care practitioners
 assessments
 care plans
 service provision
 reviews
 eCare Patient/Client Summary
 messages and alerts (with local control over triggers
and event driven)
 publishing standard eCare summaries
 children’s at risk register
Customisable tree-like structure for organising associated
information
eCare Technical
PID v1.1
Personal records could contain demographics information,
latest hospital visit, SW assessment details, housing
requirements and, if a child, educational details,
immunisations etc.
Support the recognized addressing standard BS7666
eCare Programme
PID
The appropriate health or social care practitioner needs to
be alerted when any significant event has affected a
patient/client in their care
The exchange of information must be patient/client centred
and be structured to match the business processes
eCare Technical
PID v1.1
RC0.3 / 72
End user messages alerts and notifications are required to
support a workflow capability within collaborating eCare
systems.
eCare Technical
PID v1.1
Appendix E
(eCare Technical
option Appraisal)
RC0.3 / 74
Single Shared Assessment (SSA); this will deliver the
exchange of data including referrals, assessments, care
planning and service provision, reviews and client summary.
Children’s services (including the Scottish Children’s
Reporters Administration); this will deliver the development
and testing of a variety of practical information services and
supports for children and their carers. This will range from
the simple and universal (e.g. an easily available record of
inoculations) to the specialist and complex (e.g. an electronic
framework for the assessment of Children in Need). These
products will include:
 A ‘Personal Care Record’…;
 An ‘Integrated Children’s Services Record’;
 Progress on an agreed national ‘Single Assessment
eCare Programme
PID
RC0.3 / 50
RC0.3 / 53
RC0.3 / 58
RC0.3 / 66
RC0.3 / 70
RC0.3 / 71
RC0.3 / 75
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
eCare Technical
PID v1.1
eCare Technical
PID v1.1
eCare Technical
PID v1.1
eCare Programme
PID
Version: 1.4 Release
28/03/2008
Page 15
Transformational Technologies Division
Framework’;
…Take into account the growing scope of the ScotXed
RC0.3 / 78
project – particularly with regard to the structure and content
of the pupil record …
Specify a minimum standard data set for Person and
Assessment information for sharing through a central store
and store that minimum personal information.
eCART Overview
RC0.3 / 79
The system will enable Assessment and other detailed data
to be stored and shared.
eCART Overview
RC0.3 / 80
Implement a Scottish standard for storing Activity Recording
information within Single Shared Assessment, Child
Services and Learning Disability.
Maintain Activity Recording information including Referral,
Assessment information (questions and answers), Care
Plans (what you wish for), Services (what is delivered),
Reviews and Contacts.
User definable ability to store additional local data items
against eCare index
eCART Overview
RC0.3 / 83
Enforce centrally defined data standards
eCART Overview
RC0.3 / 87
eCART Overview
RC0.3 / 89
Provide security to ensure that all personally identifiable
information is stored to a level of confidentiality that meets
Scottish Executive requirements
Allow locally defined assessment information to be
maintained to meet a specific local business need
Compile single ‘trusted’ eCare view of client/patient details
RC0.3 / 90
Broadcast updates to collaborating systems
e-CART Technical
PID
RC0.3 / 95
There is a requirement to share agreed standard data sets to
allow information sharing across Local Authority and Health
Board boundaries and with central agencies
eCare Technical
PID v1.1
RC0.3 / 103
The system will maintain an index of cross-references of
patient identifiers
eCare Programme
Board
RC0.3 / 104
The system will maintain a list of professionals
eCare Programme
Board
RC0.3 / 119
All entities and attributes (excluding key candidates)
described by the Multi Agency Store Data Model are optional
in the sense that data may or may not be recorded therein
RC0.3 / 120
All physical implementations must provide a mechanism to
ensure that a full audit history of all access and changes to
MAS data is maintained
RC0.3 / 127
Describe a harmonised approach that can provide a
structure for controlled change and extension of the eCare
data products
RC0.3 / 81
RC0.3 / 82
RC0.3 / 88
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
eCART Overview
eCare Technical
PID v1.1
eCART Overview
eCare Technical
PID v1.1
eCare Data Policy
Document
Version: 1.4 Release
28/03/2008
Page 16
Transformational Technologies Division
RC0.3 / 130
Provide a secure maintainable audit trail and archive it
eCare Data Policy
Document
RC0.3 / 132
The eCare data design should conform to national data
standards, as defined by SCDS2
eCare Data Policy
Document
RC0.3 / 133
Model deviations from SCDS2 and other national data
standards are permitted providing these are documented
and agreed with SCDS2
eCare Data Policy
Document
RC0.3 / 134
The data models produced will be implemented by local
eCare partnerships as standard, though extendible,
database schema
eCare Data Policy
Document
RC0.3 / 136
Local eCare partnerships will be required to pre-populate
certain locally defined Controlled Vocabularies
eCare Data Policy
Document
RC0.3 / 159
An auditing solution for eCare must record successful and
failed security principle access to the data model
eCare Data Policy
Document
RC0.3 / 160
An auditing solution for eCare must record exception
conditions raised by the application platform.
eCare Data Policy
Document
RC0.3 / 161
An auditing solution for eCare must be time and date
stamped.
eCare Data Policy
Document
RC0.3 / 163
An auditing solution for eCare must ensure that the creation
of the audit trail does not obscure existing information.
eCare Data Policy
Document
RC0.3 / 165
An auditing solution for eCare must ensure secure
availability of audit trails for review and reporting purposes.
eCare Data Policy
Document
RC0.3 / 166
An auditing solution for eCare must be scalable, extensible
and efficient.
eCare Data Policy
Document
RC0.3 / 216
A notification that the MAS has been changed will be created
at the same level of granularity as the web service that
caused the change.
Data workshop
4/11/2004
SCDS1007
Must be able to capture a chronology of information about
significant events, contacts or interventions (‘events
chronology’) relating to any specific child or adult
client/service user whose details are held within an eCare
MAS
SCDS2
SCDS1008
Must be able to share events chronologies via the MAS
SCDS2
SCDS1009
Events chronology must capture information about planned
and unplanned (crisis) interventions that occur in the context
of care provision…
SCDS2
SCDS1010
Events chronology must capture information about specific
life events that may impact one needs and/or service
delivery…
SCDS2
SCDS1011
EC must capture information relating to outcomes of events
and interventions.
SCDS2
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 17
Transformational Technologies Division
SCDS1012
EC must be able to link to and/or group related events.
SCDS2
SCDS1013
Must be able to link specific events or interventions to
specific processes.
SCDS2
SCDS1014
Must be able to exchange ECs between eCare partnerships,
such that the information within the chronology is meaningful
and accessible to all partnerships.
SCDS2
SCDS1015
Process dataset should include process type, process start
and end dates and lead professional.
SCDS2
SCDS1016
Process dataset should include textual statement of process
outcome and other process notes.
SCDS2
Assumption
Physical optimisation and practitioner verification will be
conducted by local eCare partnerships and pilots
Atos Origin
Assumption
SCDS2 have verified their work with other appropriate
government agencies and standards bodies
Atos Origin, eCare
Programme
Assumption
Extension and wholesale modifications to the existing MultiAgency Store Data Model are permitted at the time of writing
Atos Origin
Assumption
Validate the authenticity of messages received
Atos Origin
1.7
Scope
This document will:

Describe the core elements of the logical design of the eCare Programme’s MultiAgency Store;

Describe the data model for recording subject consent and authority to disclose data
to partner agencies through the MAS;

Describe the data model for processes, events and status episodes;

Include such features as are needed for purposes of implementing the eCART / MAS
Children’s High-level (General) Assessment Dataset and the agreed first tranche of
the Integrated Children’s Services Record dataset;

Explain in detail how the data items in the two Children’s datasets are expressed
within the data model;

Describe the data model for forms;

Introduce such additional features to the MAS logical data model as are needed to
provide an audit trail for those entities that require to be audited;

Document the current understanding of what notifications are and how they will be
processed;
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 18
Transformational Technologies Division

Provide a logical data dictionary;

Document controlled vocabularies;

Employ the work of SCDS2 and Transformational Technologies Standards Branch, eGIF and e-GMS as key design inputs;

Describe how the MAS will support Child Protection Messaging.
1.8
Out of Scope
This document will not:

Propose a complete physical solution;

Include data entities originating from specific agencies;

Consider statutory or legal issues relating to the inter-agency sharing of personal and
sensitive personal data by the eCare Programme;

Address those parts of the Integrated Children’s Service Record that are not included
in the agreed first tranche;

Describe eCare policy for Security and Auditing except insofar as this is relevant to
the eCare Multi-Agency Store Data Model;

Discuss the messaging mechanism as a whole;

Discuss any requirement that may exist for direct agency-to-agency communication,
including the acknowledgement of notifications to source systems;

Describe the systems that interact with this model;

Describe the data structure for eCare Indexing (transferred to the Hub Data Model
document [11] as from Version 1.4 of the document);

Describe the data structure necessary for authentication of Partner or Agency
Systems that interact with the MAS (transferred to the Hub Data Model document [11]
as from Version 1.4 of the document);

Describe the data structure for handling notifications (transferred to the Hub Data
Model document [11] as from Version 1.4 of the document).
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 19
Transformational Technologies Division
1.9
References
Reference
Title
Date
1
eCare Conceptual Solution Overview Version 1.1 Release
01/09/2005
2
eCare Data Policy Document Version 1.0 Release
01/09/2005
3
eCare Matching Overview Version 1.0 Release
08/11/2004
4
eCare Programme Requirements Catalogue Version 0.3
30/11/2004
5
Scottish Social Care Data Standards Manual Version 2.0
June 2005
6
eCART/MAS Children’s High-level (General) Assessment Dataset:
Definitions, Codelists & Guidance, Version 1.0 (Scottish Social
Care Data Standards Project)
March 2005
7
Integrated Children’s Services Record: Definitions, Codelists &
Guidance, Version 0.2c (Scottish Social Care Data Standards
Project)
March 2005
8
eCare Security Policy Version 1.0 Release
01/09/2005
9
Data Protection Act 1998
1998
10
Information Commissioner, Use and Disclosure of Health Data:
Guidance on the Application of the Data Protection Act 1998
May 2002
11
eCare Hub Data Model Version 1.0 Release
28/03/2008
12
Child Protection Messaging: Message Content & Guidance
Version 1.1 Draft
09/11/2007
13
Transformational Technologies Division Standards Branch,
Process, Event, and Status Episode Types for eCare Framework
Version 1.1 Release
February
2007
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 20
Transformational Technologies Division
1.10 Terminology
Term
Explanation
CSP1
Children’s Services Phase 1
CV
Controlled Vocabulary
e-GIF
e-Government Interoperability Framework
e-GMS
e-Government Metadata Standard
GDSC
Government Data Standards Catalogue
ICSR
Integrated Children’s Service Record
IEEE
Institute of Electrical and Electronics Engineers, an international
standards body
MGF-2
Modernising Government Fund – Round 2
MAS
Multi-Agency Store: the term given to the eCare consented data
store that enables inter-Agency data sharing
OSIAF
Openscotland Information Age Framework
SCDS2
Social Care Data Standards Project Phase 2
1.11 Amendment History
1.11.1 Amendments made in Version 0.2 Draft
A new section (section 4, “Disclosure Conditions for Personal Data”) has been introduced
and subsequent sections are renumbered. The new section extends the scope of the Data
Model so as to encompass both a subject’s consent to data sharing and an interface
system’s “authority to disclose” data to the MAS. As part of this change, a new attribute
SystemDescription is added to the InterfaceSystem entity.
A new attribute ContactAgency is added to the SubjectWarningFlag entity.
The new CV attribute ExtensionDataTypeCV is substituted for the textual attribute
AttributeType on the AttributeType entity as a means of identifying the data type for an
extension attribute. Section 6.4 is amended to reflect this. The extension attribute data types
in section 12.4.2 are aligned with the values in CVExtensionDataType.
The StatusEpisodeTypeCV attribute has been transferred from the StatusEpisode entity to a
newly introduced StatusEpisodeType entity. The new entity has the further attribute
IsUnique. In addition, the generic attributes OrganisationID (linking to Organisation) and
OrganisationName have been added to the StatusEpisode entity, equivalent extension
attributes being removed from seven Status Episode Types. OrganisationID is removed as
an extension attribute for two Event Types. ProfessionalID is removed as an extension
attribute for the “Developmental or medical status” Status Episode Type. The purpose of
these changes is to avert the possible difficulties that might arise from use of foreign keys as
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 21
Transformational Technologies Division
extension attributes (CV attributes being an exception). These changes have occasioned
amendments to sections 5.5, 6.3, 7.3.2, 7.3.5, 7.4.6, 7.4.7, 12.4.2.2, 12.4.2.3 and to the table
in section 12.4.3.
A new attribute NotificationReferenceID is added to the Notification entity. The values in
CVNotificationType are amended. Section 10.7 is amended to reflect both these changes.
Among other changes that do not affect the data model structure itself, “Other specific”
replaces “Intersex” in CVGender. “Not certain” is added to CVSexualOrientation.
“Communication based on sign language: Other sign language” is added to
CVPreferredCommunicationMethod. “British Sign Language (BSL)” is added to
CVLanguage. “Combined sight and hearing loss” is added to CVImpairment. “Other” is
added to CVTenureType. “Event was mistakenly reported” is added to CVEventStatus.
Changes are made to the Controlled Vocabularies for Process Type, Event Type and Status
Episode Type. The separate “Children’s referral” process type is absorbed into the generic
“Making a Referral / Request for Assistance” process type (so that the ConcernFactorCV
extension attribute becomes potentially applicable to vulnerable adults as well as children).
The discussion in section 5.4 is amended.
In handling the “Request for assistance / referral” data topic in the ICSR dataset (section
7.4.3), the “Concern Description” data item is reassigned from a Process Note to the
ProcessDescription attribute on Process. Further changes are made in consequence of
changes to the two Children’s datasets themselves. (1) In relation to the eCART / MAS
Children’s High-level (General) Assessment Dataset [6], a further value is inserted into
CVChildSocialWorkStatus. Textual amendments reflect the addition of the name of the
Reporter to the “Children’s Reporter’s Administration Involvement” data topic and the
address of the educational establishment to the “Educational establishment details” data
topic (though the existing data model accommodates these data items). (2) In relation to the
ICSR dataset [7], a new IsMultiAgency extension attribute is substituted for the previous
MultiProfessional extension attribute for the Process Type “Assessment / Care or Service
Planning (Children’s)”. For “Known allergies”, a CV extension attribute replaces the previous
textual attribute for the allergen(s) and a new IsDiagnosed attribute is introduced. “Paediatric
diabetes” is a new ICSR data topic, diabetes having five different types. “Other medically
diagnosed condition” is changed to “Other significant health condition”. (3) The “Educational
attendance” Status Episode Type, which straddles the two datasets, is changed from a
continuous period of attendance at an educational establishment to a “student stage” within
that period (following a change in ICSR requirements).
Section 7 and the table in section 12.4.3 are variously amended to take account of the above
changes. There are also a few other minor textual corrections and enhancements.
1.11.2 Amendments made in Version 1.0 Release
Title changed from eCare Multi-Agency Store Consolidated Data Model to eCare MultiAgency Store Data Model Version 2.5.
In CVCountryOfBirth, a duplicate value for Ireland is removed.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 22
Transformational Technologies Division
The length of the five AddressLine attributes on Address is increased from 35 to 100.
AttributeSetID is added to ExtensionSet as a foreign key (so that the Attribute order within an
AttributeSet can be expressed in the ExtensionTable).
A ProcessToForm link entity is introduced between Process and Form (allowing a Form to be
related to more than one Process).
The length of the QuestionText and QuestionDescription attributes on Question is reduced
from 4000 to 3000.
Two new entities (AuthorisationProfile and AuthorisationRole) are added to the data model
for Security and Auditing. Their purpose is to make better provision for the authorisation of
agency systems to use specific eCare Web Services. The InterfaceSystemFlag entity is no
longer used for this purpose.
The new attribute MessageSequence is added to the MessageLog entity. MessageID is
renamed IncomingMessageID. The MessageStatusCV, DateCreated and DateExpires
attributes are removed. Values are defined for CVMessageType.
The new entity NotificationMatchIndex is introduced to cater for Matching notifications. The
Identifier attribute is removed from NotificationTarget. In CVNotificationType, a value is
introduced for match status “Query” and match status “Received” is removed. “Duplicate”
failures are distinguished from other failures. Values are added for MAS update and
“miscellaneous” notifications. Section 10.6 (Matching Notifications) is substantially rewritten;
amendments are also made to other subsections of section 10.
1.11.3 Amendments made in Version 1.1 Release
The Data Model Version Number is incremented from 2.5 to 2.6.
The CVCategory entity is removed from the data model, for the reasons outlined in section
3.2. All diagrams containing the Controlled Vocabulary cluster have been amended
accordingly.
A new FormState entity is interposed between Form and FormSection. The reasoning behind
this is described in the new sections 8.2 and 8.4.2. The Forms data model diagram has been
moved to an earlier position within section 8. A new CV attribute SectionTypeCV has been
added to Section (see section 8.4.3). A new CV attribute QuestionDataTypeCV has been
added to Question (see section 8.4.5). Constraints on the use of the QuestionController
entity are documented in section 8.4.8.
There are minor wording changes to sections 10.2 and 10.4.3 which relate the “polling”
approach to Notifications more clearly to eCare Security Policy.
Typing mistakes corrected in section 12.4.2.1 (re attributes ChildAssessmentReportCV and
TargetEndDate).
The CV attribute MultiAgencyCV is substituted for the Boolean attribute IsMultiAgency as an
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 23
Transformational Technologies Division
extension attribute for the “Assessment / Care or Service Planning (Children’s)” Process
Type (sections 7.4.4, 12.4.2.1, 12.4.3).
In section 13, CVAuthorisationRole is amended; CVMultiAgency is added as a CV; an “Other
dwelling type” value is added to CVDwellingType; in CVAccommodationType, the value
“Independent hospitals and clinics” is changed to “Independent hospitals”.
1.11.4 Amendments made in Version 1.2 Release
The Data Model Version Number is incremented from 2.6 to 2.7.
There are a number of minor changes to the documentation. Within the extension attribute
sub-system, an IsCurrent flag attribute is added to the AttributeSetToAttribute entity to allow
extension attributes to be deprecated (section 6.4). An explanatory note on the existing CV
flags is included in section 3.2. A convention for documenting deprecated extension
attributes, CV values and CVs is introduced into sections 12.4.2 and 13 (the latter section
being now sub-divided). In section 12.4.2, multi-value extension attributes are also identified
as such. There is a brief account of the use of local identifiers within the MAS (sections 3.8
and 6.6).
In compliance with Data Standards, the existing “Civil partner” value in CVRelationship is
deprecated. The “Spouse” value encompasses civil partners as well.
There are more substantive changes in respect of children’s data. In the logical data model
for Core MAS Data (section 2.8), an ExtensionSetID attribute is added to the
SubjectWarningFlag entity. With this addition, Subject Warning Flags will provide the
necessary basis within the MAS for a Child Protection Messaging service, as described in
the new section 11. (The former sections 11 and 12 are renumbered.) Six new values are
added to CVRiskType. The new extension attributes required for CPMs are described in
section 12.8. Section 1.4.7 is added to the Introduction and small consequential amendments
are made to sections 3.6.3 and 7.3.3. A new Notification Type is introduced to alert an
interface system that newly matches a child (or any data subject) if a Subject Warning Flag is
already in existence. A redundant Notification Type is also removed and minor amendments
are made to section 10.
The previous “Investigation or enquiry (Child protection)” Process Type is split into separate
Process Types for “Child Protection Investigation” and “Child Protection Inquiry”. A new
Process Type is added for “Sharing a Concern” (applicable to adults as well as children). It
replaces the previous “Expression of Concern” Event Type. Because the ConcernLink entity
was tied specifically to that Event Type, it is now removed from the Data Model. New
Process Types are also added for “Placement”, “Admission”, “Discharge” and “Inter-Agency
Discussion”. The names of certain other Process Types are slightly amended to bring them
into line with Data Standards. Consequential changes are made to sections 5.4, 5.5, 6.2,
7.1, 7.3.2 and 7.3.7 (and Process Type names are amended in other sections).
There are associated changes to extension attributes (sections 12.4.2.1 and 12.4.3). These
include extension attributes for the new Process Types, some additional attributes for the
three “Request” Process Types, and a change in the name of the reference CV for the
existing LeadAgencyTypeCV attribute. Use of that CV being now extended to a second
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 24
Transformational Technologies Division
extension attribute, CVLeadAgencyType is restyled CVAgencyType (retaining its existing CV
code but acquiring further values). CVCPEnquiryAgency and CVCPEnquiryOutcome
disappear, while CVCPInquiryOutcome, CVNamedPersonConsulted,
CVCPInvestigatingAgency, CVCPInvestigationOutcome and CVCPStrategyMeeting are
newly introduced. Two additional values are added to CVCPConferenceOutcome. A new
value is also added to CVProcessInvolvementType (see section 6.1) for purposes of Child
Protection Inquiries.
In other minor changes to children’s data items, the “Establishment visit” Event Type loses
two extension attributes and gains four new ones (section 12.4.2.2). A new extension
attribute is also added to the “Looked after or accommodated episode” Status Episode Type
(section 12.4.2.3). In association with these extension attribute changes, CVPlannedVisit and
CVLookedAfterType are introduced as new CVs. Minor changes are made to
CVAppointmentAborted, CVCANonCompletionReason, CVChildAssessmentReason,
CVChildAssessmentReport, CVChildSocialWorkStatus, CVHearingDecision,
CVHomeVisitAborted and CVVisitType. Consequential changes are made to sections 6.4,
7.3.8, 7.4.6 and 12.4.3.
The final set of changes reflects a decision to handle a number of children’s data topics
through the medium of Forms, so that they cease to be expressed as structured data within
the MAS. The “Developmental or medical status” Status Episode Type is deprecated, as are
all the extension attributes associated with this Type and four related CVs
(CVChildhoodDifficulty, CVSeverityStatus, CVOutlook and CVAllergen). There are
consequential amendments to the text of sections 7.2, 7.4.2, 7.4.7 and 12.4.3.
1.11.5 Amendments made in Version 1.3 Release
The Data Model Version Number is incremented from 2.7 to 2.8.
A FormTypeCode attribute is added to the FormType entity and a Version attribute is added
to the FormVersion entity. Their purpose is to provide a better means of identifying Form
Types and Form Type Versions (see section 8.4.1 below).
There is an amendment to the text of section 11.2, relating to the need to notify partner
agencies of the deletion of a Child Protection Message that has been created in error. A
separate error in the previous text is also corrected.
1.11.6 Amendments made in Version 1.4 Release
A number of features are removed from the eCare Multi-Agency Store Data Model following
the consolidation of Indexing, Security and Notifications in the eCare Hub (described briefly
in section 2.3 below). The Data Model Version Number is incremented from 2.8 to 2.9.
The Indexing System (i.e. the InterfaceSystem, ExternalReference and PrimaryIndex
entities) and the PersonStatus entity are removed from the Logical Data Model for Core MAS
Data (see section 2.8). The PersonStatus entity is also removed from the diagram in section
3.6. The existing contents of section 2.3 are preserved but a Postscript is added, while there
is a substantial abridgement of the more detailed discussion of Indexing in section 3.1. Some
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 25
Transformational Technologies Division
minor amendments are made to section 2.1.
The ExternalReference, PrimaryIndex and PersonStatus entities are removed from the
Logical Data Model for Disclosure Conditions (see section 4.2, and note that InterfaceSystem
retains a logical presence in the diagram). A consequential amendment is made to the last
paragraph of section 4.4.
The InterfaceSystem entity is retained in the Logical Data Model for Forms, but a note is
added to section 8.3.
The Security features (i.e. the SystemToken, AuthorisationRole, AuthorisationProfileRole and
InterfaceSystemFlag entities) are removed from what was formerly the Logical Data Model
for Security and Auditing but is now the Logical Data Model for Auditing (see section 9.4, and
note that InterfaceSystem again retains a logical presence in the diagram). Section 9.1 is
amended, while section 9.2 is substantially abridged.
The Logical Data Model for Notifications (section 10.7) is transferred in its entirety to the Hub
Data Model, as is the discussion of Matching Notifications (section 10.6). Because of their
general relevance to an understanding of data sharing through the eCare Framework, the
first five sub-sections of section 10 are retained in this document (with some minor
annotations and amendments).
There are consequential amendments to the Data Dictionary (sections 12.2 and 12.6) and to
Controlled Vocabularies (section 13.1). There are also some minor amendments to the
Introduction (sections 1.4.1, 1.4.5, 1.4.6, 1.7 and 1.8).
In a separate change, the PersonToAddress entity is given a new primary key, with the effect
that where two interface systems relate the same Person to the same (gazetteer) Address,
each will now have a separate PersonToAddress record. This ensures that one system will
not e.g. overwrite the other system’s notes. The elements in the previous compound key
(AddressID and PersonID) become foreign keys. There is a consequential change to the
PersonToAddressHistory entity. The diagrams in sections 2.8 and 3.4 are amended.
Section 8.4.4 (QuestionGroupings and FormGroupings) has been substantially rewritten, with
a view to clarifying the role of QuestionGroupings within a Form. There are some changes to
section 8.4.5 (Questions and Responses), the main effect being to align the discussion of the
QuestionCode attribute with its current use in web services. These changes are reflected in
amendments to the definitions of the IsHeader attribute on QuestionGrouping, the
QuestionCode attribute on Question (both in section 12.5) and CVHeader (in section 13.1).
Two sentences have also been added to section 8.4.3 (Sections and FormSections). There
is a minor amendment to the last paragraph of section 10.5.2. Some points of clarification are
added to the discussion of Child Protection Messages in sections 11.2 and 11.3. Sections
2.4 and 13.1 have been amended to remove the references to local extension CVs.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 26
Transformational Technologies Division
2.
Core MAS Data: General Principles
2.1
A modular description of the MAS Data Model
For ease of understanding, the description of the MAS Data Model is sub-divided in this
document into seven separate parts, covering the “core” area, disclosure conditions,
“dynamic entities”, “forms”, security and auditing, notifications and child protection messages.
With the exception (since Version 1.4) of notifications, this modular approach is extended
both to the diagrammatic representation of the logical model (the relevant extract being
displayed in sections 2.8, 4.2, 5.8, 8.3, 9.4 and 11.4 respectively) and to the organisation of
the Data Dictionary within section 12. It should be borne in mind throughout that each of the
diagrams is simply an extract from a single, larger model. The MAS Data Model is designed
to be implemented as a unitary whole.
Many data items are linked to “controlled vocabularies” (see section 2.4 below). In some
cases, more than one data item will be linked to the same controlled vocabulary and, in
principle, these data items can belong to different parts of the model. For this reason, the
controlled vocabularies have been consolidated into a single table at the end of the
document (see section 13).
[Postscript (Document Version 1.4, March 2008). While the MAS Data Model document
continues to reflect the seven-part structure described above, a number of changes have
been made to the MAS Data Model itself following the introduction of the eCare “Hub”. The
most important of these changes relates to the eCare Indexing System. In the initial
implementation of the eCare Framework, this system had a separate physical existence in
each instance of the Multi-Agency Store. The eCare Indexing System has now been
consolidated within the eCare “Hub” database. The effect is to replace what were formerly 14
separate “MAS” Indexes by a single “Hub” Index which serves all the Stores. The detailed
description of the Indexing System (formerly provided in section 3.1 of this document) has
been transferred to the Hub Data Model document [11].
Security features (formerly discussed in section 9.2) and Notifications (section 10) have also
been consolidated within the Hub. The Notifications diagram formerly displayed in section
10.7 has been transferred to the Hub Data Model document. Along with much of the textual
discussion, the Data Dictionary for the Indexing, Security and Notifications entities and the
Controlled Vocabularies associated with their attributes have been transferred from sections
12 and 13 respectively to the corresponding sections of the Hub Data Model document. The
entities that have been transferred are listed at the start of sections 12.2, 12.6 and 12.7 and
the CVs at the start of section 13.1.
Despite its transfer to the Hub, the InterfaceSystem entity is still documented in sections 3.1
and 12.2 of this document. This is because the entity remains a logical feature of the Logical
Data Models for Disclosure Conditions (section 4.2), Forms (section 8.3) and Auditing
(section 9.4). At a physical level, the entity no longer exists within the MAS database; the
entities to which it relates (i.e. those that have InterfaceSystemID as a foreign key) are now
constrained (in regard to the maintenance of referential integrity in respect of the key) by
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 27
Transformational Technologies Division
means of a “trigger”.]
The first element within the eCare Multi-Agency Store Data Model describes the core MAS
entities – i.e. those entities that are most fundamental to inter-agency information sharing.
They include:

The entities that support the sharing of relatively static data about persons – in
particular, Person, Subject, Professional, Name, Address and the relationships
between these.

The entities that support the storage and management of controlled vocabularies
(CVs).
They formerly included, but no longer (as from Version 1.4 of this document) include:

The entities that support the indexing of the persons about whom information is
shared.
The first (“core”) element (sections 2 and 3) is supplemented by a number of other data
model elements. The second (“disclosure conditions”) element (section 4) adds the entities
that are needed to record basic details about the authorisation of data disclosure and a data
subject’s consent to share. The third (“dynamic entities”) element (sections 5 to 7) introduces
the various dynamic or changing entities (service processes, service and life events, status
episodes) that are needed in the MAS to reflect the developing life and service history of a
data subject. This element provides a connecting link between the core or static information
about persons and the fourth (“forms”) element (section 8), which describes a generic
structure for sharing the sorts of more detailed information that are normally captured or
recorded in a standard form – e.g. in a referral form, assessment form or care plan. More
specifically, each form must always be associated with at least one process; while a process
can give rise to more than one form.
Between them, the first four elements (together with the small enhancement effected in the
seventh) provide all that is needed of a substantive sort to share information about persons.
The fifth element (section 9) adds necessary auditing features to the overall model (and prior
to Version 1.4 of this document added security features as well). The sixth element (section
10) relates to eCare Notifications and sits slightly apart from the others; it no longer (Version
1.4) includes the notifications data model as such. The seventh element (section 11) is a
later (Version 1.2) supplement to the “core” data that introduces Child Protection Messages.
The entire document should be read in the context of the eCare Data Policy Document [2],
which provides a high-level description of data policy for the Multi-Agency Store. This
includes a description of the data design principles behind all the data modelling work carried
out for the eCare Programme.
As has already been noted (section 1.4.1 above), the Multi-Agency Store uses a single data
model for both adults’ and children’s data. Although the extension of scope to Children’s
Services was the occasion for enhancing the core model beyond what was encompassed in
its initial release, only one of the additional entities (SubjectAffectingDisability) is specific to
children. The other enhancements introduced at that point (e.g. PersonReference and
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 28
Transformational Technologies Division
SubjectWarningFlag) are likely to prove useful in an adult context as well.
The data items included in the core Data Model and the associated controlled vocabularies
are largely drawn from the Scottish Social Care Data Standards Manual [5], the exceptions
(mainly technical) being noted in the Data Dictionary (see section 12.2 below). The Data Item
Tabular Summary from the SCDS Manual is reproduced as Appendix B. Prior to inclusion in
the data model, SCDS data items have undergone a process of normalisation. For this
reason, there is not an exact correspondence between the data items shown in Appendix B
and those shown in the Data Dictionary.
2.2
Person data
The MAS must hold records about different sorts of persons. First, there are the persons
(adults or children) who are the primary subjects of information sharing. Secondly, there are
professionals who have an involvement with those persons (GPs, social workers, community
nurses, teachers, etc.). And thirdly, there are other “associated persons” (parents, children,
neighbours, etc.) who have an important connection with primary subjects, and about whom
some limited information must also be shared.
Person data is distributed across a number of different entities in the MAS. At the centre is
the Person entity, which contains an entry for every person who is recognised in the MAS –
whether a primary subject, a professional or an associated person. It holds those data items
(e.g. current gender and date of birth) that could potentially be required in connection with
any sort of person (even if they are not required in every particular case). The Subject entity
is an extension entity to the Person entity which holds the data items that are only ever
required for primary subjects of information sharing. The Professional entity is an extension
entity to the Person entity which holds data items that are only ever required for
professionals. There are no data items that are specific to associated persons, so there is no
extension entity for this third sort of person.
Other secondary entities expand these three primary entities. They include the entities that
hold details of names, addresses and contact details. Because a person may have more
than one name, address or contact detail, these details cannot be held on the Person entity
itself – separate entities are required. In addition, there are link entities that enable many-tomany relationships to be established between different people – so that e.g. a Subject can be
linked to many Professionals or a Professional to many Subjects.
All these entities are discussed in greater detail in sections 3.3 to 3.6 below.
Mention should be made here of two omissions from the core element within the Data Model.
At an earlier stage, the core model included both MaritalStatusHistory and
EmploymentStatusHistory entities. These had evolved into separate entities because of the
requirement to maintain a history of a Subject’s changing marital status and employment
status; but for this requirement, they could have been handled as updateable attributes of the
Subject entity. The eCare Processes and Events Data Model introduced the Status Episode
entity as a generic means of holding any time-bounded status. Marital status and
employment status are now handled as Status Episode Types within the “dynamic entities”
part of the model (although they are included in Appendix B).
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 29
Transformational Technologies Division
2.3
Indexing
The eCare Indexing system enables partner agencies to share information about a Subject
while continuing to use their own separate reference numbers as a means of identifying the
Subject. The Index relates these numbers to one another by linking each external identifier
for a person to the internal identifiers used by the eCare Framework itself.
In order to set up these linkages, a prior process of “matching” is required (described in
greater detail in the eCare Matching Overview [3]). This involves comparing demographic
characteristics recorded in an agency system with those recorded in an authoritative
repository of citizen reference data. In the absence of a national Unique Citizen Reference
Number (UCRN) in Scotland, the Community Health Index (CHI) is being used by eCare as
the authoritative repository against which to “match”. Each partner agency must initiate its
own separate match against the data held in the CHI system. A successful match leads to
the creation of an eCare Index entry for the person and agency system, but no data is stored
on the MAS at this point. The matching criteria (name, date of birth, etc.) are deleted once
the match has been effected. Data is only stored on the MAS if and when an explicit decision
is taken to share the data, and this decision (if it is taken at all) may come some time after
the match itself.
A partner agency may only view a Subject’s data (and will only receive notifications relating
to the Subject) if it has previously matched the person concerned, thus associating its own
identifier to the MAS internal identifier. Clearly no information sharing can occur until at least
two agencies have undertaken this process.
Note that the eCare Index is not restricted to Persons who are Subjects. Any Professional or
associated person must also have an Index entry (without which no updating would be
possible). This will hold a unique local identifier assigned to the person by the local agency
system from which the person was stored on the MAS. The difference is that Persons other
than Subjects need not have undergone a process of “matching”. Indeed Professionals, in
their capacity as Professionals, should never be matched. A Professional may also be a
service user in his or her private capacity and it is important, for data protection reasons, that
these two identities are kept clearly distinct within the eCare Framework. In some
Partnerships, associated persons other than Professionals may be matched, although this is
not an eCare Framework requirement. In the absence of matching, it is of course possible
that duplicate records will arise.
Note also that the eCare Index is not made available to partner agency systems. Any
external identifiers for persons that are required as shareable data items (e.g. the Scottish
Candidate Number) will be made available through the PersonReference entity (see section
3.6.1 below).
As already discussed (in section 2.1 above), the eCare Indexing System has now (Version
1.4) been consolidated within the eCare “Hub” database. The detailed description of the
system has been transferred to the Hub Data Model document [11]. Under the new
arrangement, a Person entry is only created at the MAS level when an agency system
discloses some actual data for the person in question (indicated, in the case of a Subject, by
the storing of a Disclosure Authority for the person – see section 4 below).
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 30
Transformational Technologies Division
The Indexing system is discussed further in section 3.1 below.
2.4
Controlled Vocabularies
Many database attributes require a value to be selected from a specified range of values.
These are known as controlled vocabularies (CVs). In such a case, it is not the value itself
that is held against an attribute (e.g. against the attribute ReligionCV on Person) but a unique
identifier that points to the relevant value on a standard reference table. The entities that
support this process are described in section 3.2 below.
Most CVs are “national” CVs, where not only the CV but its constituent values are mandated
centrally (either by the Social Care Data Standards Project or, in a few more technical cases,
by the eCare Programme). The name of a national CV will always begin with the letters “CV”
(and the name of the corresponding attribute will end with these letters). Occasionally
(because of the extent of local variation in the values commonly used, as in the case of
professional roles) it will be a national data standard that an attribute should be a CV
attribute, but the national standard will leave it to local Partnership decision what the CV
values should be. The name of the CV will then begin (and that of the corresponding attribute
will end) with the letters “LCV”.
2.5
Organisations
In addition to Personal data, the MAS offers a limited capacity to hold information about
Organisations. The Organisation entity was initially introduced as a light, generic structure
capable of future extension. Some small enhancements have been made since the Version
1.0 Release of the core MAS Data Model for purposes of Children’s Services. These are
discussed in section 3.7 below.
2.6
Temporal data
For some sorts of Personal data, it is an eCare requirement to share not only the current
information (e.g. the current Name or Address) but historical information as well. It may be of
importance for partner agencies to know by what name a person was known a year ago or
where that person was living. In addition to Names and Addresses, this requirement extends
to the changing roles played by professionals or by associated persons in relation to a
Subject. (As already noted, it also applies to marital status and employment status and to the
other statuses that are handled through the Status Episode entity.)
Historical information is handled in the MAS through “temporal” entities (such as the
PersonToAddressHistory entity which hangs off the main PersonToAddress link entity). A
“temporal” entry will exist for the current case as well as for past cases – so that a person’s
current address will give rise both to a PersonToAddress entry and to a
PersonToAddressHistory entry. Temporal entities are discussed individually at the
appropriate point in section 3. They possess some common features, however, which should
be noted here.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 31
Transformational Technologies Division
The first feature is that within the MAS, the “temporal” entity is mandatory, in the sense that if
there is an instance of the “primary” entity (e.g. Name) in the MAS, it must be associated with
at least one instance of the corresponding “temporal” entity (in this case NameHistory). This
is required in the MAS, even if a particular agency system does not itself support a history of
e.g. Names. Where a feeder system takes a non-temporal view of an entity which is
temporalised in the MAS, an appropriate history entry will need to be created in the process
of data transfer into the MAS.
Each temporal entity includes two sets of dates. ValidStart and ValidEnd define the period of
time during which the information is valid – e.g. during which the person was actually living at
the address in question. If the information is currently valid (the person is still living at the
address), ValidEnd is set to a constant date UC (which stands for “Until Changed”). At a
physical level, UC might be equated with the maximum date supported by the Multi-Agency
Store’s database management system. If the information is no longer valid, ValidEnd should
be the date it ceased to be valid (e.g. the date the person moved out).
TransactionStart and TransactionEnd relate to the history of the information within the MAS.
For example, if a person moved into an address on 1 February 2004 but this fact was not
recorded on the MAS until 17 April, ValidStart will be 01/02/2004 and TransactionStart will be
17/04/2004. TransactionEnd is always set to UC (see above) unless the record is cancelled
(e.g. because it was discovered that the person had not after all been living at that address).
In the event of cancellation, TransactionEnd is the cancellation date. It is important to stress
the distinction between ending a record (which remains valid for the period before the end
date) and cancelling a record (which was never valid) – in the former case, ValidEnd is set to
the validity end date and TransactionEnd remains equal to the maximum date; in the latter
case, ValidStart and ValidEnd remain unchanged and TransactionEnd is set to the date of
cancellation.
2.7
Boolean attributes and flag entities
There has been a change in the way both Boolean (true/false) attributes and “flag” entities
are handled within the core MAS model. The Boolean attributes LivesAlone and
AppropriateAdultRequired have been restored as separate attributes to the Subject entity
(where they were located in early drafts). In the Version 1.0 Release of the core Data Model,
Boolean attributes were handled through a SubjectFlag entity and a SubjectAttributesCV.
That approach allowed no distinction between a null value (i.e. not known or not recorded)
and a known negative value. Reverting to the earlier approach also helps to make the model
more transparent.
“Flag” entities are still required because some CVs allow for multiple selection (as when a
Subject has both a visual and a hearing impairment). But in place of a single SubjectFlag
entity, each multi-select CV will now have its own separate, appropriately named flag table
(e.g. SubjectImpairment, SubjectAffectingDisability). The CV attribute will also be
appropriately named. This creates a clearer logical relationship with the source CV. As with
the previous change, it should also make the data model easier to understand.
Two of the “history” entities have undergone a comparable amendment. What was formerly
PersonToProfessionalHistory has become ProfessionalRoleHistory, while
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 32
Transformational Technologies Division
PersonToPersonHistory has been renamed AssociatedPersonRoleHistory. The latter entity
has also absorbed PersonToPersonHistoryFlag, whose CVValueID attribute has become
AssociatedPersonRoleCV. Both the renamed entities allow for multiple selection of roles at a
given time (so that an Associated Person can be e.g. both a carer and a keyholder at the
same time); both also allow the sharing of historical as well as current role records for a
given Professional or Associated Person in relation to a given Subject.
2.8
Logical Data Model for Core MAS Data
The diagram below shows the logical view of the data model for core MAS entities. Like its
counterparts in later sections, this is a logical schema which specifies the key data entities,
the attributes of those entities and the relationships between entities. The logical models also
encapsulate and describe the following types of business rule for each relationship: the fact
that an entity must exist (or need not exist) for another to exist; and the fact that an entity can
be related to zero, one or many other entities. Each model is documented as an Entity
Relationship Diagram (ERD) employing IDEF1X notation. IDEF1X is a data modelling
standard of the National Institute of Standards and Technology (NIST) and employed by
many international government organisations.
Note that for reasons of legibility, there are two omissions from all the data model diagrams
except that shown in section 9.4:
1. As documented in section 9.3.3, every entity also possesses two auditing attributes:
AuditLogID and ModifiedDate.
2. Some of the relationships are omitted between CVValue and other entities.
Note also that the Indexing System (comprising the InterfaceSystem, ExternalReference and
PrimaryIndex entities) has been omitted from this diagram in Version 1.4 of this document,
following its transfer to the Hub (see section 2.3 above).
The Data Dictionary for the core part of the data model can be found in section 12.2.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 33
Transformational Technologies Division
OrganisationReference
ProfessionalRolelHistory
Professional
Organisation
HistoryID
PersonID (FK)
ProfessionalID (FK)
ProfessionalRoleLCV
ValidStart
ValidEnd
TransactionStart
TransactionEnd
PersonID (FK)
PersonToProfessional
OrganisationID (FK)
JobTitle
EmployingAgency
OfficeBase
PersonID (FK)
ProfessionalID (FK)
OrganisationID (FK)
OrganisationReferenceCV (FK)
OrganisationID
OrganisationToContactDetail
Identifier
OrganisationName
OrganisationTypeCV (FK)
OrganisationTypeDescription
OrganisationID (FK)
ContactDetailID (FK)
OrganisationToAddress
AddressID (FK)
OrganisationID (FK)
ContactDetail
Name
NameHistory
PersonToContactDetail
NameID
Person
PersonID (FK)
IsPreferredName
PersonID
NameHistoryID
NameID (FK)
NameStatusCV
ValidStart
ValidEnd
TransactionStart
TransactionEnd
NameElement
NameElementID
NameID (FK)
NameElement
ElementTypeCV
ElementPosition
IsPreferredForename
BirthDate
BirthDateVerificationCV
DeathDate
DeathDateVerificationCV
GenderCurrentCV
EthnicGroupSelfAssignedCV
EthnicGroupSpecificCV
ReligionCV
CountryOfBirthCV
FirstLanguageCV
InterpretationAssistanceCV
ContectDetailID (FK)
PersonID (FK)
HistoryID
PersonID (FK)
AssociatedPersonID (FK)
AssociatedPersonRoleCV (FK)
ValidStart
ValidEnd
TransactionStart
TransactionEnd
PersonID (FK)
AssociatedPersonID (FK)
RelationshipCV
RelationshipVerificationCV
IsDependant
Subject
PersonID (FK)
SexAtBirthCV
SexualOrientationCV
PreferredLanguageCV
HouseholdCompositionCV
LivesAlone
PreferredCommunicationMethodCV
OtherCommunicationMethod
OtherImpairment
PersonRepresentativeRequired
SubjectImpairment
PersonID (FK)
ImpairmentCV (FK)
SubjectAffectingDisability
PersonID (FK)
AffectingDisabilityCV (FK)
Identifier
AddressID
UPRN
SAON
PAON
StreetDescription
Locality
Town
AdministrativeArea
AddressLine1
AddressLine2
AddressLine3
AddressLine4
AddressLine5
PostCode
Country
UnstructuredAddress
DwellingTypeCV
AccommodationTypeCV
SubjectWarningFlag
WarningFlagID
PersonID (FK)
RiskTypeCV (FK)
WarningStartDate
WarningEndDate
ContactPerson
ContactAgency
ContactPhoneNumber
ContactEmail
WarningGuidance
ExtensionSetID (FK)
CVValue
CVControlledVocabulary
CVValueID
CVID
CVID (FK)
CVValueCode
CVValueText
CVValueOrder
CVValueFlag
CVName
CVCode
CVDescription
CVFlag
Address
PersonToAddressID (FK)
AddressTypeCV
ValidStart
ValidEnd
TransactionStart
TransactionEnd
AddressID (FK)
PersonID (FK)
TenureTypeCV
Notes
PersonID (FK)
ProfessionalID (FK)
NoteTitle
NoteText
NoteRecordedDate
Notes
HistoryID
PersonReference
PersonID (FK)
PersonReferenceCV (FK)
Controlled Vocabularies
PersonToAddressHistory
PersonToAddressID
SubjectNote
PersonToPerson
ContactDetailData
ContactDetailTypeCV
Notes
PersonToAddress
SubjectNoteID
AssociatedPersonRoleHistory
ContactDetailID
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 34
Transformational Technologies Division
3.
Core MAS Data: The data model in detail
3.1
The Indexing system
As explained in section 2.3 above, the eCare Indexing system has now (Version 1.4 of this
document) been transferred to the Hub. The system’s constituent entities in the MAS were
InterfaceSystem, ExternalReference and PrimaryIndex. Further Hub entities have now been
added to these. The effect is to modify the previous logical relationship between what is now
the Hub PrimaryIndex entity and the MAS Person entity. An associated entity
(PersonStatus), which allows for the disabling of Person records, has also been transferred
to the Hub. Detailed documentation of these entities and their attributes can be found in the
Hub Data Model document [11].
The InterfaceSystem entity remains of relevance to the main MAS Data Model, as a logical
feature of the Logical Data Models for Disclosure Conditions (section 4.2), Forms (section
8.3) and Auditing (section 9.4). For continuity, the entity is briefly documented in its old place
within this section (and in section 12.2 below). It has the attributes shown below. The logical
relationship of InterfaceSystem to other entities is expressed in the diagrams contained in
sections 4.2, 8.3 and 9.4.
InterfaceSystem
InterfaceSystemID
SystemName
SystemDescription
The InterfaceSystem entity has an entry for every agency system (or other system) that
interrelates with the MAS. SystemName is a plain English name for the system;
SystemDescription is a description of its user base (e.g. community nurses in a particular
locality). Note that the Security and Auditing systems require an InterfaceSystem entry for
every external system that updates or views the MAS, including systems that update
reference entities as well as those that update personal data. Its scope also encompasses
the eCare Matching Framework, as well as direct interventions by a database administrator.
3.2
Controlled Vocabularies
The following diagram shows a section of the data model relating particularly to Controlled
Vocabularies.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 35
Transformational Technologies Division
CVValue
CVControlledVocabulary
CVValueID
CVID
CVID (FK)
CVValueCode
CVValueText
CVValueOrder
CVValueFlag
CVName
CVCode
CVDescription
CVFlag
Prior to the Version 1.1 Release of the eCare MAS Data Model Version 2.6, this diagram had
remained unchanged since the early Version 1.0a Release of the core model (though there
had been an increase in the size of the attributes CVCode on CVControlledVocabulary and
CVValueCode and CVValueText on CVValue). The Version 1.1 Release simplified the
diagram (and other diagrams that incorporate the CV entity cluster) by dropping the
CVCategory entity.
CVControlledVocabulary contains an entry for each Controlled Vocabulary (i.e. range of
values from which a selection may be made); CVValue contains an entry for each separate
value within a controlled vocabulary. For example, there is a CVControlledVocabulary entry
for the Controlled Vocabulary CVContactDetailType and a CVValue entry (linked to
CVControlledVocabulary through the foreign key CVID) for each of the seven recognised
types of contact detail (i.e. “Home phone number”, “Mobile phone number”, “Email address”,
etc.)
Some CVs may possess an implicit hierarchical structure. This could in principle extend
through any number of levels, though few CVs are likely to exceed two. In the case of
Accommodation Types, for example, “Homeless” is a higher level value while “Rough
Sleepers”, “Other Roofless”, “Squatting”, etc. are lower level sub-types of homelessness; in
the case of Country Of Birth, “Elsewhere” is a higher level value and “Afghanistan”, “Albania”,
etc. are lower level values.
The former CVCategory entity was intended to provide a means of reflecting such
hierarchies within the explicit data model structure. (Each CVCategory entry would simply
have paired a “parent” CVValue identifier (e.g. for “Homeless”) with a “child” CVValue
identifier (e.g. for “Rough Sleepers”).) In practice, this feature has not been used, nor is
there likely to be an early use for it within the Multi-Agency Store itself. The tasks of
interpreting CV hierarchies, supporting tiered menu systems, etc. are undertaken by partneragency systems, not by the MAS.
In itself, the CVValue entity stores the values for a given classificatory hierarchy in an
undifferentiated way (so that e.g. the higher-level value “Homeless” and the lower-level
values “Rough Sleepers” and “Other Roofless” will each have an entry in CVValue, each with
the identifier for CVAccommodationType as a foreign key). This means that a CV value can
be attributed to an entity within the MAS at any level within a CV hierarchy.
But the CVs are now laid out (see section 13) in such a way as to ensure both that
hierarchies are visible (to the human eye) and that lower-level codes and values within
hierarchical CVs are self-contained and self-explanatory. For example, the textual value
stored for Rough Sleepers is “Homeless: Rough Sleepers” not “Rough Sleepers”. The
Controlled Vocabularies themselves have all been allocated codes. Where coding systems
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 36
Transformational Technologies Division
are “owned” by the Standards Branch or eCare, these serve as prefixes for the codes for CV
Values, with the effect that each of these Value codes will now be unique within the eCare
system as a whole. In a hierarchical CV, the lower level Value codes extend the code of
their parent value (so that the code for CVAccommodationType is “SN-ACC”, the code for its
“Homeless” value is “SN-ACC-01”, and the code for its “Homeless: Rough Sleepers” value is
“SN-ACC-01-HM01”). But a coding system may sometimes be drawn from a generally
recognised external source, such as the ISO codes for languages and countries. In these
“external” cases, the standard external codes are used for the CV Values (i.e. without a CV
prefix); uniqueness can only be guaranteed when the Value code is conjoined with the code
for the CV itself.
Both CVControlledVocabulary and CVValue have a “flag” attribute which allows either an
entire CV or a particular value to be deprecated. Note that the flags are included for
informational purposes only. When CV data is stored on the MAS, validation of CV values
does not extend to validation of their “current” status. This gives leeway for lags at an
agency system level in the introduction of new standards.
3.3
Names
The following diagram shows a section of the data model relating particularly to Names.
Person
Name
PersonID
NameID
PersonID (FK)
IsPreferredName
NameHistory
NameHistoryID
NameID (FK)
NameStatusCV
ValidStart
ValidEnd
TransactionStart
TransactionEnd
NameElement
NameElementID
BirthDate
BirthDateVerificationCV
DeathDate
DeathDateVerificationCV
GenderCurrentCV
EthnicGroupSelfAssignedCV
EthnicGroupSpecificCV
ReligionCV
CountryOfBirthCV
FirstLanguageCV
InterpretationAssistanceCV
NameID (FK)
NameElement
ElementTypeCV
ElementPosition
IsPreferredForename
The treatment of Names is generally compliant with the BS8766 standard. A Person can
have one or more Names at a given time. Each Name has a Name Status (e.g. registered
name, married name, maiden name, etc.). This can change over time, so is held on the
NameHistory record. A name can be held in a structured format, in which case there is a
separate NameElement entry for each element within the name (title, forenames, surname,
etc.). The element type (e.g. forename) is indicated by ElementTypeCV and the position of
the element within the name by ElementPosition. Alternatively, a name can be held in an
unstructured format, in which case there will be a single NameElement entry with the whole
name as a single string.
The main changes since the Version 1.0 Release of the core model are the transfer of
NameHistory from NameElement to Name and the transfer of the NameStatusCV attribute to
the history record. In addition, “Preferred Name” has been taken out of the Name Status CV
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 37
Transformational Technologies Division
and made into a separate Boolean attribute of a Name. This attribute is required for current
day-to-day interactions with the person, not for historical purposes – so properly belongs on
the Name record not the NameHistory record. To meet Standards Branch requirements,
there is a similar flag on NameElement to cater for the situation where e.g. someone prefers
to be known by their second forename.
3.4
Addresses
The following diagram shows a section of the data model relating particularly to Addresses.
Organisation
OrganisationID
OrganisationName
OrganisationTypeCV
OrganisationTypeDescription
OrganisationToAddress
AddressID (FK)
OrganisationID (FK)
Address
Notes
UPRN
SAON
PAON
StreetDescription
Locality
Town
AdministrativeArea
AddressLine1
AddressLine2
AddressLine3
AddressLine4
AddressLine5
PostCode
Country
UnstructuredAddress
DwellingTypeCV
AccommodationTypeCV
AddressID
Person
PersonID
BirthDate
BirthDateVerificationCV
DeathDate
DeathDateVerificationCV
GenderCurrentCV
EthnicGroupSelfAssignedCV
EthnicGroupSpecificCV
ReligionCV
CountryOfBirthCV
FirstLanguageCV
InterpretationAssistanceCV
PersonToAddressHistory
PersonToAddress
HistoryID
PersonToAddressID
PersonToAddressID (FK)
AddressTypeCV
ValidStart
ValidEnd
TransactionStart
TransactionEnd
AddressID (FK)
PersonID (FK)
TenureTypeCV
Notes
A Person may be linked to one or more Addresses and an Address to one or more Persons
through the link entity PersonToAddress. Because a Person may have different sorts of
connection with an Address, the relationship will always be of a specified type – e.g. a
normal domicile address or an alternative contact address. The type may change – a
temporary domicile address may become a normal domicile address. The requirement to
keep a history of a person’s addresses extends to any change of address type, so the
attribute AddressTypeCV was transferred in Version 1.1 from the PersonToAddress entity to
the PersonToAddressHistory entity. The attribute TenureTypeCV records whether an
address is owned, rented, etc. This is unlikely to change and there is no requirement to track
changes, so it remains on PersonToAddress (as does the Notes attribute). As noted in
section 2.6, a PersonToAddressHistory entry exists for current addresses as well as for past
addresses. The current address type will be found in the PersonToAddressHistory entry in
which both ValidEnd and TransactionEnd are set to the constant date UC (= “Until
Changed”).
In a change made in Version 1.4 of this document, the PersonToAddress entity has been
given its own primary key. AddressID and PersonID are converted into foreign keys. The
effect of this change is that where two interface systems relate the same Person to the same
(gazetteer) Address, each will now have a separate PersonToAddress record. This ensures
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 38
Transformational Technologies Division
that one system will not e.g. overwrite the other system’s notes. There is a consequential
change to the PersonToAddressHistory entity.
Organisations may also have Addresses (being linked to them through the link entity
OrganisationToAddress) but in this case there is no provision for a type. There is no
requirement either to hold a history of an Organisation’s Addresses.
An address may be held either in a structured form, including one that complies with the
BS7666 standard, or in an unstructured form. The attribute names on Address reflect the
BS7666 standard. It is recognised that not all agency systems will generate addresses in a
form that supports the BS7666 standard. The GDSC defines a Simple Address standard in
addition to the BS7666 standard. A Simple Address has up to 5 lines with a maximum of 100
characters per line. A Simple Address should be mapped to Address Lines 1 to 5 (a new
feature added since Version 1.0 Release of the core model). Note that a BS7666 address
will have a UPRN (Unique Property Reference Number), whose presence or absence will
serve to flag the address format.
AccommodationTypeCV and DwellingTypeCV are attributes that properly belong to an
Address, not to the relationship of a particular person to that Address. Accommodation types
include e.g. mainstream housing, sheltered housing, registered adult care homes, etc.
Dwelling types relate to the physical nature of the accommodation – semi-detached house,
terraced house, flat, etc.
A particular situation arises in connection with some homeless people. These may have no
address in the normal sense but it is a requirement to record an accommodation type (one of
the values being Homeless). The solution is to create an Address record with an
accommodation type but no address details.
Note that the data model does not explicitly provide for the recording of a landlord against an
address. There are various options for doing this which require further consideration. As an
interim measure, the Notes attribute on PersonToAddress can be used for sharing landlord
details.
3.5
Contact details
The following diagram shows a section of the data model relating particularly to contact
details.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 39
Transformational Technologies Division
Organisation
OrganisationID
OrganisationName
OrganisationTypeCV
OrganisationTypeDescription
OrganisationToContactDetail
OrganisationID (FK)
ContactDetailID (FK)
ContactDetail
ContactDetailID
Person
PersonID
BirthDate
BirthDateVerificationCV
DeathDate
DeathDateVerificationCV
GenderCurrentCV
EthnicGroupSelfAssignedCV
EthnicGroupSpecificCV
ReligionCV
CountryOfBirthCV
FirstLanguageCV
InterpretationAssistanceCV
PersonToContactDetail
ContactDetailData
ContactDetailTypeCV
Notes
ContectDetailID (FK)
PersonID (FK)
Either a Person or an Organisation may have one or more contact details. Contact details
include phone numbers, fax numbers, email addresses, etc. The type of contact detail is
indicated in the attribute ContactDetailTypeCV. Only current contact details are of interest –
there is no requirement for a history.
3.6
Persons, Subjects and Professionals
The following diagram shows a section of the data model relating particularly to Persons,
Subjects and Professionals. As already noted (section 2.2), the Person entity holds those
attributes that may be required for any sort of person (whether a subject, a professional or an
associated person). The Subject entity holds those attributes that are specific to the primary
subjects of information sharing. The Professional entity holds those attributes that are
specific to professionals.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 40
Transformational Technologies Division
Professional
ProfessionalRolelHistory
PersonID (FK)
PersonToProfessional
HistoryID
OrganisationID (FK)
JobTitle
EmployingAgency
OfficeBase
PersonID (FK)
ProfessionalID (FK)
PersonID (FK)
ProfessionalID (FK)
ProfessionalRoleLCV
ValidStart
ValidEnd
TransactionStart
TransactionEnd
SubjectNote
Person
PersonID
BirthDate
BirthDateVerificationCV
DeathDate
DeathDateVerificationCV
GenderCurrentCV
EthnicGroupSelfAssignedCV
EthnicGroupSpecificCV
ReligionCV
CountryOfBirthCV
FirstLanguageCV
InterpretationAssistanceCV
Organisation
PersonID (FK)
ProfessionalID (FK)
NoteTitle
NoteText
NoteRecordedDate
OrganisationID
OrganisationName
OrganisationTypeCV (FK)
OrganisationTypeDescription
Subject
PersonID (FK)
SubjectWarningFlag
SexAtBirthCV
SexualOrientationCV
PreferredLanguageCV
HouseholdCompositionCV
LivesAlone
PreferredCommunicationMethodCV
OtherCommunicationMethod
OtherImpairment
PersonRepresentativeRequired
PersonToPerson
PersonID (FK)
AssociatedPersonID (FK)
RelationshipCV
RelationshipVerificationCV
IsDependant
SubjectNoteID
PersonReference
PersonID (FK)
PersonReferenceCV (FK)
WarningFlagID
PersonID (FK)
RiskTypeCV (FK)
WarningStartDate
WarningEndDate
ContactPerson
ContactAgency
ContactPhoneNumber
ContactEmail
WarningGuidance
ExtensionSetID (FK)
Identifier
SubjectImpairment
PersonID (FK)
ImpairmentCV (FK)
SubjectAffectingDisability
PersonID (FK)
AffectingDisabilityCV (FK)
AssociatedPersonRoleHistory
HistoryID
PersonID (FK)
AssociatedPersonID (FK)
AssociatedPersonRoleCV (FK)
ValidStart
ValidEnd
TransactionStart
TransactionEnd
Controlled Vocabularies
CVControlledVocabulary
CVValue
CVID
CVValueID
CVName
CVCode
CVDescription
CVFlag
CVID (FK)
CVValueCode
CVValueText
CVValueOrder
CVValueFlag
Since the Version 1.0 Release of the core model, the Boolean attributes LivesAlone and
AppropriateAdultRequired have been restored to the Subject entity (see section 2.7 above).
Following the enhancement of the Organisation entity (see section 3.7 below), the attribute
OrganisationID has been added to Professional, for optional use when a Professional’s
employing agency has been recorded on MAS as an Organisation. This provides an
alternative to entering the name of the employing agency directly.
Note that there are two different Ethnic Group attributes on Person –
EthnicGroupSelfAssignedCV (formerly called EthnicGroupGeneralCV), which draws on a CV
with a small number of high-level values, and EthnicGroupSpecificCV, which draws on a CV
with much more specific values. This is to fulfil the requirement for flexibility in recording and
storing ethnicity data.
3.6.1 Person references
The entity PersonReference was introduced in a previous Version as a means of holding
external identifiers for a person, when these are required as viewable data items. The
external identifiers may be identifiers for a Subject (e.g. a school pupil or student’s Scottish
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 41
Transformational Technologies Division
Candidate Number, required for Children’s Services Phase 1) or for a Professional (e.g. a
doctor’s General Medical Council number).
Generally speaking, external identifiers and reference numbers may play either (or perhaps
sometimes both) of two roles within the MAS. Some, like the Scottish Candidate Number,
are genuine pieces of data in respect of which an eCare sharing requirement exists or may
exist. Others, like the client identifiers used within Local Authority Social Work IT Systems,
acquire an entry on the eCare Index once a subject has been “matched” by an agency
system. While the index entry provides the subsequent means of identifying the subject on
the MAS whenever the MAS is accessed from the relevant agency system, it does not
represent a real piece of shared data in its own right. Other agencies have no requirement to
see it.
The PersonReference entity provides for the former type of situation, where a person
identifier is or may be a data item in its own right. The Person may be either a Subject or a
Professional (or indeed an associated person). In principle, a Person could have more than
one external identifier of this sort. The Controlled Vocabulary CVPersonReference was
introduced alongside the entity to identify the type of identifier or reference number in
question; the Identifier attribute holds the actual value for the person concerned.
3.6.2 Subordinate Subject entities
SubjectImpairment and SubjectAffectingDisability are multi-select entities hanging off the
Subject entity. SubjectImpairment provides for a Subject to have one or more functional
impairments (e.g. hearing impairment, physical or motor impairment) drawn from
CVImpairment. The CV includes an “other” value. When it is selected, OtherImpairment is a
textual attribute on Subject itself which allows the nature of the unlisted impairment to be
recorded. The use of SubjectAffectingDisability is restricted to children (see section 7.3.4
below). It permits sharing of the information that a child is affected by the chronic illness or
disability of a parent or other family member. In principle, a child could fall into more than
one of the recognised categories, so that a separate entity is needed (rather than a further
attribute on Subject). In both of these cases, the eCare sharing requirement is restricted to
the current situation, so no historical records are held within the MAS.
The SubjectNote entity replaces the old Notes attribute on the Subject entity. It allows each
Note to be held separately, reducing the danger that one partner agency’s note will be
overwritten by another. The author of the note may optionally be recorded (as
ProfessionalID). The note is also dated, and may be given a brief title if desired.
The SubjectWarningFlag entity is a further new entity hanging off the Subject entity. It is
discussed in the following sub-section.
3.6.3 Warning flags
The SubjectWarningFlag entity reflects the general duty on agencies to protect children and
vulnerable adults (see section 7.3.3 below). This duty implies an agency responsibility to
share warnings or “alerts” about potential risk. It should however be noted that the term
“alert” may be used in either of two different (though related) ways:
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 42
Transformational Technologies Division
1. To refer to an action of alerting – i.e. to a message or notification that is sent to
relevant practitioners (or agency systems) at a particular point in time.
2. To refer to a more permanent flag or marker that is attached to a data subject’s
shared record within the Multi-Agency Store and remains visible (so long as it is in
force) to anyone who subsequently accesses that record.
It is the second type of “alert” that is at issue here – i.e. the database marker. The first type
of “alert” is a kind of notification, so falls within the scope of section 10 (see particularly
section 10.5.1). To avoid confusion, the database marker is referred to as a Warning Flag.
A Warning Flag may be used to indicate either that a Subject is at potential risk or that a
Subject presents a potential risk to others. The assumption is made that where a person is
deemed to present a potential risk to others, that person will always be instituted as a
Subject (not simply as a Person) on the Multi-Agency Store.
The SubjectWarningFlag entity provides the following features:

One or more Warning Flags may be attached to a Subject.

The Controlled Vocabulary CVRiskType initially allowed a basic twofold
categorisation of potential risk into “Subject is at risk” and “Potential risk exists to
others”. More recently, a number of more specific types have been introduced for
purposes of Child Protection Messaging (see section 11 below).

Legal or operational concerns may preclude the inclusion of supplementary
information about the nature of a potential risk. Rather than provide full details of the
risk, therefore, the record includes contact details – name, agency, phone number
and email address – of a practitioner from whom further details may be obtained.
(This may or may not be the practitioner who created the Warning Flag.)

The Warning Flag has both a start date and an end date. This allows a warning to be
ended, but with a historical record still retained on the MAS.

The WarningGuidance attribute allows display of a textual message to other
practitioners (such as “Take a colleague with you if visiting”).

An ExtensionSetID attribute has been added for purposes of Child Protection
Messaging. Its use is explained in section 11 below.
Note that a Warning Flag can only relate to one Subject record. When a child or vulnerable
adult is at risk from a specific individual, the feature offers two different options. First, a
Warning Flag may be associated with the Subject record for the child or vulnerable adult who
is at risk, the RiskTypeCV attribute indicating that the “Subject is at risk”. Secondly, a
Warning Flag may be associated with the specific individual who presents a risk to the child
or vulnerable adult (so long as this individual has been instituted as a Subject), the
RiskTypeCV attribute indicating that “A potential risk exists to others”. While it is of course
possible to flag both Subjects, separate (and unrelated) Warning Flags will then attach to the
person at risk and to the person presenting a risk. In other words, the SubjectWarningFlag
entity does not provide a means of indicating from which particular person(s) within the MAS
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 43
Transformational Technologies Division
a Subject may be at risk, or to which particular person(s) a Subject may pose a risk.
It is important to emphasise that the Warning Flag feature should not be over-used, or it will
cease to be useful. Many (if not most) social care clients are at potential risk – that is why
they are social care clients. The presence of a Warning Flag is intended to signify that some
risk exists of an especially serious sort, and that any professional having dealings with the
Subject should take early steps to establish the more precise nature of this risk. To ensure
consistency of use, it may be of benefit to establish an agreed protocol within a local
Partnership area as to when and how the Warning Flag should be used.
3.6.4 Link entities
The link entity PersonToProfessional allows a relationship to be recorded between a Subject
and a Professional. The professional’s role in regard to the Subject is distinguished from the
professional’s job title – “Key worker” is a role which a professional may play in relation to
one Subject but not to another; “GP” and “Community nurse” are job titles which do not relate
to particular Subjects. JobTitle is therefore a (textual) attribute on the Professional entity.
Because the professional’s role may change over time, the ProfessionalRoleLCV attribute is
held on the ProfessionalRoleHistory entity, which is the temporal offshoot of
PersonToProfessional. The attribute is an LCV attribute because there is extensive local
variation in the language used to describe professional roles.
The link entity PersonToPerson allows a relationship to be recorded between a Subject and
an associated person. In this case, a distinction is drawn between the long-term relationship
between the two people (e.g. that the associated person is the partner or parent of the
Subject) and the changing role of the associated person, who may be e.g. a carer or
keyholder at one time but not at another. If a person ceases to be their child’s carer, they do
not cease to be their child’s parent. RelationshipCV is therefore an attribute of
PersonToPerson; AssociatedPersonRoleCV is an attribute of the temporal offshoot
AssociatedPersonRoleHistory.
3.7
Organisations
The following diagram shows a section of the data model relating particularly to
Organisations.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 44
Transformational Technologies Division
Address
AddressID
Organisation
OrganisationToContactDetail
OrganisationID
OrganisationID (FK)
ContactDetailID (FK)
OrganisationToAddress
OrganisationName
OrganisationTypeCV (FK)
OrganisationTypeDescription
AddressID (FK)
OrganisationID (FK)
Notes
Professional
PersonID (FK)
OrganisationReference
OrganisationID (FK)
JobTitle
EmployingAgency
OfficeBase
ContactDetail
ContactDetailID
ContactDetailData
ContactDetailTypeCV
Notes
OrganisationID (FK)
OrganisationReferenceCV (FK)
Identifier
UPRN
SAON
PAON
StreetDescription
Locality
Town
AdministrativeArea
AddressLine1
AddressLine2
AddressLine3
AddressLine4
AddressLine5
PostCode
Country
UnstructuredAddress
DwellingTypeCV
AccommodationTypeCV
Controlled Vocabularies
CVControlledVocabulary
CVID
CVName
CVCode
CVDescription
CVFlag
CVValue
CVValueID
CVID (FK)
CVValueCode
CVValueText
CVValueOrder
CVValueFlag
Since the Version 1.0 Release of the core model, a new (optional) attribute
OrganisationTypeCV has been added to Organisation, drawing on the new controlled
vocabulary CVOrganisationType. This will allow for the structured classification of
Organisations, when this is a requirement (as it is for educational establishments in
Children’s Services Phase 1). The optional textual attribute OrganisationType is retained,
but has been renamed OrganisationTypeDescription. This allows for the direct entry of any
organisation type that is not included in the controlled vocabulary.
The entity OrganisationReference was introduced to hold external identifiers for an
organisation, when these are required. The Controlled Vocabulary
CVOrganisationReference was introduced alongside the entity to identify the type of identifier
or reference number in question; the Identifier attribute holds the actual value for the
organisation concerned. Examples where a requirement already exists include the GP
Practice Code and (for Children’s Services Phase 1) a school’s SE Education Department
Reference Number. Other examples might include the Location Codes used by
NHSScotland’s Information and Statistics Division (ISD) for all premises (including hospitals)
where health care is provided and the Care Commission’s Service Numbers for care homes
and other regulated care services.
As already noted (section 3.6 above), the data model now allows a Professional to be
associated with an Organisation, as an alternative to the direct recording of the employing
agency on the Professional record. In view of this, it is perhaps important to emphasise that
the intention is not for the MAS to provide a single multi-agency directory of professionals
and their details.
3.8
Local identifiers for core data
An interface system can only update or delete a MAS record if there is some means of
identifying the record uniquely. Some of the core MAS entities (e.g. PersonReference,
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 45
Transformational Technologies Division
SubjectImpairment) have natural primary keys. For those entities that lack a natural primary
key, local identifiers are used to identify a record uniquely. The local identifier is passed to
the MAS by the interface system “adaptor” at the time of storing the record. For example,
Name has a local identifier. This allows an existing name to be identified for update. Without
the local identifier, there would be no means of doing this (because a person may have more
than one name and the “adaptor” has no awareness of NameID, the internal identifier
created and used by the MAS itself).
Within the core data area, the following entities have local identifiers:
 Name
 NameHistory
 PersonToAddress
 PersonToAddressHistory
 ContactDetail
 SubjectWarningFlag
 SubjectNote
 AssociatedPersonRoleHistory
 ProfessionalRoleHistory
 Organisation
 OrganisationToAddress
Because a local identifier is only known to the interface system that stored the record in
question, interface system B will be unable to update or delete a record stored by interface
system A when local identifiers are employed. It should be noted also that certain sorts of
data may come to be duplicated within the MAS. For example, more than one interface
system may have recorded the same name or contact detail for a person in the MAS, or the
same relationship to an associated person. The separate entries will be separately held,
even when they are identical. This does not apply to the data items that are directly held on
e.g. the Subject entity, where no local identifier is used. A data item on Subject (such as
Preferred Communication Method) may be recorded by one interface system and overwritten
subsequently by another.
The MAS holds local identifiers in a separate physical table for each entity that makes use of
them. This being a matter that pertains to physical implementation, they are not shown in the
logical data model.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 46
Transformational Technologies Division
4.
Disclosure Conditions for Personal Data
4.1
The conditions for sharing personal data
The sharing of Subject data through the MAS is constrained by the law (most importantly, by
the Data Protection Act 1998), by partner agency policies and codes of practice, and by the
Information Sharing Protocol adopted by the eCare partnership in question (see section 3.5
of the eCare Data Policy Document [2]). In general, the legitimate sharing of Subject data
depends on two separate conditions being satisfied:
A. 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
B. It is necessary and relevant to share the data.
Subject consent on its own is not sufficient justification for the sharing of data. The “feeder”
systems for the MAS are legally separate repositories of data, each with its own data
controller, who, by section 4(4) of the Data Protection Act 1998, is under a “duty … to comply
with the data protection principles in relation to all personal data with respect to which he is
the data controller”. Irrespective of consent, disclosure of that data must always comply with
the third data protection principle, which says that “Personal data shall be adequate, relevant
and not excessive in relation to the purpose or purposes for which they are processed” (Data
Protection Act 1998, Schedule 1). In guidance on the Use and Disclosure of Health Data,
the Information Commissioner comments that “The disclosure of personal data where this is
not actually necessary would be likely to contravene this principle” [16, p. 4]. That data
disclosure to other agencies is relevant and necessary in a given case is a matter of
accountable professional judgement.
An interface system may be either (a) a discloser of data with regard to a Subject (i.e. an
updating contributor of data to the MAS for that Subject) or (b) only a viewer of data with
regard to that Subject. If an interface system is a contributor system for a Subject, some
competent professional within that system must have authorised the disclosing of data, and
both the identity of that professional and the basis for the decision require to be recorded in
the MAS. If two systems are both contributor systems for the same Subject, there must be a
separate “authority to disclose” in respect of each system, even if both of these derive from a
single client consent. But if a system is simply a viewer of the Subject’s data, there is no
need for an “authority to disclose” in respect of that system.
In principle, two different approaches might be adopted to the gathering of subject consent to
data sharing through the MAS (or of consent from a parent or proxy, if the data subject is an
“incapable” child or adult).
(1) In a “cross-partnership” approach, a practitioner from one partner agency would seek
consent to data sharing, not just on behalf of his or her own agency or service
sector, but on behalf of all the partner agencies within the eCare partnership in
question. If the practitioner were a health practitioner, for example, the consent
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 47
Transformational Technologies Division
would cover relevant disclosure not just of the person’s Health data to the MAS, but
of data from other partner agency systems (such as Social Work, Housing or
Education). If “cross-partnership” consent were initially obtained for a limited period
(e.g. a year), it might then fall to a practitioner from a different partner agency to
secure its renewal (for example, if lead responsibility had been transferred from
Health to Social Work in the interim).
(2) In what might be called a “sectoral” approach, a practitioner would seek consent
solely on behalf of his or her own agency or care sector. For a health practitioner,
the consent question would cover relevant disclosure of the person’s Health data to
the MAS, but not disclosure of e.g. the person’s Social Work or Education data.
Consent to disclose Social Work data would be separately obtained by a Social
Work practitioner, and likewise for each of the other partner agencies. Unlike a
“cross-partnership” consent, a “sectoral” consent would not be renewed by a
practitioner from a different sector (though it might in time be replaced by a “crosspartnership” consent).
It is the current intention that the gathering of subject consent to data sharing through the
MAS should follow the first, “cross-partnership” approach, i.e. that it should be obtained by a
single practitioner on behalf of all partner agencies. But the data model also accommodates
the “sectoral” approach to consent, in case this alternative approach is preferred by a
particular eCare partnership or is adopted initially as a transitional basis for data sharing.
Because a “sectoral” consent is internal to the sector in question and is only renewed from
within the sector, this approach requires less detail to be held in the MAS itself.
It is important to note that whichever approach is adopted, for the person’s “informed”
consent to be pertinent to disclosure of personal data to the MAS, it must be clear from the
consent question that the shared data covered by the question – whether this is just e.g.
Health data (in a “sectoral” approach) or all partner agency data (in the intended “crosspartnership” approach) – will be potentially viewable by any eCare partner agency which has
or acquires a service involvement with the data subject.
4.2
Logical Data Model for Disclosure Conditions
The following diagram shows the logical view of the data model for Disclosure Conditions.
As in other cases, it omits the two auditing attributes (AuditLogID and ModifiedDate) that are
common to every entity. It also omits some of the relationships between CVValue and other
entities.
Note that the ExternalReference, PrimaryIndex and PersonStatus entities have been omitted
from this diagram (in Version 1.4 of this document) following the transfer of these entities to
the Hub (see section 2.3 above). Although also transferred to the Hub, the InterfaceSystem
entity is retained in the diagram because of its continuing logical relevance to other entities.
(In fact, the entire Indexing system remains of relevance to the diagram, as establishing the
link between InterfaceSystem and Person; but the chain of linkage is now more complex, and
cannot easily be depicted in the diagram. It can be traced by conjoining the diagram with the
Hub data model diagram – for which, see [11]. This also applies to the PersonStatus entity.)
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 48
Transformational Technologies Division
The Data Dictionary for this part of the data model can be found in section 12.3.
Subject
PersonID (FK)
InterfaceSystem
SexAtBirthCV
SexualOrientationCV
PreferredLanguageCV
HouseholdCompositionCV
LivesAlone
PreferredCommunicationMethodCV
OtherCommunicationMethod
OtherImpairment
PersonRepresentativeRequired
InterfaceSystemID
SystemName
SystemDescription
DisclosureAuthority
PersonID (FK)
InterfaceSystemID (FK)
Person
PartnershipConsent
PersonID
BirthDate
BirthDateVerificationCV
DeathDate
DeathDateVerificationCV
GenderCurrentCV
EthnicGroupSelfAssignedCV
EthnicGroupSpecificCV
ReligionCV
CountryOfBirthCV
FirstLanguageCV
InterpretationAssistanceCV
PartnershipConsentID
PersonID (FK)
DisclosureAuthorityHistory
AuthorityHistoryID
PersonID (FK)
InterfaceSystemID (FK)
AuthorityStatusCV (FK)
AuthorisingProfessional
AuthorityStatusReason
PartnershipConsentID (FK)
IsConsentedForSector
ValidStart
ValidEnd
PartnershipConsentHistory
PartnershipConsentHistoryID
PartnershipConsentID (FK)
ConsentStatusCV (FK)
ConsentTypeCV (FK)
ConsentProfessional
ConsentAgency
ConsentNote
ValidStart
ValidEnd
Controlled Vocabularies
CVControlledVocabulary
CVID
CVName
CVCode
CVDescription
CVFlag
4.3
CVValue
CVValueID
CVID (FK)
CVValueCode
CVValueText
CVValueOrder
CVValueFlag
The Consent and Disclosure entities in detail
The diagram shows that the Data Model handles Subject consent and “authority to disclose”
through the separate entities PartnershipConsent and DisclosureAuthority (so long as
consent is indeed secured on a “cross-partnership” basis). Each of these entities has an
associated history entity (PartnershipConsentHistory and DisclosureAuthorityHistory
respectively). This means that several (interface system-specific) "authorities to disclose
data" (i.e. to contribute Subject data to the MAS) can all relate to the same (interface systemneutral) Subject consent. But any interface system can decide to disclose data in the
absence of Subject consent (the “override” situation). Likewise, a decision can be taken to
continue to disclose data even though the Subject (or their parent or proxy) has withdrawn
consent to such disclosure.
It is the expectation that Subject consent to data sharing will not run indefinitely – i.e. that it
will be obtained for a specified period (e.g. a year), and will be renewed (if the sharing
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 49
Transformational Technologies Division
requirement continues) when this period expires. So far as the MAS is concerned, renewal
of an existing (“cross-partnership”) consent is reflected in the creation of a new
PartnershipConsentHistory entry, not in the creation of a new PartnershipConsent entry (so
that PartnershipConsentID remains the same). Note also that the Data Model relates
PartnershipConsent and DisclosureAuthority to Person rather than to Subject, thus allowing
for the possibility that eCare Consent requirements might be extended to associated persons
as well as to Subjects.
Each DisclosureAuthority has a separate history entry (or entries) with a ValidStart and a
ValidEnd. The default value for ValidEnd on the current record will be UC (“Until Changed”)
if the interface system has not passed through an end date to the MAS. AuthorityStatusCV
draws its values from CVAuthorityStatus, these being “Disclosure authorised” and
“Authorisation ended or suspended”. AuthorisingProfessional is a text field which identifies
the professional who authorised / suspended disclosure of data from the interface system in
question (not the professional who obtained consent, if consent was obtained). No attempt is
made to establish a relationship with the Professional entity in the MAS. The
AuthorityStatusReason will be a reason for disclosing data or for the suspension of
disclosure as the case may be. It is particularly pertinent in an “override” situation, where the
person’s consent to disclosure has either not been sought or not been given.
Where (as will normally be the case) the “authority to disclose” is grounded in the person’s
“cross-partnership” consent, PartnershipConsentID establishes the connection. So long as
consent continues to be given, the periodic renewal of this consent does not generate a new
DisclosureAuthorityHistory entry. For the same reason, ValidEnd on
DisclosureAuthorityHistory may be UC even though there is a (future) end date on the
associated PartnershipConsentHistory record. As already noted, several “authorities to
disclose” may be grounded in the same “cross-partnership” consent. A PartnershipConsent
entry for a Person (a Subject or, potentially, an associated person) will only exist if the
Person (or a parent or proxy) has at some time given “cross-partnership” consent to the
sharing of data across the partnership – it will not exist if consent has always been “sectoral”,
or if it has never been given at all.
The data model also provides for adoption of the alternative “sectoral” approach to securing
consent. It does this through the Boolean (true/false) attribute IsConsentedForSector on the
DisclosureAuthorityHistory entity. This attribute will only have the value “true” if an agency
system’s “authority to disclose” is rooted in a subject consent that relates simply to data from
that agency or sector. It will have the value “false” (or be null) when either the “authority to
disclose” is rooted in a “cross-partnership” consent (in which case PartnershipConsentID will
have a value) or an “override” situation exists (i.e. data is being disclosed in the absence of
subject consent). Conversely, of course, the existence of an “override” situation is indicated
by the absence from the current DisclosureAuthorityHistory entry of either a currently valid
PartnershipConsentID or a “true” value for IsConsentedForSector.
As already noted, renewal of a “cross-partnership” consent may sometimes be secured by a
different agency from the one that initially obtained the consent. Whether this is the case or
not, the renewal still relates to the same PartnershipConsent on the MAS and is secured
again on behalf of the whole partnership. Once a “cross-partnership” consent has been
secured (and Subject data, including the PartnershipConsent entry, has been recorded on
the MAS), partner agencies will be able to check the existing consent status for a person and
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 50
Transformational Technologies Division
thus avoid asking again for a consent which has already been given. Where they have
matched a Subject, they will receive a notification of any changes to the consent status (see
section 10 below), including a withdrawal of consent if this should occur.
For a “cross-partnership” consent, consent details are held on the PartnershipConsentHistory
entity. Only minimal consent details are held in the MAS (including those details that might
be particularly pertinent if a different agency were renewing the consent). Any other details
are a matter for the agency system in which the consent is first recorded. The default value
for ValidEnd on the current record will again be UC (“Until Changed”) if the interface system
has not passed through an expiry date to the MAS. ConsentStatusCV draws its values from
CVConsentStatus, these being “Consent given”, “Consent qualified” and “Consent
withdrawn”. “Consent given” covers both the initial giving of consent and any subsequent
renewal of consent on the same terms as before. “Consent qualified” would be used if the
person amended or enlarged the terms of his or her original consent (whether at the time of
periodic renewal or at some earlier time), or if e.g. the person’s own consent were substituted
for that of a parent or proxy (see below). Note that within the MAS, a simple expiry of
consent is indicated through the end date on the latest PartnershipConsentHistory record – a
new History record is not created at the point of expiry. For this reason, CVConsentStatus
does not include a “Consent expired” value. Agency systems may of course add such a
value for purposes of front-end display to users.
ConsentTypeCV draws its values from CVConsentType, these being “Consent / withdrawal
by data subject”, “Consent / withdrawal by parent (or person with parental responsibility)” and
“Consent / withdrawal by proxy (under the Adults With Incapacity (Scotland) Act 2000)”.
ConsentProfessional is a text field which identifies the professional who obtained consent (or
registered a renewal, withdrawal or amendment), while ConsentAgency allows the
professional’s agency to be recorded as well. As with disclosure authority, no attempt is
made to establish a relationship with the Professional entity in the MAS – nor, where consent
is given on the person’s behalf by a parent or proxy, is this relationship reflected within the
data model. The ConsentNote attribute allows any further details to be recorded which it
might be relevant for a partner agency to know (e.g. the context in which consent was
obtained, the reason for withdrawal if it is withdrawn, the parent or proxy who gave consent
on behalf of an “incapable” child or adult, etc.)
The other entities in the diagram have already been described in sections 2 and 3.
4.4
Updating and viewing Subject data in the MAS
The MAS should not accept a Subject update from an interface system unless it has a
current “authority to disclose” from that system. This means that the first updating message
from the system in respect of the Subject must include an “authority to disclose” in respect of
that system. But note that this is not a requirement where an interface system has “matched”
a Subject simply in order to view MAS data contributed by other partner systems (i.e. the
only “update” is to the PrimaryIndex table).
Where the Subject has given a “cross-partnership” consent to data sharing, the first upload of
data from any system should also include the consent details (the first upload being at the
point, subsequent to the initial creation of a dummy Person record, where the Person record
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 51
Transformational Technologies Division
is populated with data and the Subject record is created – see section 2.3 above). Where a
further interface system becomes a contributor of data in respect of a Subject for whom a
current PartnershipConsent exists on the MAS, it is assumed that the new system’s
“authority to disclose” is rooted in this existing consent.
In normal circumstances, sharing (i.e. viewing data) will continue through the MAS so long as
at least one “authority to disclose” is current – i.e. there is at least one
DisclosureAuthorityHistory record with AuthorityStatusCV = “Disclosure authorised” and
ValidEnd = UC (or a future date). The fact that a particular interface system ceases to
contribute data to the MAS (by changing AuthorityStatusCV to “Authorisation ended or
suspended”) does not in itself bring an end to data sharing for the Subject in question. Nor
does withdrawal of the Subject’s consent, so long as an interface system continues to
authorise disclosure. If no disclosure authority remains current (i.e. no interface system is
currently contributing data in respect of the Subject to the MAS), it remains a separate
question whether to terminate the viewing of existing MAS data. There might, for example,
be a need to retain some shared documentation in relation to case decisions already taken.
Access permissions are defined through the PersonStatus entity – now (Version 1.4 of this
document) relocated to the Hub – and a change to these is not automatically generated
within the MAS by changes to a Subject’s consent or disclosure authority status. Unless and
until a manual intervention is made to change the person’s current access status, existing
data will remain viewable.
For a given Subject, the Disclosure Conditions data model, when conjoined with the Indexing
systems that now (Version 1.4 of this document) form part of the Hub data model [11], will
allow a practitioner to see (a) which interface systems are able to view the Subject’s data on
the MAS (namely those that have “matched” the Subject and therefore have a PrimaryIndex
entry for the Subject) and (b) which interface systems are contributors of Subject data to the
MAS (namely those that have a current DisclosureAuthority entry for the Subject). (In earlier
Versions of this document, prior to the transfer of the Index to the Hub, both (a) and (b) were
visible within the Disclosure Conditions data model diagram; following the transfer, only (b) is
visible within the diagram.) The SystemDescription attribute (see section 3.1 above) has
been added to the InterfaceSystem entity as a means of supporting a more meaningful
description of the agencies or user groups who are currently able to view (or authorised to
update) the Subject’s record on the MAS.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 52
Transformational Technologies Division
5. Dynamic Entities: Processes, Status Episodes
and Events
5.1
Background
Sections 2 and 3 have described the core MAS entities which are fundamental to information
sharing – in particular, Person, Subject, Professional, Name, Address and the relationships
between these. Section 8 will describe a generic structure for sharing the sorts of more
detailed information that are normally captured or recorded in a standard form – e.g. in a
referral form or single shared assessment form or in a care plan or personal life plan. There
is a missing information layer between these, however, which encompasses the dynamic or
changing entities to which “structured” forms (and / or “unstructured” records of similarly
detailed information such as word-processed documents, if these become shareable in
future) are generally attached. The most important of these dynamic entities (and the most
relevant to forms) are the various agency or inter-agency processes through which
information is gathered about a person (for example, social care assessments) or decisions
are made as to the services that should be set in place to meet their needs (for example,
care planning processes); but there are other dynamic entities (e.g. events) about which
information can also usefully be shared through the Multi-Agency Store.
In initial outline, the shared information picture can be depicted as follows:
Forms
Dynamic
entities
Core entities
The main purpose of sections 5 and 6 is to give a fuller general description of the entities and
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 53
Transformational Technologies Division
attributes in the intermediate, Dynamic Entities ring. In conjunction with this, the discussion
serves to introduce the concept of an “extension attribute”, as an alternative way of holding
more detailed information within the outermost ring in circumstances in which the relative
complexity of a form is not required. Section 7 focuses attention on the specific requirements
of Children’s Services. In the initial phase (Children’s Services Phase 1), it is not intended
that forms should be used as a means of sharing detailed information about children.
Extension attributes will provide a sufficient basis for the more limited information sharing
that is envisaged at this early stage.
5.2
The three dynamic entities
The data model for the intermediate layer is organised around three basic dynamic entities,
Process, Status Episode and Event. Their main distinguishing features are summarised in
the following table:
Entity
Description
Date attributes
Process
A period of purposeful activity on the part of a
service provider or care agency (or of more than
one agency acting jointly), typically aimed at
advancing a Subject onwards along a care
pathway appropriate to his or her needs.
Start and end date
Status Episode
A period of possession of a defined (special or
noteworthy) status.
Start and end date
Event
An occurrence at a single point in time.
Event date
In rather more detail, the three entities can be characterised as follows.
1. Processes are the agency or inter-agency processes through which a subject is
advanced along a care or service pathway appropriate to his or her needs – referrals,
assessments, care management processes, reviews, investigations, and so forth. A
process will often extend over days, weeks or even months and may encompass
several different stages. The process may very often be one in which detailed
information is gathered about the person’s circumstances and needs (for example, an
assessment), or decisions are made as to the services that should be set in place to
meet those needs (for example, a care planning process). So far as information
sharing is concerned, there is frequently a requirement to share – or indeed, in the
case of an inter-agency process, jointly to contribute – a substantial body of detailed
information which has been generated by the process. For this purpose, one or more
forms can be attached to a process within the MAS.
2. Events can be treated as happening at a single point of time. Events about which
information might require to be shared include significant life events (e.g. the birth of
a sibling or a parent’s illness) and significant service events that fall outwith the
routine succession of agency processes (e.g. one-off professional interventions or
actions of various sorts). When strung together, these shared events provide the
main ingredient in an outline chronology for the subject. Events may be described
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 54
Transformational Technologies Division
through a textual narrative within the MAS, but do not give rise to a structured form.
3. Status episodes constitute a third type of generic entity within the intermediate layer.
Their common characteristic is the time-bounded possession of a determinate status
– whether a marital or employment status, a service-related status such as being a
hospital inpatient or a pupil, or a legally defined status such as being on the child
protection register. The associated information that needs to be shared is usually
quite limited.
The eCare Multi-Agency Store Data Model handles each of these dynamic entities through
the combination of a fairly bare generic core entity (a Process, Event or Status Episode), a
standard typology for the entity (i.e. a standard set of Process Types, etc.) and the potential
for associating a number of specific “extension attributes” with a given Process Type, Event
Type or Status Episode Type. A referral, for example, may be expressed in the model as a
process of Process Type “Making a Referral / Request for Assistance”. The generic process
entity furnishes the small set of attributes that are common to all processes, such as the start
and end dates (and in addition a generic PersonToProcess link entity relates the process to
its various participants); the Process Type “Making a Referral / Request for Assistance” then
adds the extension attributes needed to hold those extra data items (such as the reason for
referral) that are standardly required for this particular Process Type. (In the case of a
Process, however, the real information substance will very often be held in a form – or
perhaps in a number of different forms, added serially to the MAS Process as the process
itself progresses.)
5.3
Processes versus Events
As all the terms used in this “dynamic” area are slightly fuzzy terms, the distinction between
the entities perhaps merits some further explanation. The most obvious distinction is that
between Processes and Events. Several points of difference can be noted between a typical
process and a typical event.

As already noted, processes usually have a significant duration – i.e. an end date
that is later than the start date (or a process may be still continuing at the time of
recording) – while events can be treated as occurring at a single point in time.

The processes about which information is to be shared through eCare will be
generally recognised, purposeful and rule-governed processes or procedures which
are carried out routinely within an agency or service context – e.g. investigations,
assessments, care planning, reviews, etc. This means that one or more agency
professionals will always take responsibility for the conduct of a process. Within any
agency there will also tend to be a standardised or prescribed way of carrying out a
process. As a result, each type of process tends, in a given agency context, to have
its own internal sequence and structure. But it is worth noting that the sequence and
structure may be specific to that particular agency – a process known by the same
name in another agency (e.g. an “assessment” or a “referral”) could well exhibit a
rather different sequence and structure, even if its general purpose is similar. This is
a potential source of problems when information comes to be shared.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 55
Transformational Technologies Division
Events may include life events (e.g. death of a carer) which fall entirely outwith the
sphere of agency responsibility, as well as service interventions or one-off contacts
between agencies and their clients. When events are “service” events, they tend to
be less structured than processes.

Processes typically involve the systematic gathering of information about a person or
their circumstances (as in an investigation or assessment) or the ordered generation
of information relevant to a person (as in a care plan). This information content or
subject matter which ensues from the process (“process-generated” information) is
information about something other than the process (e.g. the subject’s needs, the
subject’s background situation or the services that are due to be provided to the
subject) and is often recorded in a Form. It can be distinguished from a second sort
of information which is about the process itself (“process-descriptive” information) –
e.g. the professionals involved or the start and end dates.
For most events (though not perhaps for some agency contacts), the information that
it is mainly relevant to record and share is information about the event rather than
information acquired through the event.
Some sorts of agency or inter-agency “happening” may fall into the border territory between
“processes” and “events”, so that either term might seem appropriate. A referral, for
example, could be viewed by some agencies (or practitioners) as a process, by others as an
event. The same applies to those sorts of children’s assessments that are carried out (e.g.
by an educational psychologist) in a single session with the child – being in this respect
unlike community care assessments of need, which typically stretch out over several weeks
and involve multiple meetings or exchanges with the client, carers, and concerned
professionals. The former could be viewed as “events”, but it may be less confusing in the
MAS context to classify all assessments as processes, and to follow the same convention in
all the “borderline” cases. Adopting this convention will help to simplify InterMAS
communication. Within the data model, the main difference is that only Processes can be
associated with Forms, while both Process Types and Event Types can be associated with
extension attribute sets. Other (relatively minor) differences lie in the standard attributes and
relationships that adhere to a Process and an Event respectively.
5.4
Processes
Processes not only lie at the heart of service activity, their character is liable to be affected by
the introduction of eCare itself. The MAS is not simply a repository for process-related
information, it is intended to become an enabling medium for inter-agency processes. For
this reason, a flexible and adaptable data structure is required.
Within the overall MAS data model, the “process-generated” information – i.e. the information
that is derived from (or through) processes rather than being about the process itself –
currently falls into two categories:
1. Structured data items, held as defined attributes of Subjects or other related entities.
2. Form-based information, held in a generic Question and Answer format (expressed
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 56
Transformational Technologies Division
through a cluster of Form-related entities and attributes).
As earlier implied, a third category may be added in future, namely “unstructured data” (e.g.
word-processed or scanned documents). Although invisible to the MAS, this may sometimes
possess an internal structure which, from the user’s perspective, is comparable to that of a
Form.
It may also tend to be necessary to share some “process-descriptive” information about the
processes themselves – i.e. structured metadata such as the type of process, process start
and end dates, professionals involved in the process, the current status of the process, etc.
Very probably, less of this will be required in a sharing context than within an agency system
– where the process is a single agency process, other agencies can be spared much of the
procedural detail that has to be held internally. Indeed a “minimalist” approach to process
description within the MAS is likely to reduce terminological friction between agencies and
thus perhaps foster a more effective sharing of the “process-generated” information which it
is truly important to share.
Some “process-descriptive” information is nevertheless important to share, in particular the
identity of the professionals involved in the process. To the extent that the “processdescriptive” data items are common to all types of processes, they are held as attributes of a
generic Process entity.
In a social care context, commonly encountered types of process might well include any or
all of the following:
 Referral,
 Screening,
 Allocation,
 Assessment,
 Investigation or inquiry (e.g. in a child protection context),
 Care planning (or individual service planning),
 Care management,
 Request for service,
 Service commissioning,
 Service provision,
 Monitoring,
 Risk management,
 Review,
 Transfer of care.
However not all social care agencies would recognise all of these as distinct agency
processes. There may be systematic differences between e.g. the Health and the Social
Work perspectives. Even within Social Work, some Social Work Departments recognise
“screening” as a distinct process and others do not. In addition, the “same” process term
may mean something rather different in different localities. For example, some agencies
distinguish between a “review” and a subsequent “re-assessment” where others might see
these as simply two parts of a single “review” process; the term “assessment” may or may
not be understood to encompass care planning as well as the initial assessment of needs; in
some places, the term “care plan” is used to mean an “ideal world” description of the services
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 57
Transformational Technologies Division
that would fully meet a person’s assessed needs, before resource considerations are taken
into account; in others, it is a “real world” description of the services a person is actually
going to get (which may be rather less than they truly need).
A further potential complication is that many agencies make distinctions within these process
types. In relation to assessments, for example, there may sometimes be a distinction
between:



Needs assessments and risk assessments.
Core assessments, specialist assessments, self-assessments, etc.
Simple, standard and comprehensive assessments, etc.
Agencies also differ in what they count as a single assessment. Where one local authority
will regard e.g. a core assessment and two follow-on specialist assessments for the same
client as three separate assessments, another will view these as a single assessment with
three constituent parts. Likewise one local authority may count the assessment of an elderly
couple or a family as just one assessment where another would count a separate
assessment for each separate person whose needs are subject to assessment. There is no
strong reason to prefer one approach to another – it is simply a matter of local convention.
The wide range of procedural and terminological variation between eCare partnerships (and
even sometimes between different agencies within the same partnership) is relevant to two
important questions for data modelling.
1. Should the data model handle all processes through a single, generic Process entity
or would it be better to introduce a separate entity (e.g. a Referral entity, an
Assessment entity, a Care Planning entity, a Review entity, an Investigation entity,
etc.) for each distinct type of Process?
2. If the former option is chosen (i.e. a single Process entity), then one of the data items
on the Process entity will clearly have to be a Process Type. The different Process
Types will be listed in a Controlled Vocabulary. In this scenario, is there likely to be
sufficiently broad agreement as to a list of recognisable processes to sustain a
national set of Process Types in a national CV? Or would it be better to leave it to
each local eCare partnership to define its own Process Types in a local CV?
In response to the first question, the single Process entity option seems preferable, for a
number of reasons. First, both the fuzzy and variable use of process terms and the potential
proliferation, as the eCare Programme evolves, of an increasing number of different process
types point strongly towards handling all processes through a single entity, the processes
being then distinguished by type. Secondly, because many data items and relationships are
common to every sort of process, a single entity would reduce the extent of duplication within
the model. And thirdly, all processes are liable to be associated with forms, and a single
entity provides a clearer way of modelling this common relationship.
At first sight, the varied local procedures (and / or varied local ways of describing what may
be at root the same procedures) might also seem an argument for leaving it to each eCare
partnership to agree its own set of local Process Types, which would become the values in
an LCV. It may prove difficult enough to reach agreement between e.g. the various local
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 58
Transformational Technologies Division
Health, Social Work and Housing agencies on a common typology for Processes within the
same local partnership area, let alone across Scotland as a whole. (It is perhaps relevant to
note here that on the Social Work side there tends to be much greater uniformity of usage
within the old Regional boundaries than between them. As the local authority Social Work
Departments within each eCare Partnership will all have emerged from the same pre-1996
Region, there is some prospect that they may still adhere to a common Process typology
within the Partnership, even if it differs from the Partnership next door.)
An important argument against an LCV is the emergence of national data standards for
certain specific Process Types, particularly in relation to children. For example, national data
standards are being developed for child protection investigations and enquiries. For each of
the “nationally defined” Process Types, the standards require one or more additional, Typespecific attributes to be shared over and above the generic attributes that apply to all
Processes – e.g. the investigation outcome (chosen from a CV) in the case of a child
protection investigation, concern factors (again chosen from a CV) in the case of a request
for assistance, or indeed the lead assessment agency in the case of a community care
assessment.
On balance, therefore, a national CV seems the better option, particularly as the data model
allows scope for local partnerships to nest their own lower-level distinctions within a higherlevel national structure. There are two means of doing this. The first is to make use of the
fact that the controlled vocabulary data structure allows for the creation of hierarchical CVs.
For example, if e.g. “Community Care Assessment” were defined as a national Process
Type, it would be possible for a local Partnership then to subdivide this national Type into
e.g. “Community Care Core Assessment” and “Community Care Specialist Assessment” as
lower level, local Process Types.
As an alternative to this, local distinctions might be reflected at the level of the Forms that
attach to a Process, rather than at the level of the Process itself. Within the MAS, a Process
is designed to be a broad sharing hook on which a number of different Forms can be hung
(and, in future, items of unstructured data as well). For example, there is a good operational
and professional case for handling Assessment and Care Planning together as an integral
(and perhaps extended) Process, to which different structured or unstructured forms (core
assessments, specialist assessments, care plan) can be serially attached, perhaps by
different partners. The form types can then be locally (or nationally) classified as required.
At the time document version 1.2 was drafted, the list of standard national Process Types
was as follows:
 Making an Inter-Agency Referral / Request for Assistance
 Screening / Processing a Received Referral / Request for Assistance
 Community Care Assessment and / or Care or Service Planning
 Children’s Assessment and / or Care or Service Planning
 Justice Assessment
 Financial Assessment
 Assessment under Mental Health Legislation
 Other Assessment and / or Care or Service Planning
 Care Package Procurement and Management
 Service Provision
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 59
Transformational Technologies Division













Routine or Planned Review
Child Protection Investigation
Child Protection Inquiry
Other Investigation or Inquiry
Legal process
Request for Service(s)
Request for Specialist Assessment
Sharing a Concern
Placement
Admission
Discharge
Inter-Agency Discussion
Locally defined process
For a more detailed discussion of these process types, see the Standards Branch document
“Process, Event, and Status Episode Types for eCare Framework” [13].
There could potentially be a requirement for a national sub-division within higher level
Process Types (e.g. for nationally standard sub-types within “Community Care Assessment
and / or Care or Service Planning”). In principle, there are three different ways in which a
national two-tier typology might be effected. As with local distinctions, the first option is to
make use of hierarchical CVs. If this option were chosen, any given process for a particular
client could be identified either at a higher or a lower level, there being a separate CVValue
entry for each (which should always have a free-standing value description). Although the
hierarchical organisation of CVs is primarily intended for documentation purposes, a lower
level Process Type might be given specific extension attributes that were not available at the
higher level. But if this is not a requirement, a second option (which applies only to national
sub-types) is to introduce an extension attribute for each higher level Process Type for which
a subordinate typology is required. Something of this sort is already in place for Children’s
Assessments, the extension attribute ChildAssessmentTypeCV introducing a sub-typology
specific to this Process Type. And the third option is to introduce these distinctions at Form
rather than Process level.
It is important to note that as with the Process entity itself, a Process typology only has to
meet the requirements of information sharing (and joint working) between agencies within a
partnership area. It does not have to reflect all the procedural complexities within each
partner agency. eCare is not in the first instance a workflow or work management system, it
is a means of sharing information about a shared clientele.
5.5
Events and Chronologies
A Subject of information sharing may sometimes be affected by or involved in an event which
seems sufficiently important for a partnership agency to wish to pass on information about it
to other local agencies that share an interest in the Subject in question. Examples might be
a critical health incident such as a fall or an illness, the illness of a carer, or a service
intervention of a short-lived sort that would not in itself be regarded as a process. The Event
entity provides the basis for sharing this kind of information through the Multi-Agency Store.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 60
Transformational Technologies Division
In the Children’s Services area (see section 7 below), it also provides the basis for sharing
information about certain more specifically defined events such as A & E attendances or
Children’s Hearings. It should be noted that “events” can include future (i.e. planned) events
as well as past events.
Where information is recorded and shared about events, this can be used by an interface
application to generate a chronology for the person who is the primary subject of information
sharing, listing significant events for the user to view (and if required, drill down into) in event
date order. The requirement for a chronology greatly strengthens the case for handling
different sorts of events within MAS in a generic way, with the event date as the common
point of focus. If required, the start and / or completion date for a process (or a status
episode) could also be inserted into a common chronology.
For many types of event, not much structure is required. Most of the salient information can
be shared through a long textual description. A short description will provide a summary title
suitable for display in a chronological list. In the Children’s Services area, however, a
number of specific event types have been defined, each of which requires certain particular
pieces of information to be shared through extension attributes. Because of this, it may be
appropriate, as with Processes, to define a standard top-level set of event types in a national
CV, with the local option to sub-divide these further if required.
Event types currently include:
 Life event
 Service event
o Professional intervention or action (including crisis intervention)
o **Home visit
o **Establishment visit
o Inter-professional meeting
o **Children’s Hearing
o One-off service delivery event (e.g. supply of equipment and adaptations)
o Other service event
 Medical event
o Medical diagnosis
o Immunisation
o Medication prescription
o Medical treatment
o Other medical event
 Hospital event
o **A & E attendance
o Outpatient attendance
o Hospital inpatient admission
o Hospital inpatient discharge
o Other hospital event
 Educational event
o ** School exclusion
o Other educational event
 “Statutory” event
 Locally defined event type
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 61
Transformational Technologies Division
The values marked with a double asterisk are those required for Children’s Services Phase 1
purposes. For a more detailed discussion of these event types, see the Standards Branch
document “Process, Event, and Status Episode Types for eCare Framework” [13].
5.6
Status Episodes
Like Processes, Status Episodes have both a start date and an end date, but they are not
processes in the sense defined above. A Process must engage one or more agency
professionals in a structured period of accountable activity. It typically involves the
systematic gathering or generation of information about a Subject and typically moves the
Subject onwards to a further stage in a structured care or service pathway. A Status Episode
is more passive and inert, and need not imply an agency involvement of any sort – though it
is sometimes the end state that results from an agency or inter-agency process. The
common factor (which again points towards a single, generic entity) is the time-bounded
possession of a determinate status – whether a marital or employment status, a status as
inpatient or pupil, or e.g. the legally-defined status of being looked after or on the child
protection register.
Status Episode types might include:
 Marital status
 Employment status
 Hospital inpatient stay
 Care home stay
 Stay in other residential accommodation
 Period of specialist treatment, therapy, counselling or behaviour management
 Training involvement
 Work experience
 **Educational attendance
 **Legal status
 **Looked after or accommodated episode
 **Child protection registration
 Locally defined status episode type
As with Event types, the values marked with a double asterisk are those required for
Children’s Services Phase 1 purposes. Marital Status and Employment Status are
highlighted in the list because they are regarded as items of core personal data. As has
already been noted, they were formerly handled through separate entities (located in the
“core” part of the data model). Although they are now handled as Status Episode types, they
differ from the other Status Episode types insofar as the associated statuses are exhaustive.
In other words, every subject has some marital status and some employment status at any
given point in time.
For a more detailed discussion of these Status Episode types, see the Standards Branch
document “Process, Event, and Status Episode Types for eCare Framework” [13]. Note also
that for certain Status Episode types, Status Episodes of the type in question may overlap
(as when a person is simultaneously attending two different educational establishments). By
constrast, a person can only have one marital status at a given time.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 62
Transformational Technologies Division
5.7
Extension attributes
The data model allows a process, but not an event or a status episode, to be associated with
a form (or, if required, with more than one form). It is a reasonable expectation that it will be
processes rather than events or status episodes that give rise to forms, as processes most
typically generate a requirement to gather and share information in considerable (and often
locally defined) detail. There is no restriction within the model itself on the type of form that
can be associated with a given process.
Within the data model, processes, status episodes and events share an alternative
“extension” option, namely the possibility of extending the attribute set beyond the “core”
attribute set for the entity in question. The mechanics of extension will be explained in more
detail in section 6.4. By contrast with forms, an extension attribute set is strictly tied to a
defined process type, status episode type or event type. For example, the process type
“Assessment / Care or Service Planning (Community Care)” and the event type “Home visit”
will each possess an attribute set that is distinctive to the type in question and that is
additional to the “core” attribute set for processes and events respectively. This extra
information requirement is part of the reason for distinguishing them as different types.
The data model interposes a “connecting” or “hub” entity called ExtensionSet between
Processes, Status Episodes and Events on the one hand and Extension Attributes on the
other. Schematically, therefore, the picture looks like this:
Form
Process
Status
Episode
Extension
Set
Extension
Attributes
Event
The initial outline of the shared information picture (section 5.1) might now be amended as
follows:
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 63
Transformational Technologies Division
Forms
Processes
Events
Core entities
Status
Episodes
Extension
Attributes
As already noted, it is likely that at some later stage of the eCare Programme a third element
will be introduced into the outer information ring, namely unstructured documents of various
kinds (e.g. Word documents or scanned documents).
5.8
Logical Data Model for Dynamic Entities
The following diagram shows the logical view of the data model for Processes, Events and
Status Episodes. As in other cases, it omits the two auditing attributes (AuditLogID and
ModifiedDate) that are common to every entity. It also omits some of the relationships
between CVValue and other entities.
The Data Dictionary for this part of the data model can be found in section 12.4.1.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 64
Transformational Technologies Division
OrganisationReference
OrganisationID (FK)
OrganisationReferenceCV (FK)
Organisation
Professional
PersonToProcessHistory
HistoryID
ProcessID (FK)
ProfessionalID (FK)
NoteTitle
NoteText
NoteRecordedDate
PersonID
OrganisationName
OrganisationTypeCV
OrganisationTypeDescription
BirthDate
BirthDateVerificationCV
DeathDate
DeathDateVerificationCV
GenderCurrentCV
EthnicGroupSelfAssignedCV
EthnicGroupSpecificCV
ReligionCV
CountryOfBirthCV
FirstLanguageCV
InterpretationAssistanceCV
OrganisationID (FK)
JobTitle
EmployingAgency
OfficeBase
ProcessNoteID
OrganisationID
Identifier
PersonID (FK)
ProcessNote
Person
Subject
PersonID (FK)
PersonID (FK)
EventID (FK)
PersonID (FK)
ProcessID (FK)
ProcessInvolvementTypeCV
ValidStart
ValidEnd
TransactionStart
TransactionEnd
ProcessID
ProcessID (FK)
ProcessFocusLCV (FK)
IsMainFocus
EventInvolvementTypeCV
Event
Process
ProcessFocus
SexAtBirthCV
SexualOrientationCV
PreferredLanguageCV
HouseholdCompositionCV
LivesAlone
PreferredCommunicationMethodCV
OtherCommunicationMethod
OtherImpairment
PersonRepresentativeRequired
PersonToEvent
EventID
StatusEpisode
EventTypeCV
EventDate
EventTitle
EventDescription
InitiatingReference
EventStatusCV
ExtensionSetID (FK)
StatusEpisodeID
ProcessTypeCV
ProcessDescription
ProcessStartDate
ProcessEndDate
InitiatingReference
ProcessStatusLCV
ExtensionSetID (FK)
Form
PersonID (FK)
StatusEpisodeTypeID (FK)
StatusEpisodeDescription
OrganisationID (FK)
OrganisationName
InitiatingReference
ValidStart
ValidEnd
TransactionStart
TransactionEnd
ExtensionSetID (FK)
ExtensionSet
ExtensionSetID
AttributeSetID (FK)
ExtensionTable
FormID
ExtensionID
StatusEpisodeType
FormVersionID
FormStatusLCV (FK)
FormStartDate
FormCompletionDate
ExtensionSetID (FK)
AttributeID (FK)
AttributeCV
AttributeValue
AttributeBLOB
Occurrence
StatusEpisodeTypeID
ProcessToForm
ProcessID (FK)
FormID (FK)
ProcessToFormCV
AttributeSet
AttributeSetID
StatusEpisodeTypeCV (FK)
IsUnique
CVValueID (FK)
Attribute
AttributeID
AttributeSetToAttribute
Controlled Vocabularies
CVValue
CVControlledVocabulary
CVValueID
CVID
CVName
CVCode
CVDescription
CVFlag
CVID (FK)
CVValueCode
CVValueText
CVValueOrder
CVValueFlag
AttributeSetID (FK)
AttributeID (FK)
AttributeOrder
IsCurrent
AttributeName
AttributeTypeID (FK)
AttributeCVID (FK)
IsMultiValue
AttributeType
AttributeTypeID
ExtensionDataTypeCV (FK)
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 65
Transformational Technologies Division
6.
Dynamic Entities: The data model in detail
6.1
Processes
The full logical data model for the dynamic entities was shown in section 5.8. The following
diagram extracts a section of the data model relating particularly to Processes.
Person
Professional
PersonID
PersonID (FK)
BirthDate
BirthDateVerificationCV
DeathDate
DeathDateVerificationCV
GenderCurrentCV
EthnicGroupSelfAssignedCV
EthnicGroupSpecificCV
ReligionCV
CountryOfBirthCV
FirstLanguageCV
InterpretationAssistanceCV
OrganisationID
JobTitle
EmployingAgency
OfficeBase
ProcessNote
PersonToProcessHistory
ProcessNoteID
HistoryID
ProcessID (FK)
ProfessionalID (FK)
NoteTitle
NoteText
NoteRecordedDate
PersonID (FK)
ProcessID (FK)
ProcessInvolvementTypeCV
ValidStart
ValidEnd
TransactionStart
TransactionEnd
ProcessFocus
ProcessID (FK)
ProcessFocusLCV
IsMainFocus
Form
FormID
FormVersionID
FormStatusLCV
FormStartDate
FormCompletionDate
Process
ProcessID
ProcessTypeCV
ProcessDescription
ProcessStartDate
ProcessEndDate
InitiatingReference
ProcessStatusLCV
ExtensionSetID
ProcessToForm
ProcessID (FK)
FormID (FK)
ProcessToFormCV
The attributes of the main (and very bare) generic Process entity include a Process Type
(associated, as explained in section 5.4, with a national Controlled Vocabulary), a Process
Description, a Process Start Date and a Process End Date. The Process Description
provides a generic means of amplifying the nature of the Process (for example, for saying
what sort of specialist assessment is requested in the case of a “Request for Specialist
Assessment”). There is provision, in addition, for a locally defined Process Status (e.g. “In
Progress”, “Suspended”, etc.). The Initiating Reference attribute will be discussed in section
6.5.
A link entity (PersonToProcessHistory) enables a Process to be related to a Subject, a
Professional or some associated person (e.g. a relative or neighbour) who is neither of these.
The type of involvement is indicated through the attribute ProcessInvolvementTypeCV. In
principle, the link entity enables more than one Subject to be involved in a Process. The
usual case will be a single Subject for a Process, but there might well be some situations
(dependent on how a local agency chooses to structure its processes and procedures) where
e.g. all the children in a family are encompassed in a single Process, or the needs of a carer
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 66
Transformational Technologies Division
are assessed along with those of the cared-for person.
More commonly, several Professionals may be involved in a Process, one of whom will
usually act as the “lead” professional. Reflecting this, CVProcessInvolvementType includes
subordinate types of professional involvement. The initial distinction (at a national level) was
the simple distinction between involvement as “lead” professional and involvement as “other”
professional. But while this should prove generally sufficient for those processes (e.g.
assessments) that are not essentially about an extension or shift of responsibility across
different agencies, some processes take the form of an inter-agency “request”. For those
process types – e.g. referrals, requests for specialist assessments, requests for services –
where some form of request does pass from one agency (or professional) to another, two
further national values have been added to the CV: involvement as a referring / requesting
professional (the initiator of the process) and involvement as a “receiving” professional (the
person whom the process serves to activate). More recently, involvement as a “consulted”
professional has been introduced for purposes of Child Protection Inquiries (and is available
to other process types if required).
The link entity is a “history” entity primarily because professional roles (in particular, the lead
professional) may change over the course of a lengthy Process, and because it may be
important to know who filled a particular role at a particular point in time. Following the
standard pattern for temporal entities (see section 5.1 of the eCare Data Policy Document [2]
and section 2.6 above), there are two pairs of dates – a pair of “valid” dates defining the
period within which the professional actually performed the role in question and a pair of
“transaction” dates defining the recording history (i.e. when the professional was recorded as
having the role).
Hanging off Process is a subsidiary entity called ProcessFocus. The purpose of this entity is
to enable the Process to be associated with one or more locally defined focuses of service
interest. Examples might be e.g. “Mental Health”, “Learning Disability”, “Substance Misuse”,
“Carer’s Needs”, etc. (Focal categories of an entirely different kind could also be shared
through this entity, if these are already in common use locally.) There is an increasing
tendency among community care agencies to adopt a holistic approach to clients who may
well have a multiplicity of interrelated needs. This argues against the previous practice of
assigning each client to a single “client group” pigeonhole. At the same time there may
sometimes be a business requirement (e.g. a reporting requirement) to categorise a
particular process – e.g. a particular assessment – in this sort of way. The ProcessFocus
entity provides a means of doing this in a sharing context. The IsMainFocus attribute allows
one Focus to be singled out as the “main” focus if this is required for a report.
Also hanging off Process is a ProcessNote entity, which enables a Professional to share a
free-text (and dated) case note pertaining to a Process with colleagues in other agencies.
Among other uses, this could be used to record the outcome of a Process, if that is required.
As the relationship to Professional is optional, it could also be used for a system-generated
note on a Process. If required, a Process Note could be included in a chronology (with the
Note Title showing in the list).
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 67
Transformational Technologies Division
6.2
Events
The following diagram shows a section of the data model relating particularly to Events.
Person
PersonID
BirthDate
BirthDateVerificationCV
DeathDate
DeathDateVerificationCV
GenderCurrentCV
EthnicGroupSelfAssignedCV
EthnicGroupSpecificCV
ReligionCV
CountryOfBirthCV
FirstLanguageCV
InterpretationAssistanceCV
PersonToEvent
PersonID (FK)
EventID (FK)
EventInvolvementTypeCV
Event
EventID
EventTypeCV
EventDate
EventTitle
EventDescription
InitiatingReference
EventStatusCV
ExtensionSetID
Like the Process entity, the main Event entity is a bare generic entity. There is an Event
Type, an Event Date, an Event Title (which can be displayed in a chronological list) and an
Event Description (where a long textual account of the event can be held). As earlier noted
(see section 5.5 above), information sharing can extend to anticipated or planned future
events as well as to past events. The Event Status data item distinguishes between past
events, expected future events and events that were anticipated but failed to happen (upon
which failure, the event status must be updated). It also includes a further value for “events”
that were mistakenly reported to the MAS as having happened but were subsequently found
not to have happened (upon which discovery, the event status must again be updated). The
InitiatingReference attribute will be discussed in section 6.5.
An Event may be linked to some or all of a Subject, a Professional or an associated person
(such as a Subject’s relative or carer) who is neither of these (or of course to more than one
Subject, Professional or other person). The links must include a link to at least one Subject.
Rather than introduce three separate link tables, the data model again uses a single table
(PersonToEvent), the type of involvement being distinguished through the
EventInvolvementTypeCV attribute.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 68
Transformational Technologies Division
6.3
Status Episodes
The following diagram shows a section of the data model relating particularly to Status
Episodes.
Subject
PersonID
SexAtBirthCV
SexualOrientationCV
PreferredLanguageCV
HouseholdCompositionCV
LivesAlone
PreferredCommunicationMethodCV
OtherCommunicationMethod
OtherImpairment
PersonRepresentativeRequired
StatusEpisodeType
OrganisationReference
OrganisationID (FK)
OrganisationReferenceCV
Identifier
StatusEpisodeTypeID (FK)
StatusEpisodeTypeCV
IsUnique
StatusEpisode
StatusEpisodeID
Controlled Vocabularies
CVControlledVocabulary
CVID
CVName
CVCode
CVDescription
CVFlag
CVValue
CVValueID
PersonID (FK)
StatusEpisodeTypeID (FK)
StatusEpisodeDescription
OrganisationID (FK)
OrganisationName
InitiatingReference
ValidStart
ValidEnd
TransactionStart
TransactionEnd
ExtensionSetID
Organisation
OrganisationID
OrganisationName
OrganisationTypeCV
OrganisationTypeDescription
CVID (FK)
CVValueCode
CVValueText
CVValueOrder
CVValueFlag
Unlike a Process or an Event, a Status Episode can only be associated with a single Subject
– it is always some time-bounded status of a particular Subject (e.g. a marital status or legal
status) which provides its subject-matter. If three children in a family are all “looked after”
children, this is a separate status for each. For this reason, there is no link entity. The
Subject’s ID is simply recorded against the Status Episode. The Status Episode has both a
Type and a Description, but the Type (i.e. the CV attribute StatusEpisodeTypeCV) is held on
a separate entity (StatusEpisodeType) rather than directly on the StatusEpisode entity itself.
This allows a distinction to be drawn (by means of the IsUnique attribute) between those
Status Episode Types (such as “Marital status” or “Child protection registration”) which permit
only one entry for a given person at a given time and those other Types (such as
“Educational status” or “Developmental or medical status”) which permit more than one entry.
Being essentially a “history” entity, the Status Episode has both “valid” dates and “transaction
dates” (see sections 2.6 and 6.1 above). The InitiatingReference attribute will be discussed
in section 6.5.
Status Episode has two further attributes which are not wholly generic, but which apply to
sufficiently many Status Episode Types to warrant locating them on the generic entity. They
offer alternative ways of identifying the organisation, institution, agency or provider to which a
Status Episode relates. Examples include the hospital, care home or other residential
institution in the case of a residential stay, the clinic or treatment centre in the case of a
period of specialist treatment or therapy, the provider of training or work experience, and the
school or other educational establishment attended by a pupil. OrganisationID can be used
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 69
Transformational Technologies Division
where the “organisation” has an entry on the Organisation entity. OrganisationName offers a
textual alternative (which can include other details besides the name) if there is no
Organisation entry (but note that OrganisationID must be used for schools and educational
establishments – see section 7.3.5 below).
6.4
The Extension Set
As already discussed (in section 5.7 above), the data model enables a set of extension
attributes to be attached to a Process, Status Episode or Event. The following diagram
shows the section of the data model that contributes to this.
Event
EventID
StatusEpisode
EventTypeCV
EventDate
EventTitle
EventDescription
InitiatingReference
EventStatusCV
ExtensionSetID (FK)
Process
ProcessID
ProcessTypeCV
ProcessDescription
ProcessStartDate
ProcessEndDate
InitiatingReference
ProcessStatusLCV
ExtensionSetID (FK)
StatusEpisodeID
PersonID
StatusEpisodeTypeID
StatusEpisodeDescription
OrganisationID
OrganisationName
InitiatingReference
ValidStart
ValidEnd
TransactionStart
TransactionEnd
ExtensionSetID (FK)
ExtensionSet
ExtensionSetID
AttributeSetID (FK)
ExtensionTable
ExtensionID
AttributeSet
AttributeSetID
CVValueID (FK)
ExtensionSetID (FK)
AttributeID (FK)
AttributeCV
AttributeValue
AttributeBLOB
Occurrence
Attribute
Controlled Vocabularies
CVControlledVocabulary
CVValue
CVName
CVCode
CVDescription
CVFlag
AttributeID
CVValueID
CVID
CVID (FK)
CVValueCode
CVValueText
CVValueOrder
CVValueFlag
AttributeSetToAttribute
AttributeSetID (FK)
AttributeID (FK)
AttributeOrder
IsCurrent
AttributeName
AttributeTypeID (FK)
AttributeCVID (FK)
IsMultiValue
AttributeType
AttributeTypeID
ExtensionDataTypeCV (FK)
ExtensionSet is the central “hub” entity which relates a dynamic entity (Process, Status
Episode or Event) to a cluster of extension attributes. The Extension Set ID is held on the
dynamic entity as a foreign key. Each instance of an Extension Set will relate to just one of a
Process, a Status Episode or an Event.
Any Process Type, Event Type or Status Episode Type will have an entry on the CVValue
table. When e.g. an Event is recorded as being of a particular Event Type (e.g. as being an
A & E attendance), this is expressed in MAS by the CVValueID for that Event Type (which is
a “globally unique identifier”) being the value held against the attribute EventTypeCV on the
Event entity entry for the event in question.
The Event Type, Process Type or Status Episode Type may in turn be associated with a
defined set of extension attributes, the set being specific to that Type (e.g. to the Process
Type “Child Protection Inquiry”). A particular extension attribute (e.g. LocalAuthorityCV) may
be common to several attribute sets (e.g. be an extension attribute for both the Process Type
“Child Protection Inquiry” and the Status Episode Type “Child protection registration”). This
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 70
Transformational Technologies Division
is provided for by the inclusion of three linked entities – AttributeSet, for the set as a whole
(e.g. the “Child Protection Inquiry” attribute set); Attribute, for the individual attribute (e.g.
LocalAuthorityCV); and AttributeSetToAttribute (as the link between them).
AttributeSetToAttribute allows attributes to be given a defined order within an attribute set
through the attribute AttributeOrder. The IsCurrent attribute is a flag that allows an extension
attribute to be deprecated within a particular attribute set (though not perhaps within any
other sets in which it may also occur). As with its CV equivalents (see section 3.2 above),
the flag is included for informational purposes only. Where an Attribute draws on a CV for its
permitted range of values, the CVID for the Controlled Vocabulary is held in the attribute
AttributeCVID. For other Attributes, the value is held as a string type, regardless of its actual
type (which might be e.g. a date or an integer). The entity AttributeType allows the actual
data type to be identified through the CV attribute ExtensionDataTypeCV. The attribute
IsMultiValue is a flag which indicates whether an Attribute may admit of more than one value
for a given Process, Event or Status Episode (as when more than one Concern Factor might
apply to a given “Sharing a Concern”).
All of this definitional apparatus is comparable to the definitional entities (FormType,
FormVersion, Question, etc.) in the “forms” part of the Data Model (see section 8 below).
The ExtensionTable entity provides the counterpart to the Response to a Question within the
Forms structure – it holds the specific information for a particular case. An ExtensionSet for
a given Process, Event or Status Episode will have as many ExtensionTable entries as there
are Attributes in the AttributeSet for the Process Type, Event Type or Status Episode Type to
which it belongs (or potentially more if an Attribute is multi-answer). Both the ExtensionSetID
and the AttributeID are held as foreign keys on ExtensionTable; and because the relevant
AttributeSetID is held as a foreign key on ExtensionSet, the order of Attributes within a given
AttributeSet can be expressed in the ExtensionTable. Where an Attribute relates to a
Controlled Vocabulary, the relevant value is held in the attribute AttributeCV. Where the
Attribute takes a text string as its value, this is held in AttributeValue. If the Attribute were to
take another sort of value (e.g. an image), this would be held in AttributeBLOB. Finally,
where an Attribute assumes more than one value for a given case, the attribute Occurrence
is incremented for each new value.
6.5
A shared overview of case-related activity
It can be seen that the MAS data model is able to sustain a shared overview of agency and
non-agency activity relating to a Subject of mutual concern. This overview can be inspected
(through an agency application) in a chronological dimension. A simple chronological list can
be displayed of all Events, Processes, Process Notes and Status Episodes relating to a
Subject, with the capacity to drill down further into the detail. Alternatively, the list can be
filtered by the agency application in a variety of locally-determined ways.
But there may be a need to establish a slightly more structured network of relationships
between the items on the list, especially where a number of different strands of service
activity are happening simultaneously (perhaps in different agencies) for the same person.
The attribute InitiatingReference has been included on the Process, Event and Status
Episode entities as a simple means of distinguishing a connected sequence or chain of
dynamic entities from other such entities for the same Subject which may overlap in time but
are operationally unconnected. If some agency reference is applied to the first entity in the
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 71
Transformational Technologies Division
chain (e.g. to a referral or to a life event which initiates a succession of service processes), it
can then be applied to all the subsequent processes, events and status episodes which flow
from this initial entity.
The dynamic entities (Process, Event and Status Episode) can also be related to persons of
different sorts – to Subjects, to Professionals and to persons who are neither of these. It will
thus be possible for an agency application to display a summary chart of a Subject’s recent
(or earlier) history, including both the nexus of interconnected activities relating to the
Subject, and the nexus of people involved in those activities.
The focus of information sharing may often rest rather more in the detailed information
carried in the Forms that are attached to Processes than in the broader interconnection of
Events, Processes and Status Episodes. But sometimes there may be an interest and
purpose to information sharing that lies less in the fine detail and more in a shared summary
overview of the service journey along which a Subject has come, and the Professionals and
other Persons who have contributed to that journey. Where this is the case, it may not even
prove necessary to share the information details contained in the Forms themselves,
especially for Processes that belong to an earlier stage in the journey. The data model lends
itself to either sort of purpose.
From a purely modelling perspective, it would have been possible to introduce a somewhat
more complex Process structure into the MAS through the use of various link entities. For
example, a hierarchical relationship could have been established between one or more subprocesses (e.g. a core assessment and a specialist medical assessment) and some larger
process (e.g. a comprehensive needs assessment) of which they formed part (and which
could, in turn, have been identified as a sub-process within some even larger process). Each
of these hierarchical elements could have had its own separate start and end dates, status,
relationship to professionals, and so forth. Alternatively or as well, a “chaining” link entity
would have allowed some amplification of the functionality offered by the InitiatingReference
attribute, depicting more specifically the way that many earlier processes can jointly feed into
one later process (e.g. many Referrals into a single Assessment) or one earlier process into
many later processes (e.g. one Referral into many Assessments). The relationship between
Processes and Events could have been depicted in a comparable level of detail.
While this more complex approach may seem initially attractive, pragmatic considerations
point in the direction of greater simplicity. Information sharing will not work in practice if it is
made too difficult for an agency to identify, view and update a MAS Process which has been
created by a partner agency. It will be a sufficient challenge to establish a viable shared
relationship of partner agency systems to individual Processes and Events, let alone to a
more complex pattern of interrelationship between them. It should be noted also that the role
of the MAS is simply to record Processes, not in any way to control or enforce them. As
there is no clear business requirement (at an eCare or “information sharing” level rather than
a single agency level) for any functionality beyond what is provided by the InitiatingReference
attribute, it seems a prudent and workable compromise.
6.6
Local identifiers for dynamic entities
The general role of local identifiers was described in section 3.8 above. Within the “dynamic
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 72
Transformational Technologies Division
entities” data area, the following entities have local identifiers:
 Event
 PersonToProcessHistory
 StatusEpisode
As explained earlier, this means that neither an event nor a status episode can be updated
by an interface system other than the one that stored the event or status episode in the first
place. This would not normally be a requirement.
The situation with processes is rather different. By its nature, an inter-agency process
involves the active engagement of more than one agency, so there may quite frequently be a
requirement for one agency to store a process and another to update it. Special provision is
made within the web services to enable this to happen.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 73
Transformational Technologies Division
7.
Children’s Services Phase 1
7.1
The scope of Children’s Services Phase 1 requirements
The data requirements of Children’s Services Phase 1 (CSP1) were formerly documented as
a separate data model. While the CSP1 requirements are now wholly met by the
consolidated Data Model, it may be helpful to retain some specific discussion of the
Children’s Services perspective.
Children’s Services Phase 1 represented a first extension of the existing eCare Data Models
to meet a number of specific Children’s Services requirements for information sharing that
were not initially met within the generic documents. The scope of the extension was
determined by two datasets drawn up for the eCare Programme by the Scottish Social Care
Data Standards Project – the eCart / MAS Children’s High-level (General) Assessment
Dataset [6] and the Integrated Children’s Service Record (ICSR) dataset [7]. These datasets
were grounded in the business requirements of several different strands within the Children’s
Services workstream of the MGF2 eCare Programme, including the Integrated Assessment
Framework for Children, the Integrated Children’s Service Record and the Children at Risk
project.
In the case of the High-level Assessment dataset, CSP1 encompasses the current dataset in
its entirety. In the case of the ICSR dataset, it provides a partial enablement only – sufficient
to allow the sharing of a child’s core demographic and situational details together with an
outline chronology of events. Some ICSR data topics (e.g. educational attainments) are
deferred until a later stage.
In structural terms, the existing eCare data models already provided most of what was
needed in order to meet CSP1 requirements, though the core MAS data model had to
undergo a few enhancements in order fully to meet the requirements of the eCart / MAS
Children’s High-level (General) Assessment Dataset. These enhancements were largely
introduced in a way that maintained the core model’s generic character. The main exception
is the SubjectAffectingDisability entity, which is specific to children.
In the case of the dynamic entities (Processes, Events and Status Episodes), a distinction
can be drawn between the logical data model itself and the extension attributes and
controlled vocabularies that are associated with the entities that figure in the model, but
which are not visible within the model’s outline structure. In its existing structure, the model
not only met the CSP1 requirements but had the potential to sustain a much wider sharing of
child-related events and processes than the two datasets require (see section 7.2 below).
Where CSP1 did produce a need for further elaboration was in regard to the extension
attributes for the various Process Types, Event Types and Status Episodes Types that are
implicit in the two children’s datasets, together with the many CVs that relate to these
extension attributes.
In particular, CSP1 has introduced extension attributes (see section 12.4.2 within the Data
Dictionary) and Controlled Vocabularies (see section 13) for the following Process Types
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 74
Transformational Technologies Division
(slightly revised from earlier drafts):
 Making an Inter-Agency Referral / Request for Assistance
 Children’s Assessment and / or Care or Service Planning
 Child Protection Investigation [see Postscript below]
 Child Protection Inquiry [see Postscript below]
The Event Types also covered are:
 Expression of concern
 Home visit
 Establishment visit
 Children’s Hearing
 A & E attendance
The Status Episode Types covered are:
 Legal status
 Developmental or medical status [but see Postscript below]
 Educational attendance
 Child protection registration
 Looked after or accommodated episode
The remainder of this section offers a topic by topic explanation of the way in which the two
SCDS2 children’s datasets are reflected within the eCare data model. This detailed
explanation is necessary because there is not an exact one-to-one correspondence between
the SCDS2 data items and specific features of the model – many data items are handled
through generic features. The explanation is further supplemented by the table included as
part of the Data Dictionary in section 12.4.3.
Postscript (Version 1.2, November 2006). A number of changes have made to children’s
data in Version 1.2, but as the general position on children’s data is still fluid, it has seemed
best to defer a more comprehensive revision of sections 7.1 and 7.2. In summary, the
introduction of Child Protection Messaging (see section 11 below) has had an impact on
those existing children’s data topics that pertain to child protection, while other amendments
are aimed at the partial correction of a long-standing failure of alignment between the MAS
and current children’s data standards in relation to the ICSR. Due to the exigencies of web
services development, the expression of ICSR data items in previous versions of this
document had to be based on a draft version of the ICSR dataset. A number of significant
changes were made in the final version of that dataset which have never been reflected in
the MAS.
The Children’s datasets (including associated CV values) are likely to change further in the
course of the implementation of Getting It Right For Every Child. Partly because of the
volatility of the data item definitions and partly because there is no particular reason to share
all of the ICSR data topics as structured data, the decision has now been taken to handle
certain ICSR topics through the medium of a Form. These include a few topics that had been
included in earlier versions of the MAS as well as other topics whose inclusion had been
deferred.
Amendments in the remainder of this section therefore encompass (1) the changes required
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 75
Transformational Technologies Division
for purposes of Child Protection (in particular, the replacement of the previous “Investigation
or enquiry (Child protection)” Process Type by two separate Process Types for “Child
Protection Investigation” and “Child Protection Inquiry”), (2) deprecation of extension
attributes and associated CVs that relate to ICSR data topics that will now be handled
through a Form and (3) a few other changes to extension attributes and CV values whose
definitions seem relatively stable.
7.2
The two SCDS2 Children’s datasets
As already noted, the purpose of CSP1 was to facilitate the sharing of a number of defined
data items which were drawn from two different SCDS2 datasets, the Children’s High-level
(General) Assessment Dataset [6] and a first tranche of the dataset for the Integrated
Children’s Services Record [7]. While the data model provides everything that is needed for
this purpose, there is not an exact correspondence with the datasets at a specific data item
level. For this reason, it may be helpful to relate the two datasets topic by topic to the data
model.
Before turning to the detail, it is important to stress that the Data Model should be seen as an
enabling framework for sharing certain sorts of information about a child, when (and only
when) an appropriate reason exists to share that information. It is not the expression of a set
of data items that are to be shared about every child (e.g. whenever any child happens to be
admitted to an A & E Department). Even when a child is the proper subject of information
sharing between eCare partners, and a certain data item does happen to apply to that child,
it does not follow that that data item should automatically be shared. There must always be a
good (and legally sustainable) reason for the agency in initial possession of the piece of
information to share that particular data item with its partner agencies in those particular
circumstances.
It is also important to note, however, that the sharing capacity of the eCare Data Model is not
restricted to the specific data topics listed in the two SCDS2 datasets discussed in this
section. In particular, the Data Model enables any sort of event to be shared as a MAS Event
(i.e. any significant event occurring in a child’s life or in his or her service history) if it is an
appropriate candidate for inclusion in a shared chronology. For example, the birth of a sibling
or the death of a grandparent could be shared as an Event, the Event Type being “Life
event”. Likewise, information can be shared about any sort of service Process or Status
Episode, so long as the relevant Process Type or Status Episode Type is a recognised CV
value. In this sense the Data Model possesses the potential to extend the scope of children’s
data sharing well beyond the datasets.
The Children’s High-level (General) Assessment Dataset covers the following data topics:
 Social Work Legal Status (Children’s)
 Current Child Protection Registration
 Child Protection History
 Child potentially at risk from a specific individual
 Child affected by disability
 Education establishment details
 Children Reporter’s Administration involvement
 Concerns expressed about a child
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 76
Transformational Technologies Division

Looked After or Accommodated episodes
Whereas the first dataset is completely captured in the Data Model, some of the topics in the
ICSR dataset are deferred until a later phase of development. Deferred topics are included in
square brackets in the following list. The unbracketed topics are all handled in CSP1.
 [Educational attainment (Student assessment age 5-14)]
 [Educational attainment (Student assessment age 14+)]
 Student stage
 Difficulty in learning [but see Postscript below]
 [Attendance (i.e. attendance pattern, not enrolment) at an educational establishment]
 Request for assistance / referral
 Current and previous assessment details
 Record of home visits by professionals
 Record of appointments and visits to establishments by the child and / or their carers
 Asthma [but see Postscript below]
 Known allergies [but see Postscript below]
 Paediatric diabetes [but see Postscript below]
 Other significant health conditions [but see Postscript below]
 Mobility [but see Postscript below]
 Personal care [but see Postscript below]
 [Behaviour]
 [Medication flag]
 [Children’s Immunisations]
For the most part, the following discussion uses the topic headings in the SCDS2
documents, though “Student stage” in the second dataset is bundled together with
“Education establishment details” in the first, while seven other ICSR topics (“Difficulty in
learning”, “Asthma”, “Known allergies”, “Paediatric diabetes”, “Other significant health
condition”, “Mobility” and “Personal care”) are all discussed together. There is also a
separate discussion of Warning Flags in section 3.6.3 above (which encompasses the data
topic “Child potentially at risk from a specific individual”).
Note that whenever the discussion refers to an extension attribute or to a Controlled
Vocabulary for an extension attribute, further details can be found in section 12.4.2 or
section 13.1 respectively. Section 13.1 lists all the currently valid values for the extension
CVs (though in some cases further values may be added at a later stage).
Postscript (Version 1.2, November 2006). As noted in the Postscript to section 7.1 above,
many ICSR data topics (including those bracketed in the above list) will now be shared
through the medium of a Form (or Forms). Five ICSR data topics will continue to be handled
as structured data. These are:
 Student stage
 Request for assistance / referral
 Current and previous assessment details
 Record of home visits by professionals
 Record of appointments and visits to establishments by the child and / or their carers
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 77
Transformational Technologies Division
7.3
The Children’s High-level (General) Assessment Dataset
7.3.1 Social Work Legal Status (Children’s)
Within this data topic, the data items required are the child’s “legal status”, the start date and
end date for this status and the date on which an Order is due to be reviewed. The “legal
status” in this context is the statutory basis for providing Social Work services to a child / and
or their family. In this sense, more than one “legal status” can sometimes apply at a given
time.
This data topic is handled through the “Legal Status” Status Episode Type. The start and end
dates are the start and end dates for the Status Episode. Two extension attributes are so far
defined for this Status Episode Type: ChildSocialWorkStatusCV (which relates to the
Controlled Vocabulary CVChildSocialWorkStatus) and ReviewDate. In due course, further
extension attributes may be added to this Status Episode Type for Community Care
purposes.
7.3.2 Current Child Protection Registration and Child Protection History
These two data topics can be discussed together. For a current Child Protection Registration,
the associated data items are the registration category and the start date. The Child
Protection History encompasses previous Child Protection Inquiries and Investigations,
previous Child Protection Registrations, the start date for any current Inquiry or Investigation
and details of any previous attendances at Accident and Emergency Departments. Specific
data items required include:
 the local authority involved in previous Registrations, Inquiries and Investigations;
 start and end dates for Registrations, Inquiries and Investigations;
 the agencies consulted by Social Work in the course of an Inquiry and the names of
the professionals who were consulted;
 the name of the child’s “named person” and whether this professional was consulted
in the course of an Inquiry;
 whether an Investigation was carried out by Social Work and the Police jointly or
solely by Social Work;
 whether a Child Protection Strategy meeting was held in the course of an
Investigation and the date and time of any meeting;
 the outcome of previous child protection Inquiries and Investigations and of Child
Protection Conferences when these were convened;
 the date of any A & E attendance together with the name of the hospital attended.
These data topics are handled through the Process Types “Child Protection Investigation”
and “Child Protection Inquiry”, the Status Episode Type “Child protection registration” and the
Event Type “A & E attendance”. The generic Process and Status Episode entities come
equipped with both start and end dates (ValidStart and ValidEnd in the case of Status
Episodes), while the Event entity has an Event Date (with which the date of an A & E
attendance can be equated). LocalAuthorityCV is no longer a standard attribute for a
Process, so is added as an extension attribute for the two “Child Protection” Process Types;
it is also added as an extension attribute for the Status Episode Type “Child protection
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 78
Transformational Technologies Division
registration”.
The Process Type “Child Protection Investigation” has five further extension attributes (in
addition to LocalAuthorityCV). CPInvestigatingAgencyCV distinguishes between joint
investigations by Social Work and Police and Police-only investigations.
CPStrategyMeetingCV indicates whether a Child Protection Strategy meeting has been held
and CPStrategyMeetingDate holds the date and time of any such meeting. The remaining
attributes are CPInvestigationOutcomeCV and CPConferenceOutcomeCV.
The Process Type “Child Protection Inquiry” has four further extension attributes (in addition
to LocalAuthorityCV). ConsultingAgencyCV records the other agencies consulted by Social
Work in the course of an Inquiry (in terms of the type of agency consulted – e.g. “Health”,
“Voluntary Sector” – rather than the particular agency). NamedPersonConsultedCV indicates
whether the “named person” was consulted. The remaining attributes are
CPInquiryOutcomeCV and CPConferenceOutcomeCV.
Within the Data Model, the link between a professional (or any other person) and a process
is expressed through the PersonToProcessHistory entity. The Controlled Vocabulary
CVProcessInvolvementType distinguishes between a person’s involvement as a Subject, as
a Professional and as an associated person. As already noted (see section 6.1 above), the
CV includes a “professional” sub-type for involvement as a “consulted” professional. This can
be used to identify the professional(s) within a given agency who were consulted in the
course of an Inquiry (and the details of their agency – as against the agency type – can be
derived from the Professional record). The identity of the particular Professional who is the
child’s “named person” rests with the relationship of the Professional to the Subject, not to
this particular Process – so that the role of “named person” must be recorded in the
ProfessionalRoleLCV attribute on the ProfessionalRoleHistory entity (see section 3.6.4
above).
In addition to LocalAuthorityCV, the Status Episode Type “Child protection registration” has
the extension attribute RegistrationCategoryCV. The Event Type “A & E attendance” has the
extension attribute InstitutionName, which provides for sharing the name of the hospital
whose A & E Department a child attended.
Note finally that it is possible to record a connection between a particular Child Protection
Investigation and a subsequent Registration (and indeed to encompass e.g. an A & E
admission as an earlier event within the same continuing chain of connected happenings)
through use of the InitiatingReference attribute (see section 0 above). This linking attribute is
common to Processes, Events and Status Episodes.
7.3.3 Child potentially at risk from a specific individual
The dataset requires an indicator “to alert those interrogating the system that a child has an
individual associated with them that poses, or may pose, a risk to the child”. This requirement
has been met through the introduction of the SubjectWarningFlag entity into the core MAS
data model. The entity serves a wider function, discussed in general terms in section 3.6.3
above and, with respect to its specific use for Child Protection Messages, in section 11
below.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 79
Transformational Technologies Division
7.3.4 Child affected by disability
There is a legal obligation under the Children (Scotland) Act 1995 to provide services to
children who are affected adversely by the disability of any other person in the family. The
entity SubjectAffecting Disability has been added to the data model for this purpose. The
entity allows the assignment to the (child) Subject of one or more of the relevant disability
categories, listed in CVAffectingDisability. Note that the sharing interest lies only in the
adverse affects of a current family disability – there is no requirement to maintain a history on
the MAS.
7.3.5 Education establishment details
This data topic requires the sharing of information about the present and past enrolments of
a child or young person in schools, colleges and other educational establishments, including
admission and end dates, the name and address of the establishment and the SE Education
Department reference number for the establishment. The data topic also encompasses the
Scottish Candidate Number for the Subject, this being a unique number assigned to each
pupil or student who passes through the Scottish examination system. For purposes of this
discussion, the data topic is taken in conjunction with the “Student stage” data topic from the
ICSR dataset (see section 7.4.1 below), which pertains to the stage the Subject has currently
reached (e.g. Primary 7) within their educational journey.
The data topic falls into three parts. First, the Scottish Candidate Number is properly
regarded as an attribute of the Subject, not of the Subject’s particular enrolment within a
given school or college. It has occasioned an enhancement to the core MAS Data Model,
through the introduction of a PersonReference entity which now hangs off the Person entity.
This entity was discussed in section 3.6.1 above.
Secondly, an educational establishment is treated within the data model as a type of
Organisation. The Organisation entity already includes an OrganisationName attribute and is
linked to Address. The dataset requires a classification of educational establishments as
Primary, Secondary, SEN, etc. This requirement has been met by adding the attribute
OrganisationTypeCV to Organisation (see section 3.7 above). The new CV includes the six
values required for the Children’s dataset as well as a number of other common types of
“organisation” (e.g. Hospital, GP Practice).
An associated enhancement to the core model is the introduction of the entity
OrganisationReference, which is intended to play the same role in relation to “organisations”
that PersonReference plays in relation to persons. In the present context, it will
accommodate an educational establishment’s SE Education Department Reference Number.
It will also provide for the holding of other “organisational” identifiers, such as a GP Practice
Number or a Hospital’s ISD Location Code.
Thirdly, a Subject’s past or present enrolment in an educational establishment is handled
through the Status Episode Type “Educational attendance”. A Status Episode of this Type is
held in MAS for each “student stage” within a period of enrolment at a school or other
educational establishment. The student stage is identified through the extension attribute
StudentStageCV. Note that that there has been a change from earlier Versions of the Data
Model, in which there was just a single StatusEpisode entry for each continuous period of
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 80
Transformational Technologies Division
enrolment at the same school or other establishment (potentially covering several “student
stages”). This reflects an extension of the “student stage” ICSR requirement to cover
previous stages as well as the current stage (see section 7.4.1 below).
Following this change, the admission date now equates to the ValidStart date on the first
“Educational attendance” Status Episode for the educational establishment in question
(which represents the registration date for the first “student stage” undertaken at that
establishment). The leaving date equates to the ValidEnd date on the final “Educational
attendance” Status Episode for the establishment (which represents the end date for the final
“student stage”). The attribute OrganisationID relates the Status Episode to the Organisation
record for the educational establishment in which the Subject is or was enrolled, from which
the educational establishment name and address can be derived.
7.3.6 Children Reporter’s Administration involvement
This data topic covers the history of a child’s involvement with the Children’s Hearing system.
The data items required are both the decision and the date of the latest Hearing, the date of
the first Hearing involving the child, the date of the first Hearing within the child’s current
involvement within the system, the date of the next Hearing and the name of the Reporter.
Within the data model, this topic is handled through the Event Type “Children’s Hearing”. An
Event record can exist for a future event as well as a past event, so both past and future
Hearings can be accommodated. The Event Type has the extension attribute
HearingDecisionCV. The associated CV lists the possible Hearing decisions. On occasion,
more than one value may apply to the same Hearing. The Reporter is recorded as a
Professional, the link with the Event being made through the PersonToEvent link entity.
7.3.7 Concern(s) expressed about a child
This data topic may initially seem to overlap with the ICSR data topic “Request for assistance
/ Referral” (see section 7.4.3 below). Both make reference to the same list of Concern
Factors. A distinction can nevertheless be made between the “referral” situation, where a
professional requests assistance from another agency which may well have had no previous
involvement with the child in question, and the situation where a professional wishes to share
a concern about a child with colleagues in other agencies who are already working with the
child. The expression of concern about a child was formerly handled as a type of event, but
is now handled as a type of process (allowing greater scope for a two-way exchange of
information). It is discussed in this section. The ICSR data topic has always been handled as
a type of process, and is discussed later.
The data items required for the sharing of a concern about a child include the date the
concern was shared, the concern factor(s) to which reference is made, a concern
description, and the name and contact telephone number of the person who recorded the
concern.
This data topic is handled through the Process Type “Sharing a Concern”. Attributes of the
generic Process entity include the process start and end dates and the process description.
A Process is linked to one or more Persons (one of whom must be a Subject) through the
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 81
Transformational Technologies Division
PersonToProcessHistory entity. As well as a Subject, those Persons to whom a Process is
linked can include either or both of a Professional and an associated Person, the type of
involvement being indicated through the ProcessInvolvementTypeCV attribute. The Person
record for a Professional (or any other person) is in turn linked to Name and ContactDetail
entities which hold the name and telephone number for that Person.
The Process Type “Sharing a Concern” has the extension attribute ConcernFactorCV, which
is associated with the Controlled Vocabulary CVConcernFactor. This CV has the values
listed in the dataset (and also in the ICSR dataset). More than one Factor may apply in a
given case. As with any Process, the nature of the concern can be amplified through a
Process Note or a Form. The same media can be used to record feedback information from
other agencies against the same Process.
Note that although the values in CVConcernFactor are mainly applicable to children, the
Process Type “Sharing a Concern” can be used in connection with community care clients as
well as children.
7.3.8 Looked After or Accommodated Episodes
The data items required for this data topic are simply the start and end dates and the local
authority. The data topic is handled through the Status Episode Type “Looked after or
accommodated episode”. This Status Episode Type is given the extension attributes
LocalAuthorityCV and LookedAfterTypeCV (which distinguishes between being “looked after
and accommodated” and being “looked after at home”).
7.4
The Integrated Children’s Service Record Dataset
7.4.1 Student stage
This data topic encompasses the stages in a child’s or young person’s educational journey
(e.g. Primary 7). The requirement was formerly restricted to the current student stage, but
now extends to previous stages as well. The data items required are the student stage, the
registration date for that stage and the end date. The data topic has already been discussed
alongside “Education establishment details” under 7.3.5 above.
7.4.2 Difficulty in learning
This data topic is no longer (Version 1.2) handled as structured data.
7.4.3 Request for assistance / referral
The “Expression of concern” data topic was discussed in section 7.3.7 above. The present
data topic relates to a request for assistance made by a person or agency seeking help for a
child. The data items required include the specific concern factors and an overall concern
description, the dates the request was sent and received, the names of the person
requesting assistance and the person receiving the request, the agencies requesting and
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 82
Transformational Technologies Division
receiving the request, the reason for the request, the action taken, whether the case has
been allocated, to whom the case was allocated and the date the case was allocated.
A request for assistance equates in effect to a Children’s referral. It is handled within the data
model through the Process Type “Making an Inter-Agency Referral / Request for Assistance”.
The concern description is held in the generic ProcessDescription attribute. The date the
request was made is the Process Start Date. The date the request was received is recorded
in the extension attribute ReferralReceivedDate (not the Process End Date, because the
whole referral process may sometimes continue on beyond the first receipt of the referral).
Within the Data Model, the link between a professional (or any other person) and a process
is expressed through the PersonToProcessHistory entity. The Controlled Vocabulary
CVProcessInvolvementType distinguishes between a person’s involvement as a Subject, as
a Professional and as an associated person. As already noted (see section 6.1 above), it
includes “professional” sub-types for involvement as a referring / requesting professional (the
initiator of the process) and involvement as a “receiving” professional. With the inclusion of
these values, the Professional entity enables a professional requesting assistance (and their
employing agency) to be identified, and likewise the professional receiving the request (and
their employing agency).
On occasion, however, the person requesting assistance may be an “associated person”
(e.g. a relative or neighbour) rather than a professional. The PersonToProcessHistory entity
will still serve to identify this person (who must have a Person entry in the MAS). Note that
because matching is not required for associated persons, there may sometimes be duplicate
records for a single associated person.
The Process Type “Making an Inter-Agency Referral / Request for Assistance” has further
extension attributes in addition to ReferralReceivedDate, of which two are particularly
relevant to the current data topic: ConcernFactorCV, already discussed in section 7.3.7
above, and Reason. (The remaining extension attributes for this Process Type, which has a
more general use, are RequestedAgencyName, TargetDate and DateActioned.) The
ProcessNote entity hangs off Process and provides the most appropriate place to hold the
action taken in consequence of the request. There can be separate Notes if required, with a
separate Professional recorded against each.
As noted, the dataset also encompasses certain allocation details – whether the case has
been allocated by the “receiving” agency following the referral, to whom it has been allocated
and the allocation date. This is best seen as the creation of a relationship between an
allocated Professional and the Subject, rather than between a Professional and a specific
Process relating to the Subject (by contrast with the case of the persons making and
receiving the referral or request, where the relationship is indeed Process-specific). The core
element in the data model makes provision for linking a Subject to a Professional through the
PersonToProfessional entity, off which hangs the ProfessionalRoleHistory entity. The
ProfessionalRoleLCV attribute on this entity draws on the locally defined CV
LCVProfessionalRole. While the precise values in this LCV will be locally variable, they will
certainly sustain the identification of the allocated Professional for the Subject within the
“receiving” agency (e.g. the allocated Social Worker), as and when such a Professional is
allocated. The allocation date equates to the ValidStart date on the ProfessionalRoleHistory
record for the allocated Professional.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 83
Transformational Technologies Division
7.4.4 Current and previous assessment details
In principle, this data topic can encompass any “formal” assessment carried out in a single
agency or multi-agency environment. The associated data items include the assessment coordinator, any other participants, the start and end date (or target end date in the case of a
current assessment), the reason for the assessment, whether the assessment is multiagency or single agency, the type of assessment (i.e. whether an initial assessment, reassessment etc.), the reports available, the outcome, and the reason for non-completion
(when relevant).
This data topic is handled through the Process Type “Children’s Assessment and / or Care or
Service Planning”. The generic Process entity furnishes the start and end dates. The
PersonToProcessHistory entity allows identification of the assessment co-ordinator (with
Process Involvement Type = “Lead professional”) together with other participants in the
assessment. Seven extension attributes are defined for this Process Type. The
TargetEndDate attribute is self-explanatory. The remaining six attributes are all CV attributes.
They reflect the six outstanding data items listed in the previous paragraph.
7.4.5 Record of home visits by professionals
This data topic encompasses the recording of successful visits, planned future visits and
abortive visits to a child’s (or other person’s) home. Data items include the date and time of
the visit, the name and agency of the visiting professional(s), the recipient(s) of the visit, the
nature (or type) of the visit, whether an appointment was made, whether the intended person
was seen, whether the child (or other Subject, in the case of a Community Care visit) was
seen, and any service provided in the course of the visit. In the case of an abortive visit, the
reason for this is also included.
The data topic is handled through the Event Type “Home visit”, which (as already implied) is
available for Community Care use as well as Children’s Services use. Both the professionals
and the recipients can be captured through the link entity PersonToEvent (which allows for a
distinction between involvement as a Professional, a Subject or an associated person), while
a professional’s agency is recorded on the Professional entity.
The Event Type “Home visit” has six extension attributes, three (AppointmentMade,
SubjectSeen and IntendedPersonSeen) being Boolean attributes, two (VisitTypeCV and
HomeVisitAbortedCV) being CV attributes and one (ServiceProvided) being a textual
attribute.
7.4.6 Record of appointments and visits to establishments
This data topic encompasses appointments at and visits to establishments by children and /
or their carers (and can again be extended for use in a Community Care context). Data items
include the date and time of the appointment or visit, the name and address of the
establishment, the recipient(s) of the appointment / person visiting, the reason for the
appointment or visit, whether an appointment was made, whether a visit was planned or
unplanned, the professional(s) who saw the visitor(s), and the date of the next appointment.
In the case of an aborted appointment, the reason for this is also included.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 84
Transformational Technologies Division
The data topic is handled through the Event Type “Establishment visit”. Both the
professionals and the visitors / appointment recipients can be captured through the link entity
PersonToEvent, while a professional’s agency is recorded on the Professional entity.
The Event Type “Establishment visit” has eight extension attributes. Of these, one
(AppointmentMade) is a Boolean attribute, two (PlannedVisitCV and AppointmentAbortedCV)
are CV attributes and one (NextAppointmentDate) is a date. The remainder are textual
attributes. AppointmentReason records the reason for the appointment or visit.
InstitutionName allows the name and address of the establishment to be recorded.
ProfessionalName is for use when an appointment is with an occasionally visited specialist or
other professional for whom no Professional record exists on the MAS. VisitorSeen can be
used to clarify just which visitor(s) was seen.
7.4.7 Developmental factors and significant health conditions
These data topics are no longer (Version 1.2) handled as structured data.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 85
Transformational Technologies Division
8.
Forms
8.1
The handling of Forms within the MAS Data Model
Earlier sections have described three elements within the overall MAS Data Model: (1) the
core MAS entities which are fundamental to information sharing, (2) the entities pertinent to
authorised disclosure and (3) the dynamic or changing entities which capture the service
activity from which forms generally emerge. The fourth element to be described is the “forms”
element itself. This offers a locally configurable question and answer format for the definition
and capture of shareable information when there is no requirement to hold this information in
a fully structured way.
In many social care contexts (e.g. Single Shared Assessment) there are significant local
variations in the precise way that information is captured, even though the scope and
purpose of the captured information are broadly the same in every locality. In some cases
(e.g. variations in the way that core personal information is recorded) there may be good
reason to override the local variations through the adoption of national data standards.
Where national data standards have been adopted, the MAS data model will reflect these
through the structured medium of defined entities and attributes. For other sorts of
information, however, there is no requirement to impose this degree of standard structure,
although some consistency of approach is still needed for a national MAS. The “forms”
element within the Data Model will then provide the necessary mix of outline structure and
detailed flexibility to handle local variations in information capture in at least a semistructured way.
Forms are generated in the course of some kind of process (e.g. an initial referral, a needs
assessment or the formulation of a care plan). The MAS data model distinguishes the “form”
(or repository of information) from the assessment or other process to which it relates. One
advantage of this is that a given process may give rise to the completion either of a single
form or of several forms. This feature again accommodates actual differences of procedure
across different local agencies.
Each Form (i.e. completed or partly completed form for a given person) comprises a series of
predefined (and locally determined) questions and the associated answers for this particular
case. The further details are described in section 8.3 below. As there are no constraints
within the database regarding the questions asked, the introduction of new questions into a
form will never require changes to the database structure. The overall structure provides a
design that caters for multiple assessment form formats and for other sorts of shareable form
as well. The “forms” component of the Data Model will always be the same, furthermore,
whatever the type of process to which the form attaches.
8.2
Recent evolution of the Forms component
With the two exceptions noted below, recent releases of the Data Model have not amended
the fine detail of its “forms” component, but they have introduced two changes at a higher
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 86
Transformational Technologies Division
level. In early releases of the Data Model, a form could only be related to a single process.
The subsequent insertion of a ProcessToForm link entity enables a form to be related to
more than one process. A care plan, for example, which might well be created in one
process, updated in a second process, and be a read-only input to a succession of later
processes, can now be related to each of these processes. The ProcessToFormCV attribute
on the link entity allows the type of relationship to be identified for the process in question.
Whether within the same process or in different processes, it may be a requirement for a
professional in one agency to add further data to a form that was initially published to the
MAS by another agency system (e.g. to fill in a more specialist section in a Single Shared
Assessment form). This raises two technical issues. The first relates to form locking, as a
means of avoiding update contention. Provision for this was already made through the
FormLockingHistory record (see section 8.4.10 below). But as well as this, a strong practical
argument has emerged for preserving the previous “states” of a form within the MAS through
use of a separate subordinate entity, so that existing form detail is not simply overwritten.
This is achieved through the new FormState entity, which sits between the Form and the
form detail entities. From the end user’s perspective, this new entity is invisible. It appears to
the end user that an existing form is extracted from the MAS, updated in the end user’s
system, and returned to the MAS with amended data. In fact, no update occurs in the MAS to
the Form entity itself; instead, a new FormState instance is added to those already stored in
the MAS. As before, the Form remains locked until the editing process is completed.
The new FormState entity is further described in section 8.4.2 below.
The first “fine detail” exception noted earlier is the addition (in Version 1.1 of this document)
of a QuestionDataTypeCV attribute to the Question entity. This helps to describe the
response value expected by a Form Question (when it does not expect a CV value), and is
relevant to the display of the value in an end user application. The new attribute is further
described in section 8.4.5 below. The second exception is the addition (in Version 1.3) of a
FormTypeCode attribute to the FormType entity and a Version attribute to the FormVersion
entity. These provide a “public” means of identifying Form Types and Form Versions. The
new attributes are discussed in section 8.4.1.
8.3
Logical Data Model for Forms
The following diagram shows the logical view of the data model for Forms. As in other
cases, the diagram omits the two auditing attributes (AuditLogID and ModifiedDate) that are
common to every entity. It also omits some of the relationships between CVValue and other
entities. Note (Version 1.4 of this document) that although transferred to the Hub (see
section 2.3 above), the InterfaceSystem entity is retained in the diagram because of its
continuing logical relevance to other entities.
The Data Dictionary for this part of the data model can be found in section 12.5.
Note that the left hand side of the model is definitional for a MAS implementation as a whole
– i.e. binding on all partnership agency systems that relate to that MAS implementation; the
right hand side (enclosed in a box) contains those entities that may be specific to an agency
system. With the exception of CalculationProcedure, these are presentational. For further
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 87
Transformational Technologies Division
explanation of this distinction, see sections 8.4.1, 8.4.6 and 8.4.9 below.
FormLockingHistory
InterfaceSystem
FormType
HistoryID
InterfaceSystemID
FormVersion
FormID (FK)
InterfaceSystemID (FK)
SystemReference
LockingStatusCV
ValidStart
ValidEnd
FormTypeID
SystemName
SystemDescription
FormVersionID
Name
Description
FormTypeCode
FormTypeStatusCV
Creator
DateCreated
Publisher
SubjectCategory
FormTypeID (FK)
Version
ValidStart
ValidEnd
Description
Section
SectionID
FormSectionID
Form
FormStateID (FK)
SectionID (FK)
Occurrence
FormState
FormID
FormStateID
FormVersionID (FK)
FormStatusLCV
FormStartDate
FormCompletionDate
SectionFormatID
SectionID (FK)
InterfaceSystemID (FK)
IsDefault
SectionHelpText
SectionFormatFlag
QuestionGrouping
SectionFormatID (FK)
FormatAttributeLCV
QuestionGroupingID
FormID (FK)
EditDate
EditSystemID (FK)
ContactProfessional
SectionID (FK)
QuestionGroupingOrder
QuestionGroupingText
IsMultipleGrouping
IsHeader
FormGrouping
FormGroupingID
FormSectionID (FK)
QuestionGroupingID (FK)
GroupingOccurrence
QuestionGroupingFormat
QuestionGroupingFormatID
QuestionGroupingID (FK)
InterfaceSystemID (FK)
IsDefault
QuestionGroupingHelpText
Question
ProcessToForm
QuestionID
ProcessID (FK)
FormID (FK)
Response
ProcessToFormCV
ResponseID
Process
QuestionID (FK)
FormGroupingID (FK)
ResponseCV
ResponseText
QuestionGroupingID (FK)
ValidationTypeID (FK)
CalculationID (FK)
ResponseCVID (FK)
QuestionDataTypeCV
QuestionSourceCV
QuestionCode
MandatoryAnswerCV
IsMultiAnswer
QuestionOrder
QuestionText
QuestionDescription
HeaderCV
ProcessID
ProcessTypeCV
ProcessDescription
ProcessStartDate
ProcessEndDate
InitiatingReference
ProcessStatusLCV
ExtensionSetID
Controlled Vocabularies
CVControlledVocabulary
CVID
CVName
CVCode
CVDescription
CVFlag
8.4
SectionFormat
FormVersionID (FK)
SectionNumber
SectionTitle
SectionDescription
IsMultipleSection
SectionTypeCV
FormSection
QuestionValidationType
ValidationTypeID
QuestionGroupingFormatFlag
QuestionGroupingFormatID (FK)
FormatAttributeLCV
QuestionFormat
QuestionFormatID
QuestionID (FK)
InterfaceSystemID (FK)
IsDefault
ControlTypeLCV
QuestionHelpText
CalculationID (FK)
Description
RegularExpression
ExceptionMessage
CVValue
QuestionController
CVValueID
QuestionControllerID
CVID (FK)
CVValueCode
CVValueText
CVValueOrder
CVValueFlag
ControllerTypeCV (FK)
ControllingQuestionID (FK)
DependentQuestionID (FK)
ResponseCV (FK)
CalculationID (FK)
QuestionFormatFlag
QuestionFormatID (FK)
FormatAttributeLCV
CalculationProcedure
Calculation
CalculationID
Description
CalculationProcedureID
CalculationID (FK)
InterfaceSystemID (FK)
IsDefault
Calculation
The Forms component entities
8.4.1 Forms, FormTypes and FormVersions
As already noted, each Form comprises a series of questions and the associated answers.
The Form entity captures the basic “header” information for the form – i.e. the type of form,
when it was started and completed and its current status (drawn from the values in a local
CV).
The definition of the Form (i.e. its structure and semantics) is represented through the
FormType entity, together with the subordinate entities (FormVersion, Section,
QuestionGrouping and Question) that relate to a FormType. A FormType may be any type of
form that is used nationally or locally for recording personal data (e.g. the Carenap Single
Shared Assessment Form, the SSA-IoRN Questionnaire or some local form that is specific to
a particular Data Sharing Partnership). The FormTypeStatusCV attribute is used to indicate
whether a FormType is “active” or “inactive” within a given MAS implementation (i.e. whether
it is in current use within the Data Sharing Partnership to which the MAS relates). The
FormTypeCode attribute has been added (in Version 1.3 of this document) as a “public”
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 88
Transformational Technologies Division
means of identifying a particular FormType (i.e. a standard way of referring to the FormType
which can be used by practitioners in the different partner agencies). In the first instance, the
Code must be unique within the Data Sharing Partnership with which the MAS is associated;
if and when Forms come to be shared across Partnership boundaries (which currently
equate to Health Board boundaries), the Code will have to be unique within the wider
“sharing domain”. The Name is the ordinary name generally used by practitioners for the
FormType (which, unlike the Code, may sometimes be ambiguous).
A generic form such as Carenap may go through a series of revisions in the course of its
lifetime. Each revision gives rise to a new FormVersion. For each FormType, only one
FormVersion will normally be current at any one time within a given agency setting. It was
initially envisaged that the ValidStart and ValidEnd dates would provide a sufficient basis for
establishing version control of the form definition without impacting on historic forms that
have been completed. But this rests on the unsafe assumption that partner agencies will
always synchronise their introduction of a new version of a Form Type. For this reason, a
Version attribute has now (Version 1.3 of this document) been added to FormVersion as a
safer means of identifying the Version. The Version will sometimes be a number, but it need
not be a number so long as it is unique within the Form Type.
Within a FormVersion, Questions are grouped into Sections and within Sections into
QuestionGroupings. For a given Form, the answer to a Question is captured in the Response
entity. The hierarchical structure of a FormVersion is reflected within a Form, so that
Responses are grouped into FormSections and FormGroupings. This allows a Section or
QuestionGrouping (and their constituent Questions) to have multiple occurrences in a Form
(so that the same set of details can be recorded for e.g. more than one child, carer, external
agency, current service, etc.)
While a single Form definition must apply across all agency systems that use a FormVersion,
the model allows for system-specific variations in visual presentation (through the
“formatting” entities described in section 8.4.6 below) and also in the procedures used for
calculation (see section 8.4.9). A new FormVersion arises whenever there is a change in a
definitional entity. It does not arise when a system-specific entity is changed.
8.4.2 FormStates
As earlier mentioned (see section 8.2 above), a FormState entity has been inserted between
the Form and FormSection entities. The effect of this is to preserve the state of the Form as it
was on its initial publication to the MAS, together with its subsequent state after any occasion
of later editing by a partner agency (though only the most recent state of the Form detail is
likely to be made available to partner agencies through web services).
The FormState entity itself holds details of the date of the particular editing in question and of
the agency system involved in the editing. It also identifies (through a textual field) a
professional who can be contacted in respect of that editing. While several professionals may
of course have contributed to a form prior to its initial publication to the MAS (or in the course
of its later editing by a partner agency), some lead or specialist professional within the
agency should have taken the decision to publish to the MAS (or to edit and republish the
form) and this professional would usually act as the contact person for other agencies in
respect of his or her agency’s input to the form.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 89
Transformational Technologies Division
It can be seen that where a Form goes through a succession of states on the MAS (i.e. is
edited after its initial publication to the MAS), the FormState entity provides a summary life
history of the Form from the perspective of the MAS itself. In principle, this means that the
source agency for any particular answer to a Form question could always be identified
(together with an accountable professional), thereby adding some sort of lower-level data
privacy safeguard to the higher-level safeguards described in section 4.
8.4.3 Sections and FormSections
A Section is a logical grouping of the questions within the Form. It may also possess
semantic significance (in that the meaning of a Question text may sometimes be contextually
dependent on the Section within which it falls). The IsMultipleSection attribute determines
whether a Section can have more than one occurrence (FormSection) within an instance of a
Form. The SectionTypeCV attribute distinguishes between Sections that record metadata
items and Sections that record form content data items (a distinction that may be relevant to
end user display). The SectionNumber attribute on Section determines the sequence of
Sections within a Form. The Occurrence attribute on FormSection defaults to 1, but is
incremented for each further occurrence of a repeatable Section within an instance of a
Form.
8.4.4 QuestionGroupings and FormGroupings
A QuestionGrouping is a subordinate grouping of questions within a Section. Like a Section,
it may possess logical or semantic significance. In formal terms, every Question must belong
to a QuestionGrouping, but very often there will be just a single Question in a
QuestionGrouping. QuestionGroupings mainly come into their own where several Questions
need to bound together into a connected grouping, although an empty QuestionGrouping
may also be introduced if there is a requirement for additional display text which cannot
otherwise be met.
More specifically, QuestionGroupings are useful in the following circumstances:
1. Like a Section, a QuestionGrouping – i.e. a set of logically connected Questions –
may be repeatable. An example might be a list of services, where each service has a
small number of standard attributes (e.g. provider name, service provided, contact
details). The IsMultipleGrouping attribute is used to indicate whether a
QuestionGrouping can have more than one occurrence (FormGrouping) within a
FormSection. Note that the Form definition does not mandate how an end user
application displays multiple occurrences. The end user application may display each
repetition either as a new column or as a new row within the form.
2. A common sub-heading may be required for a group of related Questions below the
Section level. The QuestionGroupingText attribute can be used for this purpose.
3. A Form may incorporate a grid or table, with both column and row headers. An
example might be a weekly diary, with days of the week across the top and times of
day down the side. In this case, a fixed number of QuestionGroupings would be
defined, with identical Questions in each QuestionGrouping. The
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 90
Transformational Technologies Division
QuestionGroupingText attributes would supply one set of headers, the QuestionText
attributes the other (the question text being suppressed in the second and
subsequent QuestionGroupings).
4. Two or more Questions may be connected logically or semantically, in the sense that
the meaning of a Question cannot properly be grasped except by reference to the
previous Question or Questions. An example might be a conditional Question (e.g. “If
Yes …, If No …”) which is treated as a single Question, or a Question which simply
says “Note” or “Comment”. Divorced from its predecessor Question, the Question’s
significance cannot be understood. In this sort of case, the Questions should be
bound together in a single QuestionGrouping.
5. An empty QuestionGrouping (or a string of empty QuestionGroupings if there is a
requirement for more than one paragraph) might be used to allow display of
additional standard text if, for example:
i. There is standard text at the start of a Section which applies to the Section as
a whole.
ii. There is standard text after the last Question in a Section.
iii. In relation to a QuestionGrouping that is not itself empty, there is a
requirement both to display a heading for the Question Grouping and to insert
some supplementary text between that heading and the Questions
themselves (in which case an empty QuestionGrouping containing the
heading would be followed by a non-empty QuestionGrouping, with the
supplementary text held in the latter’s QuestionGroupingText attribute).
The IsHeader attribute on QuestionGrouping indicates whether the (optional)
QuestionGroupingText is intended for display as a higher-level header or whether it simply
serves a documentary purpose. The QuestionGroupingOrder attribute on QuestionGrouping
determines the sequence of QuestionGroupings within a Section. The GroupingOccurrence
attribute on FormGrouping defaults to 1, but is incremented for each further occurrence of a
repeatable QuestionGrouping within a given FormSection.
8.4.5 Questions and Responses
If a Question draws its Response(s) from a set of predefined answers, these are defined
within a Controlled Vocabulary (identified through the attribute ResponseCVID). Alternatively
the expected answer can be free text (in which case ResponseCVID will have a null value).
In a given instance of a Form, a Response is linked to a Question through the QuestionID
attribute of the Response. The Response entity can either record a selected value in
ResponseCV (if the Question uses a controlled vocabulary) or a ResponseText (if no CV
applies). A single Question may have multiple Responses (provided that this capacity is
indicated through the IsMultiAnswer attribute). For example, a person might have more than
one functional impairment from a CV-specified list; or more than one referral reason might be
recorded.
When a Form is displayed in an end user application, there may sometimes be a display
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 91
Transformational Technologies Division
requirement which depends on knowing the expected data type of a textual Response – e.g.
to left-align numbers or to apply a particular currency format. The data type is now identified
through the QuestionDataTypeCV attribute. Note that this attribute is not currently used by
the eCare Framework for purposes of data validation. For free text Questions, it is possible to
specify a validation rule through the QuestionValidationType entity. This can be used, for
example, to validate responses against date, numeric or postcode formats. The
QuestionValidationType is associated with a Question through the ValidationTypeID attribute
of the Question entity.
The QuestionOrder attribute on Question determines the sequence of Questions within a
Question Grouping. The HeaderCV attribute determines whether the question text is to be
used as what is termed a “primary” header or a “secondary” header, or whether it is not to be
displayed at all. A choice between the first two options only arises when the Question
Grouping is repeatable. In this case, a “primary” Question text will occur only once (as a
header to the column / row of responses to that question), whereas a “secondary” Question
text will be repeated for each repetition of the Question Grouping. Where the Question
Grouping is non-repeatable, the Question text is either “primary” or not displayed. (Nondisplay may be employed in a variety of contexts – e.g. for address lines, where there is no
requirement for separate text for the second and subsequent lines, or, as described in
section 8.4.4 above, in the context of a table. Note that it is mandatory for each Question to
have a text, even if it is not displayed.)
QuestionCode is a “public” identifier for a Question which facilitates the electronic submission
of forms from agency systems, providing a point of reference for mapping data. The
QuestionCode must uniquely identify the Question within a FormVersion but can also be
used to track what is in effect the same question through successive Versions of a
FormType. The QuestionSourceCV attribute can be used to identify the source of a Question
(e.g. a national dataset such as the Care Assessment Data Summary, from which the
Question has been drawn). The MandatoryAnswerCV attribute is discussed in section 8.4.7
below.
8.4.6 Visual presentation
The same Form data might be displayed in different ways. Some aspects of visual display
have structural or semantic significance, and must therefore be kept consistent across
different agency systems that access the same Forms. Other visual aspects can vary without
changing the meaning of what is displayed – for example, whether text is displayed to the left
or the right of an input field, or an overall switch of tabular axes. For the latter aspects, the
data model allows for system variation through the SectionFormat, QuestionGroupingFormat
and QuestionFormat entities (and their associated “flag” entities). In each case, the relevant
agency system is identified through the InterfaceSystemID; the IsDefault attribute identifies a
default formatting for the MAS implementation where no System formatting is specified (so
that where IsDefault = 1, InterfaceSystemID must be null).
The IsRow attribute on QuestionGroupingFormat allows for an agency system-specific
choice of row or column as the primary basis of grid display. The ControlTypeLCV attribute of
QuestionFormat is used by the presentation layer to identify the input control to be used to
capture the response (for example, text box, drop down list, check boxes, etc.). Two further
presentational attributes (of QuestionFormat) determine whether a CV response label is
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 92
Transformational Technologies Division
placed to the left or to the right of the appropriate checkbox or button and whether CV
response options are laid out horizontally or vertically. Where an agency system supports
this, the DynamicDisplay attribute allows a Question to be tagged for dynamic display (see
below).
Note, however, that with the exception of ControlTypeLCV, these presentational attributes
are not shown specifically within the data model (although they are documented in section
13). For each of the three formatting entities, a further “flag” entity is introduced into the
model, each with an attribute FormatAttributeLCV. This attribute draws its values from the
Controlled Vocabulary LCVFormatAttribute. The attributes mentioned in the previous
paragraph are converted by the data model into values within this Controlled Vocabulary.
The introduction of the “flag” entities allows for the addition of further formatting attributes to
those mentioned above.
The three formatting entities also hold agency system-specific help text or other explanatory
material for a Section, QuestionGrouping or Question.
8.4.7 Mandatory questions
Within an eCare partnership, there may be a business requirement that a Question should be
mandatory (in the sense that it should always be answered). MAS cannot enforce this, but it
can express this expectation to associated applications through the MandatoryAnswerCV
attribute on Question. A Question may be always mandatory, or always non-mandatory;
alternatively it may be sometimes mandatory and sometimes optional, dependent on a
controlling condition. For example, a question might be mandatory if a person is employed,
but optional if a person is not employed. As discussed below, QuestionController provides
the dynamic switch for this.
8.4.8 Question flow control
The Forms Data Model allows the display of Questions to be dynamically determined, and
thus supports branching in the Question flow. Two features of the model are relevant to this:
the DynamicDisplay attribute on QuestionFormat and the QuestionController entity. The
DynamicDisplay attribute identifies a Question as one whose display is to be dynamically
determined, the default being non-display; the conditions for display in a given case are
established through the QuestionController entity. A similar mechanism allows dynamic
determination of whether a Question is mandatory (in association with the
MandatoryAnswerCV attribute on Question).
The QuestionController relates to a Controlling Question (which triggers the evaluation of a
condition affecting a later Question) and to a Dependent Question (which is the later
Question whose display or mandatory status is to be determined). The Dependent Question
is identified in the attribute DependentQuestionID. A single Controlling Question may effect
the switching on of two or more Dependent Questions, so long as a separate
QuestionController entry exists for each. Note, however, that to prevent ambiguity of
reference, use of the QuestionController entity is only permitted when neither of the
associated Questions (i.e. the Questions that its use would establish as either a Controlling
Question or a Dependent Question) falls within a “repeatable” Section or Question Grouping.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 93
Transformational Technologies Division
Subject to this constraint, Controlling and Dependent Questions can fall within different
Question Groupings or Sections.
A QuestionController entry will belong to one of three types (identified through
ControllerTypeCV), in that the entry may govern (1) only whether the Dependent Question is
displayed (rather than hidden), or (2) only whether it is mandatory (rather than optional), or
(3) both of these at once.
QuestionController can allow complex conditions to be established (so that the display of a
question may depend on e.g. the conjunction of a specified answer to one previous question
with a specified answer to a second previous question, or on conditions that are imported
into the Form). In these more complex cases, it will use a Calculation. But in the simpler (and
more common) cases, the condition consists in a specified CV response to the Controlling
Question alone, and no Calculation is used.
In a simple, “single condition” case, the condition that “switches on” display (and / or
mandatory status) of a Dependent Question is that the response to the Controlling Question
is the CV Value specified in the ResponseCV attribute (indicating e.g. that the subject has an
unmet need). The Dependent Question may or may not be the Question that immediately
follows the Controlling Question. In this simple case, CalculationID is null.
Where the determining condition is more complex, CalculationID has a value and
ResponseCV is null. In one type of more complex case, the dynamic attribute may be
“switched” on by the responses to two or more different Questions, or by the combination of
two responses to a single multi-answer Question. These more complex “in-Form” conditions
may include:

AND conditions (e.g. the subject is disabled AND the subject is employed)

OR conditions (e.g. the subject is retired OR the subject has a long-term illness)

NOT conditions

Combinations of these (e.g. the subject is employed OR (the subject is retired AND
the subject has been employed within the last two years)).
The mechanism can be further extended, however, so as to encompass a condition external
to the Form – for example, an entity’s having a specified attribute (e.g. the Subject of the
Form being male) or the existence of a specified entity (e.g. the Subject having a carer).
Use of a Calculation for evaluating complex conditions is discussed in the next sub-section.
8.4.9 Calculations
A Question may admit of a calculated Response. For example, the SSA-IoRN questionnaire
derives SSA-IoRN scores and an SSA-IoRN group from the previously input responses to
the 12 standard SSA-IoRN questions, by means of a standard calculation. The calculation
procedure for a Question may be specific to a system. Where a Question has a calculated
Response, the relevant Calculation is identified through the attribute CalculationID. The
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 94
Transformational Technologies Division
Calculation and the System together identify the CalculationProcedure that is to be used.
As already noted, the Calculation mechanism can also be used, in association with
QuestionController, to introduce procedures that evaluate compound in-Form conditions or
conditions external to the Form, with a view to routing the question flow or determining
whether a Dependent Question is mandatory. In this case, CalculationID is a foreign key on
QuestionController and a Boolean value is returned. (Note that this option will also extend to
procedures that evaluate textual Responses to Questions within the Form itself.)
Similarly, Validation rules can be encapsulated by a Calculation either in place of, or in
addition to a Regular Expression.
8.4.10 Form Locking History
In some joint working contexts, professionals in more than one agency may add data to the
same form. The data model provides a capacity to lock a form for editing, so as to avoid
simultaneous attempts at update by two different agency systems or professionals. Form
locking is effected through the FormLockingHistory entity. A LockingStatus Controlled
Vocabulary currently offers “Locked” and “Unlocked” statuses. The capacity will not be
enforced centrally, but where a MAS implementation uses locking, each Form should always
have a current FormLockingHistory record. Where the Form is locked, this will hold the
identifier for the Interface System through which form editing is being effected. It will also
hold a System Reference supplied by the Interface System, which may be used to identify
the particular user who is doing the editing. Historical records will hold a start date and an
end date. On the currently valid record, the end date will be set to a constant (which equates
to the database management system’s maximum date).
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 95
Transformational Technologies Division
9.
Security and Auditing Requirements
9.1
Background
A number of features need to be added to the eCare Multi-Agency Store Data Model in order
to give effect to eCare policy for Security and Auditing. General eCare Policy for Security is
described in the eCare Security Policy document [8]. Policy for Auditing is further amplified in
the eCare Data Policy Document [2].
The most relevant Security requirements for the Data Model are those that relate to the
authentication of Partner or Agency Systems having access to a Multi-Agency Store. It is
current eCare policy that all MAS data is, in principle, accessible to any System that has
access to the MAS implementation in question. In other words, if an Agency System (which
might be e.g. a Health System, a Social Work System, an Education System or a Police
System) is authenticated for access to the MAS, no further restriction is imposed (from within
the MAS itself) on data access in respect of e.g. geographical area, client group or the
service interest of the Agency in question. This policy is reflected in a relatively simple data
model design.
The MAS Auditing requirements will have an impact throughout the MAS Logical Data Model.
AuditLog and MessageLog entities are introduced into the model. The AuditLog entity has an
entry for each successful MAS update transaction, whether or not this is mediated through
the Messaging system. The MessageLog entity has an entry for each incoming or outgoing
message. In addition, two new attributes are added to all entities for which auditing is
required. Both the overall eCare Audit Framework and the more specific data model details
are discussed in section 9.3.
Postscript (Document Version 1.4, March 2008). As already mentioned in section 2.1
above, the Security features that were formerly part of the MAS Data Model have been
transferred to the Hub Data Model. In consequence, section 9.2 of this document has been
substantially abridged; while the Logical Data Model in section 9.4 is restricted to the
Auditing system. The main discussion of Security is now to be found in the Hub Data Model
document [11].
9.2
Security
9.2.1 System Authentication
In the MAS data model, each Partner or Agency System with rights of access to the MAS
has an InterfaceSystem entry, now (Version 1.4) held physically in the Hub (see section 3.1
above). Any other System that accesses the MAS (e.g. the eCare Matching Service) will also
have an entry. The route of access to a MAS is through the Hub. The arrangements for
System Authentication are described in the Hub Data Model document [11].
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 96
Transformational Technologies Division
9.2.2 Classification of Interface Systems
As already noted (section 9.1 above), current eCare policy makes no distinction between
Interface Systems so far as MAS access rights are concerned. MAS itself allows a System
with access to one sort of MAS data (e.g. Single Shared Assessment data) to have access to
all other sorts of MAS data (e.g. Children’s Services data) – though access restrictions might
of course be imposed outwith the eCare Framework. The policy means that there is no
current restriction within MAS itself on Interface System access by reference to such
potentially relevant factors as:

The category of System (e.g. NHS, Social Work, Housing, Education, Children’s
Reporters, Police, etc.);

The category of client (so that children’s data is available in principle to Community
Care systems, or adult data to Police systems);

Geographical area (so that where a Partnership covers several local authority areas –
or even more than one health board area – a local authority system would have
access to data for a Subject who lives in a different area);

The service team that has responsibility for a client;

Particular entities or attributes (so that child-specific entities or attributes are available
to adult systems and vice versa);

The source system for the data in question;

The type of access (i.e. update access, view only access, etc.).
Prior to Version 1.4 of this document, the logical data model allowed for a possible future
modification to the current “see one, see all” access policy through the introduction of an
InterfaceSystemFlag entity to hold System Attributes of various sorts. As this entity has never
been used, and as it is now anticipated that any future modification to the access policy will
be effected through a different mechanism, it has been omitted from the Security features
transferred to the Hub.
9.3
Auditing
9.3.1 The eCare Audit Framework
The eCare Data Policy Document [2] makes a number of stipulations in regard to Auditing, of
which the most relevant here are that an auditing solution for eCare must:

Be time and date stamped;

Independently record the operator identity and actions that create, modify or delete
all records within the data model. (Auditing of user view access to records is not
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 97
Transformational Technologies Division
considered to be a current requirement.)
The eCare Audit Framework encompasses both the Interface (or Agency) System from
which an update is initiated and the eCare Framework within which the MAS resides. The
following diagram offers an overall view of the Audit Framework. It assumes that an update
to the MAS is mediated through the Messaging system. Some slight modifications will be
needed to the diagram when the MAS is updated in some other way (see section 9.3.2
below).
Audit Framework Boundary
Interface System
Journaling
View auditing (users)
What user
Adaptor
eCare Framework
WS-Security ‘envelope’
MAS Messaging
MAS
Message Log ID (MAS)
Audit Log ID (MAS)
Interface System ID
Message ID (Interface System)
Audit Reference (Interface System)
MAS timestamp
Audit Data
Within the overall eCare Audit Framework, the feeder Partner or Agency System has
responsibility for journaling, for the identification of the particular end user who initiated an
update and for any view auditing that may be required. For the reasons explained below,
these are not functions that MAS itself can sustain.
All updates to MAS, however mediated, are logged in the Audit Log. In the standard case of
a MAS update that is mediated through the Messaging system, messages pass in both
directions between the Interface System and the eCare Framework. All messages into and
out of the eCare Framework are logged in the Message Log (including view requests and
any update messages that happen to fail). An incoming message must be assigned a
message ID (IncomingMessage ID) by the Interface System (which should be unique to that
System). When combined with the Interface System ID, this equates to the internal (MAS)
Message Log ID. The IncomingMessage ID is recorded in the MAS Message Log entry for
the incoming message; it is also recorded on the Message Log entry for an outgoing
response to that message, thus linking related messages together.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 98
Transformational Technologies Division
The Interface System may also supply an optional Audit Reference for an update (which
might, for example, be a User ID for the end user whose action initiated the update). Any
Audit Reference passed through by the Interface System is recorded on the MAS Audit Log.
Several Messaging scenarios are supported, including both “on demand” and “batch”
Messaging (which may be with or without adaptor caching). Because of this, neither the end
user who initiated the original update in the feeder system nor the time of the original update
are visible to MAS. But because the Interface System’s own incoming message ID and its
(optional) Audit Reference are recorded in the MAS (in the Message Log and Audit Log
respectively), it is possible to trace back the audit trail for a MAS update from MAS into the
Interface System.
Where Messaging is used, the sequence for an update Message is (1) insert MessageLog
entry, (2) insert AuditLog entry, (3) update MessageLog entry with AuditLogID, (4) update
the record or records for which the update request is issued. This sequence is illustrated in
the next diagram. If an update fails, any rollback can go all the way through to (2) (so that
the original Message Log entry remains but not the Audit Log entry).
Adaptor/Interface System
Messaging
Message Log
Data Access Layer
Audit Log
Request()
LogMessage()
Update()
LogAudit()
AuditLogID
Commit message
Response
LogMessage()
9.3.2 Updates not mediated through the Messaging system
The above description covers the case where a MAS update is mediated through the
Messaging system. In most MAS implementations, most MAS entities will be updated
through the regular transmission of operationally generated messages by a Partner or
Agency System. These will include all those entities that carry personal, case-specific or
user-alterable data (e.g. Person, Subject, Name, PersonToPerson, etc., but also
Professional, Organisation, etc.). But entities carrying what is basically reference data
(including e.g. the CV entities, the “definitional” entities for Forms, the “presentational”
entities for Forms, etc.) will be created, modified or deleted via a rather different route. The
mechanism for updating these “reference” entities may vary from one MAS implementation to
another. Sometimes a maintenance or batch application will effect the insertion or update,
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 99
Transformational Technologies Division
these updates still perhaps being mediated through the Messaging system. There may
however be other, non-Messaged ways of making “reference” insertions or updates,
including some form of direct intervention by a database administrator. Provision should also
be made within the data model for MAS implementations where even regular updates are not
effected through Messaging.
It seems important to establish as robust an audit trail for all these alternative cases as for
the standard case where a MAS entity is updated through a message from a feeder system.
The Audit Log entity provides a common basis for auditing, even where Messaging is not
employed. It will require each maintenance or updating application to have an entry in the
InterfaceSystem table. A database administrator who makes direct updates must also be
recorded as an Interface System. Their auditing will then be handled within the Data Model in
much the same way as the regular feeder systems which update through Messaging.
One point of difference, however, is that there will be no IncomingMessageID in such cases
(the message identifier normally supplied by the Interface System). For this reason, the
AuditReference (which is optionally supplied by the Interface System in a Messaging context)
will be the sole means of continuing the audit trail beyond the MAS boundary when
Messaging is not employed. It should therefore become a mandatory and user-identifying
item in this situation.
9.3.3 Impact on the MAS Data Model
In principle, there are at least three ways in which the MAS Data Model might provide the
basis for an audit trail:
1. By adding the requisite set of “auditing” attributes to each MAS entity that is liable to
auditing. At any given time, each row would hold “last update” auditing details only.
2. By creating an additional “auditing” entity for each MAS entity that is liable to auditing.
This would hold auditing details for each update, not simply for the last.
3. By creating a single Audit table to hold auditing data for every entity.
Option 3 would produce a huge and unmanageable entity and would almost certainly cause
locking and performance problems. While option 2 has some attractions, it is not clear that it
meets a practical requirement. It would still be necessary to resort to the MAS Transaction
Log to establish just how a row had been updated. Option 1 is therefore preferred.
At a logical level, two attributes need to be added to each of the entities that have to be
audited – AuditLogID, through which the relevant Interface System and the
IncomingMessageID and/or AuditReference can be identified, and ModifiedDate, which holds
the datetime for the database update. In a physical implementation, however, the
InterfaceSystemID, the Interface System’s own IncomingMessageID (if Messaging is
employed) and its (usually) optional AuditReference would be added to each entity as well, to
allow these to be written to the Transaction Log for the update in question.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 100
Transformational Technologies Division
9.4
Logical Data Model for Auditing
The Person entity is included in the following data model merely as an example of an entity
for which auditing attributes are required. Its last two attributes will be added to all such
entities. As just noted, a further three attributes would be added to each entity at a physical
level.
The Data Dictionary for this part of the data model can be found in section 12.6.
InterfaceSystem
AuditLog
InterfaceSystemID
AuditLogID
SystemName
SystemDescription
InterfaceSystemID (FK)
AuditReference
AuditTimestamp
MessageLog
MessageLogID
MessageSequence
InterfaceSystemID (FK)
IncomingMessageID
Message
MessageTypeCV (FK)
MessageTimestamp
AuditLogID (FK)
Person
PersonID
Controlled Vocabularies
CVControlledVocabulary
CVID
CVName
CVCode
CVDescription
CVFlag
BirthDate
BirthDateVerificationCV
DeathDate
DeathDateVerificationCV
GenderCurrentCV
EthnicGroupSelfAssignedCV
EthnicGroupSpecificCV
ReligionCV
CountryOfBirthCV
FirstLanguageCV
InterpretationAssistanceCV
AuditLogID (FK)
ModifiedDate
CVValue
CVValueID
CVID (FK)
CVValueCode
CVValueText
CVValueOrder
CVValueFlag
Postscript (Document Version 1.4, March 2008). As already explained in section 9.1
above, the data model, which formerly encompassed both Security and Auditing, is now
restricted to Auditing. Although transferred to the Hub, the InterfaceSystem entity is retained
in the diagram because of its continuing logical relevance to other entities.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 101
Transformational Technologies Division
10. eCare Notifications
10.1 Background
In order to meet the requirements of data sharing via the Multi-Agency Store (MAS), changes
to the MAS must be “notified” to participating agency systems. The use of the term
“notification” serves to differentiate this process from the physical receipt of data by the MAS
from source agency systems (described as “Messages”).
It should be noted that the notification cannot update local systems directly, since it will not
contain a copy of the changed data but simply an indication of what data has been changed
in the MAS. This provides local flexibility in what action to take (including none) following
notification.
The term “notification” also encompasses certain eCare notifications to agency systems that
are pertinent to the MAS but not reflective of changes within it (e.g. notification of a failure to
match).
Postscript (Document Version 1.4, March 2008). It has already been mentioned (in section
2.1 above) that eCare Notifications are now consolidated within the Hub. Nevertheless the
existing sections 10.2, 10.3, 10.4 and 10.5 seem sufficiently relevant to a general
understanding of data sharing through the eCare Framework to warrant retention within this
document. Because Matching and Indexing are themselves discussed in the Hub Data Model
document [11], the discussion of Matching Notifications has been transferred from section
10.6 to that document. The Logical Data Model for Notifications and the associated
discussion (section 10.7) have also been transferred.
10.2 Definition
An eCare notification is defined as a parcel of commonly-formatted data which informs one
or more external agency systems (or, potentially, different instances of the MAS) that there
has been some occurrence within or relating to the MAS.
For the reasons discussed in section 10.4.1 below, notifications should not be prioritised or
otherwise interpreted for significance by the MAS but merely presented to the relevant
agency systems for consideration. Agency systems may then need to process eCare
notifications in terms of their subsequent presentation to practitioners – i.e. to generate an
internal “practitioner message”. This processing task could include:

determining whether a practitioner message is required;

identifying the relevant practitioner(s) to receive the practitioner message;

the level of “granularity” of the practitioner message (i.e. how much detail to display
and how many notifications should be displayed at a time for any given subject).
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 102
Transformational Technologies Division
eCare Security Policy requires that eCare notifications are not physically distributed by the
MAS but are placed in an accessible store within the eCare Safe Haven, to be read by
external agency systems. As already noted, a MAS update notification record will not itself
contain the changed data.
The exact model used to store these data items is now (Version 1.4 of this document)
discussed in the Hub Data Model document [11].
10.3 Potential uses for notifications
Although the principal use of eCare notifications is to inform agency systems of changes to
the MAS, various other situations have been identified where agency systems may need to
be notified of events. Overall, the following types of communication have been considered as
potential candidates for eCare notification processing:
1. MAS Changes
2. Alerts
3. Matching
4. Inter-MAS communications
5. eCare service status
6. General inter-agency communications.
Of these, the first three (MAS Changes, Alerts and Matching) are key; the first two are
discussed in the remainder of this section, while discussion of the third has now (Version 1.4
of this document) been transferred to the Hub Data Model document [11]. The main focus is
on MAS Changes (or Updates) notifications. An important type of “practitioner” alert (namely,
an alert as to the existence of risk) is discussed briefly in section 10.5.1. It represents a
particular instance of notifications with specific data issues over and above those of
“ordinary” notifications. Some of these issues were discussed earlier in section 3.6.3. As will
be seen, these alerts are currently handled as a special class of MAS update notifications.
Discussion of inter-MAS communications is certainly pertinent to Notifications but is deferred
until a later stage. eCare service status and inter-agency (i.e. non-MAS related)
communications and messages are outwith the scope of the current document and are not
discussed further here (although they could potentially be covered by the same mechanism
and may therefore be included at a later date). There is, however, a “miscellaneous”
notification category. This currently encompasses three notification types that do not fall
under either of the general “update” or “matching” heads. All three types might broadly be
categorised as “alerts”, and they are described in section 10.5.2.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 103
Transformational Technologies Division
10.4 MAS Update Notifications
10.4.1 Principles governing update notifications
When the MAS is updated by an agency system, two general questions might arise. Is the
change of sufficient importance to warrant a notification to other agency systems? And if so,
which partner systems should be notified?
Lacking the context of a change, the MAS cannot know whether or not the change is
meaningful and therefore warrants a notification. For example, a change in an address field
may imply that the subject has moved from one address to another, or merely that an error
has been corrected, or that a postcode has been added to an otherwise correct address. All
these sorts of address changes look just the same to the MAS.
While the system generating the change may know more than the MAS about the nature of
the change being made, it does not know how the change might impact on another agency
system. It does not know, for example, whether another system is interested in the change
being made or indeed whether the change is a change at all with respect to the data held in
the other system. In some cases the MAS data prior to the change may not be the same as
the data held by the end point system that is receiving the notification; indeed, the change
may simply be bringing the MAS data into line with the data already held in the end point
system.
In the absence of any clear direction as to which changes should be notified, the safest
general answer to the first question is to notify relevant partner systems in the event of any
change to the MAS, leaving it to the partner system to gauge the significance of the change.
In regard to who should be notified, there are two options for how the notification might be
passed to other systems.
1. The originating system for the MAS update might include information about which
systems should receive the notification within the update message itself.
2. There might be a central notification process that forwards the notification to the
appropriate recipient systems.
The first option would require all partnership systems to be aware of the existence of all other
end point systems. This has disadvantages, including the fact that the addition of a new
system would require the reconfiguration of all other participating systems. In the case of a
central “hub”, only the “hub” needs to know about all the systems and only the “hub” would
have to be reconfigured in the case of an addition. For this reason the second option is
preferred.
The central notifications process clearly requires a rule about which systems receive which
notifications. In formulating a rule, two assumptions are made:

When a change to the MAS creates a requirement for an eCare notification, it can
always be attributed to a particular subject of data sharing (i.e. to a particular person
who has been “matched” and for whom a MAS index record has been created).
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 104
Transformational Technologies Division

As already implied, all changes to subject-related records within the MAS should give
rise to eCare notifications.
The only rule that properly reflects these assumptions is to notify partner systems of all
changes affecting MAS subjects who are known to them and in whom they can be presumed
to have an interest. This is indicated by the existence of a MAS index record for the subject
and the partner system in question.
10.4.2 Granularity of update notifications
The notification will contain information to enable the systems that receive the notification
(via the MAS) to decide what to do about the change that has been made. This presents
issues relating to the frequency and degree of granularity of the resulting notifications. At one
extreme, each MAS change could give rise to a separate notification (i.e. three fields updated
for a subject = three separate notification records, each specifically identifying the updated
field). At the other extreme, the notification system could “roll up” all changes for a single
subject over a certain period (e.g. daily) to produce a single (unspecified) change notification
per subject for each agency system. The Notification system cannot work at a lower level of
granularity than the MAS; but it could work at a higher level of granularity than the MAS.
In regard to granularity, the main options appear to be the four adumbrated below. These
options were presented to a Data Workshop for local eCare Partnerships on 4 November
2004, where a consensus emerged in favour of the third option.
1. Lowest level of granularity. At first glance, the most attractive and flexible option
might appear to be the generation of eCare notifications at the lowest level of update
granularity that the MAS can distinguish, any collation or interpretation being carried
out by the recipient agency system locally. This approach was initially adopted in
Lanarkshire, but was later discarded. The drawbacks included the sheer volume of
notifications that were generated and the associated difficulty of distinguishing the
wood from the trees.
2. Highest level of granularity. The other extreme would be to use the same eCare
notification in respect of every change to a subject’s record on the MAS. The
notification would indicate simply that there had been some change to the subject’s
MAS record, but would carry no further detail as to the nature of the change. The
drawback of this option is that it would require end-point systems to inspect the MAS
on each occasion in order to determine if the change was of interest. For this reason,
the option was also rejected.
3. Level of Web Service granularity. The remaining two options both pitch the level of
granularity somewhere between the first option and the second. The third option is to
create a notification at the level of the XML Web Service that processes the update to
the MAS. If, for instance, there were to be a distinct Web Service for updating
personal details or for creating a new assessment, this would be reflected in distinct
“Personal Details Update” and “New Assessment” eCare notifications. Because the
Web Services will be standard across different MAS implementations, the effect of
this option is to produce a standard set of MAS update notifications that are used in
every local eCare Partnership.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 105
Transformational Technologies Division
4. Notification determined by the source agency for the update. An alternative “midrange” possibility is for the eCare notification to be generated from within the agency
system that initiates the change to the MAS. This option might be effected through a
locally determined Controlled Vocabulary, with a range of values that reflected the
locally agreed business requirements for eCare notifications. These might well vary
from one eCare Partnership to another. In effect, the end user, when initiating a MAS
update, would also choose which notification (out of a locally agreed set) should be
sent on from the MAS to other agencies in respect of the update.
Participants in the Data Workshop agreed that although the third option ties the level of
granularity of eCare notifications to the level of granularity of the Web Services, with the
potential disadvantage that it may not always correspond to the intuitive notification
requirements in a local area, it nevertheless represents the best compromise available. The
fourth option, it was felt, would place too much reliance on the capacity of the end-point
systems and users to get things right. The responsibility must lie with the MAS itself for
ensuring that the appropriate partner systems receive the appropriate update notification.
At the time of this release of this document, the notification types distinguish updates as
follows:
 Subject
 Warning flag
 Consent
 Disclosure authority
 Event
 Status episode
 Process
 Form
10.4.3 Presentation of notifications
For reasons of volume and timing, it will be impractical for the MAS actively to control the
agency uptake of notifications, so agency systems will poll for notifications from a common
area. As already noted, there are also very strong security reasons for adopting this
approach.
Each update notification will be addressed to those agency systems for which an index entry
exists for the person who is the subject of the notification. For example, if Health updates a
MAS record for a subject who has been previously “matched” by Social Work and by
Housing but who has not been “matched” by Education (so that an index entry exists for the
first two agency systems but not for the third), Social Work and Housing will receive
notification of the change but Education will not be notified.
Once read and acknowledged, each notification for an agency should be logically (or
physically) “masked” to prevent that particular agency system re-reading it as a duplicate.
The notification is marked with the date of acknowledgement for the agency system
concerned to indicate that it should no longer be supplied to that particular agency system.
As already noted, agencies will only be able to read notifications relating to subjects for
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 106
Transformational Technologies Division
which they have previously had a successful match (i.e. in which they have an interest). Note
that an agency system can still receive notifications for a subject even if they do not have
disclosure authorisation for the individual concerned (see section 4 above).
Notifications will be created in a timely fashion (i.e. near real-time) and not as batch updates.
In the case of complex updates relating to the same MAS subject, there will a separate
notification for each separate Web Service involved in the updates.
The MAS should not attempt to make any judgement as to the significance or priority of a
notification. Presentation to the practitioner (in terms of the delivered wording and the
granularity, in terms of level of detail, timing and volume) has to be controlled by the target
agency system. It should seem to the practitioner that notifications appear automatically.
10.5 Alerts
10.5.1 Alerts as to risk
It was noted earlier (section 3.6.3) that the term “alert” can be used in two different (though
related) senses.
1. To refer to an action of alerting – i.e. to a message or notification that is sent to
relevant practitioners (or agency systems) at a particular point in time.
2. To refer to a more permanent flag or marker of concern as to the existence of serious
risk that is attached to a data subject’s shared record within the Multi-Agency Store
and remains visible (so long as it is in force) to anyone who subsequently accesses
that record.
As earlier discussed, the more permanent marker of risk is expressed through the
SubjectWarningFlag entity in the core area of the Data Model. In this specific context, an
action of alerting thus equates to a particular type of update notification, namely a notification
that a Warning Flag has been set for a Subject within the Multi-Agency Store.
So far as the notification of the “alert” is concerned, no further issues arise over and above
those already discussed. The notification will be identifiable as an alert, i.e. a change to the
Warning Flag entity, so long as there is a distinct Web Service for updating that entity (see
section 10.4.2 above). But it is perhaps important to emphasise that an agency system will
only be alerted if the system has a MAS index entry for the subject in question. If the subject
of an alert is not already known to an agency, the MAS cannot transmit the alert to that
agency.
10.5.2 Other types of alert
On a broader understanding of “alerts”, there may also be an occasional requirement for the
MAS to notify partner agencies of some need for action, even though no change has
occurred within the MAS itself. One case in point is an advance notification that a Subject’s
consent to data sharing is due to expire, where this consent has been gathered on a cross001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 107
Transformational Technologies Division
partnership basis. This is currently classified as a “miscellaneous” notification.
A second “miscellaneous” notification type serves to alert agency systems to the existence of
an “identity verification” issue. When updating the MAS, an agency system has the option of
supplying identity verification criteria (specifically, the person’s gender and date of birth)
along with the update. If there proves to be a difference from the original “matching” values,
an “identity verification issue” notification is broadcast to all systems that have matched the
person concerned.
A third “miscellaneous” notification type is specific to the case where an interface system
matches a person for whom there is already a current warning flag within the Multi-Agency
Store (see section 11.2 below). Unlike the previous two notifications, this is directly solely to
that interface system.
10.6 Matching Notifications
As explained in section 10.1 above, discussion of Matching Notifications has now (Version
1.4 of this document) been transferred to the Hub Data Model document [11].
10.7 Logical Data Model for Notifications
As explained in section 10.1 above, the Logical Data Model for Notifications and the
associated discussion have now (Version 1.4 of this document) been transferred to the Hub
Data Model document [11].
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 108
Transformational Technologies Division
11. Child Protection Messages
11.1 Background
A cross-agency Child Protection Messaging (CPM) service was developed in Lanarkshire in
2005 as part of MGF Round 2, using Lanarkshire’s version of a Multi-Agency Store. In May
2006, the Scottish Executive took the decision to extend a similar system to the whole of
Scotland. The national Multi-Agency Store will be the medium for this development.
Among the principal features of the Lanarkshire CPM system are the following.
 Child Protection Messages are generated by the North Lanarkshire and South
Lanarkshire Social Work agencies. They are available for viewing by relevant staff in
Social Work, Health, Education, the Police and SCRA.
 The CPMs are restricted to Child Protection activity that has reached a formal stage –
i.e. formal Investigations (with involvement of Police as well as Social Work) and
Registrations.
 There are four different CPMs for a child who is or has been the primary subject of CP
activity –
o
Message 1a: commencement of CP Investigation (child not on Register),
o
Message 1b: commencement of CP Investigation (child already on Register),
o
Message 2: current CP Registration (where no Investigation is in process),
and
o
Message 3: past CP activity (i.e. the child has been on the Register and / or
subject to a CP Investigation at some time in the past).
 There are CPMs for “linked” adults and children as well as for the child who is the
primary subject of CP activity.
 CPMs are not simply one-off alerts but persist for later viewing.
 CPMs remain on the system until the 17th birthday of the child who is or was the
subject of CP activity.
 Professionals are required to acknowledge CPMs when they first read them. There is
a central record of acknowledgements.
The national CPM implementation will differ from the Lanarkshire system in two main
respects. First, it will not include “linked adult” messages, though messages will be
generated for children who are relevantly linked to the primary child. Secondly, there will be
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 109
Transformational Technologies Division
no central record of acknowledgements. User acknowledgements will be handled within the
interface systems through which CPMs are presented to end users.
Within the national MAS, CPMs will be superimposed upon an existing capacity to share
Child Protection information which is lacking in the Lanarkshire MAS. In particular, the
national MAS provides for sharing information about Child Protection Investigations (a
Process Type) and Child Protection Registrations (a Status Episode Type). Further details
are given in section 7.3.2 above. Through its Process structure, the national MAS also
provides a capacity to share concerns about a child prior to the initiation of a formal
Investigation.
Further background information about the national CPM implementation can be found in
“Child Protection Messaging: Message Content & Guidance”, published by the Scottish
Government’s Transformational Technologies Division [12].
11.2 CPMs in the national Multi-Agency Store
The Child Protection Message functions both as an immediate means of alerting relevant
professionals to CP activity and as a flag that remains attached to the child’s record over the
longer term. In the latter guise, it serves a continuing purpose over and above that of an
immediate alert. Over the years, new professionals will join the cross-agency network of
professionals who come into different sorts of contact with the child. In addition, new children
may become linked to a child who has been the subject of CP activity. In both contexts,
CPMs could have a continuing utility as a means of attracting a professional’s attention to the
presence of a Child Protection dimension in a child’s background story.
To clarify thinking about CPMs, it may be helpful to draw a distinction between the following:
1. A Child Protection Notification. This is a notification from the MAS to one or more
interface systems (i.e. those with a match for the child in question) that some CPrelevant MAS update has occurred.
2. A Child Protection Alert. This is an initial presentation to the end user(s) of an
interface system, consequential upon the receipt by that system of a Child
Protection Notification. The context in which the alert is presented to a user may
well vary from one interface system to another (as happens in Lanarkshire).
Assemblage and presentation of alerts fall within the responsibility of the interface
system, but should comply with the national standards set out in “Child Protection
Messaging: Message Content & Guidance” [12].
3. A Child Protection Flag. This is a piece of persistent data that forms part of a
child’s record. It can be viewed at any time subsequent to its creation. A CP Flag
may exist in the MAS, in which case it falls within the responsibility of the eCare
Framework, and / or it may be created in an interface system following receipt of
a Child Protection Notification, in which case it falls within the responsibility of the
interface system.
The Multi-Agency Store already provides a Subject Warning Flag feature (see section 3.6.3
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 110
Transformational Technologies Division
above). It is proposed to employ this as the mechanism for giving effect to Child Protection
Messages. Six new Risk Types will be introduced, one for each of the four messages for a
primary child and two for “linked child” messages (a distinction being made between a child’s
linkage to current CP activity and a linkage to past CP activity). The only change to the Data
Model itself will be the association of extension attributes with a Subject Warning Flag (see
sections 5.7 and 6.4 above and section 12.8 below).
On this approach, a Child Protection Notification will simply be a “Warning Flag” notification.
This is generated whenever a Warning Flag is created or updated (or when a Warning Flag
is deleted – see below). On receiving the notification, the interface system adaptor will then
query the MAS to retrieve such additional information as is necessary for assembling an
appropriate Child Protection Alert for presentation to end users, or for creating a Child
Protection Flag within its own persistent record for the child in question. (Note that contrary to
what was stated in Version 1.2 of this document, the Warning Flag notification does not hold
the identifier for the Warning Flag in the NotificationReferenceID.)
As part of Child Protection Messaging, an explicit check will be made for existing Subject
Warning Flags when a child is matched by a new interface system. An appropriate
Notification will be generated when a Flag is found (see section 10.5.2 above). This provides
a simple solution to the requirement to deliver existing CP Messages to agencies that are
newly involved with a child, or that are new participants in a Data Sharing Partnership. (Note
that this check extends to all Subject Warning Flags, but in the case of non-CPM Warning
Flags a notification will only be generated if a Warning Flag is current.)
Note that on occasion, a Child Protection Message (or more generally, a Subject Warning
Flag) may be recorded on the MAS in error. Provision is made for deleting an erroneous
CPM (or other Warning Flag) on the MAS. But if a CPM has been recorded against the
wrong child (or some other sort of Warning Flag has been recorded against the wrong
person), and partner agencies have been wrongly informed, it is clearly essential not simply
to make a correction on the MAS but to broadcast the correction to those who received the
original alert. A Warning Flag notification will therefore be generated not simply on insertion
or update of a Subject Warning Flag but also when a Flag is deleted.
11.3 Information required for Child Protection Messages
11.3.1 CPMs for the “primary” child
As already noted, there are four different CPMs for a child who is or has been subject to
Child Protection activity. A “primary” CPM will always be rooted in a current or past CP
Investigation and / or a current or past Registration. The relationships are as follows:
Message 1a
Message 1b
Message 2
Current CP Investigation exists;
Current CP Registration does not exist
Current CP Investigation exists;
Current CP Registration exists
Current CP Investigation does not exist;
Current CP Registration exists
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 111
Transformational Technologies Division
Message 3
Current CP Investigation does not exist;
Current CP Registration does not exist;
Either past CP Investigation exists or past CP Registration exists
(or both)
To avoid confusion, it is important to be clear that the “Child Protection Message” in the
following discussion is the CPM as presented on screen to an end user. This, of course, is
how the term is likely to be understood by most children’s services practitioners. In this
“presentation” sense, a Child Protection Message is not to be equated with a Subject
Warning Flag, nor indeed does it exist (in its assembled state) within the Multi-Agency Store.
Both in the Lanarkshire original and in the national scheme, the end user Message is
assembled by the presenting application out of a variety of ingredients, some of which will be
drawn from the underlying database (the Multi-Agency Store or its Lanarkshire equivalent)
and some of which will be contributed by the application itself. In MAS terms, the
SubjectWarningFlag entity supplies the kernel of the CPM, but other MAS entities also
contribute to the presented message.
It is also important to distinguish between (1) the current national standard for Child
Protection Messages (as expressed in the Standards Branch document “Child Protection
Messaging: Message Content & Guidance” [12]) and (2) the textual values of the
corresponding Risk Types (as held on CVRiskType). For example, the current national
standard for the main part of Message 1b is close to the Lanarkshire wording (illustrated
below) though not quite identical – “A Child Protection investigation has commenced in
respect of [Name of Child] and this child’s name is currently recorded on a Child Protection
Register.” Message 1b corresponds to Risk Type SN-RKT-04. The CV text for the value is
“Child is the subject of a CP Investigation and is currently on the CP Register”. This is again
similar to the standard CPM, but is not itself the Message (which indeed extends beyond the
quoted sentence to the whole on-screen display). The CV text expresses the general
meaning of the CPM in a form which is decoupled from any particular agency or child.
In the Lanarkshire implementation, all the CPMs have a similar format. The following
screenshot shows the Lanarkshire version of Message 1b:
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 112
Transformational Technologies Division
It can be seen that the Lanarkshire Message contains a number of elements in addition to
the child’s name. Leaving aside the Acknowledgement button, these are:
 Within the first sentence, standard text precedes the name.
 In this particular message, some further standard text follows the name.
 A second paragraph conveys an instruction to the end user.
 Contact details are displayed for the Social Work team that holds the main
responsibility for the child.
 Contact details are also displayed for the Stand By or Out of Hours team.
The national CPMs follow the same structure. Some of these elements are likely to be
standard for a given Message within a given Partnership, but the contact details may clearly
vary. There is advantage in holding the Message content within the Multi-Agency Store, but it
seems safest to use extension attributes for this purpose (leaving it to the originating agency
to store the appropriate details). In the case of contact details for the main Social Work team,
the existing ContactAgency and ContactPhoneNumber attributes are already available for
holding contact details.
As noted above, a “primary” CPM is always related to a current or past CP Investigation and
/ or a current or past Registration (or both); details of these can be stored on the MAS (any
Investigation as a Process and any Registration as a Status Episode) along with the Warning
Flag.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 113
Transformational Technologies Division
11.3.2 CPMs for a “linked” child
A “linked” child must be created as a Subject in the MAS. The primary child to whom a child
is linked may not always be resident in the same Partnership area. For this and other
reasons, it is not proposed to ground the “linked” child CPM in an explicit relationship
between the two children. If both children are Subjects within the same MAS, the originating
agency will of course have the option of recording their relationship as a PersonToPerson
entry.
There will be two main differences between “linked” child CPMs in the national system and
their counterparts in the Lanarkshire system. First, the national system will have separate
Messages for the case where a child is linked to a child (or children) who is currently subject
to a CP Registration or Investigation and the case where a child is linked to a child (or
children) who has been subject to CP activity at some time in the past. (This echoes the
distinction between Messages 1a, 1b and 2 for a “primary” child and Message 3.) Secondly,
the national Messages will not themselves identify the “primary” child or children to whom the
“linked” child is linked. But the national Messages will indicate whether the “linked” child lives
at the same address as the child (or at least one of the children if there is more than one)
who is or was subject to CP activity.
Once again, the database mechanism employed for recording the “same household”
information is simply a true/false extension attribute. The “presented” CPM reflects this
through a full English sentence, supplied by the presenting application in accordance with
national standards.
11.4 Logical Data Model for Child Protection Messages
The following diagram shows the logical view of the data model for Child Protection
Messages. All the entities have already been documented in earlier sections, the only new
feature being the attachment of extension attributes to the SubjectWarningFlag entity. The
extension attributes are documented in section 12.8 below.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 114
Transformational Technologies Division
Person
Subject
PersonID
PersonID (FK)
BirthDate
BirthDateVerificationCV
DeathDate
DeathDateVerificationCV
GenderCurrentCV
EthnicGroupSelfAssignedCV
EthnicGroupSpecificCV
ReligionCV
CountryOfBirthCV
FirstLanguageCV
InterpretationAssistanceCV
SubjectWarningFlag
SexAtBirthCV
SexualOrientationCV
PreferredLanguageCV
HouseholdCompositionCV
LivesAlone
PreferredCommunicationMethodCV
OtherCommunicationMethod
OtherImpairment
PersonRepresentativeRequired
WarningFlagID
PersonID (FK)
RiskTypeCV (FK)
WarningStartDate
WarningEndDate
ContactPerson
ContactAgency
ContactPhoneNumber
ContactEmail
WarningGuidance
ExtensionSetID (FK)
StatusEpisode
StatusEpisodeID
PersonToProcessHistory
PersonID (FK)
StatusEpisodeTypeID (FK)
StatusEpisodeDescription
OrganisationID
OrganisationName
InitiatingReference
ValidStart
ValidEnd
TransactionStart
TransactionEnd
ExtensionSetID (FK)
HistoryID
PersonID (FK)
ProcessID (FK)
ProcessInvolvementTypeCV
ValidStart
ValidEnd
TransactionStart
TransactionEnd
StatusEpisodeType
StatusEpisodeTypeID
StatusEpisodeTypeCV
IsUnique
ExtensionSet
Process
ExtensionSetID
ProcessID
AttributeSetID (FK)
ProcessTypeCV
ProcessDescription
ProcessStartDate
ProcessEndDate
InitiatingReference
ProcessStatusLCV
ExtensionSetID (FK)
Controlled Vocabularies
ExtensionTable
ExtensionID
CVValue
CVControlledVocabulary
CVValueID
CVID
CVID (FK)
CVValueCode
CVValueText
CVValueOrder
CVValueFlag
CVName
CVCode
CVDescription
CVFlag
AttributeSet
AttributeSetToAttribute
AttributeSetID
AttributeSetID (FK)
AttributeID (FK)
ExtensionSetID (FK)
AttributeID (FK)
AttributeCV
AttributeValue
AttributeBLOB
Occurrence
CVValueID (FK)
AttributeOrder
IsCurrent
Attribute
AttributeID
AttributeName
AttributeTypeID (FK)
AttributeCVID (FK)
IsMultiValue
AttributeType
AttributeTypeID
ExtensionDataTypeCV (FK)
11.5 Update of Child Protection Messages
As will be evident, Investigations may begin and end; and children may move on and off the
Register (either in the course of an Investigation or at its conclusion). Likewise, a “linked”
child may move into or out of the household in which the primary child is resident.
In principle, there are two options for handling these changes. Either (1) a new Warning Flag
could be created at each point of change or (2) the RiskTypeCV attribute or relevant
extension attribute could simply be updated on the existing Warning Flag. Option 2 seems
preferable from an end user point of view. The Warning Start Date would then be the date of
the most recent update. The Warning End Date would always be the constant date UC (“Until
Changed”). A new “Warning Flag” notification would be generated whenever a Warning Flag
was updated.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 115
Transformational Technologies Division
12. Data Dictionary
12.1 Introduction
This section contains the Data Dictionary for the entire eCare MAS data model. For ease of
cross-reference, each part of the data model has its own sub-section. The “dynamic entities”
sub-section includes details of the extension attributes for dynamic entities as well as the
Data Dictionary itself. It also includes a tabular summary of the relationship between the
data items in the two SCDS2 Children’s Datasets and the entities and attributes in the eCare
Data Model.
The following general comments apply throughout:

Many data items are associated with controlled vocabularies. These are documented
(in alphabetical order) in section 13.

As documented in section 9.3.3, every entity also possesses two standard auditing
attributes: AuditLogID and ModifiedDate. The AuditLogID associates the table entry
with the Audit Log entry pertaining to its latest update. ModifiedDate is the MAS
latest update date. (At a physical level, the attributes InterfaceSystemID, MessageID
and AuditReference would also be added to each entity, though logically these can
be inferred from the Audit Log and Message Log entries. This is to enable them to be
written to the MAS Transaction Log.)

In relation to dates, UC stands for “Until Changed”. It is a constant date which is a
default value for certain recurring data items such as ValidEnd and TransactionEnd.
At a physical level, UC might be equated with the maximum date supported by the
Multi-Agency Store’s database management system.
12.2 Data Dictionary for Core MAS Data
This part of the Data Dictionary corresponds to the data model extract shown in section 2.8,
but with the addition of the InterfaceSystem entity (which has been transferred physically to
the Hub, but continues to have logical relevance within the MAS Data Model). Note that the
data items for core data are largely derived from the Scottish Social Care Data Standards
Manual [5]. The Data Item Tabular Summary from that Manual is reproduced as Appendix B.
Further documentation can be found in the body of the Manual.
Note also that the following entities are now (Version 1.4 of this document) documented in
the Hub Data Model document:
 ExternalReference
 PrimaryIndex
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 116
Transformational Technologies Division
 PersonStatus
Table Name
Field
Candidate
Key
Description/purpose
Person
Contains an entry for every person about whom data is held in the MAS – whether a Subject (a primary subject of
information sharing), a Professional or an associated person (e.g. a relative or neighbour of a Subject). Extension
entities exist for Subjects and Professionals (but not for associated persons). Every Person must have at least one
entry in the Hub’s PrimaryIndex table (but only a Subject must be “matched”).
PersonID (FK)
(y)
Identifier of the person
globally unique
eCare Team
identifier
BirthDate
Date of Birth
large DateTime
SCDS2
BirthDate
As defined by GDSC standard. From
globally unique
SCDS2
VerificationCV
CVVerificationLevel.
identifier
DeathDate
Date of death
large DateTime
SCDS2
DeathDateVerification
As defined by GDSC standard. From
globally unique
SCDS2
CV
CVVerificationLevel.
identifier
GenderCurrentCV
From CVGender
globally unique
SCDS2
identifier
EthnicGroupSelf
From CVEthnicGroupSelfAssigned
globally unique
SCDS2
AssignedCV
identifier
EthnicGroup
From CVEthnicGroupSpecific
globally unique
SCDS2
SpecificCV
identifier
ReligionCV
From CVReligion
globally unique
SCDS2
identifier
CountryOfBirthCV
From CVCountryOfBirth
globally unique
SCDS2
identifier
FirstLanguageCV
From CVLanguage
globally unique
SCDS2
identifier
Interpretation
From CVInterpretationAssistance
globally unique
SCDS2
AssistanceCV
identifier
Person
Reference
Allows the assignment of reference numbers or identifiers to a person when these are required as viewable data
items. The person may be either a Subject or a Professional (or conceivably an associated person).
PersonID (FK)
(y)
Identifier of the person
globally unique
eCare Team
identifier
PersonReferenceCV
(y)
From CVPersonReference, which
globally unique
eCare Team
identifies the identifier as being e.g. a
identifier
Scottish Candidate Number or a GMC
number
Identifier
The reference number or identifier itself
SBCS
eCare Team
varchar(50)
Name
Identifies a person’s name, but must be associated with one or more Name Elements (where the name itself is
held). A person can have more than one name.
NameID
(y)
Identifier of this name
globally unique
eCare Team
identifier
PersonID (FK)
Identifier of the person
globally unique
eCare Team
identifier
IsPreferredName
1 = the name by which a person prefers
true/false
SCDS2
to be known; 0 = other name
Name
Element
An element within a name (e.g. a forename). Can on occasion be the whole of a name (when the Element Type is
“unstructured name”).
NameElementID
(y)
Identifier of this element of the name
globally unique
eCare Team
identifier
NameID (FK)
Identifier of the name
globally unique
eCare Team
identifier
NameElement
The element itself – e.g. 'Miss' or 'Jane'
SBCS
SCDS2
or 'Smith'
varchar(70)
ElementTypeCV
From CVNameElementType, which lists globally unique
SCDS2
the possible types of element – e.g.
identifier
title, forename, surname
ElementPosition
Position of the element within the name
integer
SCDS2
as a whole
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Data type
Source(s)
Version: 1.4 Release
28/03/2008
Page 117
Transformational Technologies Division
Table Name
Field
IsPreferredForename
Candidate
Key
Description/purpose
Data type
Source(s)
1 = the forename by which a person
prefers to be known; 0 = other
forename
true/false
SCDS2
Name
History
Allows a name history to be maintained. Now attaches to the name as a whole, not to the elements within it.
Because the status of a name may change (e.g. a “registered name” may become a “maiden name”), this attribute
is held on the history record.
NameHistoryID
(y)
Identifier of this element of the name
globally unique
eCare Team
identifier
NameID (FK)
Identifier of the name
globally unique
eCare Team
identifier
NameStatusCV
From CVNameStatus, which lists the
globally unique
SCDS2
possible statuses of a name – e.g.
identifier
married name, maiden name
ValidStart
The first day on which the Name was
large DateTime
eCare Team
valid
ValidEnd
The first day on which the Name
large DateTime
eCare Team
ceased to be valid – if still current,
defaults to UC
TransactionStart
When the Name was first recorded
large DateTime
eCare Team
TransactionEnd
Cancellation date if record is cancelled
large DateTime
eCare Team
– an uncancelled record will default to
UC
Subject
An extension entity to the Person entity, containing an entry for each person (child or adult) who is a primary
subject of information sharing through eCare. Unlike other Persons, a Subject must have been “matched”.
PersonID (FK)
(y)
Identifier of the person
globally unique
eCare Team
identifier
SexAtBirthCV
From CVGender
globally unique
SCDS2
identifier
SexualOrientationCV
From CVSexualOrientation
globally unique
SCDS2
identifier
Preferred
From CVLanguage
globally unique
SCDS2
LanguageCV
identifier
Household
From CVHouseholdComposition
globally unique
SCDS2
CompositionCV
identifier
LivesAlone
1 = Lives alone; 0 = Does not live alone
true/false
SCDS2
Preferred
From CVPreferredCommunication
globally unique
SCDS2
Communication
Method
identifier
MethodCV
OtherCommunication
To record values not contained within
SBCS
SCDS2
Method
the Controlled Vocabulary
varchar(255)
OtherImpairment
To record values not contained within
SBCS
SCDS2
CVImpairment (note that this CV is
varchar(255)
stored in the SubjectImpairment table)
Person
1 = A representative is required (e.g. an
true/false
SCDS2
Representative
advocate); 0 = A representative is not
Required
required
Subject
Impairment
Provides for a Subject to have one or more of the “impairments” listed in CVImpairment (e.g. hearing impairment,
visual impairment, etc.). Only current information is required.
PersonID (FK)
(y)
The ID of the Subject
globally unique
eCare Team
identifier
ImpairmentCV
(y)
From CVImpairment
globally unique
SCDS2
identifier
Subject
Affecting
Disability
Provides for a (child) Subject to be recorded as being affected by another family member’s disability, using the
Children (Scotland) Act 1995 categories (so that more than one category might apply). Only current information is
required.
PersonID (FK)
(y)
The ID of the Subject
globally unique
eCare Team
identifier
AffectingDisabilityCV
(y)
From CVAffectingDisability
globally unique
SCDS2
identifier
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 118
Transformational Technologies Division
Table Name
Field
SubjectNote
Provides for one or more notes to be recorded against a Subject. In Data Standards terms, these can include
notes on “Other Cultural Issues” as well as Crucial Background and Medical Information. Replaces the former
Notes attribute on Subject (which presented the danger that one agency’s note might be overwritten by another).
Allows the option of recording the author and a short note title.
SubjectNoteID
(y)
Identifier of the Subject Note
globally unique
eCare Team
identifier
PersonID (FK)
Identifier of the Subject to whom the
globally unique
eCare Team
Note relates
identifier
ProfessionalID (FK)
Identifier of the Professional who is the
globally unique
eCare Team
author of a Note (optional)
identifier
NoteTitle
A brief title identifying the Note topic
SBCS
eCare Team
(optional)
varchar(50)
NoteText
The note itself
SBCS
eCare Team
varchar(4000)
NoteRecordedDate
The date the Note was made
large DateTime
eCare Team
Subject
WarningFlag
A warning that a Subject is either at risk or a potential source of risk. Old warnings are retained.
WarningFlagID
PersonID (FK)
RiskTypeCV
WarningStartDate
WarningEndDate
ContactPerson
ContactAgency
Candidate
Key
(y)
Description/purpose
Identifier of the Warning Flag
Associates the Warning Flag with a
Subject to whom the warning relates
From CVRiskType, which distinguishes
types of potential risk
The date on which the Warning Flag
was posted
The date on which the Warning Flag
was withdrawn – equates to UC when
the warning is current
A contact person from whom further
information may be sought
The agency to which the contact person
belongs
ContactPhone
Number
ContactEmail
WarningGuidance
ExtensionSetID (FK)
Professional
PersonTo
Professional
A message relating to the warning (e.g.
containing practical guidance)
Identifier of an Extension Set of
additional Warning Flag attributes
(dependent on risk type)
Data type
Source(s)
globally unique
identifier
globally unique
identifier
globally unique
identifier
large DateTime
eCare Team
large DateTime
SCDS2
SBCS
varchar(70)
SBCS
varchar(255)
SBCS
varchar(255)
SBCS
varchar(255)
SBCS
varchar(255)
globally unique
identifier
SCDS2
An extension entity to the Person entity, containing an entry for each Professional.
PersonID
(y)
Identifier of the Professional
globally unique
identifier
OrganisationID (FK)
Where a Professional’s employing
globally unique
agency exists as an Organisation, the
identifier
identifier of the Organisation
JobTitle
SBCS
varchar(255)
EmployingAgency
Alternative to using OrganisationID
SBCS
varchar(255)
OfficeBase
The office where the worker is based
SBCS
varchar(255)
eCare Team
SCDS2
SCDS2
SCDS2
SCDS2
SCDS2
SCDS2
eCare Team
eCare Team
eCare Team
SCDS2
SCDS2
eCare Team
Provides for a person to be linked to a Professional. The Professional’s role may change over time, so is held on
the separate ProfessionalRoleHistory entity.
PersonID (FK)
(y)
Identifier of the person
globally unique
eCare Team
identifier
ProfessionalID (FK)
(y)
Identifier of the professional
globally unique
eCare Team
identifier
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 119
Transformational Technologies Division
Table Name
Field
Professional
RoleHistory
Hangs off PersonToProfessional, providing for a Professional to have one or more roles in relation to a Subject.
Historical records are retained – i.e. roles that a Professional used to play. There is a potential overlap with the
option to record the relationship of a Professional to a Process (e.g. a referral or an assessment) through the
PersonToProcessHistory entity in the Processes and Events part of the Data Model, but there are some
Professionals (e.g. a GP) whose relationship is properly seen as being to the Subject rather than to a specific
process concerning the subject. Other Professionals can have both a long-term relationship with the Subject (e.g.
being their social worker) and play a specific role in relation to a specific process (e.g. being the lead professional
for an assessment), in which case both entities can be used.
HistoryID
(y)
Identifier of the record
globally unique
eCare Team
identifier
PersonID (FK)
Identifier of the Subject
globally unique
eCare Team
identifier
ProfessionalID (FK)
Identifier of the Professional
globally unique
eCare Team
identifier
ProfessionalRoleLCV
From LCVProfessionalRole (locally
globally unique
SCDS2
defined)
identifier
ValidStart
The first day on which the Professional
large DateTime
eCare Team
had the role in question
ValidEnd
The first day on which the Professional
large DateTime
eCare Team
ceased to have the role – if still current,
defaults to UC
TransactionStart
When the Professional was first
large DateTime
eCare Team
recorded as having the role
TransactionEnd
Cancellation date if record is cancelled
large DateTime
eCare Team
– an uncancelled record will default to
UC
PersonTo
Person
Provides for a Subject to be linked to an associated person (e.g. a relative). While the abiding relationship of the
two people (e.g. the fact that the associated person is the Subject’s mother) is held on this entity, the role of the
associated person may change over time, so is held on the separate AssociatedPersonRoleHistory entity.
PersonID (FK)
(y)
ID of the person who is the subject of
globally unique
eCare Team
the assessment
identifier
AssociatedPersonID
(y)
ID of the person linked to the subject of
globally unique
eCare Team
(FK)
assessment
identifier
RelationshipCV
From CVRelationship
globally unique
SCDS2
identifier
Relationship
From CVVerificationLevel
globally unique
SCDS2
VerificationCV
identifier
IsDependant
Associated person is dependant of
true/false
SCDS2
primary person
Associated
PersonRole
History
Hangs off PersonToPerson, providing for an associated person to have one or more roles in relation to a Subject
(e.g. carer, keyholder, etc.). Historical records are retained – i.e. roles that a person used to play.
HistoryID
Candidate
Key
(y)
Description/purpose
Identifier of the record
PersonID (FK)
Identifier of the Subject
AssociatedPersonID
(FK)
AssociatedPerson
RoleCV
Identifier of the associated Person
ValidStart
ValidEnd
TransactionStart
TransactionEnd
From CVAssociatedPersonRole
(nationally defined, unlike Professional
Role)
The first day on which the person had
the role in question
The first day on which the person
ceased to have the role – if still current,
defaults to UC
When the person was first recorded as
having the role
Cancellation date if record is cancelled
– an uncancelled record will default to
UC
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Data type
Source(s)
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
eCare Team
large DateTime
eCare Team
large DateTime
eCare Team
large DateTime
eCare Team
large DateTime
eCare Team
eCare Team
eCare Team
SCDS2
Version: 1.4 Release
28/03/2008
Page 120
Transformational Technologies Division
Table Name
Field
Organisation
An organisation might be e.g. a Subject’s landlord or a child’s school. The entity is intended to hold only minimal
details within the MAS.
OrganisationID
(y)
Identifier of the Organisation
globally unique
eCare Team
identifier
OrganisationName
Name of the Organisation
SBCS
eCare Team
varchar(255)
OrganisationTypeCV
For optional use, drawing on
globally unique
eCare Team
CVOrganisationType, which lists some
identifier
common types of organisation
OrganisationType
For optional use, allowing textual entry
SBCS
eCare Team
Description
of an organisation type (formerly named varchar(100)
OrganisationType)
Organisation
Reference
Allows the assignment of reference numbers or identifiers to an “organisation” such as a school or GP practice.
Description/purpose
OrganisationID (FK)
(y)
Identifier of the organisation
Organisation
ReferenceCV
(y)
From CVOrganisationReference, which
identifies the identifier as being e.g. a
GP Practice Code or a SEED
Reference Number
The reference number or identifier itself
Identifier
Address
Candidate
Key
Data type
Source(s)
globally unique
identifier
globally unique
identifier
eCare Team
SBCS
varchar(50)
eCare Team
eCare Team
An address may be linked to one or more Persons and / or to one or more Organisations through the link entities
described below. An address may be held in a structured form, including one that complies with the BS7666
standard, or in an unstructured form. Where an agency system holds an address as a Simple Address, it is
mapped to Address Lines 1 to 5.
AddressID
(y)
Identifier of the Address
globally unique
eCare Team
identifier
UPRN
Unique Property Registration Number –
biginteger
eCare Team
if this is known then the address must
conform to BS7666
SAON
Secondary Addressable Object Name
SBCS
SCDS2
varchar(100)
PAON
Primary Addressable Object Name
SBCS
SCDS2
varchar(100)
StreetDescription
Street
SBCS
SCDS2
varchar(100)
Locality
Locality or area
SBCS
SCDS2
varchar(35)
Town
SBCS
SCDS2
varchar(30)
AdministrativeArea
E.g. County
SBCS
SCDS2
varchar(30)
AddressLine1
First line of Simple Address
SBCS
SCDS2
varchar(100)
AddressLine2
Second line of Simple Address
SBCS
SCDS2
varchar(100)
AddressLine3
Third line of Simple Address
SBCS
SCDS2
varchar(100)
AddressLine4
Fourth line of Simple Address
SBCS
SCDS2
varchar(100)
AddressLine5
Fifth line of Simple Address
SBCS
SCDS2
varchar(100)
PostCode
SBCS
SCDS2
varchar(8)
Country
Not part of the BS7666 standard but to
SBCS
eCare Team
support overseas addresses if required
varchar(35)
UnstructuredAddress
To enable storage of address as one
SBCS
eCare Team
long string if agency systems require
varchar(1000)
this
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 121
Transformational Technologies Division
Table Name
Field
Candidate
Key
DwellingTypeCV
AccommodationType
CV
Description/purpose
Data type
Source(s)
From CVDwellingType, which lists
types of dwelling (e.g. terraced house,
flat, etc.)
From CVAccommodationType, which
lists types of accommodation (e.g.
mainstream, sheltered housing, etc.)
globally unique
identifier
SCDS2
globally unique
identifier
SCDS2
PersonTo
Address
Links a Person to an Address. Temporal data (including Address Type) are held on the PersonToAddressHistory
record.
PersonToAddressID
(y)
Identifier of the record
globally unique
eCare Team
identifier
AddressID (FK)
Identifier of the Address
globally unique
eCare Team
identifier
PersonID (FK)
Identifier of the Person
globally unique
eCare Team
identifier
TenureTypeCV
From CVTenureType, which lists types
globally unique
SCDS2
of tenure (e.g. owned outright, etc.)
identifier
Notes
SBCS
eCare Team
varchar(500)
PersonTo
Address
History
Hangs off PersonToAddress. If the address type changes (e.g. what was a temporary domicile address becomes
a normal domicile address), a new history record is created.
HistoryID
(y)
PersonToAddressID
(FK)
AddressTypeCV
Identifier of the Person to Address link
to which the history record relates
From CVAddressType, which lists
different types of address with which a
person may be associated (e.g. normal
domicile address, alternative contact
address, etc.)
The first day on which the address was
valid for the person (with the given
address type)
The first day on which the address
ceased to be valid for the person – if
still current, defaults to UC
When the person was first recorded as
having the address
Cancellation date if record is cancelled
– an uncancelled record will default to
UC
ValidStart
ValidEnd
TransactionStart
TransactionEnd
Organisation
ToAddress
Identifier of the record
eCare Team
large DateTime
eCare Team
large DateTime
eCare Team
large DateTime
eCare Team
large DateTime
eCare Team
eCare Team
SCDS2
Links an Organisation to an Address. For Organisations, there is neither an Address Type nor a History entity.
AddressID (FK)
(y)
Identifier of the Address
OrganisationID (FK)
(y)
Identifier of the Organisation
Notes
ContactDetail
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
SBCS
varchar(500)
eCare Team
eCare Team
eCare Team
An entry exists for each phone number, fax number or email address. A contact detail can be linked to either a
Person or an Organisation.
ContactDetailID (FK)
(y)
Identifier of this record
globally unique
eCare Team
identifier
ContactDetailData
The phone number or email address
SBCS
eCare Team
varchar(255)
ContactDetailTypeCV
From CVContactDetailType, which lists
globally unique
eCare Team
different types of contact detail
identifier
(including different types of phone
number)
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 122
Transformational Technologies Division
Table Name
Field
Candidate
Key
Description/purpose
Notes
PersonTo
ContactDetail
Organisation
ToContact
Detail
Data type
Source(s)
SBCS
varchar(500)
eCare Team
globally unique
identifier
globally unique
identifier
eCare Team
globally unique
identifier
globally unique
identifier
eCare Team
Links a Person to a Contact Detail.
ContactDetailID (FK)
(y)
Identifier of the Contact Detail
PersonID (FK)
(y)
Identifier of the Person
eCare Team
Links an Organisation to a Contact Detail.
OrganisationID (FK)
(y)
Identifier of the Organisation
ContactDetailID (FK)
(y)
Identifier of the Contact Detail
eCare Team
CVControlled
Vocabulary
Holds an entry for each Controlled Vocabulary – i.e. for each range of specified values from which a database
value must be selected.
CVID
(y)
Identifies the Controlled Vocabulary
globally unique
eCare Team
identifier
CVName
The name of the Controlled Vocabulary
SBCS
eCare Team
varchar(50)
CVCode
A code for the Controlled Vocabulary
SBCS
eCare Team
varchar(100)
CVDescription
Free text description
SBCS
eCare Team
varchar(50)
CVFlag
To flag if not currently in use (0 = out of
true/false
eCare Team
use; 1 = in use)
CVValue
Holds an entry for each value within a Controlled Vocabulary.
CVValueID
(y)
Identifies the CV Value
CVID (FK)
Identifies the Controlled Vocabulary
CVValueCode
A code for the Value
CVValueText
The textual description of the Value
CVValueOrder
Allows the order of the items in the CV
to be set – default is 0 (unordered)
To mark a value as not in use (0 = out
of use; 1 = in use)
CVValueFlag
Interface
System
globally unique
identifier
globally unique
identifier
SBCS
varchar(100)
SBCS
varchar(500)
Integer
eCare Team
true/false
eCare Team
eCare Team
eCare Team
eCare Team
eCare Team
A partner or agency system that interacts with the MAS (or a maintenance application that updates reference
entities). Where MAS is updated through the direct intervention of a Database Administrator, the DBA must also
exist as an Interface System. [Note that this entity now lives physically in the Hub database, not in the MAS.]
InterfaceSystemID
(y)
Identifier of the Interface System
globally unique
eCare Team
identifier
SystemName
A plain English name for the Interface
SBCS varchar
eCare Team
System, equivalent to a username
(50)
SystemDescription
A description of the user base for the
SBCS varchar
eCare Team
Interface System
(255)
12.3 Data Dictionary for Disclosure Conditions
This part of the Data Dictionary corresponds to the data model extract shown in section 4.2.
It excludes those entities that have already been documented as “core” data.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 123
Transformational Technologies Division
Table Name
Field
Disclosure
Authority
A specific Interface System’s authority to contribute a person’s data to the MAS. May or may not be rooted in a
person’s own (or proxy’s) consent to the sharing of data, but must reflect a competent professional’s view that data
disclosure is necessary and relevant.
PersonID (FK)
(y)
Identifier of the person
globally unique
eCare Team
identifier
InterfaceSystemID
(y)
Identifier of the Interface System
globally unique
eCare Team
(FK)
identifier
Disclosure
Authority
History
Hangs off DisclosureAuthority and holds authority details. If the authority status changes, a new history record is
created.
AuthorityHistoryID
PersonID (FK)
InterfaceSystemID
(FK)
AuthorityStatusCV
Authorising
Professional
AuthorityStatus
Reason
PartnershipConsentID
(FK)
IsConsentedFor
Sector
ValidStart
ValidEnd
Partnership
Consent
Candidate
Key
(y)
Description/purpose
Identifier of the Disclosure Authority
History entry
Identifier of the person
Identifier of the Interface System
From CVAuthorityStatus, which
distinguishes between authority to
disclose and suspension of that
authority
Name of the professional within the
interface system agency who
authorised disclosure of the person’s
data (or suspension of disclosure)
through the MAS
The agency’s reason for disclosing data
(or for ceasing to disclose data) –
particularly pertinent in the absence of
consent
Identifier of the relevant
PartnershipConsent entry if one exists
(otherwise null)
1 = Consent has been given specifically
(by the person concerned or a parent or
proxy) for sharing data from the sector
(e.g. Health) to which the Interface
System belongs; 0 = Consent has not
been given specifically for a sector (so
that if there is no
PartnershipConsentID, it must be an
“override” situation)
The valid start date for the history entry
The valid end date for the history entry
– if still current, defaults to UC,
otherwise equates to the valid start date
for the next history entry
Data type
Source(s)
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
eCare Team
SBCS
varchar(255)
SCDS2
SBCS
varchar(255)
SCDS2
globally unique
identifier
SCDS2
true/false
SCDS2
large DateTime
large DateTime
SCDS2
SCDS2
eCare Team
eCare Team
SCDS2
A person’s informed consent to the sharing of data across eCare partner agencies (to the extent that it is
necessary and relevant to do so), when this is obtained by one partner agency on behalf of the partnership as a
whole. For a given person, there can be at most one PartnershipConsent entry, but there will only be an entry if
the person has at some time given this sort of “extended” consent to sharing of all partner agencies’ data across
the partnership. If an agency (or sector) obtains consent only in respect of disclosing its own data to other partner
agencies, this will not give rise to a PartnershipConsent entry but rather to a “true” value for IsConsentedForSector
on the relevant DislosureAuthorityHistory entries. In an “override” situation where either consent has not been
sought or it has been sought and refused, there will be no PartnershipConsent entry and a “false” value for
IsConsentedForSector.
PartnershipConsentID (y)
Identifier of the Partnership Consent
globally unique
eCare Team
identifier
PersonID (FK)
Identifier of the person
globally unique
eCare Team
identifier
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 124
Transformational Technologies Division
Table Name
Field
Candidate
Key
Description/purpose
Data type
Source(s)
Partnership
Consent
History
Hangs off PartnershipConsent and holds consent details. Where consent is given for a specified period (e.g. a
year) and is then renewed, a new history record is created (with the same status). A new history record is also
created if the consent status or consent type changes (e.g. consent is withdrawn, or the terms of consent are
amended, or the person’s own consent replaces parental or proxy consent). But if the consent simply expires, this
is indicated through the end date – a new history record is not created.
PartnershipConsent
(y)
Identifier of the Partnership Consent
globally unique
eCare Team
HistoryID
History entry
identifier
PartnershipConsentID
Identifier of the Partnership Consent
globally unique
eCare Team
(FK)
identifier
ConsentStatusCV
From CVConsentStatus
globally unique
SCDS2
identifier
ConsentTypeCV
From CVConsentType
globally unique
SCDS2
identifier
ConsentProfessional
Name of the professional who obtained
SBCS
SCDS2
the client’s consent to share data (or
varchar(255)
any subsequent qualification of that
consent)
ConsentAgency
The agency to which the professional
SBCS
SCDS2
belongs
varchar(255)
ConsentNote
Allows any necessary details to be
SBCS
SCDS2
recorded (e.g. as to the context in which varchar(2000)
consent was obtained, which parent
gave the consent for a child, the reason
for withdrawal if it is withdrawn, etc.)
ValidStart
The valid start date for the history entry
large DateTime
SCDS2
(i.e. the real world date on which
consent was given, withdrawn, etc.)
ValidEnd
The valid end date for the history entry
large DateTime
SCDS2
– if no end date exists, defaults to UC
12.4 Data Dictionary and Extension Attributes for Dynamic Entities
12.4.1 Data Dictionary for Dynamic Entities
This part of the Data Dictionary corresponds to the data model extract shown in section 5.8.
It excludes those entities that have already been documented as “core” data. It also
excludes the Form and ProcessToForm entities, which will be documented in section 12.5.
Table Name
Field
Candidate
Key
Description/purpose
Process
A mutually recognised business process or agency procedure about which information is to be shared, and which
may be associated with one or more information-bearing Forms
ProcessID
(y)
Identifier of the process
globally unique
eCare Team
identifier
ProcessTypeCV
From CVProcessType, which contains
globally unique
SCDS2
recognised process types (e.g.
identifier
assessment, review, etc.)
ProcessDescription
A brief description of the process
SBCS
SCDS2
varchar(255)
ProcessStartDate
The date the process started
large DateTime
SCDS2
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Data type
Source(s)
Version: 1.4 Release
28/03/2008
Page 125
Transformational Technologies Division
Table Name
Field
ProcessEndDate
InitiatingReference
ProcessStatusLCV
ExtensionSetID (FK)
Candidate
Key
Description/purpose
Data type
Source(s)
The date the process was completed –
if still continuing, defaults to UC
A reference applied to the first process
or event within a connected chain or
sequence and subsequently applied to
each later process, event or status
episode within the same sequence
From LCVProcessStatus – locally
defined statuses (e.g. Cancelled, etc.)
Identifier of an Extension Set of
additional process attributes
(dependent on process type)
large DateTime
SCDS2
SBCS
varchar(50)
SCDS2
globally unique
identifier
globally unique
identifier
SCDS2
eCare Team
Process
Focus
A given Process (e.g. an assessment) may have one or more focuses (as defined in a local CV). An example of a
process focus might be Mental Health or Learning Disability.
ProcessID (FK)
(y)
Identifier of the Process
globally unique
eCare Team
identifier
ProcessFocusLCV
(y)
From LCVProcessFocus – locally
globally unique
SCDS2
defined focuses (e.g. Learning
identifier
Disability)
IsMainFocus
Enables a Process Focus to be singled
true/false
SCDS2
out as the main focus for reporting
purposes
PersonTo
Process
History
Relates a Person to a Process. The person may be a Subject, a Professional or some other associated person. In
principle, more than one Subject may be involved in a Process – for example, a person and their carer, or several
children in a family. The same applies to other sorts of Person. A professional’s role in relation to a process may
change over time – for example, the professional may become the lead professional half-way through the process.
HistoryID
(y)
Identifier of the History record
globally unique
eCare Team
identifier
PersonID (FK)
Identifier of the Person who is related to globally unique
eCare Team
a Process
identifier
ProcessID (FK)
Identifier of the Process to which a
globally unique
eCare Team
Person is related
identifier
ProcessInvolvement
From CVProcessInvolvementType,
globally unique
SCDS2
TypeCV
which distinguishes between
identifier
involvement as a subject, a professional
and an associated person (and may
make further role distinctions below
this)
ValidStart
The first day on which the person had
large DateTime
eCare Team
the role
ValidEnd
The first day on which the person
large DateTime
eCare Team
ceased to have the role – if still current,
defaults to UC
TransactionStart
When the person was first recorded as
large DateTime
eCare Team
having the role
TransactionEnd
Cancellation date if record is cancelled
large DateTime
eCare Team
– an uncancelled record will default to
UC
ProcessNote
Enables a professional to share a case note relating to a process (or sharing of a system-generated note).
ProcessNoteID
(y)
Identifier of the Process Note
globally unique
eCare Team
identifier
ProcessID (FK)
Identifier of the Process which is the
globally unique
eCare Team
subject a Process Note
identifier
ProfessionalID (FK)
(Optional) identifier of the Professional
globally unique
eCare Team
who is the author of a Process Note
identifier
NoteTitle
A title for the note (for inclusion in a
SBCS
SCDS2
chronology)
varchar(50)
NoteText
The case note itself
SBCS
SCDS2
varchar(4000)
NoteRecordedDate
The date of the case note
large DateTime
SCDS2
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 126
Transformational Technologies Division
Table Name
Field
Event
An event (e.g. a life event or a service event) affecting one or more Subjects about which information is to be
shared. It may include a “failed” event – e.g. an event such as a home visit that was supposed to happen but didn’t
happen.
EventID
(y)
Identifier of the event
globally unique
eCare Team
identifier
EventTypeCV
From CVEventType, which contains
globally unique
SCDS2
recognised event types
identifier
EventDate
The date the event happened or is (or
large DateTime
SCDS2
was) due to happen
EventTitle
A short, informative, summary
SBCS
SCDS2
description of the event, suitable for
varchar(50)
display in a list
EventDescription
A full description of the event
SBCS
SCDS2
varchar(4000)
InitiatingReference
A reference applied to the first process
SBCS
SCDS2
or event within a connected chain or
varchar(50)
sequence and subsequently applied to
each later process, event or status
episode within the same sequence
EventStatusCV
From CVEventStatus, which contains a
globally unique
SCDS2
standard list of event statuses (e.g.
identifier
expected)
ExtensionSetID (FK)
Identifier of an Extension Set of
globally unique
eCare Team
additional event attributes (dependent
identifier
on event type)
PersonTo
Event
Relates Person to Event, where the person may be a Subject, a Professional or an associated person.
PersonID (FK)
(y)
EventID (FK)
(y)
EventInvolvement
TypeCV
Status
Episode
Candidate
Key
Description/purpose
Identifier of the Person who is related to
an Event
Identifier of the Event to which a Person
is related
From CVEventInvolvementType, which
contains a list of the ways a person can
be involved with an event
Data type
globally unique
identifier
globally unique
identifier
globally unique
identifier
Source(s)
eCare Team
eCare Team
SCDS2
The time-bounded possession by a Subject of a determinate status (which might be e.g. a marital status, a legal
status, a looked after status, etc.)
StatusEpisodeID
(y)
Identifier of the status episode
globally unique
eCare Team
identifier
PersonID (FK)
Identifier of the Subject to whom the
globally unique
eCare Team
status relates
identifier
StatusEpisodeTypeID
Identifier of the Status Episode Type to
globally unique
eCare Team
which the status episode belongs
identifier
StatusEpisode
An optional description of the status
SBCS
SCDS2
Description
episode
varchar(255)
OrganisationID (FK)
For use where a Status Episode Type
globally unique
SCDS2
relates to an “organisation” (e.g. a
identifier
hospital, care home, school, provider of
training, etc.) and the agency, institution
or provider exists as an Organisation on
the MAS
OrganisationName
For use to identify an “organisation”
SBCS
SCDS2
which doesn’t exist on the MAS
varchar(255)
InitiatingReference
A reference applied to the first process
SBCS
SCDS2
or event within a connected chain or
varchar(50)
sequence and subsequently applied to
each later process, event or status
episode within the same sequence
ValidStart
The first day on which the Subject had
large DateTime
eCare Team
the status in question
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 127
Transformational Technologies Division
Table Name
Field
ValidEnd
TransactionStart
TransactionEnd
ExtensionSetID (FK)
Candidate
Key
Description/purpose
Data type
Source(s)
The first day on which the Subject
ceased to have the status – if still
current, defaults to UC
When the Subject was first recorded as
having the status
Cancellation date if record is cancelled
– an uncancelled record will default to
UC
Identifier of an Extension Set of
additional status episode attributes
(dependent on status episode type)
large DateTime
eCare Team
large DateTime
eCare Team
large DateTime
eCare Team
globally unique
identifier
eCare Team
Status
EpisodeType
Status episode types are handled through a separate entity (rather than through a CV attribute on the Status
Episode itself). This allows a distinction to be made between those types (e.g. marital status) which are
necessarily unique for a given person at a given time and those which permit several entries for the same person
at the same time (e.g. developmental or medical status).
StatusEpisodeTypeID
(y)
Identifier of the Status Episode Type
globally unique
eCare Team
identifier
StatusEpisodeType
From CVStatusEpisodeType, which
globally unique
SCDS2
CV
contains a list of status episode types
identifier
IsUnique
1 = Only one instance of this Type can
true/false
eCare Team
exist for a given person at a given time
(e.g. marital status); 0 = Several
instances of this Type can exist for a
given person at a given time (e.g.
developmental or medical status)
AttributeSet
A process type, event type or status episode type may be associated with a set of additional attributes particular to
that type.
AttributeSetID
(y)
Identifier of the attribute set
globally unique
eCare Team
identifier
CVValueID
Identifier of the CVValue to which the
globally unique
eCare Team
attribute set attaches – the CVValue
identifier
being a process type, an event type or
a status episode type
AttributeType
The data type of an attribute (e.g. integer or datetime). It is required because the attribute is stored as a string type
in all cases, regardless of its actual type.
AttributeTypeID
(y)
Identifier of the attribute type
globally unique
eCare Team
identifier
ExtensionDataType
From CVExtensionDataType, which
globally unique
eCare Team
CV
contains a list of data types
identifier
Attribute
An extension attribute, which may belong in more than one attribute set.
AttributeID
(y)
Identifier of the attribute
AttributeName
The name of the attribute
AttributeTypeID (FK)
Identifier of the attribute type to which
the attribute belongs
Where an attribute takes a value from a
CV, identifier of the CV from which the
value is drawn
True indicates that the attribute can
have more than one value in a given
case
AttributeCVID (FK)
IsMultiValue
AttributeSet
ToAttribute
globally unique
identifier
SBCS
varchar(255)
globally unique
identifier
globally unique
identifier
eCare Team
true/false
SCDS2
eCare Team
eCare Team
eCare Team
Relates an Attribute Set to an Attribute which belongs to that Set. An Attribute Set may contain one or more
Attributes; an Attribute may belong to one or more Attribute Sets.
AttributeSetID (FK)
(y)
Identifier of an Attribute Set
globally unique
eCare Team
identifier
AttributeID (FK)
(y)
Identifier of an Attribute
globally unique
eCare Team
identifier
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 128
Transformational Technologies Division
Table Name
Field
Candidate
Key
AttributeOrder
IsCurrent
Description/purpose
Data type
Source(s)
Where the Attribute occurs within the
Attribute Set
To mark an attribute as not in current
use within an attribute set (0 = not in
current use; 1 = in current use)
integer
eCare Team
true/false
eCare Team
ExtensionSet
Enables Process, Event and StatusEpisode to be keyed to the ExtensionTable entity while maintaining referential
integrity. ExtensionSetID is a foreign key on each of these entities.
ExtensionSetID
(y)
Identifier of the Extension Set
globally unique
eCare Team
identifier
AttributeSetID (FK)
Identifier or the Attribute Set to which
globally unique
eCare Team
the Extension Set relates
identifier
Extension
Table
Contains the value of an extension attribute for a given Process, Event or Status Episode.
ExtensionID
ExtensionSetID (FK)
AttributeID (FK)
AttributeCV
AttributeValue
AttributeBLOB
Occurrence
(y)
Identifier of an extension value
Identifier of the extension set to which
the extension value belongs
Identifier of the attribute for which the
extension value is a value
Where an attribute takes a value from a
controlled vocabulary, identifier of the
CV value
Where an attribute does not take a
value from a CV, the value (held as a
string)
Allows for the holding of attribute values
(e.g. images) that are not held as a
string
Where an attribute can have more than
one value for a given process, event or
episode type, incremented for each
occurrence
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
eCare Team
SBCS
varchar(1000)
eCare Team
BLOB
eCare Team
integer
eCare Team
eCare Team
eCare Team
eCare Team
12.4.2 Extension Attributes for Dynamic Entity Types
The data model supports the definition of an extension attribute set for a given process type,
event type or status episode type. An attribute set draws on a pool of extension attributes
which may belong to more than one set (so that e.g. Service belongs to the attribute sets for
both the “Service Provision” and “Request for Service(s)” Process Types).
The majority of extension attributes are restricted to a single occurrence for a given Process,
Event or Status Episode. A small number (e.g. ConcernFactorCV) admit of more than one
occurrence. These are flagged through the IsMultiValue attribute on the Attribute entity and
are identified in the following tables by “MV” in the left-hand column.
Following some change in data standards, an extension attribute may be deprecated within a
particular attribute set. Within the following table, deprecation is indicated by an “XXX OLD
XXX” in the left-hand column. Note that where the same extension attribute (e.g. the
attribute LocalAuthorityCV) occurs in several attribute sets, it may be deprecated in one but
remain current in the others.
Note that some of the “data types” in the tables in the following sub-sections are different
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 129
Transformational Technologies Division
from those used elsewhere in this Data Dictionary. They are drawn from the values in
CVExtensionDataType.
12.4.2.1
Extension attributes for Process Types
The following extension attributes are currently documented for Process Types.
Process type
Attribute
Description/purpose
Making an Inter-Agency Referral / Request for Assistance
Reason
The reason for the referral or request
RequestedAgencyName
The name of the agency to which the
referral is made or from which the
assistance is requested (though this
may also be recorded as a MAS
Organisation)
ReferralReceivedDate
The date the referral or request was
received
TargetDate
Target date for the request to be met
DateActioned
The date on which the request is
actually met
MV
ConcernFactorCV
From CVConcernFactor
Community Care Assessment and / or Care or Service Planning
LeadAgencyTypeCV
From CVAgencyType (renamed from
CVLeadAgencyType) – classifies lead
agency for the process as e.g. Health,
Social Work, etc. Only a relevant
subset of types is used.
LocalAuthorityCV
From CVLocalAuthority, which contains
a standard list of LAs – identifies the
local authority (if any) that has a main
(operational) involvement in the
assessment
HealthBoardCV
From CVHealthBoard, which contains a
standard list of HBs – identifies the
health board (if any) that has a main
involvement in the assment
Children’s Assessment and / or Care or Service Planning
MultiAgencyCV
From CVMultiAgency, which
distinguishes between multi-agency and
single agency assessments (where an
agency for this purpose is e.g. Health,
Education or Social Work rather than
any smaller unit within these)
ChildAssessment
FromCVChildAssessmentType
TypeCV
ChildAssessmentReasonCV
FromCVChildAssessmentReason
MV
date
date
date
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
Target end date for current assessment
The service that is provided
string
From CVLocalAuthority
globally unique
identifier
globally unique
identifier
FromCVCANonCompletionReason
ChildAssessmentReportCV
FromCVChildAssessmentReport
ChildAssessmentOutcomeCV
FromCVChildAssessmentOutcome
CPInvestigatingAgencyCV
string
string
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
date
CANonCompletionReasonCV
TargetEndDate
Service Provision
Service
Child Protection Investigation
LocalAuthorityCV
Data type
From CVCPInvestigatingAgency –
distinguishes investigations carried out
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 130
Transformational Technologies Division
Process type
Attribute
Description/purpose
CPInvestigationOutcomeCV
by Police and Social Work jointly and by
Police alone
From CVCPInvestigationOutcome
CPConferenceOutcomeCV
From CVCPConferenceOutcome
CPStrategyMeetingCV
From CVCPStrategyMeeting
CPStrategyMeetingDate
Child Protection Inquiry
LocalAuthorityCV
MV
Date and time of CP Strategy meeting
From CVLocalAuthority
NamedPersonConsultedCV
From CVAgencyType – only a relevant
subset of types is used (e.g. Health,
Education, Police, etc.)
FromCVNamedPersonConsulted
CPInquiryOutcomeCV
From CVCPInquiryOutcome
CPConferenceOutcomeCV
From CVCPConferenceOutcome
ConsultedAgencyCV
Request for Service(s)
Service
RequestedAgencyName
TargetDate
DateActioned
Request for Specialist Assessment
AssessmentType
RequestedAgencyName
TargetDate
DateActioned
Sharing a Concern
MV
ConcernFactorCV
Data type
globally unique
identifier
globally unique
identifier
globally unique
identifier
datetime
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
The service that is requested
The name of the agency from which the
service is requested (though this may
also be recorded as a MAS
Organisation)
Target date for the request to be met
The date on which the request is
actually met
string
string
The type of assessment that is
requested
The name of the agency from which the
assessment is requested (though this
may also be recorded as a MAS
Organisation)
Target date for the request to be met
The date on which the request is
actually met
string
From CVConcernFactor
globally unique
identifier
The name of the school, scheme or
institution in which a person is to be
placed (though this may also be
recorded as a MAS Organisation)
Date of placement, which may be earlier
than the end date for the placement
process
string
The name of the institution to which a
person is to be admitted (though this
may also be recorded as a MAS
Organisation)
Date of placement, which may be earlier
than the end date for the admission
process
string
The name of the institution from which a
person is to be discharged (though this
may also be recorded as a MAS
Organisation)
string
date
date
string
date
date
Placement
PlacementDestinationName
PlacementDate
date
Admission
AdmittingOrganisationName
AdmissionDate
date
Discharge
DischargingOrganisationName
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 131
Transformational Technologies Division
Process type
Attribute
Description/purpose
Data type
DischargeDestination
A textual attribute for the destination to
which the person is being discharged
(e.g. “home”)
Date of discharge, which may be earlier
than the end date for the discharge
process
string
Brief description of the topic under
discussion between professionals in
different agencies. Contributions will
usually be by means of Process Notes.
XXX OLD XXX Investigation or Enquiry (Child protection)
XXX OLD XXX CPEnquiryAgencyCV
From CVCPEnquiryAgency –
distinguishes investigations or enquiries
carried out by Police, Social Work or
jointly
XXX OLD XXX LocalAuthorityCV
From CVLocalAuthority
string
DischargeDate
Inter-Agency Discussion
Topic
XXX OLD XXX
CPEnquiryOutcomeCV
From CVCPEnquiryOutcome
XXX OLD XXX
CPConferenceOutcomeCV
From CVCPConferenceOutcome
12.4.2.2
date
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
Extension attributes for Event Types
The following extension attributes are currently documented for Event Types.
Event type
Attribute
Description/purpose
Data type
VisitTypeCV
From CVVisitType
HomeVisitAbortedCV
From CVHomeVisitAborted
AppointmentMade
1 = Appointment made; 0 = Appointment not
made
1 = Subject (e.g. child) was seen; 0 =
Subject was not seen
1 = Intended person was seen; 0 = Intended
person was not seen
Service provided in the course of the visit
globally unique
identifier
globally unique
identifier
true/false
Home visit
SubjectSeen
IntendedPersonSeen
ServiceProvided
Establishment visit
AppointmentReason
AppointmentAbortedCV
AppointmentMade
PlannedVisitCV
ProfessionalName
VisitorSeen
InstitutionName
XXX OLD XXX
NextAppointmentDate
VisitTypeCV
XXX OLD XXX
SubjectSeen
The reason for the appointment
From CVAppointmentAborted
1 = Appointment made; 0 = Appointment not
made
From CVPlannedVisit
For occasional one-off use when no
Professional record exists for the person
who saw the visitor(s)
Name of visitor(s) seen
The name (and, if required, other details) of
the establishment visited
Date of next appointment
From CVVisitType
1 = Subject (e.g. child) was seen; 0 =
Subject was not seen
true/false
true/false
string
string
globally unique
identifier
true/false
globally unique
identifier
string
string
string
date
globally unique
identifier
true/false
Children’s Hearing
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 132
Transformational Technologies Division
Event type
Attribute
Description/purpose
Data type
HearingDecisionCV
From CVHearingDecision
globally unique
identifier
InstitutionName
The name (and, if required, other identifying
details) of the hospital
string
From CVConcernFactor
globally unique
identifier
A & E attendance
XXX OLD XXX Expression of concern
XXX OLD XXX
ConcernFactorCV
12.4.2.3
Extension attributes for Status Episode Types
The following extension attributes are currently documented for Status Episode Types.
Status episode type
Attribute
Description/purpose
Data type
MaritalStatusCV
MaritalStatus
VerificationCV
From CVMaritalStatus, which lists valid
marital statuses
From CVVerificationLevel, which lists GDSC
verification levels
globally unique
identifier
globally unique
identifier
EmploymentStatus
CV
From CVEmploymentStatus, which lists
valid employment statuses
globally unique
identifier
StudentStageCV
From CVStudentStage
globally unique
identifier
ChildSocialWork
StatusCV
From CVChildSocialWorkStatus, which lists
valid statutory bases for the provision of
Social Work services to a child
Date on which legal status is due to be
reviewed
globally unique
identifier
From CVLocalAuthority
globally unique
identifier
globally unique
identifier
Marital status
Employment status
Educational attendance
Legal status
ReviewDate
Looked after or accommodated episode
LocalAuthorityCV
LookedAfterTypeCV
Child protection registration
RegistrationCategoryCV
LocalAuthorityCV
XXX OLD XXX Developmental or medical status
XXX OLD XXX
ChildhoodDifficulty
CV
XXX OLD XXX
SeverityStatusCV
XXX OLD XXX
OutlookCV
XXX OLD XXX
EquipmentOrAids
XXX OLD XXX
AllergenCV
XXX OLD XXX
XXX OLD XXX
AllergyEffects
IsDiagnosed
From CVLookedAfterType
From CVRegistrationCategory
From CVLocalAuthority
From CVChildhoodDifficulty, which lists
factors pertinent to a child’s development or
health
From CVSeverityStatus (required for
Mobility and Personal Care in the first
instance)
From CVOutlook (required for Mobility and
Personal Care in the first instance)
In the case of a mobility problem, any
equipment or aids that are in use
From CVAllergen, which lists types of
allergen (required for Known Allergies) –
can have more than one occurrence
The effects of the allergy
1 = Condition is medically diagnosed; 0 =
Condition is not medically diagnosed
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
date
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
globally unique
identifier
string
globally unique
identifier
string
true/false
Version: 1.4 Release
28/03/2008
Page 133
Transformational Technologies Division
Status episode type
Attribute
Description/purpose
Data type
XXX OLD XXX
IdentificationDate
date
XXX OLD XXX
ProfessionalName
Date of assessment or diagnosis (which
may be later than start date for condition)
Name (and any other required details) of the
Professional who undertook the assessment
or made the diagnosis
string
12.4.3 Summary Relationship of SCDS2 Datasets to Data Model
The following table summarises the relationship between the data items in the two SCDS2
Children’s Datasets and the entities and attributes in the Data Model.
SCDS2 data item
Entity / primary attribute
Type / extension attribute
Social Work Legal Status
(Children)
Social Work Legal Status
(Children)
Start date
End date
Review date
StatusEpisode
Legal status
Current Child Protection
Registration
Registration category
Start date
StatusEpisode
Child Protection History
Process
Date inquiry / investigation began
Date inquiry / investigation
concluded
Local authority
Agency consulted in course of
inquiry
Named person consulted?
Outcome of previous child
protection inquiry
Investigation carried out by
Child Protection Strategy meeting
held?
Date and time of Child Protection
Strategy meeting
Outcome of previous child
protection investigation
Outcome of Child Protection
Conference
ProcessStartDate
ProcessEndDate
ChildSocialWorkStatusCV
ValidStart
ValidEnd
ReviewDate
Child protection registration
RegistrationCategoryCV
ValidStart
Child Protection Investigation;
Child Protection Inquiry
LocalAuthorityCV
ConsultedAgencyCV
NamedPersonConsultedCV
CPInquiryOutcomeCV
CPInvestigatingAgencyCV
CPStrategyMeetingCV
CPStrategyMeetingDate
CPInvestigationOutcomeCV
CPConferenceOutcomeCV
StatusEpisode
Previous Child Protection
registration category
Local authority
Start date
End date
Date(s) of previous at Accident and
Emergency Department
Name of Hospital attended
Child protection registration
RegistrationCategoryCV
LocalAuthorityCV
ValidStart
ValidEnd
Event
EventDate
A & E Attendance
InstitutionName
Child Protection Investigation;
Child Protection Inquiry
Process
Current Child Protection inquiry /
ProcessStartDate
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 134
Transformational Technologies Division
SCDS2 data item
Entity / primary attribute
Type / extension attribute
investigation start date
Child potentially at risk from a
specific individual
SubjectWarningFlag
See section 3.6.3 for further
details
Child affected by Disability
Education establishment details
Type of establishment
Name of education establishment
Address of education
establishment
Education establishment identifier
Admission date
End date
Candidate number
Children Reporter’s
Administration Involvement
Date of last Children’s Hearing
Date of first Hearing
Date of first Hearing in this episode
Decision of last Hearing
Date of next Hearing
SubjectAffectingDisability
Family member illness /
disability type
Organisation
OrganisationTypeCV
OrganisationName
Link to Address through
OrganisationToAddress
OrganisationReference
Identifier
StatusEpisode
ValidStart on the first entry for
the education establishment
ValidEnd on the final entry for
the education establishment
PersonReference
Identifier
AffectingDisabilityCV
Educational attendance
Children’s Hearing
Event
EventDate
EventDate
EventDate
HearingDecisionCV
EventDate
Link through PersonToEvent
Name of Reporter
Concerns expressed about a
child
Date of expression of concern
about a child
Concern Factors
Concern Description
Process
Expression of concern
Person who recorded the concern
Link through
PersonToProcessHistory
ProcessStartDate
ConcernFactorCV
ProcessDescription
Name
Contact Telephone number
Looked after or accommodated
episodes
Name of local authority
Whether or not accommodated
Start date
End date
StatusEpisode
Student stage
Student stage
Date child registered at each date
End date for stage
StatusEpisode
Request for assistance / referral
Process
Looked after or accommodated
episode
LocalAuthorityCV
LookedAfterTypeCV
ValidStart
ValidEnd
Educational attendance
StudentStageCV
ValidStart
ValidEnd
Making an Inter-agency
Referral / Request for
Assistance
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 135
Transformational Technologies Division
SCDS2 data item
Concern Factors
Concern description
Date request sent
Date request received
Reason for request
Action taken
Entity / primary attribute
Type / extension attribute
ConcernFactorCV
ProcessDescription
ProcessStartDate
ReferralReceivedDate
Reason
ProcessNote
NoteText
Link through
PersonToProcessHistory
Name of person requesting
assistance
Name of person receiving request
Agency requesting assistance
Agency receiving request
Link through
PersonToProfessional
Case allocated
Child allocated to
Child allocated date
Current and Previous
Assessment Details
Nature of integrated assessment
Type of assessment
Reason for non-completion of
assessment
Reason for assessment
Date assessment started
Date assessment completed
Target end date for current
assessment
Reports available
Outcome
Children’s Assessment and / or
Care or Service Planning
MultiAgencyCV
ChildAssessmentTypeCV
CANonCompletionReasonCV
Process
ChildAssessmentReasonCV
ProcessStartDate
ProcessEndDate
TargetEndDate
ChildAssessmentReportCV
ProcessNote
NoteText
Link through
PersonToProcessHistory
Assessment coordinator
Individuals taking part in
assessment
Record of home visits by
professionals
Nature of visit
Aborted visit reason
Date of visit
Time of visit
Date of planned visit
Appointment made
Intended person seen
Service provided
Subject seen
Event
Home visit
VisitTypeCV
HomeVisitAbortedCV
EventDate
EventDate
EventDate
AppointmentMade
IntendedPersonSeen
ServiceProvided
SubjectSeen
Link through PersonToEvent
Name of professional
Agency carrying out visit
Person visited
Address visited
Record of appointments and
visits at establishments by the
child and / or their carers
Reason for visit or appointment
Aborted appointment reason
Event
Establishment visit
AppointmentReason
AppointmentAbortedCV
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 136
Transformational Technologies Division
SCDS2 data item
Entity / primary attribute
Date of appointment
Time of appointment
Date of next appointment
Name of the establishment where
the appointment took place
Address of the establishment
where the appointment took place
Appointment made?
Unplanned visit?
Visitor(s) seen (if need to clarify)
Seen by
EventDate
EventDate
Type / extension attribute
NextAppointmentDate
InstitutionName
InstitutionName
AppointmentMade
PlannedVisitCV
VisitorSeen
ProfessionalName
Link through PersonToEvent
Visitor(s)
12.5 Data Dictionary for Forms
This part of the Data Dictionary corresponds to the data model extract shown in section 8.3.
It excludes those entities relevant to Forms (in particular, InterfaceSystem and Process) that
have already been documented.
Table Name
Field
Form
From the user’s perspective, a particular instance of a Form – i.e. conjoining a set of pre-defined questions with the
associated answers for a given person or case. Within the MAS, however, a Form is always now expressed
through a series of FormState instances (so that there must be one instance for the state of the Form as it was
originally stored on the MAS, with a further instance for each subsequent occasion of editing and republication by a
partner agency).
FormID
(y)
Identifier of the Form
globally unique
eCare Team
identifier
FormVersionID (FK)
Associates the Form with the Form
globally unique
eCare Team
Version to which it belongs (i.e. the
identifier
Form Version that contributes the
questions)
FormStatusLCV
From LCVFormStatus. Locally defined
globally unique
eCare Team
status (e.g. “incomplete”).
identifier
FormStartDate
large DateTime
eCare Team
FormCompletionDate
large DateTime
eCare Team
ProcessTo
Form
Relates the Form to a Process.
ProcessID
(y)
FormID
(y)
ProcessToFormCV
FormState
Candidate
Key
Description/purpose
Identifies the Process to which a Form
is related
Identifies the Form
From CVProcessToForm, which
distinguishes between the case where a
Form is created within a Process,
where it is an updateable input to a
Process, and where it is a read-only
input to a Process
Data type
globally unique
identifier
globally unique
identifier
globally unique
identifier
Source(s)
eCare Team
eCare Team
eCare Team
The FormState entity has been interposed between the Form entity and the lower level entities (FormSection,
FormGrouping and Response) which contain the Form detail. Whenever a Form is stored on the MAS, and on
each occasion of its later editing, a FormState instance is recorded on the MAS. It is the FormState, not the Form,
that relates to the form detail.
FormStateID
(y)
Identifier of the FormState
globally unique
eCare Team
identifier
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 137
Transformational Technologies Division
Table Name
Field
Candidate
Key
FormID (FK)
EditDate
EditSystemID (FK)
ContactProfessional
FormLocking
History
Data type
Source(s)
Associates the FormState with the
Form to which it belongs
The date on which the FormState was
stored on the MAS
Associates the FormState with the
InterfaceSystem from which the
FormState originated
Identifies the professional who should
be contacted in respect of this occasion
of editing; in the case of the original
FormState, this is likely to be the lead
professional within the originating
agency; in the case of a subsequent
addition to the Form, it might perhaps
be a specialist professional within
another agency
globally unique
identifier
large DateTime
eCare Team
globally unique
identifier
eCare Team
SBCS
varchar(255)
eCare Team
globally unique
identifier
globally unique
identifier
globally unique
identifier
eCare Team
SBCS
varchar(50)
eCare Team
globally unique
identifier
large DateTime
eCare Team
large DateTime
eCare Team
eCare Team
Enables a Form to be locked for editing.
HistoryID
FormID (FK)
InterfaceSystemID
(FK)
SystemReference
LockingStatusCV
ValidStart
ValidEnd
FormType
Description/purpose
(y)
Identifier of the Locking History record
Associates the record with the Form to
which it belongs
Where a Form is locked, associates the
record with the Interface System which
has locked it
Permits an Interface System to pass to
MAS an identifier or reference of its
choice (which could e.g. identify the
user who is editing a Form)
From CVLockingStatus – indicates
whether the Form is locked or unlocked
The start datetime for the locking status
in question
The end datetime for the locking status
– equates to UC for the current record
Any generally recognised type of form, which may go through a series of different versions.
FormTypeID
(y)
Identifier of the Form Type
globally unique
identifier
Name
Short name of the Form Type
SBCS
varchar(255)
Description
SBCS
varchar(500)
FormTypeCode
A “public” identifier for the Form Type,
SBCS
unique within the Data Sharing
varchar(100)
Partnership (or within the wider “sharing
domain” if form sharing extends across
DSP boundaries)
FormTypeStatusCV
From CVFormTypeStatus
globally unique
identifier
Creator
The entity primarily responsible for
SBCS
creating the content of the Form Type
varchar(255)
DateCreated
large DateTime
Publisher
The entity responsible for making the
SBCS
Form Type available
varchar(255)
SubjectCategory
A Government Category List (GCL)
SBCS
topic to describe the content of the
varchar(255)
Form Type
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
eCare Team
eCare Team
eCare Team
eCare Team
eCare Team
eCare Team
eCare Team
eCare Team
e-GMS
e-GMS
e-GMS
e-GMS
Version: 1.4 Release
28/03/2008
Page 138
Transformational Technologies Division
Table Name
Field
FormVersion
The version of a Form Type that is current over a given period. A new version arises whenever the form definition
is changed (but not when there is only a change to a format entity or to CalculationProcedure). [The start and end
dates are now optional, for use when the replacement of an old version by a new version is synchronised across all
the agencies using a Form Type. If introduction of the new version is staggered, the start and end dates make little
sense.]
FormVersionID
(y)
Identifier of the Form Version
globally unique
eCare Team
identifier
FormTypeID (FK)
Associates the Form Version with the
globally unique
eCare Team
Form Type to which it belongs
identifier
Version
A “public” identifier for the Form
SBCS
eCare Team
Version, unique within the Form Type
varchar(100)
ValidStart
The first day from which the Form
large DateTime
eCare Team
Version is valid (for new data capture)
ValidEnd
The first day from which the Form
large DateTime
eCare Team
Version ceases to be valid (for new
data capture) – where a new version is
substituted, ValidStart for the new
version should be equal to ValidEnd for
the old version – for current version,
ValidEnd equates to UC
Description
SBCS
eCare Team
varchar(4000)
Section
A top level grouping of Questions within a Form Version. A Section may be capable of being used more than once
within a given Form.
SectionID
(y)
Identifier of the Section
globally unique
eCare Team
identifier
FormVersionID (FK)
Associates the Section with the Form
globally unique
eCare Team
Version to which it belongs
identifier
SectionNumber
Incremented for each Section within
integer
eCare Team
Form Version
SectionTitle
Display title for Section
SBCS
eCare Team
varchar(2000)
SectionDescription
Further description of Section
SBCS
eCare Team
varchar(4000)
IsMultipleSection
1 = Section can be used more than
true/false
eCare Team
once within Form; 0 = Section cannot
be used more than once within Form
SectionTypeCV
From CVSectionType, which
globally unique
eCare Team
distinguishes between Sections that
identifier
record metadata items and Sections
that record form content data items
FormSection
A grouping of Responses at the same level as a Section. If the Section is capable of multiple occurrences, there
may be more than one such grouping for the Section within a given Form – in which case Occurrence will be
incremented.
FormSectionID
(y)
Identifier of the Form Section
globally unique
eCare Team
identifier
FormStateID (FK)
Associates the Form Section with the
globally unique
eCare Team
Form State to which it belongs
identifier
SectionID (FK)
Associates the Form Section with the
globally unique
eCare Team
Section to which it belongs
identifier
Occurrence
Incremented for each occurrence of the
integer
eCare Team
Section within the Form
Section
Format
Presentational aspects of a Section, valid within a given System.
SectionFormatID
SectionID (FK)
InterfaceSystemID
(FK)
Candidate
Key
(y)
Description/purpose
Identifier of the Section Format
Associates the Section Format with the
Section to which it belongs
Associates the Section Format with the
Interface System to which it belongs
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Data type
globally unique
identifier
globally unique
identifier
globally unique
identifier
Source(s)
eCare Team
eCare Team
eCare Team
Version: 1.4 Release
28/03/2008
Page 139
Transformational Technologies Division
Table Name
Field
Candidate
Key
IsDefault
SectionHelpText
Section
FormatFlag
Description/purpose
Data type
Source(s)
Indicates that the Section Format is a
default format for the Scheme as a
whole – subject to the constraint that
InterfaceSystemID is null
Help text for Section
true/false
eCare Team
SBCS
varchar(4000)
eCare Team
globally unique
identifier
globally unique
identifier
eCare Team
Allows further formatting attributes to be added for a Section.
SectionFormatID
(FK)
FormatAttributeLCV
(y)
Identifier of the Section Format
(y)
From LCVFormatAttribute
eCare Team
Question
Grouping
A second level grouping of Questions below a Section within a Form Version. A Question Grouping may be
capable of being used more than once within a given Section.
QuestionGroupingID
(y)
Identifier of the Question Grouping
globally unique
eCare Team
identifier
SectionID (FK)
Associates the Question Grouping with
globally unique
eCare Team
Section to which it belongs
identifier
QuestionGrouping
Incremented for each Question
integer
eCare Team
Order
Grouping within Section
QuestionGrouping
Text used for Question Grouping
SBCS
eCare Team
Text
varchar(4000)
IsMultipleGrouping
1 = Question Grouping can be used
true/false
eCare Team
more than once within Section; 0 =
Question Grouping cannot be used
more than once within Section
IsHeader
1 = QuestionGroupingText is intended
true/false
eCare Team
for display as a higher-level header; 0 =
QuestionGroupingText is not for display
(i.e. is included as documentation only)
Form
Grouping
A grouping of Responses at the same level as a Question Grouping. If the Question Grouping is capable of
multiple occurrences, there may be more than one such grouping for the Question Grouping within a given Form
Section – in which case GroupingOccurrence will be incremented.
FormGroupingID
(y)
Identifier of the Form Grouping
globally unique
eCare Team
identifier
FormSectionID (FK)
Associates the Form Grouping with the
globally unique
eCare Team
Form Section to which it belongs
identifier
QuestionGroupingID
Associates the Form Grouping with the
globally unique
eCare Team
(FK)
Question Grouping to which it belongs
identifier
GroupingOccurrence
Incremented for each occurrence of the
integer
eCare Team
Question Grouping within the Form
Section
Question
Grouping
Format
Presentational aspects of a Question Grouping, valid within a given System.
QuestionGrouping
FormatID
QuestionGroupingID
(FK)
InterfaceSystemID
(FK)
IsDefault
QuestionGrouping
HelpText
(y)
Identifier of the Question Grouping
Format
Associates the Question Grouping
Format with the Question Grouping to
which it belongs
Associates the Question Grouping
Format with the Interface System to
which it belongs
Indicates that the Section Format is a
default format for the Scheme as a
whole – subject to the constraint that
InterfaceSystemID is null
Help text for Question Grouping
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
globally unique
identifier
globally unique
identifier
eCare Team
globally unique
identifier
eCare Team
true/false
eCare Team
SBCS
varchar(4000)
eCare Team
eCare Team
Version: 1.4 Release
28/03/2008
Page 140
Transformational Technologies Division
Table Name
Field
Question
Grouping
FormatFlag
Allows further formatting attributes to be added for a Question Grouping.
QuestionGrouping
FormatID (FK)
FormatAttributeLCV
Candidate
Key
(y)
(y)
Description/purpose
Identifier of the Question Grouping
Format
From LCVFormatAttribute
Data type
Source(s)
globally unique
identifier
globally unique
identifier
eCare Team
eCare Team
Question
A question asked in a Form. It will occur more than once in the Form if (but only if) the Section or Question
Grouping to which it belongs is itself repeated in the Form.
QuestionID
(y)
Identifier of the Question
globally unique
eCare Team
identifier
QuestionGroupingID
Associates the Question with the
globally unique
eCare Team
(FK)
Question Grouping to which it belongs
identifier
ValidationTypeID (FK)
Associates the Question with the
globally unique
eCare Team
Question Validation Type (if any) to
identifier
which it belongs
CalculationID (FK)
Associates the Question with the
globally unique
eCare Team
Calculation (if any) to which it belongs
identifier
ResponseCVID (FK)
Identifies the Controlled Vocabulary (if
globally unique
eCare Team
any) from which a response to the
identifier
Question can be selected
QuestionDataTypeCV
From CVQuestionDataType, which
globally unique
eCare Team
contains a list of data types (applicable
identifier
to the expected response value when
not a CV value)
QuestionSourceCV
Identifies the source of the Question
globally unique
eCare Team
(e.g. a national dataset)
identifier
QuestionCode
A “public” identifier for the Question
SBCS
eCare Team
which must be unique within a given
varchar(255)
FormVersion, but which can also be
used to track what is in effect the same
question through successive Versions
of a FormType
MandatoryAnswerCV
From CVMandatoryAnswer
globally unique
eCare Team
identifier
IsMultiAnswer
1 = Question can attract more than one
true/false
eCare Team
Response (e.g. more than one selection
from a list); 0 = Question can only
attract a single Response
QuestionOrder
Incremented for each Question within
integer
eCare Team
Question Grouping
QuestionText
Text used for Question (i.e. the
SBCS
eCare Team
question itself)
varchar(3000)
QuestionDescription
A description of the Question
SBCS
eCare Team
varchar(3000)
HeaderCV
From CVHeader
globally unique
eCare Team
identifier
Response
The answer to a Question on a Form. If the Question expects a selection from a Controlled Vocabulary, the
identifier for the selected value will be stored in ResponseCV. If the Question expects a free text response, it will
be stored in ResponseText.
ResponseID
(y)
Identifier of the Response
globally unique
eCare Team
identifier
QuestionID (FK)
Associates the Response with the
globally unique
eCare Team
Question to which it belongs
identifier
FormGroupingID (FK)
Associates the Response with the Form
globally unique
eCare Team
Grouping to which it belongs
identifier
ResponseCV
Where the Question is associated with
globally unique
eCare Team
a Controlled Vocabulary, associates the
identifier
Response with a CV Value from that
Controlled Vocabulary
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 141
Transformational Technologies Division
Table Name
Field
Candidate
Key
ResponseText
Question
Format
Data type
Source(s)
Where the Question is not associated
with a Controlled Vocabulary, a free text
response is stored here
SBCS
varchar(4000)
eCare Team
globally unique
identifier
globally unique
identifier
globally unique
identifier
true/false
eCare Team
globally unique
identifier
SBCS
varchar(4000)
eCare Team
globally unique
identifier
globally unique
identifier
eCare Team
Presentational aspects of a Question, valid within a given System.
QuestionFormatID
(y)
QuestionID (FK)
Identifier of the Question Format
ControlTypeLCV
Associates the Question Format with
the Question to which it belongs
Associates the Question Format with
the Interface System to which it belongs
Indicates that the Section Format is a
default format for the Scheme as a
whole – subject to the constraint that
InterfaceSystemID is null
From LCVControlType
QuestionHelpText
Help text for Question
InterfaceSystemID
(FK)
IsDefault
Question
FormatFlag
Description/purpose
eCare Team
eCare Team
eCare Team
eCare Team
Allows further formatting attributes to be added for a Question.
QuestionFormatID
(FK)
FormatAttributeLCV
(y)
Identifier of the Question Format
(y)
From LCVFormatAttribute
eCare Team
Question
Validation
Type
Where a Question is not associated with a Controlled Vocabulary, enables a validation rule to be applied to a
Response – e.g. that it must comply with a date, numeric or postcode formatting mask. The validation may be
effected by comparison with a regular expression or through a Calculation.
ValidationTypeID
(y)
Identifier of the Question Validation
globally unique
eCare Team
Type
identifier
CalculationID (FK)
Associates the Question Validation
globally unique
eCare Team
Type with the Calculation (if any) to
identifier
which it belongs
Description
Short description of the Question
SBCS
eCare Team
Validation Type
varchar(50)
RegularExpression
A regular expression (e.g. a formatting
SBCS
eCare Team
mask) that is to be applied to a
varchar(4000)
response to a Question
ExceptionMessage
A standard exception message to be
SBCS
eCare Team
used if a response does not satisfy the
varchar(255)
validation rule
Question
Controller
Allows the display or mandatory status of Questions to be dynamically determined (in conjunction with
DynamicDisplay attribute on Question Format and MandatoryAnswerCV on Question). For simple in-Form
conditions (i.e. conditions that relate to a single CV response to a single earlier question), no calculation is used.
For other sorts of condition, Calculation is invoked (through CalculationID). Neither the Controlling Question nor
the Dependent Question can fall within a “repeatable” Section or Question Grouping.
QuestionController
(y)
Identifier of the Question Controller
globally unique
eCare Team
ID
identifier
ControllerTypeCV
From CVControllerType – type can be
globally unique
eCare Team
display only, mandatory status only, or
identifier
both
ControllingQuestionID
Associates the Question Controller with
globally unique
eCare Team
(FK)
the Controlling Question to which it
identifier
belongs
DependentQuestionID
Associates the Question Controller with
globally unique
eCare Team
(FK)
the Dependent Question whose display
identifier
(or mandatory status) it determines
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 142
Transformational Technologies Division
Table Name
Field
Candidate
Key
ResponseCV
CalculationID (FK)
Description/purpose
Data type
Source(s)
Where a Controlling Question is
associated with a Controlled
Vocabulary, associates the Question
Controller with a CV Value from that
Controlled Vocabulary
Associates the Question Controller with
the Calculation (if any) to which it
belongs – if this has a value, then
ResponseCV will not have a value
globally unique
identifier
eCare Team
globally unique
identifier
eCare Team
Calculation
Where the Response to a Question is to be calculated rather than input, links the Question to a System-specific
procedure which performs the calculation. Can also be employed in connection with Question Controller and
Question Validation Type.
CalculationID
(y)
Identifier of the Calculation
globally unique
eCare Team
identifier
Description
Explanation of what the calculation is
SBCS
eCare Team
varchar(255)
Calculation
Procedure
Allows different systems to use different procedures to perform the same Calculation
CalculationProcedure
ID
CalculationID (FK)
(y)
InterfaceSystemID
(FK)
IsDefault
Calculation
Identifier of the Calculation Procedure
Associates the Calculation Procedure
with the Calculation to which it belongs
Associates the Calculation Procedure
with the Interface System to which it
belongs
Indicates that the Calculation Procedure
is a default procedure for the Scheme
as a whole
Either an external reference to the
calculation or the calculation procedure
itself
globally unique
identifier
globally unique
identifier
globally unique
identifier
eCare Team
true/false
eCare Team
SBCS
varchar(4000)
eCare Team
eCare Team
eCare Team
12.6 Data Dictionary for Auditing
This part of the Data Dictionary corresponds to the data model extract shown in section 9.4.
It is now (Version 1.4 of this document) restricted to Auditing. It excludes those entities
relevant to Auditing that have already been documented within this document.
Note also that of the entities that have been removed from this section, the following are now
documented in the Hub Data Model document:
 AuthorisationProfile
 AuthorisationProfileRole
 SystemToken
Although also transferred to the Hub, the InterfaceSystem entity is still documented in section
12.2 above. The InterfaceSystemFlag entity has been discarded.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 143
Transformational Technologies Division
Table Name
Field
AuditLog
An Audit Log entry exists for every MAS update (whether or not mediated through the Messaging system).
AuditLogID
(y)
Identifier of the Audit Log
globally unique
eCare Team
identifier
InterfaceSystemID
Associates the Audit Log with the
globally unique
eCare Team
(FK)
Interface System to which it belongs
identifier
AuditReference
Permits an Interface System to pass to
SBCS
eCare Team
MAS an audit identifier or reference of
varchar(255)
its choice (which could e.g. identify the
originating user)
AuditTimestamp
DateTime for Audit Log entry
large DateTime
eCare Team
MessageLog
Contains entry for each incoming or outgoing Message.
MessageLogID
(y)
Identifier of the Message Log entry
within MAS
MessageSequence
A sequential number that would allow
an administrator explicitly to view the
Message Log in the sequence that the
records were created in the database
(required because the accuracy of the
MessageTimestamp might not be
sufficient for this purpose)
InterfaceSystemID
Associates the Message Log entry with
(FK)
the Interface System to which it belongs
IncomingMessageID
Unique identifier for Message in
Interface System (passed to MAS with
the Message)
Message
The Message itself
MessageTypeCV
From CVMessageType, which classifies
Message as request, response, etc.
MessageTimestamp
Date for Message Log entry
AuditLogID (FK)
Associates the Message Log entry with
the Audit Log entry (if any) to which it
belongs
[Table to be
audited]
Candidate
Key
Description/purpose
Data type
Source(s)
globally unique
identifier
integer
eCare Team
globally unique
identifier
SBCS
varchar(50)
eCare Team
BLOB
globally unique
identifier
large DateTime
globally unique
identifier
eCare Team
eCare Team
eCare Team
eCare Team
eCare Team
eCare Team
Additional attributes to be added to all entities liable to be updated by an Interface System.
AuditLogID
ModifiedDate
Associates the table entry with the Audit
Log entry pertaining to the latest update
The MAS latest update date
globally unique
identifier
large DateTime
eCare Team
eCare Team
12.7 Data Dictionary for Notifications
This part of the Data Dictionary is now (Version 1.4 of this document) empty, following the
transfer of Notifications to the Hub. The Data Dictionary for the Notifications entities can be
seen in section 7 of the Hub Data Model document [11]. For the record, the transferred
entities are:
 Notification
 NotificationMatchIndex
 NotificationTarget
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 144
Transformational Technologies Division
12.8 Extension attributes for Subject Warning Flags (CPMs)
As discussed in section 11, Child Protection Messages will be reflected in the MAS as
Subject Warning Flags. Extension attributes will be used to hold those CPM data items that
are not already attributes of the SubjectWarningFlag entity. These extension attributes are
currently as shown in the following table. For documentation notes, see section 12.4.2
above. Further information about the CPM extension attributes can be found in “Child
Protection Messaging: Message Content & Guidance”, published by the Scottish
Government’s Transformational Technologies Division [12].
Risk type
Attribute
All CPMs (i.e. Risk Types 3 to 8)
MessageHeader1
MessageHeader2
MessageInstruction
StandbyAgency
StandbyPhoneNumber
“Linked child” CPM (i.e. Risk Types 7 and 8)
SameAddress
Description/purpose
Data type
The part of the main CPM that precedes
the name of the child
The part of the main CPM (if any) that
comes after the name of the child
The instruction to recipients of the CPM
Address details for out of hours /
standby team
Phone number for out of hours / standby
team
string
1 = linked child lives at the same
address as the primary child (or at least
one of the primary children if there is
more than one); 0 = linked child does not
live at same address as any of the
primary children
true/false
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
string
string
string
string
Version: 1.4 Release
28/03/2008
Page 145
Transformational Technologies Division
13. Controlled Vocabularies
13.1 Current CVs
The following table brings together (in alphabetical order) the current Controlled Vocabularies
for all the Data Dictionaries in this document. It includes the CVs for extension attributes for
Processes, Events and Status Episodes.
National CVs (nationally mandated CVs where the values are also mandated) have codes
beginning SN- if they are mandated by the Social Care Data Standards Project and EN- if
they are mandated by the eCare Programme (e.g. SN-ACC for CVAccommodationType, ENCDT for CVContactDetailType). LCVs (nationally mandated CVs where the values are
locally determined) have codes beginning SL(ppp)- or EL(ppp)-, where ppp is a three-letter
acronym identifying a local eCare Partnership (e.g. SL(ppp)-PRR for LCVProfessionalRole,
EL(ppp)-RFT for LCVReferenceType).
A change in data standards may result in the deprecation of either a CV value or an entire
CV. As explained in section 3.2, the value or CV can be flagged as no longer in standard
use. Within the following table, deprecation of a particular CV value within a CV that is itself
still current is indicated by an “XXX OLD XXX” in the left-hand column. Deprecated CVs
have been removed from this table, but are documented in section 13.2 below.
Note that the following CVs are now (Version 1.4 of this document) documented in the Hub
Data Model document, along with the attributes to which they relate:
 CVAccessStatus
 CVAuthorisationRole
 CVNotificationType
 LCVReferenceType
 CVTokenType
Controlled
Vocabulary
Code
CV
Accommodation
Type
SN-ACC
Value
SN-ACC-01
Homeless
SN-ACC-01-HM01
Homeless: Homelessness Type unspecified
SN-ACC-01-HM02
Homeless: Rough Sleepers
SN-ACC-01-HM03
Homeless: Other Roofless
SN-ACC-01-HM04
Homeless: Squatting
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 146
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
SN-ACC-01-HM05
Homeless: Emergency/Temporary Accommodation
SN-ACC-01-HM06
Homeless: Women’s refuges
SN-ACC-01-HM07
Homeless: Bed & Breakfast
SN-ACC-01-HM08
Homeless: Young People asked to leave
SN-ACC-01-HM09
Homeless: Unable to secure entry
SN-ACC-02
Mainstream
SN-ACC-02-MA01
Mainstream: Unspecified
SN-ACC-02-MA02
Mainstream: No adaptations
SN-ACC-02-MA03
Mainstream: With adaptations
SN-ACC-02-MA04
Mainstream: Barrier Free Housing/Lifetime Homes
SN-ACC-03
Special housing
SN-ACC-03-SP01
Special housing: Unspecified
SN-ACC-03-SP02
Special housing: Amenity Housing
SN-ACC-03-SP03
Special housing: Wheelchair Accessible Housing
SN-ACC-03-SP04
Special housing: Ambulant Disabled Housing
SN-ACC-03-SP05
Special housing: Other specially adapted housing
SN-ACC-04
Sheltered housing
SN-ACC-04-SH01
Sheltered housing: Unspecified
SN-ACC-04-SH02
Sheltered housing: Extra Care Housing
SN-ACC-04-SH03
Sheltered housing: Very Sheltered Housing
SN-ACC-04-SH04
SN-ACC-04-SH05
Sheltered housing: Integrated Very Sheltered Housing/Shared
Housing Plus
Sheltered housing: Other Sheltered Housing
SN-ACC-05
Supported accommodation
SN-ACC-05-SU01
Supported accommodation: Unspecified
SN-ACC-05-SU02
Supported accommodation: Hostels
SN-ACC-05-SU03
Supported accommodation: Staffed Group Hostels
SN-ACC-05-SU04
Supported accommodation: Core and Cluster
SN-ACC-05-SU05
Supported accommodation: Foyers
SN-ACC-05-SU06
Supported accommodation: Supported tenancies
SN-ACC-05-SU07
Supported landlady/resident caretaker schemes
SN-ACC-05-SU08
Supported accommodation: Specialist Facilities
SN-ACC-05-SU09
Supported accommodation: Other Supported Accommodation
SN-ACC-06
Specialist rehabilitation units
SN-ACC-06-RU01
Specialist rehabilitation units: Unspecified
SN-ACC-06-RU02
Specialist rehabilitation units: Addiction Rehabilitation Units
SN-ACC-06-RU03
SN-ACC-07
Specialist rehabilitation units: Mental Health Rehabilitation
Facilities
Registered adult care homes
SN-ACC-07-AC01
Registered adult care homes: Unspecified
SN-ACC-07-AC02
SN-ACC-07-AC03
Registered adult care homes: Registered Care Homes (single
status homes)
Registered adult care homes: Nursing Homes
SN-ACC-07-AC04
Registered adult care homes: Residential Care Homes
SN-ACC-08
Registered child care accommodation
SN-ACC-08-CC01
Registered child care accommodation: Unspecified
SN-ACC-08-CC02
Registered child care accommodation: Residential Homes for
children
Registered child care accommodation: Residential Schools
SN-ACC-08-CC03
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 147
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
SN-ACC-08-CC04
Registered child care accommodation: Secure Accommodation
SN-ACC-09
NHS facilities / hospitals
SN-ACC-09-NH01
NHS facilities / hospitals: Unspecified
SN-ACC-09-NH02
SN-ACC-10
NHS facilities / hospitals: Long Stay NHS Facility/Hospital
Learning Disability
NHS facilities / hospitals: Long Stay NHS Facility/Hospital
General Psychiatry
NHS facilities / hospitals: Long Stay NHS Facility/Hospital
Psychiatry of Old Age
NHS facilities / hospitals: Long Stay NHS Facility/Hospital
Geriatric Medicine
Penal institutions
SN-ACC-10-PE01
Penal institutions: Unspecified
SN-ACC-10-PE02
Penal institutions: Prison
SN-ACC-10-PE03
Penal institutions: Young Offenders Institution
SN-ACC-10-PE04
Penal institutions: Secure (forensic) locked psychiatric facility.
SN-ACC-11
Independent hospitals
SN-ACC-12
Independent hospices
SN-ACC-13
Mobile accommodation
SN-ACC-99
Not known
SN-ACC-09-NH03
SN-ACC-09-NH04
SN-ACC-09-NH05
CVAddressType
CVAffecting
Disability
–
–
–
SN-ADD
SN-ADD-00
None
SN-ADD-01
Normal domicile (home) address
SN-ADD-02
Alternative contact address
SN-ADD-03
Non-domicile address
SN-ADD-04
Invoiced address
SN-ADD-05
Employer’s address
SN-ADD-06
Temporary domicile address
SN-ADD-07
Professional contact address
SN-ADD-08
No fixed abode
SN-AFD
SN-AFD-PD01
The Children (Scotland) Act 1995 creates duties in regard to a
child who is “affected adversely by the disability of any other
person in his family”. These are the relevant categories.
Family member illness / disability [for use only if no further detail is
initially available]
Children with chronically physically ill parent(s)
SN-AFD-PD02
Children whose parent(s) have learning disabilities
SN-AFD-PD03
Children with chronically disabled parent(s) where parenting
capacity is limited
Children with chronically mentally ill parent(s) where parenting
capacity is limited
Children caring for chronically ill or disabled family member (young
carers)
SN-AFD-PD00
SN-AFD-PD04
SN-AFD-PD05
CVAgencyType
–
SN-LAT
SN-LAT-01
This CV was formerly named CVLeadAgencyType. The change of
name reflects an extended range of use. Subsets of the CV are
used in different contexts. For Community Care lead agencies,
values 01, 02, 03, 04, 05 and 98 are used. For Child Protection
Inquiries, 01, 04, 07, 08, 09 and 98 are used.
Health
SN-LAT-02
Social Work
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 148
Transformational Technologies Division
Controlled
Vocabulary
XXX OLD XXX
CVAppointment
Aborted
CVAssociated
PersonRole
CVAuthorityStatus
CVCANon
Completion
Reason
Code
Value
SN-LAT-03
Housing
SN-LAT-04
Voluntary Sector
SN-LAT-05
Joint Agency
SN-LAT-07
Education
SN-LAT-08
Police
SN-LAT-09
SCRA
SN-LAT-98
Other
SN-LAT-06
Other
SN-APA
SN-APA-01
Visit cancelled by professional
SN-APA-02
Visit cancelled by recipient
SN-APA-03
Intended recipient did not attend (no notice given)
SN-APA-98
Other
SN-APR
SN-APR-00
No role
SN-APR-01
Carer
SN-APR-01-A
Carer: Main carer
SN-APR-01-B
Carer: Secondary carer
SN-APR-02
Key holder
SN-APR-02-A
Key holder: Main key holder
SN-APR-02-B
Key holder: Additional key holder
SN-APR-03
Appointed representative
SN-APR-03-A
Appointed representative: Advocate
SN-APR-03-B
SN-APR-04
Appointed representative: Proxy
Emergency contact
SN-APR-05
Person with parental responsibility
SN-APR-06
Relevant person
SN-APR-07
Next-of-kin
SN-APR-98
Other role
SN-APR-99
Not known
SN-AUT
SN-AUT-01
Data disclosure authorised
SN-AUT-02
Authorisation ended or suspended
SN-CNR
SN-CNR-01
Non-compliance of child
SN-CNR-02
Non-compliance of parent / guardian
SN-CNR-03
Family moved away – address unknown
SN-CNR-04
Assessment no longer required
SN-CNR-98
Other
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 149
Transformational Technologies Division
Controlled
Vocabulary
CVChild
Assessment
Outcome
CVChild
Assessment
Reason
CVChild
Assessment
Report
CVChild
AssessmentType
CVChildSocial
WorkStatus
Code
Value
SN-CAO
SN-CAO-01
No further action
SN-CAO-02
Action Plan initiated
SN-CAR
SN-CAR-01
Response to a request for assistance
SN-CAR-02
Legal Proceedings
SN-CAR-03
As part of routine work with the child
SN-CAR-98
Other
SN-CAP
SN-CAP-01
Initial Enquiry Report
SN-CAP-02
Initial Assessment Report
SN-CAP-03
Social Background Report
SN-CAP-04
Child Protection Report
SN-CAP-05
Adoption Report
SN-CAP-06
Education Report
SN-CAP-07
Asset/YLS Report – Youth Justice or Offending Behaviour
SN-CAP-08
Integrated Assessment Report
SN-CAP-09
Internal Report
SN-CAP-10
Health Report
SN-CAP-98
Other report
SN-CAT
SN-CAT-01
New / First / Initial Assessment
SN-CAT-02
SN-CAT-03
Re-assessment (following change in needs / conditions /
circumstances)
Comprehensive Assessment
SN-CAT-04
Routine review
SN-CSW
SN-CSW-00
This specifies the statutory basis for a Social Work involvement
with a child. More than one can apply.
No statutory Social Work provision
SN-CSW-01
Section 22, Children (Scotland) Act 1995
SN-CSW-02
Section 25, Children (Scotland) Act 1995
SN-CSW-03
Section 70(1), Children (Scotland) Act 1995
SN-CSW-04
Section 70(9), Children (Scotland) Act 1995
SN-CSW-05
Section 56(4)(b), Children (Scotland) Act 1995
SN-CSW-06
Section 45,63,66,67,68,69 Children (Scotland) Act 1995
SN-CSW-07
Section 57, Children (Scotland) Act 1995
SN-CSW-08
Section 86(1), Children (Scotland) Act 1995
SN-CSW-09
Section 11(12) Children Scotland (Act) 1995
SN-CSW-10
Section 55 Children Scotland (Act) 1995
SN-CSW-11
Section 70(3), Children (Scotland) Act 1995 (FC)
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 150
Transformational Technologies Division
Controlled
Vocabulary
CVConcernFactor
Code
Value
SN-CSW-12
Section 70(3), Children (Scotland) Act 1995 (RE)
SN-CSW-13
Section 70(3), Children (Scotland) Act 1995 (CO)
SN-CSW-14
Section 29, Children (Scotland) Act 1995
SN-CSW-15
Section 23, Children (Scotland) Act 1995 (CO)
SN-CSW-16
Section 53(1), 56(2) Children (Scotland) Act 1995
SN-CSW-17
Section 18 Adoption (Scotland) Act 1978
SN-CSW-18
Section 30 Adoption (Scotland) Act 1978
SN-CSW-19
(NOT PRESENTLY USED [Permanency Order])
SN-CSW-20
Additional Support for Learning Act
SN-CSW-21
Section 70(4) Children (Scotland) Act 1995
SN-CNF
SN-CNF-NA00
Factors triggering a Request for Assistance or giving rise to an
Expression of Concern.
Neglect or Abuse
SN-CNF-NA01
Suspected Failure to Thrive
SN-CNF-NA02
Suspected Physical Neglect
SN-CNF-NA03
Suspected Physical Injury
SN-CNF-NA04
Suspected Sexual Abuse
SN-CNF-NA05
Suspected Emotional Abuse
SN-CNF-NA06
Child / YP as suspected abuser
SN-CNF-NA07
Child Abandoned
SN-CNF-NA08
Child Prostitution / Sexual Exploitation
SN-CNF-CD00
Child Illness / Disability
SN-CNF-CD01
Learning difficulties
SN-CNF-CD02
Mental Health problem
SN-CNF-CD03
Autistic spectrum disorder
SN-CNF-CD04
Hearing impairment
SN-CNF-CD05
Language and communication disorder
SN-CNF-CD06
Physical or motor impairment
SN-CNF-CD07
Visual impairment
SN-CNF-CD08
Social, emotional and behavioural difficulties
SN-CNF-CD09
Other chronic illness / disability
SN-CNF-CD10
Multiple disabilities
SN-CNF-PD00
Parental Illness / disability
SN-CNF-PD01
Children with chronically physically ill parent(s) / carer(s)
SN-CNF-PD02
Children whose parent(s)/carer(s) have learning disabilities
SN-CNF-PD03
SN-CNF-MS00
Children with chronically disabled parent(s) / carer(s) where
parenting capacity is limited
Children with chronically mentally ill parent(s) / carer(s) where
parenting capacity is limited
Children caring for chronically ill or disabled family member (young
carers)
Misuse of Drugs, Alcohol or Volatile Substances
SN-CNF-MS01
Children misusing alcohol
SN-CNF-MS02
Children misusing drugs
SN-CNF-MS03
Children misusing volatile substances
SN-CNF-MS04
Children misusing alcohol and drugs
SN-CNF-MS05
Children misusing drugs and volatile substances
SN-CNF-MS06
Children misusing volatile substances and alcohol
SN-CNF-PD04
SN-CNF-PD05
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 151
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
SN-CNF-MS07
Children misusing drugs and alcohol and volatile substances
SN-CNF-MS08
SN-CNF-FS00
Children affected by the misuse of alcohol by parents or other
family members
Children affected by the misuse of drug(s) by parents or other
family members
Children affected by the misuse of volatile substances by parents
or other family members
Children affected by the misuse of a combination of
alcohol/drugs/volatile substances by parents or other family
members
Family Stress
SN-CNF-FS01
Unemployed / Low Income / Financial Difficulties
SN-CNF-FS02
Homeless /Temporary Accommodation
SN-CNF-FS03
Asylum Seeking /refugees
SN-CNF-FS04
Single Parents
SN-CNF-FS05
Absent Parents/Family member
SN-CNF-FS06
Lone Children/Young People
SN-CNF-FS07
Children of Young Parents
SN-CNF-FS08
Bereavement
SN-CNF-FD00
Family Dysfunction
SN-CNF-FD01
Suspected Poor Parenting Skills
SN-CNF-FD02
Poor Attachment
SN-CNF-FD03
Domestic Violence
SN-CNF-FD04
Family Violence
SN-CNF-FD05
Child Placing themselves at risk
SN-CNF-ED00
Educational Difficulties
SN-CNF-ED01
Low Attainment for Ability
SN-CNF-ED02
Truancy
SN-CNF-ED03
Exclusion
SN-CNF-ED04
Children Bullying
SN-CNF-ED05
Children affected by bullying
SN-CNF-CL00
Children in Conflict with the Law
SN-CNF-CL01
Offending
SN-CNF-CN00
Other Children in Need
SN-CNF-CN01
Children in the Adoption Process
SN-CNF-CN02
Court and Hearing Reports
SN-CNF-CN03
Runaways inc. those seeking refuge
SN-CNF-CN04
Missing Children
SN-CNF-CN06
Complaints & Historical allegations
SN-CNF-98
Other
SN-CTS
SN-CTS-01
Within the MAS, simple expiry of a partnership consent is indicated
through the end date on the latest PartnershipConsentHistory
entry. For this reason, the MAS CV does not include a “Consent
expired” value (though this may be added for display purposes in
agency systems).
All-agency consent given (including renewal of a previous consent)
SN-CTS-02
All-agency consent qualified
SN-CTS-03
All-agency consent withdrawn
SN-CTT
Indicates whether a partnership consent has been given (or
SN-CNF-MS09
SN-CNF-MS10
SN-CNF-MS11
CVConsentStatus
CVConsentType
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 152
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
SN-CTT-01
withdrawn) by the person concerned, or on behalf the person by a
parent (or person with parental responsibility) or a proxy (under the
Adults With Incapacity (Scotland) Act 200
Consent / withdrawal by data subject
SN-CTT-02
SN-CTT-03
CVContactDetail
Type
CVControllerType
LCVControlType
CVCountryOfBirth
Consent / withdrawal by parent (or person with parental
responsibility)
Consent / withdrawal by proxy (under AWI Act)
EN-CDT
EN-CDT-01
Home phone number
EN-CDT-02
Mobile phone number
EN-CDT-03
Work phone number
EN-CDT-04
Fax number
EN-CDT-05
Textphone number
EN-CDT-06
Other phone number
EN-CDT-07
Email address
EN-CRT
EN-CRT-1
Indicates whether Question Controller governs display of
Question, mandatory status of Question or both together.
Display
EN-CRT-2
Mandatory status
EN-CRT-3
Combined
EL(ppp)-CLT
EL(ppp)-CLT-1
Indicates the type of input element that should be displayed to the
user. [Further values may be added locally to those listed below.]
Drop down list [Allows single choice from list]
EL(ppp)-CLT-2
Combo box [A multiple choice list]
EL(ppp)-CLT-3
Radio button group [Allows single choice]
EL(ppp)-CLT-4
Check box group [Allows multiple choice]
EL(ppp)-CLT-5
Text box [A small input box for text]
EL(ppp)-CLT-6
Text area [A larger area for text input]
EL(ppp)-CLT-7
Calculated field [A command button and a label to invoke dynamic
calculation of values]
SN-COB
The three-character Value codes derive from ISO 3166-1.
SN-COB-01
Scotland
SN-COB-02
England
SN-COB-03
Wales
SN-COB-04
Northern Ireland
SN-COB-05
Republic of Ireland
SN-COB-98
Elsewhere
SN-COB-99
Not known
AFG
Afghanistan
ALB
Albania
GBR09
Alderney
DZA
Algeria
AND
Andorra
AGO
Angola
AIA
Anguilla
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 153
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
ATG
Antigua and Barbuda
ARG
Argentina
ARM
Armenia
AUS
Australia
AUT
Austria
AZE
Azerbaijan
BHS
Bahamas
BHR
Bahrain
BGD
Bangladesh
BRB
Barbados
BLR
Belarus
BEL
Belgium
BLZ
Belize
BEN
Benin
BMU
Bermuda
BTN
Bhutan
BOL
Bolivia
BIH
Bosnia and Herzegovina
BWA
Botswana
BRA
Brazil
IOT
British Indian Ocean Territory
VGB
British Virgin Islands
BRN
Brunei
BGR
Bulgaria
BFA
Burkina Faso
BDI
Burundi
KHM
Cambodia
CMR
Cameroon
CAN
Canada
CPV
Cape Verde
CYM
Cayman Islands
CAF
Central African Republic
TCD
Chad
GBR10
Channel Islands
CHL
Chile
CHN
China
COL
Columbia
RUS
Commonwealth of (Russian) Independent States
COM
Comoros
COG
Congo
COK
Cook Islands
CRI
Costa Rica
HRV
Croatia
CUB
Cuba
CYP
Cyprus
CZE
Czech Republic
COD
Democratic Republic of Congo
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 154
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
DNK
Denmark
DJI
Djibouti
DMA
Dominica
DOM
Dominican Republic
TLS
East Timor
ECU
Ecuador
EGY
Egypt
SLV
El Salvador
GNQ
Equatorial Guinea
ERI
Eritrea
EST
Estonia
ETH
Ethiopia
FLK
Falkland Islands
FRO
Faroe Islands
FJI
Fiji
FIN
Finland
FRA
France
GUF
French Guiana
PYF
French Polynesia
FRA
French Southern Territories
GAB
Gabon
GMB
Gambia
GEO
Georgia
DEU
Germany
GHA
Ghana
GIB
Gibraltar
GRC
Greece
GRL
Greenland
GRD
Grenada
GLP
Guadeloupe
GTM
Guatemala
GBR06
Guernsey
GIN
Guinea
GNB
Guinea - Bissau
GUY
Guyana
HTI
Haiti
HND
Honduras
HKG
Hong Kong
HUN
Hungary
ISL
Iceland
IND
India
IDN
Indonesia
IRN
Iran
IRQ
Iraq
GBR05
Isle of Man
ISR
Israel
ITA
Italy
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 155
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
CIV
Ivory Coast
JAM
Jamaica
JPN
Japan
GBR08
Jersey
JOR
Jordan
KAZ
Kazakhstan
KEN
Kenya
KIR
Kiribati
PRK
Korea, Democratic People's Republic of
KOR
Korea, Republic of
KWT
Kuwait
KGZ
Kyrgyzstan
LAO
Laos
LVA
Latvia
LBN
Lebanon
LSO
Lesotho
LBR
Liberia
LBY
Libya
LIE
Liechtenstein
LTU
Lithuania
LUX
Luxembourg
MKD
Macedonia
MDG
Madagascar
MWI
Malawi
MYS
Malaysia
MDV
Maldives
MLI
Mali
MLT
Malta and Gozo
MHL
Marshall Islands
MTQ
Martinique
MRT
Mauritania
MUS
Mauritius
MEX
Mexico
FSM
Micronesia (Federated States of)
MDA
Moldova
MCO
Monaco
MNG
Mongolia
SCG
Montenegro
MSR
Montserrat
MAR
Morocco
MOZ
Mozambique
MMR
Myanmar
NAM
Namibia
NRU
Nauru
NPL
Nepal
ANT
Netherlands Antilles
NLD
Netherlands
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 156
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
NCL
New Caledonia
NZL
New Zealand
NIC
Nicaragua
NER
Niger
NGA
Nigeria
NIU
Niue
NOR
Norway
PSE
Occupied Territories (Gaza and West Bank)
OMN
Oman
PAK
Pakistan
PLW
Palau
PAN
Panama
PNG
Papua New Guinea
PRY
Paraguay
PER
Peru
PHL
Philippines
PCN
Pitcairn Islands Group
POL
Poland
PRT
Portugal
PRI
Puerto Rico
QAT
Qatar
REU
Reunion
ROU
Romania
RUS
Russia
RWA
Rwanda
SMR
San Marino
STP
Sao Tome and Principe
GBR07
Sark
SAU
Saudi Arabia
SEN
Senegal
SCG
Serbia
SYC
Seychelles
SLE
Sierra Leone
SGP
Singapore
SVK
Slovakia
SVN
Slovenia
SLB
Solomon Islands
SOM
Somalia
ZAF
South Africa
ESP
Spain
LKA
Sri Lanka
KNA
St Christopher (St Kitts) - Nevis
LCA
St Lucia
VCT
St Vincent and the Grenadines
SHN
St. Helena and Dependencies
SDN
Sudan
SUR
Suriname
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 157
Transformational Technologies Division
Controlled
Vocabulary
CVCPConference
Outcome
Code
Value
SWZ
Swaziland
SWE
Sweden
CHE
Switzerland
SYR
Syrian Arab Republic
TWN
Taiwan
TJK
Tajikistan
TZA
Tanzania
THA
Thailand
TGO
Togo
TON
Tonga
TTO
Trinidad and Tobago
TUN
Tunisia
TUR
Turkey
TKM
Turkmenistan
TCA
Turks and Caicos Islands
TUV
Tuvalu
UGA
Uganda
UKR
Ukraine
ARE
United Arab Emirates
GBR
United Kingdom
USA
United States of America
URY
Uruguay
UZB
Uzbekistan
VAT
Vatican City State
VIR
US Virgin Islands
VUT
Vanuatu
VEN
Venezuela
VNM
Vietnam
WSM
Western Samoa
YEM
Yemen
YUG
Yugoslavia
ZAR
Zaire
ZMB
Zambia
ZWE
Zimbabwe
900
At sea (not otherwise stated)
903
In the air (not otherwise stated)
906
Other (not otherwise stated)
920
East Africa (not otherwise stated)
921
North Africa (not otherwise stated)
922
West Africa (not otherwise stated)
924
Asia (not otherwise stated)
927
Europe (not otherwise stated)
931
Middle East (not otherwise stated)
934
South America (not otherwise stated)
SN-CCO
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 158
Transformational Technologies Division
Controlled
Vocabulary
CVCPInquiry
Outcome
CVCP
Investigating
Agency
CVCP
Investigation
Outcome
CVCP
StrategyMeeting
CVDwellingType
Code
Value
SN-CCO-01
Child registered
SN-CCO-02
Child not registered
SN-CCO-03
Registration category changed
SN-CCO-04
Registration continued
SN-CQO
SN-CQO-01
No further action
SN-CQO-02
Inter agency meeting (where Child Protection is discussed)
SN-CQO-03
SN-CQO-04
Support services as alternative to an Inter agency meeting (where
Child Protection is discussed)
Child Protection Order
SN-CQO-05
Exclusion Order
SN-CQO-06
Assessment Order
SN-CQO-07
Child Protection Investigation initiated
SN-CQO-98
Other
SN-CVA
SN-CVA-01
Police
SN-CVA-02
Joint Police and Social Work
SN-CVO
SN-CVO-01
No further action
SN-CVO-02
Inter agency meeting (where Child Protection is discussed)
SN-CVO-03
SN-CVO-04
Support services as alternative to an Inter agency meeting (where
Child Protection is discussed)
Child Protection Order
SN-CVO-05
Exclusion Order
SN-CVO-06
Assessment Order
SN-CVO-07
Criminal Proceedings
SN-CVO-98
Other
SN-CSM
SN-CSM-01
CP Strategy meeting held
SN-CSM-02
CP Strategy meeting not held
SN-DWE
SN-DWE-01
Detached
SN-DWE-01-A
Detached: Multi-storey
SN-DWE-01-B
Detached: Single storey
SN-DWE-02
Semi-detached House
SN-DWE-02-A
Semi-detached House: Multi-storey
SN-DWE-02-B
Semi-detached House: Single storey
SN-DWE-03
Terraced House
SN-DWE-03-A
Terraced House: Multi-storey
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 159
Transformational Technologies Division
Controlled
Vocabulary
CVEmployment
Status
CVEthnicGroup
SelfAssigned
Code
Value
SN-DWE-03-B
Terraced House: Single storey
SN-DWE-04
Flat
SN-DWE-04-A
Flat: Multi-storey – entrance on ground floor
SN-DWE-04-B
Flat: Multi-storey – entrance on upper floor (stairs only)
SN-DWE-04-C
Flat: Multi-storey – entrance on upper floor (lift access)
SN-DWE-04-D
Flat: Single storey – entrance on ground floor
SN-DWE-04-E
Flat: Single storey – entrance on upper floor (stairs only)
SN-DWE-04-F
Flat: Single storey – entrance on upper floor (lift access)
SN-DWE-05
Caravan / Travelling Trailer / Portakabin
SN-DWE-05-A
Caravan / Travelling Trailer / Portakabin: Static
SN-DWE-05-B
Caravan / Travelling Trailer / Portakabin: Mobile
SN-DWE-06
Water-borne craft
SN-DWE-98
Other dwelling type
SN-DWE-99
Not Known
SN-EMS
SN-EMS-01
Regular Paid Employment – Full-time
SN-EMS-02
Regular Paid Employment – Part-Time
SN-EMS-03
Self Employed
SN-EMS-04
Looking after home/family
SN-EMS-05
Engaged in Voluntary Work (unpaid)
SN-EMS-05-A
Engaged in Voluntary Work (unpaid): Seeking paid employment
SN-EMS-05-B
SN-EMS-06
Engaged in Voluntary Work (unpaid): Not seeking paid
employment
Unemployed – available/fit for work
SN-EMS-07
Unemployed – not available/fit for work
SN-EMS-08
Full-time education (pupil or student)
SN-EMS-09
Retired
SN-EMS-09-A
Retired: Career completion
SN-EMS-09-B
Retired: Medically retired
SN-EMS-10
Not applicable
SN-EMS-11
Permanently sick/disabled
SN-EMS-12
Temporarily sick/disabled (self-employed only)
SN-EMS-13
Government Training Scheme
SN-EMS-14
Other reasons not working
SN-EMS-99
Not known
SN-EGA
SN-EGA-01
White
SN-EGA-01-E004
White: Scottish
SN-EGA-01-E070
White: Other British
SN-EGA-01-E002
White: Irish
SN-EGA-02
Mixed
SN-EGA-03
Asian, Asian Scottish or Asian British
SN-EGA-03-E041
Asian, Asian Scottish or Asian British: Indian
SN-EGA-03-E042
Asian, Asian Scottish or Asian British: Pakistani
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 160
Transformational Technologies Division
Controlled
Vocabulary
CVEthnicGroup
Specific
Code
Value
SN-EGA-03-E043
Asian, Asian Scottish or Asian British: Bangladeshi
SN-EGA-03-E081
Asian, Asian Scottish or Asian British: Chinese
SN-EGA-04
Black, Black Scottish or Black British
SN-EGA-04-E061
Black, Black Scottish or Black British: Caribbean
SN-EGA-04-E062
Black, Black Scottish or Black British: African
SN-EGA-05
Other Ethnic Background
SN-EGA-97
Not disclosed
SN-EGA-99
Not known
SN-EGS
SN-EGS-E001
British
SN-EGS-E002
Irish
SN-EGS-E003
English
SN-EGS-E004
Scottish
SN-EGS-E005
Welsh
SN-EGS-E006
Cornish
SN-EGS-E007
Cypriot (Part not stated)
SN-EGS-E008
Greek
SN-EGS-E009
Greek Cypriot
SN-EGS-E010
Turkish
SN-EGS-E011
Turkish Cypriot
SN-EGS-E012
Italian
SN-EGS-E013
Irish Traveller
SN-EGS-E014
Traveller
SN-EGS-E015
Gypsy/Romany
SN-EGS-E016
Polish
SN-EGS-E017
Commonwealth of (Russian) Independent States
SN-EGS-E018
Kosovan
SN-EGS-E019
Albanian
SN-EGS-E020
Baltic States
SN-EGS-E021
… and Black Caribbean
SN-EGS-E022
… and Black African
SN-EGS-E023
… and Asian
SN-EGS-E024
Black and Asian
SN-EGS-E025
Black and Chinese
SN-EGS-E026
Black and White
SN-EGS-E027
Chinese and White
SN-EGS-E028
Asian and Chinese
SN-EGS-E029
Other Mixed
SN-EGS-E030
Latin American
SN-EGS-E031
Bosnian
SN-EGS-E032
Croatian
SN-EGS-E033
Serbian
SN-EGS-E034
Other Former Yugoslavia
SN-EGS-E035
South American
SN-EGS-E036
Other Mixed White
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 161
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
SN-EGS-E037
Other European
SN-EGS-E038
Northern Irish
SN-EGS-E039
Other White
SN-EGS-E040
Mixed Irish/Other White
SN-EGS-E041
Indian
SN-EGS-E042
Pakistani
SN-EGS-E043
Bangladeshi
SN-EGS-E044
Mixed Asian
SN-EGS-E045
Punjabi
SN-EGS-E046
Kashmiri
SN-EGS-E047
East African Asian
SN-EGS-E048
Sri Lankan
SN-EGS-E049
Tamil
SN-EGS-E050
Sinhalese
SN-EGS-E051
British Asian
SN-EGS-E052
Possible Mixed Nigerian
SN-EGS-E053
Possible Mixed Other Black
SN-EGS-E054
Possible Mixed Chinese
SN-EGS-E055
Possible Mixed Arab or Middle Eastern
SN-EGS-E056
Possible Mixed Other
SN-EGS-E057
Caribbean Asian
SN-EGS-E058
Part Asian (Other Part Unknown)
SN-EGS-E059
Other Asian
SN-EGS-E060
Ulster Scot
SN-EGS-E061
Caribbean
SN-EGS-E062
African
SN-EGS-E063
Somali
SN-EGS-E064
Mixed Black
SN-EGS-E065
Nigerian
SN-EGS-E066
Black British
SN-EGS-E067
Part Caribbean (Other Part Unknown)
SN-EGS-E068
Part African (Other Part Unknown)
SN-EGS-E069
Other Black
SN-EGS-E070
Other British
SN-EGS-E071
Buddhist
SN-EGS-E072
Hindu
SN-EGS-E073
Jewish
SN-EGS-E074
Muslim
SN-EGS-E075
Sikh
SN-EGS-E076
Arab
SN-EGS-E077
Kurdish
SN-EGS-E078
Moroccan
SN-EGS-E079
Israeli
SN-EGS-E080
Part Chinese (Other Part Unknown)
SN-EGS-E081
Chinese
SN-EGS-E082
North African
SN-EGS-E083
Other Middle Eastern
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 162
Transformational Technologies Division
Controlled
Vocabulary
CVEvent
InvolvementType
CVEventStatus
CVEventType
Code
Value
SN-EGS-E084
Vietnamese
SN-EGS-E085
Japanese
SN-EGS-E086
Filipino
SN-EGS-E087
Malaysian
SN-EGS-E088
Iranian
SN-EGS-E089
Any Other Group
SN-EGS-E090
Multi-Ethnic islands
SN-EGS-E091
Possible Mixed Indian
SN-EGS-E092
Possible Mixed Pakistani
SN-EGS-E093
Possible Mixed Bangladeshi
SN-EGS-E094
Possible Mixed Punjabi
SN-EGS-E095
Possible Mixed Kashmiri
SN-EGS-E096
Possible Mixed Other Asian
SN-EGS-E097
Possible Mixed Caribbean
SN-EGS-E098
Possible Mixed African
SN-EGS-E099
Possible Mixed Somali
SN-EIT
Types of involvement that a person can have with an event.
SN-EIT-01
Involvement as primary subject
SN-EIT-02
Involvement as professional
SN-EIT-03
Involvement as associated person
SN-EVS
List of Event Statuses.
SN-EVS-01
Event has occurred
SN-EVS-02
Firm plans exist but event has not yet occurred
SN-EVS-03
Event was planned but did not happen
SN-EVS-04
Event was mistakenly reported
SN-EVT
Provisional list of Event Types.
SN-EVT-01
Life event
SN-EVT-02
Service event
SN-EVT-02-B
Service event: Professional intervention or action
SN-EVT-02-C
Service event: Home visit
SN-EVT-02-D
Service event: Establishment visit
SN-EVT-02-E
Service event: Inter-professional meeting
SN-EVT-02-F
Service event: Children’s Hearing
SN-EVT-02-G
Service event: One-off service delivery event
SN-EVT-02-Z
Service event: Other service event
SN-EVT-03
Medical event
SN-EVT-03-A
Medical event: Medical diagnosis
SN-EVT-03-B
Medical event: Immunisation
SN-EVT-03-C
Medical event: Medication prescription
SN-EVT-03-D
Medical event: Medical treatment
SN-EVT-03-Z
Medical event: Other medical event
SN-EVT-04
Hospital event
SN-EVT-04-A
Hospital event: A & E attendance
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 163
Transformational Technologies Division
Controlled
Vocabulary
XXX OLD XXX
CVExtensionData
Type
LCVFormat
Attribute
Code
Value
SN-EVT-04-B
Hospital event: Outpatient attendance
SN-EVT-04-C
Hospital event: Hospital inpatient admission
SN-EVT-04-D
Hospital event: Hospital inpatient discharge
SN-EVT-04-Z
Hospital event: Other hospital event
SN-EVT-05
Educational event
SN-EVT-05-A
Educational event: School exclusion
SN-EVT-05-Z
Educational event: Other educational event
SN-EVT-06
“Statutory” event
SN-EVT-98
Locally defined event type
SN-EVT-02-A
Service event: Expression of concern
EN-EDT
EN-EDT-1
Data types for extension attributes. Note that this CV differs
slightly from CVQuestionDataType, which has a different purpose.
Globally unique identifier
EN-EDT-2
String
EN-EDT-3
True/false
EN-EDT-4
Date
EN-EDT-5
DateTime
EN-EDT-6
Integer
EN-EDT-7
Numeric
EL(ppp)-FTA
EL(ppp)-FTA-1
Holds formatting attributes such as left alignment. Further values
may be added locally to those listed below.
Row [Question Grouping is to be displayed as a row]
EL(ppp)-FTA-2
Column [Question Grouping is to be displayed as a column]
EL(ppp)-FTA-3
Left Aligned [A CV response label is to be placed to the left of e.g.
the check box or radio button to which it relates]
Right Aligned [A CV response label is to be placed to the right of
e.g. the check box or radio button to which it relates]
Horizontal Layout [E.g. check boxes or radio buttons (for CV
response options) are to be laid out horizontally]
Vertical Layout [E.g. check boxes or radio buttons (for CV
response options) are to be laid out vertically]
Dynamic Display [Indicates whether the question is to be hidden
unless dynamically invoked]
EL(ppp)-FTA-4
EL(ppp)-FTA-5
EL(ppp)-FTA-6
EL(ppp)-FTA-7
LCVFormStatus
EL(ppp)-FMS
The (locally defined) status of a form. Typical values are likely to
include “completed”, “incomplete” and perhaps “cancelled”, but
eCare partnerships may wish to recognise other values as well
(e.g. “suspended”). They may also attach different business rules
to e.g. the “completed” status.
CVFormType
Status
EN-FTS
EN-FTS-1
Indicates whether a Form Type is operative within a MAS
implementation. Further values may be added.
Active [operative within the implementation]
EN-FTS-2
Inactive [not operative within the implementation]
CVGender
SN-GEN
SN-GEN-0
Not known
SN-GEN-1
Male
SN-GEN-2
Female
SN-GEN-8
Other specific
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 164
Transformational Technologies Division
Controlled
Vocabulary
CVHeader
CVHealthBoard
CVHearing
Decision
CVHomeVisit
Aborted
Code
Value
SN-GEN-9
Not specified
EN-HDR
EN-HDR-1
Indicates whether Question text is used as a “primary” header, or
as a “secondary” header, or is not displayed at all. The secondary
header option is only available when the QuestionGrouping is
repeatable, in which case a “primary” header will occur only once
(as a header to the column / row of responses to the Question)
whereas a “secondary” header will be repeated for each repetition
of the QuestionGrouping.
Secondary header
EN-HDR-2
Primary header
EN-HDR-3
Not displayed
SN-HBD
SN-HBD-C
Argyll and Clyde
SN-HBD-A
Ayrshire and Arran
SN-HBD-B
Borders
SN-HBD-Y
Dumfries and Galloway
SN-HBD-F
Fife
SN-HBD-V
Forth Valley
SN-HBD-N
Grampian
SN-HBD-G
Greater Glasgow
SN-HBD-H
Highland
SN-HBD-L
Lanarkshire
SN-HBD-S
Lothian
SN-HBD-R
Orkney
SN-HBD-Z
Shetland
SN-HBD-T
Tayside
SN-HBD-W
Western Isles
SN-HBD-E
Outwith Scotland
SN-HGD
SN-HGD-01
Discharge of the referral
SN-HGD-02
Supervision requirement at home
SN-HGD-03
Supervision requirement with residence requirement
SN-HGD-04
Voluntary contact with the social work department
SN-HGD-05
Warrant issued
SN-HGD-06
Continued Hearing
SN-HGD-07
Referred to the Sheriff Court
SN-HVA
SN-HVA-01
Visit cancelled by professional
SN-HVA-02
Visit cancelled by recipient
SN-HVA-03
Intended recipient not at home (but home occupied)
SN-HVA-04
No one at home evident
SN-HVA-05
Home occupied but no response to attempts to gain access
SN-HVA-98
Other
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 165
Transformational Technologies Division
Controlled
Vocabulary
Code
CVHousehold
Composition
SN-HHC
CVImpairment
Value
SN-HHC-01
Single adult non-pensioner household
SN-HHC-02
Single parent household
SN-HHC-02-A
Single parent household: With dependant children
SN-HHC-02-B
Single parent household: With non-dependant children
SN-HHC-02-C
SN-HHC-03
Single parent household: With dependant and non-dependant
children
Single pensioner
SN-HHC-03-A
Single pensioner: No children
SN-HHC-03-B
Single pensioner: With dependant children
SN-HHC-03-C
Single pensioner: With non-dependant children
SN-HHC-03-D
Single pensioner: With dependant and non-dependant children
SN-HHC-04
Adult couple (non-pensionable)
SN-HHC-04-A
Adult couple (non-pensionable): No children
SN-HHC-04-B
Adult couple (non-pensionable): With dependant children
SN-HHC-04-C
Adult couple (non-pensionable): With non-dependant children
SN-HHC-04-D
SN-HHC-05
Adult couple (non-pensionable): With dependant and nondependant children
Adult couple (pensionable)
SN-HHC-05-A
Adult couple (pensionable): No children
SN-HHC-05-B
Adult couple (pensionable): With dependant children
SN-HHC-05-C
Adult couple (pensionable): With non-dependant children
SN-HHC-05-D
SN-HHC-06
Adult couple (pensionable): With dependant and non-dependant
children
Adult household (related)
SN-HHC-07
Adult household (not related)
SN-HHC-07-A
Adult household (not related): Student household
SN-HHC-07-B
Adult household (not related): Other adult household
SN-HHC-08
Extended household
SN-HHC-08-A
Extended household: No children
SN-HHC-08-B
Extended household: With dependant children
SN-HHC-08-C
Extended household: With non-dependant children
SN-HHC-08-D
Extended household: With dependant and non-dependant children
SN-HHC-09
Group household
SN-HHC-09-A
Group household: No children
SN-HHC-09-B
Group household: With dependant children
SN-HHC-09-C
Group household: With non-dependant children
SN-HHC-09-D
Group household: With dependant and non-dependant children
SN-HHC-10
Other households with dependant children
SN-HHC-11
Other households without dependant children
SN-HHC-99
Not known
SN-IMP
SN-IMP-00
None
SN-IMP-01
Specific learning difficulties
SN-IMP-02
Hearing impairment
SN-IMP-03
Language and communication disorder
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 166
Transformational Technologies Division
Controlled
Vocabulary
CVInterpretation
Assistance
CVLanguage
Code
Value
SN-IMP-04
Physical or motor impairment
SN-IMP-05
Visual impairment
SN-IMP-06
Cognitive impairment
SN-IMP-07
Combined sight and hearing loss
SN-IMP-98
Other impairment (specify separately)
SN-IMP-99
Not known
SN-INT
SN-INT-00
No help needed
SN-INT-01
Need help only with complex language
SN-INT-02
Help needed at all times
SN-INT-99
Not known
SN-LAN
aar
The Value codes derive from ISO 639-2/b, with the addition of a
specific value for BSL.
Afar
abk
Abkhazian
ace
Achinese
ach
Acoli
ada
Adangme
ady
Adyghe; Adygei
afa
Afro-Asiatic (Other)
afh
Afrihili
afr
Afrikaans
aka
Akan
akk
Akkadian
alb
Albanian
ale
Aleut
alg
Algonquian languages
amh
Amharic
ang
English, Old (ca.450-1100)
apa
Apache languages
ara
Arabic
arc
Aramaic
arg
Aragonese
arm
Armenian
arn
Araucanian
arp
Arapaho
art
Artificial (Other)
arw
Arawak
asm
Assamese
ast
Asturian; Bable
ath
Athapascan languages
aus
Australian languages
ava
Avaric
ave
Avestan
awa
Awadhi
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 167
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
aym
Aymara
aze
Azerbaijani
bad
Banda
bai
Bamileke languages
bak
Bashkir
bal
Baluchi
bam
Bambara
ban
Balinese
baq
Basque
bas
Basa
bat
Baltic (Other)
bej
Beja
bel
Belarusian
bem
Bemba
ben
Bengali
ber
Berber (Other)
bho
Bhojpuri
bih
Bihari
bik
Bikol
bin
Bini
bis
Bislama
bla
Siksika
bnt
Bantu (Other)
bos
Bosnian
bra
Braj
bre
Breton
btk
Batak (Indonesia)
bua
Buriat
bug
Buginese
bul
Bulgarian
bur
Burmese
byn
Blin; Bilin
cad
Caddo
cai
Central American Indian (Other)
car
Carib
cat
Catalan; Valencian
cau
Caucasian (Other)
ceb
Cebuano
cel
Celtic (Other)
cha
Chamorro
chb
Chibcha
che
Chechen
chg
Chagatai
chi
Chinese
chk
Chuukese
chm
Mari
chn
Chinook jargon
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 168
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
cho
Choctaw
chp
Chipewyan
chr
Cherokee
chu
chv
Church Slavic; Old Slavonic; Church Slavonic; Old Bulgarian; Old
Church Slavonic
Chuvash
chy
Cheyenne
cmc
Chamic languages
cop
Coptic
cor
Cornish
cos
Corsican
cpe
Creoles and pidgins, English based (Other)
cpf
Creoles and pidgins, French-based (Other)
cpp
cre
Creoles and pidgins,
Portuguese-based (Other)
Cree
crh
Crimean Tatar; Crimean Turkish
crp
Creoles and pidgins (Other)
csb
Kashubian
cus
Cushitic (Other)
cze
Czech
dak
Dakota
dan
Danish
dar
Dargwa
day
Dayak
del
Delaware
den
Slave (Athapascan)
dgr
Dogrib
din
Dinka
div
Divehi
doi
Dogri
dra
Dravidian (Other)
dsb
Lower Sorbian
dua
Duala
dum
Dutch, Middle (ca.1050-1350)
dut
Dutch; Flemish
dyu
Dyula
dzo
Dzongkha
efi
Efik
egy
Egyptian (Ancient)
eka
Ekajuk
elx
Elamite
eng
English
enm
English, Middle (1100-1500)
epo
Esperanto
est
Estonian
ewe
Ewe
ewo
Ewondo
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 169
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
fan
Fang
fao
Faroese
fat
Fanti
fij
Fijian
fil
Filipino; Pilipino
fin
Finnish
fiu
Finno-Ugrian (Other)
fon
Fon
fre
French
frm
French, Middle (ca.1400-1800)
fro
French, Old (842-ca.1400)
fry
Frisian
ful
Fulah
fur
Friulian
gaa
Ga
gay
Gayo
gba
Gbaya
gem
Germanic (Other)
geo
Georgian
ger
German
gez
Geez
gil
Gilbertese
gla
Gaelic; Scottish Gaelic
gle
Irish
glg
Gallegan
glv
Manx
gmh
German, Middle High (ca.1050-1500)
goh
German, Old High (ca.750-1050)
gon
Gondi
gor
Gorontalo
got
Gothic
grb
Grebo
grc
Greek, Ancient (to 1453)
gre
Greek, Modern (1453-)
grn
Guarani
guj
Gujarati
gwi
Gwich´in
hai
Haida
hat
Haitian; Haitian Creole
hau
Hausa
haw
Hawaiian
heb
Hebrew
her
Herero
hil
Hiligaynon
him
Himachali
hin
Hindi
hit
Hittite
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 170
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
hmn
Hmong
hmo
Hiri Motu
hsb
Upper Sorbian
hun
Hungarian
hup
Hupa
iba
Iban
ibo
Igbo
ice
Icelandic
ido
Ido
iii
Sichuan Yi
ijo
Ijo
iku
Inuktitut
ile
Interlingue
ilo
Iloko
ina
inc
Interlingua (International Auxiliary
Language Association)
Indic (Other)
ind
Indonesian
ine
Indo-European (Other)
inh
Ingush
ipk
Inupiaq
ira
Iranian (Other)
iro
Iroquoian languages
ita
Italian
jav
Javanese
jbo
Lojban
jpn
Japanese
jpr
Judeo-Persian
jrb
Judeo-Arabic
kaa
Kara-Kalpak
kab
Kabyle
kac
Kachin
kal
Kalaallisut; Greenlandic
kam
Kamba
kan
Kannada
kar
Karen
kas
Kashmiri
kau
Kanuri
kaw
Kawi
kaz
Kazakh
kbd
Kabardian
kha
Khasi
khi
Khoisan (Other)
khm
Khmer
kho
Khotanese
kik
Kikuyu; Gikuyu
kin
Kinyarwanda
kir
Kirghiz
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 171
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
kmb
Kimbundu
kok
Konkani
kom
Komi
kon
Kongo
kor
Korean
kos
Kosraean
kpe
Kpelle
krc
Karachay-Balkar
kro
Kru
kru
Kurukh
kua
Kuanyama; Kwanyama
kum
Kumyk
kur
Kurdish
kut
Kutenai
lad
Ladino
lah
Lahnda
lam
Lamba
lao
Lao
lat
Latin
lav
Latvian
lez
Lezghian
lim
Limburgan; Limburger; Limburgish
lin
Lingala
lit
Lithuanian
lol
Mongo
loz
Lozi
ltz
Luxembourgish; Letzeburgesch
lua
Luba-Lulua
lub
Luba-Katanga
lug
Ganda
lui
Luiseno
lun
Lunda
luo
Luo (Kenya and Tanzania)
lus
lushai
mac
Macedonian
mad
Madurese
mag
Magahi
mah
Marshallese
mai
Maithili
mak
Makasar
mal
Malayalam
man
Mandingo
mao
Maori
map
Austronesian (Other)
mar
Marathi
mas
Masai
may
Malay
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 172
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
mdf
Moksha
mdr
Mandar
men
Mende
mga
Irish, Middle (900-1200)
mic
Mi'kmaq; Micmac
min
Minangkabau
mis
Miscellaneous languages
mkh
Mon-Khmer (Other)
mlg
Malagasy
mlt
Maltese
mnc
Manchu
mni
Manipuri
mno
Manobo languages
moh
Mohawk
mol
Moldavian
mon
Mongolian
mos
Mossi
mul
Multiple languages
mun
Munda languages
mus
Creek
mwl
Mirandese
mwr
Marwari
myn
Mayan languages
myv
Erzya
nah
Nahuatl
nai
North American Indian
nap
Neapolitan
nau
Nauru
nav
Navajo; Navaho
nbl
Ndebele, South; South Ndebele
nde
Ndebele, North; North Ndebele
ndo
Ndonga
nds
Low German; Low Saxon; German, Low; Saxon, Low
nep
Nepali
new
Newari; Nepal Bhasa
nia
Nias
nic
Niger-Kordofanian (Other)
niu
Niuean
nno
Norwegian Nynorsk; Nynorsk, Norwegian
nob
Norwegian Bokmål; Bokmål, Norwegian
nog
Nogai
non
Norse, Old
nor
Norwegian
nso
Northern Sotho, Pedi; Sepedi
nub
Nubian languages
nwc
Classical Newari; Old Newari; Classical Nepal Bhasa
nya
Chichewa; Chewa; Nyanja
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 173
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
nym
Nyamwezi
nyn
Nyankole
nyo
Nyoro
nzi
Nzima
oci
Occitan (post 1500); Provençal
oji
Ojibwa
ori
Oriya
orm
Oromo
osa
Osage
oss
Ossetian; Ossetic
ota
Turkish, Ottoman (1500-1928)
oto
Otomian languages
paa
Papuan (Other)
pag
Pangasinan
pal
Pahlavi
pam
Pampanga
pan
Panjabi; Punjabi
pap
Papiamento
pau
Palauan
peo
Persian, Old (ca.600-400 B.C.)
per
Persian
phi
Philippine (Other)
phn
Phoenician
pli
Pali
pol
Polish
pon
Pohnpeian
por
Portuguese
pra
Prakrit languages
pro
Provençal, Old (to 1500)
pus
Pushto
qaa-qtz
Reserved for local use
que
Quechua
raj
Rajasthani
rap
Rapanui
rar
Rarotongan
roa
Romance (Other)
roh
Raeto-Romance
rom
Romany
rum
Romanian
run
Rundi
rus
Russian
sad
Sandawe
sag
Sango
sah
Yakut
sai
South American Indian (Other)
sal
Salishan languages
sam
Samaritan Aramaic
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 174
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
san
Sanskrit
sas
Sasak
sat
Santali
scc
Serbian
scn
Sicilian
sco
Scots
scr
Croatian
sel
Selkup
sem
Semitic (Other)
sga
Irish, Old (to 900)
sgn
Sign Languages
sgn-GB
British Sign Language (BSL)
shn
Shan
sid
Sidamo
sin
Sinhala; Sinhalese
sio
Siouan languages
sit
Sino-Tibetan (Other)
sla
Slavic (Other)
slo
Slovak
slv
Slovenian
sma
Southern Sami
sme
Northern Sami
smi
Sami languages (Other)
smj
Lule Sami
smn
Inari Sami
smo
Samoan
sms
Skolt Sami
sna
Shona
snd
Sindhi
snk
Soninke
sog
Sogdian
som
Somali
son
Songhai
sot
Sotho, Southern
spa
Spanish; Castilian
srd
Sardinian
srr
Serer
ssa
Nilo-Saharan (Other)
ssw
Swati
suk
Sukuma
sun
Sundanese
sus
Susu
sux
Sumerian
swa
Swahili
swe
Swedish
syr
Syriac
tah
Tahitian
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 175
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
tai
Tai (Other)
tam
Tamil
tat
Tatar
tel
Telugu
tem
Timne
ter
Tereno
tet
Tetum
tgk
Tajik
tgl
Tagalog
tha
Thai
tib
Tibetan
tig
Tigre
tir
Tigrinya
tiv
Tiv
tkl
Tokelau
tlh
Klingon; tlhIngan-Hol
tli
Tlingit
tmh
Tamashek
tog
Tonga (Nyasa)
ton
Tonga (Tonga Islands)
tpi
Tok Pisin
tsi
Tsimshian
tsn
Tswana
tso
Tsonga
tuk
Turkmen
tum
Tumbuka
tup
Tupi languages
tur
Turkish
tut
Altaic (Other)
tvl
Tuvalu
twi
Twi
tyv
Tuvinian
udm
Udmurt
uga
Ugaritic
uig
Uighur; Uyghur
ukr
Ukrainian
umb
Umbundu
und
Undetermined
urd
Urdu
uzb
Uzbek
vai
Vai
ven
Venda
vie
Vietnamese
vol
Volapük
vot
Votic
wak
Wakashan languages
wal
Walamo
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 176
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
war
Waray
was
Washo
wel
Welsh
wen
Sorbian languages
wln
Walloon
wol
Wolof
xal
Kalmyk
xho
Xhosa
yao
Yao
yap
Yapese
yid
Yiddish
yor
Yoruba
ypk
Yupik languages
zap
Zapotec
zen
Zenaga
zha
Zhuang; Chuang
znd
Zande
zul
Zulu
zun
Zuni
CVLeadAgency
Type
SN-LAT
See CVAgencyType
CVLocalAuthority
SN-LCA
SN-LCA-100
Aberdeen City
SN-LCA-110
Aberdeenshire
SN-LCA-120
Angus
SN-LCA-130
Argyll & Bute
SN-LCA-150
Clackmannanshire
SN-LCA-170
Dumfries & Galloway
SN-LCA-180
Dundee City
SN-LCA-190
East Ayrshire
SN-LCA-200
East Dunbartonshire
SN-LCA-210
East Lothian
SN-LCA-220
East Renfrewshire
SN-LCA-230
Edinburgh, City of
SN-LCA-235
Eilean Siar
SN-LCA-240
Falkirk
SN-LCA-250
Fife
SN-LCA-260
Glasgow City
SN-LCA-270
Highland
SN-LCA-280
Inverclyde
SN-LCA-290
Midlothian
SN-LCA-300
Moray
SN-LCA-310
North Ayrshire
SN-LCA-320
North Lanarkshire
SN-LCA-330
Orkney Islands
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 177
Transformational Technologies Division
Controlled
Vocabulary
CVLockingStatus
CVLookedAfter
Type
CVMandatory
Answer
CVMaritalStatus
CVMessageType
CVMultiAgency
CVNamedPerson
Consulted
Code
Value
SN-LCA-340
Perth & Kinross
SN-LCA-350
Renfrewshire
SN-LCA-355
Scottish Borders
SN-LCA-360
Shetland Islands
SN-LCA-370
South Ayrshire
SN-LCA-380
South Lanarkshire
SN-LCA-390
Stirling
SN-LCA-395
West Dunbartonshire
SN-LCA-400
West Lothian
SN-LCA-900
Outwith Scotland
EN-LKS
EN-LKS-1
Indicates whether a Form is locked or unlocked for editing.
Further values may be added.
Locked
EN-LKS-2
Unlocked
SN-LOT
SN-LOT-01
Looked After and Accommodated
SN-LOT-02
Looked After At Home
EN-MAA
EN-MAA-1
Indicates whether a Question is always mandatory or always
optional or whether this is determined dynamically [i.e. is
dependent on a condition that is evaluated at run-time].
Mandatory
EN-MAA-2
Optional
EN-MAA-3
Dynamically determined
SN-MRS
SN-MRS-S
Single
SN-MRS-M
Married
SN-MRS-D
Divorced
SN-MRS-W
Widowed
SN-MRS-N
Not disclosed
SN-MRS-P
Separated
EN-MST
EN-MST-01
CVMessageType is used on the Message Log to distinguish
between incoming messages (requests) and outgoing messages
(responses).
Request
EN-MST-02
Response
SN-MUA
SN-MUA-01
Multi-agency assessment
SN-MUA-02
Single agency assessment
SN-MUA-99
Not known
SN-NPC
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 178
Transformational Technologies Division
Controlled
Vocabulary
CVNameElement
Type
CVNameStatus
CVOrganisation
Reference
CVOrganisation
Type
CVPerson
Reference
CVPlannedVisit
Code
Value
SN-NPC-01
Named person consulted
SN-NPC-02
Named person not consulted
EN-NET
EN-NET-01
Initials
EN-NET-02
Title
EN-NET-03
Forename
EN-NET-04
Surname / Family Name
EN-NET-05
Suffix
EN-NET-06
Unstructured Name
SN-NST
SN-NST-00
Name status not known
SN-NST-01
Registered name
SN-NST-02
Alternative name
SN-NST-03
Married name
SN-NST-04
Maiden name
SN-NST-05
Name changed by deed poll
SN-NST-06
Electoral registration name
EN-ORF
EN-ORF-GPPC
Standardly used external identifiers for types of “organisation” for
which a sharing requirement may exist.
GP Practice Code
EN-ORF-LOC
ISD Location Code
EN-ORF-SCRC
SCRC (Care Commission) Service Number
EN-ORF-SEED
SE Education Department reference code
EN-ORT
Distinguishes some commonly occurring types of “organisation”.
EN-ORT-CH
Care home
EN-ORT-EE01
Nursery school
EN-ORT-EE02
Primary school
EN-ORT-EE03
Secondary school
EN-ORT-EE04
SEN school
EN-ORT-EE05
Further Education College
EN-ORT-EE99
Other educational establishment
EN-ORT-GPP
GP Practice
EN-ORT-HOSP
Hospital
EN-ORT-RES
Residential accommodation (other than care home)
EN-PRF
EN-PRF-GMC
Standardly used external identifiers for Subjects or Professionals
for which a sharing requirement may exist.
General Medical Council Number
EN-PRF-SCN
Scottish Candidate Number
EN-PRF-SSSC
Scottish Social Services Council Registration Number
SN-PLV
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 179
Transformational Technologies Division
Controlled
Vocabulary
CVPreferred
Communication
Method
Code
Value
SN-PLV-01
Planned visit
SN-PLV-02
Unplanned visit
SN-PCM
SN-PCM-01
Verbal communication
SN-PCM-01-A
SN-PCM-02
Verbal communication: Generally intelligible speech (i.e. person
can be understood by all)
Verbal communication: Speech of limited intelligibility (i.e. only
some of what person says can be understood by all, OR person
can be understood only by people familiar with the mode of
speech)
Verbal communication: Other verbal communication (i.e. person
uses grunts or other utterances to communicate)
Communication based on the alphabet
SN-PCM-02-A
Communication based on the alphabet: Finger Spelling
SN-PCM-02-B
SN-PCM-02-C
Communication based on the alphabet: Deaf/Blind manual
alphabet
Communication based on the alphabet: Block
SN-PCM-03
Communication based on sign language
SN-PCM-03-A
SN-PCM-03-C
Communication based on sign language: British Sign Language
(BSL)
Communication based on sign language: Visual Frame
signing/Close signing
Communication based on sign language: Hands on signing
SN-PCM-03-D
Communication based on sign language: Makaton
SN-PCM-03-E
Communication based on sign language: Sign Supported English
SN-PCM-03-F
Communication based on sign language: Signed English
SN-PCM-03-G
Communication based on sign language: Other Sign Language
SN-PCM-04
Communication using text
SN-PCM-04-A
Communication using text: Large Print
SN-PCM-04-B
Communication using text: Braille and Moon
SN-PCM-05
Communication using objects and symbols
SN-PCM-05-A
Communication using objects and symbols: Objects of Reference
SN-PCM-05-B
Communication using objects and symbols: Blissymbols
SN-PCM-05-C
Communication using objects and symbols: Rebus symbols
SN-PCM-06
Communication based on body language and touch
SN-PCM-06-A
SN-PCM-06-B
Communication based on body language and touch: Body
language
Communication based on body language and touch: Tadoma
SN-PCM-98
Other preferred communication method (specify separately)
SN-PCM-99
Preferred communication method not known
LCVProcess
Focus
SL(ppp)-PRF
List of locally defined Process Focuses (e.g. Mental Health,
Learning Disability, Substance Misuse, etc.).
CVProcess
InvolvementType
SN-PIT
SN-PIT-01
List of involvement types in relation to a process. At the top level,
a person can be involved as a Subject, a Professional or an
associated person. Professionals are further divided into “lead”
and “other” professionals. Additional distinctions can be added
locally below any of the national types.
Involvement as primary subject
SN-PIT-02
Involvement as professional
SN-PCM-01-B
SN-PCM-01-C
SN-PCM-03-B
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 180
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
SN-PIT-02-A
Involvement as professional: Involvement as lead professional
SN-PIT-02-B
SN-PIT-02-Z
Involvement as professional: Involvement as referring / requesting
professional
Involvement as professional: Involvement as “receiving”
professional
Involvement as professional: Involvement as “consulted”
professional
Involvement as professional: Involvement as other professional
SN-PIT-03
Involvement as associated person
LCVProcess
Status
SL(ppp)-PRS
List of locally defined Process Statuses (e.g. Cancelled,
Suspended, Awaiting Specialist Assessment, etc.).
CVProcessTo
Form
EN-PTF
Defines the relationship between a Form and a Process
EN-PTF-01
Form is created in Process
EN-PTF-02
Form is updateable input to Process
EN-PTF-03
Form is read-only input to Process
SN-PRT
Provisional list of Process Types
SN-PRT-01
Making an Inter-Agency Referral / Request for Assistance
SN-PRT-02
SN-PRT-03
Screening / Processing a Received Referral / Request for
Assistance
Community Care Assessment and / or Care or Service Planning
SN-PRT-04
Children’s Assessment and / or Care or Service Planning
SN-PRT-05
Justice Assessment
SN-PRT-06
Financial Assessment
SN-PRT-07
Assessment under Mental Health Legislation
SN-PRT-08
Other Assessment and / or Care or Service Planning
SN-PRT-09
Care Package Procurement and Management
SN-PRT-10
Service Provision
SN-PRT-11
Routine or Planned Review
SN-PRT-17
Child Protection Investigation
SN-PRT-18
Child Protection Inquiry
SN-PRT-13
Other Investigation or Inquiry
SN-PRT-14
Legal process
SN-PRT-15
Request for Service(s)
SN-PRT-16
Request for Specialist Assessment
SN-PRT-19
Sharing a Concern
SN-PRT-20
Placement
SN-PRT-21
Admission
SN-PRT-22
Discharge
SN-PRT-23
Inter-Agency Discussion
SN-PRT-98
Locally defined process
SN-PRT-12
Investigation or Enquiry (Child Protection)
SL(ppp)-PRR
Role of Professional in relation to Subject.
SN-PIT-02-C
SN-PIT-02-D
CVProcessType
XXX OLD XXX
LCVProfessional
Role
Values determined by local Partnership
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 181
Transformational Technologies Division
Controlled
Vocabulary
CVQuestionData
Type
Code
Value
EN-QDT
EN-QDT-01
Data types applicable to the response value expected by a Form
Question, when this is not a CV value. Note that this CV differs
slightly from CVExtensionDataType, which has a different
purpose. The relevance here is to formatting for display in an end
user application.
String
EN-QDT-02
True/false
EN-QDT-03
Date
EN-QDT-04
DateTime
EN-QDT-05
Time
EN-QDT-06
Integer
EN-QDT-07
Numeric
EN-QDT-08
Percentage
EN-QDT-09
Fraction
EN-QDT-10
Currency
CVQuestion
Source
EN-QNS
This is a nationally defined CV which identifies national datasets
and other standard sources of Form questions, but the range of
values is likely to expand substantially as the eCare Programme
evolves. For this reason, existing values are not documented
here. They include the standard SSA-IoRN questionnaire.
CVRegistration
Category
SN-RGC
CVRelationship
XXX OLD XXX
CVReligion
SN-RGC-01
Failure to thrive
SN-RGC-02
Physical neglect
SN-RGC-03
Physical injury
SN-RGC-04
Sexual abuse
SN-RGC-05
Emotional abuse
SN-RLT
Relationship of associated person to Subject
SN-RLT-01
Spouse / Civil partner
SN-RLT-03
Partner
SN-RLT-04
Polygamous partner
SN-RLT-05
Parent
SN-RLT-05-A
Parent: Biological parent
SN-RLT-05-B
Parent: Foster parent
SN-RLT-05-C
Parent: Step parent
SN-RLT-05-D
Parent: Adoptive parent
SN-RLT-06
Guardian
SN-RLT-07
Child
SN-RLT-08
Sibling
SN-RLT-09
Other blood relative
SN-RLT-10
Other relative-in-law
SN-RLT-98
Other
SN-RLT-99
Not known
SN-RLT-02
Civil partner
SN-REL
SN-REL-00
None
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 182
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
SN-REL-01
Church of Scotland
SN-REL-02
Roman Catholic
SN-REL-03
Other Christian (specify)
SN-REL-04
Buddhist
SN-REL-05
Hindu
SN-REL-06
Muslim
SN-REL-07
Jewish
SN-REL-08
Sikh
SN-REL-97
Not disclosed
SN-REL-98
Another religion (specify)
SN-REL-99
Not known
SN-REL-R001
African Methodist
SN-REL-R002
Agape
SN-REL-R003
Agnostic
SN-REL-R004
Amish
SN-REL-R005
Ancestor Worship
SN-REL-R006
Anglican
SN-REL-R007
Animism
SN-REL-R008
Apostolic Church
SN-REL-R009
Asatru
SN-REL-R010
Assemblies of God
SN-REL-R011
Associate Synod
SN-REL-R012
Atheist
SN-REL-R013
Baha'i
SN-REL-R014
Baptist
SN-REL-R015
Belfast Chinese Christian Church
SN-REL-R016
Believe in God
SN-REL-R017
Bible Pattern Church
SN-REL-R018
Brahma Kumari
SN-REL-R019
Brethren
SN-REL-R020
Brethren in Christ
SN-REL-R021
British Israelite
SN-REL-R023
Bulgarian Orthodox Church
SN-REL-R024
Catholic Apostolic Church
SN-REL-R025
Celtic Christian
SN-REL-R026
Celtic Orthodox Church
SN-REL-R027
Celtic Pagan
SN-REL-R028
Chapel
SN-REL-R029
Charismatic
SN-REL-R030
Child of God
SN-REL-R031
Chinese Church
SN-REL-R032
Chinese Religions
SN-REL-R033
Christadelphian
SN-REL-R034
Christian
SN-REL-R035
Christian Fellowship
SN-REL-R036
Christian Fellowship Church
SN-REL-R037
Christian Scientist
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 183
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
SN-REL-R038
Christian Spiritualist Church
SN-REL-R039
Church
SN-REL-R040
Church in Wales
SN-REL-R041
Church of All Religion
SN-REL-R042
Church of Christ
SN-REL-R043
Church of England
SN-REL-R044
Church of God
SN-REL-R045
Church of God of Prophecy
SN-REL-R046
Church of Harmony
SN-REL-R047
Church of Ireland
SN-REL-R048
Church of Jesus Christ of Latter Day Saints (Mormons)
SN-REL-R049
Church of Prophecy
SN-REL-R051
Church of the Living
SN-REL-R052
Church of the Living God
SN-REL-R053
Church of the Nazarene
SN-REL-R054
Church on the Way
SN-REL-R055
City Mission
SN-REL-R056
Coleraine Christian Centre
SN-REL-R057
Combined Methodist/Presbyterian Church
SN-REL-R058
Confucianist
SN-REL-R059
Congregational Church
SN-REL-R060
Cooneyite
SN-REL-R061
Coptic Orthodox Church
SN-REL-R062
Day Church of God
SN-REL-R063
Deist
SN-REL-R064
Disciples of Christ
SN-REL-R065
Divine Lightmission
SN-REL-R066
Druidism
SN-REL-R067
Druze
SN-REL-R068
Dutch Reformed Church
SN-REL-R069
Eastern Orthodox Church
SN-REL-R070
Eckankar
SN-REL-R071
Ecumenical
SN-REL-R072
Elim Church
SN-REL-R073
Emmanuel Mission
SN-REL-R074
Episcopalian
SN-REL-R075
Evangelical
SN-REL-R076
Evangelical Alliance
SN-REL-R077
Evangelical Presbyterian Church
SN-REL-R078
Evangelical Union
SN-REL-R079
Faith Mission
SN-REL-R080
Fellowship of Independent Evangelical Churches
SN-REL-R081
Four Square Gospel
SN-REL-R082
Free Church of Love
SN-REL-R083
Free Church of Scotland
SN-REL-R084
Free Evangelical Church
SN-REL-R085
Free Methodist
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 184
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
SN-REL-R086
Free Presbyterian
SN-REL-R087
Free Presbyterian Church of Scotland
SN-REL-R088
Free Presbyterian Church of Ulster
SN-REL-R089
Free Thinker
SN-REL-R090
Full Gospel Assembly
SN-REL-R091
Greek Catholic
SN-REL-R092
Greek Orthodox
SN-REL-R093
Hare Krishna
SN-REL-R094
Heathen
SN-REL-R096
House Church
SN-REL-R097
Humanist
SN-REL-R098
Independent
SN-REL-R099
Independent Evangelist
SN-REL-R100
Independent Methodist
SN-REL-R101
Interdenominational
SN-REL-R102
Internationalist
SN-REL-R103
Jain
SN-REL-R104
Jedi Knight
SN-REL-R105
Jehovah's Witness
SN-REL-R107
Lutheran
SN-REL-R108
Mennonite
SN-REL-R109
Methodist
SN-REL-R110
Methodist Church in Ireland
SN-REL-R111
Methodist Church in Wales
SN-REL-R112
Metropolitan Church
SN-REL-R113
Monk
SN-REL-R114
Moravian
SN-REL-R116
Mysticism
SN-REL-R117
Native American Church
SN-REL-R118
New Age
SN-REL-R119
Non Denominational
SN-REL-R120
Nonconformist
SN-REL-R121
None
SN-REL-R122
Non-subscribing Presbyterian
SN-REL-R123
Occult
SN-REL-R124
Orthodox Catholic Church
SN-REL-R125
Orthodox Church
SN-REL-R126
Orthodox Presbyterian
SN-REL-R127
Other Religions
SN-REL-R128
Own Belief System
SN-REL-R129
Pagan
SN-REL-R130
Pantheism
SN-REL-R131
Pentecostal
SN-REL-R132
Presbyterian
SN-REL-R133
Presbyterian Apostolic
SN-REL-R134
Presbyterian Church in Ireland
SN-REL-R135
Presbyterian Church in Wales
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 185
Transformational Technologies Division
Controlled
Vocabulary
CVRiskType
Code
Value
SN-REL-R136
Presbyterian Secession Church
SN-REL-R137
Protestant
SN-REL-R138
Protestant (Mixed)
SN-REL-R139
Raja Yoga
SN-REL-R140
Rastafarian
SN-REL-R141
Rationalist
SN-REL-R142
Realist
SN-REL-R143
Reformed
SN-REL-R144
Reformed Presbyterian
SN-REL-R145
Religious Society of Friends (Quakers)
SN-REL-R147
Russian Orthodox Church
SN-REL-R148
Salvation Army
SN-REL-R149
Sant Mat
SN-REL-R150
Santeri
SN-REL-R151
Satanism
SN-REL-R152
Scientology
SN-REL-R153
Scottish Episcopal Church
SN-REL-R154
Scottish Presbyterian
SN-REL-R155
Secularist
SN-REL-R156
Serbian Orthodox Church
SN-REL-R157
Seventh Day Adventist
SN-REL-R159
Spiritualist
SN-REL-R160
Taoist
SN-REL-R161
Theism
SN-REL-R162
Tin Tao
SN-REL-R163
Ukrainian Orthodox Church
SN-REL-R164
Ukrainian Catholic
SN-REL-R165
Unification Church
SN-REL-R166
Unitarian
SN-REL-R167
Unitarian-Universalist
SN-REL-R168
United Brethren
SN-REL-R169
United Church of Canada
SN-REL-R170
United Free Church of Scotland
SN-REL-R171
United Reformed Church
SN-REL-R172
Universalist
SN-REL-R173
Unsectarian
SN-REL-R174
Vodun
SN-REL-R175
Whitewell Metropolitan Tabernacle
SN-REL-R176
Wicca
SN-REL-R177
Zoroastrian
SN-RKT
The CV has two separate functions. First, it distinguishes two
broad types of potential risk, sufficiently exceptional and important
to dictate contacting the named contact person to find out more
details (i.e. a significantly greater risk than is simply implied by
being a social care client). These two values are applicable either
to a child or to an adult. Secondly, it distinguishes six Child
Protection Messages, four being applicable to a child who is or has
been the subject of Child Protection activity, the fifth and sixth
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 186
Transformational Technologies Division
Controlled
Vocabulary
Code
Value
SN-RKT-01
being applicable to a child who is “linked” to a child who is or has
been the subject of Child Protection activity.
Subject is at risk
SN-RKT-02
A potential risk exists to others
SN-RKT-03
Child is the subject of a CP Investigation but is not currently on the
CP Register
Child is the subject of a CP Investigation and is currently on the
CP Register
Child is on the CP Register but is not the subject of a current CP
Investigation
Child was formerly (but is no longer) the subject of a CP
Investigation and / or on the CP Register
Child is linked to a child who is currently the subject of CP activity
SN-RKT-04
SN-RKT-05
SN-RKT-06
SN-RKT-07
CVSectionType
CVSexual
Orientation
CVStatusEpisode
Type
SN-RKT-08
Child is linked to a child who has been the subject of CP activity at
some time in the past
SN-SCT
SN-SCT-01
Applies to Sections within a Form, distinguishing between
“metadata” Sections and Sections that record form content data.
“Metadata” is further sub-divided into “public” metadata (which
may be of user interest) and “system” metadata (which may be
hidden) Some end user applications may handle these types of
data differently.
Form content data
SN-SCT-02
Public metadata
SN-SCT-03
System metadata
SN-SXO
SN-SXO-01
Heterosexual
SN-SXO-02
Gay man
SN-SXO-03
Lesbian
SN-SXO-04
Bisexual
SN-SXO-05
Not certain
SN-SXO-97
Not disclosed
SN-SXO-98
Other (i.e. none of the above)
SN-SXO-99
Not known
SN-SET
Provisional list of standard Status Episode types.
SN-SET-01
Marital status
SN-SET-02
Employment status
SN-SET-03
Hospital inpatient stay
SN-SET-04
Care home stay
SN-SET-05
Stay in other residential accommodation
SN-SET-06
SN-SET-07
Period of specialist treatment, therapy, counselling or behaviour
management
Training involvement
SN-SET-08
Work experience
SN-SET-10
Educational attendance
SN-SET-11
Legal status
SN-SET-12
Looked after or accommodated episode
SN-SET-13
Child protection registration
SN-SET-98
Locally defined status episode type
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 187
Transformational Technologies Division
Controlled
Vocabulary
XXX OLD XXX
Code
Value
SN-SET-09
Developmental or medical status
CVStudentStage
SN-STS
CVTenureType
CVVerification
Level
SN-STS-P1
Primary 1 P1
SN-STS-P2
Primary 2 P2
SN-STS-P3
Primary 3 P3
SN-STS-P4
Primary 4 P4
SN-STS-P5
Primary 5 P5
SN-STS-P6
Primary 6 P6
SN-STS-P7
Primary 7 P7
SN-STS-S1
Secondary 1 S1
SN-STS-S2
Secondary 2 S2
SN-STS-S3
Secondary 3 S3
SN-STS-S4
Secondary 4 S4
SN-STS-S5
Secondary 5 S5
SN-STS-S6
Secondary 6 S6
SN-STS-S7
Secondary S7
SN-STS-S8
Secondary S8
SN-STS-S9
Secondary S9
SN-STS-AD
Adult AD
SN-STS-SP
Pupils at all stages in Special Schools SP
SN-TEN
SN-TEN-00
No tenure
SN-TEN-01
Owned by data subject (single or joint ownership)
SN-TEN-01-A
Owned: Owned Outright
SN-TEN-01-B
Owned: Owned Mortgaged
SN-TEN-01-C
Owned: Part Owned/Part Rented
SN-TEN-02
Social Rented
SN-TEN-02-A
Social Rented: LA Rented – Standard
SN-TEN-02-B
Social Rented: LA Rented – Temporary
SN-TEN-02-C
Social Rented: Social Housing – Temporary
SN-TEN-02-D
Social Rented: Social Housing - Rented
SN-TEN-03
Private Accommodation Arrangements
SN-TEN-04
Tied Housing
SN-TEN-05
Institutional Living
SN-TEN-98
Other
SN-TEN-99
Not Known
SN-VRF
SN-VRF-00
Verification levels are taken from the GDSC. The meaning of each
level varies with the attribute to which verification is applied (e.g.
birth date, death date, marital status, etc.)
Level 0
SN-VRF-01
Level 1
SN-VRF-02
Level 2
SN-VRF-03
Level 3
SN-VRF-04
Level 4
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 188
Transformational Technologies Division
Controlled
Vocabulary
Code
CVVisitType
SN-VST
Value
SN-VST-01
Visit at request of another agency/person
SN-VST-02
Visit as a response to an expression of concern.
SN-VST-03
Visit as a response to an emergency.
SN-VST-04
Visit as part of a Care Plan
SN-VST-05
To review progress
SN-VST-98
Other
13.2 Deprecated CVs
As explained at the start of section 13.1 above, an entire CV may be deprecated. Currently
deprecated CVs are documented in the following table.
Controlled
Vocabulary
Code
CVAllergen
SN-ALL
Value
XXX OLD XXX
SN-ALL-00
None
XXX OLD XXX
SN-ALL-10
Drug Allergy
XXX OLD XXX
SN-ALL-10-1A
Drug Allergy: Antibiotics
XXX OLD XXX
SN-ALL-10-1B
Drug Allergy: Anaesthetic Drugs
XXX OLD XXX
SN-ALL-10-1C
Drug Allergy: Intravenous contrast media
XXX OLD XXX
SN-ALL-10-1D
Drug Allergy: Opioid analgesics
XXX OLD XXX
SN-ALL-10-18
Drug Allergy: Other drugs
XXX OLD XXX
SN-ALL-20
Food Allergy
XXX OLD XXX
SN-ALL-20-2A
Food Allergy: Egg
XXX OLD XXX
SN-ALL-20-2B
Food Allergy: Fish
XXX OLD XXX
SN-ALL-20-2C
Food Allergy: Milk
XXX OLD XXX
SN-ALL-20-2D
Food Allergy: Peanuts
XXX OLD XXX
SN-ALL-20-2E
Food Allergy: Pulses (other that peanuts)
XXX OLD XXX
SN-ALL-20-2F
Food Allergy: Sesame
XXX OLD XXX
SN-ALL-20-2G
Food Allergy: Shellfish
XXX OLD XXX
SN-ALL-20-2H
Food Allergy: Tree Nuts (e.g. Brazil nut, almond, hazelnut)
XXX OLD XXX
SN-ALL-20-28
Food Allergy: Other foods
XXX OLD XXX
SN-ALL-30
Serum Allergy
XXX OLD XXX
SN-ALL-30-3A
Serum Allergy: ABO incompatibility
XXX OLD XXX
SN-ALL-30-3B
Serum Allergy: Rhesus incompatibility
XXX OLD XXX
SN-ALL-30-3C
Serum Allergy: Immunisation
XXX OLD XXX
SN-ALL-30-38
Serum Allergy: Other serum
XXX OLD XXX
SN-ALL-40
Venom Allergy
XXX OLD XXX
SN-ALL-40-4A
Venum Allergy: Bee or wasp venom
XXX OLD XXX
SN-ALL-40-48
Venum Allergy: Other venoms
XXX OLD XXX
SN-ALL-50
Other contact allergy
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 189
Transformational Technologies Division
Controlled
Vocabulary
XXX OLD XXX
Code
Value
SN-ALL-50-5A
Other contact allergy: Animals
XXX OLD XXX
SN-ALL-50-5B
XXX OLD XXX
SN-ALL-50-5C
Other contact allergy: Chemical Products (including dyes and
adhesives)
Other contact allergy: Cosmetics
XXX OLD XXX
SN-ALL-50-5D
Other contact allergy: Dusts
XXX OLD XXX
SN-ALL-50-5E
Other contact allergy: House mite
XXX OLD XXX
SN-ALL-50-5F
Other contact allergy: Latex
XXX OLD XXX
SN-ALL-50-5G
Other contact allergy: Metal (e.g. Nickel)
XXX OLD XXX
SN-ALL-50-5H
Other contact allergy: Plants
XXX OLD XXX
SN-ALL-50-5j
Other contact allergy: Pollen
XXX OLD XXX
SN-ALL-50-58
Other contact allergy: Other contact allergies
XXX OLD XXX
SN-ALL-70
Not disclosed
XXX OLD XXX
SN-ALL-98
Other Allergy (not otherwise specified)
XXX OLD XXX
SN-ALL-99
Not known
SN-CHD
Factors pertinent to a child’s development or health.
CVChildhood
Difficulty
XXX OLD XXX
SN-CHD-DL01
Sensory – Significant hearing impairment
XXX OLD XXX
SN-CHD-DL02
Sensory – Significant visual impairment
XXX OLD XXX
SN-CHD-DL03
Significant physical or motor impairment
XXX OLD XXX
SN-CHD-DL04
Significant language and speech disorder
XXX OLD XXX
SN-CHD-DL05
Social emotional and behavioural difficulties
XXX OLD XXX
SN-CHD-DL07
XXX OLD XXX
SN-CHD-DL09
Specific learning difficulties in language and or mathematics
(including dyslexia)
Moderate learning difficulties
XXX OLD XXX
SN-CHD-DL10
Severe learning difficulties
XXX OLD XXX
SN-CHD-DL11
Profound learning difficulties
XXX OLD XXX
SN-CHD-DL12
Autistic spectrum disorder
XXX OLD XXX
SN-CHD-DL13
Complex or multiple impairments – Dual sensory impairment
XXX OLD XXX
SN-CHD-DL14
XXX OLD XXX
SN-CHD-DL15
XXX OLD XXX
SN-CHD-DL16
XXX OLD XXX
SN-CHD-DL98
Complex or multiple impairments – Moderate learning difficulties
and significant additional impairments or disorders
Complex or multiple impairments – Severe learning difficulties and
significant additional impairments or disorders
Complex or multiple impairments – Profound learning difficulties
and significant additional impairments or disorders
Other difficulty in learning
XXX OLD XXX
SN-CHD-MD01
Medically diagnosed asthma
XXX OLD XXX
SN-CHD-MD02
Allergy
XXX OLD XXX
SN-CHD-MD03
Type 1 Diabetes Mellitus
XXX OLD XXX
SN-CHD-MD04
Type 2 Diabetes Mellitus
XXX OLD XXX
SN-CHD-MD05
Gestational Diabetes Mellitus
XXX OLD XXX
SN-CHD-MD06
Maturity Onset of Diabetes of Youth (MODY)
XXX OLD XXX
SN-CHD-MD07
Other Diabetes mellitus
XXX OLD XXX
SN-CHD-MD98
Other significant health condition
XXX OLD XXX
SN-CHD-MY01
Mobility – Head control
XXX OLD XXX
SN-CHD-MY02
Mobility – Sitting
XXX OLD XXX
SN-CHD-MY03
Mobility – Standing
XXX OLD XXX
SN-CHD-MY04
Mobility – Walking
XXX OLD XXX
SN-CHD-MY05
Mobility – Managing stairs
XXX OLD XXX
SN-CHD-MY06
Mobility – Picking self up
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 190
Transformational Technologies Division
Controlled
Vocabulary
XXX OLD XXX
Code
Value
SN-CHD-MY07
Mobility – Running
XXX OLD XXX
SN-CHD-MY08
Mobility – Balance and coordination
XXX OLD XXX
SN-CHD-PC01
Personal care – Feeding/drinking
XXX OLD XXX
SN-CHD-PC02
Personal care – Toileting
XXX OLD XXX
SN-CHD-PC03
Personal care – Washing
XXX OLD XXX
SN-CHD-PC04
Personal care – Dressing
XXX OLD XXX
SN-CHD-PC05
Personal care – Ability to go out alone
XXX OLD XXX
SN-CHD-PC06
Personal care – Personal safety
CVCPEnquiry
Agency
XXX OLD XXX
SN-CEA
SN-CEA-01
Police
XXX OLD XXX
SN-CEA-02
Social Work
XXX OLD XXX
SN-CEA-03
Joint Police and Social Work
CVCPEnquiry
Outcome
XXX OLD XXX
SN-CEO
SN-CEO-00
No further action
XXX OLD XXX
SN-CEO-01
Child Protection Conference
XXX OLD XXX
SN-CEO-02
Support services as alternative to CP Conference
XXX OLD XXX
SN-CEO-03
Child Protection Order
XXX OLD XXX
SN-CEO-04
Exclusion Order
XXX OLD XXX
SN-CEO-05
Assessment Order
CVOutlook
SN-OUT
XXX OLD XXX
SN-OUT-01
Normal / good
XXX OLD XXX
SN-OUT-02
Likely to improve
XXX OLD XXX
SN-OUT-03
Likely to remain constant (i.e. unlikely to improve)
XXX OLD XXX
SN-OUT-04
May deteriorate
XXX OLD XXX
SN-OUT-05
Likely to deteriorate
XXX OLD XXX
SN-OUT-06
Uncertain prognosis
XXX OLD XXX
SN-OUT-07
Not assessable
XXX OLD XXX
SN-OUT-08
Not assessed
CVSeverityStatus
SN-SVS
XXX OLD XXX
SN-SVS-01
Appropriate for age
XXX OLD XXX
SN-SVS-02
Mild problem(s)
XXX OLD XXX
SN-SVS-03
Moderate problem(s)
XXX OLD XXX
SN-SVS-04
Severe problem(s)
XXX OLD XXX
SN-SVS-05
Profound problem(s)
XXX OLD XXX
SN-SVS-06
Not assessable
XXX OLD XXX
SN-SVS-07
Not assessed
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 191
Transformational Technologies Division
Appendix A - Derived Requirements
As part of the overall eCare Architecture Description, the content of this document produces
constraints and technical requirements. All derived requirements are assumed to be at ‘Not
Agreed’ status and have no priority. These are documented below.
Reference
Description
A-0001
Local eCare Partnerships are responsible for extending the Multi-Agency Store Data
Model to meet any additional local requirements
A-0002
Local eCare Partnerships are responsible for populating their MAS implementation
with initial person and index data
A-0003
Persons who are the primary subject of inter-agency data sharing within the MAS
must be matched to the national citizen reference number employed by eCare; a
partner agency may only view MAS subject data if it has previously matched its own
local identifier for the subject to this reference number (and has created an entry in
the MAS index)
A-0004
Following an initial match, a dummy Person record is created along with the first
index entries for a subject; the Person record will be populated with data (and a
Subject record will be created) only at the point where an explicit decision is taken to
share information
A-0005
Persons who are not the primary subject of inter-agency data sharing (professionals
and associated person) may be matched to the national citizen reference number, but
they must in any case have at least one entry in the MAS index (this holding a unique
local identifier used by the agency system that stored the person on the MAS)
A-0006
The MAS Primary Index is not made available to partner agency systems; any
external identifiers for persons that are required as shareable data items will be made
available through a separate entity
A-0007
Local eCare Partnerships are responsible for populating their MAS implementation
with initial professionals and their relationship to citizens
A-0008
Persons will initially be created with both Read and Update access, but may
subsequently be disabled
A-0009
Local eCare Partnerships are responsible for mapping their local data to the
structures described in the Multi-Agency Store Data Model
A-0010
Local eCare Partnerships are responsible for assigning a locally agreed range of
values to any local Controlled Vocabularies required for the Data Model
A-0011
Each Controlled Vocabulary and each CV Value should be assigned a code that is
unique within the eCare system
A-0012
Unless otherwise indicated, all entities and attributes (excluding key candidates)
described by the Multi-Agency Store Data Model are optional in the sense that data
may or may be recorded therein
B-0001
Local partnerships are free to interpret the high-level “national” Process Types in the
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 192
Transformational Technologies Division
way that best suits their local procedures
B-0002
Local Partnerships must adhere to the nationally defined structure for Process Types,
but are free to extend the typology downwards from any of the “national” Process
Types to include further locally recognised Process Types; the same point also
extends to the other typologies
B-0003
A partnership need not make use of a process type that is not recognised locally
B-0004
The Process typology is designed to meet the requirements of information sharing
between agencies within a partnership area; it is not intended to meet additional
classificatory requirements that are internal to a particular agency
B-0005
Where information is recorded and shared about events, this can be used by an
interface application to generate a chronology for the person who is the primary
subject of information sharing
B-0006
Status Episodes of a given Type may sometimes overlap
B-0007
Every Subject should have some marital and employment status at any given time,
but this does not apply to the remaining statuses for which Status Episode Types
exist
C-0001
Local eCare partnerships will be required to enter their own Form data (i.e. questions,
responses, formatting, business rules, etc.)
D-0001
Local eCare partnerships will be required to create an Interface System entry on MAS
for each Agency system or maintenance application for which authentication is
needed.
D-0002
Each incoming Message must be assigned a unique Message ID by the Interface
System which sends it (i.e. unique within that Interface System); a further Audit
Reference may also be appended (e.g. to identify the originating user).
D-0003
The Message ID must be recorded in the MAS Message Log entry for the incoming
message; it must also be recorded on the Message Log entry for an outgoing
response to that message.
D-0004
The Interface System may also supply an optional Audit Reference for an update
D-0005
Any Audit Reference passed through by the Interface System is recorded on the MAS
Audit Log.
D-0006
Several Messaging scenarios must be supported by the system, including both “on
demand” and “batch” Messaging (which may be with or without adaptor caching).
D-0007
Where Messaging is used, the sequence for an update Message is (1) insert
MessageLog entry, (2) insert AuditLog entry, (3) update MessageLog entry with
AuditLogID, (4) update the record or records for which the update request is issued.
D-0008
If an update fails, any rollback can go all the way through to insert AuditLog entry
D-0009
A database administrator who makes direct updates to the MAS must also be
recorded as an Interface System.
D-0010
The AuditReference should therefore become a mandatory and user-identifying item
in the situation where direct updates are made to the MAS by systems other than an
Agency system (e.g. by a database administrator).
D-0011
At a logical level, two attributes need to be added to each of the entities that have to
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 193
Transformational Technologies Division
be audited – AuditLogID, and ModifiedDate. In a physical implementation, however,
the InterfaceSystemID, the Interface System’s own MessageID (if Messaging is
employed) and its (usually) optional AuditReference need to be added to each entity
as well.
D-0012
For a given System, there can be at most one current security token of each type,
though a future token may also exist
E-0001
Changes to the MAS must be “notified” to participating agency systems.
E-0002
A central notification process forwards the notification to the appropriate recipient
systems.
E-0003
The notification cannot update local systems directly.
E-0004
The notification will not contain a copy of the changed data but simply an indication of
what data has been changed in the MAS.
E-0005
Notifications should not be prioritised or otherwise interpreted for significance by the
MAS but presented to the relevant agency systems for consideration.
E-0006
Agency systems will need to process notifications in terms of presentation to
practitioners.
E-0007
Processing of notifications by agency systems in terms of presentation to practitioners
will include identifying the relevant practitioner(s) to receive the notification.
E-0008
Processing of notifications by agency systems in terms of presentation to practitioners
will include the level of ‘granularity’ of the practitioner message (i.e. how much detail
to display and how many notifications should be displayed at a time for any given
subject).
E-0009
Local systems will have to map MAS attributes to locally meaningful descriptions.
E-0010
The granularity of MAS update notifications to local systems will reflect the granularity
of update Web Services.
E-0011
Agency systems will poll for notifications from a common area.
E-0012
Each notification will be addressed to those agency systems for which an index entry
exists for the subject of the notification.
E-0013
Once read, each notification for an agency should be logically (or physically)
“masked” to prevent that particular agency system re-reading it as a duplicate.
E-0014
Agencies will only be able to read notifications relating to subjects for which they have
previously had a successful match (i.e. in which they have an interest).
E-0015
Notifications will be created in a timely fashion (i.e. near real-time) and not as batch
updates.
E-0016
The MAS should not attempt to make any judgement as to the significance or priority
of a notification. Presentation to the practitioner (in terms of the delivered wording
and the granularity, in terms of level of detail, timing and volume) has to be controlled
by the target agency system.
E-0017
It should appear to the practitioner that notifications appear automatically.
E-0018
Notifications are recorded in the Audit Log.
E-0019
Notifications will not be acknowledged to the source system responsible for an
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 194
Transformational Technologies Division
update.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 195
Transformational Technologies Division
Appendix B - The SCDS Data Item Summary
The following table reproduces the Data Item Tabular Summary from the Scottish Social
Care Data Standards Manual [5].
Person Identification and Characteristics
Data Item
Sub Data Item
Description
Structured
Name
Person Title
e.g. Mr, Mrs, Miss, Ms, Dr, Rev,
Sir, Lady, Lord, Dame, etc
Person Family Name
Person Given Name
Person Preferred
Forename (if different)
Person Given Name 2/
Second Forename/
Other Forename(s)/
Person Given Name 3
Person Initials
Person Name Suffix
Person Name Status
Name Element Position
Start Date
End Date
Unstructured
Name
Person Full Name
Person Requested
Name
Person Birth
Date
Person
Death Date
Person
Identification
Person Birth Date
Person Birth Date
Verification
Person Death Date
Person Death Date
Verification
Unique Person Identifier
Example
The forename by which a person
prefers to be called if different
from first forename.
Used to record a person’s initials.
The “letters after the person’s
name”, eg. OBE, MBE, MBCS,
BSc, GM, JP, FRS etc
eg. registered name, married
name, maiden name.
Indicates the position each name
word holds within the entirety of
the record; particularly relevant
for people from Asian
communities where naming
conventions may differ from the
British norm.
The start and end dates for the
period during which name status
and person name are valid.
Dates should be attached to
name status and to all recorded
names.
This alternative to recording
structured name involves the
whole name being recorded as a
single character string with no
separately identified elements.
The name (or names) by which
the person wishes to be called
which differs from one or more of
the values in Title, Given
Name(s), Family Name and
Name Suffix fields.
Age and age bands can be
derived.
Level 0 (not verified); Levels 1 & 2
Level 0 (not verified); Levels 1, 2
&3
A number which can be used as a
common reference number
across information systems to
identify an individual or an
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Format
Mrs
Field
Length
35
Gibson
Joan
-
35
35
70
Text
Text
Text
Hazel
35
Text
-
35
Text
JHG
MSc
35
35
Text
Text
Married name
2
Pick list
1 = Title
2 = 1st f’name
3 = 2nd f’name
4 = surname
5 = suffix
2
Number
Married name
start date =
wedding date
Maiden name
end date =
wedding date
Mrs Joan
Hazel Gibson
MSc
min. 8
Date
min. 8
Date
70
Text
-
70
Text
11041956
min. 8
Date
Level 2
2
Pick list
-
min. 8
2
Date
Pick list
TBD
TBD
Text
Version: 1.4 Release
28/03/2008
Page 196
Transformational Technologies Division
Data Item
Sub Data Item
CHI number
NI number
Gender/Sex
Person Sex at Birth
Person Current Gender
Sexual
Orientation
Marital
Status
Ethnicity
Marital Status
Marital Status
Verification
Ethnic Group
Religion
Country of Birth
First Language
Interpretation assistance
indicator
Preferred
language
Address
Address (BS7666) or
UK Postal /Simple
Address
Postcode
UK Daytime Telephone
Number
UK Evening Telephone
Number
Telephone Number
Type
Internet E-Mail Address
Address Type
GP
Lives Alone
Person Title
Person Family Name
Person Given Name
Person Preferred
Forename (if different)
Description
Example
individual’s records.
The Community Health Index is a
population register used for
healthcare purposes in which
each person is uniquely identified
by the CHI number.
A reference number that is issued
to a person by the DWP/IR for
participants in the National
Insurance Scheme.
Sex at birth and current gender
are not necessarily the same.
An orientation towards persons of
the same sex, the opposite sex,
or both sexes.
There is a statutory, legal
requirement for public authorities
to collect data on ethnic group
under the Race Relations
(Amendment) Act 2000 in the
interests of eliminating racial
discrimination and promoting
equality of opportunity and good
race relations. Ethnic group and
all the other Ethnicity items are
also important for ensuring that
appropriate, person-focused,
needs-related care services are
delivered sensitively to
individuals.
A person's language of
preference may differ from their
identified first language.
Addresses conforming with
BS7666 will be stored in and
retrieved from an electronic
gazetteer
Alternatively, address can be
recorded in up to 5 lines of
unstructured text (minimum 2
lines).
Field
Length
Format
10
Structured
9
Structured
(GDSC)
Female
Female
Bisexual
1
1
2
Pick list
Pick list
Pick list
Level 3
1
2
Pick list
Pick list
up to 6 (2 +
4)
up to 6 (2 +
4)
up to 7
Pick list
2
2
Pick list
Pick list
2
Pick list
White Irish
None
Republic of
Ireland
English
None required
English
5x35
Text
8
35
2
Ref File
Character
string
Character
string
Pick list
joan.gibson@
hotmail.com
Normal
domicile
address
255
Text
2
Pick list
No
Dr
Linklater
Peter
Pete
up to 3
35
35
35
70
Yes/No
Text
Text
Text
Text
35
The forename by which a person
prefers to be called if different
from first forename.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Pick list
Gazetteer
One or both of these numbers
may be a mobile number.
Relates to the nature and status
of the address, eg. normal
domicile address, alternative
contact address.
Yes/No
Pick list
Version: 1.4 Release
28/03/2008
Page 197
Transformational Technologies Division
Data Item
Sub Data Item
Second
Forename/Given
name/Personal Name
Other Forename(s)
Person Name Suffix
Person Name Status
Name Element Position
Start Date
End Date
Person Full Name
GP General Medical
Council number
Registered
GP Practice
Code
Description
Example
The “letters after the person’s
name”, eg. OBE, MBE, MBCS,
BSc, GM, JP, FRS etc
eg. registered name, married
name, maiden name.
Indicates the position each name
word holds within the entirety of
the record; particularly relevant
for people from Asian
communities where naming
conventions may differ from the
British norm.
The start and end dates for the
period during which name status
and person name are valid.
Dates should be attached to
name status and to all recorded
names.
This alternative to recording
structured name involves the
whole name being recorded as a
single character string with no
separately identified elements.
This is the personal identification
number issued to each doctor by
the General Medical Council
(GMC).
Format
James
Field
Length
35
MD
35
35
Text
Text
Registered
Name
1 = Title
2 = 1st f’name
3 = 2nd f’name
4 = surname
5 = suffix
2
Pick list
2
Number
Registered
Name start
date = Date of
Birth
min. 8
Date
min. 8
Date
Dr Pete
Linklater MD
70
Text
3867549 (right
justified)
8
Reference
file
Address (BS7666) or
UK Postal/Simple
Address
UK Telephone Number
Telephone Number
Type
GP Practice Code
5x35
35
2
Each GP practice in Scotland is
identified by a unique GP practice
code.
Text
Gazetteer
Text
Character
string
Pick list
70234 (right
justified)
6
Reference
file
Example
Field
Length
Format
Associated People and Professionals
a) Associated Person
Data Item
Sub Data Item
Description
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Version: 1.4 Release
28/03/2008
Page 198
Transformational Technologies Division
Data Item
Sub Data Item
Person Role
Structured
Name
Person Title
Person Family Name
Person Given Name
Person Preferred
Forename (if different)
Person Given Name 2/
Second Forename/
Personal Name
Other Forename(s)/
Person Given Name 3
Person Name Suffix
Person Name Status
Name Element Position
Start Date
End Date
Unstructured
Name
Person Full Name
Address
Address (BS7666) or
UK Postal/Simple
Address
UK Daytime Telephone
Number
UK Evening Telephone
Number
Telephone Number
Type
Current
Gender
Person Birth
Date
Relationship
to
Relationship to
Client/Patient
Description
Example
Associated people are the people
who have a significant
involvement or relationship with
the person (e.g. main carer, next
of kin, keyholder, emergency
contact etc). The particular
involvement(s)/relationship(s) of
each associated person is(are)
indicated by the "Person Role"
data item.
Data should be entered for all
people significantly associated
with the subject, including
members of his/her household.
e.g. Mr, Mrs, Miss, Ms, Dr, Rev,
Sir, Lady, Lord, Dame, etc
The forename by which a person
prefers to be called if different
from first forename.
The “letters after the person’s
name”, eg. OBE, MBE, MBCS,
BSc, GM, JP, FRS etc
eg. registered name, married
name, maiden name.
Indicates the position each name
word holds within the entirety of
the record; particularly relevant
for people from Asian
communities where naming
conventions may differ from the
British norm.
The start and end dates for the
period during which name status
and person name are valid.
Dates should be attached to
name status and to all recorded
names.
This alternative to recording
structured name involves the
whole name being recorded as a
single character string with no
separately identified elements.
Format
Key holder
Field
Length
2
Mrs
35
Text
O’Reilly
Christine
Chrissie
35
35
70
Text
Text
Text
-
35
Text
-
35
Text
-
35
Text
Married name
2
Pick list
1 = Title
2 = 1st f’name
3 = surname
2
Number
Surname start
date =
wedding date
Maiden name
end date =
wedding date
Mrs Chrissie
O’Reilly
min. 8
Date
min. 8
Date
70
Text
5x35
Gazetteer
Text
35
2
Character
string
Character
string
Pick list
Female
1
Pick list
01011932
min. 8
Date
Parent
2
Pick list
35
The relationship of an Associated
Person to the data subject.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Pick list
Version: 1.4 Release
28/03/2008
Page 199
Transformational Technologies Division
Data Item
Sub Data Item
Description
Example
Client/Patien
t
Dependency
flag
Relationship Verification
Level 0 (not verified); Levels 1, 2,
3&4
Indicates whether the associated
person is dependent upon the
data subject.
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Format
Level 1
Field
Length
2
No
Up to 3
Yes/No
Pick list
Version: 1.4 Release
28/03/2008
Page 200
Transformational Technologies Division
b) Associated Professional
Data Item
Sub Data Item
Professional
Person Role
Structured
Name
Person Title
Person Family Name
Person Given Name
Person Preferred
Forename (if different)
Person Given Name 2/
Second Forename/
Personal Name
Other Forename(s)/
Person Given Name 3
Person Name Suffix
Person Name Status
Name Element Position
Start Date
End Date
Unstructured
Name
Person Full Name
Description
Example
Professionals are the people who
are already involved with the
person in a professional capacity.
(e.g. Social Worker, OT etc). The
particular role(s) carried out by
each professional is(are)
indicated by the “Professional
Person Role” data item.
Data for as many professionals as
required can be entered.
e.g. Mr, Mrs, Miss, Ms, Dr, Rev,
Sir, Lady, Lord, Dame, etc
The forename by which a person
prefers to be called if different
from first forename.
The “letters after the person’s
name”, eg. OBE, MBE, MBCS,
BSc, GM, JP, FRS etc
eg. registered name, married
name, maiden name.
Indicates the position each name
word holds within the entirety of
the record; particularly relevant
for people from Asian
communities where naming
conventions may differ from the
British norm.
The start and end dates for the
period during which name status
and person name are valid.
Dates should be attached to
name status and to all recorded
names.
This alternative to recording
structured name involves the
whole name being recorded as a
single character string with no
separately identified elements.
Employing
Agency
Professional
Contact
Address
Address (BS7666) or
UK Postal/Simple
Address
UK Daytime Telephone
Number
UK Evening Telephone
Number
Telephone Number
Type
Internet E-Mail Address
Format
Social Worker
Field
Length
35
Ms
35
Text
McAteer
Gill
-
35
35
70
Text
Text
Text
-
35
Text
-
35
Text
-
35
Text
Married name
2
Pick list
1 = Title
2 = 1st f’name
3 = surname
2
Number
min. 8
min. 8
Date
Date
Ms Gill
McAteer
70
Text
City of
Edinburgh
Social Work
Department
50
Text
5x35
Gazetteer
Text
35
2
Character
string
Character
string
Pick list
255
Text
35
joan.gibson@
hotmail.com
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Text
Version: 1.4 Release
28/03/2008
Page 201
Transformational Technologies Division
Social, economic and physical situation
Data Item
Sub Data Item
Accommodation
type
Dwelling Type
Tenure Type
Landlord Details
Person Title
Person Family Name
Person Given Name
Person Preferred
Forename (if different)
Person Given Name 2/
Second Forename/
Personal Name
Other Forename(s)/
Person Given Name 3
Person Name Suffix
Person Name Status
Name Element
Position
Start Date
End Date
Person Full Name
Description
The type of accommodation in
which the service user is
normally resident.
Is a description of the physical
structure in which someone
lives.
Indicates the basis on which an
individual occupies the property
in which they live.
e.g. Mr, Mrs, Miss, Ms, Dr,
Rev, Sir, Lady, Lord, Dame, etc
The forename by which a
person prefers to be called if
different from first forename.
The “letters after the person’s
name”, eg. OBE, MBE, MBCS,
BSc, GM, JP, FRS etc
eg. registered name, married
name, maiden name.
Indicates the position each
name word holds within the
entirety of the record;
particularly relevant for people
from Asian communities where
naming conventions may differ
from the British norm.
The start and end dates for the
period during which name
status and person name are
valid. Dates should be
attached to name status and to
all recorded names.
This alternative to recording
structured name involves the
whole name being recorded as
a single character string with
no separately identified
elements.
Organisation name
Address (BS7666) or
UK Postal/Simple
address
UK Telephone
Number
Telephone Number
Type
Example
Field
Length
6
Format
Flat
3
Pick list
Owned
3
Pick list
Mr
35
Text
Thomson
Gordon
-
35
35
70
Text
Text
Text
-
35
Text
-
35
Text
-
35
Text
Person
requested name
1 = Title
2 = 1st f’name
3 = surname
2
Pick list
2
Number
min. 8
min. 8
Date
Date
70
Text
70
Text
Gazetteer
Text
Mainstream
housing
Mr Gordon
Thomson
5x35
35
2
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Pick list
Character
string
Pick list
Version: 1.4 Release
28/03/2008
Page 202
Transformational Technologies Division
Data Item
Sub Data Item
Description
Field
Length
3
Format
3
Pick list
Format
No
Field
Length
Up to 3
Clear speech
3
Pick list
Visual
impairment
2
Pick list
Description
Example
Field
Length
Format
This covers any factors (other
than are indicated by other
data items in this dataset),
which it is vital to know about
in the early, pre-assessment
stages of dealing with the
person, including relevant
medical factors and cultural
issues.
Recent
suicide
attempt
Indicates the person’s
economic position in the labour
market in terms of whether he
or she is currently employed in
paid work, seeking employment
or, either by choice or age or
other restriction, not
economically active.
A household comprises one
person living alone, or a group
of people (not necessarily
related) living at the same
address with common
housekeeping - that is, sharing
either a living room or sitting
room or at least one meal a
day.
Employment Status
Household
Composition
Example
Self-employed
Adult couple
(nonpensionable)
Pick
list
Basic Needs
Data Item
Sub Data Item
Person Representative
Required
Preferred Communication
Method
Description
The method of communication
used by the person to make
themselves understood.
Impairment
Example
Yes/No
Background Information
Data Item
Crucial background
information
Sub Data Item
001-11334N-087
eCare Multi-Agency Store Data Model Version 2.9
Free text
Version: 1.4 Release
28/03/2008
Page 203