Medical Device Development

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/254303370
Supporting medical device development: A standard product design process

model
Article in Journal of Engineering Design · January 2012

DOI: 10.1080/09544828.2012.676635
CITATIONS READS
38 1,957
3 authors:
Lourdes A Medina Gül Kremer

University of Puerto Rico at Mayagüez Iowa State University
27 PUBLICATIONS 95 CITATIONS 319 PUBLICATIONS 2,096 CITATIONS
SEE PROFILE SEE PROFILE
Richard Wysk
North Carolina State University
238 PUBLICATIONS 4,090 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Commercial uses for Electrically Activated Silver View project
Measure + Innovate + Design + Act (MIDA): Promoting the Assessment of University’s Innovation and Entrepreneurship Ecosystems View project
All content following this page was uploaded by Gül Kremer on 01 August 2015.
The user has requested enhancement of the downloaded file.

Journal of Engineering Design, 2013
Vol. 24, No. 2, 83–119, http://dx.doi.org/10.1080/09544828.2012.676635
Supporting medical device development: a standard product

design process model
Lourdes A. Medinaa, *, Gül E. Okudan Kremerb and Richard A. Wyskc
a Department of Industrial Engineering, University of Puerto Rico, Mayagüez, Puerto Rico, USA; b School
of Engineering Design and Department of Industrial and Manufacturing Engineering, Pennsylvania State
University, University Park, PA, USA; c Department of Industrial and Systems Engineering, North Carolina
State University, Raleigh, NC, USA
(Received 5 November 2010; final version received 13 March 2012)
This article describes the complex nature of the medical device development (MDD) process and presents
a product design process model to aid designers engaged in MDD. Basically, the model serves as a
conceptual framework and provides a set of formalisms to define the development landscape for medical
devices. Specifically, the model describes the phases of MDD and their relationships, including the testing
and approval environment that impacts this process. The Food and Drug Administration (FDA) is an
essential part of this environment, acting as the regulatory agency for medical devices in the USA. FDA
approval is a significant milestone which industry developers must achieve before the actual release of their
devices in the US market. In this article, the relevant literature addressing the regulations and the MDD
process models are reviewed. The development and organisation of the model are discussed in detail with
descriptions of the building process, concepts, granularity, utility and overall contribution. The model is
the result of a documentation analysis and is supported by a content validation survey and a case study.
The model is proposed as an aid for designers to proactively use in handling the complexities of MDD.
Keywords: medical device; development process; product design; process model; regulation
1. Introduction
It is generally recognised that the effective execution of the new product development (NPD)
process affects the likelihood of success for new products in the market. Success in NPD is
explained as a function of multiple characteristics of the process itself along with the organi-
sation, culture, role/commitment of senior management and strategy (Ernst 2002). For medical
devices, the development process is more complex. Consistent with general product development,
an important part of medical device development (MDD) involves satisfying the needs of both the
customers and the development of the company. However, contrary to commercially non-regulated
products, MDD is performed within strict regulatory requirements that provide additional con-
straints for the development, manufacturing, marketing and continuous improvement of medical
devices. Attesting to this, the Food and Drug Administration (FDA) has been reported as the first
*Corresponding author. Email: lourdes.medina@upr.edu
© 2013 Taylor & Francis

84 L.A. Medina et al.
external factor affecting a company’s ability to develop new medical technology and influencing a
company’s product development priorities (Advanced Medical Technology Association 2003). In
the US, the FDA is the agency responsible for the regulation of medical devices. The FDA’s role
related to medical devices can be described as one of the risk assessment intended to strike a bal-
ance between assuring the complete safety and effectiveness of products, and ‘rushing a product
to market’, so that patients can take advantage of the latest technological findings (Maisel 2004).
Meanwhile, conducting an effective MDD process is also essential from a business perspective
as the device itself presents a risky investment opportunity with a high chance of failure due to
stringent regulatory processes and potential litigations.
While descriptions of the MDD process exist in the literature, current models tend to lack the
comprehensive elements needed to support medical device design teams having diverse back-
grounds and experience levels. In general, published work in this area either addresses the MDD
with a specific focus on regulations (Maisel 2004; Hamrell 2006; Pietzsch et al. 2007) or pro-
vides proposals for various MDD approaches (Alexander and Clarkson 2002; Aitchison et al.
2009; Pietzsch et al. 2009); however, these works are fragmented in that they fail to consider the
relationship between the two foci. In this article, we opt for a more comprehensive description
of the MDD landscape and thereby respond to this fragmented view in the literature, a viewpoint
concerned with potential negative implications about MDD’s effectiveness.
For the development of medical devices, empirical research has demonstrated the importance
of following a complete process, showing a significant correlation between the number of stages
followed in the development process and the success of the new devices (Rochford and Rudelius
1997). Effective communication about MDD priorities to the development team is also correlated
with success, where it is indicative of internal integration (Brown et al. 2008). In addition, team
experience influences the time-to-market of new medical devices, which is also related to success
(Lucke et al. 2009). Given the need for process completeness and effective communication, this
article presents a standard product design process model specific for MDD using conceptual
graphic representations. According to Bresciani and Eppler (2007), graphic representations are
recommended to enhance communication within knowledge-intensive teamwork settings.
The model presented can have various applications. First, it can be used as training material for
best practices of MDD. It can be used as a reference tool that start-up companies; novice designers
or experienced designers who are new to the development of medical devices can follow to gain
experience in the field. Second, the model can serve as a framework for enhancing a holistic
view of the MDD process, allowing current development processes to be examined for com-
pleteness and the inclusion of important considerations such as documentation and regulations.
Third, the model can provide process guidelines for implementing MDD; it offers a template that
designers can follow to handle the complexities of MDD and identify strategies for more effi-
cient development, as it analyses the entire MDD landscape and its inter-relationships. Finally,
the model can offer assistance for regulatory compliance. It has been developed for the regula-
tory environment in the US with specific attention paid to FDA regulation requirements. While
medical devices are regulated worldwide by a wide range of government agencies, the USA is
recognised as the global leader of MDD (Advanced Medical Technology Association 2004; FDA
2011a; PwC 2011). FDA is positioned so as to have implications for international markets within
the medical device and diagnostics industry (Advanced Medical Technology Association 2004).
Accordingly, we can assume that the model proposed is applicable to a wide range of MDD
practitioners.
The article is organised as follows. Section 2 provides a review of relevant literature that
discusses the regulations and presents previous MDD process models. Section 3 explains the
methodology followed in the development of the proposed model. Section 4 describes the devel-
opment of the conceptual model along with its validation, structure and use. Section 5 demonstrates
the utility of the proposed model with a case study, and Section 6 concludes the article.
Journal of Engineering Design 85
2. Literature review
FDA regulation is an essential element in the development of medical devices to be marketed in

the USA and much of the existing literature has paid particular attention to the FDA approval
process. Prior research also has proposed a variety of approaches for the development of medi-
cal devices. Together, the FDA regulations and the development process itself comprise the key
concepts of the model presented in this article, and thus, a summary of the prior works relevant
to these foci follows.
2.1. The FDA regulation
A significant part of the medical device literature includes reviews and summaries of the FDA
regulations with different objectives, which have provided the basis for numerous FDA publica-
tions. There are entire businesses surrounding compliance with FDA regulations. For instance,
Quality and Regulatory Associates, LLC is an example of an organisation dedicated to consulting
on FDA affairs, one that has also published an overview of the FDA’s medical device regula-
tion (Syring 2003). Summaries of FDA regulations are commonly generated with the objective
of informing specific stakeholders such as practicing physicians (Maisel 2004), manufacturers
(McAllister and Jeswiet 2003), or medical device engineers/designers (Munzner 1988). FDA
regulations also are reviewed in the context of specific facets or particular applications. Saviola
(2005) looks at the FDA’s role in clinical studies with human subjects and retinal visual pros-
thetic devices, while Ciarkowski (2000) describes the FDA regulation for medical devices having
automatic control systems. Other relevant topics involve the legal and ethical issues of regulation
(Malloy 2006); risk management to anticipate failures, manufacture safer products and reduce
liability cost (Bartoo 2003); ensuring the safety and effectiveness of medical devices through
market surveillance (Feigal et al. 2003; Bren 2006); and identifying improvement opportunities
for medical device regulations (Watson 1994; Foote 1996; Maisel 2005).
Pietzsch et al. (2007) provide one of the most general reviews to date, with a summary of the
many concepts related to medical device regulation and a discussion of contemporary issues such
as combination products (those that combine drugs and devices, or biologics and devices) and
the increasing efforts towards harmonising the regulations among countries. Several publications
have approached these issues in great detail. For instance, Eidenberger (2000) summarises the
regulation of medical devices in both European and US markets, focusing on agreements for
mutual recognition and their implications for global harmonisation.1 Hamrell (2006) highlights
the need for a more comprehensible review process and a better FDA organisation (multiple
centres may have to review one combination product) for combination products.
Combination products may incorporate nanotechnology implications. Paradise et al. (2009)
evaluate FDA regulations for drugs and medical devices that involve nanobiotechnology using a
historical case study approach. They conclude that: (1) the FDA is more reactive than proactive,
making changes largely in response to problems; (2) the continuous creation of new develop-
ments involving nano-products may require the FDA to make decisions about the applicability
of existing frameworks and/or the need for a new nanotechnology scheme, calling into question
the appropriateness of the FDA structure for nano-products; (3) there exist potential FDA-related
problems of transparency, relevant stakeholder representation, a lack of financial resources and
the need for a clear definition of ‘nano’; and (4) nanotechnology as an entity may become a critical
challenge that the FDA will have to contend with at some point, suggesting the potential for a
new product classification (neither a drug nor a device).
The incorporation of software in medical devices has become a popular topic motivating the
review of FDA regulations. Lin and Fan (2009) concentrate on the issue of software development
for FDA-compliant medical devices, providing a hybrid methodology for the application of a
Digital Subtraction Angiography device. Sudershana et al. (2007) address software development
from the perspective of collaborative distributed software projects and the challenges it presents
in an FDA-regulated environment, which include strict measures of verification and validation.
McCaffery and Coleman (2007) propose a software process improvement model – the Configu-
ration Management Capacity Model – for use in local and distributed development scenarios.
While the impact of the regulatory environment on the MDD is evident, prior work has focused
on regulations for specific applications and on the regulatory environment in general, while
neglecting to point out how and at what stage the regulations should be considered.
2.2. MDD process models
Numerous procedures have been proposed for the design and development of generic prod-
ucts. Ogot and Okudan-Kremer (2004) performed a comparative analysis of relevant literature
and defined five steps for the normative design process. These steps include: (1) needs
assessment/problem definition; (2) conceptualisation; (3) preliminary design and evaluation;
(4) detailed design and testing; and (5) production. Although the MDD process is very simi-
lar to this framework, the extensive regulatory control over medical devices presents the need to
develop separate, adaptive models for MDD. Medical devices impact human life by prolonging
it, sustaining it, improving it or supporting it. They can also represent a threat to human health
because of the potential risk of illness or injury. Consequently, medical devices are regulated by
government agencies worldwide. In addition to presenting varied submission requirements for
device approval/clearance into the market, FDA regulations stipulate that the definition of design
controls (as part of their Quality Systems (QS) regulation) be incorporated into the design and
development process to ensure that the design results are appropriate for the device’s intended use.
Given these motivations, the regulations must be considered at every stage of the development
process (Pietzsch et al. 2009), along with models developed to facilitate MDD.
Table 1 (see also Table A1) provides a comparison of Ogot and Okudan-Kremer’s normative
design process to other approaches for the MDD process. The vertical axis of the table shows the
different stages of the design process, with different publications compared throughout the hori-
zontal axis. Analysis indicates a relative consistency among all processes with Ogot and Okudan-
Kremer’s (2004) findings; however, each approach varies. Pietzsch et al. (2009) define the stage-
gate development process through the analysis of best practices and through in-depth interviews
with experts involved in the development, commercialisation and regulation processes. Alexander
and Clarkson’s (2002) approach focuses on the validation aspect of medical devices and provides
a model of design for validation. Panescu (2009) reviews the design process and addresses issues
such as intellectual property (IP) and FDA regulation. Aitchison et al. (2009) modify the design
process for the case of implantable orthopaedics and include specific methods for this application.
Finally, Das and Almonor (2000) provide an attribute-driven concurrent engineering approach for
the development of medical devices which includes customer, functional and regulatory attributes.
The literature also addresses a variety of tools and strategies used for the design, development
and manufacturing of medical devices. Eatock et al. (2009) surveyed the medical device industry
in an attempt to identify those tools and strategies that are used for varying company sizes (micro,
small, medium and large). These included: Quality Function Deployment (QFD), Design for
Manufacturing (DfM), stage gates, concurrent engineering, Lean Manufacturing, Six Sigma,
Total Quality Management (TQM), Failure Modes and Effects Analysis (FMEA) and Design of
Experiments (DoE).
The literature also addresses a variety of tools and strategies used for the design, develop-
ment and manufacturing of medical devices. Eatock et al. (2009) surveyed the medical device
Table 1. Comparison of MDD processes in the literature.

