Integration Roundup- Standards and Safety · The impact –and goal –of IHE since 1997! •...

© 2010 ECRI Institute

Integration Roundup-

Standards and Safety

Erin Sparnon, MEng

Engineering Manager

[email protected]

(610) 825 – 6000, ext 5539


Today’s Agenda

Using Standards to achieve Integration (20 min)

Tales from the Field- stories of integration safety (10 min)

Medical Device Security (10 min)

Q and A


About your Speakers

Erin Sparnon, ECRI Institute

Axel Wirth, Symantec

What is IHE?Integrating the Healthcare Enterprise (IHE) is an International Standards Profiling Organization

Vision: To enable seamless and secure access to information whenever and wherever it is needed

Mission: To improve healthcare by providing specifications, tools and services for interoperability

www.ihe.net

IHE Enables Interoperability by:• Developing consensus-based, open source Technical Frameworks (specifications)

and Integration Profiles, and making them available in the public domain

• Coordinating the use of established standards, such as CDA or FHIR (HL7), DICOM (within IHE Radiology and Pathology Profiles), LOINC & CDISC (for Laboratory Orders and Reporting), or IEEE 11073.x (for mHealth, Medical and Personal Health Devices) to address clinical needs, in support of optimal, organized, and safe patient care

• Facilitating product conformance testing to elicit feedback and demonstrate adherence of products to IHE specifications

Systems developed in accordance with IHE communicate with one another better, are easier to implement, and enable care providers to use information more effectively

Where does IHE fit in the HIT Standards ecosystem?

• Standards Development Organizations – Standards, Content, Messages, Architectures (e.g., HL7 2.x messaging, 3.x transport, FHIR, C-CDA, DICOM)

• Framework/Profiling Organizations – Building Blocks/Architectures Into Assemblies that Solve Specific Interoperability Needs (e.g., IHE PIX, PDQ, XDS, DEC)

• Projects– All of the above combined into functional interoperability solutions constrained to meet the needs of a country or health system or other related need

The impact – and goal – of IHE since 1997!• Develop, demonstrate, and disseminate trusted, workflow-driven, standards-

based interoperability solutions freely available in IHE Technical Frameworks and Integration Profiles

– IHE uses a globally trusted open ballot process for review

– IHE specifications are vetted through the international ISO process

– www.IHE.net: Download all specification documents free

• Removed barriers to creating seamless and secure access to – and exchange of - health data

• Reduces costs by eliminating or reducing the need for proprietary interfaces between systems

Over 650 Contributing Vendors & Organizations

IHE International is a 501(c)(3)

independent non-profit

organization

IHE International Board is fairly large, with broad representation- One member from each Global Development Domain- One member from each National Deployment Committee - Two At-Large members from the above communities- Two Emeritus members from prior Board membership

> 21 Societies Serving as Sponsors

IHE International Elected Co-Chairs:David Mendelson, MD

Elliot Sloane, PhD

Finland

Israel

Poland

Switzerland

Saudi Arabia Colombia

Malaysia

India

Brazil South Africa

New Zealand

UNDER WAY

Belgium

IHE USA Participation in the IHE International Cycle – Putting the D in DeploymentProposal, Development, Validation, Certification, Deployment

Education

Implement/ Extension

Testing and Certification

Implement/ Ask IHE USA

Implement/ Roadmap

11

18 Years of Steady Evolution Worldwide! 1998 – 2015IHE Interoperability Domains

Pathologysince 2006

Radiation Oncologysince 2004

Radiologysince 1998

Cardiologysince 2004

Patient Care Coordinationsince 2004

Now including home care devices, telehealth, and PHRs

Eye Caresince 2006

QualityResearch & Public Health

since 2006

Laboratorysince 2004

(Healthcare)IT Infrastructure

since 2003

Endoscopysince 2010

Dentistrysince 2010

Mobile devicesUnder way for 2015!

Surgerysince 2012

Look carefully: MOST Domains capture device AND workflow data; data

transfer is accurate and near-immediate.

Patient Care Devicessince 2005

Automated, secure data

capture and exchange

Pharmacysince 2009

User driven & vendor neutral;

based on HL7, ICD, and similar

global stds.


Profiles of Interest- Consistent Time [CT]

Enables system clocks and time stamps of computers in a

network to be synchronized (median error less than 1 second).

Example:

Data from a patient’s ventilator, monitor, and infusion pump all reach the

