Spring 2019 Papcun G Medical Device Quality Managing Cybersecurity Design Requirements Through The Application of Pdsa QFD

MEDICAL DEVICE QUALITY: MANAGING CYBERSECURITY DESIGN
REQUIREMENTS THROUGH THE APPLICATION OF
PDSA AND QFD
____________
A Thesis
Presented
to the Faculty of
California State University Dominguez Hills
____________
In Partial Fulfillment
of the Requirements for the Degree
Master of Science
in
Quality Assurance
____________
by
George Joseph Papcun
Spring 2019
Copyright by
GEORGE J. PAPCUN
2019
All Rights Reserved

This thesis is dedicated to the memory of my father, George J. Papcun, Sr., whose
constant support and encouragement of my academic pursuits in science and engineering
helped me to become the person I am today.
I would also like to thank my beautiful wife Joyce for her love, encouragement, and
support during my time in the MSQA program and especially during the development of
this thesis.
iii
TABLE OF CONTENTS
PAGE
COPYRIGHT PAGE...........................................................................................................ii
DEDICATION....................................................................................................................iii
TABLE OF CONTENTS....................................................................................................iv
LIST OF TABLES..............................................................................................................vi
LIST OF FIGURES..........................................................................................................viii
ABSTRACT.......................................................................................................................ix
CHAPTER
1. INTRODUCTION TO STUDY......................................................................................1
Background..............................................................................................................1
Statement of the Problem.......................................................................................14
Purpose of the Study..............................................................................................17
Theoretical Bases and Organization......................................................................19
Limitations of the Study.........................................................................................25
Definitions of Terms..............................................................................................26
2. REVIEW OF LITERATURE .......................................................................................30
Overview................................................................................................................30
Regulations and Guidance Documents..................................................................30
International Standards..........................................................................................37
Risk Management Techniques...............................................................................52
Human Factors Engineering..................................................................................54
Software Design and Development Methods........................................................56
Plan-Do-Study-Act (PDSA)...................................................................................57
Quality Function Deployment................................................................................60
Summary................................................................................................................65
3. METHODOLOGY........................................................................................................66
Introduction and Key Objectives...........................................................................66

PDSA Plan Phase...................................................................................................68
iv
CHAPTER PAGE
Subject Medical Device Overview........................................................................68

Quality Function Deployment Matrix Implementation.........................................70
Research Questionnaire Development.................................................................103
PDSA Do Phase...................................................................................................103
Questionnaire Administration and Follow-up Discussions.................................104
PDSA Study Phase...............................................................................................105
PDSA Act Phase..................................................................................................105
Summary..............................................................................................................106
4. RESULTS AND DISCUSSION.................................................................................108
Overview..............................................................................................................108
Initial (Baseline) Quality Function Deployment Matrix......................................109
Analysis of Research Questionnaire Data............................................................133
Incorporation of Questionnaire Data into Revised QFD Matrix.........................141
Review of QFD Methodology with Stakeholders................................................156
Summary..............................................................................................................158
5. SUMMARY, CONCLUSION, AND RECOMMENDATIONS................................159
Summary..............................................................................................................159
Conclusion...........................................................................................................161
Recommendations for Further Study...................................................................162
REFERENCES................................................................................................................163
APPENDIX: MEDICAL DEVICE CYBERSECURITY DESIGN

REQUIREMENTS QUESTIONNAIRE......................................................................174
v
LIST OF TABLES
PAGE
1. Examples of Wireless Infusion Pump Cybersecurity Threats.........................................5
2. Examples of Wireless Infusion Pump Cybersecurity Vulnerabilities..............................7
3. Examples of Malware....................................................................................................11
4. Quality Tools and Potential Challenges for Cybersecurity............................................20
5. Summary of Reviewed Regulations and Guidance Documents....................................36
6. Summary of Reviewed International Standards............................................................50
7. Five-level Ranking Scheme (VOC and Technical Requirements Comparison)............73
8. Customer Requirements Related to Software and Hardware Design............................74
9. Customer Requirements Related to Risk Management.................................................76
10. Customer Requirements Related to Human Factors....................................................82
11. Customer Requirements Related to Quality Management Systems............................85
12. Customer Requirements Related to Verification and Validation................................86
13. Voice of the Customer Requirements..........................................................................92
14. VOC Categories versus NIST Five Core Functions....................................................94
15. Technical Requirements...............................................................................................95
16. Pair-wise Comparison Scale for AHP..........................................................................97
17. Five-level Ranking Scheme (Technical Requirement Interrelationships)...................99
18. Prioritized VOC Requirements..................................................................................116
19. Technical Requirement Interrelationships.................................................................119
vi
PAGE
20. Technical Requirement Priorities..............................................................................132
21. Cybersecurity Questionnaire Demographics Overview.............................................134
22. Principal Outcomes from Cybersecurity Questionnaire............................................137
23. Revised Voice of the Customer Requirements by Category.....................................142
24. Revised VOC Requirements Prioritization................................................................144
25. Updated Technical Requirement Priorities................................................................155
vii
LIST OF FIGURES
PAGE
1. Configuration of a Standalone Infusion Pump.................................................................3
2. Configuration of a Wireless Infusion Pump....................................................................4
3. Relationship Between Security and Safety Risks..........................................................13
4. Application of PDSA to Information Systems Security................................................24
5. NIST Cybersecurity Framework Categories and Subcategories...................................34
6. Relationship Between Safety and Security Risk Management Processes.....................45
7. PDSA Cycle Process Flow............................................................................................60
8. Relationship Between Houses of Quality......................................................................62
9. Typical House of Quality...............................................................................................63
10. Voice of the Customer Affinity Diagram....................................................................88
11. Mathematics for VOC Prioritization Using AHP........................................................98
12. Use of Technical Requirement Interrelationship Table.............................................100
13. Methodology for Technical Priority Determination..................................................102
14. PDSA Cycle Utilized for Cybersecurity QFD Matrix Development.........................107
15. Initial VOC AHP Comparison Matrix.......................................................................110
16. Normalized AHP Comparison Matrix with VOC Priorities......................................113
17. Customer and Technical Requirements Comparison.................................................125
18. Updated Customer and Technical Requirements Comparison..................................148
viii
ABSTRACT
The ever-increasing interconnection and sophistication of medical devices
containing software presents a significant security risk management challenge for many
manufacturers. While a number of methods have been established for addressing these
risks relative to device integrity and availability, a comprehensive approach which
leverages existing quality assurance tools and techniques to improve the effectiveness of
design input management appears to be lacking.
This thesis explores an application of the Plan-Do-Study-Act cycle and the
Quality Function Deployment (QFD) methodology to the realization of a QFD matrix for
managing cybersecurity software and hardware design requirements across a device’s
lifecycle. As this study demonstrates, inclusion of voice of the customer data from key
medical device stakeholders allows for the development of a comprehensive QFD model,
which can be tailored for any medical device software development process. This
ultimately serves as an effective tool for improving security risk mitigation and overall
device quality.
1
CHAPTER 1
INTRODUCTION TO STUDY
Background
Medical devices are intended to improve the quality-of-life for numerous
individuals by providing an enhanced ability to diagnose, treat, and in some cases,
prevent disease and other adverse conditions. The U.S. Food and Drug Administration
(FDA) formally defines a medical device as:
 an instrument, apparatus, implement, machine, contrivance, implant, in vitro

reagent, or other similar or related article, including a component part, or
accessory which is:
o recognized in the official National Formulary, or the United States

Pharmacopoeia, or any supplement to them,
o intended for use in the diagnosis of disease or other conditions, or in

the cure, mitigation, treatment, or prevention of disease, in man or
other animals, or
o intended to affect the structure or any function of the body of man or

other animals, and which does not achieve its primary intended
purposes through chemical action within or on the body of man or
other animals and which is not dependent upon being metabolized for
the achievement of any of its primary intended purposes (2014, p. 1).
Based on this definition, medical devices can cover a wide range of applications.
Examples include: implantable devices intended to replace or augment existing body
components, electro-mechanical devices intended to administer drugs to patients, and
vascular injection systems intended to enhance diagnostic medical imaging scans through
the introduction of contrast media to specific regions of the body.

2
Whereas most medical devices containing software were once standalone units,
having little or no interaction with other devices or networks, today’s medical devices
continue to evolve in a way which allows for ever-increasing connectivity and flexibility.
The “internet of things” has enabled both remote and distributed access to many devices
(Williams & Woodward, 2015). As a result, various devices are now connected to
hospital health networks, the internet, and to other devices (Reich & McAleer, 2016).
While this offers greater benefits to both the care provider and patient, it also increases
the potential for patient data breaches, compromised device operation, misdiagnosis, and
a host of other undesirable outcomes. Cybersecurity encompasses the safeguarding of
computer networks and their associated information from penetration and from malicious
damage or disruption (Williams & Woodward, 2015). In one recent study, 94% of
healthcare institutions indicated that they had fallen victim to a cyber-attack. There are
currently four different cyber-threat modalities which have been identified: loss of device
data, monetary gains through theft, attacks on the medical device itself, and attacks on
connected device infrastructure. Specific threats to connected devices and their
associated infrastructure are the most concerning due to the potential for adverse
outcomes on patient health and safety (Perakslis, 2014).
One example of a commonly-used medical device which is subject to potential
cyber-attacks is a wireless infusion pump. These devices are commonly used to
administer medications to patients in precise dosages and flow rates over a given period
of time. Figure 1 illustrates a traditional standalone infusion pump while Figure 2

3
illustrates the configuration of a typical wireless pump to its supporting components and
to the internet (Guides et al., 2017).
Standalone
Infusion Pump
Patient
Figure 1. Configuration of a Standalone Infusion Pump. Developed by the author.

4
VPN Internet
(Virtual Private Network)
Router Wireless Access Point

Wireless Infusion
Pump
Firewall
(External)
Infusion Pump Server
Patient
Figure 2. Configuration of a Wireless Infusion Pump. Adapted by the author from

“Securing Wireless Infusion Pumps,” by H. T. Guides, G. O’Brien, S. Edwards, K.
Littlefield, N. McNab, S. Wang, and K. Zheng, 2017, NIST Special Publication, 1B, p.
37.
The standalone pump is connected only to the patient and relies on direct user
entry of parameters by a medical practitioner. No external connections are introduced
which would facilitate a potential cybersecurity threat. A wireless pump, on the other
hand, is typically connected through a wireless access point to a server which may
control the functions of several such devices. The server may also house a drug library
which is used to catalog various medications, dosages, and flow rate settings for one or
more connected pumps. In addition, the server may facilitate interoperability with other
devices connected to the hospital network. Finally external connections to the pump
manufacturer for software updates and maintenance activities may be provided through
an external firewall and a virtual private network (VPN) connection. While these
enhancements have undoubtedly improved the quality of care delivery for patients, they
5
have also introduced a number of potential cyber-threats and vulnerabilities which were
not present with the standalone pump technology. Table 1 provides several examples of
potential threats associated with the use of a typical connected device such as the wireless
infusion pump described above. Table 2 provides several examples of vulnerabilities and
consequences associated with the realization of cyber-threats (Guides et al., 2017). From
the tables it is clear that connected devices introduce a host of issues which may
compromise a device’s security, functionality, and availability, leading to increased
patient risk.
Table 1
Examples of Wireless Infusion Pump Cybersecurity Threats

Threat Type Description Intended Outcome
Targeted Attack An attempt by a threat actor to Adverse effect on pump operations,

directly compromise system pump server performance, or the drug
components (may be through the library.
manufacturer’s VPN connection,
internal to the care provider’s
organization or externally
through the public internet and
firewall)
Advanced Persistent An attempt by a threat actor to May allow an actor to perform

Threats (APTs) place malicious software on the unauthorized operations either on the
pump itself or on pump system pump itself or provide a means to
components access other devices connected to the
hospital network with the intent of
causing adverse patient outcomes.
6
Table Continued
Threat Type Description Intended Outcome
Disruption of Service-- These attacks may be Degraded availability or unavailability

Denial of Service components found in a broader of a pump or pump system
(DoS) and Distributed APT scenario. components leading to a user’s
Denial of Service inability to provide patient care.
(DDoS) Attacks
Malware Infections An attack in which a threat actor To cause a disruption in the

places malicious software on the availability of a pump (which may
pump as part of an APT affect patient safety by preventing
campaign or to cause an adverse providers from leveraging system
effect on the pump or related functionality or by preventing the
system components. pump from effectively using safety
Ransomware would be one such measures such as the drug library).
example.
Theft or Loss of Assets Applies when the pump or pump May lead to degraded availability of
system components are not equipment and a possible breach of
accounted for in an inventory. PHI.
Unintentional Misuse Occurs when the pump or its This may include errors introduced
components are unintentionally through the misapplication of software
misconfigured or used for updates, misconfiguration of network
unintended purposes settings, misapplication or errors
found in the drug library, or errors
associated with fluids applied to
pumps.
Vulnerable systems or This threat considers scenarios in In leveraging ports for unintended
other devices directly which individuals may expose purposes, threat actors may enable
connected to the device devices or server components malicious software to migrate to the
using external ports or interfaces pump or server components, or to
(e.g., USB or other hardwired create adverse conditions based on
non-network connections) for unexpected connections.
purposes outside the device’s
intended use.
Note. PHI = Personal Health Information. USB = Universal Serial Bus. VPN = Virtual Private Network.
Developed by the author from “Securing Wireless Infusion Pumps,” by H. T. Guides, G. O’Brien, S.
Edwards, K. Littlefield, N. McNab, S. Wang, and K. Zheng, 2017, NIST Special Publication, 1B, Appendix
A, p. 74-75.
7
Table 2
Examples of Wireless Infusion Pump Cybersecurity Vulnerabilities

Vulnerability Description Result / Consequence
Lack of asset inventory Deficient or out-of-date device May lead to the loss/theft of devices
inventories represent a or equipment. When paired with a
cybersecurity control deficiency. credible threat, this vulnerability
increases the risk associated with a
provider’s ability to render patient
care. This may also expose PHI to
unauthorized individuals.
Long Useful Life Since infusion pumps are Infrequent refresh may lead to
designed to perform clinical obsolescence of the device’s
functions for several years, they technological attributes or an inability
tend to have long-term refresh to provide software support via
rates. patching or periodic updating. This
may also mean that future cyber
controls cannot be implemented.
Lack of Data Pumps may not have a means to May expose sensitive information or
Encryption encrypt data stored on the allow malicious actors to determine
device. Locally stored data may how to connect to a pump or server to
include sensitive configuration perform unauthorized activities.
information, or patient
information, including possible
PHI. Sensitive data should be
safeguarded in transit as well as
at rest.
Use of Hard-coded or Reliance upon built-in passcodes Weak authentication mechanisms that
Factory Default versus managed access processes are well known or published degrade
Passcodes which include user the effectiveness of authentication
authentication. control measures.
Insecure Network Failure of patient care providers Reduces protective measures intended
Configurations to utilize a principle of “least to limit network traffic capabilities
privilege” when configuring and enforce limited trust between
networks that include pumps and zones identified in hospital
server components. environments.
Note. PHI = Personal Health Information. Developed by the author from “Securing Wireless Infusion
Pumps,” by H. T. Guides, G. O’Brien, S. Edwards, K. Littlefield, N. McNab, S. Wang, and K. Zheng,
2017, NIST Special Publication, 1B, Appendix B, p. 76-78.
8
In general, medical devices may be adversely affected by a cyber-attack in terms
of their functionality or efficacy. Each of these areas can have a negative impact on
patient diagnoses, the delivery of medications, the administration of therapy or other
aspects of healthcare. The most significant risk associated with a device which has been
compromised is the potential to harm, or even kill, a patient. As a result, device
manufacturers and healthcare providers need to pay close attention to the following:
 The security of the device itself. A cyber-attack or malware outbreak can

compromise a device’s operation or performance. Key considerations
associated with protecting devices from such risks include: the architecture of
the device, its communication pathways with other devices, and how the
device is integrated with the network to which it is connected.
 Patient privacy offered by the device. This risk is typically evaluated based
on several factors: the type of Personal Health Information (PHI) data stored,
the amount of data stored, and whether the data is retained.
 The security risk the device poses to the larger enterprise. Any system or
device connected to a provider’s network without sufficient protection or
having exposed vulnerabilities is at risk of being exploited. This device in
turn, can become a point of entry for a cyber-attack on the larger network. As
a result, any large network is only as secure as its weakest component.
In terms of risk prioritization, individual device security should be of principle
concern since any unintended event may have a direct impact on patient care and could
potentially lead to patient death. Risks imposed on the larger network would also
certainly need to be considered as devices are developed and deployed. Device
information privacy concerns depend on the type of data being utilized and would only be
a significant consideration if the data can lead to the intended or unintended disclosure of
PHI or information which would facilitate identity theft (Wirth, 2011).

9
Within the last decade, the United Kingdom has observed a significant upturn in
patient safety-related issues, with field safety alerts increasing from 62 in 2006 to 757 in
2010. This represents an increase of nearly 1,200%. While the potential safety
implications associated with recalls can be considerable, there are also economic and
legal impacts which are experienced by manufacturers, user facilities, and device users
which can be substantial or even catastrophic. The root cause of these recalls can often
be attributed to a hazardous situation which was not identified or adequately controlled
prior to market introduction of the device. The desire for products having additional
functionality, such as interoperability with other devices and systems, is also increasing
the complexity and sophistication of medical technology and healthcare infrastructure.
Such demands are also introducing additional hazardous scenarios, such as cybersecurity
vulnerabilities, which ultimately increases the difficulty for both the industry and
regulators. Even an apparently simple device can become more complex when its use
environment is taken into consideration. Thus, device designers and manufactures must
ensure now, more than ever, that proper identification and control of hazardous scenarios
is undertaken (Eagles & Wu, 2014).
Between 2006 and 2011, 5,294 recalls and approximately 1.2 million adverse
events involving medical devices were reported to the FDA. Almost 23% of the recalls
were due to computer-related failures, of which approximately 94% involved a medium
to high risk of severity to patients (Fu & Blum, 2013, p. 21-22). In May 2017, a form of
ransomware known as “WannaCry” infected as many as 200,000 Microsoft Windows-
based systems, including several medical facilities in the United States and the United
10
Kingdom. One device manufacturer confirmed receipt of reports indicating that two of
its medical devices in the United States had been impacted, the first known instance of a
medical device being infected by ransomware. Fortunately, in both cases, normal
operations were restored within 24 hours. While these types of attacks may not
necessarily threaten patient safety, they can increase resource needs, lead to delays in the
administration of care, and contribute to increased clinical mistakes (Fox-Brewster, May
2017).
There are many different forms of Malware currently in existence today.
Malware consists of a program that is inserted into a system, usually covertly, with the
intent of compromising the confidentiality, integrity, or availability of a victim’s data,
applications, or operating system or of otherwise annoying or disrupting the victim
(Kissel, 2013, p. 118). Table 3 provides examples of several types of malware (Wirth,
2011).
11
Table 3
Examples of Malware
Malware Type Description
Virus A piece of self-replicating code that appends itself to a program file or a

sector of a disk
Trojan A program in which malicious or harmful code is contained inside apparently

harmless programming or data in such a way that it can obtain control and do
its chosen form of damage.
Worm A program that duplicates itself from one directory, drive, computer, or
network to another through electronic communication or local area networks.
Backdoor A method of bypassing normal authentication, securing remote access to a

computer and data while attempting to remain undetected.
Rootkit Techniques to allow concealment by modifying the host operating system so

that the malware is hidden from the user or removal tools.
Spyware A type of malware that can be installed on computers with the purpose of
collecting information about users without their knowledge.
Botnet Network of software agents (bots or robots) that run autonomously and
automatically, most commonly for malicious purposes, but it can also refer to
a network of computers using legitimately distributed computing software.
Note. Obtained from “Cybercrimes pose growing threat to medical devices,” by A. Wirth, 2011,
Biomedical Instrumentation & Technology, 45(1), p. 32.
Overall, the increase in cyber-attacks has led to additional consideration by
regulatory bodies (Perakslis, 2014). Recognizing these risks for medical devices, the
FDA issued a safety communication in June of 2013 intended for device manufacturers,
hospitals, device user facilities, healthcare information technology personnel, and
biomedical engineers. The purpose of this communication was to recommend that
medical device manufacturers, as well as healthcare facilities, take appropriate risk
mitigation steps to reduce the potential for failures based on cyber-attacks. The
12
communication further stressed that many medical devices contain embedded software
that can be susceptible to cyber-threats and that manufacturers of such devices are
responsible for maintaining vigilance with regard to cybersecurity risks and hazards.
Specifically, the FDA’s expectation is that device manufacturers will take the necessary
steps to limit potential opportunities for unauthorized access to their devices. To this end,
manufacturers should examine their cybersecurity practices and policies to ensure that
applicable safeguards are in place which will prevent unauthorized access to devices and
will not jeopardize the security of hospital networks to which devices are connected
(FDA, 2015). Medical devices currently represent a significant component of medical
networks. As such, their security should also be an integral part of cybersecurity
protection (Williams & Woodward, 2015).
Mitigation activities related to medical device cyber-threats are complicated by a
number of factors, including ease of critical device information availability to would-be
attackers, incompatibility between embedded device software and operating systems,
manufacturer requirements for comprehensive verification and validation prior to
releasing software changes and updates, gaps in post-market reporting of cyber-threat
incidents, and limited access to device software by hospital technical personnel. While a
number of various strategies currently exist for addressing the issue (e.g., regulatory
standards, software design and development practices, and overall risk management
techniques), these activities are currently more centered on device safety rather than
security.
13
The Association for the Advancement of Medical Instrumentation (AAMI)
suggests that in order to effectively address the full scope of risk associated with
connected medical device safety and security, a broader definition is required which
encompasses not only the traditional scope of “physical injury or damage” but also
includes concepts such as “reduction of effectiveness” and “breach of data and systems
security.” Figure 3 illustrates the relationship between these different types of risk
(AAMI, 2016).
Security risk which

includes breach of
data and systems Security risk Safety related
security as well as with a safety risk
reduction of impact
effectiveness
Figure 3. Relationship Between Security and Safety Risks. Adapted by the author from
AAMI, 2016, p. x. Copyright 2016 by the Association for the Advancement of Medical
Instrumentation.
Current regulations associated with the development of medical devices are just
beginning to incorporate awareness to, and mitigation of, cybersecurity threats. In an
attempt to further assist device manufacturers in this area, the FDA released a draft
guidance document for addressing cybersecurity in pre-market submissions (FDA, 2013).

14
This document suggests that manufacturers should address cybersecurity during a
device’s design and development since this can yield a product with more efficient
patient risk mitigation. As part of the design inputs which are established in accordance
with the FDA medical device Quality System Regulation (21 CFR Part 820) (QSR),
cybersecurity requirements also need to be considered. In addition, an approach for
addressing both cybersecurity vulnerability and management needs to be incorporated
into the device’s software validation and risk analysis activities and should encompass
the following areas:
 Identification of assets, threats, and vulnerabilities
 Assessment of the impact of threats and vulnerabilities on device functionality

and end users/patients
 Assessment of the likelihood of a threat and of a vulnerability being exploited
 Determination of risk levels and suitable mitigation strategies
 Assessment of residual risk and risk acceptance criteria (FDA, 2013, p. 4).
Unfortunately, while the guidance document and QSR do provide high-level security
requirements to be considered, they do not offer any details regarding methodologies for
consistently gathering and implementing these requirements
Statement of the Problem
Consideration of risk mitigation relative to cybersecurity has been recognized by
manufacturers, hospitals, government agencies, and patients as a crucial element in the
design and development of today’s medical devices. From a cybersecurity standpoint,
medical device vulnerabilities are similar to any other networked system. What
15
differentiates these devices from their non-medical counterparts, however, is the potential
negative impact they can have on patient safety. Unfortunately, ensuring the protection
of these devices within their connected environment is complicated by a combination of
technical, managerial, and human-related causes. For example, certification agencies
routinely publish device verification information, device technical manuals include
information regarding radio frequency transmission data, and patent databases include
pertinent information on device functionality. All of this information can be utilized by a
would-be attacker to exploit a connected medical device. In addition, incompatibilities
between device software and legacy operating systems can open the door for potential
vulnerabilities to be leveraged. Unfortunately, most medical devices do not employ even
basic security features. Furthermore, the lack of timely software updates and patches is
often the result of the device manufacturer’s requirement to meet slow regulatory
approval processes. A general lack of cybersecurity awareness, coupled with poor
security practices can also complicate device development and certification. Finally,
technical tradeoffs are often made in terms of medical device power and performance
resources as a way to enable ever-smaller and faster devices. This results in a device’s
inability to perform at desired speeds and maintain expected battery life when given the
additional task of managing encryption aimed at reducing cyber-threats (Williams &
Woodward, 2015).
In general, the need for establishing software requirements is more widely
recognized than it is for security requirements. As a result, the processes and
methodologies used for generating software requirements are often at a higher level of
16
maturity within most organizations than those used for the determination of security
requirements. With the end customer in mind, any approach taken to address
cybersecurity risks must be flexible, cover the entire product lifecycle, be forward-
looking in terms of future threats, and provide confidence that the information contained
within the device or hospital network remains confidential, is trustworthy, and is
available when needed. Finally, the process needs to be reliable and repeatable such that
emerging cyber-threats can be properly identified and addressed (Phillips, 2003).
Software quality can be defined as conformance to customer software requirements.
Oftentimes, however, existing methods for requirements analysis, specification
generation, and object modeling do not take into account the impact of successive
development on customer requirements nor do they accurately detect conflicts between
customer requirements (Liu, 2000).
Current research into the area of improved medical device cybersecurity suggests
that a number of techniques are being utilized in the areas of regulatory oversight,
guidance documents, risk management, human factors engineering, and software design
and development but there is currently no agreed-upon standard approach for device
manufacturers, hospitals, and government agencies to utilize. Furthermore, there does
not appear to be a standard method for consistently identifying, gathering, and
prioritizing design inputs which could lead to improved cybersecurity for new and
existing connected medical devices.