Normative
design process Comparison of medical device development processes in the literature
Ogot and Okudan- Alexander and Aitchison et al. Das and
Kremer (2004) Pietzsch et al. (2009) Clarkson (2002) Panescu (2009) (2009) Almonor (2000)
Needs assess- Predevelopment Funding Phase Development of the

ment/problem activities product concept
definition proposal
Formation of the core
development team
Conceptualisation Initiation/opportunity Device user needs/ Concept phase Feasibility Create attribute driven
and risk analysis develop verification specification table
requirements for device
Formulation/concept Design Development and approval
validation
and feasibility phase of the project plan
Device design/final device
verification
Preliminary design Design and develop- Process user needs/ Development phase Verification Product design/design
and evaluation ment/verification & develop verification control/ continuous
validation Phase requirements for Verification and Manufacture electronic
Detailed design and Validation phase
process validation Validation documentation
testing
Process design/final Process and clinical
process verification validation of the design
Production Final validation/product Production Production phase Design transfer Release product
launch preparation development/final (scale-up or
phase process qualification manufacturing
phase)
Product launch and Market release phase Design changes
post-launch
assessment
industry in an attempt to identify those tools and strategies that are used for varying company
sizes (micro, small, medium and large). These included: QfD, DfM, stage gates, concurrent engi-
neering, Lean Manufacturing, Six Sigma, TQM, FMEA and DoE. Although no conclusions about
specific methods are drawn, Eatock et al. provide valuable information about the industry, clas-
sifying their results as ‘expected and supported’, ‘not-expected and supported’ and ‘surprising’.
Selected findings include:
• Expected and supported: Large companies use a wide variety of tools/strategies in parallel,
while small companies lag in applying Lean, Six Sigma, stage gates and TQM;
• Not-expected and supported: Large companies prefer known technologies, while small
companies prefer new-to-the-world technologies;
• Surprising: Large companies prefer to perform major upgrades even though their success of
major upgrades is lower, while small companies have a high success rate for new-to-the-world
technologies.
2.3. Summary
The prior relevant literature addressing FDA regulations ranges from very broad reviews to the
discussion of very specific problems. Although the reviews provide a reasonable synopsis of
the approval process, they do not necessarily include the most recent regulation updates. In
contrast, the FDA publications provide current, up-to-date information, but create the need to
review numerous documents. The model proposed in this article includes FDA regulations from
a practical point of view to complement the development process. It describes what the require-
ments are and how to comply with them. The FDA concepts of the model, along with their
corresponding tables, provide a framework that designers can use to engage in a more effi-
cient search of the published FDA regulations, and thus generate a more efficient development
process.
Most previous process models include a form of graphical representation; however, these typi-
cally illustrate only the model described, and they correspond to a specific process point of view
exemplified in a series of steps. The model presented in this study, however, illustrates the overall
MDD landscape, which covers a larger scope of the problem. Moreover, the proposed model does
not suggest a particular approach, as found in prior literature; rather it defines the design concepts
so that they are applicable to any approach. This model thus provides a more comprehensive
framework for the development of medical devices.
Based on a comparison of MDD processes in the literature, the process can be summarised in
five broad steps:
(1) Clinical need definition and team formation. This phase involves the identification (through
customer surveys, direct observation, personal experiences and clinical literature reviews)
and selection of a particular clinical need (including customer and company needs). Decision
criteria for selecting a particular need may include company competency, target customer,
market environment, technology, competition, regulations, legal/IP landscape, reimburse-
ment strategy and finances. Following that selection, a business proposal is developed. Then,
a team is selected, incorporating a good representation of the different areas of expertise
necessary for the development.
(2) Feasibility, risk assessment and conceptualisation. This phase involves determining detailed
prior analysis elements – e.g. market, technologies, legal/IP, regulations – to serve as criteria
requirements for the development, verification and validation procedures. The design require-
ments are specified, including performance characteristics, product characteristics, market
characteristics and regulatory and quality requirements. Design concepts are developed along
with an early risk assessment to anticipate and control potential hazards.
(3) Detailed design, verification and validation. This phase involves the completion of a detailed
device design based on the requirements and concepts developed in the previous two phases.
It includes the development of models (i.e. computer-aided-design models or prototypes) that
will be used to analyse design alternatives and to perform verification and validation. Accord-
ingly, final specifications and detailed technical drawings are specified. Simultaneously, the
production specifications are defined, taking into consideration the fact that process redesign
can impact device requirements and vice versa. Verification procedures (tests, inspections and
analyses) are performed to ensure that the final design meets the defined requirements, while
validation procedures (clinical studies, stability studies and simulated use testing) are used to
ensure that the predefined clinical need is satisfied.
(4) Production planning and qualification. This phase involves the final validation of the man-
ufacturing processes and its documentation to verify that the product is manufactured in
agreement with the quality standards.
(5) Market introduction and post-launch. This phase involves finalising a variety of procedures
for product introduction into the market after FDA approval/clearance is obtained. Mar-
ket introduction activities include patent review, reimbursement strategy, product branding,
sales training and physician training. Post-launch activities follow the market introduction
and include post-market surveillance, quality audits, clinical validation and the continuous
improvement of products and processes.
3. Methodology
While models in the literature provide a foundation to understand MDD (Das and Almonor 2000;
Alexander and Clarkson 2002; Aitchison et al. 2009; Panescu 2009; Pietzsch et al. 2009), they do
not provide the level of detail required to describe the MDD landscape. This need motivated the
Figure 1. Methodology for the development of a product design process model for MDD.
development of a product design process model for MDD. This model contributes to the literature
with a very detailed representation that is intended to train and guide designers throughout the
MDD process and environment.
The development of the product design process model was a discovery process that required
multiple iterations. Figure 1 describes the process followed to develop the final model, which
included the following research methods: document analysis, model reviews, content validation
and case study. The document analysis consisted of compiling and reviewing numerous publica-
tions describing the MDD process and environment. Given the fundamental importance of the
regulations and the research focus of this study, the FDA literature was used for consistency. The
use of FDA literature helped to define the model terminology for common knowledge. Mean-
while, current models in the literature, e.g. Pietzsch et al. (2009), helped to verify the use of the
terminology by the industry.
The document analysis provided the first iteration of the model. A second iteration of the model
was developed after broadening the document analysis and performing a model review. At this
point, additional literature was gathered and the first iteration of the model was reviewed to verify
its completeness, terminology correctness and redundancy. Finally, the third/final version of the
model was developed after a model review based on the results from the content validation with
subject matter experts (SMEs). The model was also validated with a case study that tested the
implementation of the model.
There are no guidelines to validate conceptual models; however, one can establish credibility
with evaluations from SME and exploration of cases (Macal 2005). While the content validation
justified the model from the perspective of SME, the case study validated the model use for
inexperienced developers who are new to medical devices. The content of the model was validated
by SMEs following Lawshe’s (1975) quantitative approach to measure content validity. A three-
part, 20-item questionnaire was used for data collection from SMEs. The first part assessed the
SMEs level of experience with MDD. The second part tested the content validity of particular
concepts of the model – for example, the SMEs indicated if a specific item is ‘essential’, ‘useful
but not essential’, ‘not necessary’ or ‘other’. The third part involved questions about the model as
a whole. In this approach, a content validity ratio (CVR) was calculated using Equation (1), where
ne is the number of answers as ‘essential’, and N is the total number of answers. A modification
of this equation was also used (Equation (2)), where nu measures the answers as ‘useful but not
essential’. Overall, the content validation was performed to ascertain that only essential and useful
information is included in the model. The final model was developed after the content validation
to reflect the results, which required further refinement of the model to eliminate unnecessary
information and improve its usability.
ne − N
CVR = N
2
(1)
2
Figure 2. Case study methodology.
(ne + nu ) − N
CVR = N
2
(2)
2
The case study complemented the content validation, showing a use case of the model in
a real MDD scenario. Case studies in the literature only make reference to some parts of the
process and do not show complete implementations of their models. For example, Linehan et al.
(2007) developed a model to explain the Stage-Gate Process of MDD but did not demonstrate
the implementation of their model. They presented short case studies to provide reference of
some of the phases and activities described in their model, and to highlight the importance of
technology users, regulatory and reimbursement constraints. Alexander and Clarkson (2002) also
made reference to a case study to explain that the use of design tactics helps to make a pro-active
validation of medical devices.
An academic setting was selected to demonstrate the validity of the model for the following
uses: (1) as training material/best practices for MDD, and (2) to provide process guidelines for
implementing the MDD process. The case study was executed through a semester project where
a design team was sponsored by a biomedical company to improve an existing product.
Figure 2 describes the case study methodology. The case study started with a training session
where the design team was introduced to the model. At this session, the model was explained
in detail and training material was provided. Then, the data process was divided into two parts.
While observations of the model implementation and MDD were compiled throughout the project
execution, various question and answer (Q&A) sessions and model assessments were performed.
Model assessments involved the completion of two questionnaires by each member of the design
team (administered independently). These assessments measured the (1) perceived usability of
the model, and (2) actual model use. In addition, general comments/opinions were recorded to
assess the model implementation from the user’s point of view.
The perceived usability was measured with the System Usability Scale (SUS) questionnaire,
which is a validated method (Brooke 1996; Bangor et al. 2009; Sauro 2011). The results were
evaluated using SUS score (Equation (3)), which provides a single value between 0 and 100. A
similar approach was used to measure the model use, where a score (Equation (4)) was developed
to have a value between 0 and 100.
10
SUSscore = 2.5 Si (3)
i=1
100
n
Model usescore = Si (4)
4n i=1
4. Product design process model
4.1. Development of the conceptual model and validation
The basis for our model is firmly grounded in a document analysis of the MDD literature. The doc-
ument analysis involved the same process used by Storga et al. (2008) in their ontology building
Table 2. Model relationships.
Relationship (UML notation) Meaning
A Generalisation - inheritance, “is a”

