Data Security for "Connected" Health Care: Making Interoperable Medical Devices Safer Data Security for "Connected" Health Care: Making Interoperable Medical Devices Safer

Data Security for "Connected" Health Care: Making Interoperable Medical Devices Safer

In today's fast-paced and sophisticated health care arena, information reigns. Access to the right data at the right time—and often in real time—optimizes outcomes, reduces errors and adverse events, and helps manage cost. As "more data faster" moves from gold standard to standard-of-care, interoperable medical devices assume a central position in the treatment milieu. The manufacturer of an interoperable medical device can keep patients safer and reduce risk to the organization by designing data security into the device.

A device is interoperable if it can rapidly exchange data with systems and other devices and use the exchanged data quickly and efficiently. Put simply, interoperable medical devices “talk to each other in a safe and effective way”[1] and make good use of those conversations to help patients. Interoperability is lauded as a "key" driver of innovation in health care delivery,[2] and a cybersecurity task force convened by the Department of Health and Human Services (HHS) recently emphasized that blue-ribbon patient care depends on deeper connectivity.[3]

For all its benefits, speedy data exchange is not without risk. Interoperability expands the device's attack surface and makes it more vulnerable to data security threats. If the threats and vulnerabilities associated with interoperability are not appropriately managed, connectivity can actually harm patients rather than help them. For example, a cyberattack could disturb device function, reprogram the device, result in denial of service, or even "eavesdrop" on information.[4] The potential for harm increases exponentially if the device exchanges sensitive or life-critical data.

A robust security management process for the device that includes a risk analysis and risk management plan will help the medical device manufacturer (MDM) consider appropriate design elements to achieve patient safety goals. The data security management process should focus on identifying data security threats and vulnerabilities, and using the quality system process to design and implement mitigation strategies that reduce risk to data to a reasonable and appropriate level for the device.

The MDM is not without resources in its quest to optimize data security for an interoperable medical device. Risk management is an important aspect of the federal quality system regulations to which each MDM is subject. Additionally, the U.S. Food and Drug Administration (FDA) recently released final guidance on design considerations and premarket submission recommendations related to the safe and effective exchange and use of information. Together, these will help the MDM achieve a device design that promotes speedy and efficient data processing without unnecessarily compromising data security.

        I.            The Data Security Management Process for Interoperable Medical Devices
 
Interoperability impacts patient safety and privacy, as well as the security of the entire integrated network. Designing a medical device capable of safe and effective data exchange requires rigorous, ongoing security management that accounts for data security threats, vulnerabilities, and resulting risk.
 
A.     Understanding the Data Security Triad: Confidentiality, Integrity, and Availability

Data security practices are generally focused on safeguarding confidentiality, integrity, and availability, often shortened to “CIA.” The federal government’s National Institute of Standards and Technology (NIST) defines the terms as follows:
 
  • Confidentiality is the property that sensitive information is not disclosed to unauthorized individuals, entities, or processes. This includes preserving authorized restrictions on information access and disclosure, including restrictions internal to the device or system (e.g., users, processes, other devices) that processes the data.[5]
  • Integrity is the property that sensitive data have not been modified or deleted in an unauthorized and undetected manner, and includes ensuring information non-repudiation and authenticity.[6]
  • Availability is the property that data are accessible and useable upon demand by an authorized entity and includes timely and reliable access to and use of information.[7]
It is easy to see why confidentiality, integrity, and availability are vital attributes of the data that interoperable medical devices exchange and use. For example, compromised confidentiality could result in reputational harm or medical or financial identity theft for the patient who is the data subject. Likewise, compromised integrity or availability might lead to physical injury or even death if the device fails or transmits corrupted vital information. Each of these events, in turn, could mean reputational, financial, legal, or regulatory harm for the MDM.

B.      The Role of Data Security Management

Manufacturers of interoperable medical devices should have a security management process in place to prevent, detect, contain, and correct security violations that could impact data CIA. This includes both a data security risk analysis and a risk management plan.

Risk analysis (also called risk assessment) is a device-specific process that begins with identifying threats and vulnerabilities that could compromise data CIA. The process continues with the MDM assessing the likelihood that identified threats will in fact manifest and exploit known vulnerabilities, the magnitude of resulting impacts, the overall risk posed by the threats, and the mitigation strategies needed to reduce risk to a reasonable and appropriate level for the device. [8]

The risk analysis process incorporates several key concepts; the first, of course, being "risk" itself. In the context of data security, risk is the level of adverse impact that would result from a threat to data CIA exploiting a vulnerability in the device, or in the system in which it functions.[9] Threats are circumstances or events with the potential to adversely impact CIA.[10] Threats can be adversarial, accidental, structural, or even environmental.[11] Vulnerabilities are weaknesses a threat can exploit to negatively affect CIA.[12] Vulnerabilities can be information-related, technical, operational, or environmental.[13]