17
Purpose of the Study
A number of methods have been identified for addressing the risks posed by
medical device software cyber-threats as they relate to device integrity and availability.
However, a comprehensive approach which leverages existing quality assurance tools
and techniques to improve the effectiveness of design input synthesis appears to be
lacking. Based on this premise, the intended thesis will examine the current “state of the
art” with regard to identifying, understanding, and addressing medical device
cybersecurity vulnerabilities in terms of applicable regulations, guidance documents, risk
management techniques, human factors engineering, software design and development
methods as well as other quality techniques presently being employed. Once this
framework has been established, the Plan-Do-Study-Act (PDSA) cycle will be leveraged
as a model for managing the software and hardware design requirements necessary for
ensuring cybersecurity risk mitigation across the complete lifecycle of a fictionalized
medical device. The PDSA cycle is widely recognized as an effective methodology for
implementing continuous improvement relative to the quality of numerous products,
processes, and services. Needed changes are identified, implemented, and reviewed for
effectiveness. Successive iterations incorporate the knowledge gained from previous
cycles with regard to those changes which are favorable and those which are not
(Deming, 1986, p. 88-89).
One quality technique which has been successfully employed as a means of
collecting, organizing, and prioritizing product and process design input data is Quality
Function Deployment (QFD). Originally developed in Japan during the 1960s, QFD was
18
intended to capture customer needs and desires for a new product and then to translate
this information into specific design requirements. It was originally established as a tool
for new product development within the larger framework of Total Quality Control
(TQC) (Akao & Mazur, 2003).
Within this context, QFD will be explored as a means to consistently identify,
gather, and prioritize medical device cybersecurity design input requirements from a
variety of customer inputs. This technique has been used by Japanese organizations and
others around the world for several decades to ensure appropriate incorporation of
customer-specific desires and expectations with regard to product and process quality.
The expected outcome of this particular study is the development of a comprehensive
PDSA methodology and QFD solution which can be repeatedly applied to the awareness,
identification, and remediation of cybersecurity vulnerabilities in a more holistic and
consistent manner across the lifecycle of any connected medical device.
With new connected devices entering the healthcare arena each day, the problem
of ensuring device integrity and availability will only become more complex and prolific
over time. It is for this reason that a systematic approach to managing security-specific
design requirements over the entire lifecycle of a connected device and its host
environment is extremely important.

19
Theoretical Bases and Organization
There are currently several techniques being utilized by medical device designers,
manufacturers, government agencies, and hospitals to help ensure cyber-threat awareness,
definition, and remediation. What is not readily apparent within these disparate
methodologies, however, is a common and systematic approach to synthesizing design
input requirements from a diverse set of customers and stakeholders which can be applied
to medical devices with regard to ensuring patient safety through device integrity and
availability.
Risk management techniques are widely used by medical device designers and are
readily being incorporated into quality system standards such as ISO 13485. These
methods, however, are more commonly applied to ensuring device safety rather than
addressing security issues specifically. Some of the more common risk management
techniques being utilized across the lifecycle of medical devices include: Failure Mode
and Effects Analysis (FMEA), Hazard and Fault Tree Analysis (FTA), a combination of
FMEA and FTA methods, qualitative risk prioritization methods, risk traceability
matrices, and other methodologies which do not explicitly identify assumptions and
context. FMEA represents a bottom-up approach to risk management through
consideration of subsystem and component failures. FTA, on the other hand, represents a
top-down approach to risk management. It starts with an assumption that harm has
occurred and then aims to identify all hazardous situations which could have led to the
harm. The Institute of Medicine (IOM) has characterized the complex environment in
hospitals as a sociotechnical system. The bottom-up analysis focuses on identifying

20
device component failures. It would be difficult for this method to identify all the causes,
including interactions among environmental conditions, use conditions, and non-failing
components that can lead, or contribute to, a hazardous situation or harm (Eagles & Wu,
2014).
Table 4 provides a summary of several popular quality tools and methodologies as
well as their potential implementation challenges with regard to medical device
cybersecurity mitigation.
Table 4
Quality Tools and Potential Challenges for Cybersecurity

Potential
Quality Typical
Strategy/Description Challenges for
Tool Application(s)
Cybersecurity
Design for A design methodology for ensuring Used to obtain It may be difficult to
Six Sigma goods and services meet customer critical-to-quality obtain direct critical-
(DFSS) needs and performance objectives. (CTQ) information to-quality
Includes four principle activities: from customers and characteristics from
Identify, Design, Optimize, Verify then subjects these medical device
requirements to a customers and
rigorous six sigma stakeholders.
design process.
21
Table Continued
Potential
Quality Typical
Tool Application(s)
Cybersecurity
Failure Mode Potential failure modes which can Widely used as a It is difficult to
and Effects occur within a process or product risk management determine all hazard
Analysis are first identified. The severity of tool in various scenarios at the
(FMEA) each potential failure, along with its industries, including system level as well
likelihood of occurrence and security risk as system and
detectability are also assessed. management. component
Numerical scores are then applied interactions leading
to each of these attributes, such that to device failures.
a risk priority number (RPN) is
obtained. Corrective actions and
controls are implemented in order
to lower each RPN as far as
possible.
Fault Tree Used to describe various event Risk management It is difficult to

Analysis combinations which can lead to a tool used primarily identify all low-level
(FTA) potential process or product failure. for identification of causes needed to
Conditions or events are linked failures which occur determine the events
through a series of “and” gates and as a result of and conditions
“or” gates. multiple events. which are
contributors to a
hazardous situation.
Plan Do A process improvement Has application as While the iterative

Study Act methodology which mirrors the both a short-term nature of this
(PDSA) scientific method of formulating a continuous method is well-
hypothesis, conducting an improvement suited for the
experiment, analyzing the results, methodology and as dynamic
and determining if further a long-term tool for environment of
refinement is required. organizational cybersecurity, it may
development. be difficult to obtain
required information
during the Study
phase.
22
Table Continued
Potential
Quality Typical
Tool Application(s)
Cybersecurity
Quality Also referred to as a “House of Used to guide the Requires input from
Function Quality” based on its appearance, design, manufacture, various stakeholders
Deployment this process drives incorporation of and marketing of across the entire
(QFD) Voice of the Customer (VOC) products through spectrum of a
information (via a set of linked assurance that device’s lifecycle.
matrices) throughout a product’s customer needs are Such information
lifecycle. met. may be difficult to
reliably obtain.
Note. Developed by the author using information obtained from Banuelas & Antony, 2004; Eagles &
Wu, 2014; Liu, 2000; and Taylor et al., 2013
Human factors engineering (HFE), while typically relied upon during the design
phase to assess a user’s experience with a device’s interfaces and their ability to
effectively manage patient workflows during a device’s clinical application, is not
routinely employed to understand the cyber-cognitive links which exist between
cybersecurity and the typical areas of study within human factors engineering. HFE
plays a role in effective mitigation of cybersecurity for connected medical devices based
on the premise that any process or system which is developed to identify and control
medical device cyber-threats must also take into consideration human reaction, response
time, and decision making. Thus, remediation approaches which only entail a technical
solution will not consider the equally-important understanding of human cognition and its
impact on designing within the realm of human capabilities (Gutzwiller, Fugate, Sawyer,
& Hancock, 2015).
Software assurance, a rigorous approach to ensuring that software is complete,
safe, and reliable across the lifecycle of medical device products and processes, is
23
intended to guarantee conformance to all applicable regulations, standards, requirements,
and procedures. This is especially critical when considering the design and development
of systems with embedded software as well as those connected to healthcare networks.
Unfortunately, current FDA regulatory requirements and guidance documents do not
completely address all aspects of software assurance (Cooper & Pauley, 2006).
Given the dynamic nature of the connected medical device cybersecurity
landscape, there is a constant need to incorporate device design and process changes to
address emerging threats. While not specifically tailored to the management of medical
device security requirements, the ISO 27000 series of standards was developed as a
framework for the protection of information and information systems. Specifically, ISO
27000, 27001, and 27002 provide control objectives, specific controls, requirements, and
guidelines to assist organizations in the achievement of adequate information security.
This family of standards is directly aligned with the PDSA cycle which places an
emphasis on process orientation and planning as well as a recurring focus on verification
of the intended outcomes. Figure 4 illustrates the application of PDSA to information
systems security (Disterer, 2013).

24
PLAN
(Establish)
-Identify information assets and their

associated security requirements
-Assess information security risks
-Select relevant controls to manage
unacceptable risks
ACT DO
(Maintain and (Implement and
Improve) Operate)
-Corrective actions -Implement control

-Preventive actions -Manage operations
-Monitor performance
-Assess performance
STUDY
(Monitor and Review)
Figure 4. Application of PDSA to Information Systems Security. Adapted by the author

from “ISO/IEC 27000, 27001 and 27002 for information security management,” by G.
Disterer, 2013, p. 95.
The PDSA cycle, as it is currently applied to the protection of information and
information systems, will serve as the theoretical basis for this study. Given the
aforementioned need to develop a more comprehensive method for managing specific
medical device design cybersecurity input requirements, PDSA will be leveraged for this
purpose across the lifecycle of a typical medical device.
Within this newly-realized PDSA cycle, QFD will then be utilized as a way to
consistently identify, assemble, and prioritize inputs from various customers and then
translate these into medical device security design inputs. In this utilization of QFD, the
25
idea of “customer” will be modified and expanded from the traditional role of a typical
product or service end-user to that of regulators, standards organizations, medical device
patients, device users, hospital staff, IT managers, cybersecurity specialists, network
developers, and others who may not be directly involved in the specific device design
effort but are nonetheless viewed as key stakeholders in the process.
Limitations of the Study
Cyber-threats present a number of challenges for medical device manufacturers,
users, hospitals, and patients. These situations can be categorized in terms of their impact
on confidentiality, integrity, and availability (Sametinger, Rozenblit, Lysecky, & Ott,
2015). Confidentiality of patient data is a significant concern but the more important
aspect of cyber-threat management is related to maintaining the integrity of the medical
device (in terms of its overall safety and efficacy) and ensuring its availability when
required by the user. Therefore, the intended study will focus specifically on methods for
reducing the potential for cyber-threats associated with patient safety by ensuring the
integrity and availability of connected medical devices through effective design. Within
the framework of the PDSA cycle, this will primarily encompass the Plan portion of the
cycle but may also include other portions of the process based on their relevance to the
overall lifecycle of a typical medical device.

26
Definition of Terms
Asset: Person, structure, facility, information, and records, information technology
systems and resources, material, process, relationships, or reputation that has value
(AAMI, 2016).
Cybersecurity: Precautions taken to guard against crime that involves the Internet,
especially unauthorized access to computer systems and data connected to the Internet.
In the case of connected medical devices, this includes the safeguarding of computer
networks and their associated information from penetration and from malicious damage
or disruption (Williams & Woodward, 2015).
Failure Mode and Effects Analysis (FMEA): A step-by-step approach for identifying all
possible failures in a design, a manufacturing or assembly process, or a product or
service. “Failure modes” means the ways, or modes, in which something might fail.
FMEA is used during design to prevent failures (Eagles & Wu, 2014).
Fault Tree Analysis: A top down, deductive failure analysis in which an undesired state
of a system is analyzed using Boolean logic to combine a series of lower-level events
(Eagles & Wu, 2014).
Integrity: Guarding against improper information modification or destruction and
includes ensuring information non-repudiation and authenticity (Kissel, 2013).
ISO 13485: Specifies requirements for a quality management system where an
organization needs to demonstrate its ability to provide medical devices and related
services that consistently meet customer and applicable regulatory requirements (ISO,
2016).
27
ISO 27000: An ongoing series of standards for managing and measuring information
security and its support systems within an enterprise. First published in 2005, the ISO
27000 series is jointly developed by ISO and the IEC (Disterer, 2013).
Malware: A program that is inserted into a system, usually covertly, with the intent of
compromising the confidentiality, integrity, or availability of the victim’s data,
applications, or operating system or of otherwise annoying or disrupting the victim
(Kissel, 2013).
Medical device: Any article or healthcare product intended for use in the diagnosis of
disease or other condition, or for use in the care, treatment or prevention of disease,
which does not achieve any of its primary intended purposes by chemical action or by
being metabolized (FDA, 2014).
Network: A group of two or more computer systems linked together. Computers on a
network are sometimes called nodes. Computers and devices that allocate resources for a
network are called servers (Kissel, 2013).
Non-repudiation: Assurance that the sender of information is provided with proof of
delivery and the recipient is provided with proof of the sender’s identity, so neither can
later deny having processed the information (AAMI, 2016).
Plan Do Study Act (PDSA) Cycle: A cyclical approach to quality improvement in which
you plan an action, perform the action, study the outcome to determine its conformance
to the plan and expectations, then make additional improvements. Improvements made in
this manner are eventually institutionalized (Deming, 1986).

28
Quality Function Deployment: A highly structured methodology for identifying,
classifying, and ranking customer requirements and expected benefits from a product or
service, then correlating these to design features and production requirements (Akao &
Mazur, 2003).
Ransomware: A type of malware that prevents or limits users from accessing their
system, either by locking the system's screen or by locking the users' files unless a
ransom is paid (Kansagra, Kumhar, & Jha, 2015).
Residual risk: The remaining potential risk after all security measures have been taken
(Kissel, 2013).
Risk: The combination of the probability of occurrence of harm and the severity of that
harm. In this case, harm refers to physical injury or damage to the health of people, or
damage to property or the environment (ISO, 2012).
Risk management: A coordinated set of activities and methods that is used to direct an
organization to analyze, evaluate, control, and monitor the many risks that can affect its
ability to achieve objectives (ISO, 2012).
Security requirement: Requirements levied on an information system that are derived
from applicable laws, Executive Orders, directives, policies, standards, instructions,
regulations, or procedures, or organizational mission/business case needs to ensure the
confidentiality, integrity, and availability of the information being processed, stored, or
transmitted (Kissel, 2013).
Threat: Any circumstance or event with the potential to adversely impact organizational
operations (including mission, functions, image, or reputation), organizational assets,

29
individuals, or other organizations through an information system via unauthorized
access, destruction, disclosure, modification of information, and/or denial of service
(Kissel, 2013).
Validation: Confirmation, through the provision of objective evidence that the
requirements which define an intended use or application have been met (ISO, 2016).
Verification: Confirmation, through the provision of objective evidence that specified
requirements have been fulfilled (ISO, 2012).
Vulnerability: Weakness in an information system, system security procedures, internal
controls, or implementation that could be exploited or triggered by a threat source
(Kissel, 2013).
30
CHAPTER 2
REVIEW OF LITERATURE
Overview
The literature review was undertaken to develop an improved understanding of
the current tools and methodologies being utilized for the identification, prioritization,
and management of cybersecurity vulnerabilities associated with connected medical
devices and their associated networks. In addition, the application of PDSA and QFD to
these areas was also explored. Sources reviewed for this study included well-established
regulatory requirements, emerging regulatory guidance documents, international
standards, risk management practices relative to security, human factors engineering
considerations, and software design and development techniques. In addition,
incorporation of the PDSA cycle into several security-based international standards was
evident during the research as was the utilization of QFD for software design and
development activities.
Regulations and Guidance Documents
Review of the applicable regulations and guidance documents associated with
medical device cybersecurity suggests that the FDA has played a role in providing
guidance to industry in this area for more than a decade. For example, the FDA’s
guidance document entitled, “Cybersecurity for Networked Medical Devices Containing
Off-the-Shelf (OTS) Software” was issued in 2005 and provides device manufacturers
31
with a series of 10 questions and answers for consideration when designing and
maintaining a medical device which incorporates an off-the-shelf software component.
The primary intent of this guidance document is to supplement the QSR and provide the
user with clarification on the least burdensome approach to ensuring cybersecurity
maintenance activities which are commensurate with medical device safety and efficacy
risks posed by vulnerabilities in purchased software. The questions cover a wide range of
topics including applicability of the guidance, the need for timely software patches to
address newly discovered OTS vulnerabilities, regulatory requirements associated with
software patches, validation of software patches, and the development and
implementation of a cybersecurity maintenance plan (FDA, 2005). Overall, this guidance
document provides a high-level awareness and overview of cybersecurity principles for
medical devices which utilize off-the-shelf software. It does not, however, offer any
specific insights into how to address cybersecurity vulnerabilities.
As discussed in Chapter 1 of this thesis, the FDA issued a safety communication
in 2013 entitled, “Cybersecurity for Medical Devices and Hospital Networks: FDA
Safety Communication,” which was intended to address medical devices connected to
hospital networks. The target audience for this document includes device manufacturers,
hospitals, device user facilities, healthcare information technology staff, and biomedical
engineers. The goal of the communication was to recommend that manufacturers and
healthcare facilities take the appropriate steps to reduce the risk of failures due to a cyber-
attack. Compared to the OTS guidance described above, this document offers additional
specificity with regard to cybersecurity vulnerabilities which may be encountered by

32
medical device manufacturers or hospitals with networked devices. The document also
suggests that device manufacturers consider taking steps to limit unauthorized device
access, protect individual components from exploitation through active security
appropriate to the device’s use environment, ensure the device maintains critical
functionality even when compromised, and provide methods for retention and recovery
following an event which compromises security. In a similar manner, health care
facilities are expected to evaluate the security of their networks by ensuring that antivirus
software and firewalls are kept current, network activity is monitored for unauthorized
use, network components are protected via security patches, device manufacturers or the
FDA is contacted in the event of a security issue, and strategies are developed and
evaluated to maintain critical functionality if an adverse event were to occur (FDA,
2015). While this guidance provides additional details and insights into cybersecurity
issues commonly faced by device manufacturers and hospitals, it also fails to provide
specific solutions which can be incorporated into device designs.
In October of 2014, the FDA issued a new guidance document entitled, “Content
of Premarket Submissions for Management of Cybersecurity in Medical Devices.” The
intent of this document was “to assist industry by identifying issues related to
cybersecurity that manufacturers should consider in the design and development of their
medical devices as well as in preparing premarket submissions for those devices” (FDA,
2013, p. 1). Device manufacturers are encouraged to develop a set of cybersecurity
controls intended to ensure continued functionality and safety. The FDA also indicates
that security is a responsibility, which is shared between various stakeholders, including

33
patients, health care facilities, and device manufacturers. Furthermore, the FDA
recommends that device design controls include considerations for security as well as
safety. Specifically, cybersecurity vulnerabilities should be identified and managed as
part of software validation and risk management activities which are already prescribed
under 21 CFR Part 820.30(g). To this end, five core functions (identify, protect, detect,
respond, and recover) are suggested as part of a cybersecurity framework. Identification
involves a careful review of the device’s intended use, its use environment, the types of
vulnerabilities which are present, the likelihood that a vulnerability will be exploited, and
the probability of harm associated with a cybersecurity breach. Based on this assessment,
the FDA recommends that the manufacturer include a justification for the chosen security
options within the premarket submission. Protection encompasses limiting access to
trusted users via a combination of user authentication, automatic timeouts during periods
of nonuse, password protection, data encryption, and physical lockouts where possible.
Detection, response and recovery include the implementation of features which provide
detection of a security event, provide information to the user with regard to appropriate
actions to be taken, protect critical functionality during such an event, and allow for
reestablishment of device configuration by an authenticated user having the appropriate
privileges (FDA, 2013). The cybersecurity framework referenced within this document
was developed by the National Institute of Standards and Technology (NIST). In
addition to the five core functions, the framework also includes 23 categories and 108
subcategories. The categories are intended to address cybersecurity objectives for a
given organization without providing excessive detail. The subcategories are intended to
34
drive programs for the creation or improvement of a cybersecurity program (NIST,
2014). Figure 5 illustrates a portion of the Identify function, the Business Environment
category, and a few examples of associated subcategories.
Function
Identify
Protect
Detect
Respond
Recover
Figure 5. NIST Cybersecurity Framework Categories and Subcategories. Retrieved from

NIST’s website at https://www.nist.gov/cyberframework/online-learning/components-
framework
While the Premarket Submissions guidance document begins to set the stage for
consideration of medical device security during the design and development phase, it
does not provide sufficient detail for the identification, retrieval, and management of
design input requirements necessary to ensure cybersecurity risk mitigation.
The most recent FDA guidance document addressing medical device
cybersecurity was published in December of 2016 and is entitled, “Postmarket

35
Management of Cybersecurity in Medical Devices.” The introductory section of this
document encourages medical device manufacturers to consider management of post-
market cybersecurity vulnerabilities for fielded devices in addition to addressing
cybersecurity throughout the product lifecycle stages of design, development, production,
distribution, deployment, and maintenance. Another key concept within this guidance is
the fact that not all device corrections and removals are required to be reported to the
agency as detailed within 21 CFR Part 806. In the case of routine software updates and
patches intended to address identified cybersecurity vulnerabilities, advance notification
and reporting are not required. In order to assess whether or not the reporting
requirements are to be followed, a risk-based approach is outlined. The FDA recognizes
that it is not possible to completely mitigate all security risks to a device solely through
the use of premarket controls. Instead, they advocate the implementation of a closed-
loop cybersecurity risk management program which is consistent with application of the
Quality System Regulation (21 CFR Part 820). Specific elements to be considered for
inclusion in such a system include but are not necessarily limited to: complaint handling,
quality auditing, corrective and preventive actions, software validation and risk analysis,
and servicing. In general, cybersecurity risk management programs should focus on
vulnerabilities associated with unauthorized device access, modifications to the device,
and misuse or denial of use, any of which could result in patient harm. Timely response
to identified vulnerabilities is expected (FDA, 2016). Unlike the previously-published
guidance documents, this one acknowledges the fact that cybersecurity management
extends beyond initial design and must be addressed across the entire device lifecycle.
36
Table 5 provides a summary of the regulations and guidance documents
previously discussed. Although each was observed to lack specificity regarding overall
cybersecurity design requirements management, they do include a number of valuable
customer inputs which can be leveraged for the proposed cybersecurity QFD matrix.
Table 5
Summary of Reviewed Regulations and Guidance Documents

Document Title Source Year Overview
Cybersecurity for FDA 2005 Guidance document providing device

Networked Medical manufacturers with ten key questions and
Devices Containing Off- answers for design and maintenance of a
the-Shelf (OTS) Software device incorporating off-the-shelf
technology. The primary intent is to serve as
a supplement to the Quality System
Regulation (21 CFR Part 820).
Cybersecurity for Medical FDA 2013 Safety communication aimed at medical

Devices and Hospital devices connected to hospital networks. The
Networks: FDA Safety document’s target audience includes device
Communication manufacturers, hospitals, device user
facilities, healthcare information technology
staff, and biomedical engineers. The goal of
the communication was to provide
recommendations for taking appropriate
steps to reduce the risk of failures due to a
cyber-attack.
37
Table Continued
Document Title Source Year Overview
Content of Premarket FDA 2014 Guidance document encouraging device

Submissions for manufacturers to develop a set of
Management of cybersecurity controls intended to ensure
Cybersecurity in Medical continued functionality and safety. This
Devices document also notes that security is a
responsibility which is shared between
various stakeholders (e.g. patients, health
care facilities, and device manufacturers).
Device design controls should include
considerations for security as well as safety
(i.e. vulnerabilities should be identified and
managed as part of software validation and
risk management activities). Five core
functions are suggested (identify, protect,
detect, respond, and recover).
Postmarket Management of FDA 2016 Guidance document encouraging medical

Cybersecurity in Medical device manufacturers to consider
Devices management of post-market cybersecurity
vulnerabilities for fielded devices in addition
to addressing cybersecurity throughout the
product lifecycle. Advocates the
implementation of a closed-loop
cybersecurity risk management program
which is consistent with application of the
QSR. Specific elements include but are not
necessarily limited to: complaint handling,
quality auditing, corrective and preventive
actions, software validation and risk analysis,
and servicing.
Note. Developed by the author using information obtained from FDA, 2005; FDA, 2013; FDA, 2015; and
FDA, 2016.
International Standards
There are several international standards which are applicable to the subject of
medical device cybersecurity. The primary ones reviewed during the development of this
thesis were ISO 13485, ISO 14971, IEC 80001-1, AAMI TIR57, and the ISO 27000
family of standards.
38
ISO 13485
“ISO 13485: Medical devices--Quality Management Systems--Requirements for
Regulatory Purposes,” is a quality management standard intended to provide guidance
with respect to medical device regulatory requirements. The latest version of this
standard, ISO 13485:2016 is based on ISO 9001:2008 and addresses the areas of
developing and maintaining a quality management system, management responsibility,
resource management, product realization, as well as measurement, analysis, and
improvement (ISO, 2016). Of particular interest from a cybersecurity standpoint are
clauses 7.2 (Customer-related processes), 7.3 (Design and Development) and 8.5
(Improvement).
Clause 7.2.1 Determination of requirements related to product includes the
following requirements:
The organization shall determine:
a) requirements specified by the customer, including the requirements for