B
relationship
A B Association – related with a verb
A B Aggregation – “has a” relationship
Composition – being part of a whole

A B where the part does not exist by itself
1
Dependency – demonstrates that a class
A B
depends from other
process. Relevant publications by domain experts were collected and analysed to extract critical
information. This process included the: (1) identification of concepts and terminology, (2) cat-
egorisation of concepts and (3) definition of relationships among concepts. The documentation
analysis involved 287 relationships. It provides in detail all the relevant concepts, type of rela-
tionships, impact and evidence. The impact category provides an additional explanation to justify
the relationship.
An essential part of this analysis included analysing source credibility to verify the validity of
the information. Well-founded and credible sources are used to derive evidence for the definitions
of concepts, categories and relationships. Particular emphasis is given to FDA publications, which
are the primary information sources for regulatory approval. The credibility of sources such as
books and journal articles is verified according to authorial experience in the field and the number
of publications. Information showing consistency with data from FDA publications is preferred.
An example of a reliable source for this analysis includes a book published by an expert having
(a) 36 years of industrial experience (13 as a consultant) in the development, manufacture and
marketing of medical devices, (b) experience in a broad range of areas (e.g. technical operations,
regulation, licenses and acquisitions, market development, clinical studies, manufacturing and
product development), (c) positions at eight different companies and membership on the Board
of Directors at three of them, (d) several patents and (e) two textbooks plus numerous business
and technical articles.
The model was developed using the Unified Modelling Language (UML) relationships from
UML’s class diagram. UML is a well-known general-purpose modelling language. Microsoft
Office Visio 2007 is the specific software used to develop the final model. The UML relationship
symbols used in this study and their meanings are summarised in Table 2.
Table 3 and Figure 3 illustrate a simple example of the documentation analysis and the creation
of the model. The table shows four relationships, each describing a concept within the FDA
regulations. From these relationships, the model is manually generated. This particular example
uses four different types of UML relationships:
(1) FDA regulates medical devices (association related with the verb ‘regulates’);
(2) Centre for Devices and Radiological Health (CDRH) is part of FDA (following the principle
of compositions – CDRH does not exist if FDA does not exist);
(3) CDRH has a classification for generic types of devices (following the ‘has a’ relationship of
aggregation); and
(4) Classification for generic types of devices depends on the medical specialty (demonstrating
that a class depends on the other).
Table 3. Document analysis results example for FDA-related information.
Proposed
Class A relationship Class B Impact Evidence
FDA regulates Medical Devices Requirements to assure that devices FDA (2010)
(association) are safe and effective. FDA (2009a)
CDRH is part of FDA Part of FDA ‘responsible for FDA (2009b)
(composition) regulating firms who manufacture, FDA (2009c)
repackage, relabel, and/or import
medical devices sold in the US’
(FDA 2009a).
CDRH has a (aggregation) Classification for ‘Generic type of device means a FDA (2009d)
generic types of grouping of devices that do not FDA (2009e)
devices differ significantly in purpose, FDA (2011b)
design, materials, energy source, FDA (2009c)
function or any other feature
related to safety and effectiveness,
and for which similar regulatory
controls are sufficient to provide
reasonable assurance of safety and
effectiveness’ (FDA 2011b). ‘The
name and product code identify the
generic category of a device for
FDA’ (FDA 2009e).
Classification for are grouped by Medical The grouping by medical specialty FDA (2009d)
generic types of (dependency) specialties facilitates the review process and
devices the use of review panels. Devices
in one generic type classification
will be under the same medical
specialty.
Figure 3. Model example for FDA-related information.
Table 4 and Figure 4 illustrate a similar example for the medical device records with a dif-
ferent type of relationship. The generalisation relationship is used to demonstrate the concept of
inheritance (‘is a’ relationship) to describe the medical device records.
Table 4. Document analysis results example for medical device records.
Class A Proposed Relationship Class B Impact Evidence
Design History is a Medical The Design History File is a compilation of Fries (2001)
File (DHF) (generalisation) device records that describes the design history of a
records finished device. It covers the design activities
used to develop the device, accessories,
major components, labelling, packaging and
production processes (Fries 2001).
Device Master is a Medical The Device Master Record is a compilation of Fries (2001)
Record (generalisation) device those records containing the specifications
(DMR) records and procedures for a finished device. It is
set up to contain or reference the procedures
and specfications that are current on the
manufacturing floor (Fries 2001).
Device History is a Medical The Device History Record is the actual Fries (2001)
Record (generalisation) device production records for a particular device. It
(DHR) records should be able to show the processes, tests,
rework, etc. that the device went through
from the beginning of its manufacture through
distribution (Fries 2001).
Technical Doc- is a Medical The Technical Documentation File contains all Fries (2001)
umentation (generalisation) device the relevant design data by means of which
File (TDF) records the product can be demonstrated to satisfy
the essential safety requirements which are
formulated in the Medical Device Directives
(Fries 2001)
Figure 4. Model example for medical device records.
Multiple versions of the model were generated as part of the iterative process. Figure 5 shows
the first version of the model created during the document analysis. The second version, Figure 6,
is the result of iteration to review completeness, terminology correctness and redundancy. At
this point, the structure of the model was adapted to allow reading from left-to-right rather than
center-to-side. The final model (Figure 17) was developed after merging content validation to
reflect the survey results, further refining the model to make it easier to read.
The model is divided in five clusters according to information type. Table 5 specifies the different
clusters, and corresponding gray tones identify each cluster in the diagram.
The content validation survey was conducted with 19 MDD SMEs, who collectively covered
89% of the various medical specialties. Their experience with MDD ranged from 2 to 26 years,
with 68% of them having 10 or more years of experience. Every stage of the MDD process was
represented by the SMEs; there were 14 representing ‘Clinical Need Definition and Team For-
mation’, 18 for ‘Feasibility, Risk Assessment and Conceptualisation’, 17 for ‘Detailed Design,
Verification and Validation’, 15 for ‘Production Planning and Qualification’, 8 for ‘Market Intro-
duction’ and 7 for ‘Post-Launch’. In addition, 90% of the various areas of responsibility were
covered, and the majority of SMEs selected R&D as one of their primary roles throughout their
careers in MDD.
Tables 6 and 7 display content validation results from the survey with the CVR values calculated
from Equations (1) and (2). The CVR yields a value between -1 and +1. A positive CVR means
that at least 50% of the SMEs identified the item as essential. The results include CVR values for
two scenarios: ‘essential’ and ‘essential & useful’, They show high-positive values for all clusters
94
L.A. Medina et al.
Figure 5. First model iteration.
Journal of Engineering Design
Figure 6. Second model iteration.
Source: Medina et al. (2011).
95
Table 5. Model clusters.
Cluster
Product Development &

Introduction Process
Medical Specialties
FDA
Standards
Patents
Table 6. Content validation results by cluster.
Content Validity Content Validity Percentage

Ratio Ratio (CVR) of
Cluster Concept (CVR) Essential Essential & Useful Completeness
FDA 0.8 1.0 91%

Classification of generic type of 0.4 1.0
devices(Product Code. RN)
Regulatory class (I. II. III) 0.6 1.0
Submission (e.g. PMA. 510(k)) 0.8 0.9
General controls 0.2 0.9
Special controls 0.1 0.9
Good manufacturing practices/quality 0.6 1.0
systems regulation
Standards 0.5 0.9 85%
Organizations/committees −0.5 0.6
Test method standards 0.3 0.8
Material specification standards 0.3 0.8
Device standards 0.5 0.9
Procedure/guidance standards 0.2 0.9
Medical specialties −0.2 0.7 89%
Patents (lP in general) 0.1 1.0 89%
Patent qualifications (e.g. useful, novel, 0.2 0.9
patentable. etc.)
Utility patents 0.1 1.0
Design patents 0.2 0.9
Plant patents −0.3 0.4
Product development & introduction process 0.7 1.0 89%
Product definition 0.9 1.0
Design 0.9 1.0
Risk management 0.8 1.0
Production planning 0.6 1.0
Market introduction & post-launch 0.3 1.0
Medical device records 0.7 0.9
Overall model 90%
and for most of the concepts within clusters. Note that plant patents are highlighted in Table 6
with a low-content validity (0.4); however, this is an expected result given that plant patents do
not apply to medical devices.
In the comprehensive assessment, SMEs were asked to rate both the completeness of the model
and its uses. Table 6 shows that the overall model was evaluated at 90% completeness on average,
with all the cluster completeness ratings at more than 85%. In addition, the majority of SMEs
Table 7. Content validation results for product development and introduction processes.
Product development CVR- CVR-

& introduction processes Concept essential essential & useful
Product definition 0.9 1.0

Clinical needs identification 0.9 1.0
Competencies analysis 0.1 0.9
Customer analysis 0.9 1.0
Market analysis 0.7 1.0
Technology analysis 1.0 1.0
Competitive analysis 0.4 1.0
Regulatory analysis 0.7 1.0
Legal/lntellectual property analysis 0.7 1.0
Reimbursement strategy 0.3 0.8
Financial analysis 0.5 0.8
Product life cycle 0.2 0.9
Design 0.9 1.0
Design/development plan 0.9 1.0
Design inputs 0.9 1.0
Design outputs 0.8 1.0
Prototype developments & design analysis 0.8 0.9
Design review 0.9 1.0
Design verification 0.9 1.0
Design validation 1.0 1.0
Risk management 0.8 1.0
Risk identification 0.8 0.9
Risk analysis 0.8 0.9
Risk control 0.9 1.0
Risk monitoring 0.9 1.0
Production planning 0.6 1.0
Design transfer 0.6 0.9
Process validation (retrospective & prospective) 0.6 0.9
Market introduction & post-launch 0.3 1.0
Physician training 0.5 0.9
Post-market surveillance 0.7 0.9
Quality audits 0.7 1.0
Clinical validation 1.0 1.0
Product continuous improvement −0.2 0.9
Process continuous improvement −0.2 0.9
Table 8. Model uses validation.
Model uses % Disagreement % Neutral % Agreement
Training material/best practices in medical device 5 26 68

