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 - [email protected]
44