DPSIMS

Patient Safety Incident Information Model

Stakeholder Engagement Session 3

21st June 2017

1

Agenda

2

10.30 – 11.00 Registration & networking – Tea and Coffee

Opening Plenary - Introduction and welcome Lucie Mussett, NHSI

Update Progress and Plans & Timetable for next steps Kathy Mason, Arden Gem team

Presentation of Information Model Development Richard Oakley- Arden Gem team

Q&A Session - Including Expert Panel Members Delivery team

Plenary – explanation of working group sessions Kathy Mason

Commence Group working Session 1 All

12.30 – 13.00 Working Lunch

Working Group session 1 - continued All

Commence Group Session 2 All

14.30 Tea available

Working Group session 2 - continued All

Plenary – Feedback from Working Groups and Next Steps Kathy Mason/Lucie Mussett

15.30 Close

3

Lucie Mussett

Opening Plenary - Introduction

and welcome

4

Kathy Mason

Progress, Plans, Timetable

DPSIMS programme – high level timeline

Information Model

• Now –July 2017

Alpha build (prototyping)

• Aug 2017 - ?Oct/Nov 2017

Beta phase (expansion,

testing, development)

• ?Oct/Nov 2017 - ?late 2018

Live phase roll out!

•?2019 onwards

Overall Timetable

April 2017 - Complete

May/June 2017

Deliverables:

• Horizon Scan Report

• AS IS Review Report

• Stakeholder Workshop, materials

• Method Statement and Use Cases

July 2017

Deliverables:

• Impact Analysis

• Migration Roadmap

• Data Model

• Taxonomy

• Functional Model

• Final Summary Report

This stage of DPSIMS is a ‘deep dive’ into the core component –

Patient Safety Incident Information Model Development Project

6

Reminder of governance structure

Core team and expert panel: • Have worked together previously on

several NHS England national programmes

• Combine technical knowledge and clinical expertise with delivery experience

• Acknowledge and commit to stakeholder engagement

• Have deep understanding of national and international programmes

• Bring deep expertise in data modelling and standards

• Panel made up of national leaders in patient safety with international links

Two delivery workstreams: • Stakeholder engagement

• Information modelling

7

8

Richard Oakley

Information Model Development

The Information Model

9

The new DPSIMS Information model consists of three elements:

• The data model

• The taxonomy

• The functional model

These each focus on different parts of the information model and interact in order to construct the

entirety that is required to shape the flow of information and (through implementation) the user

experience and ability to analytical analyse incident report to share learning.

The design focuses on supporting key aspects of the DPSIMS “pathway” effectively and efficiently and to

improve “fitness for purpose”

• Usability, specifically reducing complexity and uncertainty

• Reducing avoidable reliance on free text for data that should be part of a defined field

• Acknowledges that some free text is inevitable but its utilisation must be thought through

• Acknowledges that information may not all be available at the start of an individual incident

• Multiple purposes or “views”, stemming from a wider range of users

• Improving automated (pre-)analysis

• Scaling up to cover a much wider range of reports

• Providing designers with greater opportunities for implementing effective systems

Information Model components

10

The data model defines only the types of information (data items or fields) that are to be recorded in

relation to an incident or risk. It provides a picture of the structure of the data and the relationships

between entities, and the attributes of the entities. Additionally, constraints or restrictions on what

types of data are valid for each entity or attribute, and the relationships: cardinality (one-to-one, one-

to-many, etc.). A data model does not deal with the contents of the record or how it is to be used.

The data model is used as a basis for the data record used to capture details in a report.

The taxonomy lists and classifies the items found in the domain that we want to represent and

record. Similar items are grouped together, based on one or more characteristics or features (but

which are often not listed). Taxonomies are usually hierarchical, starting with general classes which

are divided into more granular subgroups. Several “levels” of subgroup may be used, as in ICD or

OPCS4. However, in contrast to ICD and OPCS4 which generally deal with only one type of item, in

many domains multiple taxonomies are necessary. This is the case in NRLS and DPSIMS. The

taxonomy supports control over the classes of items that are used in the information and data

models: for instance, separately defining “location" and "clinical role".

The functional model provides a way of representing different “use scenarios” by defining which

data fields are required, and any restrictions on the information that may legitimately be entered in

each field, within each scenario, over and above the core rules. The functional model is closely

aligned to and integrated with the data model and taxonomy.

The Data Model

