Testimony by John Murray for the November 19, 2004 NCVHS Subcommittee on Privacy and Confidentiality Hearing

Prepared statement for the Subcommittee on Privacy and Confidentiality of the National Committee on Vital and Health Statistics (NCVHS) http://www.ncvhs.hhs.gov/

Presented November 19^th, 2004 by:

John F. Murray Jr.

Software Compliance Expert

Office of Compliance

Center for Devices & Radiological Health

United States Food & Drug Administration

Good morning, Mr. Chairman and Members of the Subcommittee.

My name is John F. Murray Jr. I am the software and electronic record compliance expert in the Office of Compliance, Center for Devices and Radiological Health (CDRH), Food and Drug Administration (FDA).

I am here with my colleague, Mr. Alford R. Taylor, Jr.  He is the Director of the Division of Electrical and Software Engineering, Office of Science and Engineering Laboratories, Center for Devices and Radiological Health (CDRH), Food and Drug Administration (FDA).

The mission of CDRH is to promote and protect the health of the public by ensuring the safety and effectiveness of medical devices and the safety of radiological products.  We can talk about the radiological health part of our mission some other time, but today, we are pleased to be here to talk about cybersecurity as it relates to medical devices.

Medical Device Networks in Historical Context

It may be beneficial to start on a historical note to give context to the discussion.  In the not-too-distant past, most medical devices were exceedingly dumb.  A ventilator, for example, was networked only to a patient’s airway, and the network interface was a piece of plastic tubing.  In the fully automatic mode, the ventilator was programmed to deliver a breath at set intervals.  Alternatively, in the patient assist mode, a breath would be delivered when a negative pressure was detected in the airway, indicating that the patient was initiating a breath.  In either case, the ventilator didn’t know—or care about—the time of day, the patient’s name, or her medical condition.

The majority of medical devices are still like that.  They live only in the present, either delivering therapy or providing timely diagnostic information to a clinician.  In some instances, they may record past performance for archival purposes, but that historical data is limited to what the device measured and how it responded, and may only be associated with a given patient by the clinician who makes use of the data.

Increasingly, however, medical devices are being connected into networks.  While a variety of communications media and protocols are available to medical system developers, the standard network interface, ubiquitous in the personal computer world, affords an economical and capable choice that capitalizes on the existing infrastructure in the healthcare facility and beyond, and easily bridges different hardware platforms, operating systems, and medical device software applications.

At present, network connectivity has made the greatest inroads in two domains: in-vitro diagnostic devices in the medical laboratory setting, and image processing, storage, and display systems in the radiology department.  But devices at the patient bedside and in the operating room suite are increasingly being attached to the network.

Network Connectivity: Benefits and Risks

The connectivity made possible by modern networks is both a blessing and a curse.  On the positive side, the network connection affords a variety of possible benefits to users and patients, such as enhanced ability to:

• Remotely process and display patient information in a variety of  formats, often in real time, and/or to collect and store information for subsequent review.
• Aggregate information from multiple sources to aid in diagnosis and/or treatment.
• Deliver treatment information from an attending clinician directly to a therapeutic device, thus eliminating one or more manual programming steps and reducing the potential for data corruption and operator error.
• Remotely maintain the medical device; for example, by collecting performance data and/or usage information, troubleshooting equipment problems, and performing software updates.

Along with these benefits have come new risks which must be addressed by manufacturers.  When medical devices are connected in a closed network, or joined via dedicated point-to-point links, threats to the security of information, and corresponding risk control measures, are limited and well-defined.

The threat multiplies when medical devices are connected to a corporate intranet or the world-wide Internet.  In this situation, medical devices are potentially exposed to a large number of network users, and data flowing over the network may be intercepted and/or manipulated at various access points.  Because the technology is evolving rapidly, new threats emerge periodically and require a sustained effort to maintain the integrity of information.

Cyber-attacks may have many different goals, motivations, and consequences.  Some examples include:

• Mining of private information for financial gain or competitive advantage.
• Damage to the reputation of a computer software or hardware manufacturer by disrupting the operation of their products.
• Sabotaging the activities of an organization by a disgruntled employee, a dissatisfied customer, or a terrorist to inflict financial or personal injury.
• Delivery of unsolicited commercial messages.
• Disruption of business operations and/or network communications (e.g., by flooding the network with nuisance messages to impede the flow of useful traffic) simply to satisfy the ego of the attacker.

 We think a targeted attack on a specific medical device would be an exceedingly rare circumstance, albeit one that cannot be discounted.  In the vast majority of instances, the medical device will either be the innocent victim of a denial-of-service attack, or if inadequately protected, a portal of opportunity for a cyber-attacker seeking to disrupt other resources on the network.

Computer viruses and worms are the most visible forms of cyber-attack, but malware—malicious software—can also be incorporated into a commercial software product or network infrastructure component, or introduced as a stand-alone program by any person who has access to a computer on the network.

Most malware targets commercial off-the-shelf (COTS) software.  Because COTS software, in general, is not designed with high-risk applications in mind, it falls upon medical device manufacturers to be very cautious when applying COTS software to their products.  For example, in some devices, the network connection supports ancillary functions of the device, and safe use of the device may not be compromised if the network connection is disrupted.  However, even in such cases, the healthcare organization will want reasonable assurance that the device cannot become infected with malware that impairs network performance for other users.  It is worth noting that network outages, in addition to their economic impact, may indirectly contribute to patient injuries—for example, by impeding delivery of prescriptions.