There is typically no scientifically-rigorous process for identifying threats and vulnerabilities. The MDM can gather information from a variety of sources, such as its own experience and that of its peers, trade publications, the popular press, and cybersecurity information-sharing groups to which the MDM belongs.

Once it has identified threats and vulnerabilities, the MDM can establish a scale and assign a value (which may be qualitative or semi-quantitative), to (1) the likelihood the threat will manifest by exploiting a known vulnerability, and (2) the likelihood of adverse impact if it does.[14] For example:

Likelihood Threat Will Manifest/ Likelihood Manifested Threat Will Result in Adverse Impact Meaning
Very High/10 Almost certain to manifest/Almost certain to result in adverse impact
High/8 Highly likely
Moderate/5 Somewhat likely
Low/2 Unlikely
Very Low/0 Highly unlikely
 
Graphing these two values against each other allows the MDM to establish the overall likelihood that an identified threat will result in a data security risk:
 
Table 1. Overall Likelihood Identified Threat Will Result in Data Security Risk. 
Likelihood Threat Will Manifest Likelihood Manifested Threat Will Result in Adverse Impact
Very Low Low Moderate High Very High
Very High Low Moderate High Very High Very High
High Low Moderate Moderate High Very High
Moderate Low Low Moderate Moderate High
Low Very Low Low Low Moderate Moderate
Very Low Very Low Very Low Low Low Low
 
Source: NIST SP 800-30 Rev.1, Guide for Conducting Risk Assessments (2012)
 
Plotting overall likelihood (established above) against the impact level that would result from a manifested threat to data CIA results in an overall risk value associated with the identified threat. Manifested threats can impact operations, assets individuals, or even other organizations.[15] As with overall likelihood, there is often no precise science to assessing impact level, and NIST again suggests assigning qualitative or semi-quantitative values, such as:

Impact Level Meaning
Very High/10 Multiple severe/catastrophic impacts
High/8 Severe/catastrophic impact
Moderate/5 Serious impact
Low/2 Limited impact
Very Low/0 Negligible impact
 
Overall risk from the identified threat is a function of overall likelihood (that the threat will result in a data security risk) and the resulting impact level if the threat manifests:

Table 2. Overall Risk Posed by Identified Threat.
Overall Likelihood Resulting Impact Level
Very Low Low Moderate High Very High
Very High Very Low Low Moderate High Very High
High Very Low Low Moderate High Very High
Moderate Very Low Low Moderate Moderate High
Low Very Low Low Low Low Moderate
Very Low Very Low Very Low Very Low Low Low

Source: NIST SP 800-30 Rev.1, Guide for Conducting Risk Assessments (2012)

After assessing overall risk, the MDM is prepared to communicate the risk assessment results to decision makers and formulate a risk management plan (RMP). The RMP must not only identify immediate and long-term strategies to mitigate risk (i.e., reduce it to a reasonable and appropriate level for the device), but plan for other important risk-related functions: sharing risk information with appropriate individuals; monitoring the assessed risk and any residual risk (the risk remaining from a threat to CIA after mitigation strategies are implemented) going forward;[16] and updating the risk assessment over time.[17] Risk management is an ongoing process that requires constant vigilance for threats, vulnerabilities, and resulting data security risk.

An interoperable medical device will be safer - i.e., will more safely and effectively transmit and use data - if the manufacturer engages in robust data security risk management. The preamble to the federal quality system regulations makes clear that risk management is "essential" to the quality system process:

  • “Risk analysis must be conducted for the majority of devices subject to design controls and is considered to be an essential requirement for medical devices under this regulation …."
  • “When conducting a risk analysis, manufacturers are expected to identify possible hazards associated with the [device] design in both normal and fault conditions.”
  • “If any risk is judged unacceptable, it should be reduced to acceptable levels by the appropriate means, for example, by redesign or warnings. An important part of risk analysis is ensuring that changes made to eliminate or minimize hazards do not introduce new hazards.”[18]
Further, risk analysis underpins most aspects of FDA's recent guidance on enhancing device interoperability.

      II.            FDA Guidance: Enhancing Interoperability
 
On September 5, 2017, the U.S. Food and Drug Administration (FDA) released final guidance entitled Design Considerations and Pre-Market Submission Recommendations for Interoperable Medical Devices (“Guidance” (FDA-2015-D-4852)). The Guidance is intended to help the medical device industry develop and design interoperable medical devices that more safely and effectively exchange and use data. The Guidance also provides recommendations for the content of device premarket submissions[19] and labeling. The Guidance is part of FDA's ongoing efforts to work with providers, hospitals, standards-development organizations, and manufacturers to promote device interoperability.[20]