EMR in a synchronized manner to allow a fuller picture of the patient’s

condition


Profiles of Interest- Device Enterprise

Communication [DEC]

Transmits information from medical devices at the point of care

to enterprise applications.

Examples of information sent to EMR:

A physiologic monitor sends a snippet of an ECG waveform

An infusion pump server reports that a pump has gone to KVO because

it has reached its volume too be infused


Profiles of Interest- Point of Care Infusion

Verification [PIV]

Communicates medication orders to an infusion pump or pump

server

Example

Nurse has come into the room and used the bedside barcode scanning

system to scan and associate the patient, pumping channel, and

medication bag. The enterprise system then sends the medication order

to the pump server using PIV, which routes it to the appropriate pump

channel..


Profiles of Interest- Alert Communication

Management [ACM]

Communicates alerts (alarms - physiological or technical, or

advisories), ensuring the right alert with the right priority gets to

the right individuals with the right content.

Examples of information sent to secondary alarm notification

systems or middleware:

Physiologic monitor communicates an arrhythmia alarm

Infusion pump server communicates an air-in-line alarm


How can I tell if a system supports IHE

profiles?

Ask to see an Integration Statement for the profile you’re

interested in

If an integration statement is unavailable, request conformance

in an RFP

Look for drop-in RFP language in the PCD User Guide

© 2010 ECRI Institute© 2009 ECRI Institute

Lessons from the Trenches

What has ECRI heard? And what can we do?


1. Access Point failure takes down Tele

A call went in to Welch Allyn that a care area’s guest-services

wireless network was down.

A switch in their Cisco network switch had failed… and central

monitoring wasn’t being passed through either

Remarkable that the problem was first discovered as an outage

in guest network

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/De

tail.CFM?MDRFOI__ID=3273711

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/Detail.CFM?MDRFOI__ID=3273711


What can you do?

Monitor AP function and create a notification and escalation

scheme for outages

Technical escalation within IT

Clinical escalation within CE and Nursing


2. Firewall turned on inappropriately

Staff were setting up for a procedure and received an error message

on their bronchoscopy navigation system, which had recently

received antivirus software

During installation of the anti-virus software, the IT staff turned on the Windows

firewall, disrupting communication

Once the firewall was turned off, the system once again operated normally

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/Detail.C

FM?MDRFOI__ID=2224751

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/Detail.CFM?MDRFOI__ID=2224751


What can you do?

Make sure decisions for firewall and security settings are

documented and available to staff responsible for software

updates (IT of Clinical Engineering)

Trial an update in a controlled environment like a test lab

After updating any device, validate device function before

releasing for clinical use


3. Do you want Windows 10?

Microsoft is offering Windows 10 upgrades free-

of-charge for devices using Windows 7, 8 and

8.1.

Computers using these OS may prompt users to

upgrade, and some users have admin rights

Installing new OS can cause the failure of medical

devices or software running on the computers

(awaiting publication in Health Devices Alerts)


What can you do?

Strictly control admin privileges

Do Not upgrade computer OS without written assurance from

suppliers that medical devices or software will still work

If an unapproved upgrade happens, follow Microsoft instructions

to restore the system http://windows.microsoft.com/en-us/windows-10/going-back-to-windows-7-or-

windows-81-from-windows-10

http://windows.microsoft.com/en-us/windows-10/going-back-to-windows-7-or-windows-81-from-windows-10


4. Third-Party Vulnerability Scanning

During an unannounced black box test, telemetry kept rebooting

and was down for 2 hours

Facility had forgotten to provide an exclusion list to the security firm

No tech support in the middle of the night

Security firm forgot to exclude medical systems in the next test

and the problem recurred

https://www.ecri.org/Components/Alerts/Pages/TrackingUser/Al

ertDisplay.aspx?AId=1624261


What can you do?

Institute an approval plan for vulnerability scans

Try out the scan in a test environment

Work with vendors

Initial implementation

Keeping device security settings current

Incident reporting and support

© 2010 ECRI Institute© 2009 ECRI Institute

Thank you!

[email protected]

www.ecri.org

mailto:[email protected]

http://www.ecri.org/

Medical Device Cybersafety – a Pragmatic Approach

December 16, 2015

Axel Wirth, CPHIMS, CISSP, HCISPPNational Healthcare ArchitectDistinguished Systems Engineer

“The time is ripe to stop admiring the problem”Suzanne Schwartz, MD, MBAEMCM / FDA CDRH

