Spring 2019 Papcun G Medical Device Quality Managing Cybersecurity Design Requirements Through The Application of Pdsa QFD
Spring 2019 Papcun G Medical Device Quality Managing Cybersecurity Design Requirements Through The Application of Pdsa QFD
Spring 2019 Papcun G Medical Device Quality Managing Cybersecurity Design Requirements Through The Application of Pdsa QFD
____________
A Thesis
Presented
to the Faculty of
____________
In Partial Fulfillment
Master of Science
in
Quality Assurance
____________
by
Spring 2019
Copyright by
GEORGE J. PAPCUN
2019
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
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
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
Summary..............................................................................................................159
Conclusion...........................................................................................................161
Recommendations for Further Study...................................................................162
REFERENCES................................................................................................................163
v
LIST OF TABLES
PAGE
3. Examples of Malware....................................................................................................11
vi
PAGE
vii
LIST OF FIGURES
PAGE
viii
ABSTRACT
containing software presents a significant security risk management challenge for many
manufacturers. While a number of methods have been established for addressing these
leverages existing quality assurance tools and techniques to improve the effectiveness of
Quality Function Deployment (QFD) methodology to the realization of a QFD matrix for
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
prevent disease and other adverse conditions. The U.S. Food and Drug Administration
Based on this definition, medical devices can cover a wide range of applications.
vascular injection systems intended to enhance diagnostic medical imaging scans through
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
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
associated infrastructure are the most concerning due to the potential for adverse
administer medications to patients in precise dosages and flow rates over a given period
illustrates the configuration of a typical wireless pump to its supporting components and
Standalone
Infusion Pump
Patient
VPN Internet
(Virtual Private Network)
Patient
The standalone pump is connected only to the patient and relies on direct user
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
patient risk.
Table 1
Table Continued
Threat Type Description Intended Outcome
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
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
of their functionality or efficacy. Each of these areas can have a negative impact on
aspects of healthcare. The most significant risk associated with a device which has been
manufacturers and healthcare providers need to pay close attention to the following:
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.
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
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
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
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
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
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
to high risk of severity to patients (Fu & Blum, 2013, p. 21-22). In May 2017, a form of
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
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
2017).
Malware consists of a program that is inserted into a system, usually covertly, with the
(Kissel, 2013, p. 118). Table 3 provides examples of several types of malware (Wirth,
2011).
11
Table 3
Examples of Malware
Malware Type Description
Worm A program that duplicates itself from one directory, drive, computer, or
network to another through electronic communication or local area networks.
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.
regulatory bodies (Perakslis, 2014). Recognizing these risks for medical devices, the
FDA issued a safety communication in June of 2013 intended for device manufacturers,
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
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
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).
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
attempt to further assist device manufacturers in this area, the FDA released a draft
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),
into the device’s software validation and risk analysis activities and should encompass
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
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
information regarding radio frequency transmission data, and patent databases include
between device software and legacy operating systems can open the door for potential
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
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
Woodward, 2015).
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
available when needed. Finally, the process needs to be reliable and repeatable such that
generation, and object modeling do not take into account the impact of successive
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
prioritizing design inputs which could lead to improved cybersecurity for new and
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.
lacking. Based on this premise, the intended thesis will examine the current “state of the
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
medical device. The PDSA cycle is widely recognized as an effective methodology for
processes, and services. Needed changes are identified, implemented, and reviewed for
cycles with regard to those changes which are favorable and those which are not
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
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.
PDSA methodology and QFD solution which can be repeatedly applied to the awareness,
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
There are currently several techniques being utilized by medical device designers,
definition, and remediation. What is not readily apparent within these disparate
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
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
device component failures. It would be difficult for this method to identify all the causes,
components that can lead, or contribute to, a hazardous situation or harm (Eagles & Wu,
2014).
cybersecurity mitigation.
Table 4
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
Strategy/Description Challenges for
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.
Table Continued
Potential
Quality Typical
Strategy/Description Challenges for
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
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,
safe, and reliable across the lifecycle of medical device products and processes, is
23
and procedures. This is especially critical when considering the design and development
completely address all aspects of software assurance (Cooper & Pauley, 2006).
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
This family of standards is directly aligned with the PDSA cycle which places an
PLAN
(Establish)
-Monitor performance
-Assess performance
STUDY
(Monitor and Review)
information systems, will serve as the theoretical basis for this study. Given the
medical device design cybersecurity input requirements, PDSA will be leveraged for this
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
developers, and others who may not be directly involved in the specific device design
users, hospitals, and patients. These situations can be categorized in terms of their impact
2015). Confidentiality of patient data is a significant concern but the more important
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
Definition of Terms
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
Failure Mode and Effects Analysis (FMEA): A step-by-step approach for identifying all
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
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
(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
network are sometimes called nodes. Computers and devices that allocate resources for a
delivery and the recipient is provided with proof of the sender’s identity, so neither can
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
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
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
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
Threat: Any circumstance or event with the potential to adversely impact organizational
(Kissel, 2013).
requirements which define an intended use or application have been met (ISO, 2016).
(Kissel, 2013).
30
CHAPTER 2
REVIEW OF LITERATURE
Overview
the current tools and methodologies being utilized for the identification, prioritization,
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
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.
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
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
The primary intent of this guidance document is to supplement the QSR and provide the
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
medical devices which utilize off-the-shelf software. It does not, however, offer any
in 2013 entitled, “Cybersecurity for Medical Devices and Hospital Networks: FDA
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
medical device manufacturers or hospitals with networked devices. The document also
suggests that device manufacturers consider taking steps to limit unauthorized device
appropriate to the device’s use environment, ensure the device maintains critical
functionality even when compromised, and provide methods for retention and recovery
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
2015). While this guidance provides additional details and insights into cybersecurity
issues commonly faced by device manufacturers and hospitals, it also fails to provide
In October of 2014, the FDA issued a new guidance document entitled, “Content
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,
controls intended to ensure continued functionality and safety. The FDA also indicates
patients, health care facilities, and device manufacturers. Furthermore, the FDA
recommends that device design controls include considerations for security as well 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,
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
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
privileges (FDA, 2013). The cybersecurity framework referenced within this document
addition to the five core functions, the framework also includes 23 categories and 108
given organization without providing excessive detail. The subcategories are intended to
34
2014). Figure 5 illustrates a portion of the Identify function, the Business Environment
Function
Identify
Protect
Detect
Respond
Recover
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
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
and reporting are not required. In order to assess whether or not the reporting
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 misuse or denial of use, any of which could result in patient harm. Timely response
guidance documents, this one acknowledges the fact that cybersecurity management
extends beyond initial design and must be addressed across the entire device lifecycle.
36
previously discussed. Although each was observed to lack specificity regarding overall
customer inputs which can be leveraged for the proposed cybersecurity QFD matrix.
Table 5
Table Continued
Document Title Source Year Overview
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
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
clauses 7.2 (Customer-related processes), 7.3 (Design and Development) and 8.5
(Improvement).
following requirements:
d) any user training needed to ensure specified performance and safe use of the
medical device;
requirements are incorporated into the device design but again, this is not explicitly
further subdivided into specific requirements with respect to planning, design inputs,
and design history file management. Clause 7.3.3 Design and development inputs
Clearly, the design input requirements specified within this standard do not include
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
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
The organization shall identify and implement any actions necessary to ensure
and maintain the continued suitability, adequacy, and effectiveness of the quality
the use of the quality policy, quality objectives, audit results, post-market
ISO 14971
Devices,” is a risk management standard which was developed specifically for medical
associated with risk management are of particular importance to such devices because
integrated into a quality management system such as ISO 13485, as described above. Its
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
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
IEC 80001-1
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
This document points to several areas of ongoing concern with regard to the
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
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
AAMI TIR57
more recent medical device technical information report intended to provide guidance to
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,
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.
areas:
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
Clause 4 provides guidance around security risk analysis. Intended use and
reasonably foreseeable misuse of the device are primary considerations. Since HDOs can
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
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
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 harm. The standard suggests that device manufacturers establish a documented and
Clause 6 addresses the topic of risk control and provides the following
The remaining clauses cover the areas of residual security risk evaluation, risk
production and in post-production activities. Several annexes are also included in the
Clear: Not confusing, using simple words, concise statements, and consistent
language;
Verifiable: Can be determined that the system meets the requirement either via
verification or validation;
48
Positive: Written in the affirmative, not the negative (AAMI, 2016, p. 37).
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
emergency access, malware and virus protection, backup and disaster recovery, and
Overall, AAMI TIR57 provides the most comprehensive set of tools for
annexes C and D which provide a starting point for the development of a QFD approach
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
industries. In terms of the scope of this thesis, ISO 27000, ISO 27001, and ISO 27002
definitions relevant to the use of the other standards within the family. The primary goal
(ISO/IEC 27000).
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,
evaluation and improvement (ISO/IEC 27001). The scope of this document lends itself
“ISO 27002: Code of Practice for Information Security Systems,” is intended for
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
Table 6
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
Document Title Year Overview
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 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
Document Title Year Overview
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.
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).
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
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.
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
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
In addition to risk management, human factors also play an important role in the
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
factors as they relate to computer and information security. The article examines
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
vulnerabilities and may have their origins in early design and development assumptions
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
involvement strategies, and the design of specific roles within an organization. The study
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
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
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).
also true for software development processes. Research into this particular area revealed
Cybersecurity Risks of Medical Devices,” authors Blum and Fu (2013) argue that
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
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
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).
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
use which will facilitate the elimination of common classes of software vulnerabilities
Plan-Do-Study-Act (PDSA)
History
As a methodology for continuous improvement, the PDSA cycle has been utilized
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
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
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
the cycle is the Act portion because the cycle is complete at that point and another
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
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
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
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.
History
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
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
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
characteristics of a new or existing product (or service) which will meet the needs of
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
Technical
Requirements
Requirements
Customer
Part
Characteristics
Requirements
Technical
Process
Operations
Characteristics
Part
Manufacturing
Requirements
Operations
Process
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)
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
development process and the resulting product. In his article, “Software Quality Function
Deployment,” Liu (2000) describes how software quality function deployment (SQFD)
64
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
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
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
indicates that limited information has been published. One article by Haag, Raja, and
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
et al., 1996).
65
Summary
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
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
CHAPTER 3
METHODOLOGY
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
voice of the customer information from professionals employed within two different
consultant. The data obtained from this additional research was used to further enhance
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
o International Standards
Review of the completed cybersecurity QFD matrix with each of the surveyed
stakeholders to determine its applicability to future medical device design
efforts
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
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.
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
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
The device is portable and is typically worn by the patient when not at a care
provider location
The device has a wireless interface which allows for remote troubleshooting
by hospital biomedical technicians as well as the device manufacturer
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
Using this basic set of design criteria, the next step in the process was to identify the
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
a direct indication of the features and functions they desire in a product or service.
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.
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
proposed that this element of the customer requirement planning matrix could be utilized
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
Ranking Scheme
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
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
Table 7
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
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
Table 8
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
Table Continued
Source Customer Requirements Design Category
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 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
Source Customer Requirements Design Category
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 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
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
Source Customer Requirements Design Category
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 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
Source Customer Requirements Design Category
FDA 2016 Cybersecurity risk management programs should include: Risk Management
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
FDA 2016 Cybersecurity risk management programs should include: Risk Management
understanding, assessing, and detecting the presence and
impact of a vulnerability
FDA 2016 Cybersecurity risk management programs should include: Risk Management
establishing processes for vulnerability intake and
handling
FDA 2016 Cybersecurity risk management programs should include: Risk Management
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
FDA 2016 Cybersecurity risk management programs should include: Risk Management
adopting a coordinated vulnerability disclosure policy and
practice
FDA 2016 Cybersecurity risk management programs should include: Risk Management
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
Source Customer Requirements Design Category
FDA 2016 Manufacturers should analyze possible threat sources Risk Management
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
Source Customer Requirements Design Category
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
Source Customer Requirements Design Category
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
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.
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 required characteristics for the IT network
incorporating the medical device
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 required configuration of the IT network
incorporating the medical device
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 technical specifications of the network
connection of the medical device including security
specifications
83
Table Continued
Source Customer Requirements Design Category
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 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
IEC 80001-1 For a medical device that can be connected to an IT Human Factors
network, the medical device manufacturer shall 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
Kraemer, The Computer Information System process, lifecycle and Human Factors
Carayon, & performance measures must be well defined
Clem, 2009
Kraemer, Project funding, schedules, and staffing must be adequate Human Factors
Carayon, &
Clem, 2009
84
Table Continued
Source Customer Requirements Design Category
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
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
ISO 13485 Clause 7.3.3 Design and Development Inputs provides the Quality Management
following requirements: System
Table Continued
Source Customer Requirements Design Category
ISO 13485 Clause 8.5.1 provides general requirements with regard to Quality Management
improvements. Specifically, this clause states: System
Note. Obtained from FDA, 2005, p. 5; FDA, 2016, p. 27; and ISO, 2016, p. 22-23, 34.
Table 12
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
Source Customer Requirements Design Category
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.
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
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
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
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
For a medical device that can be
with, other medical device(s), validation
connected to an IT network, the
shall include confirmation that the
medical device manufacturer shall
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
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
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
Table Continued
Category VOC Requirement
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
Table 14
was then derived from the essential design characteristics developed earlier in this
chapter for the fictional device. In addition, these technical requirements include basic
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
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.
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
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
Table 16
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,
one being assessed are ranked with the reciprocal of these same integer values. Figure 11
mathematics utilized for normalization and overall priority determination. This process
Figure 11. Mathematics for VOC Prioritization Using AHP. Developed by the author.
99
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
Table 17
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
Table which associates pairs of numbered requirements with each other under each of the
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 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
Figure 13. Methodology for Technical Priority Determination. Developed by the author.
103
The qualitative data questionnaire utilized for this study was intended to solicit
additional research information related to current and future techniques and perceived
requirements. Five central focus areas were included within the survey, based on the
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
much detail as possible for each response but to not reveal any specific devices or any
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
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
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.
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
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
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
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
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,
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
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
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
STUDY
Figure 14. PDSA Cycle Utilized for Cybersecurity QFD Matrix Development.
Developed by the author.
108
CHAPTER 4
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
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
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
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
concerns received less consideration. In this way, preferences were ranked higher for
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
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
Table 18
Table Continued
Category VOC Requirement Priority
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.
at ensuring overall patient safety in the event of a cybersecurity attack. Examples include
(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
preference levels.
With the VOC requirements prioritized, the technical requirements were then
(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
would be illustrated graphically as a roof structure directly above the main portion of the
House of Quality.
119
Table 19
Table Continued
Very
Strong Strong
Negative Positive Strong
No. Design Requirements Negative Positive
Positive
Table Continued
Very
Strong Strong
Negative Positive Strong
No. Design Requirements Negative Positive
Positive
Table Continued
Very
Strong Strong
Negative Positive Strong
No. Design Requirements Negative Positive
Positive
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
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.,
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
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
understood.
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
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
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
Examples include the VOC requirements associated with Resources and Training,
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
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
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
Table 20
Table Continued
No. Description Priority
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
Note. COTS = Commercial off-the-shelf. Developed by the author.
With the baseline QFD matrix completed and the technical requirement priorities
identified, the research questionnaire was examined under the Study phase. As noted in
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
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,
levels was observed and a significant amount of useful information was obtained.
Table 21
Table Continued
Organizational Years of
Profession Areas of Involvement
Focus Experience
related to each participant’s experiences and thoughts regarding current and future design
International Standards
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
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
Table Continued
Question Responses
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
Table Continued
Question Responses
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
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.
Allow more local control of detection and remediation for cybersecurity issues
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
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
interrelationships developed for the baseline matrix remained unchanged for the updated
matrix.
Table 23
Table Continued
Category VOC Requirement
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
Resources and Training
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
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,
Table 24
Table Continued
Category VOC Requirement Priority
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
Category VOC Requirement Priority
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
potentially support or detract from one another, it may be beneficial to examine the
interrelationships between such requirements using the same methodology that was
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,
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
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
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
the use of encryption and decryption techniques for information residing within the
The fundamental advantage of using the PDSA cycle presented in this study is
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
Table 25
Table Continued
No. Description Priority
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
Note. COTS = Commercial off-the-shelf. Developed by the author.
The next stage in the product development process would involve a determination
of which prioritized technical requirements should be carried into the subsequent Houses
characteristics, as were discussed in Chapter 2. This activity is left for further study.
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
future improvement.
The manner in which the VOC requirements were prioritized is a more logical
and consistent approach than what is being practiced currently.
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.
Summary
This chapter served to illustrate one possible methodology for completing the first
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.
several potential benefits over the methods currently being used for the collection,
CHAPTER 5
Summary
The thesis was developed in order to explore the application of established quality
best practices with regard to how such requirements are identified, prioritized, and
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
industry experts.
160
With the underlying quality methods and tools identified, the next step was to
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
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
vulnerabilities in a more holistic and consistent manner across the lifecycle of any
Conclusion
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
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
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
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
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
REFERENCES
Akao, Y., & Mazur, G. H. (2003). The leading edge in QFD: past, present and future.
Atugade, U. R., Awate, P. P., Shinde, M. S., & Harugade, N. V. (2016) Quality function
Banuelas, R., & Antony, J. (2004). Six sigma or design for six sigma?. The TQM
https://www.researchgate.net/profile/Jiju_Antony/publication/237090966_Six_Si
gma_or_design_for_Six_Sigma/links/566b518408ae430ab4f9c8ac.pdf
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
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
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1839424/pdf/AMIA2006_0166.p
df
Disterer, G. (2013). ISO/IEC 27000, 27001 and 27002 for information security
Eagles, S., & Wu, F. (2014). Reducing risks and recalls: safety assurance cases for
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
Retrieved from
http://eprints.dkit.ie/412/1/PID3398017%20ASSURE.pdf
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
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
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.
https://pdfs.semanticscholar.org/06c7/1331dbecf12572089ab2e8739ca169f523ad.
Guides, H. T., O’Brien, G., Edwards, S., Littlefield, K., McNab, N., Wang, S., & Zheng,
8/VolB/index.html
Gutzwiller, R. S., Fugate, S., Sawyer, B. D., & Hancock, P. A. (2015, September). The
and Ergonomics Society Annual Meeting (Vol. 59, No. 1, pp. 322-326). SAGE
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
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.
landwehr-ieee.pdf
16355-1).
Kansagra, D., Kumhar, M., & Jha, D. (2015). Ransomware: A Threat to Cyber Security.
1/35.%20Malaram.pdf
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
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
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
Retrieved from
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
http://www.forpath.org/glem/minutes/140905/Glem_140905_Cybersecurity_in_H
ealth_Care.pdf
room/whitepapers/bestprac/capability-maturity-model-derive-security-
requirements-1005
Reich, D., & McAleer, S. (2016, August 9). How to mitigate cybersecurity risks in your
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
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
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–
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).
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
https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/
GuidanceDocuments/ucm077823.pdf
172
U.S. Food and Drug Administration. (2013). Content of premarket submissions for
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
Medical Devices: Guidance for Industry and Food and Drug Administration Staff.
Retrieved from
https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/gui
dancedocuments/ucm482022.pdf
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4516335/pdf/mder-8-305.pdf
http://rdcms-
aami.s3.amazonaws.com/files/production/public/FileDownloads/HT_Cybersecurit
y/2011JF_CyberCrimes.pdf
APPENDIX
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.
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:
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?
11. DESCRIBE THE TYPE(S) OF CONNECTED MEDICAL DEVICES WITH WHICH YOU
HAVE EXPERIENCE. (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
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.