Privacy Considerations for the Medical Device Ecosystem

Medical devices, just like standard hospital-based IT equipment, may store and transmit electronic protected health information (ePHI). Although a complex issue, devices need to be part of any health care provider’s larger privacy and security strategy and risk analysis. Here we will cover some of the fundamental considerations applying to this type of analysis, and provide references to standards and best practices that can guide clinical/biomedical engineers as well as help regulators, manufacturers, and health care providers start engaging with one another on this topic.

We are all aware of increasing IT security concerns with regard to networked medical devices.¹ Several high-profile cases have been published in the press, and there are two main scenarios getting increased attention. In the first and most frequent scenario, common malware affects a device’s off-the-shelf software via a network connection or portable media (eg, USB thumb drive). In the second scenario, which to date has only been demonstrated as part of security research, a device may be penetrated by a hacker with the intent to take control of the device, allowing, for example, the opportunity to reprogram the device and do harm to a patient.²

However, privacy concerns based on data stored on or transmitted by medical devices have historically been less of a discussion. Privacy concerns did, however, receive considerable attention from the American College of Clinical Engineering (ACCE) and the Healthcare Information and Management Systems Society (HIMSS) when the Health Insurance Portability and Accountability Act (HIPAA) final security rules became effective in 2005.³ Recently reported cases include, for example, a health care provider having to report a data breach to the US Department of Health and Human Services (HHS) because of a stolen piece of imaging equipment that contained data on an unencrypted hard disk.

The US government is providing substantial financial incentives to health care providers to improve information integration and the meaningful use of health data. These incentives include important quality and efficiency goals, which are leading health care providers to increase the integration of medical devices with their information systems. Therefore, we need to be conscious about increased security and privacy risks embodied by such systems. Hospitals may focus all of their attention on interoperability and inadvertently overlook critical security and privacy risks.

We need to recognize that security and privacy are closely related and can never be truly separated—you cannot have privacy without proper security. However, this article will focus on privacy-related topics, ie, the confidentiality and integrity of the information stored on and transmitted by medical devices. Figure 1 visualizes the relationship of security and privacy with regard to confidentiality, integrity, and availability of medical devices.

Medical Device Considerations

When we are applying privacy or security technologies to our medical device ecosystem, we need to be aware of a number of limitations that have the potential to restrict our technology choices, dictate what can and cannot be done, and, in many cases, even explain why these problems have not been solved in the past. The following reasons for this are a combination of technology evolution, regulatory frameworks, and system engineering considerations:

• Although medical device safety has been a focus of providers, manufacturers, and government bodies for several decades, the problems stemming from an interconnected system of medical devices (recently covered by the FDA in its Medical Devices Data System [MDDS] regulation) is relatively new to us. We have to realize that interconnected and interoperable devices can create situations where an IT security incident can lead to privacy breaches and patient safety incidents.
• Similarly, the regulatory framework guiding the design, manufacturing, distribution, maintenance, and use of medical devices is still of a single device mind-set. Only recently have we started to engage in a discussion about a new “system of systems” paradigm that is emerging.
• Medical devices typically have a long life cycle, where the functional usefulness of the device ages much slower than the device’s security capabilities. For example, a 10-year-old EKG system will still produce a diagnostic EKG strip, but its operating system may be relatively ancient in information technology terms. Such devices may be highly vulnerable and no longer be supported by the manufacturer or third-party security software vendors.
• Hospitals usually operate a vast number of differing brands, devices, models, and versions of devices and medical information systems, which makes cataloging, assessing, and solving interdependent system risks a logistics challenge due to the sheer complexity and quantity of possible configurations.
• Specific to the device, there may be limitations in power, computing capacity, or memory, all of which impose strict design considerations when architecting for on-device elements of security and privacy.
• Many medical devices are operated with intermittent connectivity and may go without either power or a network connection for hours or days. This needs to be considered when implementing any privacy or security solution, which may require management by a host computer or communication system. At the same time, if properly implemented, a centralized security management system can monitor devices and, for example, send alerts if they have not “phoned home” in a set time period.
• Lastly, considering the clinical criticality of medical device use cases, there is the need to strike a balance between protecting the device through security or privacy measures without degrading functionality or clinician access to the device, for example by requiring additional and/or complicated steps for user authentication.

Although some of these above considerations are not unique to health care or medical devices, taken together they often present unique challenges because of regulatory restraints, liability considerations, and patient safety exposure.

Privacy Considerations