What do these two gentlemen have in common?

28

Both made medical decisions based out of concern that their implanted medical device could be hacked!

Copyright © 2015 Symantec Corporation

29

Medical Device CybersecurityIntroduction to the Problem Space

Risks:• Patient safety (lives)

• Operational / Downtime

• Data Breaches / Fines

• Revenue / Financial

• Patient trust & Staff morale

• National security

Vulnerability:• Tightly regulated “turn-key” systems

• Long useful life

• Poorly protected & patched

• No detection & alerting

• Ecosystem Complexity

• Vulnerability of device, hospital, & health system

Threats:• Targeted attacks

• Collateral damage

• Malware remediation

• Theft / Loss

• Compliance violation

• Lateral attack / weakest link exploitation

• Hacktivism, terrorism


30

Medical Device Security - Separating Hype from Reality

30

• Malware outbreaks• Operational impact:• care delivery• downtime

• Devices are attacked• Research & security

testing• Vulnerabilities are:• common• broad• easy to exploit

• Dick Cheney’s pacemaker

• Predictions of murder & assassination

• TV shows (CSI Cyber, Homeland)

•National security & critical infrastructure:• Cyber-Hacktivism• Cyber-Terrorism• Cyber-Warfare

•Risk of an actual patient safety incident:• Patient harm• Treatment decisions• Reputation

•Unintended consequences

What we know Headline Material Futures

Reality Hype Hypothetical

In this discussion we need to focus on Reality, but be prepared for the Hypothetical.

In Cybersecurity, any single event can change the Paradigm!(unlike traditional hazard analysis – linear and predictable)


31

Medical Device Security – not just a Healthcare Topic

• FDA applies Regulatory Controls based on Patient Safety Risk• Class I (low risk), Class II (medium risk), Class III (high risk or no precedent)• Not all devices require formal FDA approval - filing or listing with FDA is sufficient

for many device types

• Initially treated software just like any other component (1999)• Include in Engineering Hazard Analysis, test, document residual risks, etc.

• Recognized Software unique needs (2005/2009)• Security requires lifecycle management under Manufacturer Quality System• Security patches and upgrades do not require FDA approval or notification,

but need to be documented and undergo verification & validation testing• This is why hospitals can’t install security software w/o approval

• Evolving Security Understanding – Software as a System (2014)• Cybersecurity is a manufacturer responsibility • Part of premarket documentation and filing / approval• Demonstrate (and document) that you considered cybersecurity risks

• Expected Statement about Postmarket Responsibility (Jan. 2016)• Changing view: “intended use” to “intended use in a hostile (cyber) environment”• Cybersecurity in the context of “a total product life-cycle approach,

from design to obsolescence”32Copyright © 2015 Symantec Corporation

FDA Position – evolving, yet often misunderstood

FDA Guidance (Oct. 2014):• Identify & Protect• Limit access to trusted users• Ensure trusted content

• Detect, Recover, Respond• Detect, recognize, log, and act upon

security incidents• Actions to be taken• Protect critical functionality• Recover device configuration

• Cybersecurity documentation• Hazard analysis, mitigation, design

considerations• Traceability matrix (cybersecurity

controls to risks)• Update and patch management• Manufacturing integrity• Recommended security controls

http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf

33Copyright © 2015 Symantec Corporation

http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf

34

What can Possibly Go Wrong?

• Device hack (research only, so far)

• Device loss/theft (PHI breach)• Drug abuse• Patch deployment failure• Reports on device testing – with

disastrous results• ICS-CERT and FDA warnings• FDA, DHS, FBI regulatory action


35

Medical Devices – Now Targeted and Exploited!

• MedJack: Medical Device Hijack

• APT exploit of medical devices

• 3 hospitals, 3 different medical devices (reported May 2015):Blood Gas, X-Ray, PACS)

• Undetected, difficult to remediate

• “Near perfect target”:• Limited IT visibility• Unprotected / unpatched• Entry point to the network• Common, widespread

vulnerabilities

• This is not hypothetical anymore; devices are being exploited!

• Pivot point to enter network• Invisible to IT security

• Malware detected:• Zeus, Conficker

• Citadel (Ransomware!)Copyright © 2015 Symantec Corporation

http://deceive.trapx.com/AOAMEDJACK_210_Landing_Page.html

http://deceive.trapx.com/AOAMEDJACK_210_Landing_Page.html

36

… and as of September, reported at Derbycon