Risk analysis and risk management are recurring themes throughout the Guidance, beginning with the broad statement that MDMs should “perform a risk analysis and conduct appropriate testing that considers the risks associated with interoperability, the anticipated users, reasonably foreseeable misuse, and reasonably foreseeable combinations of events that can result in a hazardous situation.”[21]

A.      Understanding the Electronic Interface
 
Many data security risks associated with interoperability relate to design or operation of the electronic interface: the medium by which the device exchanges information. The electronic interface includes both the type of connection, such as a USB port, and the information content. Manufacturers can make interoperable devices safer by “clearly [setting] forth in device labeling the functional and performance requirements of their electronic interface,” along with any limitations.[22]
 
B.      Design Considerations for Enhancing Interoperability

MDMs can take concrete steps to reduce risk associated with interoperability, including considering specific device design elements tailored to the interface technology, intended use, and use environment:
 
1.      Purpose of Electronic Interface. When designing an interoperable medical device and developing instructions for use, an MDM should "clearly" establish the purpose of the electronic interface, the level of interoperability needed to achieve it, and the information necessary to describe it in the labeling. The Guidance lists myriad elements the MDM should consider when designing the device interface, including the types of devices to which it will connect, the method of data transmission, the clinical context in which exchanged data will be used, and the functional and performance requirements of the device resulting from the exchanged information.
 
2.      Anticipated Users. Identifying anticipated users and how they will use the device within the interoperable system will help the MDM identify threats and vulnerabilities to which it can apply a risk management strategy. Possible mitigations include developing appropriate instructions for use (which may vary among anticipated users) and identifying and communicating limitations of use, contraindications, warnings, and precautions. While FDA recognizes that an MDM “cannot be responsible for all possible uses outside of the purpose of the interface,” the MDM's security management process should account for risks associated with reasonably foreseeable misuse.
 
3.      Risk Management Considerations. Interoperability, for all of its benefits, imparts a measure of risk to the device, the network, and other interfaced devices. Throughout the device lifecycle, the MDM should establish, document, and maintain a robust risk analysis and risk management plan with a “particular focus” on the threats and vulnerabilities associated with the electronic interface. This includes assessing:

  • Whether interoperability introduces vulnerabilities to basic device safety, security controls, or essential device performance;
  • Whether the design includes appropriate safety features to manage data security risk;
  • Whether corrupted data, or data outside "appropriate parameters," threatens device safety or essential performance; and
  • Whether risk management has accounted for threats associated with identified error scenarios, such device failure or malfunction caused by connection of unintended devices, invalid commands, receiving and processing erroneous data or commands, or bandwidth issues.
Risk management strategies should ensure the device retains basic safety and essential performance during normal and fault conditions. While FDA recognizes interoperability is a "shared risk among stakeholders"—including patients—MDMs should “define and document their process for objectively assessing the foreseeable use and reasonably foreseeable misuse of their medical device throughout the device lifecycle.” Put simply, the MDM should engage a solid and device-specific security management process.

4.      Verification and Validation. The degree of validation and verification required will vary according to the risk level associated with the device, the purpose of the electronic interface, and the intended and reasonably foreseeable uses. Testing should be adequate to show the "interactions on the electronic interface perform as intended." For example, the MDM's risk assessment should verify and validate that the device can detect and adequately manage corrupted data. The Guidance suggests additional verification and validation activities to enhance device safety.
 
5.      Labeling Considerations. Device labeling should include functional and performance requirements for the electronic interface. Risk management should include determining the appropriate manner in which to convey this information to intended users, e.g., via package inserts, instructions for use, and/or website information.
 
6.      Use of Consensus Standards. FDA recognizes "numerous" development and design standards for interoperable medical devices, which can be found at the FDA Recognized Consensus Standards Database. While adoption is voluntary, FDA "encourages their use." Alternatively, MDMs can adopt their own interface design preferences. Either way, FDA encourages transparency: "problems or misuse … can be minimized by making the functional, performance, and interface requirements openly available to all users."

C.      Recommendations for Premarket Submissions
 
The premarket submission (for an interoperable device that requires one) can cover a single device or an entire system in which the device is integrated. FDA makes several specific recommendations for the content of premarket submissions:

1.      Device Description. The sponsor should discuss each externally-facing interface, its purpose, intended and anticipated uses, and limitations of use. The sponsor should also describe the information exchanged, how it will be exchanged, and the impact on the device or other devices. Depending on claims the sponsor makes about data exchange and use, the description may include such elements as standards used; requirements for timeliness and integrity of information; communication format, rate, and transmission methods; and functional and performance requirements. FDA suggests other descriptive elements, as well.