Each medical device, more or less, will contain ePHI, and we need to understand the risks associated with that specific device. For example, a certain device may be subject to unauthorized access during use, or when sent out for repair, after resale, or if stolen. Any exposure of PHI that could have been mitigated by reasonable procedures or technical solutions could qualify as a data breach and cause substantial federal and state prosecution and/or fines under the 2009 Health Information Technology for Economic and Clinical Health (HITECH) Act’s breach notification regulations.⁴

To understand the potential privacy implications, we need to look at different scenarios: information stored on the device (data at rest), information transmitted or received by the device (data in motion), and access controls. To date, we have a number of standards and commercial solutions that address the requirements on a technical level. However, broad adoption and application to the complex medical device ecosystem is lacking, in part, due to the complexity of the clinical use cases, but also due to the lack of profiles that would define how to implement privacy protections from a high-level governance perspective all the way to the specific implementation on the device.

For example, a complex MRI scanner running a Windows or Linux operating system will require very different considerations than an implantable, life-sustaining device with limited battery power and computing resources. Also, in those two devices, the motivation for implementing security and privacy measures may be very different. For the MRI, there may be concerns about the large number of patient data transactions performed by and stored on the device. For the implantable device, the concerns may center on preventing unauthorized access and protecting the patient’s life.

Privacy Technologies

Some niche implementations exist, either at the level of an individual device as it may be implemented by a manufacturer, or within the realm of a specific but limited part of the infrastructure, such as the wireless network.

Below we have listed a brief review of available privacy technologies:

• Encryption—Data at Rest: Critical data stored on a medical device is at risk of exposure either through unauthorized access or improper disposal of the device. A variance of this scenario is data transferred from a device to removable media, such as for the purpose of backup. Under the HITECH Act, certain technologies are defined as making data on a device “unreadable” through:
  • Encryption for data at rest per NIST SP 800-111, “Guide to Storage Encryption Technologies for End User Devices.”
  • Encryption for data in motion per SP 800-52, “Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations;” or SP 800-77, “Guide to IPsec VPNs; or 800-113, Guide to SSL VPNs.”
  • Data destruction per NIST SP 800-88, “Guidelines for Media Sanitization.”
       The more complex the infrastructure is and the more devices need to be managed, the greater the importance of the secure and reliable management of the encryption keys. In addition to key management, secure storage of the key is of critical importance, since a key exposed in accessible computer memory, or even worse, written onto the device, would circumvent the protection provided by encryption.
• Encryption—Data in Motion: The general case of encrypting data in motion includes any data transferred over a wired or wireless infrastructure, such as via e-mail, SMS text, FTP, Web access, or proprietary device-to-device connectivity. If a medical device includes ePHI in this data transfer, then encryption should become a serious consideration.

Today’s encryption technologies utilize highly complex algorithms providing sufficiently strong encryption, based on standards like the Data Encryption Standard, or DES, or the Advanced Encryption Standard (AES), and use an asymmetrical key—ie, a public key is produced by the recipient and provided to the sender to encrypt the message. Because a mathematical one-way algorithm is used, this public key cannot be used to decrypt the message. For that, the recipient can use its private key, which was not shared.

Many standards exist allowing for secure and encrypted data exchange, for example the use of Transport Layer Security (TLS) or Secure Sockets Layer (SSL) based protocols like Hypertext Transfer Protocol Secure (HTTPS) or File Transfer Protocol Secure (FTPS).

Especially in a wireless environment, encryption is also of paramount importance as the wireless signal may be intercepted within public areas. Encryption and key management are therefore part of the IEEE 802.11x wireless standards.

Although the 802.11 has undergone a number of evolutionary improvements, many providers find it too challenging to implement the level or reliability and privacy required for the health care environment. As part of the standard, encryption and key management is provided. Note that Wired Equivalent Privacy (WEP) encryption used in earlier versions of 802.11 is no longer deemed secure and has been cited as HIPAA security and privacy vulnerability.⁵

Government-strength encryption meeting the AES is provided through Wi-Fi Protected Access (WPA) or WPA2. In low-complexity environments the “home/consumer” mode using an AES preshared key may suffice. However, those keys will need to be managed (assigned and revoked) at all access points and devices, or departing employees and transient service personnel may retain access to the systems after their departure. Therefore, many providers may find that they require “enterprise” management solutions such as a RADIUS authentication server and a strong authentication method such as Extensible Authentication Protocol-Transport Layer Security, or EAP-TLS.

• Access Control and Authentication (digital certification)

There may be cases where encryption is not feasible or sufficient and additional controls need to put in place, such as implementing a system of digital signatures or digital certificates.