• Exposed 68,000 Medical Devices from a large, unnamed US health group.

• Discoverable via Shodan Search Engine.

• Thousands of misconfigurations and direct attack vectors, incl. Win XP.

• Allows for detailed mapping of network, including devices.

• MRI and Defibrillator “honeypots”.• 55,416 login attempts over 6 months.• 299 attempts to install malware.• 24 exploits of Conficker vulnerability

• Conclusion:• Medical Devices are a recognized target!• Most likely because they are vulnerable,

not because of what they are.• We have to assume that there are many

“owned” devices out there.


http://www.bbc.com/news/technology-34390165

http://www.bbc.com/news/technology-34390165

37

Solutions Approach – Key Elements


• Organizational:• Define responsibilities• Security training• Establish best practices

• Design into your device (based on risk and use):• Cybersecurity (update-less)• PHI Encryption• Authentication, esp. for

remote access• Platform hardening• Critical file and function

protection• Document:• Device security properties• Risks assessed

• Maintain:• Security posture• Documentation

• Stop stupid, cooperate!

• Organizational:• Security responsibility• Security training

• Procurement:• Specify security req’s in

RFP and contracts• Request MDS2

• Establish security obligations and contacts

• Asset Management:• Complete inventory• Including security &

privacy properties• Risk Management:• Include medical devices• Supply chain risks• HIPAA (PHI Risk Analysis), • Joint Commission (Med.

Equipment Safety)• ISO/IEC 80001 series

• Risk Mitigation• Defense in Depth• Device Security:• Manufacturer guidance• Patching• Security software

(as appropriate)

• Device Handling:• Configuration & Change

Management• New device onboarding• EOL (esp. PHI handling)• Loaners/leased devices• USB device usage

• Network Architecture:• Understand dependencies

(device to network gear)• Wireless best practices• Biomed VLAN• Security Gateway

Manufacturer Provider (procedural) Provider (technical)

Note: References for MDS2, IEC 80001, VLAN Architecture, etc. are provided in the Appendix

Embedded Systems Security – the right approach

38Copyright © 2015 Symantec Corporation – Company Confidential!

On-device security:• HIDS / HIPS• Ease Lifecycle Management

and Patch pressures• Provide EOL OS “lifeline”• App & Process Whitelisting• Process/Port control• System administration

Common Use Scenarios:FDA-regulated Medical Device:• Example: Imaging, Diagnostics• Manufacturer approval / implementationSupporting IT System:• Workstation, ServerSoftware-only Medical Device:• Example: PACS workstation• Protect platform (install on workstation)Non-Medical Device:• Example: pharmacy robots, building systems, nurse call, etc.• Install on Device as permitted by Contract/Warranty

Note: check with manufacturer on device FDA status


Cybersafety – It’s a shared Responsibility

39

Increasing and Sophisticated Cyber Threats

Growing Regulatory Pressure & Compliance Risks

Complex and Highly Integrated Ecosystem of Vulnerable Devices

Pro

cure

me

nt

& C

on

trac

t M

anag

em

en

t

Ris

k A

nal

ysis

&

Man

age

me

nt

Ass

et M

anag

em

en

t

Net

wo

rk S

ecu

rity

&

Arc

hit

ect

ure

Pro

cess

es

& W

ork

flo

ws

Device Manufacturers Healthcare Providers

Encr

ypti

on

& D

ata

Pri

vacy

Pla

tfo

rm a

nd

Cri

tica

l Sy

ste

m P

rote

ctio

n

Dev

ice

Ce

rtif

icat

es,

C

od

e S

ign

ing

Secu

rity

Cap

abili

tie

s (d

ete

ctio

n, l

ogg

ing)

Cyb

ers

ecu

rity

D

ocu

me

nta

tio

n &

Up

dat

es

Acc

ess

& A

uth

en

tica

tio

n

Shared Problem

Coordinated Solutions Approach

Thank you!

Copyright © 2014 Symantec Corporation. All rights reserved. Symantec and the Symantec Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners.

This document is provided for informational purposes only and is not intended as advertising. All warranties relating to the information in this document, either express or implied, are disclaimed to the maximum extent allowed by law. The information in this document is subject to change without notice.

Axel Wirth

[email protected](617) 999 4035

Good security advise:Don’t rely on the kindness of strangers;

think as if they are out to get you –because they are!

mailto:[email protected]

FDA References

• Information for Healthcare Organizations about FDA's "Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS) Software“ (updated July 2015) http://www.fda.gov/RegulatoryInformation/Guidances/ucm070634.htm