The Challenge for FDA

The challenge for FDA is to ensure that network-connected medical devices are adequately safeguarded, working within the regulatory framework under which we are required to operate.  FDA’s principal concern is risk to health, but healthcare organizations and other stakeholders are also concerned with protecting the privacy of information as well as minimizing economic risk.  These risks must be balanced against the cost of cybersecurity and the benefits afforded by healthcare computer networks.

It is generally recognized that some risk must be accepted in order to reap the benefits, but the responsible parties have a responsibility to actively manage risk on an ongoing basis, responding to emergent threats by developing and applying reasonable technological and administrative control measures.

From FDA’s perspective, responsibility for cybersecurity is shared by three key stakeholders:

• Healthcare organizations who set up and maintain networks.
• Suppliers of network infrastructure (software and hardware)—computers, routers and switches, operating systems, database engines, etc.
• Manufacturers of networked medical devices.

FDA’s focus is on how to properly lead and motivate the technical and scientific experts to create solutions that are appropriate for the needs of all of the stakeholders.  It is important to appreciate that the software engineering community, not the FDA, will dictate the solutions to cybersecurity threats.  FDA has rarely suggested specific design elements, but there are well-accepted methods, practices and techniques currently used in the information technology community to mitigate cybersecurity threats.  Medical device manufacturers and other responsible parties must avail themselves of the software engineering body of knowledge and make reasonable judgments in applying this knowledge to their products, services, and systems.

Current FDA Efforts in Cybersecurity

Our current effort is to clarify how the existing FDA rules and regulations apply to breaches in cybersecurity, and in particular to the maintenance of commercial off-the-shelf software to address cybersecurity concerns.

We are developing a formal policy statement on cybersecurity patches that will be issued as guidance to the medical device industry.  This guidance has been drafted and is currently being vetted in accordance with our established good guidance practices, so it would be premature to share it with you at this point.  But the key points are as follows:

1. FDA regulations require medical device manufacturers to systematically examine sources of quality data and implement actions needed to correct or prevent quality problems.  Actions taken must be appropriate to the magnitude of the problem and commensurate with the risks encountered.  Thus, medical device manufacturers have a legal obligation to be vigilant and responsive to cybersecurity threats. The medical device manufacturer using commercial off-the-shelf software bears the responsibility for the continued safe and effective performance of the medical device.
2. FDA premarket review is rarely required prior to implementation of a software patch.  FDA has previously published detailed guidance on when FDA review of a design change is required, and most cybersecurity patches fall below the threshold for FDA review.
3. FDA regulations require that design changes be verified and/or validated, reviewed, and approved prior to implementation.  For most software patches, verification by means of analysis, inspection and testing should be adequate, and clinical validation of the patch should not be necessary.
4. The medical device manufacturer should maintain formal business relationships with their software vendors to ensure timely receipt of information concerning quality problems and recommended corrective actions.  A detailed and thorough engineering analysis of each recommended patch, and the underlying problem or threat, is required.  Test results and evaluations of proposed changes—i.e., decisions and their rationales—should be documented.  Configuration management records should be maintained for each installation or copy of the software.   People making and reviewing decisions should be competent, both in terms of their software engineering expertise and their familiarity with the product(s) being evaluated.  These regulatory requirements can be satisfied by establishing a documented software maintenance plan.
5. Under some circumstances, FDA would consider a software patch to be a medical device recall.  However, software patches to address breaches in cybersecurity are necessary to ensure the continued safe and effective operation of medical devices, and FDA recognizes that routine cybersecurity patches are a fact of life for commercial off-the-shelf software today.  Therefore, when such software is used in a medical device application, FDA will use its regulatory discretion and will exempt the manufacturer from the requirement to report each individual patch to FDA, provided that:
   • the maintenance is performed within the framework of an established software maintenance plan (as described above), and
   • the medical device manufacturer’s evaluation of the patch indicates that it raises no significant new safety and effectiveness concerns.

   When the software patch affects either a function or performance of the medical device having significant implications for safety or effectiveness, the correction should be reported to FDA, even if a software maintenance plan is in effect.

Our Vision for the Future

In addition to developing the guidance on cybersecurity patches just described, our staff of software engineers is meeting routinely with members of the healthcare IT community, medical device manufacturers and their trade associations, standards developing organizations, and other stakeholders.  We seek to develop a shared understanding of the problem, which we believe will ultimately lead to consensus solutions.

We see no need for burdensome new FDA regulations concerning cybersecurity.  The established principles of quality management and risk management, which are already part of our regulatory structure, provide an adequate roadmap for responding to cybersecurity threats.

We view the HIPAA Security Rule as simply one more element in the environment that medical device manufacturers operate in.  Fortunately, the measures that safeguard privacy are in many cases also important to assure the safety and effectiveness of medical devices.

We recognize that other parts of the Department of Health and Human Services have overlapping concerns regarding cybersecurity in medical devices, and we regret that resource limitations have impeded our outreach to other operating divisions in the HHS family.  For that reason, we appreciate the opportunity to participate in this hearing today.  We hope that you have found this presentation to be informative and pertinent to your needs, and we would be glad to answer any questions you might have.

This communication is consistent with 21 CFR 10.85(k) and constitutes an informal communication that represents my best judgment at this time but does not constitute an advisory opinion, does not necessarily represent the formal position of FDA, and does not bind or otherwise obligate or commit the agency to the view expressed.