delivery and post-delivery activities;
b) requirements not stated by the customer but necessary for specified or

intended use, as known;
c) applicable regulatory requirements related to product;
d) any user training needed to ensure specified performance and safe use of the
medical device;
e) any additional requirements determined by the organization (ISO, 2016, p.

22).
39
Sub-clause (b) above could be interpreted as a need for ensuring security
requirements are incorporated into the device design but again, this is not explicitly
indicated and is therefore open to multiple interpretations. Design and development is
further subdivided into specific requirements with respect to planning, design inputs,
design outputs, review, verification, validation, transfer activities, change management,
and design history file management. Clause 7.3.3 Design and development inputs
provides the following requirements:
Inputs relating to product requirements shall be determined and records
maintained. These inputs shall include:
a) functional, performance, usability, and safety requirements, according to the

intended user;
b) applicable regulatory requirements and standards;
c) applicable output(s) of risk management;
d) as appropriate, information derived from previous similar designs;
e) other requirements essential for design and development of product and

processes (ISO, 2016, p. 23).
Clearly, the design input requirements specified within this standard do not include
specifics with regard to device security.
Clause 7.3.6 Design and development verification includes the following statement:
If the intended use requires that the medical device be connected to, or have an
interface with, other medical device(s), verification shall include confirmation
that the design outputs meet design inputs when so connected or interfaced. (ISO,
2016, p. 24)
40
Similarly, clause 7.3.7 Design and development validation includes the following
statement:
If the intended use requires that the medical device be connected to, or have an
interface with, other medical device(s), validation shall include confirmation that
the requirements for the specified application or intended use have been met when
so connected or interfaced. (ISO, 2016, p. 25)
Finally, clause 8.5.1 provides general requirements with regard to improvements.
Specifically, this clause states:
The organization shall identify and implement any actions necessary to ensure
and maintain the continued suitability, adequacy, and effectiveness of the quality
management system as well as medical device safety and performance through
the use of the quality policy, quality objectives, audit results, post-market
surveillance, analysis of data, corrective actions, preventive actions, and
management review. (ISO, 2016, p. 34)
ISO 14971
“ISO 14971: Medical devices--Application of Risk Management to Medical
Devices,” is a risk management standard which was developed specifically for medical
device manufacturers using established principles of risk management. The concepts
associated with risk management are of particular importance to such devices because
their use encompasses a wide variety of stakeholders. This standard is typically
integrated into a quality management system such as ISO 13485, as described above. Its
overall applicability is intended to address the complete lifecycle of a medical device.

41
At a high level, the risk management process is comprised of risk analysis,
evaluation, control, and the iterative use of production and post-production information.
Risk analysis entails understanding the device’s intended use, reasonably foreseeable
misuse, and safety characteristics, identifying hazards, and estimating the risk associated
with each potentially hazardous situation. This is followed by risk evaluation in which
decisions are made with regard to the need for risk reduction based on a set of standard
criteria. When required, risk control activities are undertaken for risk reduction. Options
typically employed for risk reduction include designing for safety upfront, protective
measures within the device itself or within the manufacturing process, and providing
safety information to device users. If residual risks remain after these activities are
performed which cannot be mitigated to an acceptable level, a risk versus benefit analysis
is completed. Finally, the results of all these activities are incorporated into a
comprehensive risk management report. Information obtained from production and post-
production surveillance activities are then incorporated into additional risk analysis
activities throughout the lifecycle of a given device.
Of particular interest with regard to cybersecurity is the provision within the
standard for production and post-production information collection and review, as
detailed in clause 9. In addition to this information, Annex E of the standard provides
examples of hazards, foreseeable sequences of events, and hazardous situations. The
tables included within this annex provide several examples of hazards related to various
types of energy, biological and chemical hazards, operational hazards, and informational
42
hazards as well as initiating events and circumstances and the harm that can occur (ISO,
2012).
What is clear from reviewing ISO 14971 is that it is primarily intended to address
medical device safety risks rather than security risks. Based on this shortcoming,
additional research was undertaken to determine what other standards might be more
readily applied to the task of managing medical device security input requirements.
Three additional standards which were observed to have applicability in this area are IEC
80001-1, AAMI TIR 57 and the ISO 27000 family of standards.
IEC 80001-1
The intent of “IEC 80001-1: Application of Risk Management for IT-networks
Incorporating Medical Devices--Part 1: Roles, Responsibilities, and Activities,” is to
provide a set of requirements for the connection of a medical device to IT networks to
achieve interoperability without compromising the organization and delivery of
healthcare in terms of key properties, defined as safety, effectiveness, and data and
system security. The target audience for this standard is a responsible organization that
intends to incorporate a medical device into an IT network. As such, it does not address
pre-market risk management activities that are assumed to have been within the scope of
the device manufacturer. Prior to the publication of this particular standard, no other
standard addressed the appropriate connection of medical devices to IT networks to
ensure interoperability, safety, effectiveness, in addition to data and system security.
This document points to several areas of ongoing concern with regard to the
incorporation of medical devices to an IT network.

43
Sub-clauses 3.2 through 3.6 define specific roles and responsibilities associated
with the incorporation of medical devices into IT networks. Overall responsibility for the
correct functioning of a medical IT network resides with the health delivery organization
(HDO). One of the key roles to be established is that of a medical IT network risk
manager. Per the requirements of sub-clause 3.4, this individual is responsible for the
overall risk management process. Sub-clause 3.5 provides requirements for the
manufacturer of a medical device which is intended to be connected to an IT network to
make available instructions for implementation of the device’s connection. Clause 4 of
the standard provides requirements for risk management to be performed on the medical
IT network with consideration of the impact that changes will have on the overall risk of
the network with regard to the key properties. While the risk management practices
within this document are based largely on the activities defined within ISO 14971, IEC
80001-1 moves beyond basic safety to include the management of risk associated with
effectiveness as well as data and system security. In order to accomplish this, the
meaning of harm is expanded to include both a reduction in effectiveness as well as
breach of security (IEC, 2010).
AAMI TIR57
“AAMI TIR57: Principles for Medical Device Security--Risk Management,” is a
more recent medical device technical information report intended to provide guidance to
device manufacturers with regard to security-based risk management. This document
was developed based on the realization that there is minimal guidance available for the
assessment of medical device cybersecurity risk. Like IEC 80001-1, this guidance is
44
based upon ISO 14971 requirements. The rationale for this alignment is that device
manufacturers are already familiar with ISO 14971. Also, like the ISO 80000-1 standard,
this document considers risk in the broader context of including a “reduction in
effectiveness” as well as “breach of data and systems security” (AAMI, 2016, p. ix).
Unlike safety risk which is based on the probability and severity of a hazard leading to
harm, security risk looks at the likelihood of a threat being successful in exploiting a
device vulnerability.
In terms of its scope, TIR57 is intended to assist manufacturers in the following
areas:
 identifying threats, vulnerabilities, and assets associated with medical devices;
 estimating and evaluating associated security risks;
 controlling security risks; and
 monitoring the effectiveness of the risk controls (AAMI, 2016, p.1).
It is recommended that a separate process for security management be established which
parallels the process most likely already in place for safety risk management under ISO
14971. This is based primarily on the fact that the methods used to assess security differ
from those used to address safety risk. Similarities between this document as well as ISO
14971 and IEC 80001-1 include the development of a risk management plan and a risk
management file. Figure 6 illustrates the relationship which exists between the safety and
security risk management processes.

45
Figure 6. Relationship Between Safety and Security Risk Management Processes.

Obtained from AAMI, 2016, p. 7. Copyright 2016 by the Association for the
Advancement of Medical Instrumentation.
Clause 4 provides guidance around security risk analysis. Intended use and
reasonably foreseeable misuse of the device are primary considerations. Since HDOs can
vary in the sophistication of their cybersecurity capabilities, medical device
manufacturers are encouraged to perform a needs assessment using a representative
sample of HDOs as a precursor to the design and development process. Of primary
concern is consideration of the intended device’s expected operating environment.
Sub-clause 4.3 addresses the identification of threats, vulnerabilities, assets, and
adverse impacts which become the starting point for further analysis. From a threat
46
perspective, the risk analysis should consider not only potential threats but also the means
a threat actor might utilize in the exploitation of a vulnerability. Vulnerabilities originate
from three possible sources:
1. Those introduced by conscious design decisions (e.g. inclusion of a security

control versus allowing its bypass)
2. Errors in the design, implementation, manufacture, or configuration of the

device (sources include the manufacturer, their suppliers, or end users)
3. A design characteristic that was not known to be a vulnerability at the time of

design release
Typically, a top-down approach is utilized to identify device vulnerabilities. The process
is most valuable if initiated in the design concept phase but should also be leveraged
across advanced development stages as well as for devices currently in use. Device
assets can include items such as patient data, diagnostic data, therapy parameters, the
device itself, or device components such as software. The identification of these assets is
accomplished through a systematic process which includes those needed by the device
user to manage, diagnose, and provide patient treatment. Once the assets have been
identified, consideration is then given to the impact that a loss of integrity, availability, or
confidentiality could have on safety, effectiveness, or data and system security.
Sub-clause 4.4 provides an overview of the risk estimation process associated
with each combination of threat and vulnerability. In comparison to the process of safety
risk estimation, the combination of threat and vulnerability is analogous to the probability
of occurrence. Similarly, the impact of a compromised asset is analogous to the severity

47
of harm. The standard suggests that device manufacturers establish a documented and
repeatable risk estimation process.
Clause 6 addresses the topic of risk control and provides the following
prioritization with regard to options:
a) Inherent security by design
b) Protective measures in the medical device itself or in the manufacturing

process
c) Information for security (AAMI, 2016, p. 12).
The remaining clauses cover the areas of residual security risk evaluation, risk
management reporting requirements, and assessment of information obtained during
production and in post-production activities. Several annexes are also included in the
standard. Annex A provides informative details around security engineering principles
and nomenclature. Annex B provides a comprehensive overview of security risk
assessment. Annex C discusses the generation of cybersecurity requirements and
includes the following characteristics that each requirement should possess:
 Attainable: Technically and legally possible;
 Unambiguous: Simple, concise, standalone expression of a whole idea or

statement;
 Clear: Not confusing, using simple words, concise statements, and consistent
language;
 Consistent: Not in conflict with other requirements;
 Verifiable: Can be determined that the system meets the requirement either via
verification or validation;
48
 Necessary: Essential to meet the need of a stakeholder by implementing a

security control;
 Design free: Does not specify a design approach; and
 Positive: Written in the affirmative, not the negative (AAMI, 2016, p. 37).
Annex D provides a comprehensive list of questions intended to elicit ideas for
medical device security requirements. The questions are posed from the perspective of
multiple stakeholders, including device users, patients, and others. Overall, it provides a
starting point for additional inquiry. The list is subdivided into the following twelve
categories: essential performance, data storage, data transfer, authentication and
authorization, auditing, physical security, device and system updates, hardening,
emergency access, malware and virus protection, backup and disaster recovery, and
labeling (AAMI, 2016).
Overall, AAMI TIR57 provides the most comprehensive set of tools for
addressing cybersecurity requirements for medical devices. Of particular interest are
annexes C and D which provide a starting point for the development of a QFD approach
to medical device security requirements management.
ISO 27000 Family
The ISO 27000 family of standards includes over thirty different documents, a
number of which are under development, intended to provide operating models for the
establishment of security management systems across a wide range of organizations and
industries. In terms of the scope of this thesis, ISO 27000, ISO 27001, and ISO 27002
are the most relevant and will be discussed here.

49
“ISO 27000: Information Technology--Security Techniques--Information
Security Management Systems--Overview and Vocabulary,” provides an overview of
information security management systems (ISMS) as well as common terms and
definitions relevant to the use of the other standards within the family. The primary goal
of this standard is to provide an introduction to the importance and use of an ISMS
(ISO/IEC 27000).
“ISO 27001: Information Technology--Security Techniques--Information
Security Management Systems--Requirements,” is intended to provide a set of
requirements for the establishment, implementation, maintenance, and continuous
improvement of an ISMS. It is intentionally designed to be compatible with other
management system standards such that adopting organizations can operate under a
single management system standard which also incorporates the requirements of ISO
27001. Key considerations within this standard include leadership, policy development,
roles and responsibilities, planning, support, operation of the ISMS, performance
evaluation and improvement (ISO/IEC 27001). The scope of this document lends itself
to the use of the PDSA cycle, as noted in Chapter 1 of this thesis.
“ISO 27002: Code of Practice for Information Security Systems,” is intended for
organizations to use for the selection of appropriate controls during implementation of an
ISMS under ISO 27001. While a standard set of controls is presented, organizations can
also develop their own, based on their specific needs. Key topics covered within this
standard include: information security policies, human resource security, asset
management, access control, cryptography, physical and environmental security,

50
operations security, protection from malware, communications security, system
acquisition, development, and maintenance, supplier relationships, and information
security incident management (ISO/IEC 27002, p. 2-5).
Table 6 provides a summary of the international standards previously discussed.
Table 6
Summary of Reviewed International Standards

Document
Document Title Year Overview
Number
ISO 13485 Medical devices--quality 2016 Quality management standard intended
management systems-- to provide guidance with respect to
requirements for medical device regulatory requirements.
regulatory purposes The latest version of this standard is
based on ISO 9001:2008 and addresses
the areas of developing and maintaining
a quality management system,
management responsibility, resource
management, product realization, as
well as measurement, analysis, and
improvement.
ISO 14971 Medical devices-- 2012 Risk management standard which was
application of risk developed specifically for medical
management to medical device manufacturers using established
devices principles of risk management. This
standard is typically integrated into a
quality management system such as
ISO 13485. Its overall applicability is
intended to address the complete
lifecycle of a medical device.
51
Table Continued
Document
Number
IEC 80001-1 Application of risk 2010 Provides a set of requirements for the
management for IT-- connection of a medical device to IT
networks incorporating networks to achieve interoperability
medical devices--Part 1: without compromising the organization
Roles, responsibilities and delivery of healthcare in terms of
and activities key properties (safety, effectiveness,
data and system security). Expands the
meaning of “harm” to include both a
reduction in effectiveness as well as
breach of security.
AAMI TIR57 Principles for medical 2016 Technical information report intended
device security--risk to provide guidance to device
management manufacturers with regard to security-
based risk management. Developed
based on the realization that there is
minimal guidance available for the
assessment of medical device
cybersecurity risk.
ISO 27000 Information technology- 2015 Primary goal is to provide an

-Security techniques-- introduction to the importance and use
Information security of an Information Security Management
management systems-- System (ISMS).
Overview and
vocabulary
ISO 27001 Information technology- 2015 Provides a set of requirements for the
-Security techniques-- establishment, implementation,
Information security maintenance, and continuous
management systems-- improvement of an ISMS. Intentionally
Requirements designed to be compatible with other
management system standards (e.g.,
ISO 13485) such that organizations can
operate under a single management
system standard.
52
Table Continued
Document
Number
ISO 27002 Information technology- 2017 Intended for organizations to use for
-Security techniques-- selection of appropriate controls during
Code of practice for implementation of an ISMS under ISO
information security 27001. While a standard set of controls
controls is presented, organizations can also
develop their own, based on their
specific needs.
Note. Developed by the author using information obtained from ISO, 2012; ISO, 2016; IEC, 2010;
AAMI, 2016; ISO/IEC 27000; ISO/IEC 27001; and ISO/IEC 27002.
Risk Management Techniques
In their paper, “A Risk Management Capability Model for Use in Medical
Devices,” authors Burton, McCaffery, and Richardson (2006) note that regulators are
posing significant penalties against medical device manufacturers who fail to adequately
address hazard analysis and risk management throughout the software development
process. One of the primary reasons for this shortcoming is the number of standards,
regulatory guidance documents, and industry guides available on the topic of medical
device risk management. Given this situation, the authors set out to develop a Risk
Management Capability Model (RMCM) that can be utilized by medical device designers
to help ensure the consistency of software in terms of effectiveness and safety (Burton et
al., 2006).
Eagles and Wu describe a number of risk management techniques currently being
utilized during the development of medical devices and point out several of their inherent
shortcomings. In their paper, “Reducing Risks and Recalls: Safety Assurance Cases for
53
Medical Devices,” they note that while ISO 14971 provides a systematic lifecycle
process for risk identification, evaluation, and control, its requirements are open to
interpretation which can lead to varying methods and levels of effectiveness. After
providing a comprehensive list of typical methodologies used for risk management, they
point out the limitations associated with each and outline the benefits associated with
safety assurance cases. A safety assurance case provides validity for a particular safety
claim through both a convincing argument and supporting evidence. For medical
devices, a safety assurance case begins with a top-level claim and proceeds in a
hierarchical manner through various layers of sub-claims, each of which includes an
argument supporting its validity. The goal of this process is to build a structure of sub-
claims which support the top level claim with sufficient objective evidence (Eagles &
Wu, 2014). While this methodology is being applied to safety risk management, it could
be argued that the same process could also be utilized for the management of security
risks.
Additional research in this area identified a study aimed at the application of
assurance cases to security risk management. In their paper, “A Security Argument
Pattern for Medical Device Assurance Cases,” authors Finnegan and McCaffery (2014)
note that there is no formal methodology for implementing security risk management
within the medical device industry. To help address this gap, their research is based on
the development of a framework for meeting the requirements established within the
FDA cybersecurity guidance documents discussed earlier in Chapter 2 of this thesis. The
authors note that the application of assurance cases have expanded from safety risk
54
management into areas such as dependability, reliability, and security. Their proposed
framework was developed based on a review of several different security standards
resulting in nineteen different key security capabilities that device designers should
consider. The authors note that while these capabilities provide an organization and
structure for security requirements, they do not provide sufficient detail for the
specification of such requirements (Finnegan & McCaffery, 2014). With the framework
of capabilities established, a security assurance case structure is discussed which is
similar to the safety assurance case detailed by Eagles and Wu (2014).
Human Factors Engineering
In addition to risk management, human factors also play an important role in the
development of a comprehensive cybersecurity mitigation strategy. From the literature, it
is clear that any approach which ignores the human aspects over technology alone will
not be successful. In their paper, “Human and Organizational Factors in Computer and
Information Security: Pathways to Vulnerabilities,” authors Kraemer, Carayon, and Clem
(2009) conducted a study to understand the significance of human and organizational
factors as they relate to computer and information security. The article examines
computer-based vulnerabilities from a macroergonomic perspective. While not
specifically focused on medical devices, it does provide a detailed sociotechnical
viewpoint in contrast to the traditional technical-only solution. The authors recognize
that the effective mitigation of vulnerabilities and the damage resulting from cyber-
attacks continues to be one of the key problems within information security today.
55
However, most organizations tend to rely upon a technology-focused strategy rather than
considering the broader perspective of a sociotechnical approach, which has been shown
to play an important role in areas such as safety and accident mitigation. Improper
organizational policies and individual practices play a role in information system
vulnerabilities and may have their origins in early design and development assumptions
as well as management decisions. By considering a macroergonomic approach, both
human and organizational factors are addressed as a sociotechnical system such that both
the culture and structure of a given organization are appropriately designed. This may
include the boundaries between departments, systems of employee reward and
recognition, systems of supervision and control, performance expectations, employee
involvement strategies, and the design of specific roles within an organization. The study
resulted in the identification of potential pathways to security vulnerabilities in the areas
of design, implementation, configuration, and operation (Kraemer et al., 2009).
In a similar fashion, authors Gutzwiller, Fugate, Sawyer, and Hancock (2015)
argue in their paper, “The Human Factors of Cyber Network Defense,” that technology
does not exist in isolation and as a result, human factors play an increasingly important
role in cyber-defense operations. They note that industry is beginning to recognize that
design activities must include human cognition and capabilities in addition to the
software and hardware components (Gutzwiller et al., 2015).
Finally, while mainly targeted at device safety rather than security, a report by Fu
(2011) entitled, “Trustworthy Medical Device Software,” indicates that many of the
problems with today’s medical device software are precipitated by the inappropriate
56
application of systems engineering techniques, including specifications development and
consideration of human factors. For example, standalone devices which function
correctly may become less effective or ineffective if a component which is developed
separately is added to the system. It is further noted that designing medical device
software without a proper understanding of human factors can reinforce behaviors which
are risky and may result in injury or death. Thus, medical device software needs to
consider the potential for human error without compromising the safety of patients (Fu,
2011).
Software Design and Development Methods
As previously noted, device safety is typically emphasized over security. This is
also true for software development processes. Research into this particular area revealed
a number of interesting studies. In their article, “Inside Risks: Controlling for
Cybersecurity Risks of Medical Devices,” authors Blum and Fu (2013) argue that
medical device software must satisfy a number of simultaneous requirements, including
safety, security, reliability, and robustness. From an availability standpoint, they cite a
Wall Street Journal article which describes a Veteran’s Administration laboratory which
was closed in 2010 due to malware which infected a number of their critical care systems.
In another case, the Conficker virus was detected on 104 different systems at a Veteran’s
Administration hospital in Tampa. This case is of particular interest because at the time
of this incident, the Conficker virus was a well-known and easily mitigated form of
malware. The authors note that one of the key cultural issues with maintaining the
57
security of device software is a mismatch in lifecycles between off-the-shelf operating
systems and product software. The former typically has a lifecycle on the order of
months while the latter is measured in years or even decades. Of particular note is that
many devices currently in use today are still functioning on platforms which are no
longer supported, such as Microsoft Windows XP and 95. A common solution is to
install anti-virus software but as the authors point out, this is essentially an afterthought
intended to address the real root cause of inherent flaws in the device’s design. They
argue that security concerns need to be addressed during the design stage (Blum & Fu,
2013).
Based on a two-day invitational workshop on medical device software security
held in 2014, authors Haigh and Landwehr published the technical details surrounding
the development of a draft building code for software to allow for the most commonly
exploited vulnerability types to be addressed. The report, entitled, “Building Code for
Medical Device Software Security,” by Haigh and Landwehr (2015) covers the
development of a software model intended to provide a starting point for developers to
use which will facilitate the elimination of common classes of software vulnerabilities
(Haigh & Landwehr, 2015).
Plan-Do-Study-Act (PDSA)
History
As a methodology for continuous improvement, the PDSA cycle has been utilized
for decades to drive continuous improvement activities across numerous manufacturing

58
and service industries. The cycle has its original roots in the Shewhart Cycle, which was
developed in 1939. This cycle contained three elements: Specification, Production, and
Inspection. Shewhart related these to the scientific method of making a hypothesis,
carrying out an experiment, and testing the hypothesis. Deming later revised this concept
to include a fourth element and in 1951 it became known in Japan as the Deming Wheel.
The wheel initially consisted of: Design, Production, Sales, and Research. Later, this was
changed to PDCA (Plan, Do, Check, Act). By the 1980s, the letters were changed again
to PDSA (Plan, Do, Study, Act) because Deming felt that Check implied something was
being held back. The PDCA/PDSA cycle stresses the importance of establishing
standards to prevent recurrence of error. The standards need to be stabilized and
constantly modified (Moen & Norman, 2006).
Application
Sokovic, Pavletic, and Pipan (2010) suggest that “application of the PDCA cycle
has been found more effective than adopting ‘the right first time’ approach” (p. 478).
The use of PDCA implies continuously seeking out better improvement methods. The
cycle enables both temporary and permanent corrective actions. The former is aimed at
short-term fixes while the latter drives towards root cause analysis, correction, and
sustaining of processes. More than just a quality tool, the PDCA concept of continuous
improvement becomes imbedded in an organization's culture. The most important part of
the cycle is the Act portion because the cycle is complete at that point and another
iteration of improvement can begin, if necessary (Sokovic et al., 2010).

59
Taylor et al. (2013) discuss the application of PDSA to the continuous
improvement of healthcare. They advocate the importance of viewing PDSA as more
than simply a “black box” approach to continuous improvement. Rather, they argue that
PDSA is comprised of numerous inter-related steps which are impacted by the context of
the situation to which it has been applied. As opposed to more traditional methods of
healthcare research, such as randomized controlled trials, PDSA offers a practical way of
assessing changes within a complex system. The methodology mirrors the scientific
method in terms of generating a hypothesis (Plan), obtaining data to test the hypothesis
(Do), assessing the results (Study) and using this information to further refine the
hypothesis (Act) (Taylor et al., 2013).
As previously discussed, a review of the applicable literature also indicates that
PDSA has been adapted to the management of medical device security requirements.
This is evident within some of today’s international standards such as IEC 80001-1 and
the ISO 27000 family (as illustrated in Figure 4). Figure 7 serves to highlight the
problem solving process steps, iterative nature, and continuous improvement potential of
the PDSA cycle.