• Cybersecurity for Networked Medical Devices is a Shared Responsibility: FDA Safety Reminder (updated Oct. 2014) http://www.fda.gov/MedicalDevices/Safety/AlertsandNotices/ucm189111.htm

• Guidance for Industry - Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software (Jan. 2005) http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm077812.htm

• Off-The-Shelf Software Use in Medical Devices (Sept. 1999) http://www.fda.gov/downloads/MedicalDevices/.../ucm073779.pdf

http://cybersecurity.ieee.org/images/files/images/pdf/building-code-for-medica-device-software-security.pdf 41

http://www.fda.gov/RegulatoryInformation/Guidances/ucm070634.htm

http://www.fda.gov/MedicalDevices/Safety/AlertsandNotices/ucm189111.htm

http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm077812.htm

http://www.fda.gov/downloads/MedicalDevices/.../ucm073779.pdf

http://cybersecurity.ieee.org/images/files/images/pdf/building-code-for-medica-device-software-security.pdf

IEEE: Building Code for Medical Device Software Security• Nov. 2014 Workshop

• Released May 2015

• Addressing device manufacturers’ secureSW design needs.

• Key Elements:• Avoid vulnerabilities

• Cryptography

• SW integrity

• Impede attackers

• Enable detection

• Safe degradation

• Restoration

• Maintain operations

• Support privacy

http://cybersecurity.ieee.org/images/files/images/pdf/building-code-for-medica-device-software-security.pdf 42

http://cybersecurity.ieee.org/images/files/images/pdf/building-code-for-medica-device-software-security.pdf

IHE International - PCD MEMPatient Care Device Domain, Medical Equipment Management

MEM Whitepapers: • Cybersecurity (2011: Education &

Problem Baseline)

• Cybersecurity Best Practices (2015)

• Medical Device Patching (2015)co-authored by MDISS and IHE


Asset & Supply Chain Management

• Manufacturer Disclosure Statement for Medical Devices Security (MDS2)

• Medical Device Securityshould be part of theProcurement Process:- RFP Language - Request NEMA MDS2

• Developed in cooperation by HIMSS and NEMA

• New version Oct. 2013

• More detailed (2 -> 6 pages)

• Now harmonized withIEC 80001 technical controls

http://www.nema.org/Standards/Pages/Manufacturer-Disclosure-Statement-for-Medical-Device-Security.aspx


http://www.nema.org/Standards/Pages/Manufacturer-Disclosure-Statement-for-Medical-Device-Security.aspx

45

IEC 80001 SeriesApplication of Risk Management for IT-Networks Incorporating Medical Devices

IEC 80001-1:2010 - “Part 1: Roles, responsibilities and activities”

IEC 80001-2-1:2012 - “Part 2-1: Step by Step Risk Management of Medical IT-Networks; Practical Applications and Examples”

IEC 80001-2-2:2012 - “Part 2-2: Guidance for the communication of medical device security needs, risks and controls”

IEC 80001-2-3:2012 - “Part 2-3: Guidance for wireless networks”

IEC 80001-2-4:2012 - “Part 2-4: General implementation guidance for Healthcare Delivery Organizations”

IEC 80001-2-5:2014 - “Part 2-5: Application guidance -- Guidance for distributed alarm systems”

IEC 80001-2-6:2014 - “Part 2-6: Application guidance -- Guidance for responsibility agreements”

IEC 80001-2-7:2015 - “Part 2-7: Application guidance for healthcare delivery organizations (HDOs) on how to self-assess their conformance with IEC 80001-1”

IEC 80001-2-8 “Part 2-8: Application guidance -- Guidance on standards for establishing the security capabilities identified in IEC 80001-2-2”

IEC 80001-2-9 “Part 2-9: Application guidance -- Guidance for use of security assurance cases to demonstrate confidence in IEC/TR 80001-2-2 security capabilities”

From: “VA Medical Device Protection Program (MDPP)”, presented at the NIST Health Security Conference, May 11, 2011

Segregation (VLAN Network, Access Control)

46

http://www.symantec.com/threatreport

Symantec Internet Security Threat Report, Vol. 20


http://www.symantec.com/threatreport

Integration Roundup- Standards and Safety · The impact –and goal –of IHE since 1997! •...

Documents

Transcript of Integration Roundup- Standards and Safety · The impact –and goal –of IHE since 1997! •...