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

on

  • 2,012 views

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)

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)

Statistics

Views

Total Views
2,012
Views on SlideShare
2,005
Embed Views
7

Actions

Likes
0
Downloads
21
Comments
0

1 Embed 7

http://www.slideshare.net 7

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • Safer clinical systems : IT safety management on the NHS National Programme Prof Michael Thick Chief Clinical Officer Connecting for Health
    • 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
    • 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
    • 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%
    • The kit we operate is unpredictable
    • 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
    • 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 other safety industries would” • Kick started (Sep 2004) formation of Clinical Safety Management System • Legal opinion “CfH have a duty of care…”
    • 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
    • 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
    • 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
    • A common clinical condition
    • 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”
    • Our approach must change with lessons learned
    • 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
    • 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?
    • 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
    • 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?
    • 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
    • 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.
    • However ...