11

Design Principles

• Comprehensive coverage for multiple settings and uses, with templates to specify which parts

are needed in each case – only relevant sections are used

• Systematic, structured design that clearly separates different aspects, such as coding, text for

data entry, rules to help detect inconsistent data

• Designed to be extensible in the future without having to re-engineer

• Takes account of legacy data models, international standards, etc., where possible

• Integrated with taxonomy

• The model is flexible and acknowledges much information may be unavailable

Our approach and structure

• Clearly demarcates different types of information

• Uses standardised classifications where these are relevant (but without requiring users to know

codes)

• “Rules” that link to the data model to help with consistency checking

• The rules cut down the amount of irrelevant information presented to a user

• Designed with easy updating in mind: both the data model and taxonomy can be extended or

updated with relatively low effort

• Reduces and removes arguments around “meaning” whilst retaining room for interpretation

Data Model and Taxonomy

Entity Relationship Model -1

12

Data Model and Taxonomy

Entity Relationship Model -2

13

14

Richard Oakley

Information Model Development

The Information Model

15

The new DPSIMS Information model consists of three elements:

• The data model

• The taxonomy

• The functional model framework

These each focus on different parts of the overall model and interact in order to illustrate and define the

flow of information and (through implementation) the user experience and outputs.

The design focuses on supporting key aspects of the DPSIMS project effectively and efficiently, helping it

achieve its aims and ambitions. To this end, key considerations are:

• Usability, specifically reducing complexity and uncertainty

• Reducing avoidable reliance on free text for data that should be part of a defined field

• Acknowledgement that some free text is required but its utilisation must be thought through

• Acknowledgment that all information may not be available at the point of report

• Multiple purposes or “views”, stemming from a wider range of users

• Improving automated (pre-)analysis

• Scaling up to cover a much wider range of incident reporting both in depth and breadth

• Providing designers with greater opportunities for implementing effective systems

Information Model components

16

The data model provides a picture of the structure of the data as it is logically held within the

database, the relationships between tables, and the fields in each of those. Additionally it details

constraints or restrictions on what types of data are valid for each field and rules regarding required

data items and relationships. A data model does not deal with the contents of any one record or how

it is to be used. The data model gives the build team all the information they require on how to

construct the framework within which other parts of the information model are physically held.

The taxonomy lists and classifies the items found in the domain that we want to represent and

record. Similar items are grouped together, based on one or more characteristics or features (but

which are often not listed). Taxonomies are usually hierarchical, starting with general classes which

are divided into more granular subgroups. Several “levels” of subgroup may be used, as in ICD or

OPCS4. However, in contrast to ICD and OPCS4 which generally deal with only one type of item, in

many domains multiple taxonomies are necessary. This is the case in NRLS and DPSIMS. The

taxonomy supports control over the classes of items that are used in the information and data

models: for instance, separately defining “location" and "clinical role".

The functional model framework provides a way of representing different “use scenarios” by

defining which data fields are required, and any restrictions on the information that may legitimately

be entered in each field, within each scenario, over and above the core rules. The functional model

is closely aligned to and integrated with the data model and taxonomy. It can be thought of as a high-

level visual representation of a use-case, outlining the interaction between users and other aspects

of the information model.

The Information Model: Methodology

17

Design Principles

• Comprehensive coverage for multiple settings and uses with clarity on which parts are needed

in each case to ensure only relevant sections are used

• Systematic, structured design that clearly separates different aspects, such as coding, text for

data entry, rules to help detect inconsistent data

• Designed to be extensible in the future without having to re-engineer

• Takes account of legacy data models, international standards, etc., where possible

• Integrated – the taxonomy and data model have to sit together

• Flexibility – use-cases change and evolve

• Extensibility – designed with an eye on future uses

• Speed – the model must be a performant structure for a system to sit on

Our approach and structure

• Clearly demarcates different types of information

• Uses standardised classifications where these are relevant (but without requiring users to know

codes)

• Rules that help with consistency checking both at input and output

• Designed with consideration; reducing irrelevant information presented to a user

• Designed with easy updating in mind: both the data model and taxonomy can be extended or

updated with relatively low effort

• Reduces and removes arguments around “meaning” whilst retaining room for interpretation

• Places unavoidable complexity into appropriate areas of the overall system

Information Model:

Entity Relationship Model

18

Information Model:

Entity Relationship Model - 2

19

