Post on 24-Jun-2020
© 2010 ECRI Institute
Integration Roundup-
Standards and Safety
Erin Sparnon, MEng
Engineering Manager
esparnon@ecri.org
(610) 825 – 6000, ext 5539
© 2010 ECRI Institute
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
© 2010 ECRI Institute
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.
© 2010 ECRI Institute
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
© 2010 ECRI Institute
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
© 2010 ECRI Institute
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..
© 2010 ECRI Institute
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
© 2010 ECRI Institute
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?
© 2010 ECRI Institute
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
© 2010 ECRI Institute
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
© 2010 ECRI Institute
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
© 2010 ECRI Institute
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
© 2010 ECRI Institute
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)
© 2010 ECRI Institute
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
© 2010 ECRI Institute
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
© 2010 ECRI Institute
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!
esparnon@ecri.org
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
Copyright © 2015 Symantec Corporation
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)
Copyright © 2015 Symantec Corporation
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
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
Copyright © 2015 Symantec Corporation
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
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.
Copyright © 2015 Symantec Corporation
http://www.bbc.com/news/technology-34390165
37
Solutions Approach – Key Elements
Copyright © 2015 Symantec Corporation
• 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
Copyright © 2015 Symantec Corporation
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
axel_wirth@symantec.com(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!
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
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
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
43Copyright © 2015 Symantec Corporation
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
44Copyright © 2015 Symantec Corporation
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
47Copyright © 2015 Symantec Corporation