60
Start
Identify Problem
PLAN
Analyze Data
Identify Solution
Develop
Implementation
Plan
Implement
DO
Solution
Check
Effectiveness of
Solution
STUDY
No
Expected
Outcome?
Yes
Standardize
ACT
Solution
End or New Task
Figure 7. PDSA Cycle Process Flow. Adapted by the author from “The improvement on
the basis of PDCA and SDCA cycles,” by K. Knop and K. Mielczarek, 2015, p. 63.
Quality Function Deployment
History
One quality technique which has been successfully employed as a means of
collecting, organizing, and prioritizing product and process design inputs is QFD. QFD
was developed in Japan during the 1960s, a period of time marked by a departure from
the post-World War II method of product development through imitation. Instead, Japan
was embarking on a new era of originality in this area. QFD was first established during
61
this time as a tool for new product development within the larger framework of TQC
(Akao & Mazur, 2003).
Definition and Methodology
QFD is defined as a process for establishing a quality of design, which is aimed at
satisfying the requirements of customers and then translating these requirements into
design specifications and measurable quality targets to be used throughout the production
phase. Thus, QFD is a method of ensuring design quality while a product is still in the
design stage. It is also a means for recognizing, valuing, and carrying the voice of the
customer through the entire design process. QFD consists of two main components
which are deployed into the design process, quality and function. The quality
deployment component allows the voice of the customer (VOC) to be brought into the
design process. The function deployment component brings together different
organizational areas to enable translation of the customer inputs into detailed engineering
requirements and design specifications. This component also facilitates the creation of
operational definitions around the customer requirements, which are often-times vaguely
expressed. Overall, QFD is intended to assist organizations in targeting those
characteristics of a new or existing product (or service) which will meet the needs of
various market segments, as well as company or technology development needs
(Atugade, Awate, Shinde, & Harugade, 2016, p. 53).
QFD relies upon a series of linked matrices to ensure that voice of the customer
information is translated through all aspects of the design, manufacturing, and delivery
process. The first of these matrices is known as the Customer Requirement Planning
62
Matrix. It is also referred to as the House of Quality, based on its overall appearance.
Figures 8 and 9 illustrate each of these concepts (Liu, 2000). Note that there are seven
distinct regions within the House of Quality (see Figure 9).
Technical
Requirements
Requirements
Customer
Part
Characteristics
Requirements
Technical
Process
Operations
Characteristics
Part
Manufacturing
Requirements
Operations
Process
Figure 8. Relationship Between Houses of Quality. Adapted by the author from

“Software quality function deployment,” by X. F. Liu, 2000, IEEE Potentials, 19(5), p.
14-16.
63
Technical Requirement
Interrelationships
(Region 3)
Technical Requirements
(Region 2)
Customer Requirement Priorities
Customer Requirements (VOC)
Competitive Analysis
(Region 1)
(Region 4)
Relationship Between
(Region 6)
Customer and Technical
Requirements
(Region 5)
(Region 5)
Technical Requirement Priorities

(Region 7)
Figure 9. Typical House of Quality. Adapted by the author from “Software quality
function deployment,” by X. F. Liu, 2000, IEEE Potentials, 19(5), p. 14-16.
Applications
Additional review of the literature in this area revealed that QFD has also been
utilized in the realization of software as a means of improving both the software
development process and the resulting product. In his article, “Software Quality Function
Deployment,” Liu (2000) describes how software quality function deployment (SQFD)
64
can be utilized as a means of reducing rework based on the minimization of changes to
requirement specifications, design, and coding. SQFD was first utilized as a method of
improving embedded software development in Japan and was later adopted by several
large organizations such as Hewlett-Packard, IBM, and Texas Instruments. The process
incorporates the typical house of quality structure to capture customer requirements
which are complete, consistent, and realizable. Liu goes on to describe the three types of
customer requirements: revealed, expected, and exciting, based on the Kano Model of
Customer Requirements. Revealed requirements are identified when a customer is asked
directly what features and functions of a product are desired. Expected requirements are
typically of such a basic nature that they are not discussed until a failure occurs. Finally,
exciting requirements are the most difficult to identify because they are typically not
something that the customer has even considered (Liu, 2000).
Overall, research into the application of quality function deployment to software
indicates that limited information has been published. One article by Haag, Raja, and
Schkade (1996), entitled, “Quality Function Usage in Software Development,” explores
the use of SQFD across a number of organizations which develop various types of
software, including operating systems, embedded, network, and others. While not
specific to the development of medical device software, it does illustrate the advantages
of using a structured approach to the identification of software input requirements (Haag
et al., 1996).
65
Summary
Ongoing cybersecurity threats to medical devices demonstrate a clear need for
managing risks associated with the assurance of safe and effective device utilization over
a given product’s lifecycle. To this end, the identification, acquisition, and prioritization
of software and hardware design input requirements inherent to this goal is a key
consideration for today’s medical device organizations. The literature review completed
for this thesis revealed that while a number of different methodologies are presently
being utilized to achieve this goal, there does not appear to be a systematic approach to
ensuring its consistent realization. The review further clarified the fact that such a
methodology would need to encompass the requirements of relevant regulatory guidance
documents and international standards as well as the fundamental aspects of risk
management and human factors engineering. To this end, the research did identify a
number of key customer inputs across these categories which could be effectively
leveraged for the proposed QFD matrix. It was also observed that the PDSA cycle has
been incorporated into several security management standards as a way of managing the
applicable requirements across the entire lifecycle of a device, including not only the
design but also post-market vigilance activities. While the adaptation of QFD to software
design and development is apparent, its usage does not appear to be widespread. Finally,
the literature review did not reveal any current applications of QFD to medical device
security requirements, which will be the primary focus of this thesis.

66
CHAPTER 3
METHODOLOGY
Introduction and Key Objectives
This study focused on the development of a cybersecurity-specific QFD matrix
for a fictionalized medical device incorporating features and components which could
allow for a potential cyber-attack. While the device under examination may be similar to
existing products on the market today, no proprietary information was included in the
development of the QFD matrix used for this study. The Plan-Do-Study-Act cycle served
as the basis for this process in order to illustrate the iterative nature of cybersecurity
design requirements development and to allow for ongoing refinement of the proposed
QFD matrix via incorporation of active stakeholder participation. In order to gather the
required information needed to initially construct a suitable matrix for the fictional
device, data was first obtained from several of the key resources identified within the
literature search undertaken in Chapter 2. This was followed by solicitation of additional
voice of the customer information from professionals employed within two different
medical device manufacturing firms as well as an independent medical device validation
consultant. The data obtained from this additional research was used to further enhance
the baseline QFD matrix.
Key Activities
The specific objectives of the study included completion of the following key
activities:
67
 Definition of the criteria and boundaries associated with each phase of the
PDSA cycle used for the study
 Definition of a fictional medical device which would minimally contain a

wireless interface or be connected to a hospital network and would therefore
be subject to potential cyber-attacks
 Identification of baseline customer requirements associated with the

previously completed literature review
 Identification of software and hardware design requirements for the fictional

device necessary to establish a baseline cybersecurity QFD matrix
 Development of a general questionnaire for gathering additional voice of the

customer stakeholder data relative to the following cybersecurity focus areas:
o Regulations and Guidance Documents
o International Standards
o Risk Management Techniques
o Human Factors Engineering
o Software and/or Hardware Design and Development Methods
 Administration of the questionnaire to individuals involved in the design and

development of a typical connected medical device who have responsibility
for the inclusion of security requirements
 Completion of follow-up discussions with selected stakeholders to understand

potential gaps in the way security requirements are communicated, prioritized,
implemented, and managed throughout the lifecycle of a typical connected
medical device (such as the device being utilized for this study)
 Analysis of all questionnaire and follow-up discussion data to identify

requirements which may have been previously overlooked
 Enhancement of the baseline matrix, resulting in a final cybersecurity-specific

QFD matrix which leverages the inputs of device users, security management,
information technology, and other personnel in addition to device designers
68
 Review of the completed cybersecurity QFD matrix with each of the surveyed
stakeholders to determine its applicability to future medical device design
efforts
PDSA Plan Phase
During the Plan phase of the PDSA cycle, a fictional medical device was created
in order to serve as a model for eventual construction of the subject QFD matrix. The
device was defined both in terms of its intended use and its typical use environment since
these basic parameters are essential for the determination of security requirements. This
was followed by the identification of baseline customer and technical requirements
necessary for establishment of a general QFD matrix incorporating security criteria. In
preparation for further refinement of this initial matrix, a stakeholder questionnaire was
also developed. Finally, the steps necessary to construct the baseline matrix were
identified and discussed. Completion of the Plan phase resulted in the essential elements
needed for a security-based QFD matrix as well as the additional research steps for its
eventual enhancement.
Subject Medical Device Overview
For the purpose of this study, a fictionalized medical device was defined in order
to allow for the realization of a cybersecurity QFD matrix without any concerns for the
disclosure of proprietary information. This device is representative of any number of
actual connected medical devices and serves to illustrate one possible version of a
cybersecurity QFD matrix. The essential design characteristics of the fictional device
which are necessary for this study are detailed below. This is a simplified set of design
69
criteria intended primarily to illustrate the basic requirements for a security-based QFD
matrix. Design requirements for the development of a real device would necessarily be
more comprehensive.
 The device’s intended use is for diabetes patients and combines insulin
delivery and blood glucose sensing functions into a single, fully-automated
system
 The device is external to the human body but contains patient-applied sensors
along with a tubing set and catheter for the infusion of insulin
 The device utilizes a single, subcutaneous infusion site located on the patient’s
body
 The device delivers basal insulin based on the patient’s 24-hour glucose
profile as measured by the blood glucose sensor
 Basal rates are modifiable by the patient manually or by the system

automatically
 The device is portable and is typically worn by the patient when not at a care
provider location
 The device is intended to continuously monitor blood glucose levels and

administer a precise dosage of insulin to the patient, as required
 The device is directly connected to a hospital network during in-patient visits
 The device has a wireless interface which allows for remote troubleshooting
by hospital biomedical technicians as well as the device manufacturer
 The wireless interface is accessible via a username and password with

authentication of users provided by an external server intended for this
purpose
 The device is capable of generating and maintaining an internal electronic

record of patient data including the following information:
o Patient personal information: name, age, and sex

70
o Device functional status (e.g., operational, on standby, unavailable)
o Historical trend data (blood glucose levels and insulin administration)
o Battery charge level
o Device alerts (e.g., blood glucose too high or low, low battery)
 Electronic records can be transmitted by the device to the care provider via the
wireless interface
 Therapy and alert parameters can be modified by the care provider via the
wireless interface
 Transmitted/received data is encrypted/decrypted using a recognized standard
Using this basic set of design criteria, the next step in the process was to identify the
activities necessary for construction of a baseline cybersecurity QFD matrix.
Quality Function Deployment

Matrix Implementation
General Development Process
The initial step in development of the baseline matrix was to review the process
associated with the creation of a customer requirement planning matrix, which is the first
of four matrices discussed in Chapter 2. See Figures 8 and 9 for details. The key
elements of this process are as follows:
1. Identify customer and technical requirements (Regions 1 and 2 respectively)
2. Evaluate interrelationships between technical requirements (Region 3)
3. Prioritize the customer requirements (Region 4)
4. Relate the customer requirements to the technical requirements (Region 5)
5. Conduct an evaluation of competing products or services (Region 6)

71
6. Determine which technical requirements to deploy in the remainder of the

production/delivery process (Region 7)
Customer Expectations and Competitive

Product Analysis
As previously discussed, the Kano Model considers three distinct categories of
customer requirements. Revealed requirements are identified when a customer provides
a direct indication of the features and functions they desire in a product or service.
Expected requirements are anticipated to be present without necessarily being explicitly
requested. Exciting requirements are the most challenging for designers because they are
typically something the customer has not considered or does not know they even need.
Developing a customer requirement planning matrix for cybersecurity consisted primarily
of identifying expected requirements since the end customer (representing in this case, a
combination of patient, medical care practitioner, and device regulator) will ultimately
demand a product which is inherently safe and effective without necessarily expressing
this need.
Based on the nature of this study, the competitive product analysis noted in step 5
(Region 6 of Figure 9) could not be performed due to the lack of available data regarding
cybersecurity design practices associated with competitors’ products. Instead, it is
proposed that this element of the customer requirement planning matrix could be utilized
by a device manufacturer to assess cybersecurity performance against a previous version
of the device being investigated or against a similar device already being manufactured
by that particular organization. Additionally, the scope of the study was limited to
72
ideation of the customer requirement planning matrix only. As discussed later,
generation of the additional house of quality matrices is left to the reader.
Ranking Scheme
More traditional methods of QFD rely on a three-level relationship between
characteristics, typically expressed qualitatively as weak, moderate, and strong and
having corresponding numerical values such as 1, 2, and 4 or 1, 3, and 9. The advantage
of this approach is that priorities will not be too closely related to one another once the
subsequent mathematical steps are performed. The disadvantage, however, is that using
ordinal ranking scales such as these without fixed intervals provide order for the
characteristics of interest but do not necessarily serve to illustrate their relative
importance. A more contemporary approach is to utilize either five or nine levels with
common rational number assignments for each. For this study, a five-level approach was
utilized. Table 7 provides an overview of these ranking levels, which are consistent with
ISO 16355-1:2015. This ranking scheme was used within the main structure of the QFD
matrix (Region 5 of Figure 9) to compare voice of the customer requirements with the
technical (design) requirements.

73
Table 7
Five-level Ranking Scheme (VOC and Technical Requirements Comparison)

Qualitative Ordinal Rational Symbol
Symbol
Description Value Value Description
Weak 1 0.069 Unfilled Triangle
Moderate 3 0.135 Unfilled Circle
Strong 5 0.267 Filled Circle
Very Strong 7 0.518 Unfilled Square
Extremely Strong 9 1.000 Filled Square
Note. Developed by the author using information obtained from ISO 16355-1:2015, p. 12
Identification of Customer Requirements
In order to construct a suitable list of customer requirements, several resources
were utilized. As previously noted, the research completed for this study revealed a need
to incorporate several focus areas, including, but not limited to, risk management,
software and hardware design, human factors engineering, verification and validation as
well as quality management system elements. To accomplish this, it was necessary to
revisit the literature review and identify applicable customer requirements based on those
sources. Overall, the FDA guidance documents, ISO 13485, ISO 80001-1, and AAMI
TIR57 were observed to contain key voice of the customer requirements which are well-
suited for this purpose. Tables 8 through 12 provide a summary of these requirements
along with their source documentation and specific design categories. As noted earlier,
for this exercise the traditional QFD definition of voice of the customer has been
expanded to include medical device and information technology regulators, standards
organizations, and industry experts.

74
Table 8
Customer Requirements Related to Software and Hardware Design

Source Customer Requirements Design Category
FDA 2015 Take steps to limit unauthorized device access to trusted Software Design
users only
FDA 2015 Protect individual components from exploitation and Software Design
develop strategies for active security protection
appropriate for the device's use environment (should
include timely deployment of routine, validated security
patches and methods to restrict software or firmware
updates to authenticated code)
FDA 2015 Use design approaches that maintain a device's critical Software Design
functionality, even when security has been compromised,
known as “fail-safe” modes
FDA 2015 Provide methods for retention and recovery after an Software Design
incident where security has been compromised
FDA 2013 Limit access to devices through the authentication of users Software Design
(e.g., user ID and password, smartcard, biometric)
FDA 2013 Use automatic timed methods to terminate sessions within Software Design
the system where appropriate for the use environment
FDA 2013 Where appropriate, employ a layered authorization model Software Design
by differentiating privileges based on the user role (e.g.,
caregiver, system administrator) or device role
FDA 2013 Use appropriate authentication (e.g., multi-factor Software Design

authentication to permit privileged device access to system
administrators, service technicians, maintenance
personnel)
75
Table Continued
FDA 2013 Strengthen password protection by avoiding “hardcoded” Software Design

password or common words (i.e., passwords which are the
same for each device, difficult to change, and vulnerable
to public disclosure) and limit public access to passwords
used for privileged device access
FDA 2013 Where appropriate, provide physical locks on devices and Hardware Design
their communication ports to minimize tampering
FDA 2013 Require user authentication or other appropriate controls Software Design
before permitting software or firmware updates, including
those affecting the operating system, applications, and
anti-malware
FDA 2013 Restrict software or firmware updates to authenticated Software Design

code (e.g., code signature verification)
FDA 2013 Use systematic procedures for authorized users to Software Design
download version-identifiable software and firmware from
the manufacturer
FDA 2013 Ensure capability of secure data transfer to and from the Software Design
device, and when appropriate, use methods for encryption
FDA 2013 Implement features that allow for security compromises to Software Design
be detected, recognized, logged, timed, and acted upon
during normal use
FDA 2013 Implement device features that protect critical Software Design
functionality, even when the device's cybersecurity has
been compromised
FDA 2013 Provide methods for retention and recovery of device Software Design
configuration by an authenticated privileged user
76
Table Continued
FDA 2016 Manufacturers can also enhance their postmarket detection Software Design
of cybersecurity risks by incorporating detection
mechanisms into their device design and device features to
increase detectability of attacks and permit forensically
sound evidence capture
FDA 2016 When characterizing the exploitability of a vulnerability, Software Design

the manufacturer should consider factors such as remote
exploitability, attack complexity, threat privileges, actions
required by the user, exploit code maturity, and report
confidence
FDA 2016 Manufacturers should consider the incorporation of design Software Design
features that establish or enhance the ability of the device
to detect and produce forensically sound postmarket
evidence capture in the event of an attack
Note. Obtained from FDA, 2013, p. 4-5; FDA, 2015; and, 2016, p. 28-29.
Table 9
Customer Requirements Related to Risk Management

FDA 2005 There is a need for timely software patches to correct Risk Management
newly discovered vulnerabilities
FDA 2015 Manufacturers should consider incident response plans Risk Management
that address the possibility of degraded operation and
efficient restoration and recovery
77
Table Continued
FDA 2013 Manufacturers should establish design inputs for their Risk Management
device related to cybersecurity, and establish a
cybersecurity vulnerability and management approach as
part of the software validation and risk analysis that is
required by 21 CFR 820.30(g)
FDA 2013 Cybersecurity vulnerability and management approach Risk Management

should address identification of assets, threats, and
vulnerabilities

should address assessment of the impact of threats and
vulnerabilities on device functionality and end
user/patients

should address assessment of the likelihood of a threat and
a vulnerability being exploited

should address determination of risk levels and suitable
mitigation strategies

should address assessment of residual risk and risk
acceptance criteria
FDA 2013 The extent to which security controls are needed will Risk Management
depend on the device's intended use, the presence and
intent of its electronic data interfaces, its intended
environment of use, the type of cybersecurity
vulnerabilities present, the likelihood the vulnerability will
be exploited, and the probable risk of patient harm due to a
cybersecurity breach
FDA 2016 Cybersecurity risk management programs should include: Risk Management
monitoring cybersecurity information sources for
identification and detection of cybersecurity
vulnerabilities and risk
78
Table Continued
Maintaining robust software lifecycle processes that
include mechanisms for monitoring third party software
components for new vulnerabilities throughout the
device's lifecycle and design V&V for software updates
and patches that are used to remediate vulnerabilities,
including OTS software
understanding, assessing, and detecting the presence and
impact of a vulnerability
establishing processes for vulnerability intake and
handling
using threat modeling to clearly define how to maintain
safety and essential performance of a device by
developing mitigations that protect, respond, and recover
from the cybersecurity risk
adopting a coordinated vulnerability disclosure policy and
practice
deploying mitigations that address cybersecurity risk early
and prior to exploitation
FDA 2016 Manufacturers should define, as part of the comprehensive Risk Management
cybersecurity risk management, the safety and essential
performance of their device, the resulting severity of
patient harm if compromised, and the risk acceptance
criteria
FDA 2016 Manufacturers are encouraged to actively identify Risk Management
cybersecurity signals that might affect their product, and
engage with the sources that report them
79
Table Continued
FDA 2016 Manufacturers should analyze possible threat sources Risk Management
AAMI TIR57 Security risk management should be maintained as a Risk Management

companion process to the safety risk management process
AAMI TIR57 Top management should provide adequate and qualified Risk Management
personnel to perform the security risk management
process
AAMI TIR57 Persons performing security risk management tasks need Risk Management
to have the knowledge and experience appropriate to the
tasks assigned to them.
AAMI TIR57 Device manufacturers should have a security risk Risk Management
management plan.
AAMI TIR57 The security risk management file should contain, at a Risk Management
minimum, the following:
a) security risk management plan
b) security risk analysis components
c) security risk controls
AAMI TIR57 Security risk analysis should be performed for the medical Risk Management
device. This should include at least the following:
a) a description and identification of the medical device
that was analyzed
b) identification of the person(s) and organization carrying
out the security risk analysis
c) scope and date of the security risk analysis
AAMI TIR57 For the particular medical device being considered, the Risk Management
manufacturer should document the intended use and
reasonably foreseeable misuse.
AAMI TIR57 The manufacturer should document the assumed operating Risk Management
environment and security architecture for which the device
is designed to operate
80
Table Continued
AAMI TIR57 The manufacturer should perform a needs assessment with Risk Management
a representative sample of health delivery organizations
prior to initiating product design
AAMI TIR57 The manufacturer should document characteristics of the Risk Management
system that rely on user configuration to ensure the
security of the device
AAMI TIR57 The risk analysis should address characteristics of the Risk Management
device and its expected operating environment (physical
and IT)
AAMI TIR57 The risk analysis should document potential threats and Risk Management
the means a threat actor might use to exploit a
vulnerability
AAMI TIR57 The risk analysis should document known and potential Risk Management
vulnerabilities in the device (conscious design decisions;
errors in the design, implementation, manufacture, or
configuration; design characteristic not known to be a
vulnerability)
AAMI TIR57 Document the assets of the device. Assets may include Risk Management
information, the device itself, or components of the device
(software and physical connections)
AAMI TIR57 For each identified asset, consider the impact that loss of Risk Management
confidentiality, loss of integrity, or loss of availability
might have on safety, effectiveness, or data or system
security.
AAMI TIR57 Manufacturers should use a security risk control hierarchy Risk Management
that parallels the safety hierarchy presented in ISO 14971.
a) Inherent security by design
b) Protective measures in the medical device itself or in
the manufacturing process
c) Information for security
AAMI TIR57 The security risk control measures selected need to be Risk Management
implemented and verified with the results recorded in the
security risk management file
81
Table Continued
AAMI TIR57 Residual risk is re-evaluated after the security risk controls Risk Management
have been applied.
AAMI TIR57 Manufacturers should ensure that the risk(s) from all Risk Management
identified threats, vulnerabilities, and potentially
compromised assets have been considered and the
implemented controls are comprehensive in addressing
them.
AAMI TIR57 The manufacturer should employ security testing as a Risk Management
means to aid in the assessment of overall residual security
risk.
AAMI TIR57 The security risk management report should provide, Risk Management
either directly or by reference, the following items:
a) Risk analysis, mitigations, and design considerations
pertaining to cybersecurity risks
b) A traceability matrix of security risks to security
controls
c) Traceability of the verification reports for documented
security controls
d) A description of when and how security
updates/patches will be provided
e) A description of the steps taken to assure devices will
be delivered malware-free
Note. Obtained from FDA, 2005, p. 4; FDA, 2013, p. 4; FDA, 2015; FDA, 2016, p. 13-14; and AAMI,
2016, p. xi, 7-14.
82
Table 10
Customer Requirements Related to Human Factors

FDA 2005 Device users should not make changes without seeking Human Factors
manufacturer advice and recommendations
FDA 2013 Manufacturers should carefully consider the balance Human Factors
between cybersecurity safeguards and the usability of the
device in its intended environment of use to ensure that the
security controls are appropriate for the intended users
FDA 2013 Security controls should not unreasonably hinder access to Human Factors
a device intended to be used during an emergency
situation
FDA 2013 Develop and provide information to the end user Human Factors
concerning appropriate actions to take upon detection of a
cybersecurity event
IEC 80001-1 For a medical device that can be connected to an IT Human Factors
network, the medical device manufacturer shall make
available the purpose of the medical device's connection to
an IT network.
available the required characteristics for the IT network
incorporating the medical device
available the required configuration of the IT network
incorporating the medical device
available the technical specifications of the network
connection of the medical device including security
specifications
83
Table Continued
available the intended information flow between the
medical device, the medical IT network and other devices
on the medical IT network and if relevant to the key
properties, the intended routing through the medical IT
network
available a list of hazardous situations resulting from a
failure of the IT network to provide the characteristics
required to meet the purpose of the medical device
connection to the IT network
Kraemer, Management support is required Human Factors

Carayon, &
Clem, 2009
Kraemer, A commitment to maintenance is required Human Factors

Carayon, &
Clem, 2009
Kraemer, Data criticality must be adequately specified Human Factors

Carayon, &
Clem, 2009
Kraemer, Required Computer Information System (CIS) Human Factors

Carayon, & information must be accessible
Clem, 2009
Kraemer, The Computer Information System process, lifecycle and Human Factors
Carayon, & performance measures must be well defined
Clem, 2009
Kraemer, Computer Information System policy documentation Human Factors

Carayon, & within the organization must be in place
Clem, 2009
Kraemer, Project funding, schedules, and staffing must be adequate Human Factors
Carayon, &
Clem, 2009
84
Table Continued
Kraemer, Technology must be adapted to system requirements Human Factors

Carayon, &
Clem, 2009
Kraemer, Changes in design must be evaluated in a system context Human Factors

Carayon, &
Clem, 2009
Kraemer, Computer Information System policies must be followed Human Factors

