information architecture review - shb.scot.nhs.uk · information from allan small on girfec...

Information Architecture Review

DSTB / Health and Social Care Data Sharing

10 April 2013 Sopra Group

© Sopra Group, 2013 / / Status : Final / Ref. : 20121123-101157-PY

1/74

DSTB

Health and Social Care Data Sharing


Final Issue on 10 April 2013




© Sopra Group, 2013 / Status : Final / Ref. : 20121123-101157-PY

2/74

To

Johan Nolan, Eddie Turnbull, Ann Martin, Murdoch Carberry, Robin Wright, Stephen Pratt,

Stephen Duffy, Mark Daroch, DSTB Members

Document History

Version Date Update Origin Written by Verified by

Interim 00 29/11/2012 Draft for limited stakeholder review Phil Young Cheryl Trigg

John Bailey

Interim 01 7/12/2012 Updated as a result of:

Feedback from SG eHealth area

Information on Western Isles solution

Discussion with Stephen Pratt

Phil Young


Feedback from Finlay Stewart (Tayside)

Feedback from Stephen Duffy (Ayrshire)

Information from Allan Small on GIRFEC

Information on Borders proposals

Phil Young


Feedback from from Allan Small on GIRFEC

Minor changes to Borders detailed notes

Information on D&G approach

Phil Young

Final 10/4/2013 Updated as a result of information on Fife, Orkney and Forth Valley approaches

Phil Young





3/74

Summary

1. Introduction 5

2. Key Messages 6

3. Terms of Reference 7

4. Approach Taken 7

5. Summary of Information Shared 10

5.1. Summary Table 10

5.2. Common Locally Shared Information 11

5.2.1. Service User Demographics and Linked Professional Details 11

5.2.2. Assessments and Plans 11

5.2.3. Child Protection Alerts and Messages 12

5.2.4. GIRFEC Chronologies 13

5.3. Other Locally Shared Information 13

5.4. National Information Sharing 13

5.5. Status of Solutions 14

6. Approaches Taken 15

6.1. Stand-alone Central Store 16

6.1.1. Key Features 16

6.1.2. Planned Implementations 16

6.2. Integrated Central Store 16


6.2.2. Operational and Planned Implementations 18

6.3. Portal 18


6.3.2. Operational and Planned Implementations 19

6.4. Central Messaging Hub 19


6.4.2. Planned Implementations 20

6.5. Single Shared System 20


6.5.2. Operational Implementations 20

7. Common Features 20





4/74

8. Commercial Packages 22

9. Strategic Options 23

9.1. Spectrum of Solutions 23

9.2. Central Assistance and Coordination 23

9.3. National Child Protection Alerts 24

10. Short Term Actions 25

11. Maturity Model 25

11.1. Functions and Data 26

11.1.1. Service User Demographics 26

11.1.2. Professional Details and Consents 26

11.1.3. Assessments and Plans 26

11.1.4. Child and Adult Protection 27

11.1.5. GIRFEC Support 27

11.1.6. Access Control 28

11.1.7. Data Matching 29

11.1.8. Auditing 29

11.1.9. Reporting 29

11.1.10. General 29

11.1.11. Other Possible Data 30

11.2. Partners 30

11.3. Support 31

12. Benefits Summary 32

Attachment 1 - Interviewees 34

Attachment 2 – National Child Protection Alerts 35

Attachment 3 – Detailed Solution Catalogue 39





5/74

1. Introduction

This document is intended to summarise the current and planned approaches health and social care

data sharing in Scotland. Input was obtained from all Data Sharing Partnership areas in Scotland

(henceforth referred to as areas or regions) on the data that they shared, or planned to share, how

sharing was achieved, as well as the achieved and expected business benefits.

The review has identified immediate and long term options for further improving the sharing of health

and social care data at a regional and national level.

The report assumes that the current national eCare solution will be decommissioned in 2013.





6/74

2. Key Messages

A set of core data is being shared by the majority of areas reviewed (i.e. basic service use

demographics, professional contact details, various types of assessments and plans, child protection

alerts, and to a lesser extent, GIRFEC chronologies). See Section 5.2.

Various other types of data is being shared by a minority of areas, e.g. adult plans, service requests

and referrals. See Section 5.3.

Based on this commission there seems to be no general desire to share data nationally except child

protection messages / alerts. National level discussions are required on the requirements, solution

and architecture in this area. For example there may be architectural issues regarding the

connection of regional portal solutions to regional central store solutions that need to be considered.

See Section 5.2.3 and Attachment 2. UK wide child protection alert sharing, and Scottish data

sharing on Looked After Children was also seen as beneficial by some areas.

Various local data sharing solutions have been adopted that can be broadly categorised into 5 main

types, central store, portal, central messaging hub, stand-alone and single shared system (although

there overlaps between the solutions). There is no single correct solution. See Section 6.

Progress towards data sharing varies from mature live systems in a few areas, through systems in

various stages of planning and development, to a few areas with no firm plans for any data sharing.

Several key agency systems can be identified that will need to interface to multiple regional

solutions, in particular SWIFT (Northgate), CareFirst (OLM) and SEEMiS. Some form of national

vendor coordination and knowledge sharing could encourage synergies, reduce costs and speed up

implementation timescales. It is important to ensure that this generates leverage on suppliers rather

than one-size-fits-nobody outcomes. See Section 8.

There are number of achieved and expected benefits business benefits. See Section 12.

There is no national solution and no single approach for the further development of regional

solutions, but instead a spectrum of options comprising:

Development of solution from scratch

Extension of an existing regional health portal

Extension of regional portals or central stores to neighbouring regions and evolving as a single

solution

Copying all or some of an existing regional solution to other regions and evolving separately

(possibly using some different technologies)

Sharing discrete technical elements, for example interface software

Sharing of standardised information services at local, regional and national levels as appropriate

to the nature of the information/capability being delivered

Sharing lessons learned, best practice, standards etc.

These options are not necessarily exclusive. See Section 9.1 for more details.

There is a role for national organisations such as the Scottish Government and NHS NISG to provide

assistance and coordination to the regional integration efforts.

In the short term there are several activities that could be progressed quickly:





7/74

Organise a workshop involving 2 or 3 key people from each area, for the purpose of sharing best

practice, considering reuse and getting to know who’s doing what.

Encourage vendor cooperation and coordination

Review how the proposed vulnerable persons i6 programme being undertaken by the Police

Service in Scotland will support data sharing with health and local authority agencies.

Define a Maturity Model for evaluating local solutions in more detail, eg to benchmark data

sharing success, assess technical reusability and determine capability.

3. Terms of Reference

Sopra Group were commissioned by the DSTB in September 2012 to undertake a short 34 day review

of the procedures and information that frontline personnel need to support integrated health and social

care provision. The high level terms of reference for the study were:

The information sharing required to support the key in-scope Health and Social Care operational

procedures, i.e.:

The registration and management of pre-birth concerns

Child protection and adult protection messages and alerts

Integrated Assessment Form (IAF) / Single Shared Assessment (SSA) processes

The impact of GIRFEC across these key processes.

The key business drivers/benefits for Health and Social Care integration, by key stakeholder area

The high-level organisational information stores (i.e. data and documents) involved in local and

national exchanges of information.

The improved information flows required to support the key procedures

A proposed engagement plan and a high level roadmap

It was not intended that the study would review governance agreements (e.g. Information Sharing

Protocols) or governance arrangements (e.g. Data Sharing Partnerships).

4. Approach Taken

The review has involved face to face meetings with representatives from the organisations listed below

(see Attachment 1 for full details of the personnel involved). Input was also obtained from the Scottish

Government eHealth area, and NHS NISG. In the end a total of 10 operational and planned systems

were reviewed.

Organisation Main Inputs

Scottish Government eHealth National strategies, eCare background

NHS NISG National strategies, NISG involvement





8/74

Organisation Main Inputs

Scottish Government GIRFEC

Policy Area

National strategies, Children and Young Persons Bill detail.

Sopra Group Orion portal details

East Renfrewshire CHCP Local requirements and possible solutions

Lanarkshire DSP Local requirements, Lanarkshire eCare and national CPM

NHS Ayrshire & Arran Local requirements and the AYRshare solution

NHS GGC&C GGC&C requirements and the Orion Portal

Renfrewshire Council Local requirements and the Orion Portal

NHS Grampian Local requirements and the proposed Grampian solution

NHS Highlands Local requirements and the Highland SharePoint solution

NHS Lothian Local requirements and the Lothian CareFx Solution

NHS Tayside Local requirements and the proposed Tayside solution

Shetland Islands Council Local requirements and the Shetland SWIFT based solution

West Lothian Council Local requirements and the West Lothian C-me solution

Comhairle nan Eilean Siar Local requirements (via Scottish Government and Capita)

Borders Council Local requirements and proposed solution

NHS Dumfries & Galloway Local requirements and proposed solution

NHS Orkneys Local situation

NHS Fife Local requirements and proposed solution

NHS Forth Valley Local situation

In addition a considerable number of documents have been reviewed, both for specific solutions, e.g.

Statement of Requirements, Proposals, Business Requirements and PIDs, as well as various national

background documents.

To allow comparison of solutions a detailed profile of each solution was documented using the following

categories:

Partners involved

Current and planned interfaces

Service user / patient matching approach

Data shared

Functions provided

Approach taken to integration

User access method

Access control

Data volumes (expected and actual)

Planned features (i.e. reasonably firm plans)

Desirable features (wish list features)

mailto:[email protected]





9/74

History of the solution

General notes

Benefits of sharing

See Attachment 3 for the full catalogue. Additional detail on the data held was recorded where it was

readily available.

An interim summary of findings were presented to the DTSB meeting on November 30th 2012 and a

further update was given on the 24th January 2013.





10/74

5. Summary of Information Shared

5.1. Summary Table

Most of the solutions currently share, or plan to share, basic service use demographics, professional

contact details, various types of assessments and plans, and child protection messages / alerts.

Additionally there were a large number of other types of information that is shared by a minority of

organisations. It should be noted that the “Planned” category covers a wide range of situations, from

firm costed proposals to unscheduled wish-lists.

L = Live (non eCare) Le = Live (with eCare) T = In test P = Planned or Proposed

GG

&C

Lan

ark

sh

ire

West L

oth

ian

Lo

thia

n

Ayrs

hir

e

Taysid

e

Gram

pia

n

Hig

hla

nd

Sh

etla

nd

Bo

rders

Weste

rn I

sle

s

D&

G

Fife

Ork

neys

Fo

rth

Valle

y

Service user demographics T L L P T P L P

Associated professional details T L L P T P P

Child protection messages / alerts T L L P Le P Le P Le P L Le P Le P

Assessments and plans T L L P T P P L P P

GIRFEC style chronologies T L L P T P P

Case lists T L L T

Additional health data, eg KIS & ECS* P L P P

Carer Demographics L

Adult protection messages L

Pre birth concern messages L

Service requests L

Secure email L

IAFs and IRDs ** P L

Referrals L L

Register of interest L

Telecare assessments P

Automatic equipment prescriptions P

Adult chronologies P

My World Triangle Assessments & Child’s plan

P

Request for assistance P

Concerns (inc. child’s concerns) P P

Services delivered P

Missing Persons Alerts

Automatic synch of demographics

Looked after children indicator

A&E attendance sharing

Third sector data sharing

Fire and rescue sharing





11/74

Police sharing

* Additional health data may be available to health users of health portals such as Orion and CareFx.

KIS: Key Information Summary, ECS: Emergency Care Summary

** IAF: Integrated Assessment Form, IRD: Inter-agency Referral Discussion.

5.2. Common Locally Shared Information

5.2.1. Service User Demographics and Linked Professional Details

As can be seen from the table above most areas share some level of patient / service user

demographics (e.g. name, DoB, GP, addresses, relationships & carers, CHI number, other identifiers).

However the specific data shared varies. Some areas show data from 2 linked systems on the same

screen to allow comparisons.

Most areas also share basic details for linked professionals, e.g. name, organisation, contact details

(email and phone) and role (e.g. Lead Professional / Named Person).

5.2.2. Assessments and Plans

Various types of assessments and plans are currently being shared electronically, or are planned to be

shared in the near future, as detailed below.

There is no common national format for any of the document types and the contents are likely to vary

significantly between individual councils, and over time. For this reason, and because of the

complexity of the various types of documents, most areas do not try to extract data from the

documents but instead share documents in pdf or Word format. However some data is extracted by

West Lothian and documents are reconstructed by Lanarkshire and Lothian. Use of XML metadata for

documents is also common.

In the future the proposed Children and Young Person Bill which will be enacted in 2015 will suggest a

nationally agreed minimum data set for a child’s plan, chronology and a Well-being Concern form.

NHS GG&C Orion

Children's Integrated Assessment Framework and Shared Action Plan

Adult Standardised Shareable Assessment Forms

Lanarkshire eCare

Adult Shared Assessments (full Assessments, not just Practitioner Summaries). Assessment

types include long term conditions, mental health, learning disabilities, addictions and

substance misuse

Personal Outcome Plans

Care Plans

Child’s Single Agency Wellbeing Assessment and Plan

My World Triangle Assessments and Plan

Integrated Assessment and Plan

West Lothian C-me





12/74

IRDs (Inter-agency Referral Discussion),

Single Share Assessments (SSAs)

Specialist Assessments and Care & Support Plans

Telecare Assessment (Safe at Home)

Lothian CareFx

Child Plans

SSAs

Ayrshire AYRshare

Wide range of assessments and plans for service users

Highland

Multi Agency Children's Plans

Shetland

SSAs (includes involvements, reviews, needs and consents)

Some areas only share the final version of a document whilst others share initial and interim versions.

This commission found no desire to share assessments and plans between regions. Where permanent

cross-border movements occur there are generally satisfactory processes in place to securely transfer

documents to the new responsible authority.

5.2.3. Child Protection Alerts and Messages

Ten areas are locally sharing child protection messages and alerts, although there is significant variety

in the types of alerts shared, and the information in the messages. Shetland share their complete

Child Protection Register (although numbers are low).

NHD GG&C (Orion Portal)

Warning / hazard indicator

Child Protection Register indicator

Lanarkshire (local eCare)

Child Protection Messages (4 main protection messages, i.e. Investigation, Investigation and

on the CP Register, Registration and Past Activity, and the 2 linked person messages)

Pre-birth concern messages (linked to the mother)

Adult protection messaging

West Lothian (C-me)

Alerts (wide range of types: 18 SWIFT, 23 TrakCare and also Education messages)

Lothian (CareFx)

Child Protection Messages (4 main protection messages and the 2 linked person messages)

Child protection alerts from Trak and SWIFT hazards

Ayrshire (currently via national eCare but will be replaced by AYRshare)

Child Protection Messages

Grampian (national eCare but to be replaced)





13/74

Child Protection Messages (4 main protection messages, but not Linked Adult and Linked Child

messages).

Shetland

Child Protection Register is shared.

Borders (national eCare but to be replaced)

Child Protection Messages (6 types)

Tayside (national eCare but to be replaced)


Western Isles (national eCare)