For example, digital signatures are used to verify the authenticity of received data from a device that may not be under my direct control. In other words, I cannot use the traditional means like controlling access to the device or controlling users entering my facility to assure integrity and validate authenticity of the data provided by the system. Digital signatures rely on communication between the peer devices to establish trust using a similar public key scheme as discussed under encryption above.

Digital certificates take this concept a step further by introducing a certificate authority (CA) that handles the authentication. CAs can be private or public (eg, using the X.509 standard), and can be used to certify information, devices, or users. Utilizing CAs opens the opportunity for a wide range of use cases, for example to verify authenticity of information delivered by a home-based monitoring device, or to verify that a software patch is from a trusted source, or to authenticate a programming device to access a pacemaker.

Traditionally, digital signatures and digital certificates have been less relevant in the health care space. But, with increasing digitization and ongoing technology trends (eg, adoption of mobile devices) as well as a changing care model (eg, home care), we will see these topics becoming increasingly relevant.

• Access Control and Authentication (user)

Similar considerations apply to controlling and verifying user access for both clinical as well as administrative users. In an ideal world, any user access to program a medical device, such as to change dosage, or configure—such as to calibrate—should require role-based authentication and should be logged. Implementing such a scheme will require addressing significant complexities and a careful trade-off between access control and patient safety.

Further technical discussion of these embedded systems topics can be found in reference six in the online version of this article.⁶

Security and Privacy Regulatory Environments

HIPAA Privacy and Security Rules require that PHI is protected to assure its confidentiality, integrity, and availability. HIPAA also requires a regular security risk analysis of any environment that contains ePHI—consequently, a comprehensive risk analysis should always include medical devices and how a compromised device may affect a security or privacy incident.

In 2009, as part of the HITECH Act, the US government introduced a complex framework to incentivize health care providers to adopt electronic health records. In understanding the sensitivities and risks around the rapidly growing amount of patient data, HITECH also introduced stricter penalties for security and privacy violations, as well as mandates to notify HHS about data breaches, in compliance with breach notification laws. This includes any data on a medical device; and we have seen breach notifications sent to HHS due to stolen imaging equipment.⁷

Further, health care providers need to consider state laws, which in many cases may add additional requirements and may even be stricter than HIPAA or HITECH.

Other countries have similar patient privacy laws and requirements, for example the EU Data Protection Directive.⁸

Standards and Best Practices

A number of standards and best practices exist as general technical guidelines, or, in other sectors like banking. Yet, health care faces significant gaps in order to implement these standards in the highly complex and sensitive medical device ecosystem. Other industries face similar issues and, like health care, are undertaking initiatives to protect their complex device infrastructure. For example, the energy and utility sectors have been subject to cyber attacks⁹ and are now undertaking efforts to provide a regulatory and best practices security framework. Some of the guidance provided for other industries can be applied in the health care environment since some of the fundamental technical and architectural limitations and requirements are similar.¹⁰

One of the largest obstacles for medical devices is that the FDA, rightfully, puts the burden of validating and verifying a medical device’s safety with the manufacturer. This may prevent the end user, ie, the health care provider, from implementing privacy or security measures on the device itself unless they can ensure that patient safety and performance is not compromised. This sometimes leads to a disconnect between the provider who is facing the privacy and security challenges and the manufacturer who could implement the technical solution on the device. This problem cannot be easily solved because the regulatory, technical, liability, and patient safety implications are significant and complex.

Several industry working groups are currently starting to address these issues and are gaining momentum quickly. There is a newly launched initiative within Integrating the Healthcare Enterprise (IHE) and its Patient Care Device (PCD) and IT Infrastructure (ITI) working groups to address the issues around IT management for medical devices.¹¹ These IHE initiatives are supported by many well-regarded organizations and agencies, including AAMI, ACCE, HIMSS, the Radiological Society of North America Inc, the Healthcare Information Technology Standards Panel,¹² and others. Also, ACCE, AAMI, HIMSS, the International Electrotechnical Commission, and the National Electrical Manufacturers Association have been working on related risk-mitigation and risk disclosure strategies for the past several years.¹³

The recently formed Medical Device Innovation, Safety and Security Consortium,¹⁴ a collaborative of provider representatives, regulators, and manufacturers, is taking a broad and comprehensive approach with the goal to “build and facilitate a public and private collaborative dedicated to mitigating the risk of medical device associated security and safety risks; ensure that security risks associated with medical devices are well understood and appreciated across the health care system; improve the safety and security of medical devices and associated networks.”