development
Framework for process improvement 5 21 74
Process guideline for implementing the medical device 5 5 89
development process
Assistance for regulatory compliance 16 5 79
agreed that the uses defined for the model were appropriate (Table 8), with a very low percentage
of disagreement (5–16%).
4.2. Model structure and use
The model describes the landscape of MDD by defining essential elements of the environment
and specifying the product development/introduction processes. Using well-established relation-
ships, the model provides additional information and exhibits a higher degree of detail than do
other graphical representations currently in the literature. The environment is described from a
practical point of view, including concepts (grouped by clusters) of the FDA regulations, patents as
IP protection (US Patent and Trademark Office) and consensus standards. Figure 7 demonstrates
two clusters of the model: FDA regulations and the medical specialties. The former cluster corre-
sponds to the logic designers should follow for classifying their devices in determining applicable
regulations and requirements (that is, it follows a classification logic composed of various levels),
while the latter cluster consists of a simple listing of the different specialties defined by the FDA.
While the literature has paid particular attention to the regulations affecting medical devices,
the use of standards and patents is less frequently addressed. The employment of standards is
voluntary; however, they provide multiple advantages to medical device applications includ-
ing: (1) providing assistance during FDA approval to expedite the review process; (2) serving
as guidelines for testing and creating of materials and devices; (3) providing a summarised
description of newly developed products for sale purposes; (4) simplifying and harmonising
the industry as a whole; (5) providing confidence to product users and (6) re-producing or veri-
fying results in the case of standard test methods (Duncan et al. 2004). Our model (Figure 8)
delineates the different types of standards with descriptions and relationships. An example
of one of these relationships is ‘Device standards make reference to material/specification
standards’.
Patents are also relevant to MDD.Although they are an important aspect of product development
in general, they have also been recognised as a healthcare issue. According to Gold et al. (2009),
the existing patent system has caused increases in healthcare cost and decreases in the level of
innovation, particularly within the pharmaceutical industry. Patents are used to protect specific
drugs, while in MDD only the basic principle is protected as specific devices are usually non-
patentable (Kahn 1991). However, large-medical device manufacturers take advantage of patent-
protected devices to benefit from price increases (Gold et al. 2009). In addition, Gold et al. note that
the cost of R&D is affected by the existence of patents when researchers must clear patent rights
to pursue product development. The model (Figure 9) incorporates general information about
patents (including types, qualifications and their relationships) to account for their relevance to
MDD.
A significant part of the model is dedicated to the development/introduction cluster (Figure 10),
which contains an extensive range of processes. These are summarised at the highest level as
follows: (1) product definition process, (2) design process, (3) risk management process, (4)
production planning process, and (5) market introduction and post-launch process. This cluster’s
Figure 7. FDA’s and medical specialties clusters.
Figure 8. Standards cluster.

Figure 9. Patents cluster.
Figure 10. Development/introduction cluster.
product definition process (Figure 11) is very broad, incorporating different types of analyses
such as competencies analysis, market analysis and financial analysis to help develop a product
proposal. Conversely, the cluster’s concepts for the design process (Figure 12) are very specific
and mostly defined using FDA terminology, reflecting its subjectivity to good manufacturing
practices/quality systems (GMP/QS) regulations.
The cluster’s risk management process (Figure 13) includes four fundamental steps (identifi-
cation, analysis, control and monitoring), paralleling that of the design process. Its production
planning process (also Figure 14) is focused on the validation of the manufacturing processes.
Finally, the market introduction and post-launch process (Figure 15) is executed using steps in
tandem with those of the design process. A variety of medical device records (Figure 16) are kept
as necessary documentation for multiple purposes. In conclusion, Figure 17 illustrates the final
Figure 11. Development/introduction cluster – concepts of the product definition process.
Figure 12. Development/introduction cluster – concepts of the design process.

Figure 13. Development/introduction cluster – risk management process.
Figure 14. Development/introduction cluster – production planning process.
Figure 15. Development/introduction cluster – market introduction & post-launch process.
Figure 16. Development/introduction cluster – medical device records.
model assembly, including relationships between clusters such as ‘FDA recognises consensus
standards’.
The model includes different levels of granularity, following a hierarchical approach to differ-
entiate among these levels. This modification resulted from the review process for usability, where
the model structure was re-designed to follow a left-to-right and top-to-bottom logic (Figure 17)
to be consistent with the way in which we tend to read and write. This methodology is supported
by Yusuf et al.’s (2007) assessment of UML class diagrams comprehensiveness with eye-tracking
equipment, which concluded that novices like to navigate and explore UML diagrams from top-
to-bottom and left-to-right. Considering the diagrams by cluster, higher level (less granular)
components are on the left side, while lower level (higher granularity) components are on the
right side. Likewise, the granularity may increase downward for some of the components along
the right side. A good example of the granularity hierarchy is the initial development/introduction
cluster (Figure 10), where the main processes are specified and then divided (moving towards
the right side of the diagram) into sub-processes. These processes are then further disaggregated
(e.g., Figure 12) into more specific descriptions.
This overall model granularity is appropriate for designers to help them understand and further
use the model for application with a particular MDD. The model’s highest level of granularity
includes a description of specific requirements through the use of explanatory notes. A more
detailed approach would involve specifying particular physical properties; these will be dependent
on the specific medical device application.
This proposed standard product design process model supports MDD by detailing the require-
ments and how to comply with them. For instance, FDA regulation requirements are specified
at a high level, and the model is organised to show compliance methods. The model indicates
that the initial step is to identify the classification of the device in order to ascertain its regu-
latory class and the type of submission. In addition, the use of standards is recommended to
Figure 17. Final product design process model for medical devices.
101
facilitate compliance with regulation requirements. The model follows linearly, specifying which
processes to go through and providing the guidance to complete these; for example, some of the
recommendations for design verifications include biocompatibility tests in tandem with FMEA.
In summary, this research provides a product design process model as a visualisation aid for
designers to use proactively in handling the complexities of MDD. The model provides a set
of formalisms to define the critical factors for MDD, along with their relationships. It includes
information about the medical device environment (regulations, patents and standards) at a high
level. Simultaneously, the development and introduction processes are defined with great detail
for ease of application with MDD in general. Two of the model’s shortcomings are that absolute
completeness cannot be guaranteed and that the model is not generated automatically. However,
the model provides a generalised approach that can be customised with a greater level of detail
for specific device developments. Furthermore, the model is designed to support MDD through
training, process improvement, process implementation and regulatory compliance.
5. Case study
The implementation of the model is tested in an academic setting as part of a capstone design
course, where a biomedical company (sponsor) requested the re-design a laparoscopic surgical
instrument. The medical device studied is novel and a state-of-the-art technology developed for
laparoendoscopic single-site surgery (LESS). This is one of the most recent approaches to make
minimally invasive surgeries truly minimal with the transition from multiple to single port access
surgery (Kommu and Rane 2009). LESS improves the quality of life of patients with smaller
incisions and shorter recovery times. The design team was responsible to re-design this instrument
to improve its performance, which is a critical part for LESS feasibility.
The design team was asked to use the proposed model as a process guideline for implement-
ing the MDD process in their project. Figure 18 summarises the timeline, the weekly progress
of course activities and the MDD process. The left side of the timeline also explains activities
relevant to the model, which included the initial training session (week 3), follow-up meetings
(weeks 4 and 6) and assessments (weeks 8 and 13). The completion of important MDD processes
and milestones are documented to the right side of the timeline. Some of the major tasks included
planning (weeks 2–3), completion of the product definition process (weeks 3–6), concept gen-
eration (weeks 6–7), design reviews/verification (weeks 7–9) and production of parts with rapid
prototyping (weeks 11–13).
5.1. Model assessment
Assessments of the model were performed with three questionnaires to evaluate the model’s per-
ceived usability, specific uses and observations from the users. These assessments were performed
twice in the semester, 5 weeks apart. These assessments included a: (1) mid-project assessment
after the concept generation/design reviews/design verification, and (2) end-of-project assess-
ment after the detailed design specifications. The perceived usability of the model was tested
using the SUS. SUS is a standardised and validated method that can be used to assess the usability
of almost any user interface (Brooke 1996; Bangor et al. 2009; Sauro 2011). The questionnaire
included 10 statements assessed using a Likert scale where the user specifies their degree of
agreement or disagreement. The results were quantified with a single score that ranged between
0 and 100. This score measures the perceived usability, where higher scores represent a higher
perceived usability.
Table 9 summarises the SUS score results for the mid-project (M) and final-project (F) assess-
ment. User 1 results had a SUS scores of 65 (M) and 90 (F) for the perceived usability of the
Figure 18. Weekly MDD progress.
model. Based on Bangor et al.’s (2009) evaluation of SUS scores (Figure 19), a score of 65 can be
interpreted as marginally acceptable in acceptability ranges, with a D grade and between ‘ok’ and
‘good’ in adjective ratings. Meanwhile, a score of 90 means it is acceptable, with A-grade, and
above ‘excellent’. On the other hand, user 2 obtained scores of 75 (M) and 70 (F). A score of 75 is
interpreted within the acceptable range, with a C grade and ‘good’, while a score of 70 means that
the usability of the model is still acceptable, with a D+ grade and almost ‘good’. Overall, usability
scores were between 65 and 90 which are all between an acceptable range of D to A-grade and
‘ok’ to ‘excellent’ rating (Bangor et al. 2009).
Table 9. Mid-project (M) / final-project (F) assessments – SUS results.
Assessment score per question (Si)∗
Question User 1 (M/F) User 2 (M/F)
1 I think that I would like to use this model frequently 3/4 2/3
2 I found the model unnecessarily complex 2/2 3/3
3 I thought the model was easy to use 4/4 4/3
4 I think that I would need the support of a technical person to be 0/3 3/3
able to use this model
5 I found that various functions in this model were well-integrated 4/4 4/3
6 I thought there was too much inconsistency in this model 4/4 4/3
7 I would imagine that most people would learn to use this model 3/4 3/3
very quickly
8 I found the model very cumbersome to use 2/4 1/3
9 I felt very confident using the model 3/4 3/3
10 I needed to learn a lot of things before I could get going with 1/3 3/1
this model
SUS Score (2.5∗ Si )∗∗ 65/90 75/70
∗
Value between 0 and 4
∗∗
M = mid-project assessment; F = final-project assessment
Potential answers:
Strongly Disagree Neither agree Agree Strongly
disagree nor disagree agree
Figure 19. A comparison of the adjective ratings, acceptability scores and school grading scales, in relation to the
average SUS score.
Source: adopted from Bangor et al. (2009).
For most of the cases, scores between the mid- and final-project assessments were consistent.
For user 1, the final-project assessment resulted in a higher SUS score due to increases in the
scores for the different questions. Meanwhile, user 2 had a decrease in the score. This decrease is
explained by Questions 3 and 10 where the user still found the model easy to use (answer from
‘strongly agree’ to ‘agree’) but had to learn many things to get going with the model (answer from
‘agree’ to ‘disagree’). These changes in answers are not a big concern, with low impact on the
SUS score results.
The scores for the independent questions in the mid-project assessments are explained further
given that this assessment is weighted higher as it represents the first impression from the users.
User 1 neither agreed nor disagreed that the model is unnecessarily complex (Question 2) and
explained that there are pros and cons to this complexity. The user explained that although one
single person will not go through the whole process, the model provides a complete understanding
of MDD. To increase the ease of use (Question 3), a determining factor for a good score was that
the model was developed with a standardised language, UML. On the other hand, lower usability
was observed when the user indicated the need: (1) for a knowledgeable person to support the
model use (Question 4), and (2) to learn many things to implement the model (Question 10). The
user attributed these needs to the model complexity and the technical jargon of MDD. Accordingly,
support was given throughout the duration of the case study with a training session at the beginning
and various Q&A sessions.
Explanations were also gathered for the mid-project assessment from user 2, which in com-
parison to user 1 showed few contradictions. The frequency of the model use (Question 1) was
rated lower, given that the user considered the model to be a guideline for starting the MDD
process and for clarifying questions as the process proceeds. The user considered the model to be
a good tool to have in order to see the inter-relations of the different processes and understand how
everything fits together. In addition, user 2 found the model cumbersome to use due to the level
of details that makes it overwhelming at times. At this point, the user remembered the training
session, indicating that he/she liked it when the model was broken down in parts and noted this
point.
In comparison with user 1, user 2 did not find the need for a knowledgeable person to support
the model use (Question 4). Likewise, user 2 did not need to learn many things to implement the
model (Question 10). To explain this, user 2 indicated that ‘If you sit down and look at it, you
will be able to figure it out; however, it definitely helps to have someone (helping to interpret the
model) but it is not necessary. With the arrows, it is kind of a flowchart where you can follow what
is going on. I had to search some terms, but not a lot’. However, this changed in the final-project
assessment where user 2 indicated a need to learn things in order to use the model.
Besides the usability test, the model was assessed in more detail based on specific model
concepts (Table 10) and the general use of the model (Table 11). The model was evaluated with a
score between 0 and 100, which was developed to be consistent with the SUS score calculation.
The first part of this analysis (Table 10) had scores of 82 (M) and 100 (F) for user 1, and 86 (M)
and 89 (F) for user 2. This analysis demonstrated that for most of the cases, the model increased
the user’s level of understanding to implement the different model concepts. However, the results
Table 10. Mid-project (M) / final-project (F) assessments – model use results part I.
1 After using this model, my understanding of the implementation 4/4 4/4