Carayon, &
Clem, 2009
Kraemer, Ownership of Computer Information System must be Human Factors

Carayon, & defined
Clem, 2009
Kraemer, Communication among Computer Information System Human Factors

Carayon, & designers and between design and implementation must be
Clem, 2009 effective
Kraemer, Computer Information System must be a priority for the Human Factors
Carayon, & design project
Clem, 2009
Note. Obtained from FDA, 2005, p. 3; FDA, 2013, p. 4-5; IEC, 2010, p. 17-18; and Kraemer, Carayon, &
Clem, 2009, p. 10.
85
Table 11
Customer Requirements Related to Quality Management Systems

FDA 2005 Maintain business relationship with OTS software vendors Quality Management
to ensure timely receipt of information concerning quality System
problems and recommended corrective actions
FDA 2005 Develop a single cybersecurity maintenance plan to Quality Management
address compliance with the QS regulation System
FDA 2016 Manufacturers are required to analyze complaints, Quality Management

returned product, service records, and other sources of System
quality data to identify existing and potential causes of
nonconforming product or other quality problems
ISO 13485 Clause 7.2.1 Determination of Requirements Related to Quality Management

Product includes the following requirements: System
The organization shall determine:
a) requirements specified by the customer, including the
requirements for delivery and post-delivery activities;
b) requirements not stated by the customer but necessary
for specified or intended use, as known;
c) applicable regulatory requirements related to product;
d) any user training needed to ensure specified
performance and safe use of the medical device;
e) any additional requirements determined by the
organization.
ISO 13485 Clause 7.3.3 Design and Development Inputs provides the Quality Management
following requirements: System
Inputs relating to product requirements shall be

determined and records maintained. These inputs shall
include:
a) functional, performance, usability, and safety
requirements, according to the intended user;
b) applicable regulatory requirements and standards;
c) applicable output(s) of risk management;
d) as appropriate, information derived from previous
similar designs;
e) other requirements essential for design and
development of product and processes
86
Table Continued
ISO 13485 Clause 8.5.1 provides general requirements with regard to Quality Management
improvements. Specifically, this clause states: System
The organization shall identify and implement any actions

necessary to ensure and maintain the continued suitability,
adequacy, and effectiveness of the quality management
system as well as medical device safety and performance
through the use of the quality policy, quality objectives,
audit results, post-market surveillance, analysis of data,
corrective actions, preventive actions, and management
review.
Note. Obtained from FDA, 2005, p. 5; FDA, 2016, p. 27; and ISO, 2016, p. 22-23, 34.
Table 12
Customer Requirements Related to Verification and Validation

FDA 2005 Software changes to address cybersecurity vulnerabilities Verification and

must be validated before approval and issuance. Validation
ISO 13485 Clause 7.3.6 Design and development verification includes Verification and
the following statement: Validation
If the intended use requires that the medical device be
connected to, or have an interface with, other medical
device(s), verification shall include confirmation that the
design outputs meet design inputs when so connected or
interfaced.
87
Table Continued
ISO 13485 Clause 7.3.7 Design and development validation includes Verification and
the following statement: Validation
If the intended use requires that the medical device be
connected to, or have an interface with, other medical
device(s), validation shall include confirmation that the
requirements for the specified application or intended use
have been met when so connected or interfaced.
Note. Obtained from FDA, 2005, p. 4; and ISO, 2016, p. 24-25.
Organization of Customer Requirements
Given the large number of customer requirements which were addressed for this
study it was also necessary to employ two additional quality methods. An Affinity
Diagram was used to help consolidate the initial list obtained through the literature
search. The next challenge was to identify a consistent and repeatable process for
obtaining the relative importance of each requirement which could be used in place of
more subjective methods. For this purpose, the Analytic Hierarchy Process (AHP) was
selected. This multiple-criteria decision-making method employs pair-wise comparisons
to simplify the process of ranking a large number of different criteria. For this study,
elements of the AHP methodology were utilized to obtain weighted importance levels for
each of the customer requirements associated with the product being developed.
Additional details regarding this use of this process are left to the reader.
During the affinity diagramming process, the customer data from Tables 8
through 12 were sorted into a more manageable set of inputs for the baseline QFD matrix.
Through this activity, 15 new customer requirement categories emerged (Access and
88
Trust, Critical Functions, Device Recovery, Software Patches, Detection and Response,
Policies and Procedures, Intended Use, Vigilance, Resources and Training, Verification
and Validation, Documentation, Configuration Management, Asset Management,
Organizational Management and Risk Management). These categories were observed to
be more meaningful in terms of their relationship to the QFD technical requirements.
The Affinity Diagram developed for the study is shown in Figure 10.
Access and Trust Critical Functions Device Recovery Software Patches Detection and Response
Limit device access to Maintain device critical Provide for retention Timely software patches Implement features that allow
trusted users only functions even when and recovery after a are available for security compromises to
compromised (fail-safe security event be detected, recognized,
Limit device access modes) Restrict software or logged, timed, and acted upon
through user Provide methods for firmware updates to
authentication Cybersecurity retention and recovery authenticated code
vulnerability and of device configuration Incorporate detection
management approach by an authenticated mechanisms into device
should address Use systematic design and device features to
Utilize timed methods to privileged user
assessment of the impact procedures for increase detectability of
terminate user sessions
of threats and authorized users to attacks and permit
vulnerabilities on device Consider incident download version- forensically sound evidence
functionality and end response plans that identifiable software and capture
Employ layered
user/patients address the possibility of firmware
authorization by
differentiating privileges degraded operation and
based on the user role efficient restoration and Ensure timely software When characterizing the
Implement device recovery exploitability of a
patch availability to
features that protect vulnerability, the
correct newly
Strengthen password critical functionality, manufacturer should consider
discovered
protection by avoiding even when the device's factors such as remote
vulnerabilities
hardcoded passwords or cybersecurity has been exploitability, attack
common words compromised complexity, threat privileges,
actions required by the user,
Require user Ensure secure data exploit code maturity, and
authentication before transfer from and to the report confidence
permitting software or device (encryption)
firmware updates
Develop and provide
Security controls should information to the end user
not unreasonably hinder concerning appropriate
access to device actions to take upon detection
intended to be used of a cybersecurity event
during an emergency
situation
Manufacturers should
Provide physical locks
consider the incorporation of
on devices and ports to
design features that establish
limit access
or enhance the ability of the
device to detect and produce
forensically sound postmarket
evidence capture in the event
of an attack
89
Policies and Procedures Intended Use Vigilance Resources and Training
For the particular medical

Cybersecurity risk management Cybersecurity risk management Top management should
device being considered, the
programs should include: adopting programs should include: monitoring provide adequate and
manufacturer should
a coordinated vulnerability cybersecurity information sources for qualified personnel to perform
document the intended use
disclosure policy and practice identification and detection of the security risk management
and reasonably foreseeable
cybersecurity vulnerabilities and risk process
misuse.
Manufacturers should establish

The manufacturer should
design inputs for their device Cybersecurity risk management
document the assumed Persons performing security
related to cybersecurity, and programs should include: Maintaining
operating environment and risk management tasks need
establish a cybersecurity robust software lifecycle processes that
security architecture for which to have the knowledge and
vulnerability and management include mechanisms for monitoring
the device is designed to experience appropriate to the
approach as part of the software third party software components for
operate tasks assigned to them.
validation and risk analysis that is new vulnerabilities throughout the
required by 21 CFR 820.30(g) device's lifecycle and design V&V for
The manufacturer should software updates and patches that are
perform a needs assessment used to remediate vulnerabilities,
A commitment to maintenance is with a representative sample including OTS software
required of health delivery
organizations prior to
initiating product design
The CIS process, lifecycle and Cybersecurity risk management
performance measures must be programs should include:
well defined Manufacturers should understanding, assessing, and detecting
carefully consider the balance the presence and impact of a
between cybersecurity vulnerability
CIS policy documentation within safeguards and the usability of
the organization must be in place the device in its intended
environment of use to ensure Cybersecurity risk management
that the security controls are programs should include: establishing
CIS policies must be followed appropriate for the intended processes for vulnerability intake and
users handling
Ownership of CIS must be defined

The extent to which security Manufacturers are encouraged to
controls are needed will actively identify cybersecurity signals
depend on the device's that might affect their product, and
Communication among CIS intended use, the presence and engage with the sources that report them
designers and between design and intent of its electronic data
implementation must be effective interfaces, its intended
environment of use, the type
of cybersecurity Manufacturers should analyze possible
vulnerabilities present, the threat sources
CIS must be a priority for the
design project likelihood the vulnerability
will be exploited, and the
probable risk of patient harm Maintain business relationship with
due to a cybersecurity breach OTS software vendors to ensure timely
Develop a single cybersecurity receipt of information concerning
maintenance plan to address quality problems and recommended
compliance with the QS regulation corrective actions
Manufacturers are required to analyze

complaints, returned product, service
records, and other sources of quality
data to identify existing and potential
causes of nonconforming product or
other quality problems
90
Configuration
Verification and Validation Documentation Asset Management
Management
For a medical device that can be The manufacturer Document the assets of
Cybersecurity risk management programs
connected to an IT network, the medical should document the device. Assets may
should include: using threat modeling to
device manufacturer shall make characteristics of the include information, the
clearly define how to maintain safety and
available the purpose of the medical system that rely on user device itself, or
essential performance of a device by
device's connection to an IT network. configuration to ensure components of the
developing mitigations that protect, respond,
the security of the device (software and
and recover from the cybersecurity risk
device physical connections)
For a medical device that can be
connected to an IT network, the Technology must be For each identified asset,
The manufacturer should employ security medical device manufacturer shall adapted to system consider the impact that
testing as a means to aid in the assessment of make available the required requirements loss of confidentiality,
overall residual security risk. configuration of the IT network loss of integrity, or loss
incorporating the medical device of availability might
Device users should not
make changes without have on safety,
seeking manufacturer effectiveness, or data or
Software changes to address cybersecurity
advice and system security.
vulnerabilities must be validated before For a medical device that can be
approval and issuance. connected to an IT network, the recommendations
medical device manufacturer shall
make available the required Changes in design must Data criticality must be
characteristics for the IT network be evaluated in a system adequately specified
Clause 7.3.6 Design and development incorporating the medical device context
verification includes the following
statement: If the intended use requires that
the medical device be connected to, or have
an interface with, other medical device(s), For a medical device that can be
verification shall include confirmation that connected to an IT network, the
the design outputs meet design inputs when medical device manufacturer shall
so connected or interfaced. make available the technical
specifications of the network
connection of the medical device
Clause 7.3.7 Design and development including security specifications
validation includes the following statement:
If the intended use requires that the medical
device be connected to, or have an interface
with, other medical device(s), validation
connected to an IT network, the
shall include confirmation that the
requirements for the specified application or
make available the intended
intended use have been met when so
information flow between the medical
connected or interfaced.
device, the medical IT network and
other devices on the medical IT
network and if relevant to the key
properties, the intended routing through
the medical IT network

connected to an IT network, the
make available a list of hazardous
situations resulting from a failure of the
IT network to provide the
characteristics required to meet the
purpose of the medical device
connection to the IT network
Required CIS information must be

accessible
91
Organizational Management Risk Management
Management support is Project funding, Cybersecurity

Cybersecurity vulnerability Cybersecurity
required schedules, and staffing vulnerability and
and management approach vulnerability and
must be adequate management approach
should address identification management approach
of assets, threats, and should address should address
vulnerabilities assessment of the determination of risk
Clause 7.2.1 Determination of Requirements Related to Product likelihood of a threat levels and suitable
includes the following requirements: and a vulnerability being mitigation strategies
The organization shall determine: exploited
a) requirements specified by the customer, including the Cybersecurity vulnerability
requirements for delivery and post-delivery activities; and management approach
b) requirements not stated by the customer but necessary for should address assessment of Manufacturers should
specified or intended use, as known; residual risk and risk Cybersecurity risk define, as part of the
c) applicable regulatory requirements related to product; acceptance criteria management programs comprehensive
d) any user training needed to ensure specified performance and should include: cybersecurity risk
safe use of the medical device; deploying mitigations management, the safety
e) any additional requirements determined by the organization. that address and essential
Device manufacturers should
cybersecurity risk early performance of their
have a security risk
and prior to exploitation device, the resulting
management plan.
severity of patient harm
Clause 7.3.3 Design and Development Inputs provides the if compromised, and the
following requirements: risk acceptance criteria
The security risk
Inputs relating to product requirements shall be determined and Security risk analysis should management file should
records maintained. These inputs shall include: be performed for the medical contain, at a minimum,
a) functional, performance, usability, and safety requirements, device. This should include at the following: Security risk
according to the intended user; least the following: a) security risk management should be
b) applicable regulatory requirements and standards; a) a description and management plan maintained as a
c) applicable output(s) of risk management; identification of the medical b) security risk analysis companion process to
d) as appropriate, information derived from previous similar device that was analyzed components the safety risk
designs; b) identification of the c) security risk controls management process
e) other requirements essential for design and development of person(s) and organization
product and processes carrying out the security risk
analysis
c) scope and date of the The risk analysis should The risk analysis should
security risk analysis document potential document known and
Clause 8.5.1 provides general requirements with regard to threats and the means a potential vulnerabilities
improvements. Specifically, this clause states: threat actor might use to in the device (conscious
The organization shall identify and implement any actions exploit a vulnerability design decisions; errors
necessary to ensure and maintain the continued suitability, Manufacturers should use a in the design,
adequacy, and effectiveness of the quality management system security risk control hierarchy implementation,
as well as medical device safety and performance through the that parallels the safety The security risk manufacture, or
use of the quality policy, quality objectives, audit results, post- hierarchy presented in ISO management report configuration; design
market surveillance, analysis of data, corrective actions, 14971. should provide, either characteristic not known
preventive actions, and management review. a) Inherent security by design directly or by reference, to be a vulnerability
b) Protective measures in the the following items:
medical device itself or in the a) Risk analysis,
manufacturing process mitigations, and design The risk analysis should
c) Information for security considerations address characteristics
pertaining to of the device and its
cybersecurity risks expected operating
b) A traceability matrix environment (physical
Manufacturers should ensure of security risks to and IT)
that the risk(s) from all security controls
identified threats, c) Traceability of the
vulnerabilities, and potentially verification reports for
documented security Residual risk is re-
compromised assets have evaluated after the
been considered and the controls
d) A description of when security risk controls
implemented controls are have been applied.
comprehensive in addressing and how security
them. updates/patches will be
provided
e) A description of the The security risk control
steps taken to assure measures selected need
devices will be delivered to be implemented and
malware-free verified with the results
recorded in the security
risk management file
Figure 10. Voice of the Customer Affinity Diagram. Developed by the author using
information obtained from FDA, 2005, p. 3-5; FDA, 2013, p. 4-5; FDA, 2015; FDA,
2016, p. 13-14, 27-29; IEC, 2010, p. 17-18; ISO, 2016, p. 22-25, 34; AAMI, 2016, p. xi,
7-14; and Kraemer, Carayon, & Clem, 2009, p. 10.
92
An examination of Figure 10 suggests that additional consolidation of the
requirements was still needed in order to develop a manageable QFD matrix. Based on
this, it was necessary to further review and summarize each one into a set of succinct yet
representative customer inputs. For this task, it was decided to limit each main category
to no greater than four sub-requirements. Through this process, the essence of each
requirement was maintained while yielding a manageable list of inputs for the matrix.
Overall, a total of 38 specific voice of the customer inputs were finally realized. These
are shown in Table 13 along with their associated Affinity Diagram main categories.
Table 13
Voice of the Customer Requirements

Category VOC Requirement
Limit device access
Access and User Trust Require authentication
Physical locks on external ports
Employ fail-safe modes
Critical Functions
Use data encryption/decryption
Recover after security event
Device Recovery
Address potentially degraded operation
Authentication required for patches
Software Patches
Patches need to be timely
Detect, recognize, and log security events
Detection and Response
Inform user regarding actions to take following security event
CIS policies must be established, documented, and followed
Policies and Procedures Communication between designers is required
Incorporate cybersecurity into design inputs
Define device intended use and foreseeable misuse
Intended Use Define the use environment
Balance between intended use and security requirements
93
Table Continued
Monitor cybersecurity information sources
Maintain a robust software lifecycle process
Vigilance
Identify cybersecurity signals and work with sources
Analyze complaints, service reports, returned product
Management should provide qualified personnel
Resources and Training
Employee knowledge and experience with cybersecurity
Employ threat modeling to define safety and essential performance
Verification and Validation Validate software changes before deployment
Design V&V includes connections to external devices and networks
Document connection to IT networks (purpose, configuration,
characteristics, specifications)
Documentation
Document the information flow between device, other devices and
network
Define critical system configurations required for security
Configuration Management
Evaluate design changes in a system context
Document device assets (information, components)
Consider impact associated with loss of confidentiality, integrity,
Asset Management
availability
Consider criticality of data
Project funding, schedules, and staffing must be adequate
Organizational Management
Management support is required
Identify assets, threats, and vulnerabilities
Risk Management Develop a security risk management plan
Employ a security risk control hierarchy
Note. CIS = Computer Information Systems. Developed by the author.
A closer assessment of the resulting VOC categories suggests that they are also
fairly well aligned with the NIST Framework Five Core Functions which were previously
discussed. This alignment provides additional support for the approach taken to identify
the comprehensive set of voice of the customer inputs which were used for the study.
Table 14 provides an overview of the relationship between the VOC categories and the
Five Core Functions (see Figure 5).

94
Table 14
VOC Categories versus NIST Five Core Functions

NIST Framework Core Function VOC Category
Asset Management
Intended Use
Identify Risk Management
Organizational Management
Vigilance
Access and User Trust
Configuration Management
Documentation
Protect
Policies and Procedures
Verification and Validation
Detect Detection (and Response)
(Detection and) Response
Respond
Software Patches
Critical Functions
Recover
Device Recovery
Note. Developed by the author using information obtained from NIST Cybersecurity Framework
Categories and Subcategories. Retrieved from NIST’s website at
https://www.nist.gov/cyberframework/online-learning/components-framework
Technical Requirements Identification
With the baseline VOC requirements established, a set of technical requirements
was then derived from the essential design characteristics developed earlier in this
chapter for the fictional device. In addition, these technical requirements include basic
security measures which would typically be employed in a device of this nature. As
noted previously, this list does not necessarily include all design specifications for a
connected medical device. Rather, it is intended to illustrate one possible approach to the
development of a QFD matrix which appropriately blends user wants, functional

95
requirements, and security needs. A total of 46 specific technical requirements were
established. These are shown in Table 15.
Table 15
Technical Requirements
No. Description
1 Incorporate a robust user authentication scheme
2 Incorporate user access timeout
3 Incorporate segregation of duties relative to device user access
4 No hardcoded passwords
5 Include fail-safe mode relative to security breaches
6 Provide capability for software patches
7 Limit software patch installation to authenticated users
8 Maintain functionality and configuration following cybersecurity event
9 Device data is encrypted and decrypted using industry-standard methods
10 Monitor for and address security compromises, including evidence recording mechanism/
memory
11 Operating system is developed and managed in-house vs. COTS
12 Intended use is for diabetes patients
13 Combines insulin delivery and blood glucose sensing functions into a single, fully-
automated system
14 External to human body
15 Contains patient-applied sensors
16 Contains tubing and catheter set (disposable)
17 Infuses insulin based on patient need
18 Utilizes a single, subcutaneous infusion site located on the patient’s body
19 Delivers basal insulin based on the patient’s 24-hour glucose profile as measured by the
blood glucose sensor
20 Basal rates are modifiable by the patient manually or by the system automatically
21 Worn by patient when not in care provider location
22 Is lightweight and portable
23 Continuously monitors blood glucose levels
24 Administers precise dosage of insulin as required
25 Is directly connected to hospital network during care provider visit
26 Contains wireless interface for troubleshooting
27 Wireless connectivity interface utilizes latest Bluetooth technology
28 User credentials (passwords) automatically expire after 90 days
29 User account is disabled following five unsuccessful login attempts
30 Locked user account requires administrative access for resets
96
Table Continued
No. Description
31 Wireless capability can be disabled/enabled by user
32 Wireless interface use requires user name and password for access
33 Wireless network requires user authentication via external server
34 Generates and maintains electronic record of patient name, age, and sex
35 Generates and maintains electronic record of device functional status (e.g., operational, on
standby, unavailable)
36 Generates and maintains electronic record of historical trend data (blood glucose levels and
insulin administration)
37 Generates and maintains electronic record of patient data including battery charge level
38 Generates and maintains electronic record of patient data including device alerts (e.g.,
blood glucose too high or low, low battery)
39 Electronic records can be transmitted by the device to the care provider via the wireless
interface
40 Therapy and alert parameters can be modified by the care provider via the wireless
interface
41 Transmitted/received data is encrypted/decrypted using a recognized standard
42 External ports used for troubleshooting are disabled when not in use
43 Configuration and calibration data are stored locally on device
44 Configuration and calibration data are encrypted/decrypted using a recognized standard
45 System maintains an audit trail which is human-readable
46 System audit trail cannot be modified or deleted by user or administrative access
Note. COTS = Commercial off-the-shelf. Developed by the author using information obtained from “An
overview of insulin pumps and glucose sensors for the generalist,” by B. H. McAdams and A. A. Rizvi,
2016, Journal of Clinical Medicine, 5(1), 5.
VOC Prioritization Using the

Analytic Hierarchy Process
In order to prioritize the previously identified VOC requirements, the
aforementioned AHP method was utilized. This allowed for a structured approach to the
determination of importance levels for each of the VOC rows within the baseline QFD
matrix. Once these weighted importance rankings were calculated, it was then possible
to compare each customer requirement against each technical requirement to understand
potential tradeoffs while ensuring device integrity and availability were maintained to the
highest degree possible. The first step in this process was to relate qualitative
97
comparisons for each criterion to a numeric scale. Table 16 provides the necessary
approach. Note that the five-level scheme defined earlier was also utilized here and
expanded to cover both positive and negative preferences.
Table 16
Pair-wise Comparison Scale for AHP

Fractional Scale Decimal Scale Qualitative Preference Level
1/9 0.111 Extremely Less Important
1/7 0.143 Very Less Important
1/5 0.200 Strongly Less Important
1/3 0.333 Moderately Less Important
1 1.000 Equally Important
3 3.000 Moderately More Important
5 5.000 Strongly More Important
7 7.000 Very Important
9 9.000 Extremely More Important
Note. Developed by the author using information obtained from “How to do AHP
analysis in Excel,” by K. Bunruamkaew, 2012, University of Tsukuba, Graduate School
of Life and Environmental Sciences, Division of Spatial Information Science.
Next, a VOC comparison matrix was developed using the system denoted in
Table 16. Normalization of these matrix calculations allowed for a weight to be assigned
to each row (VOC requirement) of the QFD matrix. This information comprises Region
4 of Figure 9. The comparison matrix provides an assessment of each criterion against all
others and ranks those having a greater degree of importance with an integer value (1, 3,
5, 7, or 9 in this case). Comparisons having a lower degree of importance relative to the
one being assessed are ranked with the reciprocal of these same integer values. Figure 11
provides an example of the initial comparison valuation process as well as the
mathematics utilized for normalization and overall priority determination. This process
was used for each of the VOC requirements.

98
Figure 11. Mathematics for VOC Prioritization Using AHP. Developed by the author.
99
Technical Requirement Interrelationships
In order to compare the prioritized VOC requirements against the prioritized
technical requirements, the symbols and rational values defined within Table 7 were
utilized. However, for the technical requirement interrelationships, which are typically
observed as the roof of the House of Quality (Region 3 of Figure 9), the qualitative
ranking scheme illustrated in Table 17 was utilized instead. This process helped to reveal
apparent design tradeoffs (e.g., one technical requirement can influence another in a
negative or positive manner) when considering one design feature over another while
simultaneously attempting to maximize device integrity and availability.
Table 17
Five-level Ranking Scheme (Technical Requirement Interrelationships)

Qualitative Description Symbol Symbol Description
Strong Negative Concentric Circles
Negative Minus Sign
Positive Plus Sign
Strong Positive Plus Within Circle
Very Strong Positive Concentric Squares
Note. Developed by the author.
Due to the large number of technical requirements associated with the baseline
QFD matrix, it was necessary to employ an alternative approach to the more traditional
roof concept. Figure 12 illustrates the use of a Technical Requirement Interrelationships
Table which associates pairs of numbered requirements with each other under each of the
five ranking values denoted in Table 17.

100
Figure 12. Use of Technical Requirement Interrelationship Table. Developed by the

author.
101
Technical Requirement Prioritization
To determine the overall priority level for each of the technical requirements
(Region 7 of Figure 9), the technique illustrated in Figure 13 was utilized. As previously
discussed, many applications of QFD rely upon the use of ordinal values assigned to the
priority of each VOC requirement as well as each relationship between these and the
technical requirements. In this application, however, rational values were used for both.
The overall mathematical operations of multiplication and summation remain unchanged.
The process for obtaining a final design requirement priority for each of the elements in
Table 15 took into consideration both the relative importance of the VOC inputs and their
relationship to each design criterion. Since the primary goal of the QFD matrix was to
adequately assess the importance of security along with other requirements (from a
customer perspective) on the final design decisions to be made, the application of ranking
values was made with due consideration of device integrity and availability. The
resulting numerical value calculated for each technical requirement (e.g., 1.985 for the
column illustrated in Figure 13), is intended to reflect its relative importance in
developing the next House of Quality (see Figure 8).