5.2.4. GIRFEC Chronologies

A smaller number of areas share GIRFEC style chronologies of significant events in a child’s life (e.g.

date, type, title of event, recorded by, notes/action taken and a Red/Amber/Green code). Once shared

these chronologies can be integrated and all significant events in a child’s life at a particular point in

time can be viewed and assessed. The format of the chronologies are very similar with only a couple

of minor differences.

Lanarkshire eCare

West Lothian C-me

Ayrshire AYRshare

5.3. Other Locally Shared Information

As can be seen from the table in Section 5.1 a wide range of other data is also shared by one or two of

the areas reviewed, for example Service Requests, Referrals, Registers of Interests. West Lothian also

provides secure email between registered system users. There are also types of data that at least one

area have said they would like to share but are not currently being shared.

5.4. National Information Sharing

The study found very little appetite for national information sharing, with the exception of child

protection alerts. In this case there was a recognition that it would be beneficial if key NHS areas such

as Accident and Emergency, Child Protection specialist nurses, NHS Out of Hours and NHS Child

Protection Units could be given some indication that a child might be at risk. In general it was felt that

very little data needed to be shared, for example:

The minimum demographics needed to identify the child

An indication that there was an issue with the child. There was no consensus on the situation

that would trigger a national alert, e.g. just the four main protection messages, or being on the

child protection register, or a less precise criteria such a "vulnerable child". It maybe that any

national solution needs to leave this definition to the local source systems





14/74

Contact details for a linked professional or organisation.

Lanarkshire have proposed a limited proof of concept for cross-boundary CPM sharing with two

neighbouring authorities using a central matching index and message store.

See Attachment 2 for a summary of the proposed Lanarkshire solution and possible issues integrating

with regional solutions.

Some areas expressed a desire for UK wide child protection alert sharing; for Scottish data sharing on

Looked After Children; and for a way to efficiently share UK missing persons alerts. Potentially a

national child protection alert system could be extended to feedback notifications of hospital

attendances to social work and education systems, at the discretion of the health professional. It could

also incorporate notification of Girfec concerns.

The study found little awareness of the likely duties to be imposed on Local authorities and Health

Boards by the Children and Young Persons Bill due in 2015. All public bodies will be required to share

any information that they have, which may indicate a risk to a child’s well-being. In effect this

introduces a threshold where information must be shared far below that which is currently regarded as

Child Protection.

It is recommended that the requirements and options for cross border data sharing are properly

reviewed with key stakeholders with scrutiny on the merits and sustainability of each approach.

There may be an opportunity to share well-being concerns in a similar or identical manner as Child

Protection alerts.

5.5. Status of Solutions

The solutions reviewed are at various stages of development, as follows:

Organisation Status

Operational (excluding national eCare)

Lanarkshire DSP (local eCare) Operational solution, further enhancements planned. Considering

migrating from ClearSpan to Ensemble

Shetland Islands Council (SWIFT) Operational solution, further enhancements planned

West Lothian Council (C-me) Operational solution, further enhancements planned

POC / Development / Testing

NHS Ayrshire & Arran (AYRShare) Ready to start end-to-end testing with SAC SWIS and NHSAA

FACE when network linkages complete

NHS GGC&C (Orion) Go live Q1 2013, phase 2 in planning

NHS Highlands (SharePoint) System under development with a limited pilot planned for March

2013

NHS Lothian (CareFx) 1st POC completed October 2012. To be followed by a business

case for integration between NHS Lothian and all Lothian councils

Proposal






15/74

Organisation Status

NHS Grampian Proposal submitted for initial solution to replace eCare CPM using

Ensemble

NHS Tayside Proposal submitted for initial solution to replace eCare CPM

Borders Council Proposal submitted for solution to replace eCare CPM using same

Ensemble solution as Grampian.

Reviewing

Comhairle nan Eilean Siar and

NHS Western Isles

Using eCare for CPM and are considering options for an

alternative solution.

Dumfries and Galloway Considering using CareFx portal, Midis and dartEDM (Electronic

Document Management) system

Fife Considering the use of the CareFx portal to support sharing with

Fife social work.

Orkney No definite plans for regular electronic data sharing between

social work, NHS or education. Some health staff have access to

the Paris social work system.

Forth Valley No electronic data sharing in place. Work has taken place on

developing a clinical portal which could be expanded in the future.

Currently there is no funding available for data sharing and no

single point of responsibility.

6. Approaches Taken

The areas reviewed have, or propose to, adapt different solutions to sharing data, driven by different

local requirements, and different existing systems and infrastructure. However it is possible to identify

5 basic approaches, 2 of which allow data sharing but do not involve any system integration. These

models are not always mutually exclusive, for example a single shared system could be used in parallel

with a stand-alone central store to share different types of data. And a central store architecture could

exhibit some qualities of a portal and messaging Hub approach.

It is also possible that a stand-alone central store could evolve into an integrated central stored if the

architecture and infrastructure allows the development of electronic interfaces.

Given the diversity of existing and proposed solutions this study has not attempted to define a target

information architecture. The need for such an architecture and what it might look like need to be

debated by the key stakeholders who understand the issues involved.





16/74

Hig

hla

nd

Lan

ark

sh

ire

West L

oth

ian

Ayrs

hir

e

Gram

pia

n

Bo

rders

D&

G

Lo

thia

n

GG

&C

Fife

Taysid

e

Sh

etla

nd

Stand-alone Central Store Y

Integrated Central Store Y Y Y Y Y

Portal Y Y Y Y

Central Messaging Hub Y

Single Shared System Y

6.1. Stand-alone Central Store

6.1.1. Key Features

Centrally hosted database

No electronic links to agency systems (although view and update links could in theory be

implemented)

Direct browser based access allowing update and read access from any location provided

access security is sufficient

Separate logon (user ids can be set to the same as agency systems but not passwords)

6.1.2. Planned Implementations

Highland SharePoint Solution

6.2. Integrated Central Store

Example architecture:





17/74

Central Store Council Social

Work Systems NHS systems

Automatic or manual export of

New/updated/deleted data

Read response

View / update

NHS systems

Matching Index

Read request

Automatic or manual

Export of

new / updated /

deleted data

View /

update

Read response

Read request

NHS system

Read response Read request

Notification of

data change

Notification of data change

View

only

Audit Log

View audit

log

View central

store

Update matching index

6.2.1. Key Features

Based on a publisher/subscriber concept with a central data store and a central matching index

Details of new, updated or deleted data is automatically or manually exported from the linked

agency systems into a central database. Notifications of changed data can be sent to the

linked systems. Acknowledgements of reads can be sent back to the central store and read by

the linked systems.

A central matching index holds 2 or more identifiers from the linked agency systems. The

index normally includes a CHI number but this not essential. It is not essential to CHI seed the

agency systems but this can still be done to aid manual information sharing. Matching is

achieved by a combination of automatic and manual processes.

Access can be limited to the patient or service user context in the linked agency systems

(which ensures greater access control), but direct access to the central store is also possible

(which will involve some form of search by an identifier or demographic data, or a user case

list). Direct access to the store can be read only, or direct update may be allowed (as

implemented in AYRShare).





18/74

6.2.2. Operational and Planned Implementations

Lanarkshire eCare (using ClearSpan as an integration engine but considering its replacement

with Ensemble)

West Lothian Council C-me (using VisionWare MultiVue for central matching and integration)

Ayrshire AYRShare (using Ensemble for matching and integration)

Grampian (proposing to use Ensemble)

Borders (similar architecture to Grampian)

6.3. Portal


Council Social

Work Systems

Integration and

MatchingCouncil Social

Work Systems

NHS systems

Read response

View / update

NHS systems

Read request

View /

update

Read response

Read request

Portal Viewer

Access control

Audit log

View audit

log

Read requestRead response

6.3.1. Key Features

Based on request / response model with no central data store or matching index

Linked agency systems are seeded with CHI numbers using a combination of automatic and

manual processes

Access can be via the patient context in a linked agency system (by selecting a portal icon), or

by logging directly onto the portal. Direct logon may provide a list of the user’s cases, or a

search page. Search could be by CHI number or a minimum number of demographic details

Users have access to restricted sets of data depending on role

Extends existing NHS portals to give shared access to data from non-NHS systems





19/74

The Lothian CareFx solution could support deployment of eForms for update access, e.g. for

requests for services and additional notes

6.3.2. Operational and Planned Implementations

GG&C Orion Portal (using Rhapsody as the portal integration engine)

Lothian CareFx Portal (using Ensemble for integration)

Ayrshire and Arran are proposing to use Ensemble and Web Services to present multi-agency

information to the Orion Portal from AYRshare

Dumfries and Galloway are considering the use of the CareFx portal, although they may also

implement dartEDM as a central document repository.

Fife are considering using the CareFx portal in a similar way to NHS Lothian.

6.4. Central Messaging Hub


Message HubRouting rules

Retrieving rules

Agency

System AAgency

System B

View / update2 Broadcast

Message

View /

update

1 Broadcast Message (Agency A only)

1 Data request & response

Agency

System C

Viewer

Application

View messages

(Search client)

A

P

I

A

P

I

A

P

I

2 Data request

& response

2 Data request

& response

1 Messages

Agency D

View messages

(pre selected client)

1 Collaboration

Request or Lock Notification

2 Collaboration

Request

View /

update

Matching

Framework

2 Match Request /

Response

Manual matchingMatch

requests

4 Match Request /

Response

1 Match Request / Response

SCI Store

3 Match Request /

Response





20/74

6.4.1. Key Features

Uses a hub and spoke architecture utilising a small flexible API based on transmission of XML

messages via input and output streams

The message hub will provide the following functionality:

Agency system can post message and broadcast to other agency systems

Agency system can request information from other agency systems

Agency system can request other agency systems to work collaboratively on a dataset.

Actual data sharing is by the post or request methods

User index – the hub could access a virtual directory for each agency to allow messages to be

routed appropriately within each agency system, e.g. to users, mailboxes, teams etc

List of agencies – the hub could provide a list of agencies connected to it to support the

identification of the agency to route the message to

Linked agency systems would initially be pre-seeded with CHI numbers. New clients would

then be manually updated with a CHI number or use a matching framework that automatically

retrieves a CHI number from SCI Store using details provided, else passed for manual

matching.

6.4.2. Planned Implementations

Tayside (considering using Ensemble)

6.5. Single Shared System

6.5.1. Key Features

Information remains in a single agency system with no links to other systems

Update access is extended outside the normal user community provided access security is

sufficient, e.g. NHS staff are given access to SWIFT or social work staff to a health system

User access is carefully controlled to a limited subset of data with restricted search facilities

Associated agency systems may be seeded with CHI numbers to assist with manual record

identification.

6.5.2. Operational Implementations

Shetland Islands (using SWIFT)

7. Common Features

All the solutions described above present common functions (eg matching) and qualities (flexibility)

that need to be considered and implemented by any future data sharing solutions.





21/74

Record matching – Client / patient records from several agency systems needs to be quickly

matched with a high degree of certainty. As far as possible this needs to be automatic with

minimal manual intervention.

CHI numbers are the best means of achieving satisfactory levels of matching and are used by

all the areas reviewed with the exception of Highland. However there may be a minority of

cases that require matching with no health involvement, eg between Education and Social

Work. In this situation the solution may need to support matching without CHI numbers.

Alternatively CHI numbers could still be used – subject to central guidance on their use where

health is not directly involved. None of the areas reviewed were considering using the Citizen’s

Account Unique Citizen’s Reference Number (UCRN).

Audit log – A comprehensive audit log of data updates and views is required, with a means to

quickly report on the log and identify misuse.

Management reporting – As solutions mature they could become an increasing source of

management information, e.g. identifying differing levels of sharing and trends.

Secure access – All solutions need a secure means to link systems. In many cases this is

based on secure links between the NHS N3 network and Local Authority networks to support

integration of health, social work and education systems. However further sharing with Police

and Fire & Rescue systems may require additional links. The effort required to implement

these links should not be underestimated. Links need to have sufficient capacity, availability

and reliability. The SWAN initiative may provide a good solution in the medium term.

Access by the Third Sector, private companies and the public – Giving access to non-agency

users has many benefits but presents several challenges which have not been widely

addressed. An architecture that works well with agencies may not lend itself to this purpose.

Access needs to be very secure and tightly managed. As increasingly the third sector are

contracted or commissioned to supply services, this issue will continue to occur.

User Access – There are several possible models for user access:

Individual professionals linked to service user cases

By role (e.g. Lead Professional, Named Person, Health Worker, Social Worker)