of the medical device development process is
2 After using this model, my understanding for the implementation 2/4 4/4
of the product definition process is
of the design process
of risk management is
of production planning is
of market introduction & post-launch is
7 After using this model, my understanding to deal with the 4/4 4/4
medical device development environment (regulations,
patents, standards) is
Score (3.57143∗ Si )∗∗ 82/100 86/89
∗
∗∗
M = mid-project assessment; F = final-project assessment
Potential answers:
Much Slightly About the Higher Much
lower lower same higher
Table 11. Mid-project (M) / final-project (F) assessments – model use results part II.
8 In future medical device design projects using this model will be 4/4 3/4
Not Slightly Moderately Very Extremely
beneficial beneficial beneficial beneficial beneficial
9 The model needs −−−−−− improvements 4/4 4/3

Not Slightly Moderately Many Extreme
10 The model −−−−−− following a complete and proficient medical 4/4 3/3
device development process
Very rarely Rarely Occasionally Frequently Very frequently
enhanced enhanced enhanced enhanced enhanced
11 My experience in medical device development is −−−−−− by the 4/4 3/4

use of this model
Much Slightly About the Higher Much higher
lower lower same
12 My communication throughout the development process was 4/4 3/3

−−−−−− by the use of the model
Very rarely Rarely Occasionally Frequently Very frequently
enhanced enhanced enhanced enhanced enhanced
13 The use of this model made my learning in the course 4/4 3/3
Much Slightly About the Higher Much
lower lower same higher
Assessment of the model’s intended uses

14 Training material/best practices in medical device development 4/4 4/4
15 Process guideline for implementing the medical device 3/4 3/3

development process
Score (3.125∗ Si )∗∗ 97/100 81/84