Information Model:

Data Model - 1

20

Information Model:

Data Model - 2

21

Information Model:

Taxonomy - 1

22

So how do you build a section of a Taxonomy?

1. Use-case

2. Understand why and what that means

3. Research

4. Define

5. Validate

Information Model:

Taxonomy - 2

23

Use-case:

“When reporting an incident I am in a position to comment on some

of the contributory factors which led to this occurring, I wish to record

these with minimal fuss, associated with the incident I am reporting

on”.

Understanding what that means:

• “factors contributing to incidents” are a thing – they need to be captured

• Clearly there is some complexity here because “record these with

minimal fuss” is mentioned

• These directly relate to the incident being reported (or are perceived to)

Information Model:

Taxonomy – 3.1

24

Patient factors: Clinical condition Physical factors Social factors Psychological/ mental factors Interpersonal relationships

Individual (staff) factors: Physical issues Psychological Social/domestic Personality Cognitive factors

Task factors: Guidelines/ procedures/ protocols Decision aids Task design

Communication factors: Verbal Written Non-verbal Management

Team factors: Role congruence Leadership Support + cultural factors

Education + Training Factors: Competence Supervision Availability / Accessibility Appropriateness

Equipment + resources: Displays Integrity Positioning Usability

Working condition factors: Administrative Design of physical environment Environment Staffing Workload and hours Time

Organisational + strategic factors: Organisational structure Priorities Externally imported risks Safety culture

Problem or issue

(CDP/SDP)

Information Model:

Taxonomy – 3.2

25

Research:

http://www.who.int/patientsafety/taxonomy/icps_full_report.pdf

Image credit: WHO -

http://www.who.int/patientsafety/taxono

my/icps_full_report.pdf

Information Model:

Taxonomy – 3.3

26

Patient_Factors

Clinical_Condition

Pre-Existing_Co-Morbidity

Complexity_Of_Condition

Seriousness_Of_Condition

Limited_Options_Available_To_Treat_Condition

Disability

Physical_Factors

Poor_General_Physical_State

Malnourished

Dehydrated

Age_Related_Issues

Obese

Poor_Sleep_Pattern

Social_Factors

Cultural

Religious_Beliefs

Language

Lifestyle

Smoking

Drinking

Drugs

Diet

Sub-Standard_Living_Accommodation

e.g._Dilapidated

Life_Events

Lack_Of_Support_Networks

Social_Protective_Factors_-Mental_Health_Services

Engaging_In_High_Risk_Activity

Information Model:

Taxonomy – 3.4

27

Then link it into the data model

28

Q&A

29

Kathy Mason

Plenary – explanation of working

group session

Objectives of Group Work

• To develop Use Cases

• Informal versions of these based on User Stories developed previously

have been used so far to develop the draft information model

• Now need to expand and refine these to support next iteration of the

modelling

• Objective is to capture stakeholders’ vision and aims for the new

system

• To further develop understanding of anticipated Impacts and

Benefits of the new PSIMS Information Model (How hard will it be

to change in order to get the benefits?)

• To identify questions and issues to refer to Expert Panel

30

Group Work format – Session 1

• Delegates have been organised into 5 Working Groups based on

their organisations i.e. world views

• Each Group has been provided with examples of Use Cases to

demonstrate their use

• Objective: to develop 3 Use Cases using the proforma to capture

key points and other capture materials to facilitate discussion and

development

• Time allocated 60 minutes

• Each Group to appoint a chair and a scribe

31

Use Cases

32

• The Use Cases inform the development of the information model, in particular the

functional model component; which will underpin the next (Alpha) phase of system

development. The functional model demonstrates how the data model and

taxonomy are to be used in specific circumstances.

• Use Case driven development is iterative and incremental in nature and supports the

Agile development approach being used for the PSIMS.

• An initial set of Use Cases have been prepared from stakeholder input to date and

will continue to be refined and added to as the system goes through its development

phases.

• A Use Case is a list of actions or event steps, defining the interactions between a

role (Actor) and a system, to achieve a goal. The Actor can be a human or other

external system.

• It is the next Alpha phase which will produce a prototype of the systems for testing

and development with stakeholders, not this stage of the work. Use Cases do not

seek to identify system user interface details (which would complicate capture of the

Use Case and place constraints on the development of the information model too

early in the development process).

User Stories

33

• Builds on previous work to capture User Stories - informal, natural language description of one or