By agency (e.g. allow access by Health but not Education to a case

To areas of data (e.g. types of health data)

To subsets of data (e.g. limited or full assessment access)

Service user restrictions (i.e. no sharing allowed at all for a specified individual)

Emergency “break the glass” access

However access controls need to be kept as simple as possible and be consistent within the

region.

Scalability - Solutions need to be scalable to allow the integration of many agency systems, for

example an eventual solution for GG&C would need to allow data to be shared between up to 8

local authority systems, education systems, housing systems, a central police system,

secondary care systems, 2 types of GP systems and a fire and rescue system.

Flexibility - Solutions need to be flexible enough to support a variety of constantly changing

plans and assessments. They also need to be able to support regular upgrades to agency

systems and, and occasional replacements.





22/74

8. Commercial Packages

There are a number of common agency systems where at least one region is planning to develop an

interface, or has already implemented an interface. The number is likely to increase as other areas

implement shared solutions. There are obvious opportunities to share knowledge, develop common

interface software, and work in a more joined up fashion with vendors. For example SEEMiS have

recently issued a proposal for a universal API for exchanging information with external agencies – the

Single Lightweight Interface for Data Exchange (SLIDE). It does not appear that Northgate or OLM

have made any similar proposals.

System Users Area

SWIS Social Work Lanarkshire and Ayrshire (planned)

SWIFT Social Work Ayrshire (planned), Renfrewshire (planned), West Lothian, Lothian (planned), Tayside (planned), Fife (considered)

CareFirst Social Work West Dunbartonshire (planned) and Ayrshire (planned), Tayside (planned), Grampian (Planned)

Frameworki Social Work Borders (planned), D&G (possible)

EMS Education West Lothian

SEEMiS Education Lanarkshire, West Lothian, Ayrshire (planned), Tayside (planned), Grampian (planned), Borders (planned)

Phoenix Education Grampian (planned)

FACE Health CN Lanarkshire

Orion Portal Health portal Renfrewshire

CNIS Health CN Renfrewshire (planned)

INPS GPs Lanarkshire

EMIS GPs Lanarkshire (planned)

MIDIS * Health Lanarkshire and Tayside (planned), D&G (possible). Other MIDIS consortium partners are NHS Fife, Forth Valley, D&G and Highland (although all have configured MIDIS differently).

PIMS Health Lanarkshire

Adastra Health NHS24 Lanarkshire

Academy Housing West Lothian

TrakCare PMS

Health Implemented by NHS Lothian, NHS GG&C, NHS Grampian, NHS A&A, NHS Borders and NHS Lanarkshire.

Additionally there are a further 4 Boards planning to take on Trakcare. NHS Highland have signed a contract and are due to start implementation in April. NHS Orkney are in the final stages of agreeing their business plan which involves a hosting arrangement with NHS Grampian. NHS Shetland and the NWTC are at an early stage of consideration.





23/74

9. Strategic Options

9.1. Spectrum of Solutions

There is no single approach for the further development of regional solutions, but instead a spectrum

of solutions:

Development of a solution from scratch, ideally based on a package or framework used by

other areas

Extending an existing regional health portal to integrate with other non-health agency systems

Copying all or some of an existing regional solution to other regions and evolving separately

(possibly using some different technologies)

Sharing discrete technical elements, for example interfaces to agency systems, or

transformation technology

Sharing of standardised information services at local, regional and national levels as

appropriate to the nature of the information/capability being delivered

Extending an existing regional portal, central store or messaging solution to neighbouring

regions and evolving as a single solution.

Sharing lessons learned, best practice, standards etc.

These options are not necessarily mutually exclusive, for example lessons learned could be shared as

well as discrete technical elements.

Possible sharing options exist in some areas. For example:

The proposed Grampian Ensemble based central store solution could be extended to include

Borders agencies as they are both TrakCare PMS users, with similar initial requirements for

CPM sharing. Highland, Orkney and Shetland are also TrakCare PMS users with inter-regional

patient movements.

A full Lothian solution would require integration between the planned Lothian CareFx portal and

the West Lothian C-me solution.

The CareFx regional portal includes Lothian, Borders, Fife and Dumfries and Galloway.

MIDIS consortium partners are Lanarkshire, Tayside NHS Fife, Forth Valley, D&G and Highland.

A solution for NHS GG&C is important because of the 1.2 million core population in the area and the

number of Local Authorities (six plus parts of North and South Lanarkshire). Delivering portals for NHS

Lothian and NHS GG&C would cover nearly 2 million people, or nearly 40% of the Scottish population.

A move to a flexible, interoperable network of local / regional / national data services should be

informed by an Information Architecture that would be agreed by all the areas currently developing

solutions.

9.2. Central Assistance and Coordination

There is role for national organisations such as the DSTB, Scottish Government and NHS NISG to

provide assistance and coordination to the regional integration efforts, in particular:





24/74

Assistance with the communications infrastructure required for data sharing, including the

SWAN initiative in the medium term

Coordinating the relationships with the vendors of key agency systems such as Northgate, OLM

and SEEMiS

Identifying common interfaces wherever possible, publicising standards and guiding their

shared adoption. As mentioned in Section 8 SEEMiS have recently issued a proposal for a

universal interface for exchanging information with external agencies. It is important to ensure

that this central activity generates leverage on suppliers rather than a one-size-fits-nobody

outcome

Defining suggested standards and providing advice on good practice in technical areas such as

network connectivity and security, as well as applications security

Suggesting good practice in governance areas such as Information Sharing Protocols

Co-ordinating knowledge sharing between the regions

Tracking national progress with data sharing

Developing a National Information Architecture (if there is a national consensus that this is

desirable)

9.3. National Child Protection Alerts

As described in Section 5.4 above most areas saw a need for some form of national sharing of child

protection alerts, especially given the planned decommissioning of eCare CPM. Some form of national

structure is required to develop this initiative. Activities could include:

Identifying stakeholders

Define a national policy

Defining requirements, benefits and options

Agree a strategic architecture

Agreement on an outline solution. It is likely that any solution would need to be able to

interface with individual agency systems as well as the various regional sharing solutions.

Solutions will need to be scalable and sustainable.

Development of a Proof of Concept, involving links to at least 1 agency system, 1 central store

and 1 portal, involving at least 3 regions

Full development of a national solution

The possibility of using the Emergency Care Summary (ECS) system to display alerts to A&E

staff could be considered, although the ECS consent model (i.e. opt –out) is different to that

required for CP alerts (i.e. mandatory). However concerns or alerts may be raised by A&E staff

and require to be directed to the Child’s Named Person.

Central coordination to reduce costs by maximising reuse and working with vendors in a joined

up fashion

See Attachment 2 for further details on possible options for an integrated National Child Protection

Alert solution. There are important architectural issues that need to be considered in relation to

integrating portal solutions with central data stores.

Assuming a gradual take-on of a national alert system then full business benefits will not be achieved

until a large proportion of the population were covered by linked social work systems. However





25/74

defining a framework architecture and undertaking a proof of concept will encourage regions to build

compatible local solutions. Ideally there should be consensus on the conceptual architecture prior to

deciding which concept will be tested.

The GIRFEC focus on early and effective intervention requires information to be shared with a child’s

Named Person at the first sign of risk to well-being far in advance of Child Protection measures. Alerts

relating to child protection could be expanded to meet the requirements of the Children and Young

Persons Bill and the scope altered to include well-being concerns.

10. Short Term Actions

In the short term there are several activities that could be progressed quickly to improve information

sharing.

Organise a workshop involving 2 or 3 key people from each area, for the purpose of sharing

best practice, considering reuse and getting to know who’s doing what. This could include

streams on business requirements and possible solutions / architectures (including

requirements for a target information architecture)

Create a structure to encourage vendor cooperation to raise the profile of the programme,

improve reuse and reduce cost

Review how the i6 programme being undertaken by the Police Service in Scotland will support

data sharing with Health and Local Authority agencies. The purpose of the programme is to

develop a national solution to record and manage vulnerable persons. Assisted by Scottish

Government funding it has identified requirements and through a European Journal

Procurement exercise has identified a preferred supplier.

Review possible impacts of the proposed Children and Young Peoples Bill

Define the Maturity Model in more detail and agree at a national level

Define the expected benefits in more detail

Review the best model for manual data matching, ie local or national.

11. Maturity Model

This section attempts to define the key elements of a comprehensive data sharing solution, including

functions, qualities (eg flexibility and scalability), partners and the underpinning support required. It

does not define the intermediate steps to get to full maturity, and it unlikely that any area could ever

implement all the functions described below.

Local requirements will vary and it is unlikely that any single area will implement the full scope

described here; however a maturity model gives a possible target or benchmark for regional solutions,

including assessing technical reusability and determining capability. There may also be additional





26/74

functions and partners that a region will decide to implement that are not described here. Finally

changing legislation and practices mean that a maturity model will never be static.

It may be desirable to prioritise the elements of the maturity model if a national consensus can be

obtained, although local priorities are likely to vary. It should also be noted that some of the lower

priority items listed in the Other Data area could be delivered as relatively quick wins on the back of

solutions developed for higher priority requirements, e.g. adult alerts, adult chronologies and

notification of A&E attendances.

11.1. Functions and Data

11.1.1. Service User Demographics

View integrated demographics from linked agency systems, possibly in a format that allows

easy comparison. Details could include the person’s name, address, contact details,

relationships, education establishments, GP details, health visitor, nurse, communication

details, and accommodation.

Some indication what assessments and plans are in development or completed for a service

user, e.g. IAF underway flag

Provide an indication to professionals that a child is classed as vulnerable

Automate the setup of demographics when a social work record is registered (e.g. by access to

SCI store)

11.1.2. Professional Details and Consents

List of contacts (professionals) with consent to share the service user data (name,

organisation, phone numbers and email)

Identification of Named Person and Lead Professional for the service user

Show the “network of support” or register of interests in the service user, i.e. a list of

important people who are linked to the child (but who are not necessarily all shared data

users)

Professionals could maintain their own contact details with the exception of emails which would

be maintained by a senior user or administrator

Key team details

Consent details (type and notes). The Children and Young Person Bill will negate any

requirement for consent prior to information sharing about a risk to a child’s well-being.

Consents broadcast to all agencies whenever they are changed by one agency

Consent to share is assumed for 1 year but can be switched of manually by a senior user or

administrator.

There need to be procedures for ensuring professional’s contact details are up-to-date - e.g.

created when undertaking training, or on registration with the system.

11.1.3. Assessments and Plans

Allow a wide range child and adult related documents to be shared





27/74

Provide a mechanism to control the creation, updates and management of documents by the

Lead Professional, Named Person or other senior professionals, e.g. submission, review and

publication

Allow authorised professionals to contribute to all of a document, or only to limited areas of a

document

Identify the most recently issued document, and possibly display earlier versions

Display as pdf / Word files, or in a common structure (e.g. chapter / verse style), or collated

from data in the linked systems

Allows plans to be downloaded and printed, with the ability to disable this function for some

types of users, or by some other criteria

Allow documents to be shared with the service user and family whether in printed form or

view.

11.1.4. Child and Adult Protection

Show a warning / hazard indicator for the child with instructions to refer to practitioners for

more info, and the practitioner contact details.

Could share different types of alerts / messages, e.g.

Full range of messages from the agency systems

The 4 main Child Protection Messages, optionally with the 2 linked persons messages

Simply an indication that there is a protection issue with the child and the professional

should be contacted

Request a read acknowledgement from the viewing professional and keep a record of the

acknowledgement

Share pre-birth concern messages - linked to the mother and persist until birth/delivery date

Extend to support adult protection messaging,

Shared alerts need to be kept synchronised with the source system

Allow discretionary or automatic sharing from the source systems

11.1.5. GIRFEC Support

Chronologies

Show a chronology of significant events in the child’s life (e.g. start date, end date, type, title

of event, source agency, recorded by, notes/action taken and a RAG code or positive/negative

flag) ) including all well-being concerns

Support filtering and sorting by various criteria

A chronology could be merged from 2 or more sharing agencies, triggered by an authority to

share in the source system

The solution could also allow direct manual update of chronologies

Documentation

Allow sharing of My World Triangle Assessments, Plans, Well-being Indicators, Resilience Matrix

Concerns

Securely share information/concerns raised (by any adult who in the normal course of their

duties has contact with a child) with a child’s Named Person.





28/74

Provide an acknowledgement that the information/concern has been received.

Provide a read receipt

Audits and checks

A configurable and flexible facility to audit the receipt of information shared and produce an

alert if the information remains unopened (as a fail-safe mechanism to ensure that messages

do not go unopened hence increasing the risk to the child.)

Alerts to be notified via e-mail (required by users working in remote areas who do not tend to

access LoB systems on a daily basis)

System to send an alert should information sharing have failed, the alert should clearly state

the reason for the failure

Management

Ability to transfer the role of the named person both within organisations and to other

organisations and to provide the ability for delegation

Named Person’s home organisation to be able to configure the system to direct a message for

the Named Person/Lead Professional to a unit, a person or a group - to ensure Business

Continuity in respect of all abstractions planned and unplanned

Be able to share information with a child’s Lead Professional.

Lead Professional to be able to securely share a completed child’s plan with others involved,

including the child and family

Support the coordination of a Child’s Plan by the Lead Professional - This will entail the LP

sending, and receiving information such as concerns, practitioner summaries and chronologies.

Lead Professional to be able to add a new partner to a plan and advise other partners.

The above GIRFEC points are largely based on the document General Business Requirements for an

Information Sharing System to Support GIRFEC, issued in February 2012.

It is possible that Concerns could be processed and managed in the same way as CP messages.

There are obvious common requirements with other areas such as the more general sharing of

assessments and the management of access to shared data.

11.1.6. Access Control

There are several possible models for controlling user access:

Individual professionals linked to service user cases by a senior user (e.g. the Lead

Professional) and/or a system administrator)

By user role (e.g. Lead Professional, Named Person, Health Worker, Social Worker)

By agency (e.g. allow access by Health users but not Education users to a case, or for Social

Work users from one council only)

To selected areas of data (e.g. to restricted types of health data for Social Work users, or to an

assessment summary only for some types of users)

Service user restrictions (i.e. no sharing allowed at all for a specified individual)

Emergency “break the glass” access, with a comprehensive audit trail of its user

Register / unregister an interest in a service user

Access can be managed centrally or in the lined agency systems. Approval to share could be

the norm (e.g. triggered by adding a CHI number to a social work record), or the exception





29/74

Shared data could be accessed in several ways:

Only from the context of a service users record in a linked system (ensuring that data

access restrictions are the same as the linked system)

Directly in the shared data solution by a list of service users assigned to the

professional

Directly in the shared data solution by a search based on a CHI number or a minimum

number of demographic details (against cases who the user has consent to access due

to their role or team).

Possible single sign-on to local systems and the shared data solution.

11.1.7. Data Matching

A solution should have a means of automatically matching as many records as possible, with a

manual matching process for priority unmatched records. It is not necessary to match all

possible records, just data that needs to be shared.

Portal solutions generally need Social Work systems to be initially seeded with CHI numbers,

possibly by an initial automatic matching process.

Ongoing data sharing needs a mechanism to add CHI numbers to new referrals and un-seeded

existing records, and also manage merges, duplicates etc. This could take place by non-health

users contacting Health staff for a CHI staff, or by giving non health staff direct access to CHI

data.

Manual data matching could be provided locally or nationally (views differ)

A solution may need to allow for data sharing where the service user has no health record, e.g.

just between education and social work.

11.1.8. Auditing

The solution should collect audit data on direct access to shared data, and on access via the

linked agency systems

It should support reporting on specific situations e.g. access to a particular service user or by a

particular user

Also give the ability to identify patterns of suspicious behaviour, e.g. excessive searches for

service users outwith a user’s area

Audit data should only viewed by senior users and administrators

Retention and deletion arrangements for audit data would need to be implemented.

11.1.9. Reporting

The solution should provide operational and management reporting– e.g. number of cases per

user, levels of sharing by agency, report by school of activities linked to their pupils and

automatic production of appropriate SG healthcare assessment indicators.

11.1.10. General

Appropriate staff should receive notifications of new shared information available to view





30/74

Central and interfacing systems may need high availability (e.g. as close to 24x7 as possible).

Archiving policies need to be implemented for central store style solutions (portal solutions do

not hold data centrally so archiving is as per linked agency systems)

System monitoring and alert tools will be required

11.1.11. Other Possible Data

There are a several other types of data that is already being shared by a minority of areas, are planned

to be shared, or have been suggested as desirable features by an area.

Concerns

Reviews

Notes and correspondence.

Encounters and appointments (current and future)

Ward stays

Carer demographics

Service requests for home care, equipment and adaptations, specialist assessments e.g. OT

and income maximisation.

Service provision e.g. actual verses requested

Adult chronologies (in a similar format to GIRFEC children’s chronologies)

Adult alerts, i.e. show a warning / hazard indicator with instructions to refer to practitioners for

more info, and the practitioner contact details

Secure messaging between professionals (possibly with restricted emails, e.g. .gov or .nhs

addresses only. But would then exclude use by third sector etc.). Emails could only contain the

service users name and link to the record in the shared data to reduce the risk of inappropriate

data sharing.

Automatic equipment prescriptions

Confidential transfer of case information with attachments

Search professional contact data

Case Load Management

A homescreen shows recent logins, site notifications, notifications of changes to linked service

and user history

Missing Persons Alerts

Automatic synchronisations of demographics between linked agency systems (eg Social Work)

and the NHS SCI Store

Looked after children indicator

Notification of A&E attendances to other agencies.