∗
∗∗
M = Mid-project assessment; F = Final-project assessment
were subject to the current knowledge of the users. For example, the level of understanding
to implement the product definition process (Question 2 – user 1) was ‘about the same’ in the
mid-project assessment due to user 1’s prior learning in other courses. However, this level of
understanding increased for the final-project assessment.
User 2 expressed no change in the level of understanding in the mid-project assessment for
the risk management process, given that it was not implemented yet. However, for the final-
project assessment, user 2 indicated an increase in their understanding on the risk management
process after its implementation. Other observations included that the model provides a detailed
description of the design process (Question 3-user 1) and a gain in understanding about the
MDD environment. Overall, the model provided users with a direction to search and use of
appropriate terminology. They learned the MDD landscape and the interactions/impact between
its processes.
Assessing the general use of the model (Table 11) also provided good results, with scores of
97 and 100 for user 1, and 81 and 84 for user 2. The difference in scores was due to multiple
selections in the positive side of the scale, e.g. between agree/strongly agree, extremely/very
beneficial. However, both users recognised that the model (1) will be beneficial for future MDD
projects, (2) required no major improvement, (3) enhanced their understanding to follow a
complete/proficient MDD, (4) increased their level of experience, (5) enhanced their commu-
nication and (6) increased their learning in the course. The users also showed agreement with the
model’s intended use as training material and a process guideline for implementation. In addition,
Question 12 was clarified to verify the correct interpretation of the term ‘communication’. User
1 explained that using the model makes it much easier to communicate with teammates, while
user 2 described it as an aid to learn the vocabulary to communicate and progress throughout the
process.
5.2. Model implementation
The users’ observations were also gathered to gain insights about the implementation of the model
from the users’ point of view. Table 12 summarises the users’ thoughts about the overall model
and specific concepts of the model. They explained how the different concepts applied to their
project and how they would go about implementing the concepts that were outside the scope of
their project. Benefits of the particular model concepts were noted.
The overall model helped the users as a guidance tool at the planning stage (e.g. Gantt chart and
reports) and to implement the MDD process. For the MDD environment, the process steps were
mapped for them to provide an initial understanding to go through the regulations, standards and
patents. The clinical needs identification was an important part of the process, where information
was gathered through multiple sources: meeting with the sponsor, site visits, videos and team
meetings. The analysis of the needs was complemented with the analysis of the technology,
completion and patents. Other significant part of the process included the iterations between
design inputs and outputs for concept generation. This process also included design reviews and
design verification.
The design team investigation started at the front-end of the development process. The product
requirements were initially specified in detail by the company; however, the design team had to
further study the product given its complex mechanism. To understand the product and the design
requirements, the design team watched videos of surgeries and met with the company. Some of the
topics discussed with the company included: (1) identification of materials, (2) requirements and
problems with the current model and (3) explanation of the mechanism, product specifications
and particular components. The main objective of such meetings was to learn from the company’s
experience, prior research/iterations of the product. Meanwhile, the company representatives
explained the context of use of the product – where for this type of surgery, the surgeon has many
instruments in his/her hands. Accordingly, the re-design of the instrument should not require
additional burden to the surgeon. While the company representatives tried to clarify questions
about the current model characteristics, they did not want to provide too much information to
avoid restricting the design team ideas.
The technology analysis supported the tasks of understanding the clinical need and require-
ments. The technology was analysed through the observation of CAD drawings and other products
in the market. In fact, analysing other products in the market raised questions about unspecified
product characteristics. While other laparoscopic instruments in the market are disposable, it is
clear that the product under study was reusable. The instrument was too expensive to be disposable
given its complex mechanism and materials. However, this finding revealed other issues of MDD
– how this product would be cleaned and sterilised after a surgery.
Table 12. Model implementation comments from users.
Model concept Observations from users
Overall model The model was used to plan the project steps as part of the definition of tasks in the Gantt
chart. It was used to plan the whole design process and to have a clearer idea of what needed
to be done. Overall, it was the inspiration, framework and taxonomy used to drive the MDD
process.
The model was used to verify the information to be included in the reports: SOW and DSR. It
was used as a reference to write the reports and use the right terminology.
The model was a good place to go to clarify questions about the MDD landscape.
The model helped to keep track of the progress of the project in order to understand what
has been completed and what is remaining. It also provided a perspective of the challenges
remaining for the product commercialisation.
We did not had a model reference to go through the process as detailed as this, so the model
was the place to go to for this. Accordingly, the model helped to understand the whole
process, very detailed and in all aspects.
For a project based course this is very appropriate, given that we do not necessarily remember
many of the prior courses we had on this and the format of the course assumes that you
know everything.
The model provided awareness of how and what is done in one part of the process can impact
and is related to other parts of the MDD process. Also, how the work of one individual may
affect other people working on other parts of the process.
The complexity of the model is not a con if it helps. Might be a negative thing for someone
that does not want to spent time in this. However, if it is your job you must do it.
The model helped to learn the difference and implications of medical devices versus other
products. Medical devices focus more on the regulations and human body rather than
environmental effects. Medical devices have many standards that are well defined, have
many implications that are very broad and complex. Therefore, the model helped to search
for the regulations that apply for the particular device being modified.
FDA The model helped to understand the FDA regulations for medical devices. These must be
considered to analyse if the design fulfils the requirements. Moreover, these must be
constantly checked throughout the whole process.
The model has the regulations for medical devices already mapped for you to use as a starting
point. The model helped to speed up the initial understanding providing the basic idea to go
through these regulations. However, it has to be constantly updated if there are any changes
in the regulations.
Given the scope of the project, we would not have been exposed to the FDA process if it
was not for this model. In the search for the regulations, we learned about the regulation
requirements for sterilisation where we have to be careful of. These regulations affected our
choice of materials for the instrument.
Standards This part of the model gave a list of choices of how we can choose standards depending on our
objectives. This provided a starting point to understand the types of standards to consider,
including how one could go about testing the prototype.
The specifications of organisations gives a place to search for standards.
For the project, we looked at material standards to see if the materials under study have a
standard on their use for medical products.
Patents The description of patents in the model helped to define if the design ideas are patentable. This
part of the model provides a ‘first step’ to device if we need to look any further.
The patent part is the same throughout every process. Everyone in design should understand
patents well enough. It might help someone who do not have an understanding about
patents. Should include recent changes of patent requirements.
Clinical needs This part of the model was implemented in watching videos to see the practical use of the
identification instrument and how they are applied during the operation. This helped to discover customer
process latent needs (the needs the customer does not specify/know). The videos also helped to see
how the product is used and provide a better understanding of the basic functionalities that
the product should have and current problems of the product. In addition to the intended
use, the context of used was obtained from this analysis.
For this project, the company (project customer/sponsor) and customer (surgeon) were
related such that complying with customer needs will attend company needs. Company
needs included trying to develop a product that will have a bigger market share, income
and competitive advantage. Customer needs were more in terms of the usability of the
instrument during the surgical procedure, if they can reuse the product and how they are
going to maintain this.
(Continued)
Table 12. Continued
Competencies This part of the model was used to understand what are the specific company capabilities.
analysis However, this should be done by a third party and maybe compare with the team itself to
avoid bias because people sometimes promise a lot.
For the project, this included a team contract with strengths and weaknesses, and the
assignment of roles based on the differences in expertise - for the development of prototypes.
Customer analysis The model helped to define what is the customer and its segment. The customer is the surgeon.
One must consider whether the surgeon had prior knowledge with the instrument.
In teams of product specifications, the customer adds variability given that depending on the
surgeon the grip force transmitted to the end effector could be different.
Analysing the segment included considering the amount of technology knowledge customers
may have and how they can afford the product. This could also depend on the country,
where people may have different weighting for price versus functionality. For example, they
might prefer something cheaper than with added functionality.
Market analysis This part of the model was implemented by looking at products in the market and their
functions. This helped in understanding what functions could we achieve, but also to
work towards developing something different. This analysis included looking into special
capabilities and design characteristics, such as degrees of freedom, locking mechanism and
handle design. This helped in developing some targets and design goals.
Technology analysis This part of the model was implemented researching different material that could be used to
improve the current model. Looked at other fields of technologies that can be used in this
development process.
Competitive analysis For this part of the model would have considered what customer segments and niche markets
are being attended by the competition. Also to consider the market share of these companies.
This part was out of the scope of the project and was left to the sponsor.
Regulatory analysis This is implemented going back to the part of the model that describe the FDA regulation.
Check regulation requirements to keep our product within the regulations.
Legal/IP analysis This part of the model was pursued with a patent search. This analysis included looking at the
date of the IP to see if it could be implemented in the design.
If the idea was protected but was an attractive and feasible option, the analysis would involve
considering if the company is willing to pay for the patented idea.
This analysis also helped to understand why some of mechanisms do not reach the market due
to IP restrictions. Likewise, some ideas patented might not be feasible even though they are
considered as good ideas.
Overall, this analysis gave insights about the device being re-designed and how other people
have gone about solving similar problems. However, this need further consideration from
the point of view of requesting a patent for the new design developed.
Financial analysis This part of the model included the consideration of budget controls. It involved determining
how many hours are going to be put into designing the device. For this project, the budget
was $1000, which should include – labour, shipping costs and manufacturing of prototypes.
Design process This part of the model is implemented based on the outcome from the product definition
process.
This included setting targets and constraints for the steps to follow in the design process. The
team used the specifications to generate the concepts and then selected an idea based on
customer preferences and worked to develop it.
The model lists the steps to go through the design process. It helps to plan and to follow the
progress.
Inputs outputs The first step of this process involved deciding what needed to be addressed in terms of the
requirements, to then convert these requirements in actual design ideas that met those
requirements. The concepts were assessed to determine which of the requirements (inputs)
they would fulfil.
Targets (design inputs) were defined from the product definition process. From this, design
outputs were generated. This was an iterative process where verification and design reviews
included looking if product specifications met the requirements.
Design verification and design reviews impacted this process. More cycles were generated as
design reviews and verifications were performed. Every time we verified and we got more
ideas. This was necessary in order to move forward to develop prototypes in order to see if
these were feasible, how they functioned and how they could be manufactured.
This part of the model was implemented by looking into the feasibility of the ideas.
(Continued)
Table 12. Continued
Design reviews and verification were performed with peer reviews on the design ideas for
concept screening that included an analysis of the weaknesses.
Design verification also included meeting with the company to revise the ideas.
This was an important step towards having a final design.
The development of concepts was divided in sections; however, it was challenging to combine
the three sub-systems together given the complexity of the product and also that different
teams developed each sub-system.
Design validation This part of the model must be considered when there is a prototype manufactured that is
functional. To achieve this, it is important to go through the prototype development and
design analysis, which was the last stage of this project.
This is out of the scope of this project given that this stage may include performing in vitro
testing and clinical trials.
Risk management This part of the model is very important. For the project, one of the ideas proposed the use of
a material that required further analysis of risks. Some of the risks considered included the
risk of new technology, regulation risks and risk on human life. In addition, this included
considerations on the risk of investment before moving on.
Production planning For this part of the model, we considered that some of the mechanisms required more complex
manufacturing processes and costs. Critical tolerances required critical dimensioning which
resulted as a more expensive product. Design for manufacturing is recommended to reduce
the complexity of manufacturing this product.
For the scope of this project, the manufacturing of the device is very complex and the focus
remained on rapid prototyping.
Market introduction This part of the model is critical for device commercialisation. Accordingly, we expand on the
and launch quality audits and physician training.
For quality audits, it important to train your own people and study about what kind of quality
requirements they have, e.g. clean rooms. Using a model like this can help having a standard
process representation for quality audits.
Physician training is important to help surgeons changeover and avoid resistance to change.
Also, to make sure that the instrument is used correctly. To accomplish this, may need to
provide free testing to physicians and schools of medicine.
Records This part of the model needs to be considered throughout all the process.
This is important for FDA. FDA might look at the records as part of quality audits.
This was implemented in the project with a design journal and multiple reports.
The analysis of patents also helped to understand the technology and how other companies have
solved similar problems. However, the review of patents was a major requirement of the sponsor
company as well and a constraint for the development process as the sponsor asked specifically
to review existing patents to make sure that the proposed ideas are not already protected.
The design process was also impacted by the product complexity, which required various itera-
tions of design inputs and outputs. At first, the concepts were too abstract, not fully developed and
required further work/or more efforts. Colour-coded sketches, CAD drawings and animations
were developed to facilitate these discussions. Some of the ideas developed included the consid-
eration of friction, decomposition of product functions and conflicts between functions. Still, it
was difficult for the design team to come up with ideas and a complex mechanism of the same
degree of sophistication than the current model. However, these difficulties were also impacted
by the lack of access to the physical product.
Design reviews and verifications included peer review evaluations and observations from the
instructor. A critical design review consisted of a meeting with the sponsor company. At this
stage, the sponsor’s major concerns included the integration of the design concepts to the current
model and satisfaction of major requirements. For instance, some of the ideas’ shortcomings
included a decrease in the number of degrees of freedom and the replacement of major parts of
the current model. This design review also showed how the requirements target can change. An
interesting outcome of this review was the attention to detail of a particular idea. This idea involved
a particular material with properties that could solve one of the design problems. However, further
analysis was necessary to study the feasibility of using this material in a surgical instrument. It
was not clear if this material could be (1) in contact with patient’s tissue, (2) cleaned and sterilised
easily, and used for medical products. Interestingly, prior to the design review with the sponsor
company, this idea was neglected by the design team based on feasibility and cost concerns. The
interest for this material shows the dynamics of the development process and the importance of
the customer involvement. In addition, this shows the need for standards that already guarantee
the biocompatibility of materials.
Design reviews also included an assessment of the current model based on the DfM and Design
for Assembly (DfA) methods. This analysis showed that the current model could benefit from
DfM and DfA, given the (1) numerous parts, (2) manufacturing processes that require a lot of
precision and (3) assembly process by hand based on the number of parts, size and complexity.
Other challenges of MDD were addressed for this product. The importance of documentation
for MDD was highlighted through strict documentation procedures as described in the literature.
This study also included a search for the applicable FDA requirements. Similar products have a
risk-based classification of II and require a premarket notification (510(k)). In addition, there is
a special guidance document that should be reviewed for extended laparoscopic devices (FDA
1994).
6. Conclusions and future work
This article presents a validated product design process model as a conceptual tool and a visuali-
sation approach for the development of medical devices. While there is extensive research on the
regulations and the development processes for medical devices, the proposed model provides a
more comprehensive representation of the development landscape for medical devices than do any
of the previous models. The proposed model includes the fundamental information that design-
ers should grasp to initiate the development of medical devices. The model supports MDD in
multiple forms, providing: (1) training material for start-up companies, new designers and expe-
rienced designers new to the field of medical devices, (2) framework for process improvement
and completeness, (3) process guideline for implementing MDD and (4) assistance for regulatory
compliance. At the same time, the model supports potential research efforts towards identifying
critical success factors in MDD by providing a clearer view of the domain’s overall landscape. The
proposed model was validated through findings from a document analysis and content validation
that justified the concepts and their significance. The model also addresses important issues of
success within the field of MDD such as the completeness of the process, the enhancement of
experience and communication.
Besides explaining the importance and implementation of the model concepts, this study
demonstrated the use of the proposed model in a case study. Both, observations and surveys
from the users demonstrated that the model serves its purpose of training and guiding the imple-
mentation of MDD. The usability of the model was rated between adequate and excellent, and its
use was confirmed to increase the understanding for implementation, knowledge and experience
in MDD. The assessment of the model showed its utility from the point of view of the user,
where the model uses ranged from the initial planning and understanding of the whole process,
to the implementation of specific model concepts. Furthermore, significant factors from the liter-
ature were confirmed. Product complexity/technical challenge (Brown et al. 2008) and customer
involvement (Millson and Wilemon 1998) were relevant in the development process. The com-
plexity of the product was a challenge that the design team needed to overcome in order to move
forward with the project. This required studying further the clinical need with the observation
of videos and the analysis of drawings of the current model. Meanwhile, the involvement of the
customer helped to understand the product and the requirements for re-design. In addition, the
involvement of the customer was important in design reviews and verification to make sure that
the requirements were met.
Future research directions are proposed to address the limitations of this study. These limitations
include: (1) specific focus in US market, (2) complexity of the product design process model, and
(3) challenges to enhance the use of the model. Future research will involve the modification of
this framework for global harmonisation. The global harmonisation of the development process
and regulations is important to help improve MDD in order to avoid redundancy of products and
focus in the needs of the community. These efforts are expected to enhance a global integration of
medical device safety and process quality (Pietzsch et al. 2007). Likewise, global harmonisation
has a broader impact on society by speeding up patient’s access to the latest technological advances
worldwide.
A benefit but also limitation of the model is that it is very detailed and hence complex. Given
its complexity, a larger paper size (11 × 17) had to be used for its implementation during the
case study. To overcome this challenge, the model should be converted to a software tool where
the user can zoom in and zoom out the model. Converting the model to software will provide
additional benefits and further development of this study. Meanwhile to motivate the model use,
Macal (2005) explained that the use of case studies enhances the use of models in real life, given
that such studies increase the credibility and exposure of the models. This challenge has been
overcome, in part, with the case study presented with promising results. However, additional case
studies are necessary to further increase its exposure and use. To accomplish this, the case study
presented can be used as a pilot to facilitate the implementation of future case studies. This study
provides the framework for the case study procedure along with the evaluation tools to maintain
consistency. Furthermore, the development of a software tool will further enhance the model use
and will provide opportunities for more case studies.
References
Advanced Medical Technology Association, 2003. AdvaMed survey of member companies. Falls Church, VA: AdvaMed
(The Lewis Group).
Advanced Medical Technology Association, 2004. The medical technology industry at a glance [Brochure]. Falls Church,
VA: AdvaMed (The Lewis Group).
Aitchison, G.A., et al., 2009. A review of the design process for implantable orthopedic medical devices. The Open
Biomedical Engineering Journal, 3, 21–17.
Alexander, K. and Clarkson, P.J., 2002. A validation model for the medical devices industry. Journal of Engineering
Design, 13 (3), 197–204.
Bangor, A., Kortum, P., and Miller, J., 2009. Determining what individual SUS scores mean: adding an adjective rating
scale. Journal of Usability Studies, 4 (3), 114–123.
Bartoo, G., 2003. Risk management. IEEE Engineering in Medicine and Biology Magazine, 22 (4), 166–172.
Bren, L., 2006. Ensuring the safety of medical devices. FDA Consumer, 40 (3), 10–15.
Bresciani, S. and Eppler, M.J., 2007. Usability of diagrams for group knowledge work: toward an analytic description.
In: Proceedings of the 7th International Conference on Knowledge Management and Knowledge Technologies
(I-IKNOW), 5–7 September, Graz, Austria. Graz, Austria: Know-Center, 1–8.
Brown, A., et al., 2008. A survey of success factors in new product development in the medical devices industry. Paper
presented at a meeting of the Engineering Management Conference, Estoril, Portugal.
Brooke, J., 1996. SUS: A quick and dirty usability scale. In: B.T.P. Jordan and B. Weerdmeester, eds. Usability evaluation
in industry. London: Taylor and Francis, 198–194.
Ciarkowski, A.A., 2000. FDA regulatory requirements for medical devices with control algorithms. In: Proceedings of the
American control conference, Vol. 5, 28–30 June, Chicago, IL. Piscataway, NJ: Institute of Electrical and Electronics
Engineers, 3497–3500.
Das, S.K. and Almonor, J.B., 2000. A concurrent engineering approach for the development of medical devices.
International Journal of Computer Integrated Manufacturing, 13 (2), 139–147.
Duncan, E., et al., 2004. New products and standards. In: B.D. Ratner, ed. Biomaterials science: an introduction to
materials in medicine. San Diego, CA: Elsevier Academic Press, 783–803.
Eatock, J., Dixon, D., and Young, T., 2009. An exploratory survey of current practice in the medical device industry.
Journal of Manufacturing Technology Management, 20 (2), 218–234.
Eidenberger, R., 2000. Medical device registration, agreements on mutual recognition – a step forward to global
harmonization. Radiation Physics and Chemistry, 57, 539–542.
Ernst, H., 2002. Success factors of new product development: a review of the empirical literature. International Journal
of Management Reviews, 4 (1), 1–40.
FDA, 1994. Draft guidance for the preparation of a premarket notification for extended laparoscopy devices (ELD). FDA
web publication [online]. Available from: http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGui
dance/GuidanceDocuments/ucm080849.pdf [Accessed 28 July 2011].
FDA, 2009a. What FDA regulates [online]. Available from: http://www.fda.gov/AboutFDA/WhatWeDo/WhatFDARegul
ates/default.htm [Accessed 28 July 2011].
FDA, 2009b. Overview of device regulation [online]. Available from: http://www.fda.gov/MedicalDevices/
DeviceRegulationandGuidance/overview/default.htm [Accessed 28 July 2011].
FDA, 2009c. Is your product regulated? [online]. Available from: http://www.fda.gov/MedicalDevices/DeviceRegulation
andGuidance/Overview/IsYourProductRegulated/default.htm [Accessed 28 July 2011].
FDA, 2009d. Device classification [online]. Available from: http://www.fda.gov/%20MedicalDevices/DeviceRegulation
andGuidance/Overview/ClassifyYourDevice/default.htm [Accessed 28 July 2011].
FDA, 2009e. Product code classification database [online]. Available from: http://www.fda.gov/MedicalDevices/Device
RegulationandGuidance/Overview/ClassifyYourDevice/ucm051637.htm [Accessed 28 July 2011].
FDA, 2010. Is the product a medical device? [online]. Available from: http://www.fda.gov/MedicalDevices/DeviceRegula
tionandGuidance/Overview/ClassifyYourDevice/ucm051512.htm [Accessed 28 July 2011].
FDA, 2011a. CDRH innovation initiative. FDA web publication [online]. Available from: http://www.fda.gov/downloads/
AboutFDA/CentersOffices/OfficeofMedicalProductsandTobacco/CDRH/CDRHInnovation/UCM242528.pdf
[Accessed 27 November 2011].
FDA, 2011b. Medical device classification procedures [online]. Available from: http://www.accessdata.fda.gov/scripts/
cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=860.3 [Accessed 28 July 2011].
Feigal, D.W., Gardner, S.N., and McClellan, M., 2003. Ensuring safety and effective medical devices. The New England
Journal of Medicine, 348 (3), 191–192.
Foote, S.B., 1996. Medical technology development: limiting regulation. IEEE Technology and Society Magazine, 15,
4–9.
Fries, R.S., 2001. Handbook of medical device design, New York: Marcel Dekker.
Gold, E.R., et al., 2009. Are patents impeding medical care and innovation? Public Library of Science (PLoS) Medicine,
7 (1), 1–5.
Hamrell, M.R., 2006. An overview of the US regulatory environment for drug-device and biologic-device combination
products. Drug Information Journal, Health Module, 40 (1), 23–32.
Kahn, A., 1991. The dynamics of medical device innovation: a innovator’s perspective. In: A. Gelijns, ed. The changing
economics of medical technology, Washington, DC: National Academy Press, 89–95.
Kommu, S.S. and Rane, A., 2009. Devices for laparoendoscopic single-site surgery in urology. Expert Review of Medical
Devices, 6 (1), 95–103.
Lawshe, C.H., 1975. A quantitative approach to content validity. Personnel Psychology, 28, 563–575.
Lin, W. and Fan, X., 2009. Software development practice for FDA-compliant medical devices. In: 2009 international
joint conference on computational sciences and optimization (CSO), 24–26 April, Sanya, China. Washington, DC:
IEEE Computer Society, 388–390.
Linehan, J.H., et al., 2007. Study on medical device development models, Final report. Palo Alto, CA: Stanford University,
1–300.
Lucke L.E., Mickelson, A., and Anderson, D., 2009. Proving experience speeds medical device time to market. In: 31st
annual international conference of the IEEE engineering in medicine and biology society (EMBS), 2–6 September,
Minneapolis, MN. Piscataway, NJ: Institute of Electrical and Electronics Engineers, 7057–7060.
Macal, C.M., 2005. Model verification and validation. Workshop on threat anticipation: social science methods and
models. Chicago, IL: The University of Chicago and Argonne National Laboratory.
Maisel, W.H., 2004. Medical device regulation: an introduction for the practicing physician. Annals of Internal Medicine,
140 (4), 296–302.
Maisel, W.H., 2005. Safety issues involving medical devices: implications of recent implantable cardioverter-defibrillator
malfunctions. The Journal of the American Medical Association (JAMA), 294 (8), 955–958.
Malloy, A., 2006. Legal and ethical issues in the regulation and development of engineering achievements in medical
technology: a 2006 perspective. In: Proceedings of the 28th IEEE engineering in medicine and biology society
(EMBS) annual international conference, 30 August–3 September, New York. Piscataway, NJ: IEEE, 6660–6662.
McAllister, P. and Jeswiet, J., 2003. Medical device regulation for manufacturers. Proceedings Institution of Mechanical
Engineers, Journal of Engineering in Medicine, 217 (6), 459–467.
McCaffery, F. and Coleman, G., 2007. Developing a configuration management capability model for the medical device
industry. International Journal of Information Systems and Change Management, 2 (2), 139–154.
Medina, L.A., Okudan-Kremer, G., and Wysk, R.A., 2011. An ontology model for the medical device product develop-
ment process and environment. In: Proceedings of the design of medical devices conference (DMD), 12–14 April,
Minneapolis, MN. New York: American Society of Mechanical Engineers, 1–8.
Millson, M.R. and Wilemon, D., 1998. Managing innovation in the medical device industry. In: International conference
on engineering and technology management (IEMC), 11–13 October, San Juan, Puerto Rico. Piscataway, NJ: Institute
of Electrical and Electronics Engineers, 213–220.
Munzner, R.F., 1988. FDA rules for the medical device engineer. In: Proceedings of a special symposium on maturing
technologies and emerging horizons in biomedical engineering, 4–7 November, New Orleans, LA. Piscataway, NJ:
Institute of Electrical and Electronics Engineers, 48–49.
Ogot, M. and Okudan-Kremer, G., 2004. Engineering design: a practical guide. Victoria, Canada: Trafford Publishing.
Panescu, D., 2009. Medical device development. In: 31st annual international conference of the 31st IEEE engineering
in medicine and biology society (EMBS), 2–6 September, Minneapolis, MN. Piscataway, NJ: Institute of Electrical
and Electronics Engineers, 5591–5594.
Paradise, J., et al., 2009. Evaluating oversight of human drugs and medical devices: a case study of the FDA and implications
for nanobiotechnology. Journal of Law, Medicine & Ethics, 37 (4), 598–623.
PwC, 2011. Emerging markets are gaining ground in medical technology innovation; US maintains lead,
finds PwC’s medical technology innovation scorecard [online]. PricewaterhouseCoopers LLP. Available from:
http://www.pwc.com/us/en/press-releases/2011/emerging-markets.jhtml [Accessed 13 December 2011].
Pietzsch, J.B., et al., 2007. Review of US medical device regulation. Journal of Medical Devices, 1, 283–292.
Pietzsch, J.B., et al., 2009. State-gate process for the development of medical devices. Journal of Medical Devices, 3,
1–15.
Rochford, L. and Rudelius, W., 1997. New product development process: stages and successes in the medical products
industry. Industrial Marketing Management, 26, 67–84.
Sauro, J., 2011. Measuring usability with the System Usability Scale (SUS) [online]. Available from:
http://www.measuringusability.com/sus.php [Accessed 15 August 2011].
Saviola, J., 2005. The FDA’s role in medical device clinical studies of human subjects. Journal of Neural Engineering, 2,
S1–S4.
Storga, M., Andreasen, M.M., and Marjanovic, D., 2008. The design ontology: foundation for the design knowledge
exchange and management. Journal of Engineering Design, 21 (4), 427–454.
Sudershana, S., Villca-Roque, A., and Baldanza, J., 2007. Successful collaborative software projects for medical devices
in an FDA regulated environment: myth or reality? In: Second IEEE International conference on global software
engineering (ICGSE), 27–30 August, Munich, Germany. Washington, DC: IEEE Computer Society, 217–224.
Syring, G., 2003. Overview: FDA regulation of medical devices. Quality and regulatory associates, LLC web publication
[online]. Available from: http://www.qrasupport.com/FDA_MED_DEVICE.html [Accessed 28 July 2011].
Watson, J.T., 1994. Food and drug administration guidance sections: a new paradigm for medical devices. American
Society for Artificial Internal Organs (ASAIO) Journal, 40 (2), 138–144.
Yusuf, S., Kagdi, H., and Maletic, J.I., 2007. Assessing the comprehension of UML class diagrams via eye tracking. In:
15th IEEE international conference on program comprehension (ICPC’07), 26–29 June, Banff, Canada. Washington,
DC: IEEE Computer Society, 1–10.
Table A1. Detailed comparison of medical device development processes in the literature
Normative design process Medical device design processes in the literature
Ogot and Okudan-Kremer (2004) Pietzsch et al. (2009) Alexander and Clarkson (2002) Panescu (2009)
Needs assessment/ problem definition Predevelopment activities Funding phase