102
Figure 13. Methodology for Technical Priority Determination. Developed by the author.
103
Research Questionnaire Development
The qualitative data questionnaire utilized for this study was intended to solicit
additional research information related to current and future techniques and perceived
challenges associated with implementing connected medical device security
requirements. Five central focus areas were included within the survey, based on the
research completed in previous chapters of the thesis (Regulations and Guidance
Documents, International Standards, Risk Management Techniques, Human Factors
Engineering, and Software/Hardware Design and Development). The primary goal of
gathering this data was to incorporate the knowledge and experiences of several
individuals across a number of disciplines into the VOC process through augmentation of
the original literature review requirements. Participants were instructed to provide as
much detail as possible for each response but to not reveal any specific devices or any
proprietary information associated with a specific device or family of devices. The
questionnaire template developed for the study is provided in the Appendix.
PDSA Do Phase
The Do phase of the PDSA cycle encompassed initial construction of the baseline
QFD matrix using the customer and technical requirements information obtained during
the planning phase. Formal use of the AHP technique for establishing priority levels
between the large quantity of initial voice of the customer requirements provided a higher
degree of judgement consistency over more traditional methods. Determination of
technical requirement interrelationships helped to reveal key design considerations

104
associated with the integration of security concerns into other design criteria. With the
initial matrix in place, it was then possible to further analyze potential design tradeoffs
made in the interest of device security (with an emphasis on device integrity and
availability, as previously noted). The result of this assessment was the overall
prioritization of device technical requirements relative to meeting customer needs for
cybersecurity robustness. Using this data, it was then possible to determine which
concepts should be carried through the remaining Houses of Quality. Finally, as a first
step toward enhancing the baseline matrix, the aforementioned research questionnaire
was administered to selected participants and the resulting data was reviewed during this
phase.
Questionnaire Administration and

Follow-up Discussions
The questionnaire in the Appendix was administered via email to a total of 24
recipients, representing a cross-section of several technical disciplines, including:
software development, risk management, cybersecurity management, technical sales,
standards management, information technology and systems engineering. Nine
individuals provided responses. Participation was obtained from two device
manufacturers as well as one independent consultant working within the medical device
space. The resulting data was collected and analyzed to identify any additional voice of
the customer inputs which were not previously included within the baseline VOC data.
Follow-up discussions were then held with participants to clarify responses, when
required.
105
PDSA Study Phase
During the Study phase of the PDSA cycle, the supplemental information
obtained from the cybersecurity questionnaires was analyzed in more detail to identify
potential voice of the customer inputs and new ideas which may have been overlooked
during development of the baseline matrix. As previously noted, follow-up discussions
were also held with stakeholders, as required, to clarify key points from the
questionnaire. The additional data obtained from these interactions was prioritized and
prepared for incorporation into an updated QFD matrix. The primary reason for
obtaining additional data in this manner was to illustrate the importance of continuous
improvement relative to the dynamic nature of medical device security management. In
addition to subject matter expert feedback, it would also be advisable in this context to
incorporate customer complaint data, field performance metrics, and other relevant forms
of input into the design process.
PDSA Act Phase
Finally, during the Act phase of the PDSA cycle, the prioritized stakeholder
information was leveraged to develop a second iteration of the QFD matrix. The same
process steps which were previously used were also incorporated here. The advantages
and disadvantages of combining voice of the customer data from the literature review
with the subject matter expert data was also explored and comparisons were made
between the design priorities obtained initially and those obtained with the additional
customer inputs. In addition, other techniques were briefly discussed in order to illustrate
106
potential alternatives to the House of Quality method used in this study. This phase
culminated by reviewing the final QFD matrix with selected stakeholders in order to
understand its perceived value as a scalable tool for the consistent identification,
selection, and prioritization of medical device cybersecurity design requirements.
Summary
This chapter served to define the key objectives of the study, primarily in terms of
the Plan phase of the PDSA cycle. A fictional medical device was envisioned in order to
illustrate the process of gathering, organizing, and managing cybersecurity design
requirements using QFD techniques over more traditionally used methods which were
identified and discussed in Chapters 1 and 2. A modern set of quality techniques was
selected to augment the Quality Function Deployment process in order to improve the
overall management of the numerous data points required for the study. These
techniques included the use of rational comparison scales, an Affinity Diagram, and the
Analytic Hierarchy Process. The methods used for development of a stakeholder
questionnaire were also discussed and preliminary results were reviewed. Finally, the
remaining phases of the PDSA cycle were outlined and will be further explored in the
remaining chapters. Figure 14 illustrates the complete PDSA cycle utilized for the study.
107
PLAN
- Develop fictional medical device

design characteristics
- Identify baseline customer requirements
- Identify baseline technical requirements
- Develop stakeholder questionnaire
- Define process for baseline QFD
matrix development
- Construct baseline QFD Matrix

- Augment baseline QFD matrix - Deliver stakeholder questionnaire
- Review final QFD matrix - Understand design tradeoffs for
ACT with stakeholders cybersecurity (integrity and availability) DO
- Identify areas for future improvement - Identify key design considerations
- Determine next PDSA iteration(s) (priorities) for translation into
additional QFD matrices
- Analyze and present stakeholder

questionnaire data
- Complete follow-up discussions to clarify
key points (as required)
- Determine method for incorporation of
additional VOC data into QFD matrix
STUDY
Figure 14. PDSA Cycle Utilized for Cybersecurity QFD Matrix Development.
Developed by the author.
108
CHAPTER 4
RESULTS AND DISCUSSION
Overview
In this chapter, the baseline QFD matrix is presented as the first iteration of the
PDSA Do phase. Analysis of the resulting technical requirement priorities was also
completed, as was a discussion of next steps regarding the additional Houses of Quality
which would normally be developed for a real medical device. Further evaluation of the
information received through the stakeholder survey process was undertaken as part of
the Study phase. This included any participant follow-up discussions which were
required to clarify key points of interest within the data. This phase concluded with a
determination of which information provided additional value to the baseline QFD matrix
and could therefore be incorporated into the next iteration. The Act phase was used
primarily to revise the baseline matrix with these additional customer requirement inputs
and to discuss its overall merits with members of the stakeholder group. Additionally,
future improvement ideas were reviewed and subsequent PDSA iterations were briefly
investigated and discussed. As previously observed, the intended outcome of this study
was to understand if the application of PDSA and QFD to the management of medical
device security requirements represents a viable alternative to other methods currently
being employed throughout industry.

109
Initial (Baseline) Quality Function

Deployment Matrix
Determination of VOC Priorities
Under the Do phase, the basic House of Quality matrix structure (Region 5 of
Figure 9) was developed with the VOC data comprising the rows and the Technical data
forming the columns. The AHP technique was then applied, such that each VOC
requirement row within the matrix was successively compared to (and ranked against) all
others in terms of overall preference. Collectively, the resulting pairwise comparisons
generated in this manner formed an initial comparison matrix for each of the 38 design
inputs (i.e., 38 x 38 = 1444 distinct preference values). This is illustrated in Figure 15.
The highlighted values along the diagonal in this figure are equal to one (i.e., Equally
Important) since each requirement is effectively being compared to itself at these
locations. In addition, values on opposite sides (i.e., mirror images) of this diagonal will
always be reciprocals of one another (see Figure 11 for details). Note that the entire
process was completed from the perspective of maintaining patient safety in terms of
ensuring device integrity and availability, as previously discussed. Confidentiality
concerns received less consideration. In this way, preferences were ranked higher for
requirements associated with security functions such as maintaining device usability
following a cyber event and for the inclusion of fail-safe modes of operation. Once these
initial priority (raw) values were obtained, it was then possible to complete the
normalization process and arrive at a final priority level for each of the inputs. The
normalized matrix is shown as Figure 16.

110
111
112
Figure 15. Initial VOC AHP Comparison Matrix. Developed by the author.
113
114
115
Figure 16. Normalized AHP Comparison Matrix with VOC Priorities. Developed by the
author.
116
The Average column in Figure 16 represents the final priority level assigned to each of
the 38 voice of the customer requirements (rows). Table 18 provides the final priority
level obtained for each voice of the customer requirement, listed in descending order of
importance (Region 4 of Figure 9).
Table 18
Prioritized VOC Requirements

Category VOC Requirement Priority
Critical Functions Employ fail-safe modes 0.09713
Device Recovery Recover after security event 0.06771
Device Recovery Address potentially degraded operation 0.06359
Intended Use Balance between intended use and security 0.04978
requirements
Asset Management Consider impact associated with loss of 0.04686
confidentiality, integrity, availability
Asset Management Consider criticality of data 0.04520
Critical Functions Use data encryption/decryption 0.04511
Risk Management Identify assets, threats, and vulnerabilities 0.03867
Asset Management Document device assets (information, components) 0.03611
Configuration Management Define critical system configurations required for 0.03377
security
Policies and Procedures Incorporate cybersecurity into design inputs 0.03311
Intended Use Define device intended use and foreseeable misuse 0.03131
Intended Use Define the use environment 0.03131
Verification and Validation Validate software changes before deployment 0.02736
Risk Management Develop a security risk management plan 0.02604
Configuration Management Evaluate design changes in a system context 0.02182
Access and User Trust Require authentication 0.02013
Risk Management Employ a security risk control hierarchy 0.01960
Verification and Validation Design V&V includes connections to external devices 0.01852
and networks
Detection and Response Inform user regarding actions to take following 0.01834
security event
Verification and Validation Employ threat modeling to define safety and essential 0.01778
performance
Documentation Document connection to IT networks (purpose, 0.01750
configuration, characteristics, specifications)
117
Table Continued
Documentation Document the information flow between device, other 0.01750
devices and network
Vigilance Monitor cybersecurity information sources 0.01670
Detection and Response Detect , recognize, and log security events 0.01645
Access and User Trust Limit device access 0.01466
Vigilance Identify cybersecurity signals and work with sources 0.01386
Vigilance Analyze complaints, service reports, returned product 0.01386
Vigilance Maintain a robust software lifecycle process 0.01275
Software Patches Authentication required for patches 0.01182
Organizational Management Project funding, schedules, and staffing must be 0.01172
adequate
Organizational Management Management support is required 0.01172
Policies and Procedures Communication between designers is required 0.01056
Resources and Training Employee knowledge and experience with 0.01036
cybersecurity
Resources and Training Management should provide qualified personnel 0.00955
Policies and Procedures CIS policies must be established, documented, and 0.00867
followed
Access and User Trust Physical locks on external ports 0.00724
Software Patches Patches need to be timely 0.00581
Note. CIS = Computer Information Systems; Priority sorting was completed to four significant figures as
shown. Subsequent calculations utilize two significant figures. Developed by the author.
As anticipated, higher priority levels were assigned to those requirements aimed
at ensuring overall patient safety in the event of a cybersecurity attack. Examples include
providing a fail-safe mode (Critical Functions), recovering after an event (Device
Recovery), providing a means for addressing degraded device operation (Device
Recovery), maintaining an appropriate balance between intended use and security
(Intended Use), and the use of data encryption and decryption techniques (Critical
Functions) as part of the design. While still important elements of the design process for
the fictional device, lower preferences were assigned to items such as documentation of
118
connections between the device and IT networks and for the flow of information between
devices. If, for example, confidentiality concerns were also being considered here, the
prioritization results would undoubtedly reflect a tendency towards these aspects of the
design as well. It is also important to note that several customer requirements which may
have ranked lower in priority at this first stage of the QFD process could become more
important when applied to future Houses of Quality where process operations and
manufacturing requirements are being determined (see Figure 8). Examples include
those under the categories of Policies and Procedures, Organizational Management, and
Resources and Training. While other prioritization methods may have been successively
implemented here, the application of AHP to such a large number of customer inputs
resulted in a logical, consistent, and repeatable process for obtaining quantitative
preference levels.
With the VOC requirements prioritized, the technical requirements were then
examined to identify potential interrelationships. These are illustrated in Table 19
(Region 3 of Figure 9). As discussed in Chapter 3, the alternate method of using a table
to illustrate these relationships was employed here due primarily to spatial limitations
imposed by the large number of technical requirements. Typically, the interrelationships
would be illustrated graphically as a roof structure directly above the main portion of the
House of Quality.
119
Table 19

Very
Strong Strong
Negative Positive Strong
No. Design Requirements Negative Positive
Positive
1 Incorporate a robust user 2, 3, 28, 7, 4, 32,

authentication scheme 29 33
2 Incorporate user access 20 1
timeout
3 Incorporate segregation of 1, 30 30, 46 7
duties relative to device
user access
4 No hardcoded passwords 25 1
5 Include fail-safe mode 43 8
relative to security
breaches
6 Provide capability for 7 11
software patches
7 Limit software patch 6 1 3
installation to
authenticated users
8 Maintain functionality and 43 10 5
configuration following
cybersecurity event
9 Device data is encrypted 41, 44
and decrypted using
industry-standard methods
10 Monitor for and address 8, 45
security compromises,
including evidence
recording
mechanism/memory
11 Operating system is 6
developed and managed
in-house vs. COTS
12 Intended use is for 13
diabetes patients
13 Combines insulin delivery 22 12, 15
and blood glucose sensing
functions into a single,
fully-automated system
14 External to human body 21
120
Table Continued
Very
Strong Strong
Positive
15 Contains patient-applied 13, 17, 19 23

sensors
16 Contains tubing and 22 18
catheter set (disposable)
17 Infuses insulin based on 15 24
patient need
18 Utilizes a single, 16
subcutaneous infusion site
located on the patient’s
body
19 Delivers basal insulin 20 15
based on the patient’s 24-
hour glucose profile as
measured by the blood
glucose sensor
20 Basal rates are modifiable 2, 19, 28, 40
by the patient manually or 29, 30
by the system
automatically
21 Worn by patient when not 14, 22
in care provider location
22 Is lightweight and portable 13, 16 21
23 Continuously monitors 24 15
blood glucose levels
24 Administers precise 23 17
dosage of insulin as
required
25 Is directly connected to 4, 31, 32,
hospital network during 33
care provider visit
26 Contains wireless interface 27, 33, 39
for troubleshooting
27 Wireless connectivity 26, 33, 39
interface utilizes latest
Bluetooth technology
28 User credentials 20 1
(passwords) automatically
expire after 90 days
121
Table Continued
Very
Strong Strong
Positive
29 User account is disabled 20 1, 30

following five
unsuccessful login
attempts
30 Locked user account 20, 31 3, 29 3