11.2. Partners

At the moment most data sharing only involves MHS secondary care and social work departments.

However in the longer term a much wider number of partners could be involved:

Health, including GPs, A&E, out-of-hours, community nursing, ambulance service and mental

health





31/74

Local Authority, including Social Work, Education and Housing

Police

Fire and Rescue

Third sector agencies, e.g. charities providing services and running care homes

Private sector, e.g. care home providers, private nurseries, private schools

Members of the public, including children, families and guardians

Scottish Children's Reporter Administration

Other areas of the criminal justice system.

11.3. Support

Any data sharing solution will need a support and governance framework that will include:

An agreed Information Sharing Protocol between the partner agencies

Specific access protocols for each agency

Availability of personnel to administer the solution on an ongoing basis

Operational level agreements between agency system support areas





32/74

12. Benefits Summary

The areas involved in the study have identified a variety of achieved and expected benefits in the core areas of information shared, i.e.

assessments, alerts/messages, chronologies, as well as general benefits. Benefits accrue to service users, practitioners and partner

organisations. It should be noted that this is not a comprehensive survey of the benefits of data sharing but it does provide an indication

of the benefits that can be achieved.

Service Users Practitioners Organisations

Assessments Speedier, more effective and accurate assessments

Better understanding of needs

Better planning leading to better outcomes for children and families

Providing accurate and up-to-date information to support early intervention and rapid identification of children at risk

Faster implementation of plans and services Reduce the replication /volume of questions

asked

Provides a more seamless service to children and their families.

Shortened pathways

Broader range of services can be put in place to support plans

A more comprehensive and integrated assessment can be done more easily, and the patient/client has a copy.

In future, opportunities for information to accessed electronically by patient/client s

Patient/client asked to give written consent to information being shared, recorded and reviewed, and have an immediate hard copy

Reduces duplication, time to process and time taken in discussing background

Improved quality and efficiency of Assessments

A more comprehensive assessment of risk

For professionals new to a case - reduced need for background information gathering.

Saves practitioner time and effort

Improved quality and efficiency of assessments

Streamlines the process for the Lead Professional

More effective alerting of linked professionals that a new plan has been created

Professionals are more likely to view plans, and more likely to view the most recent version

Immediate information sharing 24/7 Development of assessment skills

Obtaining consent formalised

Reduced risk of inappropriate sharing

Improved information security

Better sharing of plans with the 3rd sector and families

Faster sharing of plans, especially with those who don't have secure email

Consistent feedback from NHS to Social Work on the outcomes of contact with a child

Alerts / Messages / Concerns

Reduced risk to children and adults

Early intervention possible due to well-being concerns being raised.

Less crisis intervention

A&E and out of hours health see the most benefits in CPM, i.e. people not previously involved with a case

Child Protection awareness raising

Sharing of Alerts and Concerns reduces personal risk for practitioners

CP messaging supports Child Protection Procedures and raises practitioners’ awareness





33/74

Service Users Practitioners Organisations

Improved outcomes for children and families

Adult Support & Protection awareness raising

Named Person has full picture of events impacting child

Named person has full picture of needs of child

of their responsibilities

Child Protection messaging links adult and child information systems and assist agencies meet the recommendations of inquiry reports into child deaths

Adult Protection messaging supports the Adult Support and Protection Procedures and arises practitioners awareness of their responsibilities

Legal Requirements of the CYP Bill met.

GIRFEC Chronologies enable practitioners to see an emerging pattern of events, leading to earlier identification of risk, appropriate intervention and prevention of harm

Working in a GIRFEC way requires an appropriate level of joint working – use IT to supplement current data sharing activities to improve the business process.

Information sharing with the Named Person and by the Named person to support the needs of the child.

Will provide a tool kit to support GIRFEC practice and integrated services for children and adults (the health and social care integration agenda)

General Earlier, better and more appropriate interventions and outcomes

Quicker services

Better protection and safeguarding

More accessible services

More capacity to deliver a tailored service Reduced risk to children

Vulnerable children and adults are identified to practitioners

Children receive the most appropriate intervention, care and protection

Better protection and Safeguarding of Children and Vulnerable Adults

Information sharing 24 x 7 supports partnership working

Reducing Duplication and Speeding Up Processes

Better knowledge of what other practitioners do

Reduces the possibility of crucial information not being shared

Linked Adult and Children’s Information systems

ISP training and guidance

more consistent recording practices improved data integrity help achieve national and local strategies

Statistical reporting is becoming easier – especially for activity between partnership agencies and teams.

Improved date integrity

More consistent and improved recording practices

Information sharing 24/7

Reduction in duplication across the partner agencies

Improved report and planning

Development of an ISP and a comprehensive package of supporting materials and a training programme

Other Functions

Ability to order services electronically Secure messaging enables rapid and effective communication between professionals.





34/74

Attachment 1 - Interviewees

Name Organisation

Erik Sutherland East Renfrewshire CHCP

Mary Gallagher East Renfrewshire CHCP

Tim Eltringham East Renfrewshire CHCP

Bill McKechnie Lanarkshire DSP

Fraser McLellan Lanarkshire DSP

Kathy Shilliday Lanarkshire DSP

John Barrett NHS Ayrshire & Arran

Stephen Duffy NHS Ayrshire & Arran

Jane Ankori NHS GGC&C

Mark Darroch NHS GGC&C

Alison Hawkins NHS Grampian

George McCaig NHS Highlands

Kevin Colclough NHS Highlands

Phil Dixon NHS Highlands

Steve McGregor NHS Highlands

Barry Mcalister NHS Lanarkshire

John Sturgeon NHS Lothian

Andy Robertson NHS NISG

Stephen Pratt NHS NISG

Finlay Stewart NHS Tayside

Jenny Bodie NHS Tayside

George Lynch Renfrewshire Council

Anne Martin Scottish Government eHealth

Blythe Robertson Scottish Government eHealth

Eddie Turnbull Scottish Government eHealth

Gary Johnston Scottish Government eHealth

Johan Nolan Scottish Government eHealth

Stephen Pratt NHS NISG

Jane Cluness Shetland Islands Council

Dave Meikle Sopra Group

John Patterson Sopra Group

Martin Bucknall Sopra Group

Stefan Heuman Sopra Group

David Robertson West Lothian Council

Alan Small Scottish Government – GIRFEC Policy Area

Alan Geake Borders Council

Graham Gault NHS Dumfries and Galloway

Ronnie Monagham NHS Fife

Lorna Brown NHS Fife

Lesley Halliday NHS Fife

Tom Gilmour NHS Orkney

Mary Cameron NHS Forth Valley

John Wells NHS Forth Valley










35/74

Attachment 2 – National Child Protection Alerts Lanarkshire eCare have recently proposed a Proof of Concept for a national child protection alert system using a central store and matching index. The proposed solution would need to interface directly with agency systems (example 1), and with regional data sharing solutions (examples 2 and 3). There will be other concepts which could be considered alongside the Lanarkshire proposal, e.g. federated information service brokerage. All proposals should be evaluated against criteria such as flexibility, sustainability, extensiblility, scalability etc. Example 1 – Alerts from Social Work to A&E

NHS A&E

Systems

Council Social

Work Systems

National

central

Store

2

New / Updated / Deleted

Alert

4

Read request

(by CHI number)

5

Alert details

Update alert in

the store

6

Alert read audit record

3

Access patient record

and view alert

Automatic

matching

service

8

Unmatched alert

(no CHI number)

10

Matched alert

Manual

matching

service

9

Unmatched

alert

11

Failed match notification

1 Update client record





36/74

Example 2 – Alerts from Regional Central Store to Regional Portal

National

central

Store

Update alert in

the store

Council Social

Work Systems

Council Social

Work SystemsNHS systems

6 Access patient

record and

view alert

Request / response Request / response

4 Read request

(by CHI number)

7 Alert read audit record ?

3

Alert details

Regional portal

solution

Regional central

store solution

5 Alert details

Council Social

Work Systems

Council Social


2 Automatic export of

New/updated/deleted alert Read response

Automatic and

manual

matching

Unmatched alert

(no CHI number)


Access patient

record and

view alert


3 Automatic export of

New/updated/deleted alert





37/74

It needs to be considered how the regional portal could generate an alert read notice for the central regional

store.

Example 3 – Alerts from Regional Portal to Regional Central Store

National

central

Store

Update alert in

the store

Council Social

Work Systems

Council Social


2 Access patient

record and

view alert

Request / response Request / response

Read request

(by CHI number)

Alert read audit record

3

New / Updated / Deleted

Alert

3

Alert details

Regional portal

solution

Regional central

store solution

Alert details

Council Social

Work Systems

Council Social


Automatic export Read response


Automatic and

manual

matching

Unmatched alert

(no CHI number)


Access patient

record and

view alert





38/74

Issues to be considered are:

1. How does the portal get the new/updated/deleted message to the national central store? (does the portal

have a means to create this sort of message?)

2. How do we get the alert read notification back into the portal (if it’s required) as the portal doesn’t hold

data?

3. How does the regional central store access the national central store? May need a read request triggered

by NHS read?

4. Either the regional portal has to get messages into the store (somehow), or when a read request comes

into the NCS the store has to send a read request to all regional portals which then polls the linked SW

systems in the normal way, and passes any alerts found back to the NCS.





39/74

Attachment 3 – Detailed Solution Catalogue

GG&C Orion Portal 40

Lanarkshire eCare 42

West Lothian C-me / eCare 46

Lothian CareFx Solution 48

Ayrshire AYRshare Solution 52

Tayside proposed solution 54

Grampian proposed solution 57

Highland solution 60

Shetland Solution 63

Western Isles 65

Borders 67

Dumfries and Galloway 69

Fife 70

Orkney 71

Forth Valley 73





40/74

Solution GG&C Orion Portal Portal

Partners > NHS GC&C > Renfrewshire Council (1st phase) >West Dunbartonshire Council (2nd phase)

And in future phases > Other council social work areas completely in the GG&C area (Glasgow City, West and East Dunbartonshire and Inverclyde) and possibly other agencies, eg education, police and housing.

Current Area and System Technology

and planned interfaces

Integrated health data - Orion Portal Web based Integrates various NHS CG&C systems

NHS GCC Community Nursing - CNIS Web service interface

RC Social Work data - SWIFT Web service interface

WD Social Work - CareFirst Web service interface

Matching Approach

> Initial CHI seeding of SWIFT and CareFirst data using a batch load (98% matching) > Manual ongoing maintenance by a small number of SW staff who have access to CHI lookup in Clinical Portal but not the shared data > CHI number will be visible to all SW users

Data Shared > Basic demographics > Warning / hazard indicator - from WD and RC SW systems (with instructions to refer to SW practitioners for more info) > Child Protection Register indicator - from WD and RC SW systems (also with instructions to refer to SW practitioners) > Children's IAF documents from Renfrewshire EDMS system (including Shared Action Plan) > Children's IAF and Shared Action plan from SWIFT (RC) > Adult Standardised Shareable Assessment (SSA) Forms from WD CareFirst (CareAssess Module) and later CNIS SSA application > Initially only the latest versions of documents will be visible in the portal > Audit data (which Orion user invoked which web service call and when) > Audit trail of web service calls also held in the LoB systems > My case data for SW users - list of clients on that users case list from SWIFT / Care First (switched off in phase 1). No closed cases will be shown.





41/74

Functions > View integrated demographics from Health and Social Work LoB systems (2 part screen) > View CP register indicators (no acknowledgement requested) > View latest version of IAF documents and SSA form in pdf format (within the Clinical Document Viewer area) > Warning / Hazard indicator - from WD and RC SW systems > View audit log of data views > System monitoring and alert tools > View professional contact details (addresses but not email or phone) > Search CHI number (by surname, first name and postcode) > Social Work client context access, or "my case list", or search own Council data by CHI no > Health staff access client details from context of patient details screen > Archiving policies depend on LoB system - no data held in the portal > Id of each clinical portal user is passed to the councils as part of each web service call and can be recorded

Integration Approach

> Orion will pass Web Service requests to linked systems which send back data (triggered by access of client record in Orion) > Health network already has 6 links to all council networks

Read only? All read only - update only in linked systems

User Access Method

> WD and RC Social Workers - read only direct logon. > Designated NHSGGC health staff - read only client context access > From CNIS - link in patient context. No search? > Same logon id for SWIFT and Orion (but not password) > SW staff click on a portal icon in LoB client details page > Or by logging directly onto the portal and accessing a "my case list" or search page (not phase 1). To be determined how access managed to case list. > Searches would be by CHI number

Access Control

> Access managed by Portal administrators > Various levels of health user access depending on professional grade > 2 types of social work access (standard and CHI lookup) > SWIFT confidential addresses not displayed in the portal > Role based access control (eg Renfrewshire Social Worker will only see RC SW clients)

Volumes > 190 Renfrewshire Social Work users > Possibly 40/50 CPMs in Renfrewshire





42/74

Planned features

Phase 2 provisionally may include: > My case list (WD requirement) > Other service applications of NHS GG&C > Integration with remaining councils wholly within the GG&C area, ie ER, ED, Glasgow and Inverclyde > Sharing of Single Shared Assessments with CareFirst and CNIS > Sharing of Discharge Letters subject to consent > Access from SWIFT via an icon in the client context > Display first authorised and updated versions of documents > Display contact information (directories) for health and social workers (pulled from the agency systems) > Integrated children's chronologies > IAF underway flag. > Initial discussions with SEEMiS around the Education Information System utilised by the GGC DSP Local Authority Education services

Desirable features

> Access to Education (SEEMiS), Police and other areas. > Automate setup of demographics when a social work record is registered (ie by access to SCI store from SWIFT and CareFirst). However would need a lot of governance work and agreement > Vision of standard Assessment forms within all GG&C partners > National CPM

History Currently in testing (Oct 2012), go live Q4 2012

Notes > Both Glasgow (Orion) and Lothian (Harris) architectures are similar, although GG&C are using Rhapsody as the portal integration engine and Lothian are using Ensemble > East Renfrewshire have also considered the OLM MultiAgency View product. Would support a many to many between clients and professionals. > Integrated children's chronologies could be maintained by NHS Child Protection area if they could get access to SW systems

Benefits of sharing

> Business benefits of quick assessments to IAFs

Solution Lanarkshire eCare Central Store

Partners

> North Lanarkshire Council > South Lanarkshire Council > NHS Lanarkshire

> Strathclyde Police N and Q Divisions > SCRA > Strathclyde Fire and Rescue



Lanarkshire eCare > Central MS SQL Server database > ClearSpan integration software

GPs - INPS View access

GPs - EMIS EMIS link under consideration

NHS Comm Nursing & others - MIDIS & PIMS

Bi directional data exchange





43/74

NL and SL Education - SEEMiS Bi directional data exchange

NL & SL Social Work - MySWIS & SWIS+ Bi directional data exchange

NHS 24 - Adastra/OOH View access via Adastra/OOH (inc mobile supp.)

NHS A&E and acute services inpatient and outpatient - TrakCare

View access via TrakCare

NHS SCI Store Automated reference look up