Includes the definition of the problem Identification of the clinical need to Identify the clinical need, market potential,
and the customer/client’s needs as pursue from a large list of clinical intellectual property landscape, potential

part of the requirements review of the needs. regulatory approval requirements and
product or process. reimbursement road.
Conceptualisation Initiation/opportunity and risk analysis Device user needs/verification Concept phase
Includes external and internal searches. Initial evaluation of possible development requirements for device validation Determine the specifications that describe the
The external search is to discover of commercial product. medical device according to the original
what has been done in the past, Define implicit and explicit require- idea. Includes: marketing specifications
including literature searches, ments (technical, business and and products requirements specifications.
reviewing patents, talking with Formulation/concept and feasibility regulatory) together with verification
experts and benchmarking existing Phase requirements.
similar products. The internal search Definition of design input based on Device design/ final device verification
is when the design team develops customer needs and technical Use a risk-based approach to design
several concepts from which the best requirements. and verify. Consider the effects of
suited to the defined need is selected. redesign on requirements
A concept is a very preliminary
description of the form, required
principles and required technology
for the solution.
(Continued)
115
116
Table A1. Continued
Ogot and Okudan-Kremer (2004) Pietzsch et al. (2009) Alexander and Clarkson (2002) Panescu (2009)
Preliminary design and evaluation Design and development/ verification & Process user needs/verification Development phase
Evaluation of feasible concepts for validation phase requirements for process validation Definition of lower level requirements
concept selection and to determine Development of product design, and of Consider the effects of device specifications. Verification and
system and component design. manufacturing process, verification requirements, design and verification reviews are necessary to assure
Detailed design and testing and validation. on process requirements and design compliance with the
Development of technical drawings and verification. requirements. A “freeze” preliminary
system specifications. Process design/ final process verification design is obtained.
Perform final process design and Verification and validation phase
verification. Consider the effects The design is tested for compliance with
of process redesign on device
L.A. Medina et al.