2.      Risk Analysis. The manufacturer may make changes to device design, interoperability scenarios, or device limitations and/or warnings based on the risk analysis. Additional risks may arise when a system contains two or more connected devices. The manufacturer should identify risk mitigations that other parties—such as installers—should implement. If the MDM is subject to the quality system design validation risk analysis, the MDM should assess the interfaces, intended connections, and their effect on device performance. In any case, the risk analysis should address:

  • Mitigations required to manage unacceptable risks to a reasonable and acceptable level;
  • Issues with receiving and transmitting data, such as "fault tolerant behavior, boundary conditions, and fail safe behavior such as how the device handles delays, corrupted data, data provided in the wrong formal, [and] unsynchronized or time mismatched data …,"
  • Vulnerabilities and resulting risk from the interface; and
  • Risk resulting from intended use and reasonably foreseeable misuse.[23]
3.      Verification and Validation. The nature and extent of testing and the nature and degree of documentation will vary depending on the risks associated with the device, the purpose of the interface, and the anticipated use of the device and the device within the system. The submission should include:

  • Verification that the interface meets design specifications;
  • Validation that the interface performs as intended;
  • Determination and verification of information provided to enable the user to connect to the interface and confirm correct connection; and
  • Verification that the device will perform safely within specifications under intended conditions and reasonably-likely abnormal conditions.
4.      Labeling. The labeling should contain information necessary to enable users to connect safely to the device and to use the connection in the ways for which it was designed. The MDM should implement warnings, precautions, and limitations of use, and discourage misuse. FDA provides specific recommendations for device labeling to be used as appropriate for the purpose of the interface. These include (but are not limited to) identifying the purpose of the interface and intended connections, anticipated users, interface specifications and necessary performance and functional requirements, and data attributes being exchanged.

    III.            Conclusion.
 
Interoperability offers patients and providers the benefits of rapid data exchange, but brings with it unique vulnerabilities and threats to data confidentiality, integrity, and availability. A rigorous and device-specific security management process that includes risk analysis and risk management can make data exchange safer and more effective. FDA's recent guidance builds on the quality system requirements with the goal of helping manufacturers consider design elements that appropriately balance interoperability and data security.
 
For more information on data security in health care, contact Kim Metzger or another member of our Data Security and Privacy Practice.

This publication is intended for general information purposes only and does not and is not intended to constitute legal advice. The reader should consult with legal counsel to determine how laws or decisions discussed herein apply to the reader’s specific circumstances.


[1] Bakul Patel, Interoperability: FDA's Final Guidance on Smart, Safe Medical Device Interactions. FDA Voice, September 5, 2017. Available at https://blogs.fda.gov/fdavoice/index.php/tag/guidance-design-considerations-and-premarket-submission-recommendations-for-interoperable-medical-devices/
[2] Bakul Patel, Building A Case for Medical Device Interoperability: FDA's Call to Action (FDA Voice, February 9, 2016). Available at https://blogs.fda.gov/fdavoice/index.php/tag/design-considerations-and-pre-market-submission-recommendations-for-interoperable-medical-devices/
[3] Health Care Industry Cybersecurity Task Force: Report On Improving Cybersecurity In the Health Care Industry (June 2017), p. 1.
[4] Krishan K. Venkatasubramanian et al. "Security and Interoperable Medical Device Systems: Part I." Security and Privacy, IEEE 10(5), 61-63 (September 2012). Available at http://dx.doi.org/10.1109/MSP.2012.128
[5] NIST Interagency or Internal Report (IR) 7298 Rev.2, Glossary of Key Information Security Terms (“Glossary”), available at http://dx.doi.org/10.6028/NIST.IR.7298r2, p. 45.
[6] Id. p. 101
[7] Id. p. 17
[8] Glossary p. 162
[9] Id. p. 161
[10] Id. p. 198
[11] NIST Special Publication 800-30 Rev.1, Guide for Conducting Risk Assessment s (“RA Guide”), p. D-2.
[12] Glossary p. 212
[13] RA Guide p. F-3
[14] Id. p. G-2
[15] Id. p. H-2
[16] Glossary p. 160
[17] RA Guide p. L-2
[18] 61 Fed. Reg. 195, 52601-52662 (October 7, 1996)
[19] These include 510(k) Premarket Notifications (Traditional, Special, and Abbreviated); de novo requests; Premarket Approval Applications (PMA); Product Development Protocols (PDP); Humanitarian Device Exemption (HDE) submissions; and Biologics License Applications (BLA).
[20] Patel, Building A Case for Medical Device Interoperability (supra). Other key steps at FDA include the 2012 Summit on Medical Device Interoperability (identifying challenges); 2013 agency guidance, Radio Frequency Wireless Technology In Medical Devices (recognizing standards for medical device manufacturers);and 2015 agency guidance, Medical Device Data Systems, Medical Image Storage Devices, and Image Communications Devices.
[21] Guidance p. 5
[22] Id.
[23] Guidance pages 14-15
 
View Full Site View Mobile Optimized