Safer clinical systems :
IT safety management on the NHS National Programme



                            Prof Michael Th...
Overview
 Why do we need a formal approach to IT safety?
 Where we are
 Where we came from

 Clinicians and Safety Eng...
Why do we need a formal approach
to IT safety?
•Airbus – first fly by
wire aircfraft
•Safety controls over
ridden to allow...
It could never happen to us?
"Overrides of Medication Alerts in Ambulatory Care," Archives of Internal Medicine,
   Feb. 9...
The kit we operate
is unpredictable
Where are we (2010)?

Safety statistics               Safety incidents
•>200 assessed systems          •Over 500 reported ...
We have travelled a long way...
Where we came from
(2004)
• Review by NPSA : critical of lack of systematic
  approach to IT safety management

  “and oth...
Safety engineering for clinical
systems
  There is an existing, proven, scientific body of
  knowledge into which we shoul...
A marriage made in heaven?
In order to deploy safety engineering techniques effectively we “pair”
a safety engineer and a ...
Issues presented by Large Scale
Integrated Health Systems
• We are working with York University (who
  have a specialist s...
A common clinical condition
Issues presented by Large Scale
Integrated Health Systems
Some examples :
• Same-functionality on different hardware
• Lac...
Our
approach
must
change
with
lessons
learned
Future direction (Macro influences)

Environment :
• EU legislation on medical software
• Ageing population & chronic cond...
Future direction (technology)

Some challenging safety projects :
• VTE risk assessment tool & closed loops

• Cross borde...
Future direction (profession)

Safety engineering in Health Informatics :
• National Occupational Competence
  Framework
•...
Don’t forget…...

• Safety comes with a price – can we afford it?

• What level of IT risk is “tolerable”? “No risk” is
  ...
Our model:
                                                             Excluded from the scope
                          ...
Develop                              Interpret for                   Implement change to               Run                ...
However ...
Health Informatics – Application of Clinical Risk Management to the Manufacture and Deployment of Health Software
Upcoming SlideShare
Loading in …5
×

Health Informatics – Application of Clinical Risk Management to the Manufacture and Deployment of Health Software

1,761 views

Published on

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)

Published in: Health & Medicine
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,761
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Health Informatics – Application of Clinical Risk Management to the Manufacture and Deployment of Health Software

  1. 1. Safer clinical systems : IT safety management on the NHS National Programme Prof Michael Thick Chief Clinical Officer Connecting for Health
  2. 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. 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. 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. 5. The kit we operate is unpredictable
  6. 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. 7. We have travelled a long way...
  8. 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. 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. 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. 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. 12. A common clinical condition
  13. 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. 14. Our approach must change with lessons learned
  15. 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. 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. 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. 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. 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. 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.
  21. 21. However ...

×