the requirements. In compliance
requirements. with quality controls and procedures,
aspects of the design can be changed
if found to not meet requirements.
Production Final validation/ product launch Production development/ final process Production phase (scale-up or
Planning of production process. preparation phase qualification manufacturing)
Final validation of manufacturing Perform final process qualifications. Create appropriate processes and
processes, preparation of product documentation that would ensure
introduction. that the product is manufactured
according to quality standards.
Manufacturing processes and tools
may be developed.
Product launch and post-launch Market release phase
assessment After receiving FDA approval, the
Market introduction of product and product could be released to the U.S.
continuous improvement. market. Training material should be
prepared for patients and physicians.
Perform post-market release product
quality surveillance.
Table A1. Continued

Ogot and Okudan-Kremer (2004) Aitchison et al. (2009) Das and Almonor (2000) Hill (1998)
Needs assessment/ problem definition Development of the product concept Design brief
Includes the definition of the problem proposal The design brief is usually supplied by the
and the customer/client’s needs as Approval of a concept taking into account marketing department, and obtained
part of the requirements review of the potential regulatory barriers, potential from purchasers, users, customer
product or process. medical side effects, feasibility of key feedback and market awareness
technologies and in-house experience
with key technologies.
Formation of the core development team

Following a concurrent engineering
approach, the team should include
personnel from different areas: medical
& clinical, costing & regulatory
liaison, supply & distribution, product
design, product & process validation,
manufacturing, and packaging design.
Conceptualisation Feasibility Create attribute driven specification table Feasibility
Includes external and internal searches. Definition of design inputs, com- The table includes customer, functional and May include the clarification of
The external search is to discover mercial aspects, planning, regulatory attributes, that are used to requirements, setting limits on
what has been done in the past, regulatory requirements and ensure that all the target specifications physical size and cost and identifying
including literature searches, design requirements. are linked to a desired attribute of the variants.
reviewing patents, talking with product. The table must be approved by
experts and benchmarking existing the team.
similar products. The internal search
is when the design team develops
several concepts from which the best
suited to the defined need is selected.
A concept is a very preliminary
description of the form, required
principles and required technology
for the solution.
(Continued)
117
118
Table A1. Continued

Design Development and approval of the project Concept design

From conceptual to a detailed design. plan The development of ideas on
Includes: solid CAD models, The project plan should include: organ- form/construction form, manu-
materials specification, engineering isational and technical interactions, facturing methods and information
drawings, tolerance stacks analysis, information mechanisms, assignment for medical staff. May include
L.A. Medina et al.

inspecting, and Dfx (DFM, DFA, of responsibilities, approval/conflict building of prototypes, lab testing
DFMA) requirements. resolutions, required design inputs and customer evaluations.
and outputs for each stage, cost
estimation motels and targets.
Preliminary design and evaluation Verification Product design/design control/ Final design
Evaluation of feasible concepts for Design verification is performed through continuous electronic documentation Creation of final specifications, detailed
concept selection and to determine finite element analyses (FMEA), risk The product design activities may drawings, and costs QA/QC test
system and component design. analyses and rapid prototyping. include: marketing/distribution, protocols
primary product design, validation
protocol, FMEA, processing, packag-
ing/graphics, materials, use/disposal.
Design control is implemented by
monitoring a weighted specification
accomplishment and cost targets.
Table A1. Continued
Detailed design and testing Manufacture Process and clinical validation of the
Development of technical drawings and Choose the manufacturing techniques design
system specifications. to utilize based on the number to be As part of the company’s quality
produced, the surface finish required, assurance program, validation must
post machining cleaning processes be carefully planned to ensure that
and the sterilization process. regulatory requirements are met
Validation and that corporate philosophies

Ensure that the device meets the user are maintain in a reasonable and
requirements and the intended use cost-effective manner.
through: mechanical testing of
prototypes, evidence that similar
devices are clinically safe, a clinical
investigation and sterilisation
validation.
Production Design transfer Release product Sales
Planning of production process. Creation of all documents and training Release product to production. Consideration of factors such as: training,
necessary to transfer the design discounts, overheads, legal liability
into production. These may include: and distribution.
documentation, surgical technique,
training, packaging and labelling, and
the master device record.
Design changes
A post-market surveillance process
should be in place for feedback from
surgeons that may lead to design
changes. The changes that arise must
be documented and the effects upon
the device investigated.
119
Copyright of Journal of Engineering Design is the property of Taylor & Francis Ltd and its content may not be
copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written
permission. However, users may print, download, or email articles for individual use.
View publication stats

Medical Device Development

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Medical Device Development

Caricato da

Copyright:

Formati disponibili

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Supporting medical device development: A standard product design process

Article in Journal of Engineering Design · January 2012

Lourdes A Medina Gül Kremer

SEE PROFILE SEE PROFILE

Commercial uses for Electrically Activated Silver View project

The user has requested enhancement of the downloaded file.

Supporting medical device development: a standard product

(Received 5 November 2010; final version received 13 March 2012)

*Corresponding author. Email: lourdes.medina@upr.edu

© 2013 Taylor & Francis

FDA regulation is an essential element in the development of medical devices to be marketed in

2.1. The FDA regulation

2.2. MDD process models

Table 1. Comparison of MDD processes in the literature.

Needs assess- Predevelopment Funding Phase Development of the

Figure 2. Case study methodology.

4. Product design process model

4.1. Development of the conceptual model and validation

Table 2. Model relationships.

Relationship (UML notation) Meaning

A Generalisation - inheritance, “is a”

A B Association – related with a verb

A B Aggregation – “has a” relationship

Composition – being part of a whole

Table 3. Document analysis results example for FDA-related information.

Figure 3. Model example for FDA-related information.

Table 4. Document analysis results example for medical device records.

Class A Proposed Relationship Class B Impact Evidence

Figure 4. Model example for medical device records.

Table 5. Model clusters.

Product Development &

Table 6. Content validation results by cluster.

Content Validity Content Validity Percentage

FDA 0.8 1.0 91%

Product development CVR- CVR-

Product definition 0.9 1.0

Table 8. Model uses validation.

Model uses % Disagreement % Neutral % Agreement

Training material/best practices in medical device 5 26 68

4.2. Model structure and use

Figure 7. FDA’s and medical specialties clusters.

Figure 8. Standards cluster.

Figure 9. Patents cluster.

Figure 10. Development/introduction cluster.

Figure 11. Development/introduction cluster – concepts of the product definition process.

Figure 12. Development/introduction cluster – concepts of the design process.

Figure 13. Development/introduction cluster – risk management process.

Figure 14. Development/introduction cluster – production planning process.

Figure 15. Development/introduction cluster – market introduction & post-launch process.

Figure 16. Development/introduction cluster – medical device records.

5.1. Model assessment

Figure 18. Weekly MDD progress.

Table 9. Mid-project (M) / final-project (F) assessments – SUS results.

Assessment score per question (Si)∗

Question User 1 (M/F) User 2 (M/F)

Assessment score per question (Si)∗

Question User 1 (M/F) User 2 (M/F)

1 After using this model, my understanding of the implementation 4/4 4/4

Assessment score per question (Si)∗

Question User 1 (M/F) User 2 (M/F)

9 The model needs −−−−−− improvements 4/4 4/3

11 My experience in medical device development is −−−−−− by the 4/4 3/4