MDPnP¹⁵ addresses the overall issue of the use of medical devices to improve the safety of medical care, facilitating the adoption of open standards and technologies for medical device interoperability, based on clinical requirements. Specific requirements and architecture models for medical device interoperability are provided through the “Patient-Centric Integrated Clinical Environment” (ICE) Functional Model (ASTM F2761-2009).

With a specific focus on personal health care devices, the Continua Health Alliance¹⁶ is dedicated to establishing a system of interoperable personal connected health solutions with the knowledge that extending those solutions into the home fosters independence, empowers individuals, and provides the opportunity for truly personalized health and wellness management.

Still to Come

Protecting the privacy of PHI on medical devices and assuring the integrity of device functionality are challenging requirements. Although standards exist to address specific point problems, the larger and more complex problem of protecting the networked medical device ecosystem is yet to be addressed. Solving this will require the cooperation of all stakeholders, including providers, manufacturers, regulatory bodies, and industry standards groups.

---

Axel Wirth, MSc, CPHIMS, is a national health care solutions architect at Symantec Corp, Mountain View, Calif. With more than 25 years of international experience in the health care industry, he provides strategic vision and technical leadership to health care providers, industry partners, and technology professionals. Elliot Sloane, PhD, CCE, FHIMSS, has spent nearly 4 decades in a dual career spanning IT and medical technologies that improve health care. He founded the Center for Healthcare Information Research and Policy, a nonprofit devoted to patient-centric, safe, efficient, effective, and secure medical technologies. As its president, he assists the US Government, the World Health Organization, and state and private health care agencies develop and improve their EHR and medical device interoperability programs. He is a member of 24×7‘s editorial advisory board. For more information, contact .

References

1. Wirth A. Cybercrimes pose growing threat to medical devices. Biomedical Instrumentation & Technology. 2011;45(1):26-34. TN 905.
2. Fu K. Inside risks, reducing the risks of implantable medical devices: A prescription to improve security and privacy of pervasive health care. Communications of the ACM 52(6), June 2009.
3. US Department of Health and Human Services. HIPAA Administrative Simplification Statute and Rules: Security Rule. Available at: www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/index.html. Accessed January 12, 2012.
4. US Department of Health and Human Services. HITECH Breach Notification Interim Final Rule. Available at: www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/breachnotificationifr.html. Accessed January 12, 2012.
5. Department of Health and Human Services, Office of Inspector General. Nationwide Rollup Review of the Centers for Medicare & Medicaid Services Health Insurance Portability and Accountability Act of 1996 Oversight. May 2011. Available at: www.oig.hhs.gov/oas/reports/region4/40805069.pdf. Accessed January 12, 2012.
6. Anoop MS. Security needs in embedded systems. July 2008. Available at: http://eprint.iacr.org/2008/198.pdf. Accessed January 12, 2012.
7. Department of Health and Human Services. Breaches Affecting 500 or More Individuals. Available at: www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/breachtool.html. Accessed January 12, 2012.
8. European Commission, Directorate-General Justice. Data Protection Directive 95/46/EC
9. Mocana Corp. Night Dragon Pilfers Oil & Gas Smart Grid. Available at: https://mocana.com/blog/2011/03/09/night-dragon-pilfers-oil-gas-smart-grid. Accessed January 12, 2012.
10. Symantec Corp. SCADA Vulnerabilities. Available at: www.symantec.com/business/threatreport/topic.jsp?id=vulnerability_trends&aid=scada_vulnerabilities. Accessed January 12, 2012.
11. IHE Patient Care Device and IT Infrastructure Working Groups. IHE Joint Work Item Proposal: Device Management Infrastructure. Available here: ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr10-2012-2013/Technical_cmte/DetailedProposals/ITI-PCD_IHE_Profile_Proposal-Detailed_1_0.doc. Accessed January 12, 2012.
12. Healthcare Information Technology Standards Panel (HITSP). Technical Note TN 905—Device Connectivity. Available at: www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=5&PrefixNumeric=905. Accessed January 12, 2012.
13. HIMSS. Medical Device Security. Available at: www.himss.org/ASP/topics_medicalDevice.asp. Accessed January 12, 2012.
14. Medical Device Innovation, Safety and Security Consortium. Available at: www.mdiss.org. Accessed January 12, 2012.
15. MDPnP. Available at: www.mdpnp.org. Accessed January 12, 2012.
16. Continua Health Alliance. Available at: www.continuaalliance.org. Accessed January 12, 2012.