IEC 80001: An Introduction

IEC 80001: An Introduction

19th Annual NCBA Conference September 13, 2012

Sherman Eagles Partner, SoftwareCPR Principal, 80001 Experts, LLC

Copyright © 2012, 80001 Experts, LLC. All rights reserved.

2 IEC 80001 – An introduction

Sherman Eagles

• Medtronic Technical Fellow (retired 2008)

• Co-Chair AAMI Software Committee

– Editor of AAMI SW87 - Application of quality management system concepts to medical device data systems

• Convener of IEC & ISO working groups

– Editor for IEC 62304 – Medical device software lifecycles

– Editor for IEC 80001-1 – Risk management for IT-Networks incorporating medical devices

• ACCE 2012 Challenge award for work on 80001 and SW87


80001 – An Introduction

• What is 80001?

• What’s the context?

• What does 80001 require?

• Example

What is 80001?


• IEC 80001-1:2010, Application of risk

management for IT-networks incorporating

MEDICAL DEVICES – Part 1: Roles,

responsibilities and activities


A Standard

• A consensus set of requirements

developed by an international working

group with members from medical device

industry and hospital clinical engineering

and IT

• Adopted internationally by IEC and ISO

• Adopted in US by AAMI and ANSI


A Series of Documents

• IEC 80001-1:2010

PLUS

• IEC TR 80001-2-1:2012

• IEC TR 80001-2-2:2012

• IEC TR 80001-2-3:2012

• IEC TR 80001-2-4 (under development)

• IEC TR 80001-2-5 (under development)

• More coming


Risk Management Guidance

• IEC 80001-2-1 TR Ed.1.0 - "Application of

risk management for IT-networks

incorporating medical devices - Part 2-1:

Step by step risk management of

medical IT-networks - Practical

applications and examples "


This technical report is a step-by-step

guide to help in the application of RISK

MANAGEMENT when creating or changing a

MEDICAL IT-NETWORK. It provides easy to

apply steps, examples, and information

helping in the identification and control of

RISKS.


Security Guidance




Guidance for the disclosure and

communication of medical device

security needs, risks and controls"


