Health Informatics – Application of Clinical Risk Management to the Manufacture and Deployment of Health Software. Thick M. eHealth week 2010 (Barcelona: CCIB Convention Centre; 2010)

1. Safer clinical systems :
IT safety management on the NHS National Programme
Prof Michael Thick
Chief Clinical Officer
Connecting for Health

2. Overview
 Why do we need a formal approach to IT safety?
 Where we are
 Where we came from
 Clinicians and Safety Engineers: a marriage made in heaven
(I think.....)
 Issues presented by Large Scale Integrated health systems
 Future direction
 Thoughts to provoke

3. Why do we need a formal approach
to IT safety?
•Airbus – first fly by
wire aircfraft
•Safety controls over
ridden to allow low
level pass (30m)
•Pilot fights software
for control (s/ware in
landing mode) 1988

4. It could never happen to us?
"Overrides of Medication Alerts in Ambulatory Care," Archives of Internal Medicine,
Feb. 9 2009 (archinte.ama-assn.org/cgi/content/abstract/169/3/305)
Physicians ignore electronic drug-safety alerts more than 90% of the time. The rate
does not vary much based on how e-prescribing systems classify the severity of
the potential drug interaction.
Alert type Drug-safety alerts Overridden
High severity 143,943 89.6%
Moderate
67,973 92.7%
severity
Low severity 17,747 92.9%

5. The kit we operate
is unpredictable

6. Where are we (2010)?
Safety statistics Safety incidents
•>200 assessed systems •Over 500 reported safety
releases incidents with IT systems
•Under reporting present
•5 years safety records
•Clinical Safety Group •Key dangerous areas
•10 Regional CSOs • Data migration
• Prescribing
• Imaging
•UK IT safety standards
• Failure of backup
• For supplier
•But NO deaths attributable
• For Health Organisations

7. We have travelled a long way...

8. Where we came from
(2004)
• Review by NPSA : critical of lack of systematic
approach to IT safety management
“and other safety industries would”
• Kick started (Sep 2004) formation of Clinical
Safety Management System
• Legal opinion “CfH have a duty of care…”

9. Safety engineering for clinical
systems
There is an existing, proven, scientific body of
knowledge into which we should tap.
Industry Standards Techniques
Defence Industry Def Stan 0055/56 Safety cases
FMEA
Human Factors
Aerospace DO178B & C Type approval
Hazard assessment
Electronics IEC61508 Safety management
system

10. A marriage made in heaven?
In order to deploy safety engineering techniques effectively we “pair”
a safety engineer and a clinician trained in IT risk management.
Both sides need to make cultural adjustments ...
Induction ceremony for a newly qualified Safety Engineer

11. Issues presented by Large Scale
Integrated Health Systems
• We are working with York University (who
have a specialist software safety team under
Dr Tim Kelly) – papers later in 2010
• We are examining the differences between
safety in “closed” engineering systems and
large “open” ehealth systems
• There are some key differences which need
managing otherwise safety is compromised

12. A common clinical condition

13. Issues presented by Large Scale
Integrated Health Systems
Some examples :
• Same-functionality on different hardware
• Lack of empirical safety data
• Multiple and complex vendor relationships
• User population with vastly different “training”
levels from “patient” to “consultant”

14. Our
approach
must
change
with
lessons
learned

15. Future direction (Macro influences)
Environment :
• EU legislation on medical software
• Ageing population & chronic conditions :
VTE, T2 Diabetes
• Health budget squeezed
= More cost effective safety approaches
but also more safety approaches

16. Future direction (technology)
Some challenging safety projects :
• VTE risk assessment tool & closed loops
• Cross border exchange of patient alerts
• Telehealth : glucose monitoring
But : How to regulate safety?

17. Future direction (profession)
Safety engineering in Health Informatics :
• National Occupational Competence
Framework
• Training courses in safety engineering
• Formal role : National Clinical Safety Officer
• UK Council for Health Informatics Professions

18. Don’t forget…...
• Safety comes with a price – can we afford it?
• What level of IT risk is “tolerable”? “No risk” is
impossible with a large scale health system.
• Can we regulate ehealth using a Medical
Device standard focused on standalone
software?

19. Our model:
Excluded from the scope
of the safety study
Development Safety improvements in Health & Social Care organisations Delivery of
and outcomes
interpretation of
policy Safety management for the development and operations of
centrally managed systems (primary use)
Safety management for the development and operations of
centrally managed systems (secondary use)
Safety management for the connection of third party systems (eg
MoD)
Definition and
review of safety
and other
standards

20. Develop Interpret for Implement change to Run Deliver
safety policy Health & Social Care operations operation outcomes
& safety- operations
related Develop and communicate Run safety projects
Safety activity map
strategies advice, standards,
procedures and guidelines
Feedback Interpret for centrally Implement release Run systems
Develop safety managed systems (primary use) (primary use)
policy
Develop safety- Conduct feasibility and proof
related strategy of concept activities
Deliver
outcomes
Work with Develop and own
national bodies, requirements for primary use
Manage/monitor
x-government, Implement release Run systems delivery of
Europe Develop and own (secondary use) (secondary use) outcomes
requirements for secondary
use
Interpret policy for third
party connection
Develop and own
requirements for third party
connection
For each role, the safety activities can fall into the following categories:
Define/review standards - Do (carrying out the role)
- Assure/enforce
Define and review safety standards
- Advise/support
Define user interface, data and other standards
Not to scale! The size of the boxes does not indicate anything about the
scale or importance of roles.

22. However ...