more features of the required system written from the perspective of a user of that system.

Captured in interactive sessions, using Post-it notes etc.

"As a <role>, I want <goal/desire> so that <benefit>" “As Nurse In Charge, I

need clear guidance on

what constitutes each

level of harm, so I can

advise my team how to

report incidents

accurately without wasting

time looking it up and

agonising over definitions” “As a patient safety lead, I

need to know if anyone

else has solved the

problem I’m stuck with,

so I can get a good

solution in place without

re-inventing the wheel”

“As a patient, I need to be

able to see why the NHS

makes the changes it

does so that I can feel

reassured that they are a

good idea for me and my

family”

“As an academic safety

science researcher, I need

to be able to use high-

quality service safety

data so that I can analyse

how public services can

most effectively improve

their safety practices while

being free to innovate”

34

• Patient Safety Incidents (voluntary, for purposes

of learning)

• Serious Incidents

• unexpected or avoidable death

• unexpected or avoidable injury resulting in

serious harm

• abuse

• Never Events;

• incidents that prevent an organisation’s

ability to continue to deliver an acceptable

quality of healthcare services

• incidents that cause widespread public

concern resulting in a loss of confidence in

healthcare services.

• Notifiable incidents

• Death of service user

• Serious injury to service user

• Abuse

• Yellow Card

• Side effects (ADR)

• Devices

• Defective Drugs

• Fake/Counterfeit Drugs

• E-cigarette issue

AS IS – Data Sources

35

Draft Use Cases – First batch

Use

Case

Content BAU/

future

state

Rank

1 As a ward nurse I need to be able to record a fall in an acute ward BAU High

2 As a practice manager in primary care I need to be able to record a

missed cancer diagnosis

BAU High

3 As a national reviewer I need to read, assess, categorise and

consider lessons from a serious harm incident

BAU High

4 As a Patient Safety Analyst, I need to be able to review recorded

incidents using key filters e.g. near miss incidents

BAU High

5 As a healthcare assistant, I need to be able to record what

happened when I found a patient unconscious in a corridor and

bleeding from a head wound

BAU High

6 As a risk manager, I need to be able to record concerns that you

now have to get sign off from the Nurse Director to order pressure-

relieving mattresses, which I do not believe has yet caused harm to

a patient, but might in the future

BAU High

Group Work format – Background task

• During Group both Sessions 1 and 2

• Using Post-It Notes provided • Add to and further develop headlines of Impacts and Benefits

anticipated from new PSIMS Information Model

• Queries and issues to refer to the Expert Panel

• Target – at least 6 of each from each Group

• Group providing most ideas wins a prize!

36

Group 1 - Local • Bridget Tustin - NELFT

• Sarah Morrice - NELFT

• Shruthi Belavadi - NHS E

• Jane Weatherill - Cumbia

• Carol Pennington - Cumbria

Group 2 Regional • Trevor Povey - Asda

• Kate Livesey - CCA

• William Rial - NHS E

• Jasmine Shah - NPA

• Peter Glover - DL

• Ifti Kahn - Well

• Lucinda Keenan - TPA

Group 5 – National • Paras Shah - MHRA

• Tony Sant - MHRA

• Justin Park - NHSI

• Ana Shaer-Levitt - CQC

• Felicity Mitchell - NHSD

• David Grreett - NHSI

• Frances Wood - NHSI

Group 4 - National • Matthew Fogarty - NHSI

• Lene Gurney - AHIO

• Fiona Grossick - NHS E

• Mitul Jadeja - MHRA

• Jeanette Beer - NHSR

• Melanie Harris - NHSW

• Philip Ashcroft - NHSI

Group 3 National • Madeleine Ottrey - PHE

• Helen Best - PHE

• Una Findlay - PHE

• Jane Woodland - PHE

• Steve Taylor - PHE

• Sue Bull - PHE

Breakout Groups

37

38

Working Lunch

39

Draft Use Cases – Second batch Use

Case

Content BAU/

future

state

Rank

7 As a relative I wish to report an incident where a dose of an important drug

was missed due to being out of stock

FS High

8 Dentistry e.g. As a dentist with no local risk management system, I need to

be able to record a patient safety incident happening in my small practice

FS High

9 As a night manager in a Local Authority-funded rehab centre I need to be

able to report a suspected accidental overdose of a controlled drug

FS High