Strathclyde Police N&Q divisions

View access via SWIS logon

SCRA View access via SWIS logon

NL & SL Housing View access via SWIS logon

Matching Approach

> Central matching index of all indices - includes CHI number > Initial automatic matching against CHI by name etc (e.g. 60%), then manual matching as required (4%) via eCare Management application > Failed matches from CP messages go into a priority manual matching queue and are dealt with urgently. > If a match cannot be made, notification goes back to the sender to allow them to decide what to do. > Index updated automatically when new entry registration on any partner LoB system.

Data Shared > Primary care person demographics > Associated professionals contact details > GP details > Addictions Contact details > Referrals > Appointments > Ward stays > Carer demographics > CPM - 4 main protection messages and the 2 linked person messages. Persist until age 17. Alert messaging includes child protection subject, linked children and linked adult messaging, include relationship to subject child status, carer status, legally responsible status, lives at same address or not and if CP activity is current or past. > Pre-birth concern messages - linked to the mum persist until birth/delivery date > Adult protection messaging, investigation adult protection plan and AP activity ceased on date messages persist for three years from ceased on date > Shared Assessments (full assessments are shared, not just practitioner summaries). Assessment types- Long Term Conditions, mental health, learning disabilities, addictions and substance misuse > Personal outcome plans > Care plans > Service requests for home care, equipment and adaptations, specialist assessments e.g. OT and income maximisation. > Service provision e.g. actual verses requested > GIRFEC consent details – consent held centrally in MAS all partnership updated automatically when consent changes (continued >>) > Child integrated Chronologies each significant event record comprises – 7 or 8 fields





44/74

and summary, > Single Named Person and “network of support” for the child, i.e. a list of important people who are linked to the child.

Functions > Appropriate staff receive notifications of new shared information available to view in the central database. > Update status of CP and AP messages in the MAS and issue alert for Child and Adult Protection Messages to the linked agency system > Acknowledgement has to be selected when viewing CP and AP Protection messages , this creates an audit trail in the MAS (CP and AP Messages can also be printed). > Consents broadcast to all agencies whenever they are changed by one agency, so they all follow the same rules. > Child Integrated Chronology - Merged from 2 or more sharing agencies (Significant events are authorised to share into the integrated chronology from source systems). > CP alerts are automatically deleted when the child reaches 17 years of age other Girfec components are removed when consent expires or is withdrawn. > Child Chronologies - Filter by date, source agency, category (e.g. well being of the child, legislation etc), or +ve/-ve/neutral indicator. > Consent model allows any participating agency to view shared information e.g. an integrated chronology where consent has been granted for that agency to view the information > CHI matching management application allows identifiers to be added where messages fail to comply with the eCare business rules e.g. a health assessment must have a social work identifier attached, social work assessment must have a health identifier and protection messages must have identifiers appropriate to all involved agencies > Service Requests (from PiMS or Midis - e.g. Health order Home Care, Equipment and Adaptations or Specialist Assessment)


> Assessments - automatic export from SWIS and NHS systems to a central database. Notifications are then pushed to the recipient systems. The information is then viewed in all partnership systems via an embedded web application which appears as part of each host system > System supports sharing of assessments in different formats. All message construction is carried out by eCare adapters. > Messages - automatic export to central database then read from linked systems e.g. no additional operations required by system users. > Chronologies - user authorised export to central database where merged and read via an embedded web application which appears as part of each host system, i.e. Care Viewer

Read only? The eCare viewer application does not allow shared information to be altered and in this respect is view only. No user may update information shared by any other agency. New information may be shared from any of the agencies at anytime and new information may be recorded using the assessment server component or service request tabs of the eCare viewer. Any information shared e.g. an assessment or integrated chronology, from a source system may be added to or updated but only by that source system.

User Access Method

> Embedded in source systems. > Service user context only (access control advantages), i.e. no service user search facility Only Patient/Client context available.





45/74

Access Control

> Granular access possible by agency (GIFREC compliant) but not by assessment section. > Information Shared is agreed on a process basis across the Partnership e.g. it is not appropriate to further restrict system user access. > Consents are broadcast to all agencies whenever they are changed by one agency, so they all follow the same rules. > Full assessments are shared, not just practitioner summaries.

Volumes > 19k CPMs to 4/2012, 9k in 2011, > 887 people with APMs in 2011 > Between 2k and 3k people with shared assessments in 2010 > Nearly 500 Health Service Requests in 2011

Planned features

>The Named Person and Lead Professional, start and end date, contact details and history > Child’s Single Agency Wellbeing Assessment and Plan > My World Triangle Assessments and Plan > Request for Assistance and Notification of Concern > Integrated Assessment and Plan > Adult chronologies > Police contribution to a chronology (with ACPOS and Scottish Government)

Desirable features

> Other 3rd sector access Care Home access (security issues need to be addressed), > Share referrals assessments etc with Meridian Services (addiction services) > Links to EMIS GP systems > Fire and Rescue access > Demonstrator project with 2 neighbouring areas to share public protection messaging e. g. child and adult protection messaging (any social work system with any A&E) > August DSTB meeting gave in principal support for Lanarkshire proposals for sharing public protection alert messaging across partnership boundaries and viewing and sharing alert messaging and shared care information with the third sector, whilst awaiting a detailed proposal. > Would like to investigate the capabilities of Ensemble to replace ClearSpan functions. Could then transfer all or parts of an Ensemble based solution to other areas

History 2003 SSAs, 2004 service requesting, 2005 CPM, 2011 APM, 2012 GIRFEC part 1

Notes





46/74

> Source assessments content and format all differ but presented in same hierarchical book / chapter / verse format as a "report" > Selective sharing rarely occurs > Messaging to A&E very important > Would like to share messages with neighbouring areas, using a small central dataset, 1 adaptor, web services and matching by CHI number > Lanarkshire have a fully mirrored test environment > Current interfaces are:

Benefits of sharing

> Shared Assessments - within hospitals, the ability to access shared information reduces the need for staff to contact Social Work in the first instance > It also significantly reduces the time taken to gather information from families on GP, Care Manager and Social Worker contact details and to gather a full picture of patients’ circumstances. This has led to reductions in hospital stays for a number of cases. > Electronic requests for homecare equipment by health practitioners - has been a tremendous benefit to both patients and staff, and has incentivised health practitioners to use the electronic system > See full details in Lanarkshire benefits table

Solution West Lothian C-me / eCare Central Store

Partners

> NHS Lothian > West Lothian Council > Lothian and Borders Police >Children's Reporter



C-me VisionWare MultiVue for matching and merging

Social Work - SWIFT Direct duplex interface – bespoke from Northgate

Health - TrakCare & CIS Web service interface

Education - SEEMiS & EMS Web service interface

WL Council - ETS (enquiry tracking) Archive web service interface

Archive SW records - SSID Incorporated into SWIFT interface

GPs No direct system interface required

Health - Telecare No system interface required

Police users No system interface required

WL Housing users Web Service interface with Academy

Children's Reporter users No system interface required

Matching > Secure central matching and merging facility (VisionWare MultiVue)





47/74

Approach > Automatic update between all systems via the central eCare matching facility > Manual review process for physical matching of non verified matched records > CHI number held as a secondary key in C-me - not visible to all Social Work users

Data Shared

> Detailed service user demographics, inc. Person details, relationships, education establishments, GP details, health visitor, nurse, communication details, accommodation) > Chronology of events (start date, end date, type, title of event, recorded by, notes). RAG coded. > Alerts (wide range: 18 SWIFT, +23 TrakCare + Education messages) > IRDs (Inter-agency Referral Discussion), SSA’s, specialist assessments and Care & Support Plans > Consent details (type and notes) > Professional contact data > Register of interests in service users by professionals

Functions > Searchable client database (by N&A, DoB & Swift ID) > CPM (RAG coded) > Update shared SSAs, IRDs, and Care & Support Plans > Secure messaging between professionals > Confidential transfer of case information with attachments > Search professional contact data > Update chronology of events > Automatic Alert Notification > Case Load Management > Register / unregister an interest in a service user > Care home staff can use secure email (including to securely send assessments) > Reports/extracts, e.g. report by school of activities linked to their pupils and automatic production of SG healthcare assessment indicators.


> Duplex adaptors in the linked systems > SEEMiS - scheduled extracts >TrakCare - outward only > Use published APIs to write directly to SWIFT database > Event driven extracts from SWIFT

Read only? No - all sharable data items can be updated in C-me if the user has the correct permissions.

User Access Method

> Logon to C-me portal from within linked systems

Access > Role based access control





48/74