requires administrative
access for resets
31 Wireless capability can be 25, 39 30 `
disabled/enabled by user
32 Wireless interface use 25 1
requires user name and
password for access
33 Wireless network requires 25 26, 27, 39 1
user authentication via
external server
34 Generates and maintains 35
electronic record of patient
name, age, and sex
35 Generates and maintains 34, 36
electronic record of device
functional status (e.g.,
operational, on standby,
unavailable)

electronic record of
historical trend data (blood
glucose levels and insulin
administration)
data including battery
charge level
122
Table Continued
Very
Strong Strong
Positive
38 Generates and maintains 37

data including device
alerts (e.g., blood glucose
too high or low, low
battery)
39 Electronic records can be 31 26, 27, 33, 41
transmitted by the device 40
to the care provider via the
wireless interface
40 Therapy and alert 39 20
parameters can be
modified by the care
provider via the wireless
interface
41 Transmitted/received data 9, 44 39
is encrypted/decrypted
using a recognized
standard
42 External ports used for
troubleshooting are
disabled when not in use
43 Configuration and 5, 8 44
calibration data are stored
locally on device
44 Configuration and 9, 41 43
calibration data are
encrypted/decrypted using
a recognized standard
45 System maintains an audit 10

trail which is human-
readable
46 System audit trail cannot 3
be modified or deleted by
user or administrative
access
Note. COTS = Commercial off-the-shelf. Developed by the author.
123
A review of the interrelationships reveals some interesting details. A strong
negative (i.e., conflicting) relationship exists between several of the requirements. For
example, requirement 4, “No Hardcoded Passwords,” conflicts with the desire to have the
device connected to the hospital network during a care provider visit (requirement 25)
since some level of user interaction would be required to allow for this connection in the
absence of a hardcoded password. Similarly, the local storage of configuration and
calibration data in requirement 43 may pose additional design challenges around meeting
the desire to employ a fail-safe mode when a security event occurs (requirement 5). In
this case, the data may be compromised in a manner that would hinder the availability of
such a mode. In a similar fashion, requirement 8 also conflicts with 43 since maintaining
the device’s functionality and configuration may be difficult if the associated data were
lost or corrupted during a cyber-event. There are also several very strong positive (i.e.,
highly complementary) relationships between the technical requirements. Examples
include requirements 3 and 7 as well as requirements 5 and 8. In the former case,
limiting software patch installation to authenticated users is a direct application of the
segregation of duties principle. In the latter case, maintaining device functionality and
configuration is directly aligned with the goal of having a fail-safe mode of operation in
the event of security event.
What is clear from this process is the benefit to be gained from understanding
how the technical requirements complement each other in some instances and potentially
conflict in others. This applies not only to security considerations but also to how these
might impact functional aspects of the design. For example, a negative relationship is
124
observed to exist between the functional need for infusion rates to be user-modifiable
(requirement 20) and the security need to incorporate user access timeouts (requirement
2). While other methods of assessment surely exist for understanding these design
tradeoffs, the QFD process of examining technical requirement interrelationships
provides a straightforward graphical method which is easily communicated and
understood.
Comparison of VOC and Technical

Requirements
The next step in development of the baseline House of Quality was to compare
each of the prioritized voice of the customer requirements to each of the technical
requirements using the symbols and rational values assigned previously in Table 7. The
results of this comparison are illustrated in Figure 17. VOC requirements which
correspond directly with a technical requirement were qualitatively ranked as extremely
strong (filled square in Figure 17). One example of this is the comparison between the
VOC requirement of “Detect, recognize, and log security events” and the technical
requirement of “Monitor for and address security compromises, including evidence
recording mechanism/memory.” Conversely, those requirements observed to have only a
limited influence on each other were ranked as weak (unfilled triangle in Figure 17). An
example of this is the comparison between the VOC requirement of “Identify assets,
threats, and vulnerabilities” and the technical requirement of “System maintains an audit
trail which is human-readable.” As previously discussed, several of the VOC and
technical requirements did not reveal a corresponding relationship at this level.

125
126
127
128
129
130
Figure 17. Customer and Technical Requirements Comparison. Developed by the

author.
131
Examples include the VOC requirements associated with Resources and Training,
Verification and Validation, and Organizational Management. Similarly, the technical
requirement of “Is lightweight and portable” did not have any perceived relationship to
the VOC requirements. As the QFD process is carried forward into the development of
successive Houses of Quality, many of these requirements will become increasingly
important considerations, especially as process operations and manufacturing
requirements are identified.
Determination of Technical Requirement

Priorities
The remaining step in development of the initial House of Quality was the
determination of the technical requirement priorities. This was accomplished using the
process discussed in Chapter 3 (see Figure 13 for details). The final list of technical
priorities, displayed in descending order of importance is shown in Table 20 (Region 7 of
Figure 9). From this list it is clear that maintaining system functionality in light of a
security event is of prime importance when considering device integrity and availability.
This list provides a convenient method for determining which technical requirements to
include in subsequent steps of the design process and allows for any underlying
assumptions made during its generation to be challenged. This flexibility is one of the
primary benefits of using the QFD method to manage security-specific design
requirements over the entire lifecycle of a connected medical device.

132
Table 20
Technical Requirement Priorities

No. Description Priority
8 Maintain functionality and configuration following cybersecurity event 16.449
5 Include fail-safe mode relative to security breaches 15.295
44 Configuration and calibration data are encrypted/decrypted using a recognized 7.908
standard
10 Monitor for and address security compromises, including evidence recording 6.970
mechanism/memory
9 Device data is encrypted and decrypted using industry-standard methods 6.147
41 Transmitted/received data is encrypted/decrypted using a recognized standard 5.499
13 Combines insulin delivery and blood glucose sensing functions into a single, 3.100
fully-automated system
19 Delivers basal insulin based on the patient’s 24-hour glucose profile as 3.100
measured by the blood glucose sensor
43 Configuration and calibration data are stored locally on device 2.516
45 System maintains an audit trail which is human-readable 2.218
7 Limit software patch installation to authenticated users 1.985
35 Generates and maintains electronic record of device functional status (e.g., 1.865
operational, on standby, unavailable)
36 Generates and maintains electronic record of historical trend data (blood 1.865
glucose levels and insulin administration)
37 Generates and maintains electronic record of patient data including battery 1.865
charge level
38 Generates and maintains electronic record of patient data including device 1.865
alerts (e.g., blood glucose too high or low, low battery)
34 Generates and maintains electronic record of patient name, age, and sex 1.865
12 Intended use is for diabetes patients 1.606
33 Wireless network requires user authentication via external server 1.363
1 Incorporate a robust user authentication scheme 1.239
29 User account is disabled following five unsuccessful login attempts 1.039
28 User credentials (passwords) automatically expire after 90 days 1.039
6 Provide capability for software patches 0.962
46 System audit trail cannot be modified or deleted by user or administrative 0.932
access
3 Incorporate segregation of duties relative to device user access 0.746
30 Locked user account requires administrative access for resets 0.663
42 External ports used for troubleshooting are disabled when not in use 0.662
14 External to human body 0.632
21 Worn by patient when not in care provider location 0.632
32 Wireless interface use requires user name and password for access 0.597
133
Table Continued
27 Wireless connectivity interface utilizes latest Bluetooth technology 0.486
39 Electronic records can be transmitted by the device to the care provider via the 0.481
wireless interface
25 Is directly connected to hospital network during care provider visit 0.457
24 Administers precise dosage of insulin as required 0.419
23 Continuously monitors blood glucose levels 0.419
17 Infuses insulin based on patient need 0.419
18 Utilizes a single, subcutaneous infusion site located on the patient’s body 0.419
2 Incorporate user access timeout 0.401
31 Wireless capability can be disabled/enabled by user 0.327
26 Contains wireless interface for troubleshooting 0.243
40 Therapy and alert parameters can be modified by the care provider via the 0.228
wireless interface
20 Basal rates are modifiable by the patient manually or by the system 0.214
automatically
15 Contains patient-applied sensors 0.214
16 Contains tubing and catheter set (disposable) 0.214
11 Operating system is developed and managed in-house vs. COTS 0.176
4 No hardcoded passwords 0.138
22 Is lightweight and portable 0.000
Analysis of Research Questionnaire Data
Response Rate and General Demographics
With the baseline QFD matrix completed and the technical requirement priorities
identified, the research questionnaire was examined under the Study phase. As noted in
Chapter 3, the questionnaire was administered via email to a total of 24 potential
candidates, representing a cross-section of several technical disciplines. Included among
these were: software development, risk management, cybersecurity management,
technical sales, standards management, information technology and systems engineering.
Nine individuals (38% overall response rate) from two device manufacturers and one
134
independent consulting firm within the medical device industry provided responses.
Potential reasons for the low response rate include concerns over confidentiality of the
disclosed information, the sensitive nature of the cybersecurity topic in general, and the
proprietary nature of currently employed cybersecurity methods and individual
experiences. The original approach to managing the data associated with the
questionnaire and with potential follow-up discussions was to employ some level of text
analytics to derive important features and trends. However, given the limited response
rate, simple qualitative data analysis was used instead. Table 21 provides an overview of
the participant demographics. Although the questionnaire participation rate was lower
than desired, the scope of professions responding included a good cross section covering
the five specific areas of risk management, systems engineering, cybersecurity expertise,
quality engineering, and information technology. In addition, a wide range of experience
levels was observed and a significant amount of useful information was obtained.
Table 21
Cybersecurity Questionnaire Demographics Overview

Organizational Years of
Profession Areas of Involvement
Focus Experience
Medical Device Risk Management Security risk management 1 to 3

Design/Manufacturing Engineer (pre and post-market)
Medical Device Systems Engineer Perform security risk 1 to 3

Design/Manufacturing assessments
Medical Device Cybersecurity Other (No details provided) 4 to 6

Design/Manufacturing Professional
135
Table Continued
Organizational Years of
Profession Areas of Involvement
Focus Experience
Medical Device Cybersecurity Maintain the performance 7 to 10

Design/Manufacturing Professional and oversee the security of
(software quality) one or more types of
connected medical devices
Design software for

connected medical devices
Medical Device Information Design software for 7 to 10

Design/Manufacturing Technology Specialist connected medical devices
Medical Device Design Quality Facilitate security risk 11 to 15

Design/Manufacturing (for hosted web assessments for medical
and desk top device products and
applications) identify security
requirements for products
that are later verified.
Informatics SW Sales Informatics Sales Recommend the purchase 16 to 20

- Technical Sales Specialist of connected medical
devices
Medical Device Quality Engineer Involvement in processes 16 to 20

Design/Manufacturing (focused on associated with the
standards) development of a connected
medical device
(development includes all
aspects since my role is
focused on standards)
Independent Information Computer Systems More than

Consultant Technology Specialist Validation 20
Note. Developed by the author.
136
Principal Outcomes and Follow-up

Discussions
The central focus of the research questionnaire was solicitation of information
related to each participant’s experiences and thoughts regarding current and future design
considerations relative to device security management. The questions were organized
around the five cybersecurity focus areas discussed previously:
 Regulations and Guidance Documents
 International Standards
 Risk Management Techniques
 Human Factors Engineering
 Software and/or Hardware Design and Development Methods
Analysis of the responses to these questions revealed a number of interesting takeaways.
In several instances the received information was somewhat unclear in terms of its
content, scope, or applicability to the subject matter. To mitigate this situation, follow-up
discussions were held with several of the participants in order to remove any ambiguity in
the data they had provided. Table 22 provides and overview of the principal outcomes
from the questionnaire exercise. In addition to confirming many of the concepts
discussed in the first two chapters of the thesis, the data revealed a reliance on trade
organizations for up-to-date security information and the use of common security risk
rating tools. Training was observed to be a common deficiency as was the concern over
management of both legacy and third-party software. Finally, there was a consensus that
too many standards currently exist and that there is no clear path for designers the follow.
137
Table 22
Principal Outcomes from Cybersecurity Questionnaire

Question Responses
11. Device Cybersecurity Customers Customers

Experience is often typically have want to be
dependent on no access to assured that
what the the device manufacturers
customer has software so have a
purchased they are reliant lifecycle
upon the program in
manufacturer place and are
to provide following a
support standard
14. Risk Software Cybersecurity Cyber signals Risks are rated

Management vulnerability team meets are obtained using OWASP
Experience scans are regularly to through and CVSS
regularly understand organizations systems
performed new risks (can like MITA and (threat and
using be technical ADVAMED vulnerability
NESSUS, and/or likelihood)
which is business-
updated daily oriented)
15. Human Need to HFE is used to HFE is used to Need to

Factors consider determine if ensure that understand
Engineering “insider security security how use
Experience attacks” and controls controls do not environment
how requiring impact the can impact
customers are customer device’s system access,
going to use interactions workflow data exposure
the system are effective This often
drives
interface
specifications
and labeling
decisions
16. Software NIST SOUP is a Encryption Need to

and Hardware Cybersecurity significant keys are used understand
Design framework is concern (e.g., for data at rest security
Experience utilized 3rd party and in transit. mechanisms
applications Strong associated
like JAVA, passwords and with supplied
POSTGRES, policies are components
operating leveraged and
systems) subassemblies
138
Table Continued
Question Responses
17. Future Should be Need greater Ability for Need Frequency of

Regulations performing flexibility in customers to additional SOUP
and Guidance reviews of administration interact with guidance on evaluation for
Documents internal medical device data criticality changes needs
requirements device software is levels to be
against software limited by considered.
changes in FDA rules Need a way to FDA is
standards and More local identify “tiers” currently
regulations responsibility of data to silent on how
(two-year for better identify to address
interval administration risk levels legacy
suggested) of third-party software
software security
More
guidelines and
training
programs for
OEMs
18. Future Suggest more There are too Would like to Address risks
International documented many see AAMI on a periodic
Standards evidence to standards in TIR57 move basis and track
confirm use at this from a trends
device time. Need a technical associated
security. way to information with cyber
harmonize report to an risks
these international
standard
139
Table Continued
Question Responses
19. Future Customer The most Security Should create a Current

Risk questionnaires popular assessment comprehensive CVSS
Management need to be cybersecurity programs need cybersecurity scoring
Standards constructed risk to be document that system is not
with more assessment “tunable” to customers could specific to
specificity methodologies vendors, review software use
relative to focus on vendor
product and network products, and Should have a Would like to
risk potential security, not services database to see better
necessarily the address adoption of
device itself Assessments frequently the CVSS
need to be asked questions scoring
more balanced across entire
with risk industry
potential
20. Future Need to Guidance
Human involve the documents
Factors HFE should provide
organization information
early on in the on
design process establishing
to identify probabilities
cybersecurity of risk based
issues that on use
could arise environment,
user
expectations,
and user
training
21. Future Use of agile Need to Need to Early

Hardware and software include consider how identification of
Software development security to manage product and
methodologies training for SOUP as this software
to allow a software is an area requirements is
focus on developers which is often keys to
enabling overlooked controlling cost
cybersecurity until late in and compliance
features early the design
process
140
Table Continued
Question Responses
22. Future Cybersecurity Develop Ensure Security needs Ensure

Design and needs to be medical developers are to make its unauthorized
Development more of a devices in trained on the way into device
shared such a way latest design communication
responsibility that allows cybersecurity requirements is stopped and
between the more local techniques (should be logged
device control of (e.g., SQL built in from
designer and detection and injection, use the beginning) Verify third-
the user remediation of data access party suppliers
for layers, etc.) are reputable
cybersecurity and maintain
issues their software
23. Additional Training for Ensure a solid Faster ways to All medical Continue to
Ideas service post market develop and devices should validate that
engineering to surveillance deploy be connected the intended
ensure they plan is in updates and to the use of the
know how to place that patches manufacturer’s interface and
handle a addresses remote content of the
security security and connectivity interface's data
breach provides a solution hasn't changed
(provide a consistent (allows for
consistent message to easier
message to customers monitoring
customers) and
management
all device
activities)
24. Additional There is not What can Greater Need to Would like to
Thoughts enough focus often be education of identify see a set of
on vendor overlooked is the industry as security standards
training. port security a whole is requirements leading to a
(e.g., USB needed at the product cyber
ports). level so they certification
can be fulfilled
and traced to
hardware and
software
Note. MITA = Medical Imaging and Technology Alliance; ADVAMED = Advanced Medical Technology
Association; OWASP = Open Web Application Security Project; CVSS = Common Vulnerability Scoring
System; NESSUS = a proprietary vulnerability scanner; SOUP = Software of Unknown Provenance; SQL
= Structured Query Language; USB = Universal Serial Bus; HFE = Human Factors Engineering; NIST =
National Institute of Standards and Technology; JAVA = a compiled programming language; POSTGRES
= an open source object-relational database management system; OEM = Original Equipment
Manufacturer. Developed by the author.
141
Incorporation of Questionnaire Data into

Revised QFD Matrix
Identification of Additional VOC

Requirements
As anticipated, the stakeholder data also revealed several new voice of the
customer requirements which were not previously identified during the literature search.
The following 12 new requirements were selected from the data within Table 22.
 Consider potential for “insider attacks”
 Allow more local control of detection and remediation for cybersecurity issues
 Periodically review internal requirements against changes in standards and

regulations
 Verify third-party suppliers are reputable and maintain their software
 Use HFE to ensure security controls do not impact the device’s workflow
 Understand how use environment can impact system access and data exposure
 Hold cyber response training for service personnel with emphasis on providing a
consistent message to customers
 Include SOUP change evaluation during periodic reviews
 Employ data access layers to protect against SQL injection
 Ensure HFE is involved as early as possible in design activities
 Utilize OWASP and/or CVSS risk rating systems
 Hold regular cybersecurity meetings to review and address risks
By comparing these 12 to the original requirements listed in Table 13, it was possible to
associate each with one of the primary categories developed through the Affinity
142
Diagramming process (see Figure 10). Table 23 provides the complete listing of all 50
VOC requirements, which will be used during the Act phase to construct the next
iteration of the baseline QFD matrix. Since there were no additional technical
requirements generated through the stakeholder questionnaire process, the
interrelationships developed for the baseline matrix remained unchanged for the updated
matrix.
Table 23
Revised Voice of the Customer Requirements by Category

Limit device access
Require authentication
Access and User Trust
Physical locks on external ports
Consider potential for “insider attacks”
Employ fail-safe modes
Critical Functions
Use data encryption/decryption
Recover after security event
Device Recovery
Address potentially degraded operation
Authentication required for patches
Software Patches
Patches need to be timely
Detect, recognize, and log security events
Inform user regarding actions to take following security event
Detection and Response
Allow more local control of detection and remediation for
cybersecurity issues
CIS policies must be established, documented, and followed
Communication between designers is required
Incorporate cybersecurity into design inputs
Policies and Procedures
Periodically review internal requirements against changes in
standards and regulations
Verify third-party suppliers are reputable and maintain their software
143
Table Continued
Define device intended use and foreseeable misuse
Define the use environment
Balance between intended use and security requirements
Intended Use Use HFE to ensure security controls do not impact the device’s
workflow
Understand how use environment can impact system access and data
exposure
Monitor cybersecurity information sources
Maintain a robust software lifecycle process
Vigilance
Identify cybersecurity signals and work with sources
Analyze complaints, service reports, returned product
Management should provide qualified personnel
Employee knowledge and experience with cybersecurity
Hold cyber response training for service personnel with emphasis on
providing a consistent message to customers
Employ threat modeling to define safety and essential performance
Verification and Validation Validate software changes before deployment
Design V&V includes connections to external devices and networks
Document connection to IT networks (purpose, configuration,
characteristics, specifications)
Documentation
Document the information flow between device, other devices, and
network
Define critical system configurations required for security
Configuration Management Evaluate design changes in a system context
Include SOUP change evaluation during periodic reviews
Document device assets (information, components)
Consider impact associated with loss of confidentiality, integrity,
Asset Management availability
Consider criticality of data
Employ data access layers to protect against SQL injection
Project funding, schedules, and staffing must be adequate
Organizational Management Management support is required
Ensure HFE is involved as early as possible in design activities
Identify assets, threats, and vulnerabilities
Develop a security risk management plan
Risk Management Employ a security risk control hierarchy
Utilize OWASP and/or CVSS risk rating systems
Hold regular cybersecurity meetings to review and address risks
Note. CIS = Computer Information Systems; SOUP = Software of Unknown Provenance; OWASP = Open
Web Application Security Project; CVSS = Common Vulnerability Scoring System; SQL = Structured
Query Language; HFE = Human Factors Engineering; Additional requirements obtained through
stakeholder data analysis are shown in italics. Developed by the author.
144
Re-evaluation of VOC Priorities
Under the Act phase, the baseline House of Quality matrix was revised to include
the new VOC data obtained from the stakeholder questionnaire. These requirements
were integrated into the existing rows of the matrix. The AHP process was repeated so
that each new VOC requirement row within the matrix was successively compared to
(and ranked against) all others in terms of overall preference. None of the existing
pairwise comparisons were modified during this process but the resulting priority values
did change as the new requirements were introduced. A final comparison matrix was
obtained (not shown) for each of the 50 design inputs (i.e., 50 x 50 = 2500 distinct
preference values). Again, this process was completed from the perspective of
maintaining patient safety in terms of ensuring device integrity and availability. Once
these final priority values were established, the normalization process was completed
(also not shown). Table 24 provides the revised list of priorities obtained for each VOC,
again listed in descending order of importance (Region 4 of Figure 9).
Table 24
Revised VOC Requirements Prioritization

Critical Functions Employ fail-safe modes 0.07750
Device Recovery Recover after security event 0.05727
Device Recovery Address potentially degraded operation 0.05468
Critical Functions Use data encryption/decryption 0.03626
Asset Management Consider impact associated with loss of 0.03624
confidentiality, integrity, availability
145
Table Continued
Intended Use Balance between intended use and security 0.03534
requirements
Asset Management Consider criticality of data 0.03513
Risk Management Identify assets, threats, and vulnerabilities 0.03068
Policies and Procedures Incorporate cybersecurity into design inputs 0.02690
Asset Management Employ data access layers to protect against SQL 0.02669
injection
Asset Management Document device assets (information, components) 0.02632
Configuration Management Define critical system configurations required for 0.02587
security
Intended Use Define device intended use and foreseeable misuse 0.02500
Intended Use Define the use environment 0.02461
Verification and Validation Validate software changes before deployment 0.02288
Access and User Trust Consider potential for “insider attacks” 0.02259
Intended Use Use HFE to ensure security controls do not impact 0.02201
the device’s workflow
Risk Management Develop a security risk management plan 0.02051
Access and User Trust Require authentication 0.01967
Intended Use Understand how use environment can impact system 0.01736
access and data exposure
Verification and Validation Design V&V includes connections to external 0.01735
devices and networks
Risk Management Employ a security risk control hierarchy 0.01655
Access and User Trust Limit device access 0.01641
Configuration Management Evaluate design changes in a system context 0.01626
Software Patches Authentication required for patches 0.01584
Risk Management Utilize OWASP and/or CVSS risk rating systems 0.01550
Vigilance Monitor cybersecurity information sources 0.01508
Risk Management Hold regular cybersecurity meetings to review and 0.01491
address risks
Verification and Validation Employ threat modeling to define safety and 0.01455
essential performance
Detection and Response Inform user regarding actions to take following 0.01386
security event
Vigilance Identify cybersecurity signals and work with sources 0.01363
Documentation Document the information flow between device, 0.01334
other devices and network
Documentation Document connection to IT networks (purpose, 0.01305
configuration, characteristics, specifications)
Detection and Response Detect, recognize, and log security events 0.01296
146
Table Continued
Resources and Training Hold cyber response training for service personnel 0.01242
with emphasis on providing a consistent message to
customers
Configuration Management Include SOUP change evaluation during periodic 0.01236
reviews
Vigilance Analyze complaints, service reports, returned 0.01209
product
Vigilance Maintain a robust software lifecycle process 0.01172
Organizational Management Ensure HFE is involved as early as possible in 0.01122
design activities
Policies and Procedures Verify third-party suppliers are reputable and 0.01015
maintain their software
Resources and Training Employee knowledge and experience with 0.00911
cybersecurity
Organizational Management Project funding, schedules, and staffing must be 0.00909
adequate
Policies and Procedures Periodically review internal requirements against 0.00907
changes in standards and regulations
Detection and Response Allow more local control of detection and 0.00904
remediation for cybersecurity issues
Organizational Management Management support is required 0.00897
Resources and Training Management should provide qualified personnel 0.00823
Policies and Procedures Communication between designers is required 0.00737
Policies and Procedures CIS policies must be established, documented, and 0.00645
followed
Access and User Trust Physical locks on external ports 0.00543
Software Patches Patches need to be timely 0.00453
Note. CIS = Computer Information Systems; SOUP = Software of Unknown Provenance; OWASP =
Open Web Application Security Project; CVSS = Common Vulnerability Scoring System; SQL =
Structured Query Language; HFE = Human Factors Engineering; Additional requirements obtained
through stakeholder data analysis are shown in italics. Priority sorting was completed to four significant
figures as shown. Subsequent calculations utilize two significant figures. Developed by the author.
Comparing the updated values to those previously obtained (see Table 18), it is
clear that prioritization of the baseline requirements related to Critical Functions and
Device Recovery were not impacted by the additional customer inputs. This suggests
that the goal of maintaining device integrity and availability will be more likely realized
147
by ensuring that these elements are factored into the design. It is also interesting to note
that some of the new requirements appear to conflict with one another. For example, the
desire to “Allow more local control of detection and remediation for cybersecurity
issues” conflicts to some extent with the need to “Consider potential for insider attacks”
since increasing localized access to a device may offer a greater opportunity for a threat
agent to initiate a cyber-attack. In cases where customer inputs are observed to
potentially support or detract from one another, it may be beneficial to examine the
interrelationships between such requirements using the same methodology that was
previously applied to the technical requirements.
Additional VOC and Technical

Requirements Comparison
The next step in development of the updated House of Quality was to assess each
of the new (prioritized) voice of the customer requirements against each of the technical
requirements using the symbols and rational values defined in Table 7. The original
comparisons made between the initial VOC requirements and the technical requirements
were unchanged during this process. Of the 12 new requirements introduced, 10 were
observed to have varying levels of influence on the design, while two of these,
“Periodically review internal requirements against changes in standards and regulations”
along with “Ensure HFE is involved as early as possible in design activities” were not
clearly supported by the technical requirements. The results of the overall comparison
are illustrated in Figure 18.

148
149
150
151
152
153
Figure 18. Updated Customer and Technical Requirements Comparison. Additional

VOC requirement rows are shaded for clarity. Developed by the author.
154
Reassessment of Technical Requirement

Priorities
In order to conclude the House of Quality update, it was necessary to re-evaluate
each of the technical requirement priorities. The introduction of new VOC requirements
into the process necessitated a recalculation of the 46 technical priority scores using the
methods previously discussed. The revised list of technical priorities, displayed in
descending order of importance, is shown in Table 25 (Region 7 of Figure 9). What is
clear from this data is that the new VOC requirements did not significantly alter the
previously established design priorities. Key technical considerations for the fictional
device include the ability to maintain functionality in response to a cyber-event as well as
the use of encryption and decryption techniques for information residing within the
device as well as during transmission (either wirelessly or via a network connection).
Perceived Advantages and Next Steps
The fundamental advantage of using the PDSA cycle presented in this study is
that it provides a systematic way to incorporate new requirements and cybersecurity
signal data into an existing QFD framework. Obtaining feedback from stakeholders
directly involved in the design and deployment of connected medical devices offers one
such opportunity for continuous improvement. Other opportunities might include active
membership and participation in security-related trade associations, use of commercially
available vulnerability scanning software, and attendance at cybersecurity conferences.

155
Table 25
Updated Technical Requirement Priorities

8 Maintain functionality and configuration following cybersecurity event 13.698
5 Include fail-safe mode relative to security breaches 12.422
44 Configuration and calibration data are encrypted/decrypted using a recognized 6.405
standard
10 Monitor for and address security compromises, including evidence recording 6.396
mechanism/memory
41 Transmitted/received data is encrypted/decrypted using a recognized standard 5.420
9 Device data is encrypted and decrypted using industry-standard methods 5.058
7 Limit software patch installation to authenticated users 2.764
13 Combines insulin delivery and blood glucose sensing functions into a single, 2.500
fully automated system
19 Delivers basal insulin based on the patient’s 24-hour glucose profile as 2.500
measured by the blood glucose sensor
33 Wireless network requires user authentication via external server 2.494
29 User account is disabled following five unsuccessful login attempts 1.954
43 Configuration and calibration data are stored locally on device 1.912
45 System maintains an audit trail which is human-readable 1.828
42 External ports used for troubleshooting are disabled when not in use 1.688
28 User credentials (passwords) automatically expire after 90 days 1.512
30 Locked user account requires administrative access for resets 1.484
34 Generates and maintains electronic record of patient name, age, and sex 1.347
35 Generates and maintains electronic record of device functional status (e.g., 1.347
operational, on standby, unavailable)
36 Generates and maintains electronic record of historical trend data (blood 1.347
glucose levels and insulin administration)
37 Generates and maintains electronic record of patient data including battery 1.347
charge level
38 Generates and maintains electronic record of patient data including device 1.347
alerts (e.g., blood glucose too high or low, low battery)
12 Intended use is for diabetes patients 1.295
1 Incorporate a robust user authentication scheme 1.141
31 Wireless capability can be disabled/enabled by user 1.001
27 Wireless connectivity interface utilizes latest Bluetooth technology 0.995
40 Therapy and alert parameters can be modified by the care provider via the 0.875
wireless interface
6 Provide capability for software patches 0.852
32 Wireless interface use requires user name and password for access 0.845
39 Electronic records can be transmitted by the device to the care provider via the 0.829
wireless interface
156
Table Continued
3 Incorporate segregation of duties relative to device user access 0.821
26 Contains wireless interface for troubleshooting 0.790
25 Is directly connected to hospital network during care provider visit 0.776
46 System audit trail cannot be modified or deleted by user or administrative 0.721
access
2 Incorporate user access timeout 0.579
14 External to human body 0.510
21 Worn by patient when not in care provider location 0.510
17 Infuses insulin based on patient need 0.338
18 Utilizes a single, subcutaneous infusion site located on the patient’s body 0.338
23 Continuously monitors blood glucose levels 0.338
24 Administers precise dosage of insulin as required 0.338
11 Operating system is developed and managed in-house vs. COTS 0.314
15 Contains patient-applied sensors 0.173
16 Contains tubing and catheter set (disposable) 0.173
20 Basal rates are modifiable by the patient manually or by the system 0.173
automatically
4 No hardcoded passwords 0.138
22 Is lightweight and portable 0.000
The next stage in the product development process would involve a determination
of which prioritized technical requirements should be carried into the subsequent Houses
of Quality, the first of which is intended to help identify lower-level component
characteristics, as were discussed in Chapter 2. This activity is left for further study.
Review of QFD Methodology

With Stakeholders
Following development of the baseline and revised Houses of Quality, a subset of
the questionnaire participant group was selected to review the overall process and offer
additional feedback. This was undertaken as the final step of the Act phase in order to
understand whether or not the methodology used for the study provides potential value as
157
a tool for the identification, selection, and prioritization of medical device cybersecurity
design requirements. In addition, this review allowed for the solicitation of suggested
changes and improvements which could be utilized for additional PDSA cycles.
Of the nine individuals who provided responses to the questionnaire, five were
available for the review. An overview of the PDSA cycle and QFD process steps used
for the fictional medical device was provided to the stakeholders. This resulted in the
following discussion points regarding possible utilization as well as opportunities for
future improvement.
 The manner in which the VOC requirements were prioritized is a more logical
and consistent approach than what is being practiced currently.
 Management of security requirements is currently based on a collection of

best-practices. As more security features are added to a product, it becomes
more difficult to use. The idea of requesting input from customers is viewed
as favorable since cybersecurity is a shared responsibility. The ability to work
with customers and provide the best mix of security and usability would be
very beneficial.
 While it is desirable to include both functional and security requirements

within the same House of Quality structure, the overall size of the resulting
matrix could become difficult to manage.
 There will always be some level of security (residual) risk associated with a
given medical device. The goal is to ensure that the benefit of using the
device continues to outweigh this risk.
 The current process of gathering, organizing, and managing device security

requirements consists of the following:
o A marketing document is developed to gather high-level requirements.
o High-level requirements undergo an approval process.

158
o System-level requirements are broken down into hardware and

software requirements.
o Security requirements are included within this process but do not

necessarily come directly from voice of the customer input. Typically
these requirements are based on internal knowledge of current security
practices.
 Rather than attempting to align voice of the customer requirements around a

large quantity of standards, it may be more useful to look at organizations
which are attempting to harmonize a number of these standards (e.g.,
HITRUST).
Summary
This chapter served to illustrate one possible methodology for completing the first
in a series of QFD matrices specifically intended to address medical device security
requirements. The resulting matrix utilized an initial set of voice of the customer data
along with a set of technical requirements appropriate to the fictional medical device
under consideration. The PDSA cycle was leveraged to improve upon this initial matrix
through the inclusion of subject matter expert feedback, from which it was possible to
define a number of additional requirements and incorporate these into the process.
Subsequent stakeholder review of the techniques introduced in this study suggested
several potential benefits over the methods currently being used for the collection,
organization, and management of cybersecurity design requirements.

159
CHAPTER 5
SUMMARY, CONCLUSION, AND

RECOMMENDATIONS
Summary
The thesis was developed in order to explore the application of established quality
methods and tools to the problem of medical device cybersecurity requirements
management. To begin, a comprehensive review was completed by examining current
best practices with regard to how such requirements are identified, prioritized, and
managed in terms of applicable regulations, guidance documents, risk management
techniques, human factors engineering, software design and development methods as
well as other quality techniques presently being employed. Once this was well
understood, available quality tools and techniques were then studied to determine which
could potentially be used to improve upon today’s methods. The PDSA cycle was
ultimately selected as a model for managing the software and hardware design
requirements necessary for ensuring cybersecurity risk mitigation across the lifecycle of a
given medical device. Additionally, the QFD methodology was identified as a suitable
tool for gathering voice of the customer data which could then be used to drive security
design requirements. In this context, the definition of customer was expanded to include
medical device and information technology regulators, standards organizations, and
industry experts.
160
With the underlying quality methods and tools identified, the next step was to
develop a cybersecurity questionnaire to gather feedback from subject matter experts
within the medical device space. The data received through this process would ultimately
serve to augment an initial QFD matrix. To develop the initial matrix, a fictional medical
device was established from which a set of basic functional and security design
requirements could be derived. The literature review provided a wide variety of voice of
the customer inputs in terms of established guidance documents, international standards,
and other sources of information. Given the large number of data points to be managed
within the QFD matrix, the customer inputs underwent an Affinity Diagramming process.
Prioritization of the resulting list of inputs was effectively managed through the use of the
Analytic Hierarchy Process. The resulting House of Quality was developed and
reviewed.
A review of the questionnaire data was undertaken and several additional voice of
the customer requirements were identified. These were added to the baseline House of
Quality matrix, resulting in a new iteration. Finally, the overall process was reviewed
with a subset of the questionnaire stakeholder group to better understand if the process
could be applied to the awareness, identification, and remediation of cybersecurity
vulnerabilities in a more holistic and consistent manner across the lifecycle of any
connected medical device.

161
Conclusion
As this study demonstrates, cybersecurity will continue to pose a significant
challenge for ensuring the safety and efficacy of connected medical devices. Industry
regulators, manufacturers, users, and patients all play an important role in managing risk
within this complex and dynamic environment. At the present time, there are numerous
resources available for identifying and mitigating the risks associated with cyber-threats
as they relate to device integrity and availability. However, as technology continues to
evolve and devices become more dependent on each other and on increasingly complex
connectivity platforms, industry leaders will be forced to identify new and improved
methods for addressing these emerging obstacles.
The process undertaken during this study represents one possible solution to
meeting the needs of medical device developers who require a consistent approach to the
overall management of security requirements. The research indicates that a large amount
of information is currently available to assist with this process but overall, there does not
appear to be a logical method for its application. This was further supported in the
survey data received from a stakeholder group. By leveraging a well-established
continuous improvement method, such as the PDSA cycle, along with QFD’s House of
Quality structure, it is possible to improve upon the current manner in which security
requirements are being managed. With new connected devices entering the healthcare
space every day, the problem of ensuring device integrity and availability will only
become more complex and prolific over time. It is for this reason that a systematic
approach to managing security-specific design requirements is extremely important.

162
Recommendations for Further Study
Several recommendations can be made with regard to additional areas of study as
they relate to the topics presented in this thesis. Cybersecurity is an emerging field of
study and there will undoubtedly be new requirements and processes developed to
counter future threats. The reader is therefore encouraged to explore other quality tools
and techniques which could be leveraged to effectively manage cybersecurity
requirements going forward.

REFERENCES
164
REFERENCES
Akao, Y., & Mazur, G. H. (2003). The leading edge in QFD: past, present and future.
International Journal of Quality & Reliability Management, 20(1), 20-35.
Retrieved from http://intra.itiltd-india.com/quality/qulandreltools/qfd_history.pdf
Association for the Advancement of Medical Instrumentation. (2016). Principles for
medical device security--risk management (AAMI TIR57).
Atugade, U. R., Awate, P. P., Shinde, M. S., & Harugade, N. V. (2016) Quality function
deployment. Retrieved from http://data.conferenceworld.in/BHIMA/P53-57.pdf
Banuelas, R., & Antony, J. (2004). Six sigma or design for six sigma?. The TQM
magazine, 16(4), 250-263. Retrieved from
https://www.researchgate.net/profile/Jiju_Antony/publication/237090966_Six_Si
gma_or_design_for_Six_Sigma/links/566b518408ae430ab4f9c8ac.pdf
Bunruamkaew, K. (2012). How to do AHP analysis in Excel. University of Tsukuba,
Graduate School of Life and Environmental Sciences, Division of Spatial
Information Science. Retrieved from
https://s3.amazonaws.com/academia.edu.documents/36910609/AHP-
Bunruamkaew-En-iyi_ciklama-
How_to_do_AHP_analysis_in_Excel.pdf?AWSAccessKeyId=AKIAIWOWYYG
Z2Y53UL3A&Expires=1541094126&Signature=9cVTaO2V2KfHYGJNKWRhp
wRfZgQ%3D&response-content-disposition=inline%3B%20filename%3DAHP-
Bunruamkaew-En-iyi_ciklama-How_to_do.pdf
165
Burton, J., McCaffery, F., & Richardson, I. (2006, May). A risk management capability
model for use in medical device companies. In Proceedings of the 2006
international workshop on Software quality (pp. 3-8). ACM. Retrieved from
http://eprints.dkit.ie/134/1/A_Risk_Management_Capability_Model_no.43.docx
Cooper, J. G., & Pauley, K. A. (2006). Healthcare software assurance. In AMIA Annual
Symposium Proceedings (Vol. 2006, p. 166). American Medical Informatics
Association. Retrieved from
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1839424/pdf/AMIA2006_0166.p
df
Deming, W. E. (1986). Out of the crisis. Cambridge, MA: Massachusetts Institute of
Technology. Center for Advanced Engineering Study.
Disterer, G. (2013). ISO/IEC 27000, 27001 and 27002 for information security
management. Retrieved from http://file.scirp.org/pdf/JIS_2013042311130103.pdf
Eagles, S., & Wu, F. (2014). Reducing risks and recalls: safety assurance cases for
medical devices. Biomedical Instrumentation & Technology, 48(1), 24-32.
Retrieved from
https://www.researchgate.net/profile/Fubin_Wu/publication/260251415_Reducin
g_Risks_and_Recalls_Safety_Assurance_Cases_For_Medical_Devices/links/57c0
7a1908ae2f5eb3322244.pdf
Finnegan, A., & McCaffery, F. (2014, November). A security argument pattern for
medical device assurance cases. In Software Reliability Engineering Workshops

166
(ISSREW), 2014 IEEE International Symposium on (pp. 220-225). IEEE.
Retrieved from
http://eprints.dkit.ie/412/1/PID3398017%20ASSURE.pdf
Finnegan, A., McCaffery, F., & Coleman, G. (2013). Development of a process
assessment model for assessing security of IT networks incorporating medical
devices against ISO/IEC 15026-4. Retrieved from
https://ulir.ul.ie/bitstream/handle/10344/3124/Finnegan_2013_process.pdf?sequen
ce=2
Fox-Brewster, T. (2017, May 17). Medical devices hit by ransomware for the first time in
US hospitals. Forbes. Retrieved from
https://www.forbes.com/sites/thomasbrewster/2017/05/17/wannacry-ransomware-
hit-real-medical-devices/print/
Fu, K. (2011). Trustworthy medical device software. Public Health Effectiveness of the
FDA, 510, 102. Retrieved from
http://css.csail.mit.edu/6.858/2014/readings/medical-sw.pdf
Fu, K., & Blum, J. (2013). Controlling for cybersecurity risks of medical device software.
Communications of the ACM, 56(10), 35-37. Retrieved from
https://pdfs.semanticscholar.org/06c7/1331dbecf12572089ab2e8739ca169f523ad.
pdf
Guides, H. T., O’Brien, G., Edwards, S., Littlefield, K., McNab, N., Wang, S., & Zheng,
K. (2017, May) (1800). Securing Wireless Infusion Pumps. NIST Special

167
Publication, 1B. Retrieved from https://www.nccoe.nist.gov/publication/1800-
8/VolB/index.html
Gutzwiller, R. S., Fugate, S., Sawyer, B. D., & Hancock, P. A. (2015, September). The
human factors of cyber network defense. In Proceedings of the Human Factors
and Ergonomics Society Annual Meeting (Vol. 59, No. 1, pp. 322-326). SAGE
Publications. Retrieved from
https://www.researchgate.net/profile/Robert_Gutzwiller/publication/283520210_
The_Human_Factors_of_Cyber_Network_Defense/links/56452de308ae451880a8
be24.pdf
Haag, S., Raja, M., & Schkade, L. L. (1996). Quality function deployment usage in
software development. Communications of the ACM, 39(1), 41-49.
https://www.researchgate.net/profile/Stephen_Haag/publication/220420894_Quali
ty_Function_Deployment_Usage_in_Software_Development/links/53f4b5de0cf2
888a749114b7.pdf
Haigh, T., & Landwehr, C. (2015). Building code for medical device software security.
IEEE Cybersecurity. Retrieved from http://www.landwehr.org/2015-03-haigh-
landwehr-ieee.pdf
International Electrotechnical Commission. (2010). Application of risk management for
IT-networks incorporating medical devices-Part 1: Roles, responsibilities and
activities (IEC 80001-1).
International Organization for Standardization. (2012). Medical devices--application of
risk management to medical devices (ISO 14971).

168
International Organization for Standardization. (2015). Application of statistical and
related methods to new technology and product development process--Part 1:
General principles and perspectives of Quality Function Deployment (QFD) (ISO
16355-1).
International Organization for Standardization. (2016). Medical devices--quality
management systems--requirements for regulatory purposes (ISO 13485).
International Organization for Standardization/International Electrotechnical
Commission. (2015). Information technology--Security techniques--Information
security management systems--Overview and vocabulary (ISO/IEC 27000).
Commission. (2015). Information technology--Security techniques--Information
security management systems--Requirements (ISO/IEC 27001).
Commission. (2017). Information technology--Security techniques--Code of
practice for information security controls (ISO/IEC 27002).
Kansagra, D., Kumhar, M., & Jha, D. (2015). Ransomware: A Threat to Cyber Security.
IJCSC, 7(1), 224-27. Retrieved from http://csjournals.com/IJCSC/PDF7-
1/35.%20Malaram.pdf
Kissel, R. Glossary of Key Information Security Terms, National Institute of Standards
and Technology Std. NIST IR 7298, Rev. 2, May 2013. Retrieved from
http://nvlpubs.nist.gov/nistpubs/ir/2013/NIST.IR.7298r2.pdf
169
Knop, K., & Mielczarek, K. (2015). The improvement on the basis of PDCA and SDCA
cycles. Zeszyty Naukowe. Quality. Production. Improvement. Retrieved from
https://yadda.icm.edu.pl/baztech/element/bwmeta1.element.baztech-e5cb7b71-
2739-4414-9f6a-cfb9f61bf879/c/qpi.No._2_3__-_06.2015.pdf
Kraemer, S., Carayon, P., & Clem, J. (2009). Human and organizational factors in
computer and information security: Pathways to vulnerabilities. Computers &
security, 28(7), 509-520. Retrieved from
https://www.researchgate.net/profile/Pascale_Carayon/publication/222550002_H
uman_and_organizational_factors_in_computer_and_information_security_Pathw
ays_to_vulnerabilities/links/0fcfd50e8c7ff53603000000.pdf
Liu, X. F. (2000). Software quality function deployment. IEEE Potentials, 19(5), 14-16.
Retrieved from
http://scholarsmine.mst.edu/cgi/viewcontent.cgi?article=1153&context=comsci_f
acwork&sei-
redir=1&referer=https%3A%2F%2Fscholar.google.com%2Fscholar%3Fstart%3
D10%26q%3Dquality%2Bfunction%2Bdeployment%2Bdeming%26hl%3Den%2
6as_sdt%3D0%2C39#search=%22quality%20function%20deployment%20demin
g%22
McAdams, B. H., & Rizvi, A. A. (2016). An overview of insulin pumps and glucose
sensors for the generalist. Journal of Clinical Medicine, 5(1), 5. Retrieved from:
http://doi.org/10.3390/jcm5010005
170
Moen, R., & Norman, C. (2006). Evolution of the PDCA cycle. Retrieved from:
http://kaizensite.com/learninglean/wp-content/uploads/2012/09/Evolution-of-
PDCA.pdf
NIST, U. (2014). Framework for improving critical infrastructure cybersecurity.
Retrieved from
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
Perakslis, E. D. (2014). Cybersecurity in health care. The New England journal of
medicine, 371(5), 395. Retrieved from
http://www.forpath.org/glem/minutes/140905/Glem_140905_Cybersecurity_in_H
ealth_Care.pdf
Phillips, M. (2003). Using a capability maturity model to derive security requirements.
SANS Institute. Retrieved from https://www.sans.org/reading-
room/whitepapers/bestprac/capability-maturity-model-derive-security-
requirements-1005
Reich, D., & McAleer, S. (2016, August 9). How to mitigate cybersecurity risks in your
medical device. Medical Product Manufacturing News. Retrieved from
http://www.qmed.com/mpmn/medtechpulse/how-mitigate-cybersecurity-risks-
your-medical-device
Saaty, T. L. (1990). How to make a decision: the analytic hierarchy process. European
journal of operational research, 48(1), 9-26. Retrieved from
https://s3.amazonaws.com/academia.edu.documents/34802958/06F167EF-B243-
48ED-8C45-F7466B3136EB-WebPublishings-
171
How_to_make_decision_AHP.pdf?AWSAccessKeyId=AKIAIWOWYYGZ2Y53
UL3A&Expires=1541094713&Signature=TIArhOr6Zx8Qaa37XqrdPoyUwEI%3
D&response-content-
disposition=inline%3B%20filename%3DHow_to_make_a_decision_The_Analyti
c_Hier.pdf
Sametinger, J., Rozenblit, J., Lysecky, R., & Ott, P. (2015). Security challenges for
medical devices. Communications of the ACM, 58(4), 74-82. Retrieved from
https://www.se.jku.at/wp-content/uploads/2015/03/TR-SE-15.03.pdf
Sokovic, M., Pavletic, D., & Pipan, K. K. (2010). Quality improvement methodologies–
PDCA cycle, RADAR matrix, DMAIC and DFSS. Journal of Achievements in
Materials and Manufacturing Engineering, 43(1), 476-483. Retrieved from
http://jamme.acmsse.h2.pl/papers_vol43_1/43155.pdf
Taylor, M. J., McNicholas, C., Nicolay, C., Darzi, A., Bell, D., & Reed, J. E. (2013).
Systematic review of the application of the plan-do-study-act method to improve
quality in healthcare. BMJ Qual Saf, bmjqs-2013. Retrieved from
http://qualitysafety.bmj.com/content/qhc/early/2013/09/11/bmjqs-2013-
001862.full.pdf
U.S. Food and Drug Administration. (2005). Cybersecurity for networked medical
devices containing off-the-shelf (ots) software. Retrieved from
https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/
GuidanceDocuments/ucm077823.pdf
172
U.S. Food and Drug Administration. (2013). Content of premarket submissions for
management of cybersecurity in medical devices: draft guidance for industry and
food and drug administration staff. Retrieved from
http://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guid
ancedocuments/ucm356190.pdf
U.S. Food and Drug Administration. (2014). Classify your medical device. July 2014.
Retrieved from
http://www.fda.gov/medicaldevices/deviceregulationandguidance/overview/classi
fyyourdevice/ucm051512.htm
U.S. Food and Drug Administration. (2015). Cybersecurity for medical devices and
hospital networks: FDA safety communication. June 13, 2013. Retrieved from
http://www.fda.gov/medicaldevices/safety/alertsandnotices/ucm356423.htm
U.S. Food and Drug Administration. (2016). Cybersecurity. November 1, 2016.
Retrieved from www.fda.gov/medicaldevices/digitalhealth/ucm373213.htm
U.S. Food and Drug Administration. (2016). Postmarket Management of Cybersecurity in
Medical Devices: Guidance for Industry and Food and Drug Administration Staff.
Retrieved from
https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/gui
dancedocuments/ucm482022.pdf
Williams, P. A., & Woodward, A. J. (2015). Cybersecurity vulnerabilities in medical
devices: a complex environment and multifaceted problem. Medical devices

173
(Auckland, NZ), 8, 305. Retrieved from
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4516335/pdf/mder-8-305.pdf
Wirth, A. (2011). Cybercrimes pose growing threat to medical devices. Biomedical
Instrumentation & Technology, 45(1), 26-34. Retrieved from
http://rdcms-
aami.s3.amazonaws.com/files/production/public/FileDownloads/HT_Cybersecurit
y/2011JF_CyberCrimes.pdf
APPENDIX
MEDICAL DEVICE CYBERSECURITY DESIGN

REQUIREMENTS QUESTIONNAIRE
175
Medical Device Cybersecurity Design Requirements

Questionnaire
GJP 5/7/2018
Revision 03
Purpose: The purpose of this questionnaire is to solicit research information

related to current and future techniques for implementing security requirements
associated with connected medical devices. Five central focus areas are included
within the questionnaire (Regulations and Guidance Documents, International
Standards, Risk Management Techniques, Human Factors Engineering, and
Software/Hardware Design and Development). The primary goal of the research
project is to improve the identification, collection, organization, and management of
cybersecurity design requirements for medical devices.
Instructions: Please type all responses directly into the yellow-highlighted boxes
provided below each question. For responses which require a multiple choice
selection, please click to add an “X” in the column denoted by “Check One”. Note
that all entry boxes will expand to accommodate the length of your response.
Please provide as much detail as possible for each response but do not
reveal any specific devices or any proprietary information associated with a
specific device or family of devices.
Part A: PERSONAL INFORMATION AND EXPERIENCE
1. NAME:
2. TITLE:
3. ORGANIZATION NAME:
4. TELEPHONE NUMBER(s):
176
Business Phone:
Cellular Phone:
5. MAILING ADDRESS:
Organization Name:
Street Address 1:
Street Address 2:
City:
State:
ZIP Code:
6. EMAIL ADDRESS:
7. WHICH OF THE FOLLOWING BEST DESCRIBES YOUR ORGANIZATION?
Organization Check One

Medical Device Design / Manufacturing
Medical Device Service Contractor
Hospital
Clinic
Consulting Firm
Independent Consultant
Nonprofit
Other (Please Describe):
8. WHICH OF THE FOLLOWING BEST DESCRIBES YOUR PROFESSION WITHIN THE

MEDICAL DEVICE FIELD:
Profession Check One

Software Engineer
Hardware Engineer
Cybersecurity Professional
177
Profession Check One

Information Technology Professional
Clinical and/or Device Applications
Service Repair Engineer / Technician
Physician
Nurse
Radiologist / Medical Technician
Biomedical Engineer
9. WHICH OF THE FOLLOWING BEST DESCRIBES YOUR INVOLVEMENT WITH

MEDICAL DEVICES WHICH ARE CONNECTED VIA THE INTERNET.
Areas of Involvement Check One

I recommend the purchase of connected medical devices
I maintain the performance of one of more types of connected medical devices

(i.e. perform routine software updates, repairs, etc.)
I use one or more connected medical devices on patients for diagnostic or

therapeutic procedures
I oversee the security of one or more connected medical devices
I design software for connected medical devices
I design hardware for connected medical devices
I am not involved with medical devices which are connected to the internet
10. WITHIN YOUR FIELD, HOW MANY YEARS OF EXPERIENCE DO YOU HAVE WITH
CONNECTED MEDICAL DEVICES?
Years of Experience Check One

Less than 1 year
1 to 3 years
4 to 6 years
178
Years of Experience Check One

7 to 10 years
11 to 15 years
16 to 20 years
More than 20 years
11. DESCRIBE THE TYPE(S) OF CONNECTED MEDICAL DEVICES WITH WHICH YOU
HAVE EXPERIENCE. (List and discuss all that apply)
12. DESCRIBE ALL REGULATIONS AND GUIDANCE DOCUMENTS ADDRESSING

CYBERSECURITY WITH WHICH YOU ARE FAMILIAR AND HOW YOU APPLY EACH.
(List and discuss all that apply)
13. DESCRIBE ALL INTERNATIONAL STANDARDS RELATING THE CYBERSECURITY

WITH WHICH YOU ARE FAMILIAR AND HOW YOU APPLY EACH. (List and discuss all
that apply)
14. DESCRIBE THE RISK MANAGEMENT TECHNIQUES YOU ARE AWARE OF WITH
REGARD TO CYBERSECURITY AND HOW YOU APPLY EACH. (List and discuss all
that apply)
179
15. DESCRIBE YOUR EXPERIENCE WITH HUMAN FACTORS ENGINEERING AS IT

RELATES TO CONNECTED MEDICAL DEVICES AND CYBERSECURITY.
16. DESCRIBE ANY SOFTWARE AND/OR HARDWARE DESIGN AND DEVELOPMENT

METHODS YOU ARE FAMILIAR WITH REGARDING CYBERSECURITY. (List and
discuss all that apply)
Part B: DESIGN CONSIDERATIONS FOR FUTURE DEVICES
17. FROM THE PERSPECTIVE OF EXISTING REGULATIONS AND GUIDANCE

DOCUMENTS ADDRESSING MEDICAL DEVICE CYBERSECURITY, WHAT CHANGES
OR IMPROVEMENTS WOULD YOU SUGGEST? (Please be as specific as possible in
your response)
18. FROM THE PERSPECTIVE OF EXISTING INTERNATIONAL STANDARDS

ADDRESSING MEDICAL DEVICE CYBERSECURITY, WHAT CHANGES OR
IMPROVEMENTS WOULD YOU SUGGEST? (Please be as specific as possible in your
response)
180
19. FROM THE PERSPECTIVE OF EXISTING RISK MANAGEMENT STANDARDS,

TECHNIQUES, AND TOOLS ADDRESSING MEDICAL DEVICE CYBERSECURITY,
WHAT CHANGES OR IMPROVEMENTS WOULD YOU SUGGEST? (Please be as
specific as possible in your response)
20. FROM THE PERSPECTIVE OF EXISTING HUMAN FACTORS ENGINEERING

METHODOLOGIES ADDRESSING MEDICAL DEVICE CYBERSECURITY, WHAT
CHANGES OR IMPROVEMENTS WOULD YOU SUGGEST? (Please be as specific as
possible in your response)
21. FROM THE PERSPECTIVE OF EXISTING SOFTWARE AND/OR HARDWARE

DESIGN AND DEVELOPMENT METHODS ADDRESSING MEDICAL DEVICE
CYBERSECURITY, WHAT CHANGES OR IMPROVEMENTS WOULD YOU SUGGEST?
(Please be as specific as possible in your response)
22. WHAT ADDITIONAL IDEAS DO YOU HAVE WITH REGARD TO IMPROVING

CONNECTED MEDICAL DEVICE CYBERSECURITY ROBUSTNESS DURING THE
DESIGN AND DEVELOPMENT PROCESS?
181
23. WHAT ADDITIONAL IDEAS DO YOU HAVE WITH REGARD TO IMPROVING

CONNECTED MEDICAL DEVICE CYBERSECURITY ROBUSTNESS DURING THE
LIFECYCLE OF A DEVICE ONCE IT IS IN USE?
24. PLEASE SHARE ANY ADDITIONAL THOUGHTS YOU HAVE REGARDING THE
STATE OF TODAY’S MEDICAL DEVICE CYBERSECURITY PRACTICES AND WHAT
YOU WOULD LIKE TO SEE IN THE FUTURE.
25. PLEASE PROVIDE ANY ADDITIONAL INFORMATION OR COMMENTS YOU WISH TO

SHARE RELATIVE TO THE TOPICS DISCUSSED IN THIS QUESTIONNAIRE.

Spring 2019 Papcun G Medical Device Quality Managing Cybersecurity Design Requirements Through The Application of Pdsa QFD

Uploaded by

Copyright:

Available Formats

Spring 2019 Papcun G Medical Device Quality Managing Cybersecurity Design Requirements Through The Application of Pdsa QFD

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Spring 2019 Papcun G Medical Device Quality Managing Cybersecurity Design Requirements Through The Application of Pdsa QFD

Uploaded by

Copyright:

Available Formats

MEDICAL DEVICE QUALITY: MANAGING CYBERSECURITY DESIGN

REQUIREMENTS THROUGH THE APPLICATION OF

PDSA AND QFD

California State University Dominguez Hills

of the Requirements for the Degree

George Joseph Papcun

All Rights Reserved

constant support and encouragement of my academic pursuits in science and engineering

helped me to become the person I am today.

2. REVIEW OF LITERATURE .......................................................................................30

Introduction and Key Objectives...........................................................................66

Subject Medical Device Overview........................................................................68

4. RESULTS AND DISCUSSION.................................................................................108

5. SUMMARY, CONCLUSION, AND RECOMMENDATIONS................................159

APPENDIX: MEDICAL DEVICE CYBERSECURITY DESIGN

1. Examples of Wireless Infusion Pump Cybersecurity Threats.........................................5

2. Examples of Wireless Infusion Pump Cybersecurity Vulnerabilities..............................7

4. Quality Tools and Potential Challenges for Cybersecurity............................................20

5. Summary of Reviewed Regulations and Guidance Documents....................................36

6. Summary of Reviewed International Standards............................................................50

7. Five-level Ranking Scheme (VOC and Technical Requirements Comparison)............73

8. Customer Requirements Related to Software and Hardware Design............................74

9. Customer Requirements Related to Risk Management.................................................76

10. Customer Requirements Related to Human Factors....................................................82

11. Customer Requirements Related to Quality Management Systems............................85

12. Customer Requirements Related to Verification and Validation................................86

13. Voice of the Customer Requirements..........................................................................92

14. VOC Categories versus NIST Five Core Functions....................................................94

15. Technical Requirements...............................................................................................95

16. Pair-wise Comparison Scale for AHP..........................................................................97

17. Five-level Ranking Scheme (Technical Requirement Interrelationships)...................99

18. Prioritized VOC Requirements..................................................................................116

19. Technical Requirement Interrelationships.................................................................119

20. Technical Requirement Priorities..............................................................................132

21. Cybersecurity Questionnaire Demographics Overview.............................................134

22. Principal Outcomes from Cybersecurity Questionnaire............................................137

23. Revised Voice of the Customer Requirements by Category.....................................142

24. Revised VOC Requirements Prioritization................................................................144

25. Updated Technical Requirement Priorities................................................................155

1. Configuration of a Standalone Infusion Pump.................................................................3

2. Configuration of a Wireless Infusion Pump....................................................................4

3. Relationship Between Security and Safety Risks..........................................................13

4. Application of PDSA to Information Systems Security................................................24

5. NIST Cybersecurity Framework Categories and Subcategories...................................34

6. Relationship Between Safety and Security Risk Management Processes.....................45

7. PDSA Cycle Process Flow............................................................................................60

8. Relationship Between Houses of Quality......................................................................62

9. Typical House of Quality...............................................................................................63

10. Voice of the Customer Affinity Diagram....................................................................88

11. Mathematics for VOC Prioritization Using AHP........................................................98

12. Use of Technical Requirement Interrelationship Table.............................................100

13. Methodology for Technical Priority Determination..................................................102

14. PDSA Cycle Utilized for Cybersecurity QFD Matrix Development.........................107

15. Initial VOC AHP Comparison Matrix.......................................................................110

16. Normalized AHP Comparison Matrix with VOC Priorities......................................113

17. Customer and Technical Requirements Comparison.................................................125

18. Updated Customer and Technical Requirements Comparison..................................148

The ever-increasing interconnection and sophistication of medical devices

risks relative to device integrity and availability, a comprehensive approach which