Security capabilities 5.1 Automat ic logoff – ALOF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2 Audit controls – AUDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.3 Authorizat ion – AUTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.4 Configuration of security features – CNFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.5 Cyber security product upgrades – CSUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.6 HEA LTH DA TA de-ident ification – DIDT.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.7 Data backup and disaster recovery – DTBK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.8 Emergency access – EMRG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.9 HEA LTH DA TA integrity and authentic ity – IGAU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.10 Malware detection/protect ion – MLDP.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.11 Node authenticat ion – NAUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.12 `Person authentication – PAUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.13 Physical locks on device – PLOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.14 Third-party components in product li fecycle roadmaps – RDMP . . . . . . . . . . . . . . . . . . . . . . . 20

5.15 System and applicat ion hardening – SAHD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.16 Security guides – SGUD.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.17 HEA LTH DA TA storage confident iali ty – STCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.18 Transmiss ion confidentiali ty – TXCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.19 Transmiss ion integrity – TXIG .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22


Automatic logoff - ALOF Applicable: Standard: N/A

Policies: Local HDO IT Policies

Reference material: N/A

Requirement goal: Reduce the RISK of unauthorized access to HEALTH DATA from an unattended workspot.

Prevent misuse by other users if a system or workspot is left idle for a period of time.

User need: Unauthorized users are not able to access HEALTH DATA at an unattended workspot.

Authorized user sessions need to automatically terminate or lock after a pre-set period

of time. This reduces the RISK of unauthorized access to HEALTH DATA when an

authorized user left the workspot without logging off or locking the display or room.

Automatic log off needs to include a clearing of HEALTH DATA from all displays as

appropriate.

The local authorized IT administrator needs to be able to disable the function and set

the expiration time (including screen saver)

A screen saver with short inactivity time or manually enabled by a shortcut key might

be an additional feature. This HEALTH DATA display clearing could be invoked when no

key is pressed for some short period (e.g. 15 s to several minutes). This would not log

out the user but would reduce RISK of casual viewing of information.

It is desirable that clinical users should not lose uncommitted work due to automatic

logoff. Consider detailing characteristics under ALOF that distinguish between (a)

logoff and (b) screen locking with resumption of session.


Example Exchange A screen-saver starts automatically 5 minutes after

last keystroke / mouse movement operation.

Remark: the local authorized IT administrator can

set the delay for this action and even disable the

screen-saver.

acknowledged by HDO

desirable would be a longer time period

since diagnostics has pauses with inactivity

The screen-saver clears all displayed HEALTH DATA

from the screen.

acknowledged by HDO

The screen-saver does not log-off the user / does

not terminate the session.

acknowledged by HDO

User has to log-in after occurrence of the screen-

saver.

acknowledged by HDO

The user-session terminates automatically

60 minutes after last keystroke / mouse movement /

touchscreen operation.

Remark: the local authorized IT administrator can

set the delay for this action and even disable the

automatic log-off.

acknowledged by HDO

additional: a master account would be

desirable to override a user account and

log in a screen-saved box


Wireless Guidance




Guidance for wireless networks"


Policies and Scaling

• IEC/TR 80001-2-4: Application of risk

management for IT-networks incorporating

medical devices – Part 2-4:

General implementation guidance for

Healthcare Delivery Organizations


• This technical report helps a RESPONSIBLE ORGANIZATION

through the key decisions and steps required to establish a

RISK MANAGEMENT framework, before the organization

embarks on a detailed RISK ASSESSMENT of an individual

instance of a MEDICAL IT-NETWORK. The steps are supported

by a series of decision points to steer the RESPONSIBLE

ORGANIZATION through the PROCESS of understanding the

MEDICAL IT-NETWORK context and identifying any

organizational changes required to execute the

responsibilities of TOP MANAGEMENT as defined Figure 1 of

IEC 80001-1:2010.


More guidance started

• IEC 80001-2-x Guidance on distributed

alarm systems

• IEC 80001-2-x Guidance on

Responsibility Agreements

• IEC 80001-2-x Guidance on Self-

assessment to IEC 80001-1


A New Risk Model

• Transformative view of managing risk

– Each component of a network may have

properties that can cause a hazard

– These properties can be managed by the

developer of the component

– Putting the components together creates

something new, with emergent properties that

can cause a hazard and can only be

managed by a collaborative approach


Relationships

• Requirements for collaboration

– Between all participants

• Hospital management

• Purchasing

• Network integrators

• IT vendors

• Medical device manufacturers

• Clinical engineering

• Hospital IT

• Others

What’s the Context?


SAFETY: “Secondary” alarm communication failure then entire wireless network crashes – for days – after smart pump drug libraries are pushed out … simultaneously!

EFFECTIVENESS: PBX and an entire public phone exchange used to monitor home health patients is taken down when Microsoft Office is installed on the server to read documentation …

SECURITY: “Why did that system reboot right in the middle of surgery?!” Conflicker infects systems … including medical devices … throughout the hospital when security patch application is suspended after a system actively used in surgery is updated and … resets!

Everyone … EVERYONE! … has a Story


The Safety Context

• The FDA view

• The Joint Commission View

• The Institute of Medicine View

• What Congress just said


FDA’s Perspective on the Problem

Q: “Is there really a problem with medical devices being integrated into general I.T. networks?”

A: “Oh, yes!!!”

JWG7 to Brian Fitzgerald (FDA) 2007.01:

FDA Testimony to ONC 2010.02.25: Nevertheless, certain HIT vendors have voluntarily registered and listed their software devices with the FDA, and some have provided submissions for premarket review. Additionally, patients, clinicians, and user facilities have voluntarily reported HIT-related adverse events. In the past two years, we have received 260 reports of HIT-related malfunctions with the potential for patient harm – including 44 reported injuries and 6 reported deaths. Because these reports are purely voluntary, they may represent only the tip of the iceberg in terms of the HIT-related problems that exist.

(Dr. Jeffrey Shuren, Director FDA/CDRH to ONC HIT Policy Committee Adoption/Certification Workgroup, 2010.02.25)


Infusion pump - Under certain wireless network conditions, a communication error can occur, which freezes the PC Unit screen. This error may result in a delay of therapy and inability to make programming changes to current infusions.

Infusion systems upgraded with the Motorola compact flash hardware and supporting software when used in a network environment that utilizes Temporal Key Integrity Protocol (TKIP) authentication can potentially induce a memory leak that can cause the Management Processor to become non-responsive. This causes normal operation to stop.

There is a potential safety issue in regard to data transfer between LANTIS OIS system and the hospital Information System (HIS) when the HL7 (ADT) interface is used.

Data cached on the Neuron due to server unavailability is not being delivered to the server after server availability is restored. If a compact flash failure occurs, the file system may be corrupted and result in system hangs, lock-ups or crashes.

The LOGIX OE automated backup does not retain the three most recent backup files and instead will only retain the last three backups of the previous year. The software stores backup files in numeric order rather than chronological date order.

Under certain circumstances, edits to an order can result in unintended scheduled interventions on the IntelliVue Clinical Information Portfolio. A patient may receive interventions or additional medication doses that are not intended.

A software problem that has the potential for data loss during the transfer of treatment records to the OIS, which may not be recorded in MOSAIQ, and subsequently may lead to mistreatment

Networked Medical Tech Recalls

Source: FDA Medical and Radiation Emitting Device Recalls database


FDA’s MDDS

Medical Device Data System – a device that

is intended to provide:

Electronic transfer of medical device data;

Electronic storage of medical device data;

Electronic conversion of medical device data;

Electronic display of medical device data


FDA’s Vision of MDDS

Most MDDS will be off-the-shelf IT

components with some software “glue”

Hospitals that assemble components and

add software “glue” become the

manufacturer of the MDDS

FDA believes that general controls,

especially the QS regulation will provide

adequate assurance of safety


What about The accreditors?

See also The Joint Commission Environment of Care

News February 2011, “The Networked Health Care

Environment: Keeping Patients Safe – Sometimes?”


Key findings: Health IT may lead to safer care and/or introduce new

safety risks

Safety is a characteristic of a sociotechnical system that includes people, process, environment, organization and technology

System-level failures occur almost always because of unforeseen combinations of component failures

Recommendations: Health care accrediting organizations should adopt

criteria relating to EHR safety.

All health IT vendors should be required to publicly register and list their products

Health IT vendors should be required to adopt quality and risk management processes

Reporting of health IT– related adverse events should be mandatory for vendors and voluntary and confidential for users.

The IOM View


Recent Legislation

• The FDA, ONC and FCC shall report

within 18 months

• “a proposed strategy and

recommendations on an appropriate, risk-

based regulatory framework pertaining to

health information technology, including

mobile medical applications, that promotes

innovation, protects patient safety, and

avoids regulatory duplication.”


The Reimbursement Context

• Meaningful use of EMRs is required for

incentive payments under ARRA

• Office of the National Coordinator for

Health IT sets objectives for meaningful

use that must be met for incentives

• Meaningful use objectives will include

storing data from medical devices in the

future


The Interoperability Context

• Integrating the Healthcare Enterprise (IHE)

has been developing interoperability

protocols and doing connectathons for

over 7 years


• The medical device plug and play

interoperability program (MDPnP) affiliated

with Massachusetts General Hospital and

the Center for Integration of Medicine and

Innovative Technology has been working

since 2004. In 2010 they were awarded a

$10 million grant from NIH to develop a

prototype healthcare intranet for improved

health outcomes.


• In 2012, FDA facilitated the organization of

a Medical Device Interoperability

Coordination Council (MDICC)

– Intent is to bring together people and groups

working on interoperability to identify what

exists and gaps that need to be filled

– FDA has put a very large amount of staff time

into this initiative


• FDA and Life Science Alley have agreed to

form a public/private partnership organized

as a non-profit institution to be called Medical

Device Innovation Consortium

– Focused on pre-competitive regulatory science

– One of the areas it intends to work in is

interoperability

– It is expected to take over the facilitation of the

MDICC work.

What does 80001 Require?

Management Ownership


(IEC 80001-1:2010, Figure B.1)

IEC 80001-1, section 3.2:

"The overall responsibility for RISK

MANAGEMENT for a MEDICAL IT-

NETWORK shall stay within the

RESPONSIBLE ORGANIZATION”

HDO has Overall Responsibility


Roles & Responsibilities

TOP MANAGEMENT

Biomedical

Engineering

area of

expertise

IT area of

expertise

Clinical Area

of expertise

Other...

Residual Risk

Risk

Management

File

MEDICAL IT-

NETWORK RISK

MANAGEMENT

FILE

Sub-

contractorMedical

device

manufacturer

or provider of

other IT

technology

B

ProceduresProcesses

Policies

Medical

device

manufacturer

or provider of

other IT

technology

A

MEDICAL

IT-NETWORK

RISK

MANAGER

Supervises creation of

App

rove

s

Pro

vides

input to

Pro

vid

es in

pu

t to P

rovid

es in

put to

Appoin

tsGuid

e a

ctivities o

f

Pro

vide

s

expe

rts

to

Pro

vides

exp

erts

to

Provides

experts to

Providesexperts to

The RESPONSIBLE ORGANIZATION

(IEC 80001-1:2010, Figure B.1)

Responsible Organization

Overall responsibility for Risk

Management stays with the HDO!

Owner of the Risk Management

Process, incl.:

• Planning

• Design

• Installation

• Device Connection

• Configuration

• …

• Decommissioning


TOP MANAGEMENT

Biomedical

Engineering

area of

expertise

IT area of

expertise

Clinical Area

of expertise

Other...

Residual Risk

Risk

Management

File

MEDICAL IT-

NETWORK RISK

MANAGEMENT

FILE

Sub-

contractorMedical

device

manufacturer

or provider of

other IT

technology

B

ProceduresProcesses

Policies

Medical

device

manufacturer

or provider of

other IT

technology

A

MEDICAL

IT-NETWORK

RISK

MANAGER


App

rove

s

Pro

vides

input to

Pro

vid

es in

pu

t to P

rovid

es in

put to

Appoin

tsGuid

e a

ctivities o

f

Pro

vide

s

expe

rts

to

Pro

vides

exp

erts

to

Provides

experts to

Providesexperts to


(IEC 80001-1:2010, Figure B.1)

Medical-IT Network Risk

Manager …

Overall RM Process

Reporting to Top Management

Managing Communications –

Internal & External

Design, Maintenance &

Performance of RM Process

Note: This is an Individual,

not a Team!



TOP MANAGEMENT

Biomedical

Engineering

area of

expertise

IT area of

expertise

Clinical Area

of expertise

Other...

Residual Risk

Risk

Management

File

MEDICAL IT-

NETWORK RISK

MANAGEMENT

FILE

Sub-

contractorMedical

device

manufacturer

or provider of

other IT

technology

B

ProceduresProcesses

Policies

Medical

device

manufacturer

or provider of

other IT

technology

A

MEDICAL

IT-NETWORK

RISK

MANAGER


App

rove

s

Pro

vides

input to

Pro

vid

es in

pu

t to P

rovid

es in

put to

Appoin

tsGuid

e a

ctivities o

f

Pro

vide

s

expe

rts

to

Pro

vides

exp

erts

to

Provides

experts to

Providesexperts to


(IEC 80001-1:2010, Figure B.1)

Stakeholder

partnerships:

Healthcare Provider /

Responsible Organization

Medical Device Manufacturers

I.T. Technology Vendors

3rd Party Integrators

Risk Management Experts

…

… shared vision & mission!


Risk Management Life Cycle


Full Life Cycle

CONFIGURATION

MANAGEMENT

Applicable

CHANGE PERMIT?

MonitoringEVENT

MANAGEMENT

“Project”

- Project plan

- Execute RISK MANAGEMENT

- Update RISK MANAGEMENT FILE

Live environment RISK MANAGEMENT

CHANGE-RELEASE MANAGEMENT

RESIDUAL RISK

evaluation &

report

Yes

Unacceptable

Go live

No

Request for Change to

or creation of a

MEDICAL IT-NETWORK

Acceptable

MDMs focus on safety …

at the time of sale.

80001 addresses safety,

effectiveness & security

during deployment and

use!

80001 fills a current gap &

benefits all stakeholders,

including tech suppliers esp.

after the sale. (IEC 80001-1:2010, Figure 2)


Risk Management Definitions

Harm

• physical injury or damage to the health of people, or damage to property or the environment, or reduction in effectiveness, or breach of data and systems security

Hazard

• potential source of harm

Hazardous situation

• circumstance in which people, property, or the environment are exposed to one or more hazard(s)


80001 Basic Risk Management Process

Identify Hazards Loss of data

Incorrect data

Incorrect timing of data

Degraded function of devices

Unauthorized access to private data

Etc…

Identify Causes Overloaded link

Network configuration error

Wireless dropout

Network hardware failure

IP Addressing conflict

Security too aggressive

Faulty cabling

User/procedural error

Etc…

Identify Risk Control Measures Network design, best practices

Pre-go-live testing

Redundancy

IT procedures, Clinical procedures

Etc…

Go

Live!


HAZARD Foreseeable sequence of events HAZARDOUS SITUATION

Loss of data

Misconfiguration of network component

(cause)

Lost connectivity

Alarm data not received

Clinician is not notified of a PATIENT alarm

Loss of data

Poor network design (cause)

Overloaded link

Intermittent connectivity

Real-time waveform dropout

Clinician unable to properly diagnose

PATIENT

Intermittent

connectivity

Unplanned non-real-time traffic attempting to

use link (Cause)

Overloaded Metro Area Network (MAN) link

Intermittent packet loss

Waveform display is choppy and

incomplete. Delay in provision of care

because remote clinician is unable to

evaluate PATIENT ECG waveform

Intermittent

connectivity

Unplanned non-real-time traffic attempting to

use link (Cause)

Overloaded MAN link

Intermittent packet loss

Alarm data not received. Delay in provision

of care because clinician is unaware of

PATIENT in need of treatment.

Complete loss of

connectivity

MAN outage out of RO control (provider

failure)

Remote clinician must determine treatment

without access to real-time PATIENT data

Delivery of inappropriate care or treatment.


Life Cycle Risk Management Activities

Steps Input Output (Hazard Causal Chain Elements)

Harms

(Risks)

Hazards Hazardous

Situations

Failure

Modes

Causes/

Faults

System Hazard

Analysis

•Indented use

•Use conditions

•Historical Data

•Guidance/Standards

Focus

====================

System Fault

Tree

Analysis

System Requirements

and Design Focus

====================

Sub-System

FMEAs

Sub-System

Requirements and

Design

Focus

=========

Component/

Unit /

Process

FMEAs

Component/

Unit /Process

Requirements and

Implementation

Focus

=========

Event/Incident

Handling

Monitoring

Industry Information Focus

=====================================

Copyright GessNet 2012 – Used by permission


Hazard Causal Chain based Risk Analysis

Fault/Cause Failure Mode

Event (s)

Condition(s)

Hazardous

Situation

Harm

Event (s)

Condition(s)

Event (s)

Condition(s)



Hazard Causal Chain based Risk Controls


Event (s)

Condition(s)

Hazardous

Situation

Harm

Event (s)

Condition(s)

Event (s)

Condition(s)

Safety

Features

Safety

Requirements Controls



Great standard, but…

(The Washington Post “Express”, 2011.06.21, page 6)

Published 2010

November

Example


Wireless patient monitoring

• Use – transfer real-time data during

transport mode. The acuity of patients can

vary widely. During transport data is sent

to nurse stations for patient surveillance

and to the hospital EMR for archiving.


Network Description

• 802.11 hospital-wide network using 2.4

and 5 GHz. Eight network identifiers

including a guest access. In certain areas

of coverage there can be a large number

of wireless users. One SSID is dedicated

to patient monitoring. The main kitchen

uses high power commercial microwave

ovens. The hospital uses DECT

telephones in the 2.4 GHz band.


Identify hazards

• HAZ01: Complete loss of connectivity

• HAZ02: Intermittent connectivity


Identify causes

• C01: RF interference from a microwave

oven causes immediate loss of

connectivity between a device and an

access point

• C02: RF interference from DECT phones

causes intermittent loss of connectivity

• C03: Too many client devices cause

access point overload, causing intermittent

data loss.


Identify the hazardous situations

• HS01: Clinician is unaware of patient in

need of treatment. Delay in treatment due

to loss of data (alarms not received by

clinician)

– This could result from any of the causes.


Example Severity Scale Scale

SAFETY

RISK of HARM

EFFECTIVENESS Security of Data

Catastrophic Severe injury,

death

Planned operation

is no longer

possible

Can result in complete compromise of

sensitive information.

High Permanent

impairment of

body function or

permanent

damage of a

body structure

Planned operation

is disrupted or

delayed

Can result in compromise of large

amount of sensitive information.

Medium Temporary and

minor injury,

medical

intervention

required

Inconveniencing

to disrupted effect

on operation

Exposure of sensitive information can

cause embarrassment. Will require some

expenditure of resources to repair.

Low Temporary

discomfort,

reversible

without medical

intervention

Very limited or

inconveniencing

effect on

operation

Exposure of sensitive information will

have some minor effect on the

organization or individuals. It will require

minimal effort to repair.

Negligible Minor and short

term discomfort

No or very limited

impact on

operation

Will have negligible impact if threat is

realized and exploits vulnerability.


Example Probability Scale

Frequent

UNINTENDED CONSEQUENCES occur frequently or occur

every time

Probable

Very likely to result in any UNINTENDED CONSEQUENCE

Occasional

Somewhat likely to result in any UNINTENDED CONSEQUENCE

Remote

Not likely to result in any UNINTENDED CONSEQUENCE

Improbable

Very unlikely that use will result in any UNINTENDED

CONSEQUENCE


Unintended consequences

• Because acuity of the patients can vary,

loss of real-time data for high acuity

patients could lead to severe injury.

Severity of the harm is catastrophic.

• Probability of any of the causes is judged

to be remote.


Example Risk Level Matrix UNINTENDED

CONSEQUENCE for

security,

EFFECTIVENESS and

DATA AND SYSTEMS

SECURITY

Increasing probability

Improbable Remote Occasional Probable Frequent

Inc

rea

sin

g

Se

ve

rity

Catastrophic

High

High

Medium

Moderate

Low

Low

Negligible

High RISK to goals is unacceptable, RISK must be reduced before MEDICAL IT-

NETWORK can be used, either by reducing probability or by reducing

severity.

Moderate RISK acceptability needs further consideration. RISK has some effect to

goals but can be accepted when balanced with benefit. RO must pre-define

policies in RISK MANAGEMENT plan for RISKS in this level. Policies can include

special team reviews (IT, clinical) or review boards, rationales, TOP

MANAGEMENT signoff, showing RISK has been reduced as low as practicable,

etc.

Low RISK is acceptable. RISK has little effect on goals, no additional control

measures required. NOTE This Technical Report uses the above matrix for all three KEY PROPERTIES.


Risk of unintended consequence

• Based on a pre-determined risk

acceptability criteria, a catastrophic

consequence with a remote probability

equals a high risk level.

• Because the risk level is high, the risk

needs to be controlled or mitigated


Hazard Causal Chain based Risk Controls


Event (s)

Condition(s)

Hazardous

Situation

Harm

Event (s)

Condition(s)

Event (s)

Condition(s)

Safety

Features

Safety

Requirements Controls



Identify risk control measures

• Control the cause

– Replace the old microwave oven effectively

reducing the RF emissions because newer

units are better shielded.

• Add safety requirements

– Design the capacity of the network to

overprovision the number of WAPs in an area

such that fewer clients are serviced by a

single WAP


Identify risk control measures

• Add a safety feature

– A clinician attends the PATIENT during

transport. The clinical protocol can be

designed such that clinician attendance

during transport is only required for PATIENTS

above a pre-determined acuity level.


Implement the controls

• Replace microwave

• Add access points

• Create or update a clinical transport policy


Verify the controls are effective

• Check RF emissions in the vicinity of the

microwave

• Confirm WAP density and availability is as

per design. Verify that at peak usage there

is no WAP overload.

• Verify clinical transport protocol is in place

and staff is trained.


Review risk

• Check if any new hazardous scenarios

could have been added by the risk control

measures

• Review any remaining risk for acceptability

• You’re done and ready to go live with the

updated wireless transport monitoring

• Once you are live, monitor and feed any

new information back into the risk

management process


Questions?

Discussion

Sherman Eagles

[email protected]

[email protected]

612-865-0107

mailto:[email protected]

mailto:[email protected]

IEC 80001: An Introduction

Documents

Transcript of IEC 80001: An Introduction