Control > Consent controls > Access can be restricted by service user (client) or web-part > No requirement for GIRFEC style granular access (full sharing or none) > Two levels of access (1 = child's core data and other linked professionals, 2 = chronology and assessments)

Volumes > 500,000 matched records > 10,000 completed assessments (all client groups) > 3,000 users > WL population is 170,000

Planned features

> Telecare assessment (Safe at Home) > Automatic equipment prescriptions

Desirable features

> Share messages with Lanarkshire > Update of functionality for children’s services to support the GIRFEC agenda – updated chronology, shared child’s plan and interface with education. > Extended proof of concept with NHS wrt Community portal technology. > Extended geographical propagation of web services

History Launched 2004

Benefits of sharing

> Overarching aim: "To improve the quality and integration of services for children and adults in West Lothian through effective sharing of information between involved agencies, children and families at every point in their care". > Chronologies - enables practitioners to see an emerging pattern of events, leading to earlier identification of risk, appropriate intervention and prevention of harm. > Earlier Identification and Intervention > Sharing of Alerts and Concerns – reduced personal risk for practitioners and safeguarding children > Referral and Assessment history – more effective and accurate assessment of the individual, less time taken in discussing background, fewer repeated questions and better understanding of the needs relating to a child. > Reducing Duplication and Speeding Up Processes > Rapid Effective Communication - secure messaging enables rapid and effective communication between professionals. > Improving the Quality and Efficiency of Assessments > For professionals new to a case - reduced need for background information gathering. Saves practitioner time and effort but also to improving the quality and efficiency of assessments and providing a more seamless service to children and their families. > Statistical reporting is becoming easier – especially for activity between partnership agencies and teams.

Solution Lothian CareFx Solut ion Portal





49/74

Partners > NHS Lothian, with: > Initially: Edinburgh Council, SW Initially POC core information set

> In the future: Enhanced datasets, actual assessments, and CP messaging SW, Education, Housing etc in > East Lothian > Mid Lothian > West Lothian Council And Consider other agencies > Police > Voluntary Services



NHS Lothian - CareFx regional portal > Ensemble for integration and aggregation > Web services > Uses Carefx’s Fusionfx platform

TrakCare - NHS EPR Already integrated with CareFx (however enhancement required from further integration with other agencies) Webservices / Ensemble

ECS - NHS Emergency Care Summary Already integrated with CareFx (however enhancement required from further integration with other agencies) Webservices / Ensemble

Edinburgh SW - SWIFT POC adaptor completed(however enhancement required from further integration with other agencies)

And in the future:

Borders NHS – Trak. Currently integrated for Regional NHS Clinical Portal, but local partner agency implications needs assessed for SC Portal and associated Child Protection messaging

Webservices / Ensemble

Dumfries – Topaz. Currently integrated for Regional NHS Clinical Portal, but local partner agency implications needs assessed for SC Portal and associated Child Protection messaging


Fife NHS - Oasis Patient Administration (PAS)/Electronic Patient Record (EPR) Currently integrated for Regional NHS Clinical Portal, but local partner agency implications needs assessed for SC Portal and associated Child Protection messaging


Police – IRDs (Inter-agency Referral Discussion) (Child Concern / Child






50/74

Protection related documentation and associated Child Protection messaging)

Matching Approach

> Social Work systems will initially be manually seeded with CHI numbers (Social Work staff need to obtain CHI numbers by phoning NHS staff for the POC – Any final production solution would need CHI search / update mechanism agreed for Social Care, (and other agencies – Voluntary, Police) > CHI numbers will need to be manually added to new data and existing data where the seed failed (Part of any new protocol for CHI access and maintenance > New DSTB working group on CHI use across agencies, guidance on usage scenarios, seeding, view / sharing and updates (also dealing with validation, matching and CHI and local demographic variance between agencies)

Data Shared The final Portal solution will display: > Wide range of patient data available for health and social care users (subset provided for POC) appropriately filtered based on usage roles / need to know, including: > Demographics from SWIFT / NHS > Standard child protection messages > Alerts from Trak and SWIFT hazards > Key worker details > Teams involved / Services provided > Notes > Patient/Client Contacts > Adult and Child plans > Shared assessments and chronologies > Requests for Service > The combined social and NHS summary screen, holds demographics / NOK contact details from each system, concerns, teams involved, services delivered, assessments , reviews, notes and correspondence. > Trak referral, diagnosis and GP / HCP information was also provided. > A further workshop is arranged at the end of Jan 13 to detail the exact datasets that require to be shared, and to work cooperatively with Glasgow on integration approach and message content (and any other regional portal providers)

Functions > NHS users can enter a CHI number or search by DOB, name, post code etc, or by grouping (eg clinic or ward) > Social Work users have to enter a valid CHI number (no search facilities on CHI data sources) The Social Care user search criteria would also be limited to CHI. > Displays various tabs and portlets to present data from various sources, patient context retained > Portal Application Extensions to be developed (there for Clinical Portal already, e.g. Trak), which allow seamless launching of client systems (e.g SWIFT) in patient context for data entry > Review of options to use Portal Clinical / Social Care forms to collect data and post back to client systems > Assessments - portal will allow various source formats to be displayed in a "report" style (built from source data, rather than in a pdf format). > Share alerts from Trak and SWIFT hazards > Encounters and appointments (current and future) > Consents (need Portal controls added over records to be shared / with-held) > Linked professionals





51/74

> Demographics from SWIFT and SCI store / Trak > Key team details > Authorised NHS users can get full access to Clinical Portal clinical content from Trak, all regional SCI Stores, ECS (medication / Allergies) and shared Social Care / NHS summary > The Social Care user portal contains more limited NHS encounter and appointment information and the shared Social Care / NHS summary. > Future functional Social Care interface needs to deal with CHI access, End User (AD/federated domains) or Trusted system-system credentials and Access audit, also Additional Data Items including Assessment Documentation, GIRFEC information and messaging) > Record locator service (generally Board level SCI Store) to limit access requests to operational systems


> Users of linked systems will supply a CHI number and the relevant data will be pulled from the source systems on demand. > Need to agree any additional patient/client data for validation (e.g. Surname, Sex, DOB) > There will be no patient / client data held centrally, portal pulls data on demand from client systems > Access Control data will need to be held within portal, e.g. user accounts, roles, access logs etc (need to define production approach here)

Read only? > Initially yes > However CareFx could support deployment of eForms for update access, eg for requests for services, additional notes, input to client systems

User Access Method

> Logon via secure communications infrastructure (to be determined, additional SC networking SWAN, existing GSI/GSX, Secure VPN Tunnelling etc) > Also need Defined Approach to user identification, role management and system-system trusted communications

Access Control

> Different users get access to different tabs and portlets, e.g. Social Work staff get a restricted view of health data > Audit trail maintained for Portal accesses > Sharing can be blocked in the source systems for defined individuals (part of consent to share flags within source systems, need agreed standards here) > To be decided if a positive decision to share, (adding a CHI number in SWIFT could be taken as a positive decision to share but that’s a very high level approach more granularity likely required> To be determined who will manage user access. > Will need restrictions on cross-board and cross-council access - to be worked out (part of a new interagency gateway architecture) > CHI guidance required on use with other agencies, where health not directly involved (eg between SC and Education) > Updated rules on non-disclosure patients

Volumes To be supplied





52/74

Planned features

> Integration with Mid Lothian and East Lothian Social Work systems (both CoreLogic/Frameworki) > Integration with West Lothian eCare system and/or Social care system (Swift) As noted also need Defined Social Care (and Other agency) Gateways, to limit connection complexity and broker access requests (e.g. Social care, Education and Housing behind a SC gateway – Board / regional / national ?) This depends on Ensemble Architectural and Licensing decisions > Put each agency dependent system upgrade plans on a common timeline along with health to assist coordinating portal approach

Desirable features

> Possible single sign-on to local systems and the portal > Portlets for GIRFEC concepts such as Well-being Indicators, My World Triangle and Resilience Matrix, Chronology, Child Plan etc > Agency based and integrated chronologies > Interface with Education SEEMiS systems (would need to be CHI seeded) and similar controls to Social Care Systems > Alerts (currently manually typed into Trak). Would need to be synchronised, and also allow discretionary sharing from the source systems. > Secure messaging with partners (CareFx has secure messaging that could be extended) > Social care (and Other Agency Integration) to be an extension to existing Portal (NHS) National Data Standards (NDS) – Small Agile interfaces (vs complex / expensive earlier eCare adapters – APIs need unlocked from each supplier and web Service Standards agreed (need authentication, legitimate interest (roles) etc)

History > Social Care POC completed October 2012, > Additional Patient Portal POC in progress (likely Nov / Dec) > To be followed by business case for integration between NHS Lothian and all Lothian councils including West Lothian (and other agencies including Education, Housing and Voluntary Sector, Police). DSP to own business case.

Notes > CareFx regional portal includes Lothian, Borders, Fife and Dumfries and Galloway > Ensemble license issues need to be addressed (use outwith NHS) – Possible National Ensemble license > Need to consider national System Access standards (e.g. ECS, Child health Screening, and CHI) through National Ensemble Integration gateway

Solution Ayrshire AYRshare Solut ion Stand-alone

Partners

NHS Ayrshire & Arran East Ayrshire Council South Ayrshire Council

North Ayrshire Council



AYRshare central database > Hosted in NHS environment > Ensemble for matching and integration > .Net front end

NHS Ayrshire Health Visitors - FACE Specified XML format output transformed by Ensemble

North Ayrshire Council SW - CareFirst Specified XML format output transformed by Ensemble East Ayrshire Council SW - SWIFT

South Ayrshire Council - SWIS Adaptor in SWIS





53/74

All 3 councils Education - SEEMiS XML output

Matching Approach

> Central index of identifiers, ie CHI number, SW LoB system ids > Match on demand > CHI number desirable but not mandatory (eg for unborn children and transient individuals) > NHS staff add CHI numbers to central index

Data Shared > Homescreen shows recent logins, site notifications, notifications of changes to linked service user history > Summary list of linked service users (My Folders) > Basic service user demographics (CHI no. Gender, DOB, Age, Address) > Contact details for Named Person and Lead Professional (name, email and phone numbers) > Assessments and plans for service users (as a list of documents in various formats) > Chronology of significant events for service users (organisation, source, recorded by, date recorded, title, notes/action taken, category, RAG significance - alert, +ve or -ve) > All child data at present > List of contacts (professionals) with consent to share the service user data (name, org, phone nos. email) > Audit trail of all user actions (including queries)

Functions All users who have access to the child's record can > Upload documents > Add chronology events (but not edit existing events) > Search for service users which they have consent to access (by id, inc. CHI number or at least 3 items of demographic data) > Maintain own contact details (phone numbers - not emails) In addition Named Person and Lead Professional can: > Give contacts (professionals) access to a service user's data (can see all data - no partial access) > Delete and hide documents > Delete and edit chronologies > View the audit log > 2 sources for chronologies, linked LoB systems and direct manual entry. > Some actions in LoB systems automatically send data to AYRshare, or data can be manually sent. > Some users can be given emergency access to all service user records because of the nature of their job, eg A&E, 24 hour cross-Ayrshire Social Work Team > Any user can raise a concern. When it is agreed to share information a record is created automatically in AYRshare when information first sent, or manually by request to System Admin to do so. > NHS staff add the CHI number > Contact emails restricted, eg .gov or .nhs addresses. > Emails only contain the child's name and link to the record in AYRshare > Various reports on data stats and system usage will be possible > Consent to share is assumed for 1 year but can be switched of manually by NP or LP > Archiving strategy is to be finalised - probably driven by the LoB system


> Central store database holds assessments, plans and chronologies > Adaptors / XML exports from LoB systems > 3 council networks need to be hooked into the Ayrshire & Arran NHS Network





54/74

Read only? No - users can directly upload documents and create chronology events.

User Access Method

> Browser based stand alone access (ie not via LoB systems)

Access Control

> Via secure network (Local authority or NHS) > Police and 3rd Sector access might need a different approach > Named Person and Lead Professional control access for Contacts (Professionals) > No attempt to manage access by roles, agencies or to sub-sets of data - regarded as adding to much complexity

Volumes Difficult to forecast, maybe: > 1 in 10 children > 3000 active cases per year

Planned features

> CPM needs more analysis > CPM in NAC between health (FACE) and Social Work (CareFirst) uses eCare.

Desirable features

> Open access to areas outwith LAs and NHS, eg 3rd sector, police, fire and rescue. But would need a secure means of access. > Could be by direct logon initially, then LoB system integration > Cross border CPM (in discussions with Lanarkshire and D&G)

History > Ready to start end to end testing with SAC SWIS when network linkages complete > Then integrate with FACE > Bring in EAC when they have completed an upgrade to SWIFT > NAC integration at the proposal (development) stage > Could tap into Lanarkshire SEEMiS changes

Notes > Don't under estimate the effort to link council networks to NHS network > Decided that all was needed were documents and metadata rather than XML. The Chronology is produced in XML. > ISP in draft for Ayrshire DSP. AYRshare will be covered by a local guidance procedure.

Benefits of sharing

> Children & families quicker services better protection and safeguarding more appropriate interventions and outcomes > Practitioners Information sharing 24 x 7 reduces duplication and time to process supports partnership working better outcomes for children > Organisations improved data integrity more consistent recording practices help achieve national and local strategies extend to other areas

Solution Tayside proposed solut ion Central Messaging Hub

Partners

> Tayside NHS > Dundee Council > Angus Council

> Perth and Kinross Council > Tayside Police > Tayside Fire and Rescue > Voluntary Agencies






55/74


NHS Tayside - MiDIS Clinical Portal To be agreed. Solution may use a hub and spoke architecture utilising a very small flexible API based on transmission of XML messages via input and output streams. System interfaces would need to be implemented by each agency system. Interfaces would need to support: receive message, send message, get user directory, and get agencies

Angus Social Work - OLM CareFirst

Dundee Social Work - K2 (in-house)

P&K Council Social Work - Northgate SWIFT

P&K, Angus & Dundee Education – SEEMiS

(but no involvement from private schools or private nurseries)

Matching Approach

> Use CHI number as a the as the central index that all other agencies match to > Agreed that CHI ids can be held on other agency systems > Agency systems will need to be bulk matched and pre-seeded for initial connection to the hub but can then either match new clients via a manual process or use a matching framework provided > Unmatched requests would be processed manually by a matching clerk in NHS Tayside > Ideally would like to get notifications from SCI Store of demographic changes

Data Shared > Initial focus is on CPM framework as well as an indexing and matching service > Initially just CPM for Dundee and Angus - P&K are not using CPM at the moment > The proposed framework would support 4 types of data sharing: 1. Sending Information - An agency can send information to one or more other agencies via the message hub but can also restrict the message to specific agencies, eg CPM. 2. Requesting Information - An agency can request information from one or more agencies via the message hub, eg a portal type application that just needs to display information on demand. 3. View only - The ability to only view shared data will be required if an agency does not have an application of its own, is not connected to the message hub, or the agency system cannot process all message types. 4. Collaborative Working - 2 or more agencies may require to work together to complete a joint record and the hub will provide the mechanisms for doing so. For example collaboration between Social Work and Health to complete a Single Shared Assessment. > Tayside Fire and Rescue currently have restricted access to MIDIS for referrals only - they then need to contact the appropriate professional > Tayside police can access CPMs via a restricted MIDIS logon > NHS out of hours can access MIDIS.

Functions > Sharing of Child Protection Messages between all partner agencies > Central indexing and matching function > Ideally the solution should allow true collaborative working on a dataset, including record locking > Broadcast messages based on information in the message or default routing information > Allow agencies to request information from other agencies





56/74

> Hold a virtual directory for each agency to allow message routing to users, teams etc > Provide a dynamic list of agencies connected to the hub > Optionally hold historic messages in the hub


> Solution would be based on standard services > N3 connectivity will be required for some sites. Any sites not on N3 (eg Police) will need an internet facing architecture > Solution likely to be based on the following principles: • Be lightweight with low barrier to connect • Be simple • Keep business logic within the agency systems • Use CHI as a matching index • Be flexible to accommodate new datasets as they are introduced • Use a hub and spoke architecture to reduce point to point connections and impact of connecting new systems.

Read only? Yes - all updates would be via agency LoB systems

User Access Method

> Both via LoB and stand alone viewer. > A viewer application will be created independently of the message hub and will receive messages from the message hub for storing and viewing based on routing rules within the hub. The application will be accessible either as a standalone application that a user logs into and searches for a client to view or via an interface to allow a third party application to open the viewer with a pre-selected client.

Access Control

> An internet-facing service would require an internet security management solution to continually protect the site from any potential threats.

Volumes > In eCare number of new children with CP warning 2011/2012 averaged about 30 per month > Number of new children with linked person CP warning averaged about 4 per month > Number of CPMs retrieved via agency adaptors between 180 and 250 per month (all for Dundee City and Angus Councils only)

Planned features

> Proposed to build a solution utilising local architecture but using underlying principles that allow collaboration to support future multiple partner consortiums or centralised national solutions

Desirable features

> Recognised that GIRFEC may change requirements for CPM. Could be the subject of a future bid for funding.





57/74

> Perceived need for Scottish national CPM, especially with A&E. > UK wide CPM would also be useful > National CPM would just involve general alert messages with no specific details about the alert > Scottish wide data sharing on Looked After Children would also be useful > Have discussed options for sharing data on fire starters with Tayside Fire Service (currently on spreadsheets) > Proposed CPM framework could be used for adult messages in the future > Extend scope of MIDIS to include more hospitals and GP systems (4 EMIS and 63 INPS). MIDIS is mainly community nurses and mental health at the moment) > Integrate Adastra in the future (NHS out of hours) > Share solutions with other regional MIDIS consortium partners (NHS Fife, Forth Valley, Lanarkshire, D&G and Highland). Although all have configured MIDIS differently.

History > Tayside have adopted eCare CPM in Dundee City and Angus Councils. MiDIS, Clinical Portal, SEEMiS, K2 (Dundee social work), and CareFirst OLM (Angus social work) are all connected. > October 2012 submitted a funding request to the SG to define the business requirements and identifying the business solution and technology required to deliver replacement solutions for the services provided within the eCare framework (i.e. an indexing and matching service and a CPM framework).

Notes > Would need continuously available hardware, with 24/7 monitoring and application support. > Above information based on meetings with Jeni Bodie and Finlay Stewart also the following documents: Data Sharing Technologies Board - 30 October 2012 - Tayside Funding Request.doc Data Sharing Technologies Board - 30 October 2012 - Tayside Data Sharing Framework Proposal.doc > Although a fully defined architecture for the CPM replacement work is not yet available, the solution is likely to be developed outside the Ensemble framework initially but equally developed such that it converts to an Ensemble platform relatively easily in order to aid any wider collaborative approach

Benefits of sharing

> A&E and out of hours health see the most benefits in CPM, ie people not previously involved with a case. > New initiatives, such as GIRFEC, are introduced that require an increased level of joint working there is a greater opportunity to use IT to supplement current data sharing activities to improve the business process

Solution Grampian proposed solut ion Central Store

Partners

> NHS Grampian > Aberdeenshire Council > Aberdeen City Council > Moray Council

> Grampian Police



NHS Grampian - Trakcare PMS system > To be determined > Possibly based on Ensemble, Cache and HealthShare Foundation from InterSystems All council Social Work areas - CareFirst





58/74

Aberdeenshire and Moray Education - SEEMiS

> Reuse existing adaptors for CPM if possible > Proposed interface technologies are: TrakCare - HL7 CareFirst - XML SEEMiS - XML EMS/Vision - OpenHR/CDA

Aberdeen City Education - Phoenix

Matching Approach

> Probably a central matching index of identifiers from linked systems, including CHI numbers and CareFirst ids > InterSystems have proposed using the HealthShare Patient Index for record linking > A simple ZEN user interface could be developed and integrated with the Patient Index to allow manual matching/analysis > It is possible but highly unlikely that an alert could be raised against a client in CareFirst and shared with SEEMiS even if the child doesn't have a patient record in TrakCare PMS. Any child born in Grampian is registered on PMS at birth and any child moving into the area and registering with a GP would be picked up by PMS. > But also considering CHI seeding of LoB systems > 97% of the Grampian population have a CHI number

Data Shared

> First priority is to implement CPM between NHS PMS system and Moray CareFirst SW system > Initially would support 4 main protection messages, ie: Investigation Investigation and on the CP Register Registration Past activity But not the linked adult and linked child messages





59/74

Functions Core functional requirements are: > Ability for CareFirst to send CPM messages to SEEMiS. > Ability for CareFirst to send CPM messages to TrakCare, and for alerts to be displayed next to the correct patient data > TrakCare and SEEMiS users to be able to view the CPM message in context. > A process to match identifiers across the different systems > An interface for CHI lookup and CHI broadcast would also be required. > The solution would need to ensure that shared messages are kept synchronised with the source data > May also want users to be able to see expired messages


> Will use a publisher / subscriber model that supports extensibility > Information will be exchanged with a surrounding "wrapper" A possible initial messaging scenario is: > A CareFirst registration triggers the send of an XML CPM message > HealthShare Foundation receives the messages and uses the algorithms defined in Patient Index to match/record link the patient. > The message is stored in the message store. > The message is converted to HL7 and sent to TrakCare, if the patient is currently known in TrakCare an alert will appear next to the patient. > The message will be sent to the SEEMiS system as XML. > TrakCare and SEEMiS users will be able to view the CPM in the message store using the Viewing/Matching UI. > The message store will also be used periodically by TrakCare to query for CPM messages on admission of a new patient.

Read only? > Centrally held message data can not be updated directly - only viewed via LoB systems or by the Viewing / Matching UI > Centrally held matching data in the Patient Index could be able to be updated directly by the Viewing / Matching UI

User Access Method

> To be determined, but possibly only matching index held centrally so all access via patient/client context in linked LoB systems

Access Control

> PMS operates a Role Based Access model. CPM messages would be treated as a medical alert ie restricted access. > SSAs would need to allow the source agency to configure which parts of the source document will be shared

Volumes > Grampian CPM messages on eCare (between Moray Council Social Work and Education systems only) averaged about 10 new warnings per month in early 2011. > Potential full volumes have not been estimated.

Planned features

As stated above

Desirable features

> Sharing of SSAs and other types of assessments and plans > All parties should be able to contribute to an assessment > Governance issues would need to be addressed > Give GP practices access to PMS (some have access already), or integrate GP systems (mainly Vision INPS, some EMIS). PMS has the CHI number and GP code > Bring community nursing onto PMS (no IT systems at the moment) > Integrate NHS out of hours (on Adastra) > Possibly GIRFEC chronologies





60/74

> Extend CPM sharing to Highland, Orkney and Shetland (all TrakCare PMS users) > In the future maybe integration with national CPM (proposed InterSystems architecture would support this) > Any solution needs to be flexible enough to support vulnerable adults messages, plans and assessments > The proposed Ensemble / HealthShare architecture would allow TrakCare to publish attendance messages with CareFirst and SEEMiS

History > Grampian are using eCare CPM between Moray Council SW CareFirst and Education SEEMiS system > Now need to find a replacement due to the pending decommissioning of eCare > Sharing of SSAs has been piloted between NHS Grampian and Aberdeenshire Social Work, however was stopped to allow existing processes and paper forms to be refined > InterSystems have recently (Nov 2012) proposed an solution for the delivery of CPM.

Notes > It is important to stress that any IT solutions are the belt and braces and don't in any way replace good business systems and personal contact between professionals > Solutions should work on the presumption to share supported by a high level governance document > Borders are also TrakCare PMS users and are interested in the discussions with InterSystems > Likely that Helix and Topaz in Orkney and Shetland will be replaced with PMS eventually (hosted by Grampian) > Grampian, Orkney and Shetland currently use SCI store to share patient information, eg discharge notes, lab results > The proposed InterSystems architecture is very similar to the existing Lanarkshire architecture. Lanarkshire are considering rebasing their solution on Ensemble.

Benefits of sharing

Not yet fully articulated but initially mainly patient safety and care as a result of CPM, then better outcomes as a result of shared assessments and GIRFEC.

Solution Highland solut ion

(pending verification by Highland Representatives)

Stand-alone

Partners

> NHS Highland (A&E, children's & maternity wards, public health nurses, community nurses) > Highland Council Social Work Services > Highland Council Education, Culture and Sport > Northern Constabulary

> Voluntary Sector > Children and families > And in the future, Argyll and Bute Council areas and Strathclyde Police



Highland Council Social Work - CareFirst Highland are developing a stand-alone SharePoint based solution. There are no electronic interfaces to the agency systems.

Highland Council Education - E1

NHS Highland - MIDIS

Matching Approach

> All matching is manual by the Lead Professional so there is no requirement for a central matching index or CHI seeding of LoB systems.

Data Shared > The initial solution will support the sharing of Multi Agency Children's Plans > CareFirst can output the plans as pdf documents. > The CareFirst user can select what information to output and hence what to share > Education will provide plans in Word format





61/74

> The solution will also hold information about consents.

Functions > The Lead Professional will create a SharePoint site for a case > They will then give other registered users access to the site as required > Professionals will see a list of cases assigned to them by the Lead Professional > The Lead Professional is responsible for requesting input to the plan from the other professionals > Professionals will supply a "practitioner summary" document that will be reviewed by the Lead Professional > The Lead Professional will then create the Childs Plan and share with the other linked professionals > Users will only be able to see information they have uploaded themselves or plans that have been made available for sharing by the Lead Professional > Plans can be downloaded if the ability to download a Plan has been enabled (at the site and/or user level?) > Access to a site can be suspended by the SharePoint System Administration when requested by the Lead Professional (eg when multi-agency intervention is no longer appropriate). The data will remain on the system but will not be visible to the linked professionals. > The system retains an audit trail of all access and updates to the system > Random audits of user access to the Childs Plan sites will be undertaken by the SharePoint Administration > Is the SharePoint search function enabled?


> No direct system to system integration is involved in the solution > However Highland Council, NHS Highland and Northern Constabulary users will access the system via linked secure networks, which will require firewall configuration by NHS Highland

Read only? > No - linked professionals can contribute documents directly to the system

User Access Method

> Direct logon to the SharePoint system > Access can be made available to users in public sector organisations, those providing commissioned services in from the third sector, and to children and families directly involved in Childs Plans

Access Control

> There will be one site per child > Users will be added to a trusted user list by SharePoint Administration. This does not automatically provide access to any sites. > The Lead Professional will control access to a site by selecting one or more users from a list of registered users > In the absence of the Lead Professional a system administrator will be able to control access > The Lead Professional may also be the Named Person > There is no role or team based access - all access is managed at the level of individual users > Blanket sharing consents only - no granular access by professional area > Users will only be able to see information they have uploaded themselves, or information that has been released for sharing by the Lead Professional > Sites will be made unavailable for sharing when a child turns 17?

Volumes > To be determined but probably 1000s of children will have plans across Highland > A professional could potentially have 100s of cases in the system

Planned > Planned to get CHI numbers seeded into CareFirst (as part of a national initiative - not





62/74

features essential for the new system)

Desirable features

Possibly in the future: > Provide an indication to users (especially in A&E) that a child is on the CPR and/or Looked After Children (Highland view is that CPM conflicts with the role of the Named Person in GIRFEC, however they would like to provide a central CP register that locations such as A&E departments and children’s wards can have lookup access to - as stated in the eCare Review Document Sept 2012) > Provide an indication to users that a child is classed as vulnerable (see note below) > Indicator to Police that a person had a plan and who the Lead Professional is > Show the name and contact details for the Lead Professional > Show basic demographic details for the child > Allow access by fire and rescue staff > The system could be used for Adult Personal Plans in the future > Management reporting on usage of the system > No immediate requirements for local sharing of concerns regarding children > No strong desire for a national CPM solution > No current requirements for an electronic GIRFEC chronology - the Children's Plan includes a chronology

History > The Highland DSP tried to develop a local collaborative SSA solution that progressed as far as the trials stage > However, the trials showed it had too many critical bugs and would have been too expensive to develop further > Highland are now trialling the adult Personal Plan, which is adult version of the GIRFEC Child Plan. Highland do not really like SSA as a business process and will probably phase out SSA and adopt the Personal Plan. > A SharePoint system, initially for sharing Childrens Plans, is under development by Fujitsu > A limited pilot is planned for March 2013, involving representatives from education, social work, NHS Highlands and Northern Constabulary.

Notes > GPs should know that a child is on the CP Register but this information may not always be shared with secondary care professionals > NHS out of hours staff have access to CareFirst but not the CP data > It is worth noting that basic level technologies such as mobile phones and secure email have already improved information sharing > GPs have restricted access to CareFirst (including basic client details, chronologies, part of CPR) > There is no agreed or legal definition of a "vulnerable child". It may include all or part of the group of children who are part of a live case in CareFirst > A minimum specification of internet browser is required to access the system (what types / versions? IE7 and later?)

Benefits of Sharing

> Streamlines the process for the Lead Professional > Faster creation of plans > More effective alerting of linked professionals that a new plan has been created > Reduced risk of inappropriate sharing > Improved information security > Professionals are more likely to view plans, and more likely to view the most recent version > Better sharing of plans with the 3rd sector and families





63/74

> Faster sharing of plans, especially with those who don't have secure email > Providing accurate and up-to-date information to support early intervention and rapid identification of children at risk > Consistent feedback from NHS Highland to Social Work on the outcomes of contact with a child

Solution Shet land Solut ion Single Shared System

Partners > Shetland Islands Council Community Care, Social Work, ASBO team, Education, Housing Outreach, Youth Team > NHS Shetland

> Voluntary sector (eg befriending service), Community Alcohol and Drugs Services > Skills Development Scotland



Shetland Islands Council - SWIFT Shetland use SWIFT as an area for data sharing with direct access by professionals. There are no electronic interfaces to other systems.

Matching Approach

> Matching is manually achieved by the practitioners. However, there is a problem of similar names. > Will be seeding the CHI number into SWIFT to improve matching.

Data Shared SSAs > SSAs are created as PDF documents and attached to client records in SWIFT (A subset of SSA data is held as SWIFT data) > The SWIFT data for SSA includes basic demographic data, assessment dates, involvements (in particular lead professional), reviews, needs and consent status. > Non social work partner agencies have been given access to SWIFT and can view a subset of the system and only the SSA clients > Partner agencies can see basic demographic data, SSA only contacts, assessment dates, involvements, needs, consent, eligibility criteria and reviews. CP register > The Children & Families team manually update a CP register. > Register details are securely shared by attaching them to a “false” record in SWIFT. > Health then access the record and put the details into their A&E system. > Also planning to do similar with adult protection.





64/74

Functions SSAs > An on-line PDF document is completed by the first practitioner in contact with the client. It is then uploaded to SWIFT and the client is marked as SSA. > SSAs generally originate from Community Care practitioners although a few can come from health professionals, especially community care nurses or ward staff prior to discharges. > Ward staff access SWIFT from a PC on the ward and attach a document to the case record > SWIFT system administrators audit for searches (eg interested in searches for people not linked to a case) CP Register > Health staff are manually notified of additions/changes to the CP register on SWIFT. They then update EDIS for A&E access with an alert that a child is on the register (also CP specialist nurses) > Health staff can then contact the duty social worker


> NHS and Council networks are securely linked via Firewalls > Health and Council Staff can access SWIFT (but currently not GPs outside Lerwick) > Voluntary sector users are co-located in a building which is on the Council network so many VS users can be given secure access to SWIFT

Read only? > No - linked professionals can contribute documents directly to the system > Read only access can be achieved where required, e.g. audits, inspections.

User Access Method

> Users can search in SWIFT by demographics. Would also like to add CHI number to SWIFT to facilitate searches. > The search is restricted to the search functionality on that screen in SWIFT. Users typically use names, dob or addresses.

Access Control

> Electronic access is managed by SWIFT System Admin. > Users are assigned to a group based on approval by appropriate managements. > The audit record can track attempts to access records where a user does not have a clear involvement > Typically professionals have more than one case. Assignment to cases is managed on a team by team basis > SWIFT supports role based access and non-social work users are assigned to a role with limited access. There is a completely separate security model for Partner SSA only access > Possible issue with large case loads and staff turnover > Access to the CP register Swift record is restricted to a group of staff agreed by the Child Protection Committee. It is managed by the SWIFT System Admin team.

Volumes > 10 to 15 children on the CP register > There are approximately 700 adult assessments under With You For You

Planned features

> Shetland are running a pilot based on consent to share information on chaotic young people using the same SWIFT based approaches.





65/74

Desirable features

> The GIRFEC principles are supported but are still working through the practicalities. > Will possibly use some variation of the SSA solution for the Child Plan > Would like to get CHI numbers seeded into SWIFT to assist manual client identification (especially for service users with similar names) > Would not expect NHS staff to do the seeding > Considering CP alerts into the GPs EMIS systems > Would like to get all GPs access to SWIFT (not just Lerwick) > Are considering using a more modern system than SWIFT to share data in a similar way. Ultimately would like to get to a portal solution.l > A Scottish or UK wide CP alert system would be useful - people tend to runaway to Shetland > Some sort of way to share UK missing persons alerts would also be highly desirable. At the moment Shetland Islands Council receive requests from English local authorities to log into their own (English individual LA system) to view missing child alerts. This will become more and more risky as more English local authorities introduce individual systems. Some way to feed all UK alerts into a Scottish notification system would be very useful.

History > Shetland did not use any of the eCare functions > SWIFT based solution is operational

Notes > Shetland have used a LEAN exercise to simplify the existing process for SSAs and reduce the paperwork > SSAs are used for a range of functions, including children transitioning to adult services, supported living, employability, housing and older persons services > No Fire and Rescue data sharing at the moment > Police do not access SWIFT but do hold weekly meetings with Social Work staff – > There is a paper based process for the police to notify Social Work of concerns > GIRFEC chronologies are under review but no firm plans for sharing them

Benefits of sharing

> Less repetition of assessments > Speedier assessments > Shortened pathways > Broader range of services can be put in place to support plans > Faster implementation of plans > More accessible services > More capacity to deliver a tailored service > Better information security > Reduced risk to children > Better knowledge of what other practitioners do > Supporting principles and practice of early intervention.

Solution Western Isles

Partners > Comhairle Nan Eilean Siar > NHS Western Isles






66/74


NHS Western Isles - Tynedale There is currently no data sharing solution in use in the area apart from eCare CPM between Children’s Services and Social & Community services with NHS Western Isles

Comhairle nan Eilean Siar (CNES) Social Work - OLM CareFirst

Comhairle nan Eilean Siar Education - E1

Matching Approach

> No data matching is undertaken > Low volumes may mean that manual matching would be sufficient in the future > In the future agreed that there needs to be a master indexing methodology but not agreed what this should be. Each of the agencies systems generate unique referencing for their system. The use of CHI index has been discussed but not agreed that this should be the master index.

Data Shared > SSAs are used electronically within CNES Social & Community services (S&CS) but only shared on paper with NHS. > eCare CPM is currently used. Children’s Services and S&CS generate messages and the functionality to pick up messages is available to NHS via the Tynedale system. The functionality is not available outwith S&CS and NHS > There are plans to replace the Tynedale system which is the vehicle for eCare CPM in Health.


No system integration takes place apart from eCare CPM as outlined above

Volumes 2 people on the CP register

Planned features

No definite plans for a replacement data sharing system

Desirable features

> The DSP consider it vital to be able share data across DSP boundaries. However rather than wait for an all singing all dancing system they would be happy to see the local solution further developed initially rather than try to accommodate every scenario at the outset. > Common interface standards and sharing protocols, and a secure infrastructure would be required for national sharing. > Pro-active alerts to users when records added or changed in the CPR > Need to share a chronological history of an engagement > The ability to have remote access to information might be helpful but was not seen as a driver. There is concern that the challenges presented by the islands infrastructure technology might not support this > There is a strong consensus of opinion that the system must be managed, maintained and developed at a local level > The system must be scalable to allow communications with other Board’s systems in the future > Existing systems should be utilised if practical, eg SCI Store

History Using eCare for CPM but not SSAs





67/74

Notes > Currently Use of NHS mail for secure messaging. However there is some embryonic work looking at the possibility of extending the use of digital pens/ forms into this area, using a jointly designed form > GIRFEC business processes have been developed by Education and Children’s Services and the associated sharing will follow the DSP protocol. > Children’s Services have commissioned Carefirst to create a Child’s Plan Form and the plan will be stored in MS Word format in the Education Service MIS e1 for school and Education staff > Need to complete protocols, procedures and agreements between all the agencies involved > Meetings are held on a weekly basis where all the currently involved agencies discuss specific cases, this provides opportunities to discuss the issues in more detail > The three main agencies are using their own systems and believe that these are sufficient , and that any new arrangements must provide improvements/value above and beyond the current arrangements which include a very successful networking arrangement based on telephone, conversations, e-mails and meetings. > General view that perhaps information flows should be one-way, with certain agencies providing information, but not having access to “read” information on the system(s). There would need to be greater involvement in the weekly meetings.

Benefits of sharing

Not reviewed as part of this study.

Solution Borders Central Store

Partners > NHS Borders > Borders Council



Borders Social Work – Frameworki from CoreLogic Borders Education – SEEMIS Probably NHS Borders - Trakcare PMS system

To be determined > Possibly based on Ensemble, Cache and HealthShare Foundation from InterSystems as per Grampian > Proposed interface technologies are: TrakCare - HL7 Frameworki – XML ? SEEMiS - XML

Matching Approach

> If Grampian architecture is followed then will use a central matching index of identifiers from linked systems, including CHI numbers and Frameworki ids. > Not considering CHI seeding of social work data in Frameworki – business have reservations about data protection.

Data Shared > Proposed scope only includes CPM as a replacement for eCare CPM, between Social Work and Education. > Also likely to share CPM with NHS users but may depend on the solution chosen, eg if Intersystems Ensemble as a solution then it will include NHS Borders > Would like to support 6 main messages (including linked adult and linked child messages) > May want to include some form of descriptive free text or lookup value in the message





68/74

Functions > Would like to send CPMs from Social Work (Frameworki ) to Borders Education (SEEMiS) as this is happening by national eCare at the moment > If possible also send CPM messages from Frameworki to TrakCare for NHS users, and for alerts to be displayed next to the correct patient data > A process to match identifiers across the 2 systems would be required > Not decided if an interface for CHI lookup and CHI broadcast would also be required. > The solution would need to ensure that shared messages are kept synchronised with the source data > Important for users to be able to see expired messages


> Possibly as per Grampian use a publisher / subscriber model, with information exchanged with a surrounding "wrapper" > Not determined what format of messages from Frameworki – possibly XLM > Believed that comms infrastructure in place

Read only? > If Grampian architecture utilised then Centrally held message data can not be updated directly - only viewed via LoB systems or by the Viewing / Matching UI > Centrally held matching data in the Patient Index could be able to be updated directly by the Viewing / Matching UI

User Access Method

> To be determined, but possibly only matching index held centrally so all access via patient/client context in linked LoB systems

Access Control

> PMS operates a Role Based Access model. CPM messages would be treated as a medical alert ie restricted access

Volumes Border eCare CPM activity during the financial year 2011/2012: > Number of new children with a Child Protection warning - 168 > Number of new children with a Linked Person CP warning - 2 > Number of CPMs retrieved by agency adaptors - 296 (from Stephen Pratt’s Review of the existing national eCare Framework) Believed to be less than 50 entries on the CP Register

Planned features

> No desire for sharing CPM outwith Borders, although thought to be cross border movements, eg Borders resident children attending school and hospital in Edinburgh > However local solution identified should not be incompatible with solutions within other DSPs so that connection between DSP regions can be attained if a child enters or leaves a region. > The solution should also support the amalgamation of statistical information for national purposes. > Not considering police, 3rd sector of Fire & Rescue involvement at present > Sharing of assessments and plans has been looked at in the past but not in scope of current proposal.

Desirable features

The ability to provide Integrated Assessments for children (GIRFEC)

History > Borders had started using the eCare CPM facilities and now need to implement a replacement given the planned decommissioning of eCare > eCare CP messages were only shared between Education and Social Work professionals, with the matching data provided by NHS Borders. > Have submitted an application to the SG for funding to develop a replacement > Have considered 3 options: do nothing; implement in-house solution; implement a solution based on Ensemble and the Grampian architecture.





69/74

Notes > Borders DSP has been disbanded > A project board has been appointed to manage the implementation of a replacement

Business Benefits

> Want to retain benefits of electronic CPM post eCare > Want to share CPM with NHS > Would like to build a platform to support future health and social care data sharing

Solution Dumfries and Galloway Portal / Central Store

Partners > NHS Dumfries and Galloway > Dumfries and Galloway Council



Social Work - – Frameworki from CoreLogic NHS secondary care – MiDIS NHS GP systems – INPS (1) / EMIS (33)

Matching Approach

> F rameworki records are seeded with CHI numbers > To be determined how dartEDM data will be matched, albeit CHI is used throughout.

Data Shared > Plans and assessments > Child Protection alerts / messages

Planned Functions

> Create and maintain shared plans and assessments in dartEDM > Create child protection messages / alerts in Frameworki for distribution to NHS secondary care users (including read acknowledgements) > Good audit trail in dartEDM


> Link dartEDM to Frameworki (has been done in England) > Link dartEDM to GP systems (both INPS and EMIS) > Midis / dartEDM integration – dartEDM will be fed by completed documents > Use Ensemble for matching and integration, > Use XML messages as part of Ensemble > Use the dartEDM alerting and messaging function > Use CareFx as an overall portal to provide an integrated view of data in dartEDM, Midis and Frameworki > CareFx forces the synchronisation of views for a patient.

Read only? > Social Workers could have a read only view of documents in dartEDM

User Access Method

> Via CareFx > Direct to dartEDM

Access Control

> Time limited consents in dartEDM > Self consent model - dartEDM asks what relationship the user has with the patient and why they want access > Looking at how social work access can be managed





70/74

Volumes Relatively low volumes of children on the CP register

Desirable features

> Links to data in SEEMIS > DartEDM could provide true document collaboration using local forms

History > In the past both the council and NHS secondary care had in-house developed systems linked using JWS (Joint Working System) with an architecture similar to eCare. Subsequently both have moved to commercial packages and the linkage has been lost. > Have never used national eCare system

Notes > Unitary authority - 1 health board and 1 council > Information currently shared manually via weekly case conferences, email and non-electronic means > Have worked with Martin Egan at NHS Lothian at NHS Lothian on Midis integration > As part of the drive to reduce the usage of paper NHS D&G have purchased the DartEDM electronic document management system from Plumtree Group. This will be used for electronic case notes management. > Part of the MIDIS consortium with Lothian, Fife and Borders > Are adopting SASPI to manage information sharing governance (would include police, education and the 3rd sector) > 20% patients are from England so no CHI numbers. D&G residents also use English hospitals.

Business Benefits

Solution Fife Portal Notes to be confirmed by NHS Fife

Partners > NHS Fife > Fife Council



> Social Work - –Swift from Northgate > NHS – MiDIS and CareFx Patient Portal,

Excelicare, Adastra > NHS GP systems – 15% INPS / 85% EMIS

Matching Approach

> Clinical Portal using CHI as master – Record Locator Service to provide matching > Unmatched record processing as follows - Sits on exception file, NHS Access SCI and

Clinical Portal, duplication Records, Non NHS limited access to SCI store, Store-to-Store, Record Locator Service (to be developed).

Data Shared > Planned to share: SSA (Single Share Assessments), Emergency Care Summary (ECS), Key Information Summary (KIS), Palliative Care Summary (ePCS), GP Summary (recent GP tratement), GIRFEC (but not looked at in any detail).

> All these data types could be shared with non NHS professionals, eg Social Work staff? Or just extend access to KIS to non NHS professionals?

> Includes basic patient demographics in ECS and KIS, and professional contacts in KIS (the Patient Contact List).





71/74

> There are currently 6 health apps integrated with MiDIS, including district nursing and other community based services.

> Would also like to share selected social work data from SWIFT.

Planned Functions

> Making health information available in the clinical portal. > Integration with selected social work data from SWIFT


> Ensemble as an integration engine. > CareFx Clinical Portal (extended to include Social Record in SWIFT – could use same

approach as NHS Lothian) > Patient Portal > CDR

Read only? > Phase One – View Only > Phase Two – View and Do using Portal forms. Could deliver proper integrated

assessments. Could also use for GIRFEC chronologies.

User Access Method

> Access directly into SWIFT via a landing portal – view only > Precise access model needs to be resolved – likely to be role based.

Access Control

> Managed by Fife Council. > Use proxy cards to access the portal at the moment with strong authentication.

Volumes > Currently very limited with limited links in place > In the future there will be large volumes increasing as solutions to record electronic

information increase and opportunities to share increase.

Desirable features

> Augmenting clinical portal with local authority, police, 3rd sector etc electronic information.

> Would like to provide mobile access > Automatic access from SWIFT to SCI store to obtain CHI numbers > Cross border sharing of data is important for the future, although users might need to

accept slower response times when accessing cross border data, > CPM could be developed via the portal (including acknowledgements)

History > Currently much sharing is done via the emailing of information between secure email addresses

> An ISP between health and social care has been developed > NHS staff in some areas currently have access to SWIFT – view only access to SSAs > There has been some CHI seeding in SWIFT

Notes > Already use DartEDM electronic document management system from Plumtree Group to hold archived documents (see D&G notes).

Business Benefits

> Minimise the risk to patients/clients and therefore the organisation of out of date information.

> Reduced delays information sharing

Solution Orkney Notes to be confirmed by NHS Orkney





72/74

Partners > NHS Orkney > Orkney Islands Council

Current Area and System Social Work – Paris from In4tek Ltd NHS Orkney – what A&E systems now? What GP systems?

Technology There is currently no electronic data sharing between health and social work or any other agencies.


> No system to system interfaces planned at the moment

Matching Approach

> No data matching at present > CHI numbers are manually added to some records in Paris (to be confirmed if this happens and how they are obtained)

Data Shared > There is no dedicated systems for data sharing between health and social work > No data shared with Education apart from ad-hoc data requests

Planned Functions

> No plans at the moment for regular electronic data sharing between social work, NHS or education.


> Secure private fibre link between the Council and NHS

Read only?

User Access Method

> Some health staff are given access to Paris by social work staff. To be confirmed what data can be accessed. Assessments and plans?

Access Control

> Paris provides role based access > A data sharing protocol between health and social care has been agreed at a high level but not signed off – more work is required.

Volumes > Number of children on the CPR is very low – approximate numbers to be confirmed

Desirable features

> Could possibly use Ensemble to exchange data between PMS TrakCare (if implemented) and Paris, however no definite plans at the moment – could be 2 years away. > There is no requirement to share Child Protection messages with areas outwith Orkney

History > Information currently shared manually between health and social care via weekly case conferences, email and non-electronic means > Orkney Health and Care organisation was established in April 2010. It manages the full range of social services previously provided by Orkney Islands Council, and a number of services previously provided by NHS Orkney. There is no DSP.

Notes > Unitary authority - 1 health board and 1 council > Improved information sharing is not one of the key themes of the Orkney Health and Care Local Delivery Plan for 2011/12 – the focus has been on other areas to date. > NHS A&E have system for managing child protection concerns. Any contact with social work is by manual means. > NHS Orkney are considering implementing the Grampian hosted PMS TrakCare to support community nursing. > Have never used the national eCare system in the Orkneys > Significant numbers of patients are treated by NHS Grampian and Highland. Data is shared on these patients in formal and ad hoc ways. Sharing could be improved if PMS





73/74

Trakcare is implemented. > Orkney NHS staff can view the Grampian SCI store.

Business Benefits

> Not properly considered

Solution Forth Valley Notes to be confirmed by NHS Forth Valley

Partners

> NHS Forth Valley > Stirling Council > Clackmannanshire Council

> Falkirk Council > Central Scotland Police > Fire & Rescue > Scottish Ambulance service (Intended)

Planned interfaces

Area and System Technology

> NHS Forth Valley Secondary Care – MIDIS > Stirling Council Social Work – SWIFT > Stirling Council Education – SEEMIS > Falkirk Council Social Work – In house solution > Falkirk Council Education – SEEMIS > Clackmannanshire Council Social Work – CCIS > Clackmannanshire Council Education - SEEMIS

There is currently no technical data sharing solution in use between health and social care. This is done manually through integrated teams or direct data requests via face to face, phone or email. NHS FV have implemented a clinical portal (NHS FV version of the Tayside portal) to link with secondary care, which is currently in Phase 1 and being tested in specific outpatient clinics. This allows clinicians to access collated patient based information from a variety of systems. In the future this could expand to other partners including social care.

Matching Approach

> No electronic data matching is undertaken > Manual matching is conducted using patient demographics > Historically for eCart CHI matching was undertaken but no seeding

Data Shared > CPM email alerts are received > SSA printed from MIDIS and shared upon request > Clinical portal currently shares details of previous and current admissions, details of previous and current outpatient appointments, allergies and alerts, referral letters, discharge letters, clinic letters, labs results, radiology results, links to SID, clinical guidance websites on the intranet and internet and BNF website

Functions N/A


No system integration takes place between health and social care





74/74

Read only? >Clinical portal currently only allows read only access to clinicians > In future if a portal solution is implemented providing access to social care and partners read only access would be granted by role on a ‘need to know’ basis

User Access Method

> For clinical portal it is a single sign on approach > For social care data sharing this is requested through face to face, email or phone interactions

Access Control

> Would be role based

Volumes > 1,300 episodes of electronic information transfer between LA/Police per month (excluding telephone and face to face transfer)

Planned features

>MIDIS to comply with GIRFEC requirements > Clinical portal future phases – to included users beyond secondary care such as primary care, community care and longer term LA partners

Desirable features

>Portal & ensemble solution > Share data with all partners involved > Two way sharing process between NHS and partners > Share CPM & VA data across the 3 LA’s and nationally > SSAs > Share change of details i.e. carer information

History > Part of the eCare programme, NHS Forth Valley got to the testing stage with eCart. However, there were problems regarding this solution such as inability to access data from community sites and security issues, and eventually this was not progressed. > eCart and the council systems also had an interface with MAS whereby any demographics/shared assessments could be viewed, however when eCart was pulled so was the MAS and instead NHS Forth Valley implemented MIDIS but didn’t link to a MAS because they feel that this has been discontinued at a National level.

Notes > All forms used are GIRFEC compliant > No current plan (over next 2 years) to share ECS/KIS with social workers. KIS easier to access via web services therefore could be a possibility if/when portal is implemented > No funding available for data sharing and so no one has that role/responsibility > There has been more of a focus on telehealth/telecare as being one of the DALLAS partners > NHS Forth Valley have complications with the 3 Councils as they all employ their own systems. There is no standardisation/consistency between them which makes it difficult to integrate the systems > NHS Forth Valley have developed a protocol for sharing information and are awaiting signatures from partners involved > A lot of groundwork has been done for Information Sharing Procedures but nothing has materialised into plans yet

Benefits of sharing

> Shared Assessments > Avoiding duplication > More joined up services > Increase patient safety

information architecture review - shb.scot.nhs.uk · information from allan small on girfec...

Documents