10 As a learning lead at MHRA I need self-service access to all medicines and

devices related incidents recorded within the last week to cross reference

with Yellow Card reports and see if there are any issues we have missed

FS High

11 As a Registrar on a surgical ward I need to be able to record my perspective

as part of the team involved in a surgical Never Event

FS High

12 As a local risk manager, I need to understand how patterns of our own

patient safety incidents have changed over the last 2 years, and if my

organisation is comparable to a similar trust in the next county in this regard

FS High

13 As a Ward Manager, I need to know if anyone has developed a solution that

might work in my organisation for improving handover documentation to

reduce risks to patients

FS High

14 As an academic safety researcher, I want to understand how common

injuries due to bed rails are, and the severity of these injuries

FS High

15 As a ward nurse I need to be able to record a near miss in an acute ward BAU Mediu

m

16 As a lead investigator for my trust, I need to know how many other similar

investigations to the one I am undertaking have been carried out in the last

year, what their findings were, and what lessons we can learn from them

about contributory factors and actions for improvement

FS Mediu

m

17 As a nurse in a medium-security prison I need to be able to record the

details of harm to an inmate resulting from the use of restraint by a mixed

team of prison and healthcare staff

FS Low

18 As a database manager, I need to be assured that all provider codes are

updated and accurate on a daily basis

FS Low

And the next batch –

• building on User

Stories already

gathered

• Identifying additional

use cases

40

Draft Use Cases – Second batch Use

Case

Content BAU/

future

state

Rank

7 As a relative I wish to report an incident where a dose of an important drug

was missed due to being out of stock

FS High

8 Dentistry e.g. As a dentist with no local risk management system, I need to be

able to record a patient safety incident happening in my small practice

FS High

9 As a night manager in a Local Authority-funded rehab centre I need to be able

to report a suspected accidental overdose of a controlled drug

FS High

10 As a learning lead at MHRA I need self-service access to all medicines and

devices related incidents recorded within the last week to cross reference with

Yellow Card reports and see if there are any issues we have missed

FS High

11 As a Registrar on a surgical ward I need to be able to record my perspective

as part of the team involved in a surgical Never Event

FS High

12 As a local risk manager, I need to understand how patterns of our own patient

safety incidents have changed over the last 2 years, and if my organisation is

comparable to a similar trust in the next county in this regard

FS High

13 As a Ward Manager, I need to know if anyone has developed a solution that

might work in my organisation for improving handover documentation to

reduce risks to patients

FS High

14 As an academic safety researcher, I want to understand how common injuries

due to bed rails are, and the severity of these injuries

FS High

15 As a ward nurse I need to be able to record a near miss in an acute ward BAU Medium

16 As a lead investigator for my trust, I need to know how many other similar

investigations to the one I am undertaking have been carried out in the last

year, what their findings were, and what lessons we can learn from them

about contributory factors and actions for improvement

FS Medium

17 As a nurse in a medium-security prison I need to be able to record the details

of harm to an inmate resulting from the use of restraint by a mixed team of

prison and healthcare staff

FS Low

18 As a database manager, I need to be assured that all provider codes are

updated and accurate on a daily basis

FS Low

Patient

/ carer

report

Care

home

setting

Primary

care No LRMS

LA-

funded

National

Statutory

functions Low-

reporting

staff grps Better

outputs/data

for local use Info on

solutions/

interventions Research

community

needs,

international

uses Theming

info

Investigations

Offender

health

Back-end/

technical

functions

41

Kathy Mason

Lucie Mussett

Plenary – Feedback and

conclusions from Group work &

next steps

Stakeholders - who is in the room?

National Users

• National Patient Safety team

• NHS Improvement regional teams

• MHRA

• CQC

• NHS Resolution

Local Users • Local Risk and/or Patient Safety Managers

• Frontline reporters

• Commissioners (CCGs)

• Patients/relatives/carers

• [what about other regulators, commissioners]

Research community

• Academics

• Safety Science community

• Professional associations

• Specialist safety improvement projects (eg. Anaesthetics)

42

Stakeholders - is missing that we need to add?

Group Work Feedback

• Which Uses Cases worked on

• Gaps?

• New Use Cases identified

• Other headlines

• Have you written it down!

43

Staying in touch

Contact details:

• Website - http://www.ardengemcsu.nhs.uk/dpsims

• Email for comments and feedback - dpsims-stakeholders@nhs.net

44