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

severity67,973 92.7%

Low severity 17,747 92.9%

The kit we operate

is unpredictable

Where are we (2010)?

Safety statistics

•>200 assessed systems

releases

•5 years safety records

•Clinical Safety Group

•10 Regional CSOs

•UK IT safety standards

• For supplier

• For Health Organisations

Safety incidents

•Over 500 reported safety

incidents with IT systems

•Under reporting present

•Key dangerous areas

• Data migration

• Prescribing

• Imaging

• Failure of backup

•But NO deaths attributable

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

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

There is an existing, proven, scientific body of

knowledge into which we should tap.

A marriage made in heaven?

Induction ceremony for a newly qualified Safety Engineer

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 ...

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:

Safety improvements in Health & Social Care organisations

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)

Development

and

interpretation of

policy

Definition and

review of safety

and other

standards

Delivery of

outcomes

Excluded from the scope

of the safety study

Feedback

Safety activity map

Interpret for

Health & Social Care

operations

Implement change to

operations

Run

operation

Develop and communicate

advice, standards,

procedures and guidelines

Interpret policy for third

party connection

Deliver

outcomes

Deliver

outcomes

Manage/monitor

delivery of

outcomes

Develop

safety policy

& safety-

related

strategies

Develop safety

policy

Develop safety-

related strategy

Work with

national bodies,

x-government,

Europe

Not to scale! The size of the boxes does not indicate anything about the

scale or importance of roles.

Interpret for centrally

managed systems

Implement release

(primary use)

Run systems

(primary use)

Run systems

(secondary use)

Conduct feasibility and proof

of concept activities

Develop and own

requirements for primary use

Develop and own

requirements for secondary

use

Run safety projects

Define/review standards

Define and review safety standards

Define user interface, data and other standards

Develop and own

requirements for third party

connection

For each role, the safety activities can fall into the following categories:

- Do (carrying out the role)

- Assure/enforce

- Advise/support

Implement release

(secondary use)

However ...