Design Controls For The MEDICAL DEVICE InDustry

Marie B.
teixeira
Design Controls
For the
MEDICAL DEVICE
InDustry
seConD eDition
Design Controls
For the
MEDICAL DEVICE
InDustry
seConD eDition
Marie B. teixeira
CRC Press
Taylor & Francis Group
6000 Broken Sound Parkway NW, Suite 300
Boca Raton, FL 33487-2742
© 2014 by Taylor & Francis Group, LLC

CRC Press is an imprint of Taylor & Francis Group, an Informa business
No claim to original U.S. Government works

Version Date: 20131018
International Standard Book Number-13: 978-1-4665-0355-7 (eBook - PDF)
This book contains information obtained from authentic and highly regarded sources. Reasonable efforts
have been made to publish reliable data and information, but the author and publisher cannot assume
responsibility for the validity of all materials or the consequences of their use. The authors and publishers
have attempted to trace the copyright holders of all material reproduced in this publication and apologize to
copyright holders if permission to publish in this form has not been obtained. If any copyright material has
not been acknowledged please write and let us know so we may rectify in any future reprint.
Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmit-
ted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented,
including photocopying, microfilming, and recording, or in any information storage or retrieval system,
without written permission from the publishers.
For permission to photocopy or use material electronically from this work, please access www.copyright.
com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood
Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and
registration for a variety of users. For organizations that have been granted a photocopy license by the CCC,
a separate system of payment has been arranged.
Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used
only for identification and explanation without intent to infringe.
Visit the Taylor & Francis Web site at
http://www.taylorandfrancis.com
and the CRC Press Web site at

http://www.crcpress.com
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
About the Author. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Overview 1
2 Device classification . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Overview of design controls . . . . . . . . . . . . . . . . . . . 9

Applicability 9
Design controls and the bottom line 9
An idea is born 12
Ask the customers 12
Design controls and the customer 13
4 Design and development planning . . . . . . . . . . . . . . 17

Do we really need a plan? 17
Design and development planning requirements 19
So what makes up the plan? 21
Planning techniques 22
Project planning: How do I get started? 26
5 Design inputs—Part I . . . . . . . . . . . . . . . . . . . . . . 29
What are design inputs? 29
The foundation: Design input 30
Design input requirements 30
The concept document 31
Product performance specification 33
v
Design controls for the medical device industry
6 Design inputs—Part II . . . . . . . . . . . . . . . . . . . . . . 37
From feasibility to development 37
Performance characteristics 37
Product characteristics 43
Marketing requirements 58
Regulatory and contractual requirements 63
Design input: One final word 64
7 Design outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
From inputs to outputs 65
Design output requirements 66
Typical design outputs 67
Device master record 67
8 Design review . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Not another meeting! 69
FDA and design review 69
Meeting dynamics 75
9 Design verification . . . . . . . . . . . . . . . . . . . . . . . . . 83
What is the purpose of design verification? 83
What is design verification? 83
Design verification requirements 83
Verification activities 84
10 Risk management . . . . . . . . . . . . . . . . . . . . . . . . . 87
Why? 87
How does risk management fit into design and
development? 87
What is a risk analysis, and what is risk
management? 88
Risk management process 89
Human factors and the risk management process 95
Risk management plan 97
11 Design validation . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Why validate? 99
What is design validation? 99
vi
Contents
Design validation requirements 100

Typical validation activities 102
Risk assessment of medical device materials
and the finished device 103
12 Biocompatibility . . . . . . . . . . . . . . . . . . . . . . . . . 105
Regulatory aspects of biocompatibility 106
Biocompatibility testing programs 108
Phases of biocompatibility testing 109
13 Design transfer . . . . . . . . . . . . . . . . . . . . . . . . . . 123

What is design transfer? 123
Check your attitude at the door 123
FDA and design transfer 124
Design transfer requirements 125
14 Design change . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Design change control 127
Design change requirements 127
Engineering change order or change request
form 129
15 Design history file . . . . . . . . . . . . . . . . . . . . . . . . 131

Why do we need a design history file? 131
What is a design history file? 131
Design history file requirements 131
16 The FDA inspection technique . . . . . . . . . . . . . . . 135

Oh no! The FDA investigator is here 135
Appendix A—QARA Compliance Connection, Inc.: Design

control procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Appendix B—QARA Compliance Connection, Inc.: Product
performance specification. . . . . . . . . . . . . . . . . . . . . . . . 153
Appendix C—QARA Compliance Connection, Inc.: CE product
claims sheet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
vii
Appendix D—QARA Compliance Connection, Inc.: Design

inputs and associated outputs matrix . . . . . . . . . . . . . . . . 161
Appendix E—QARA Compliance Connection, Inc.: Project
approval form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Appendix F—Design review meeting record . . . . . . . . . . . . 165
Appendix G—QARA Compliance Connection, Inc.: Risk
management plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Appendix H—QARA Compliance Connection, Inc.: Clinical
evaluation report form . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Appendix I—QARA Compliance Connection, Inc.: Design
transfer checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Appendix J—QARA Compliance Connection, Inc.:
Design change form . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Appendix K—QARA Compliance Connection, Inc.:
Approval for sale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
viii
Preface
Since the design control requirements were formally mandated by the Food
and Drug Administration’s (FDA’s) Quality System Regulation (QSR) in June
1997, and revisions were made to the International Standard ISO 13485 in 2003,
expectations for compliance with design control requirements have evolved.
Furthermore, as Regulatory Authorities and Notified Bodies have become more
familiar with the intent of the design control requirements and these persons have
assessed industry’s various methods and techniques for implementing the design
control requirements, what may have passed as acceptable a number of years ago
is often deemed unacceptable or inadequate today. As such, a company’s design
control program should be dynamic in nature and continue to evolve in accor-
dance with current expectations and industry practice.
Over the past 10 years since the book was first published, I have gained additional
practical experience in understanding the expectations for compliance of various
Regulatory Authorities and Notified Bodies by participating in numerous FDA
QSR inspections and Notified Body ISO audits. My experience with various types
of companies, both large and small, and varying in functionality and exposure to
a broader range of products and systems, has given me the insight and experience
needed to develop practical systems to meet company and external regulatory
requirements. My prime goal in writing the second edition is to keep the book up
to date with the methods used to meet design control requirements and to comply
with third-party expectations for compliance.
In this second edition, I expanded the scope of the book to include ISO 9001 and
ISO 13485 requirements for design control. The book has also undergone a major
revision in an effort to add more detail for understanding and clarity and to pro-
vide more practical examples for implementation of the concepts. In addition, the
majority of the appendices have been revised or replaced with more current and
applicable templates.
In a book such as this, which covers the design control requirements applica-
ble to a broad range of products and companies, it is often difficult, and likely
ix
impossible, to include every opinion or interpretation of the requirements or

present the information in a manner that addresses everyone’s specific situation.
I have tried to present a comprehensive review of the requirements and provide
practical and proven tools and techniques for meeting the design control require-
ments and third-party auditor/investigator expectations.
x
About the Author
Marie B. Teixeira is the founder and principal consultant for QA/RA Compliance
Connection, Inc., in Odessa, Florida. QARACC is a world-class consulting com-
pany providing expert management and guidance for its clients in all aspects of
quality management and regulatory affairs.
Before beginning this venture, she was director of quality assurance and regula-
tory affairs at Bioderm, Inc., a start-up medical device company in the Tampa
Bay, Florida, area where she designed, directed, and implemented the policies
and procedures that established this company’s compliance with the FDA’s QSR
policy for medical devices, as well as Europe’s Medical Device Directive. In
addition, Teixeira established a quality management system that would allow
this company to achieve ISO 9001 certification with minimum effort. She also
directed regulatory compliance for Europe, Australia, Canada, and several South
American countries.
Teixeira was also quality systems manager for regulatory affairs at Smith &
Nephew’s Wound Management Division in Largo, Florida. In addition to direct-
ing the planning, development, and implementation of Smith & Nephew’s ISO
9001/EN 46001, FDA GMP, and MDD 93/42/EEC regulatory efforts, she imple-
mented and directed the company’s internal audit and management review sys-
tem. It was her direction and guidance that allowed Smith & Nephew’s Wound
Management Division to achieve ISO 9001 certification in less than a year, as well
as its MDD certification one year later.
Teixeira began her career as a quality engineer for Raytheon, GTE Government
Systems, and Sparton Electronics. During her tenure at these companies, she was
responsible for establishing and implementing quality assurance programs and pro-
cedures, leading supplier and customer audits, developing and performing quality
system and auditor training, initiating and managing corrective actions, and devel-
oping and implementing supplier certification programs. During her tenure at
Sparton, she managed the company through its initial ISO 9002 certification and
subsequent surveillance audits.
xi
Teixeira holds a BS in industrial engineering and operations research from the

University of Massachusetts at Amherst. She is a member of the American
Society for Quality, and is an ASQ Certified Quality Manager and Quality
Engineer and an RABQSA Principal Auditor. Teixeira was also an active member
of an international task force, CEN/TC257/SC-DETG10, whose objective was to
standardize medical device nomenclature. She has published numerous quality-
system-related CD-ROM training modules and related informational handbooks
and has conducted numerous quality system training seminars.
xii
Chapter 1 Introduction
Overview
Quality system requirements apply to all organizations providing medical devices
regardless of the type or size of the organization. Medical device manufacturers
are required to establish, implement, and maintain quality systems to help ensure
that their products consistently meet applicable requirements and specifications.
In the United States, the quality system requirements for devices regulated by
the Food and Drug Administration (FDA) are codified under 21 CFR Part 820–
Quality System Regulation (QSR). Likewise, ISO 9001 is an international quality
management system standard applicable to any product, and ISO 13485 is an
international quality management system standard specific to medical devices.
ISO 13485 is considered to be compatible with the QSR. The QSR, ISO 9001,
and ISO 13485 Standard include the requirements related to the methods, facili-
ties, and controls used for designing, manufacturing, packaging, labeling, storing,
installing, and servicing finished products. Manufacturers are expected to adopt
current and effective methods and procedures for each device they design and
manufacture in order to comply with and implement the basic requirements.
What is “design control”?

Design control may be thought of as a system of checks and balances that ensure
that the product being developed will meet the performance requirements for the
product, the applicable statutory and regulatory requirements for marketing and
distributing the product, and the needs of the end user (i.e., customer), and is safe
and effective for its intended use. Simply put, design controls are a documented
method of ensuring that what you think you are developing is what you wanted
to develop in the first place and that what finally comes off the production line
is what the customer needs and wants and you can legally market and distribute.
Why design controls?

The Safe Medical Devices Act of 1990 (the SMDA), enacted on November 28,
1990, amended section 520(f) of the Federal Food, Drug, and Cosmetic Act, pro-
viding the FDA with the authority to add preproduction design controls to the
Current Good Manufacturing Practice (CGMP) regulation. This change in law
was based on findings that a significant proportion (44 percent) of device recalls
were attributed to faulty design of products, believed to be due to an inadequate
1
allocation of resources to product development.* The FDA published the revised

CGMP requirements in the final rule titled “Quality System Regulation” in the
Federal Register of October 7, 1996. This regulation became effective on June 1,
1997, and remains in effect today.
FDA inspections reveal deficiencies

When the FDA first began inspecting medical device manufacturers for compli-
ance with the design control requirements, they kept track of the areas where
manufacturers were most deficient. The results of 157 inspections from June 1,
1998, through September 30, 1999, showed that inadequate design and develop-
ment planning was the most significant problem area.† Now, almost 15 years later,
compliance with design control requirements still remains a problem for medical
device manufacturers; however, the majority of inspection citations have to do
with failure to document the design and development process, the design change
control process, and design validation.
Failure to document the design and development process (i.e., procedure) and/or
the design change control process is considered a major deficiency. If during an
FDA inspection of a facility any major deficiencies exist, the FDA will classify
the Establishment Inspection Report (EIR) as Official Action Indicated (OAI)
and, based on the significance (risk) of the device and the findings, will determine
which administrative and/or regulatory action to initiate. Such actions include,
but are not limited to, issuance of a warning letter, injunction, detention, seizure,
civil penalty, and/or prosecution.
If any of these deficiencies exist for foreign manufacturers, based on the signifi-
cance (risk) of the device and the findings, a warning letter and/or warning letter
with detention without physical examination will be considered by the Center for
Devices and Radiological Health (CDRH), Office of Compliance (OC).
From January 2010 to December 2010, the FDA issued 89 warning letters to med-
ical device firms for Quality System/Good Manufacturing Practice deficiencies.
Of the warning letters issued, 49 (55 percent) included design control citations.‡
The breakdown of those design control citations is shown in Table 1.1. As you can
see, design control remains an area in need of improvement.
* The proportion was even greater for software-related recalls at 90 percent.

† FDA QSIT Workshop, Orlando, FL, October 1999.
‡ FDA. FDA Medical Device 2010 Quality System Data: Analysis of 2010 Warning Letter Cites.
2
Introduction
Table 1.1 Design Control Subsystem

Warning Letter Cites, 2010
21 CFR 820.30(i) = 18 21 CFR 820.30 (e) = 3
21 CFR 820.30(g) = 17 21 CFR 820.30(d) = 3
21 CFR 820.30(a) = 14 21 CFR 820.30 = 2
21 CFR 820.30(j) = 6 21 CFR 820.30(b) = 1
21 CFR 820.30(c) = 4 21 CFR 820.30(h) = 0
21 CFR 820.30(f) = 4 Total citations = 72
3
Chapter 2 Device classification
Before we talk about who is required to comply with design control requirements
and what those requirements are, let’s talk a little about medical device clas-
sification. Medical devices are typically assigned a device class (see Table 2.1).
In the United States, medical devices fall into three device classes. In Canada
and Europe, there are currently four medical device classes. In addition, the
European classification system includes a Class I sterile and Class I measuring
function category.
The amount of control needed for a medical device to ensure its safety and effec-
tiveness is dependent on its medical device class. A Class I device represents the
lowest risk of harm to the user and requires the least amount of regulatory control,
whereas a Class III or IV device represents the greatest amount of risk of harm to
the user and requires the most regulatory control.
The class to which a medical device is assigned is based on its safety and effec-
tiveness or “risk.” In the United States, the FDA determines and assigns the
device class by considering the following factors:
• Intended use: Who is the device intended for?
• Indications for use: What are the conditions for use of the device, includ-
ing the conditions of use prescribed, recommended, or suggested in the
labeling or advertising of the device and other intended conditions of use?
• Safety and risk: What is the probable benefit to health from use of the
device when weighed against any probable injury or illness from such
use (risk/benefit analysis)?
• Effectiveness: What is the reliability of the device?
Examples of the FDA’s classification of medical devices are shown in Table 2.2
In Europe and Canada, medical devices are also classified using a risk-based clas-
sification scheme; however, it is the manufacturer’s responsibility to determine
the device class. In determining the device classification, manufacturers must
consider the following:
• Device intended use: What part of the body is affected?
• Device duration of contact: How long is the device in continuous use?
• Device degree of invasiveness: What is the degree in which the device
contacts the patient?
5
In Europe, device classification is determined using Annex IX of the Medical

Device Directive. Examples of Europe’s classification of medical devices are
shown in Table 2.3. In Canada, medical device classification is determined per
Schedule 1 of the Canadian Medical Device Regulations. Examples of Canada’s
classification of medical devices are shown in Table 2.4.
Table 2.1 Medical Device Classes

Location Class Class Class Class
United States I II III
Canada I II III IV
Europe I IIa IIb III
Table 2.2 FDA’s Classification of Medical Devices

Class Examples
I Forceps, scalpels, surgical scissors, ophthalmic surgical needles, elastic bandages,
examination gloves, handheld surgical instruments, laryngoscope blades and handles,
esophageal stethoscopes, nose clips, ventilator tubing, tracheal tube stylets, oxygen
masks, nasopharyngeal airways, hearing aids, otoscopes, occlusive and hydrophilic wound
dressings, eye pads, surgeon gloves, patient scales
II Infusion pumps, surgical drapes, diagnostic ultrasound, powered wheelchairs, bone fixation
plates and screws, T-piece resuscitators, positive end-expiratory pressure (PEEP) valves,
wound dressings, apnea monitors, powered emergency ventilators, tracheal tubes,
bronchial tubes, DC defibrillators, vascular clamps, piston syringes, oximeters,
oscillometers, audiometers, ophthalmoscopes
III Replacement heart valves, silicone gel-filled breast implants, implanted cerebella
stimulators, implantable pacemakers, pacemaker programmers, intraocular lens, hip joint
acetabular metal cemented prosthesis, shoulder joint glenoid metallic cemented prosthesis
6
Device classification
Table 2.3 Europe’s Classification of Medical Devices

Class Examples
I CO2 detectors, CPR bags, face masks, laryngoscope blades and handles, dressing
adhesive removers, most orthotic or prosthetic devices, ostomy collection devices,
wheelchairs, spectacle lenses and frames, fundus cameras, rehabilitation equipment,
stethoscopes, examination gloves, hypodermic syringes, incision drapes, conductive
gels, wound dressings that act as a mechanical barrier for compression or absorption
of exudates, reusable surgical instruments
I Sterile Any sterile Class I device, for example, sterile laryngoscope blades and handles, sterile
eye guards/shields, ET introducers and stylets
I Measuring Devices that measure body temperature, nonactive and noninvasive devices for
Function measuring blood pressure, nonactive devices for measuring intraocular pressure,
devices for measuring volume or pressure or flow of liquid or gases delivered to or
removed from the body, for example, manometer, negative inspiratory force monitor
IIa CPAP, endotracheal tubes, incontinence cleansers, protective barrier creams, X-ray
film, cleaning and disinfecting products used with medical devices, syringes for
infusion pumps, anesthesia breathing circuits and pressure indicators, polymer film
dressings, hydrogel dressings and nonmedicated impregnated gauze dressings,
contact lenses, urinary catheters, fixed dental prostheses, surgical gloves, bridges,
crowns, dental alloys, muscle stimulators, TENS devices
IIb T-piece resuscitators, long-term-use tracheostomy tubes, wound dressings for chronic
extensive ulcerated wounds, severe burns or severe decubitis wounds, blood bags,
contact lens care products, condoms, radiological equipment, urethral stents, insulin
pens, brachytherapy devices, prosthetic joint replacements, intraocular lenses,
nonabsorbable sutures, bone cements, lung ventilators, surgical lasers, diagnostic
X-ray sources
III Intrauterine contraceptive devices (IUDs), heparin coated catheters, bone cement
containing an antibiotic, cardiovascular catheters, neurological catheters, cortical
electrodes and connonoid paddles, absorbable sutures and biological adhesives,
prosthetic heart valves, aneurysm clips, spinal stents, condoms with spermicide,
dressings incorporating an antimicrobial agent to provide ancillary action on the
wound, collagen implants
7
Table 2.4 Canada’s Classification of Medical Devices

Class Examples
I Oropharyngeal airways, tympanoscopes, intranasal septal splints, reusable surgical and
dental instruments, dressings, adhesive strips, surgical drapes, manual adjustable
hospital beds, thoracic drainage systems, intraoral dental lights, surgical microscope
systems, endoscopic still cameras, AC-powered keratoscopes, fiber-optic illuminators for
endoscopes, leg braces
II Disposable surgical instruments, short-term intravascular catheters, X-ray-detectable
nonabsorbable internal sponges, oximeters intended only for sampling percent oxygen
saturation, ECG machine intended only to be used in a doctor’s office for routine checkups,
laryngoscopes, retention-type catheter balloons, daily wear soft contact lenses, orthodontic
brackets, preformed dentures, latex condoms, hydrogel dressing, wound and burn dressing,
flowmeters, piston syringes, nebulizers, audiometers, steam sterilizers
III Pulse oximeters recommended for use in the operating and recovery room for continuous
monitoring of arterial oxygen saturation; ECG machines intended to be used in critical care
settings; peritoneal, long-term, indwelling catheters; internal saline inflatable breast
prosthesis; shoulder prosthesis; amalgam alloys; tooth shade resin materials; intrauterine
contraceptive devices; tracheal stents; female condoms; gas analyzers; infusion pumps
IV Intracardiac oximeters, breast implants, aneurysm clips, HIS bundle detectors, implanted
spinal cord stimulators for pain relief, fetal blood-sampling endoscopes and accessories,
fetoscopes and accessories, external pacemaker, pulse generator, automatic implantable
cardioverter defibrillator, implanted vagus nerve stimulator, cerebral blood flow monitors,
fetal Ph monitors, closed-loop blood glucose controller, closed-loop blood pressure
controller, collagen corneal shields, tissue heart valves, skin grafts
8
Chapter 3 Overview of
design controls
Applicability
Now that we have discussed how medical devices are classified, we can determine
who is required to meet FDA and ISO design control requirements and what those
requirements entail; that is, Who? What? Why? How?
Design controls are a component of a comprehensive quality management sys-
tem that covers the entire “life” of a device from initial approval of the device
design to disposal. Design controls are needed to ensure products meet specified
requirements and user needs and are safe and effective for their intended use. The
FDA’s QSR and ISO 9001 and ISO 13485 Standards require that you document
the method that you choose to use to control your design and development process.
In the United States, medical device companies that design and develop Class
II and Class III medical devices, as well as devices automated with computer
software and Class I devices listed in Table 3.1, are mandated to comply with the
design control requirements called out in 21 CFR 820.30. Similarly, organiza-
tions that require compliance with ISO 9001 and 13485 International Standards
must also comply with design control requirements unless exclusion of these
requirements (Section 7.3) is permitted (e.g., FDA Class I device not called out in
Table 3.1 or above).
Note that if you design and develop a Class I device, you are still subject to design
change control requirements (Section 820.30(i)).
Design controls and the bottom line

The main objective of any business is to make money. The question that we need
to continually ask ourselves as businesspeople is whether what we are doing is
moving us closer to or farther away from that objective. Designing a new medical
device requires engineers to determine the materials that will be used, as well
as the best way to assemble and test the product. Unfortunately, oftentimes these
otherwise bright people forget the goal of the business. They have not been hired
to make the longest lasting, strongest, most cosmetically pleasing medical device.
They have been hired to make a medical device that is safe and effective for the
9
Table 3.1 Class 1: Design Control Applicability

Section FDA Class I Device
868.6810 Tracheobronchial suction catheter
878.4460 Surgeon’s glove
880.6760 Protective restraint
892.5650 Manual radionuclide applicator system
892.5740 Radionuclide teletherapy source
application for which it is intended to be used. More important, they have been
hired to do this and generate the most profit.
All those things like comfort, safety, effectiveness, ease of use, and durability are
certainly key elements that will contribute to achieving the ultimate goal, but the
prime design criterion is whether the device will make money—at least if you buy
into the idea that being in business has profit as its prime objective. Meeting this
objective may be as simple as answering the following questions:
• Is this a viable product?
• Will anybody buy this?
• Is it reimbursable?
• Does the product fit into the company’s overall product portfolio and
business strategy?
• Can we manufacture it at a cost that will give us the desired profit margin?
The product development process must also address the purchasing, production,
marketing, financial, and customer expectations and requirements for the product
in addition to all those things that the product must do to be safe and effective in
its application. The only way to ensure that all these factors are addressed and
that they do not conflict is through the creation of some sort of master plan that
ensures that all aspects are being looked at and balanced in relation to each other;
in other words, a design control system.
Regardless of whether the design control process is mandated by a government
agency, such as it has been with medical devices, it simply makes good business
sense to control what is a very expensive process. No modern company, whether
large or small, can afford the “experiment till you drop or find an answer” approach
made famous by Thomas Edison. Today’s world simply moves too fast and is
too expensive. If your company develops and manufactures medical devices, a
design control program needs to be implemented not just because the FDA has
mandated it, but because there is really no efficient alternative for managing the
product development process. An effective design control program will reduce
the guesswork, the wrong turns, and the blind spots, and provide a structure for
sound reasoning and objective decision making.
10
Overview of design controls
Keep in mind, the design control process does not apply to basic research, at least
not in the context of this book, or to feasibility studies. However, once someone
has decided that a particular product or design will move forward toward produc-
tion, a design control process must be implemented for medical devices.
When might design controls be considered?

Design controls may be applied to any product development process and may be
initiated for a variety of reasons, including but not limited to the following:
• Identification of a new product or market
• New intended use
• Marketing need to satisfy a customer’s request or problem
• Cost constraints or savings to the customer or company
• Potential for a process improvement
• Change that is imposed by external circumstances
What are the benefits of design control

other than the obvious mandate?
Design controls help to identify what your customers want and need, what they
are willing to pay for it, and what your competition is doing. They can even help
you identify who your competition really is and where you should focus your
marketing efforts.
Implementing design controls at the outset of the design and development process
helps to reduce the overall project and product costs by permitting the identi-
fication and correction of problems earlier in the design cycle. Identification of
discrepancies earlier in the process reduces the amount of costly redesign and
rework and improves the quality of the product. Early detection of problems also
allows you to make any essential corrections and adjust resources as needed, or
help you realize that a product cannot be manufactured or manufactured at the
projected cost and may need to be modified or terminated before thousands of
dollars are spent needlessly.
The basic intent and underlying principle of design controls is that they will
enhance communication and the coordination of interfaces (e.g., team members).
A formal design control process puts all project team members on the same page
by providing them with a more complete understanding of the product require-
ments, the user’s and patient’s needs, and the company’s objectives. Tasks, depen-
dencies, and responsibilities are clearly defined so that their impact on the design
project and project team members is clearly understood.
Furthermore, design controls provide an interrelated set of practices and proce-
dures, which serve as a system of checks and balances to ensure that outputs
11
satisfy input requirements. In other words, the product you developed is what you
intended it to be, is what the customer wants, has been verified and validated as
meeting all of these requirements, and has been proven to be safe and effective
for its intended use.
An idea is born
If you stop to think about how much it costs to research, develop, and then manu-
facture a new product from the point at which people say they need it to the point
when the first batch of product comes off the production line, you might wish
you had a way to ensure that your new product is the right one and that it works
right the first time. Think about that whole process. There are a lot of steps, and
each step uses your company’s most valuable resource: your people. New product
development has a voracious appetite. It consumes people, and people use time
and money. Time and money are two of the things that you have to keep an eye on
if you want to make a profit and stay in business. An easy way to control this is
to do it right the first time—and that is what design controls can help accomplish.
So what typically happens when a new product is developed or, for that matter,
when an old product is improved? In an ideal world, the customers may say, “We
want this” or “We need that, and I’m willing to pay more for it.” If they’re not tell-
ing you that directly, then you need to go and find out just what it is your customers
really want or need. It’s called market research, and it costs money and it takes
time. But if it’s done correctly, you will know what kind of product you need to
develop to make a profitable sale in the first place, and you won’t waste time and
money developing something that you know how to manufacture but nobody wants.
Ask the customers

At this point you still don’t know if you can actually do what they want, but at
least you know what you should do. Sometimes the whole thing starts differently.
Occasionally, an inventor has a great idea. It may be for something entirely new,
or it may be a better way to do something that’s been done before in some way
that’s better than the old way. This lone inventor then sets off and begins devel-
oping the product. She risks her own money, time, and other things. One would
think that this inventor might want to check to see whether anybody else thought
the product was a good idea before moving ahead, but that is not often a question
the entrepreneur considers, and it’s often only a personal risk. Suppose, however,
that your company has a department full of inventors that you call the Research &
Development Department, and they come up with this really cool idea for some-
thing new. Do you go ahead and do it because you know you can or at least think
12
you can? Do you assume you know what’s best for your customers, or do you ask
them? Although the answer may seem obvious, it should be stated. You need to
ask your customers what they want, and you need to keep asking them through-
out the development process and, in fact, throughout the commercial life of the
product. The customer’s input and, even better, evaluation and feedback during
design as well as post-production are invaluable to the acceptance and success of
the product.
Design controls and the customer

The design control process is a cyclical system of checks and balances that starts
and ends with the customer. Product development should start with the identifi-
cation of what the customer or user wants and what he or she needs. Actually,
defining the customer can be far more complicated than it seems. Is the cus-
tomer the patient, the nurse, the physician, or the health care facility? In many cases,
the answer is all of these. Answering that question correctly is one of the major
obstacles associated with developing a new medical device or improving an old
one. Like many developments in medical devices, the answer will likely be a
combination of, and maybe even a compromise among, the many requirements
each customer wants and needs.
So now that we’ve done our market reseach and know that if we make this device
there is a market for it, now what? We need a plan. The design and development
process is often depicted as consisting of five phases or stages (see Figure 3.1).
First phase: Definition and documentation

Now all we need to do to get started is identify what we would like the product
to be or do and who needs to be involved in this product development effort. In
other words, we need to define our product, user, and interface requirements—
the design inputs—so that we can begin developing the outputs we will need to
verify and validate the device design for its intended use. We should also be able
to look at our market research data and identify and assess any known or antici-
pated risks associated with our device so that measures can be taken to eliminate
or reduce these risks to acceptable levels. We need to perform a risk analysis.
Finally, to successfully manage the design and development project, we will need
Definition Design V&V Transfer Pilot/Production

Phase 1 Phase 2 Phase 3 Phase 4 Phase 5
Figure 3.1 Design and development.
13
to establish a design and development plan that identifies all of the activities that
need to occur and assign responsibility for each task.
To get started, we need to begin asking some basic but essential questions, which
may include but certainly are not limited to the following:
• Who will use it? Are special training or special skills required?
• What are the risks associated with its use or misuse?
• What kind of environment will it be used in? Is the device susceptible to
environmental influences?
• How much can it cost? Is it reimbursable?
• What are the shapes, the colors, and the sizes that are desired?
• What accuracy and precision are needed?
• What materials can be used?
• How should it be packaged?
• Is the device supplied sterile or intended to be sterilized by the user?
• Is the device intended for single use or is it reusable?
• How will it function? Is assembly needed?
• Will the device have a shelf life or a finite number of reuses?
• Does the device require any special handling or storage?
• What equipment or accessories will it be used with?
• What user constraints might there be?
• Where do we want to sell it?
• What are the statutory and regulatory requirements?
• Will the device require installation?
• Will the device require maintenance, calibration, and/or service?
The answers to these questions are your design inputs. They include the inputs
from all the work that was completed prior to deciding that the development is
past the feasibility or research phase and is a viable product that the company
would like to move forward with in development and production. The design is
now ready to enter the design and development phase and requires compliance
with design controls.
These inputs may in fact become outputs of additional testing and design pro-
totypes based on continued work. Remember the cyclical nature of the design
control process. These and other questions are associated with the design inputs.
Which of these inputs are critical and essential, which are only desires (wish
lists), which can be modified, which are incomplete or vague, and which are con-
tradictory? All this needs to be determined and documented.
Second phase: inputs = outputs

In Phase 2 you have entered into the actual design and development phase where
you are required to operate in a controlled state; all design changes need to be
14
controlled. Phase 2 is where you begin developing your design outputs: software
code, assembly processes, specifications, design validation protocols, engineering
drawings, inspection procedures, test methods, labeling, and so on. Your outputs
are generated in response to the answers to your design input requirements ques-
tions. Your design outputs need to include acceptance criteria so that you can evalu-
ate whether your device has met requirements. These outputs often become inputs
into the next design and development phase where you will need to verify and vali-
date that your outputs = inputs. Did we meet our goals? For example, you may need
to develop a test method to verify that the device meets some design performance
requirement. The test protocol is a design output and is used to perform the test.
As such, it is also a design input to the verification process. The results of the test
are also an output, for example, the test report. The test report then needs to be
reviewed to determine whether the output met the input requirement and whether
any changes are needed. Again, the test results serve as an input into the design
review process. Any inconsistencies, ambiguities, or conflicting requirements then
need to be identified, evaluated, and resolved, and any changes needed to the inputs
and design and development plan will need to be made.
Third phase: Verify and validate

In Phase 3 we need to verify and validate that our device is what it is supposed to
be and does what it is supposed to do. Does the device meet specification require-
ments and user needs? During this phase we need to verify that we have met
the acceptance criteria defined by the test methods and specifications, and that the
device can be consistently produced. We also need to validate that we are making
what the customer wants. Validation typically follows successful verification and
is usually done through in vitro performance testing, functional testing, predicate
device comparisons, literature searches, and in vivo clinical evaluations and stud-
ies. Verification and validation activities need to be done using our outputs, for
example, test plans, verification protocols, and validation protocols in accordance
with our design and development plan.
Fourth phase: Transfer is inevitable

OK, now that we have completed all of our tasks, verified and validated that our
outputs have met our input requirements, and made any changes that needed to
be made, we are ready to transfer everything over to manufacturing and ready for
launch! At this stage your design outputs (i.e., device master record) should be
approved, your manufacturing quality plan should be established, your manufac-
turing personnel should be trained, and process validation should be well under
way, if not completed, to show the repeatability and reproducibility of the process.
Note that during the design and development process, you will need to transfer
your outputs (e.g., test methods, assembly procedures, etc.) in order to manufacture
15
your prototypes and subsequently verify and validate your device for its intended
use. Many companies transfer these documents for use during design and devel-
opment (e.g., approval is required) but do not officially transfer these documents
to production until all elements of the device master record are ready to be trans-
ferred prior to market and distribution.
Fifth phase: Improvement and optimization

As stated earlier, design control is a cyclical process. In Phase 5, you should be
looking at ways to optimize your process and improve your product or device.
Your customers’ feedback, good or bad, should always be sought for improvement
opportunities. Look at what your competition is doing. This information needs
to be continually evaluated and fed back into the design control process so that
improvements can be made. Technology changes so fast that it is essential that
you look at new and better or cheaper ways of doing things. For example, look
for ways to improve process efficiencies in order to decrease cycle times, delivery
times, and overall costs and improve product or device quality, thereby decreas-
ing product failures and rework costs.
So that’s a quick synopsis of design controls. If you think about it, it’s really just
common sense. A sound design control program will provide you with a method
for managing a project from start to finish in a manner that will ensure that what
you think you are developing is what you intended to develop in the first place,
and that what results at the end of the process is a product that meets your own
specifications and the customer’s needs and expectations. The rest of this book
discusses each step of the design control process in detail.
16
Chapter 4 Design and
development
planning
Do we really need a plan?

Let’s say you are at the mall or the airport or just walking past the bakery at your
nearest grocery store and that familiar, oh so wonderful smell of chocolate chip
cookies takes over your nasal passages. The smell is so intoxicating you swear
you can almost taste the chocolate chips melting in your mouth. Not surpris-
ingly, you get the bright idea that when you get home not only are you going
to make some of these delicious cookies, but you are going to make enough to
bring to your coworkers. Great, the plan is to make chocolate chip cookies when
you get home. Seems simple enough! OK, it’s highly unlikely that some of you
would even attempt to make chocolate chip cookies let alone share them with
your coworkers, but bear with me.
Stop! It’s time for a reality check. If your plan is that you are simply going to make
chocolate chip cookies when you get home, then you really have no plan at all.
You may think this example is a bit oversimplified, and it may be, but have you
ever had marketing people come back from a trade show having seen a cool new
device and decide that they want to make one just like it? No big deal; no elabo-
rate plan needed. They grabbed a sample from the show from which R & D can
quickly design their own version. It should be simple enough. Right?
Let’s go back to the chocolate chip cookie plan and take a closer look at what
really has to happen to make those cookies a mouthwatering reality. Before you
can begin, do you know if you even have a recipe for chocolate chip cookies? Is it
any good? Has it been proven? Let’s say you’re going with the famous Toll House
recipe. OK, that’s a good starting point. Now, what ingredients are going to be
needed, and do you even have them at home? If not, you need to make a list and
go to the store and get them. Wow, this is going to add a lot of extra time and put
a wrench into the whole process. Before you head out to the store, however, you
need to determine how many cookies you want to make in order to determine how
much you need of each item. Do you want to make a lot of small cookies or fewer
large ones? Will you need to double the recipe? Do you want to add nuts? If so,
17
walnuts or macadamia nuts? Wait, do you have enough gas in the car to get to the
grocery store and money in your wallet to purchase these items? If not, additional
stops will be necessary. You’re probably starting to think it’s time to abort this
wonderful plan, but don’t give up yet. The fun is only just starting.
Let’s say you’re back from the store with all of your ingredients and you are ready
to begin making the cookies. Wait, the recipe says that the butter has to soften
and the eggs have to be at room temperature. Another delay! No problem, while
you are waiting for the butter and the eggs, you can start to measure out your
ingredients and get your tools together. What equipment are you going to need
to make the cookies: mixing bowls, mixer, spoons, measuring cups, pans, oven,
and so on? Let’s just assume that you have all of these items to avoid any further
delay and headaches.
Now you’re ready. What gets mixed together when, in what order, with what
equipment, and for how long? What temperature does the oven need to be set at
and how long does it take to preheat? If you don’t want another delay, you need to
make sure that your oven is ready when you have finished mixing the chocolate
chip cookie dough and the cookies are on the baking sheet ready to be put in
the oven.
Great, the oven is preheated and the dough has been dropped in spoonfuls onto
the baking sheets. Now, how long do they need to bake? Do you want them a
little gooey or crispy? The baking time is also going to vary based on the size of
the cookie and your oven, so you better check on them periodically. No one likes
burned cookies, and you didn’t go through all this trouble just to throw them out.
OK, mission accomplished; the cookies are baked, but guess what? Now they
have to cool.
Finally, the cookies are cooled, and it’s time to eat. Wait, do you have milk? Yes!
But how are you going to pack some of them up for your coworkers so that they
don’t break and don’t melt by the time you get to work? Most important, who’s
going to clean up the mess?
As you can see, what may seem like a simple project can turn into a much more
complex project quite quickly. Many decisions and changes are likely along the
way, and often obstacles delay the completion of tasks or halt the project com-
pletely. A plan is needed to ensure the process or project is appropriately con-
trolled and objectives are met. Everybody knows that, but not everybody does it.
Many think it is a waste of time; however, there is absolutely no way to success-
fully complete a complicated project without a plan. It shouldn’t matter how long
the planning process takes; it needs to be done. Just because someone can articu-
late the product doesn’t mean he or she can tell you how to develop that product
for manufacture and sale.
18
Design and development planning
Design and development planning requirements

The FDA’s requirements for design and development planning fall under 21 CFR
Part 820, Subpart C, Section 820.30(b). The ISO 9001 and ISO 13485 design
and development planning requirements fall under Section 7.3.1. The design and
development planning requirements include the following:
• Establish a design plan
• Determine the design and development stages
• Identify the appropriate design and development activities at each stage
and assign responsibility for each
• Assess and reassess risk during development
• Define and manage the technical interfaces
• Review, update, and approve the design plan as it changes
Sounds simple enough, but let’s take a closer look at these requirements for clar-
ity and understanding. Remember, once you decide that you have a viable product
based on preliminary design work that you may have performed (e.g., feasibil-
ity studies), and you have decided that you are going to proceed forward with
development, a design and development plan must be established. Your design
plan will help to control the development process and help to ensure that the
product meets requirements and is safe and effective for its intended use. The
design plan is essentially a road map (or recipe) for the development project. As
such, the design plan needs to identify the design and development stages and
identify or refer to the design and development activities required at each design
stage (i.e., review, verification, validation, and design transfer activities). If you
think about the chocolate chip cookie example provided previously, your design
and development stages might be considered your prep work, the mixing process,
the baking process, cooling, packaging, and cleanup.
In addition to identifying the steps or tasks required, your plan also needs to
identify who is responsible for each task or activity. The requirements do not
preclude one-person companies or small project teams, but this does imply a
level of expertise is expected for most of the functions that have input into the
design and development project. So far, then, we have determined that the design
and development plan needs to identify what activities are required and what
resources are necessary, who is responsible for each activity, when activities
need to be done and when results need to be reviewed, and how activities will be
performed and what constitutes success, that is, method and acceptance criteria.
Again, if we think about the chocolate chip cookie example, our plan needs to
consider what steps are required to make the cookies and who is responsible for
each step; what ingredients, equipment, and utilities are required; when each step
needs to be completed, in what order they need to be completed, how are they to
19
be performed, and for how long; and, last, what is considered to be the acceptance
criteria for an acceptable cookie.
As we will discuss in more detail in later chapters, risk analysis should be initi-
ated and addressed in part at the outset of the design and development process and
considered continually throughout the development process. With that being said,
your design plan should define when risk assessments will be conducted. Risk
assessments should be scheduled similarly to design reviews. The most opportune
times would be upon design and development approval, at the initiation of design
inputs, and after the completion and review of verification and validation activi-
ties in order to determine whether any unanticipated risks have surfaced and/or
your original assessment was inaccurate.
Your design and development plan also needs to define the technical interfaces,
both internal and external, that input into the design and development process.
These interfaces need to be managed to ensure effective communication and a
clear understanding of who is responsible for what and how activities impact each
other. This determines the dependencies and independencies. You want to make
sure that the people assigned to perform design and development activities are
qualified to perform those activities. They should be coordinating these tasks with
the appropriate functions and personnel and communicating and reporting on any
problems and the status of these activities on a regular basis. It doesn’t matter
whether those tasks are assigned to employees, consultants, or other companies.
For example, if internal resources cannot tell you if the product you are making is
sterile (assuming it has to be), then you need to find someone or someplace quali-
fied to provide that testing. But the plan goes one step further; it requires that we
show how all these resources will interact. Design controls require that we think
about and identify how groups, sometimes working independently in their own
disciplines, will be sure that what they are doing will be integrated into the tasks
of what other resources are doing. The output from one group is often the input for
one or more other resources.
It seems obvious that different groups of people working on the same project
should know what the others are doing. Everybody knows that, and for the most
part, everybody does it. It’s done most often with the big things, but we some-
times miss the smaller subtle things, and most often we miss the soft require-
ments, the expectations, and the wish list. The fact that one group may not know
what another department or group expects is not usually due to anything sinister,
but most often due to poor communication. The folks in marketing know that the
customer wants this product to be soft to the touch and have a low profile so it will
be unobtrusive when worn. They’ve talked to users, they’ve run focus groups, and
they made sure it was in the product development goals right from the beginning.
The design folks knew about it too. So how come what is being developed isn’t
soft enough or unobtrusive enough for the marketing group?
20
Part of the reason may be a poorly written specification. Does “unobtrusive” mean
a profile that’s 3 cm high or 0.3 cm? If everyone knew that it meant 0.3 cm, for
example, did the design folks tell marketing (and the rest of the team for that
matter) that some of the other critical objectives couldn’t be met at a profile
that thin? There are lots of these small misunderstandings that occur. Remember
the greatest problem in communication is the illusion that it’s been achieved.
Design and development is a “live” process, and as such the design plan will con-
tinue to changes as the design evolves. As a result, the design plan is required to
be updated, and any changes to the plan must be reviewed and approved. Probably
the best way to make sure this happens is to schedule these reviews on a frequent
and regular basis. These meetings do more than just force a review of the project
plan. They force the procrastinators to update and document what they’ve done,
what they’ve discovered, and what needs to be changed and modified. It also
forces other functional groups to respond to these changes and the person respon-
sible to approve any changes or initiate a new task to resolve the fact that the input
no longer quite equals the output.
So what makes up the plan?

You can’t just walk into the room where you keep your technical folks and say,
“I want a new, fully functional, implantable, small intestine prosthesis.” You can’t
wander on down the hall to the marketing folks and tell them to get ready for
launch in 24 months and then stop by the regulatory office and tell those people to
file a 510(k). We all know better. There are hundreds of things that need to happen
before a product is ready for a launch. But that’s why we pay all these technical,
marketing, and regulatory people; they know what they have to do. But what they
don’t know are the details. They don’t know what is happening somewhere else.
And every time someone changes something, then everyone else has to adjust to
what that person is doing.
As stated earlier, your design plan is essentially a road map for the project, similar
to a AAA TripTik travel planner. It tells you how to get from point A to point B.
In the context of the design and development of a medical device, it tells you how
to go from concept to production. With that in mind, you should ensure your
design and development plan considers and defines the following elements:
• The goals and objectives of the project: What is the product that is to be
developed, and what is its intended use?
• The organizational or departmental responsibilities and interrelation-
ships: Who is doing what inclusive of external resources such as contrac-
tors, consultants, and testing labs, and how are they related?
21
• The tasks: What are the major tasks or milestones, as well as the deliv-
erables associated with each task? What tasks depend on others before
they can happen?
• The resources: What will it cost? Do we have the resources (money, people,
equipment, time)? If we hire two more engineers, can we do it faster?
• The time schedule: What tasks should start first? How long does each
task take? What tasks can be done concurrently? Which critical tasks, if
late, affect the outcome of the entire project? There should be a time line
specifying a time frame assigned to each task or sequence of events so
that progress can be tracked.
• The milestones: When do we get together for a design review meeting
to find out if there has been any progress? Are there problems? Do
changes need to be made? Do major decisions need to be made? When
can we launch? Design plans should identify key decision points or
milestones in the project, for example, results of biocompatibility test-
ing, functional testing, clinical testing, or evaluation. The completion
of these tasks suggests a good time for a design review meeting.
• The communication activities: How do we tell everyone who needs to
know what just happened? When should major reports be issued? When
do change notifications occur? Design plans should identify notification
and communication activities, for example, when a design review and/or
risk assessment will take place.
Planning techniques
Design and development plans will vary depending on the complexity of the proj-
ect and the degree of risk associated with the device or product. For example,
plans may take the form of a simple flowchart, task list, or simple time line for
less-complex projects, or for larger projects, may make use of PERT (program
evaluation and review technique), CPM (critical path method), or Gantt charts.
It is beyond the scope of this book to provide an in-depth study of planning tech-
niques or even some of the planning methods. For technical projects, however,
there are a couple of techniques that have been used effectively.
Gantt and PERT charts are visualization tools commonly used to display tasks
required for task scheduling and project management. They are probably the best-
known project management charts. Gantt charts are essentially bar charts that
emphasize the time it takes to complete tasks, while PERT charts are flowcharts
that emphasize relationships between tasks (especially their dependencies).
22
Gantt charts
The Gantt chart was developed by Charles Gantt in 1917. It provides a graphical
representation of the sequence of tasks and is an excellent tool for quickly assess-
ing the status of a project. Each task is listed in a column along the vertical axis
(y-axis). The horizontal axis (x-axis) is the time scale over which the project will
last (days, weeks, months, years). The time to complete each task is then repre-
sented by a horizontal bar that begins on the start date and ends on the estimated
completion date. Arrows connecting independent tasks reflect the relationships
between the tasks they connect. The relationship usually shows dependencies
where one task cannot begin until another is completed. The resources necessary
for completion of each task are identified next to each task, and often a bar within
a bar will be used to show the task status from 0 percent to 100 percent comple-
tion. If a task takes longer or less time than expected, everything slides appropri-
ately. Figure 4.1 shows the typical elements of a Gantt chart.
When is a good time to use a Gantt chart?

• When you have a small to medium-sized project
• When you want to be able to view each stage of your project inclusive of
goals and resource allotment
• When you want to easily depict and review project status
Figure 4.1 Gantt chart.
23
When might a Gantt chart not be appropriate?

• If your tasks aren’t known and/or time estimates for each aren’t worked out
• If you want to make changes to your schedule, as you will need to redraw
the chart
• If you want to map out multiple scheduling options within the same chart
PERT charts
PERT charts were first developed in the 1950s by the US Navy to help manage
the Polaris submarine missile program. A similar methodology, the CPM, has
become synonymous with PERT. Each chart begins with an initiation node that
branches out into other nodes that represent events or milestones. Directional
lines representing tasks in the project link these nodes. The direction of the
arrows on the lines indicates the sequence of tasks. These are called dependent
tasks. Tasks that are not dependent on the completion of another task so they
can start and can be undertaken simultaneously are called concurrent or parallel
tasks. Lines diverging from the arrows of the dependent tasks may represent these
tasks. Dotted lines indicate dependent tasks that do not require resources. They
are considered dummy tasks. After all of this is laid out, it is relatively simple to
find the longest time line ending with the overall goal. This is referred to as the
critical path, and it estimates the project length. It shows the tasks that need to be
completed on time in order for the estimated project completion date to remain as
that originally calculated.
What are the advantages of using PERT charts?

• A PERT chart helps to simplify the planning and scheduling of large and
complex projects.
• A PERT chart explicitly defines and makes visible dependencies (pre-
cedence relationships) between the work breakdown structure elements.
• PERT facilitates the identification of the project’s critical path.
• PERT facilitates the identification of early and late start, and slack for
each activity.
When might PERT charts not be appropriate?

• In a PERT chart, the relationship between the task at hand and the time
allotted for said task may not be as immediately obvious as in a Gantt
chart.
• PERT charts also tend to underestimate actual risks inherent to your
project.
• The lack of a time frame on most PERT charts makes it harder to show
status.
Figure 4.2 shows the elements of a typical PERT chart.
24
Manufacture Prototypes Run Clinical Trial/Evaluation
Market Survey
Engineering/
1 week Clinical Affairs 2 months
Marketing 4 weeks MFG
06/11/12 06/15/12 06/15/12 08/15/12

01/03/12 02/01/12 Design Team Meeting Develop DMR Outputs
All 1 Day Engineering/ 3 months

QA
Product Bench Testing Approve
03/01/12 03/05/12 06/04/12
Inputs
R&D 6 weeks File 510(k)
01/03/12 02/15/12 RA 3 months
06/11/12 09/24/12
Draft Initial Product Claims
Marketing 1 week
02/15/12 02/22/12
Figure 4.2 PERT chart.
25
Microsoft Project© is a prime example of a software program that is available to

create Gantt and PERT charts.
Project planning: How do I get started?

The hardest part of project planning is determining all of the tasks that need
to be done and accurately estimating the time to complete each of these tasks.
Things almost never go according to plan, so you need to take that into consider-
ation when developing your project plan, hence the requirement that your plan be
reviewed and updated as you progress through design and development.
When I first started my consultancy business, the hardest thing to do was esti-
mate project times and associated cost. I almost always underestimated the
time to complete a project because I didn’t anticipate some of the obstacles that
I might encounter along the way. One area that was underestimated quite fre-
quently was the time to complete an internal audit. Clients always assume an
internal audit should take only a day or two, especially if they design and manu-
facture only a few products. However, when you perform an audit, you typically
follow one or two products from inception through manufacture, distribution, and
service, as well as postmarket. You, as a manufacturer, are required to develop a
comprehensive quality management system. As a result, whether you manufac-
ture one product or many, it is irrelevant to the audit because the auditor still has
to look at the whole system. What is relevant is the complexity of the product with
regard to design and development and manufacture, as this will affect the time
spent in these areas.
A comprehensive internal audit will typically take about five days to complete
from start to finish. If someone tells you he or she can do it in a day or two, then
you are not getting a comprehensive audit. For those of you who undergo Notified
Body audits, you know that the length of time to conduct surveillance and full
QMS audits has nothing to do with the number of products you design and manu-
facture. The time is calculated based on the number of employees. I don’t neces-
sarily agree with this determination of time, and you also have to remember that
when your Notified Body conducts its full QMS assessment it usually takes five
man days. Surveillance audits only take a day or two because the Notified Body
is looking at only a portion of your system.
Keeping this in mind, you need to make the first step in creating a project sched-
ule clearly defining your design inputs so that you can determine what outputs are
needed. These outputs are your tasks that need to occur. Each output will require
an assignment of resources and a determination of dependency or independency
with regard to other tasks. We will take a close look at design inputs in Chapters 5
and 6.
26
Next, when assigning the duration time for tasks, don’t use the first time that
comes into your head. You won’t get an award for underestimating the time
required to complete your tasks, and no one will be happy when you have to
extend your product launch date. Believe me, heads will roll.
The best way to determine the time required to complete a task is to identify three
times for each task:
• What is the time in which you can expect to complete this activity if
everything works out ideally (best case)?
• Under average conditions, what would be the most likely duration of this
activity (most probable)?
• What is the time required to complete this activity if almost everything
goes wrong (worst case)?
With these estimates, you can use a weighted average. For example,
2 (best case) + 2 (worst case)
Most probable duration = = best case
5
Now that you have identified your tasks and the time to complete each, and
everyone has agreed and signed on to the project, you can initiate the design
and development process. Remember, there are a number of reasons why proj-
ects take longer and cost more than anticipated. Usually it is because you don’t
account for unforeseen circumstances. Things often change as you progress
through the design and development cycle. Testing may show the product doesn’t
work the way you expected it to, and some design changes and new testing may
be required. Materials may not be available from suppliers, may be too expen-
sive, or may not be compatible. Marketing may decide to add new claims that
you will need to verify and validate. All of these tasks will need to be added to
the project plan and will extend the time to project completion or product launch.
These revised plans will need to be reviewed and approved and any problems or
conflicts resolved before progressing forward.
27
Chapter 5 Design inputs—Part I
What are design inputs?

The FDA’s 21 CFR Part 820.30(f) defines design input as the physical and perfor-
mance requirements of a device that are used as a basis for product design. In a
nutshell, your design inputs are your product requirements, taking into account the
product’s intended use and the user’s requirements. It is important to understand
that your design inputs are your intentions for the device. They are not solutions.
Design controls, as mandated by the FDA and as covered in this book, do not
apply to what is done during research or feasibility. Before design controls can
begin, someone has to confirm that there is a viable product that can be devel-
oped. This affirmation is usually based on some type of feasibility testing that has
shown the product has some promise in meeting intended use and user require-
ments. There also should have been some type of market analysis that indicates
that the product is worth pursuing. Someone should have also made a determina-
tion, no matter how crude, that the product could be made at a cost and sold at a
price that will make money. All of these things should be outputs from feasibility
and will become part of the design input.
Design input is probably the most critical element of the design control process
and not necessarily just from a regulatory point of view. It is certainly important
to know that the medical device being developed is safe for human use and is
effective for the intended use. That is, without a doubt, a regulatory issue, and it
is in fact the reason why the Pure Food and Drug Act created the FDA in the first
place. But equally as important to regulatory issues is the simple fact that clearly
defining design inputs is just sound business.
It is also important to want to minimize the risks where possible. No legitimate
company wants to harm its customers or make a product that doesn’t work. But
there are other risks. A good business doesn’t want to spend more money than it
has, or can get, to develop a product that no one will buy. It is unimaginable that
someone would waste time and money developing a product whose selling price
would be 600 percent higher than the market will bear (or that reimbursement
will allow). No one wants to develop a product that is as big as a microwave that
should have been as small as a cell phone to be acceptable to doctors, nurses, and
patients. These things can be avoided with clear and accurately defined inputs.
29
The foundation: Design input

Design input is arguably the most important part of the design control process. It
is the foundation for the entire design and development activity. If the foundation
has basic problems, then the entire structure will be suspect until those problems
are identified and corrected. The scope of the design input process and the level
of detail that is needed will be dependent on the complexity of the device and the
risk associated with its use.
Again, your design inputs are the physical and performance characteristics and
requirements for a device. They are the basis for the design. Companies are often
urged to initiate the design and development process without clearly understanding
or yet knowing the product requirements. They figure they will figure it out as they
go. As a result, project deadlines are missed and projects run over budget because
of costly redesign activity further into the design and development process. By
spending the time and the resources to get these inputs defined accurately up front,
a company can save an enormous amount of time and money in the long run.
Once again it is important to keep in mind the cyclic nature of the design control
process. Inputs are themselves the output of previous work; they are not merely
pulled out of a hat. At least they shouldn’t be. The design inputs that initiate the
design control process cannot be all wishes and desires. Remember, the early
exploratory work, the research, or the feasibility study (whatever you would like
to call it) is not part of design controls as defined by the FDA. At the point when
design controls become mandatory for a medical device and need to be defined,
it is hoped that you will have the output from a great deal of preliminary work.
As a result, design controls should typically begin with a prototype that has been
defined as likely to become a commercial medical device. The output of any
testing and studies completed prior to the implementation of the design control
process are the design inputs for the development process.
Design input requirements

Design input is the most important element of design controls. It is the starting
point, and it provides the foundation for successful product design and develop-
ment. For complex designs, design inputs may consume as much as 30 percent of
the total project time. The design input requirements to satisfy the FDA’s 21 CFR
Part 820.30 and ISO’s 13485 Section 7.3 include the following:
• Inputs need to be comprehensive and realistic and defined in unambig-
uous (can be verified by an objective method of analysis, inspection,
or testing) and quantifiable terms (including a measurement tolerance
where feasible).
30
Design inputs—Part I
• Inputs need to identify the critical functional, performance, safety, and

reliability requirements for the product, taking into account the user’s
needs and the device’s intended use. Those inputs essential to the proper
function of the product, and necessary to meet the intended use, user’s
needs, and regulatory requirements, must be clearly defined. In doing so,
it is important to consider environmental requirements and limitations
(e.g., temperature, humidity, altitude, energy requirements, EMC, ESD,
etc.) and human factors (e.g., ergonomics and ease of use, experience and
education of the user, etc.).
• Inputs should include internally or externally imposed or essential
requirements. These may include the following:
• Customer requirements (including user and patient needs) both
stated and implied.
• Product intended use requirements. These may include functional,
performance, or safety and reliability requirements necessary for
the product to function effectively or as it is intended to be used.
• Regulatory and/or statutory requirements imposed on the product
based on its intended distribution and that take into account the device’s
intended use and issues of safety, equivalence, or effectiveness.
• Requirements imposed by the organization based on market research,
clinical trials, competitor products, previous similar products, contrac-
tual requirements, environmental requirements, and so on.
• Requirements related to any known risks, from contraindications,
precautions, and warnings to product labeling and instructions for use.
• Design inputs need to be documented, reviewed, and approved for ade-
quacy by a designated individual(s). The approval needs to include the
date and signature of designated personnel.
• Any incomplete, ambiguous, or conflicting requirements need to be
resolved, and the method for doing this needs to be documented in the
design control procedure (see Appendix A).
When you clearly and completely define the requirements that are essential to
your product early in the design process, you, in turn, reduce expensive redesign
and rework costs that would likely be incurred further on in the development or
production process. Better still, clear communication of the requirements will
allow everyone involved in the development process to be on the same page with
regard to knowing what it is you are developing, the requirements that need to be
met, and the resources and the time frame needed to do it.
The concept document

The concept document, sometimes referred to as a Product Initiation Request, is
the first step along the way to an effective design control process. The concept
31
document, or other term, is a document that kicks off the early stages of the prod-
uct development process or what is typically referred to as feasibility.
Do not confuse a concept document with the formal Design Input Document that
kicks off the design and development process and design controls. The concept
document, or Product Initiation Request, is the starting point for the design and
development process. It defines the basic requirements for a product that is, or
is about to be, developed. By its very nature as a starting point, it is not usually
comprehensive in nature; however, it should be what its name implies: a written
document. It is not a verbal agreement among a few individuals to go off and
develop a new medical device. In fact, even the lone inventor would benefit from
producing a concept document; it would help him/her to begin to solidify that
“lightbulb” that went off in his/her head the day before.
The concept document is generally qualitative in terms, especially when it is being
used to define a new product or application for which little is known and when the
product being developed is “new” to the company undertaking the development.
It can, however, contain any known quantitative information, but that is typically
left for the Product Performance Specification (PPS) document.
In an ideal world, the marketing department of a company prepares the concept
document based on a perceived or real need for a product. However, it can be
initiated by anyone from any discipline. The concept document’s purpose is to
broadly define the requirements of a new product idea so that the R & D depart-
ment can begin translating these requirements into verifiable terms and perform
some preliminary feasibility/bench testing to determine whether the concept/
product is viable. Remember that inputs need to be able to be verified and vali-
dated, and therefore need to be put into terms that allow for such. The outcome of
this process, that is, feasibility, can then be reviewed by key company personnel
so that a decision can be made as to whether the project should move forward
into development. Several elements should be included in the concept document:
• A statement of product purpose or indication: Why would we want to
develop this product? Is there an opportunity? How big is the opportu-
nity, and what are our expectations?
• A statement of the market position: How is this product going to com-
pete? Where? Against whom?
• A statement of essential or desirable characteristics: What does the
product do? What does the product need to do to be successful? What
does it look like (e.g., size, shape, color, etc.)? What kind of delivery
system is required or preferred? Does the product need to be compatible
with other products, equipment, or accessories? Is the product going to
be supplied sterile or nonsterile? What method of sterilization will be
used, and will the packaging be adequate?
32
• A statement of the intended claims: What indications would you like to be

able to make and can be made? Are there any limitations or exclusions?
What claims are competitors making that you would like to also make?
• A statement on suitable packaging: Do the intended users require spe-
cial packaging for ease of opening? Does the product design require
specific packaging to ensure stability? Does the packaging need to be
able to withstand sterility testing?
• A statement on the clinical and technical requirements: What is the
product intended to treat or manage? How is the product envisioned to
provide the treatment or management? How does it differ from other
similar products? How is it the same? Will a clinical study be required,
or will a clinical evaluation be sufficient?
• A statement regarding cost: What should the product cost? What does it
need to cost? Will it be reimbursed?
An example of a simple Product Initiation Request or concept document is pro-
vided in Figure 5.1.
Once the concept phase is completed, the output from this evaluation/testing must
be evaluated to determine if there is a viable product. If management decides
to move forward with the design and development of the product, appropriate
approval(s) should be documented, and a design team composed of personnel
representing different disciplines should be assembled to prepare the PPS and
formally kick off the design and development process.
Product performance specification

Once the concept document has been completed, feasibility/bench testing has
shown that there is a viable product capable of meeting basic requirements, and
management has agreed to move forward with the development of the product, a
Design Input Document or PPS can be developed. The PPS represents the output
or results from the research or feasibility phase and serves as the primary input
to the design and development phase. Any ambiguities or changes that might be
necessary with regard to the initial design concept inputs (e.g., Product Initiation
Request) should be resolved and incorporated into the PPS.
Unlike the concept document, the PPS should be comprehensive. At this point in
time you should have some type of crude prototype or model of your product and
be able to define the majority of your product requirements in verifiable or quan-
tifiable terms. Any essential or critical outputs for the product to ensure its proper
performance, functioning, or use should also be known and stipulated. Note that
it is important that you make a clear distinction between what are “desirable”
33
Product/Project Name: Manometer (Disposable) Initiation Date: 06/01/2012
Intended Use/User Need:

The intended use of the Disposable Manometer is to provide a visual method
for clinicians to monitor proper airway pressure and PEEP during ventilation or
resuscitation.
Marketing Requirements/Market Position:

The manometer will be an accessory product to CPR hand resuscitators. The esti-
mated total market size for the child and infant CPR bags before the manometer is
$2,290,840. After the manometer is completed, an increase of 10% in sales of the
infant bags and 5% in sales of the child bags is projected. This represents a total
increase of $322,977 in sales revenues and a unit sales increase of 6,400 units.
Product Requirements:
Compatible with CPR hand resuscitators and can be used with other breathing
devices (e.g. resuscitation bags, hyperinflation bags, CPAP masks, CPAP circuits).
Single patient use, disposable, and non-sterile.
Range of 0-60 cm H2O. Gauge has color coding green, yellow and red.
Lightweight. Latex-free.
Claims:
Easy to Read Dial
Measures up to 60cm H2O
Reduces the need to look away from the patient while resuscitating
Allows in-line use on most manual hand resuscitators (with adaptor)
Allows for monitoring of PEEP pressure
Allows for monitoring of Airway pressure
Attaches easily and directly to the Patient Port on standard CPR Bags
Lightweight, Cost efficient
Packaging Requirements:
Individual poly bag, 20 units per case, non-sterile.
Clinical/Technical Requirements/Consideration:
Viewable while patient is being tended to, measures up to 60 cm H2O
Product Cost:
Target production cost under $3.00, target sales price $5.00 to $10.00 each
Author: _______________________________________ Date: ______________
Figure 5.1 Sample Product Initiation Request.
34
requirements and what are “essential” requirements for the product. Although
the sales and marketing group would love to have a product with lots of bells and
whistles, the bells and whistles may not be feasible given technology, cost con-
straints, time constraints, and so on. Customer expectations, human factors, and
safety must also be taken into consideration, as should requirements that may be
required to gain access to a certain distribution market or user population.
A multidisciplinary team is essential to developing a comprehensive PPS. There
are simply too many questions that need to be answered that require an expert in
that field or area. If a company does not have the specific or adequate resources
in-house, it needs to find an alternative (e.g., subcontract). Think of the time and
the money that would be wasted if a product were developed that was revolution-
ary for the indication, but became trapped in the regulatory approval process
because developers were unaware of the regulatory requirements for the product.
It is also important that when you define your inputs they be put in layman’s terms
so that all team members can clearly understand them. Remember, not everyone
is a rocket scientist or intimately familiar with the technojargon. If you want your
team to be fully committed and provide value-added feedback, then they need
to understand what you are talking about. No one wants to be the one to raise
his hand and say he doesn’t understand. Usually people just nod their head and
pretend they get it.
Your Design Input Document (e.g., PPS) should typically consider four areas:
• Performance characteristics for the product: What does the product
need to do? Who needs to use it and how?
• Product characteristics: How does it need to look (i.e., design)?
• Marketing requirements: Where is it intended to be sold, and what
claims need to be able to be made?
• Regulatory and/or quality requirements: What standards or regulatory
or statutory requirements are applicable to the product?
These four design input areas can be grouped into three basic categories: inputs
related to device functionality, performance, and device interface. Virtually every
product will have requirements that fall into all three categories. There are, how-
ever, many instances where it may be impractical to establish every functional
and performance characteristic at this design input stage. However, in most cases
the form of the requirements can be determined, and the requirement can be
stated with a “to be determined” numerical value or a range of possible values.
Let’s take a closer look at these three areas. Your functional requirements will
define what the product does from a functional or operational standpoint. Your
performance characteristics will define how much or how well the product is to
perform. Examples may include speed, strength, response times, accuracy, limits
of operations, and so on. This also includes a quantitative characterization of the
35
use environment, including, for example, temperature, humidity, shock, vibra-

tion, electromagnetic compatibility, and so on. Requirements relating to device
reliability and safety also fit into this category. Last, your interface requirements
are going to define how the product is to be used and/or what it needs to be com-
patible with. For example, an interface that is important in every case is the user
and/or patient interface. Your interface inputs relate to those characteristics that
are required of the device as a result of external systems that are outside the con-
trol of developers; for example, the equipment of other devices or parts that the
product may be connected to.
Because (1) design inputs are so critical to medical device/product development
and success; (2) some inputs are overlooked or defined qualitatively when a quan-
titative measure is both desired and possible; and, (3) people often confuse nec-
essary and critical requirements with wishes and desires, we will look at design
inputs in more detail in the next chapter.
36
Chapter 6 Design inputs—Part II
From feasibility to development

Some medical device manufacturers have difficulty determining when the feasibil-
ity phase or the R & D phase of a project ends and the developmental stage begins.
Remember, a Product Initiation Request form or similar document is typically used
to kick off the feasibility or research stage of the development process. This docu-
ment allows R & D to play around with the concept and try to figure out if the prod-
uct is even a viable one. Even in industrial research there are unknowns and certain
fundamental facts that need to be studied, quantified, and explained before anyone
should even think about developing a new product. The research or the feasibility
stage should also be used to decide whether a business opportunity even exists.
So, we now enter the development stage and need to implement the design con-
trols process as we make our first prototypes. Correct? Not necessarily. It may be
quite reasonable to make several prototypes before the actual development begins
and sometimes before the input requirements are even partially understood. Do
not equate prototype design with finished product design. The early prototypes
lack many of the features that the final product will have. These early prototypes
may not indicate a process by which they can be made, or be made of the intended
materials; they are feasibility models. But when there is enough information to
think that there may be a new product or a new business opportunity, the process
of design controls should be initiated and the Product Performance Specification
(PPS) developed.
Performance characteristics
At this point in the process, we have completed our feasibility portion of the
development process and/or we all believe and agree that we have a viable product
that we want to develop and bring to market. Our next step is to take a look at the
results of any feasibility work and to define our product inputs in a manner that
will allow us to determine the required outputs and verification and validation
activities. It is now time to develop a PPS, a template of which can be found in
Appendix B.
Since everything has to start somewhere, let’s assume that the starting point for
our design inputs begins with defining the performance characteristics of our
new product.
37
Indications for use

The first question we need to ask and answer is, “What is the device’s purpose?”
The second question is, “Can the patient affect its use; for example, are there any
limitations of hearing, sight, strength, mobility, age, and so on that would influ-
ence the usefulness of the product?”
Anyone who has ever submitted a premarket notification (510(k)) to the FDA
should be familiar with this requirement, as one of the submission requirements
is the submittal of a separate “indications for use” page. With that being said, the
indications for use statement typically mimics that of a competitor’s device and
is often dictated by the regulation number and/or product code that the device
falls under, unless you are designing a new device for which there is no predi-
cate device or adding an indication to an existing device that was not previously
indicated. Per the FDA, the indications for use statement should describe the dis-
ease or condition the device will diagnose, treat, prevent, cure, or mitigate and
include a description of the patient population for which the device is intended
(see 21 CFR Part 814.20(b)(3)(i)). A device’s intended use defines what the device
does and encompasses the indications for use.
Let’s use an example of a wound dressing. At this point in the development cycle,
you must define the indications for use with something more specific than just
saying, “We want to develop a wound dressing.” It is not enough to simply say
what the product is supposed to be or what it is supposed to do in such general
terms. If you were to plug in “wound dressing” under the product code section of
the FDA’s medical device database, the result would be a listing of fourteen differ-
ent types of wound dressings with different assigned regulation numbers and device
classes. Therefore, defining the indications for use clearly, concisely, and accu-
rately is a necessary first step in ensuring that you design a product that meets the
needs of the market, the patient, the end user, and the regulatory environment for
which the products is intended to be used.
Suppose we say that our wound dressing should be indicated for use on chronic
wounds. Is that detailed enough? Again, probably not. We need to decide if we plan
on marketing a product that is indicated for all chronic wounds or if there are con-
traindications. Will the product be indicated for leg ulcers or for pressure sores or
for both? What about burns, surgical wounds, or chronic wounds that are infected?
Is there any other type of wound that our research indicates might be appropriate
for the product? Don’t forget, these inputs should be based on data that are rela-
tively concrete. It doesn’t mean we still can’t have a wish list, but if all the prelimi-
nary work has shown that this new wound dressing does not heal wounds and that
nothing that could be added to it would change that, then don’t say the indication
is “heals chronic wounds.” If you did, it could set in motion a series of events that
will ensure a product development that will fall short of its goals and perhaps even
fail completely.
38
Design inputs—Part II
A word of caution: although it should be apparent to everyone, this section of the

PPS is to define the indications for use not the claims for the product. The defini-
tion of the claims will come in a later section. Also remember that these are the
inputs from the work that has preceded the development or are the result of the
continuing work on products that are already in the market and may have received
premarket approval from the FDA.
Remember, a new indication for an “old” marketed product will typically require
a new FDA filing. For example, if the inputs suggest that a wound dressing that
you are already marketing and is cleared for use on chronic wounds may also be
safe and effective in the management of nonhealing surgical wounds, a new filing
to the FDA will be necessary for these new indications, even though the product is
already “cleared.” This new indication may also result in different functional and
product requirements and subsequent verification and validation.
Clinical procedure for use

The next input requires that you define how the product is to be used. There
should be enough information at this point from preliminary research or from
competitive product literature to be fairly specific. This input or information will
translate into your “instructions for use” and should include any requirements
for assembly or setup and/or cleaning, disinfection, sterilization, inspection, or
testing prior to use. Some details may still be uncertain and need to be verified
and/or validated, but at this point you should know the general procedure for use.
For example, if you are planning on developing a reusable surgical instrument,
you may not know what method of sterilization is appropriate after use, the spe-
cific parameters that are required, and/or what cleaning or disinfection solution
is adequate, but you will know if such steps will be required. Remember that this
section has several audiences. It not only tells the engineers what design param-
eters and requirements they need to include in the ongoing design, but should also
be written with the patient and/or end user in mind. This means that the instruc-
tions should be written using vocabulary that is suited for technical/engineering
personnel, trained or professional personnel, or the layman. The instructions for
use should be kept as simple as possible, even if the device is intended for use only
by a physician. Pictures are often an effective means of displaying this informa-
tion. The instructions for use should be revisited as the design and development
continues to ensure that it is accurate, comprehensive, and adequate.
Relevant setting/use environment

Defining the “relevant setting/use environment” characteristic incorrectly can
severely restrict a product launch. This particular input will have some techno-
logical and clinical facets to it, but it should be thought of as a marketing input.
39
This input should be easily addressed by answering the question, “Where is this
product currently used or most likely to be used?” One might also ask, “Where
might we like to see this product used?”
At this point you have already defined the indications for use. So now you need to
ask, “Where is this indication usually treated or managed?” Several answers may
come to mind such as emergency rooms, hospitals, home health care, clinics, and
nursing homes. Depending on the device being developed, the answer may be all
of the above. But those may be the standard answers. Maybe there are other cur-
rent or potential use markets such as physician’s offices, operating rooms, emer-
gency rooms, ambulances, rehab facilities, outpatient clinics, and so on. As you
can see, the answer to this question will help determine the total market for the
product. Who would’ve thought years ago that airports and airlines would be a
market for defibrillators?
Your new product may have gone through its feasibility phase aimed all the while
at the current market niche of the company. But maybe somewhere along the way
marketing realized that this new device has a much broader spectrum of use.
Or maybe this product is intended for an entirely new market that has not previ-
ously been tapped by the company. Or the new device will launch the current
company product portfolio into new use environments not previously considered.
If so, it will be important to validate that the product meets the user needs in
these environments. This new input should also trigger a check of the company’s
resources to ensure they are adequate. For example, will specialized training of
the sales force be required to ensure the device is correctly marketed and/or will
more sales personnel be needed to compensate for the increased market potential?
These tasks will need to be addressed prior to launch as part of the design process
if you want the launch to be successful.
Medical specialty of the user

This should be a relatively easy input to define. To address this requirement you
might ask, “Does the product require the intervention of a health care profes-
sional, or can it be used directly by the patient or a layman?” If the product can
be used by the patient or layman, what level of education is expected? If the
product requires the intervention of a professional (e.g., nurse, technician, doctor,
paramedic, physician’s assistant, etc.), what level of professional competence is
needed? If use of the device is indicated as “prescription-use only” (e.g., a physi-
cian), does it require that the physician have specialized training in order to be
able to use the device? Some devices require that the end user be a registered
nurse or perhaps a trained medical technician. The answer to this question will
determine the level of instruction, if any, that is needed and/or what needs to be
covered and to what detail in the instructions for use for the product.
40
Patient population: Inclusion/exclusion criteria

This is another characteristic that is usually relatively easy for a design team to
define. Most medical devices are designed to treat or manage a specific indication
and that simultaneously defines the patient population. But it is its simplicity that
can allow the input to be misleading. For example, let’s say that we are develop-
ing a device for the management of urinary incontinence. Is the patient popula-
tion then all those people who suffer from any form of urinary incontinence?
The answer is “probably not.” First of all is the device for males or females? If
we continue our example by saying it’s a female urinary incontinence device,
then we have just cut the overall patient population by more than half. If it’s an
external female urinary device, it has probably cut the remaining 50 percent of
the original total population in half again. Is the device appropriate for females
with stress incontinence? The answer may lead to an even smaller fraction of the
total population.
The other part of defining the patient population characteristic is defining the
contraindications. Is there a group of patients on whom the device should not be
used, for example, children or older people? Is there a component or an ingredient
that may cause an allergic reaction in some people, for example, latex? Are there
situations or conditions or even other devices that could interfere with the proper
and safe function of the new device, for example, MRI compatibility? Does the
new device interfere with other situations in the surrounding environment? The
answers to these and similar questions will help define the contraindications and
therefore the ultimate patient population.
User interface/ergonomic considerations

It’s important to understand the expectations, abilities, and limitations of the
intended users with regard to the device and its use environment. This is often
referred to as “human factors engineering,” “usability engineering,” or “ergonom-
ics.” The design team’s goal should be to design a device that will be relatively
easy and safe to use. The requirement to consider human factors in the design
and development process is implied in the FDA’s Quality System Regulation in
paragraphs 820.30(c), (f), and (g).
For any device, the abilities and limitations of the user population might be rela-
tively uniform; however, the user population might contain subcomponents that
have significantly different abilities. Examples are young and old users or home
users versus professional health care providers. Fatigue, stress, medication, or
other mental or physical conditions can also affect ability levels of device users.
As a result, the design team will need to consider the user and the user interface,
the complexity of the device and its use, and the use environment.
41
Important characteristics to consider with regard to user populations might

include the following:
• General health and mental state
• Physical size and strength
• Sensory capabilities (hearing, vision, touch)
• Coordination (manual dexterity)
• Cognitive ability and memory
• Previous experience with devices, training, or expectations
User interface includes all components and accessories necessary to operate and
properly maintain the device, including the controls, displays, software, logic of
operation, labels, and instructions. Design features that can contribute to user
error include controls and indicators, symbols, ergonomic features, physical
design and layout, visibility of warnings, audibility of alarm signals, standardiza-
tion of color coding, and so on.
This characteristic should take into consideration what the product is envisioned
to do and what clinical use testing needs to be done to verify those expectations.
Clinical evaluations are not required for all medical devices, but knowing the
result of what will or could happen as the result of the use of your product is. It
seems unbelievable that any company would develop a medical device without
performing any type of clinical evaluation. Even for straightforward products a
clinical use test is important. How else do you know that your product will work
under the conditions it will see in use? A review of competitive product literature,
clinical studies, adverse event reports, recalls, and so on will help to identify both
potential and real device use and misuse errors, as well as aid in identification of
solutions that might be implemented during the design and development process
to eliminate or reduce such errors.
Some questions to consider when addressing this characteristic might include
the following:
• How is the user to interact with the device user interface?
• Are there any physical characteristics associated with the user interface?
What might be the physical constraints (e.g., size, shape, weight, etc.)?
• What tasks are users expected to perform?
• Will use of the device require one or two hands?
• Will the environment impact the user interface (e.g., noise, vibration,
motion, light, etc.)? For example, the user might not be able to notice
alarms if they are not sufficiently loud or distinctive when used in noisy
environments. Similarly, motion and vibration can affect the degree to
which people are able to perform fine physical manipulations such as
typing on the keyboard portion of a medical device. If lighting or print
size of labeling or visual displays are not sufficient, users may not be able
42
to accurately read the device labeling, or the display scale or device status
indicators might not be clear to the user. What if the user is color-blind?
• How is the device powered and/or to what other devices might the device
be connected? Is it possible for the device to be connected incorrectly?
We will discuss human factors and risk assessment in more detail in Chapter 10.
Product characteristics
According to Wikipedia, “product characteristics are attributes or properties that
describe the product’s ability to satisfy its purpose in a larger system. As such,
product characteristics describe what your product ought to be, not what it ought
to do. Every product characteristic will have an impact on every basic property
of a product. The basic properties of a product are: size, shape, mass and inertia,
material and surface finish (including color).”
The PPS needs to clearly define a device’s product characteristics, that is, what
it needs to be. It is from these inputs that outputs will be generated and subse-
quently verified and/or validated to ensure that the device meets these require-
ments. Product characteristics may include the following:
• Physical characteristics
• Chemical characteristics
• Biological characteristics
• Environmental characteristics
• Sterilization characteristics
• Packaging and labeling requirements
• Equipment interface requirements
• Safety and reliability requirements
Let’s take a look at each of these types of product characteristics.
Physical or functional characteristics

The physical characteristics of the product such as its dimensions (length × width
× height), weight, shape, and even color should be clearly and accurately defined.
There should be nothing about the physical characteristics of the device that isn’t
clearly stated in the PPS. This includes not only the dimensions for the device but
also the limits and acceptable tolerances, measuring accuracy, and precision. If
you believe that these dimensions and tolerances are an issue only for engineering
and manufacturing, think again. Ask someone with a colostomy if a pouch that
is dimensioned awkwardly to the point where it is obtrusive is a good product.
43
Don’t forget that here is where you define the different sizes or shapes that the
product may need to be available in or where you will indicate if the product is
intended to be portable and if there are any associated weight or size require-
ments or constraints. You also need to consider how energy is to be delivered
to the device: manually (e.g., manual resuscitator), batteries (e.g., laryngoscope
handle), or via hookup to an electrical outlet (e.g., ultrasound machine). Does the
device have physical characteristics that vary with time, for example, appearance,
viscosity, elasticity, tensile strength, burst strength, or electrical resistance? If so,
this may affect the device’s shelf life.
Remember to identify and/or distinguish between what the essential requirements
are for the device and the “want to have or nice to have” features. The bells and
whistles may be nice, but the basics are a necessity.
Chemical characteristics
Material and component selection is very important when developing your medi-
cal device. When selecting your materials and components, you need to consider
the possibility of chemical degradation (i.e., do any materials or components
of the device degrade over time in a manner that could adversely affect the
device’s safety or performance), chemical interactions (i.e., do materials or com-
ponents interact to alter the device and/or cause degradation or the ability of the
device to perform the intended function), and biological safety issues. Often man-
ufacturers believe they are using a “common” material in their medical devices
(i.e., the same material as their competitor); however, when pressed for evidence
of the material’s safety, manufacturers come up blank. You need to show that the
material is comparable after your manufacturing process. Furthermore, you can-
not assume that because materials meet USP Class V or VI requirements that they
are sufficiently safe for your device application.
Chemical characterization is an accepted method for comparing one finished
manufactured material to another in order to make the argument that they are
clinically equivalent or that one material is no worse than a currently used mate-
rial. ISO 10993-18 (chemical characterization of materials) provides a framework
for the identification of materials and the identification and quantification of their
chemical constituents. This process will help to justify the performance or omis-
sion of animal biocompatibility tests, measure the level of a leachable substance
in a medical device, judge the equivalence of a proposed material to a clinically
established material, or help screen potential new materials for suitability of your
medical device for your proposed clinical application.
The PPS should identify all of the materials and components that make up your
finished device (i.e., chemical formulation) and consider any potential associated
hazards (e.g., flammability, toxicity, etc.).
44
Many of today’s medical devices are composed of polymers or blends of poly-

mers, so it is important to know the types and amounts of any additives that
these polymers contain. Plastics often contain plasticizers, stabilizers, and fillers
that are used to make the materials more flexible, transparent, durable, and long
lasting. Phthalates or phthalate esters are esters of phthalic acid and are mainly
used as plasticizers. Anyone who is involved in the manufacture of vinyl blood
bags or medical tubing knows that PVC is a popular choice of material because
it is strong and flexible, can be easily sterilized, and resists kinking. Although
there seems to be a lot of controversy regarding the use of phthalates in medical
devices, according to the American Chemistry Council, while some studies have
suggested a link between phthalates and various human health effects, none have
demonstrated an actual causal link (that phthalates are the cause of the effect). In
addition, in an opinion presented by the EU Scientific Committee for Health and
Environmental Risks in October 2008, the EU Scientific Committee for Health
and Environmental Risks stated that at the DEHP doses observed in humans,
DEHP exposure did not represent a relevant cancer risk to humans.
You also need to take into consideration the chemical interactions of your mate-
rials in the preparation for use of the device and, more important, during use.
For example:
• It would not be wise to manufacture surgical gloves intended for use in an
operating room setting from a polymeric material that dissolves in alcohol
or other solvents.
• If the proper functioning of a device requires a material that is not
included with the device, for example, “wall oxygen,” then the inter-
action of this material or drug with the device should be considered
and identified in the PPS.
• Some of the parts that make up an orthopedic implant must touch
each other or rub together, especially in the case of an artificial joint.
Therefore, the choice of the two materials that rub together is important
in minimizing wear or degradation. When an implant wears, tiny par-
ticles of the material are removed from the surface and remain in the
tissues that surround the implant. In some patients, these particles may
cause a reaction that could lead to inflammation. If the inflammation is
severe, or continues for too long, the implant may become loose.
• Some of the normal chemicals that make up the fluids in your body can
damage certain materials. With an implant, corrosion occurs as these
chemicals react with the implant material, creating particles similar to
small wear particles. Not only can corrosion weaken the implant, but
also the particles produced can remain in the tissues that surround the
implant. This could eventually lead to implant failure or, in severe cases,
damage to the bone.
45
As you can see, there is a lot to consider when choosing the materials and com-
ponents for your medical device, and your choices will influence the biological
testing required for your device.
Biological characteristics
When you think about biological characteristics, the term biocompatibility should
come to mind, but what does biocompatibility mean? Simply put, biocompatibil-
ity means the effect on life and refers to the way materials interact with your body.
Biocompatibility in general is a term that is used to describe the suitability of a
material for exposure to the body or bodily fluids. A material will be considered
biocompatible (in a specific application) if it allows the body to function without
any complications such as allergic reactions or other adverse side effects. If a
material is used that is not biocompatible, there may be complications such as
the following:
• Extended chronic inflammation at the contact point or where leachates
interact with the body
• Generation of materials that are toxic to cells (cytotoxicity)
• Cell disruption
• Skin irritation
• Restenosis (narrowing of blood vessels after treatment)
• Thrombosis (formation of blood clots)
• Corrosion of an implant (if used)
Some materials, lead and mercury, for example, are naturally harmful when taken
into the body so are not suitable for implanting. Other materials are not suitable
to implant because the body fluids cause them to break down, either weakening
them or causing corrosion or other by-products. Some materials may cause sensi-
tization or irritation or may cause an allergic reaction.
A biological evaluation should be performed to determine the potential toxicity
resulting from contact of the component materials of the device with the body.
The device materials should not, either directly or through the release of their
material constituents,
• produce adverse local or systemic effects,
• be carcinogenic, or
• produce adverse reproductive and developmental effects.
Evaluation of any new device intended for human use will require data from
systematic testing to ensure that the benefits provided by the final product will
exceed any potential risks produced by the device materials. Therefore, the selec-
tion and evaluation of materials and devices intended for use in humans requires
a method of assessment to establish biocompatibility and safety.
46
Biological characteristics need to consider the intended clinical use of the device,
the duration of contact (i.e., how long the device is to be used), and the intended
contact (i.e., the tissues and body fluids the device and its components may come
into contact with during normal use). The answers to these questions will be
essential to determining the nature of the toxicity and biocompatibility testing
required for the finished device and its components.
Current regulations, whether FDA or ISO, require safety testing of devices
through preclinical and clinical phases as part of the regulatory clearance pro-
cess. The number and types of specific safety tests required to assess product
safety and compliance will be dependent on the individual characteristics of the
finished device, its component materials, and its intended clinical use. There are
some significant differences between the FDA’s Blue Book Memorandum G95-1
and the ISO 10993 Part 1 selection of tests; however, they are very similar. The
FDA’s Blue Book Memorandum G95-1 includes an FDA-modified ISO 10993-1
biological evaluation test matrix that designates the type of testing needed for
various medical devices. Whether you choose to use the FDA’s modified matrix
or the ISO 10993-1 matrix, know that both provide only a framework for the
selection of tests and not a checklist of every required test. Again, the particular
tests required will vary depending on the medial device, its intended use, the
duration and frequency of use, and the degree of invasiveness. As a result, this
information needs to be clearly documented in the PPS.
Duration of use Both the FDA’s Memorandum G95-1 (i.e., modified matrix)
and ISO 10993-1 matrix categorize duration of contact/use as follows:
• Limited or transient use: devices whose single or multiple use or contact
is likely to be up to 24 hours
• Prolonged or short-term use: devices whose single, multiple, or long-
term use or contact is likely to exceed 24 hours but is less than 30 days
• Permanent or long-term use: devices whose single, multiple, or long-
term use or contact exceeds 30 days
Of particular note is the Medical Device Directive’s definition of duration of use.
If you use a device, say, a wound dressing, for twenty-four hours and then change
it out with a new dressing and do this for three months, this is considered con-
tinuous use and would be classified as long-term or permanent use rather than
prolonged or short-term use.
Degree of invasiveness Devices may be applied to the surface of the body, be

inserted into an orifice or through the skin, or find their way into tissues, spaces,
or organs of the bodies of humans by ingestion, inhalation, skin absorption, or
implantation. Devices may contact blood, mucosal tissues, muscle or other con-
nective tissue, bone, teeth, and other tissues. When talking about the degree of
47
invasiveness, you are talking about the nature in which the device contacts the
body of the patient. If you refer to the FDA’s Memorandum G95-1 (i.e., modi-
fied matrix) or ISO 10993-1 matrix, you’ll see the categories are broken down as
indicated in Table 6.1.
Selection of tests Tests to be used in biological evaluation, and the interpreta-

tion of the results of such tests, should take into account the chemical composition
of the materials, including the conditions of exposure and the nature, degree,
Table 6.1 Degree of Invasiveness

Device Category Examples of Devices
Noncontact device: devices that do not Medical device software, ventilators, medical gases,
contact the patient’s body directly or in vitro diagnostic devices
indirectly
Surface-Contacting Devices
Skin: devices that contact intact skin Electrodes, external prostheses, fixation tapes,
surfaces only compression bandages, and monitors of various types
Mucosal membranes: devices that Contact lenses, urinary catheters, intravaginal and
contact intact mucosal membranes intraintestinal devices (stomach tubes, sigmoidoscopes,
colonoscopes, gastroscopes), endotracheal tubes,
bronchoscopes, dental prostheses, orthodontic devices,
and intrauterine devices
Breached or compromised surfaces: Dressings, healing devices, and occlusive patches for
devices that contact breached or ulcers, burns, and granulation tissue
otherwise compromised body surfaces
External Communicating Devices

Blood path, indirect: devices that Solution administration sets, extension sets, transfer sets,
contact the blood path at one point and blood administration sets
and serve as a conduit for fluid entry
into the vascular systems
Tissue/bone/dentin: devices that contact Laparoscopes, arthroscopes, draining systems, dental
tissue, bone, or pulp/dentin systems cements, dental filling materials, and skin staples
Circulating blood: devices that contact Intravascular catheters, temporary pacemaker electrodes,
recirculating blood oxygenators, extracorporeal oxygenator tubing and
accessories, dialyzers, and dialysis tubing and
accessories
Implant Devices
Tissue/bone: devices principally Orthopedic pins, plates, replacement joints, bone
contacting bone prostheses, and bone cements
Blood: devices principally contacting Pacemaker electrodes, artificial arteriovenous fistulae,
blood heart valves, vascular grafts, internal drug-delivery
catheters, and ventricular assist pumps
48
frequency, and duration of exposure of the device or its constituents to the body.
Once you have determined these factors, you can use the FDA’s modified matrix
and/or ISO 10993-1 matrix to identify the testing that is recommended for your
medical device. Remember, a good first step in determining what biocompat-
ibility testing is required should include a chemical characterization of the device
materials and a comparison of these materials to materials in existing clinical
use. This chemical characterization may justify the performance or omission of
some of these tests. Most medical devices will require cytotoxicity, sensitization,
and/or irritation testing unless a risk analysis or existing data show otherwise.
In addition, the FDA’s Program Memorandum G95-1, Attachment C provides a
flowchart for use in selecting the required toxicity tests that would be required for
a 510(k) submission.
Environmental characteristics
Environmental characteristics include those environmental factors that may have
an adverse impact on the device or its components during transport, storage, or
use. It includes those environmental conditions that may affect the device itself,
the user of the device (e.g., physician, nurse, technician, etc.), or the patient in the
intended use environment.
The PPS needs to document any anticipated factors associated with transport,
storage, and use. Environmental factors to examine depend on your device, its
intended use, and the use environment and may include temperature, humidity,
atmospheric gas composition and pressure, energy, electromagnetic interference,
electrostatic discharge, radiation emissions, noise, vibration, motion, lighting,
shock, moisture, and so on.
Transport and storage Medical devices are typically transported by truck, air,
boat, or train. This means that packages and their contents will be subjected to
the following:
• Vibration and shock
• Temperature fluctuations and humidity changes
• Variation in atmospheric pressure
As a result, it is important to understand the impact the conditions of transport
and storage may have on your device and components so that the right materials
are chosen and/or actions may be taken to eliminate or reduce these effects.
Material properties may break down under certain environmental conditions; for
example, materials may soften or even melt if subjected to high temperatures or
become brittle and break if subjected to extreme low temperatures. Humidity
under most normal conditions of 0–70 percent relative humidity would likely
have no impact on a light-curable adhesive; however, anyone who lives in Florida
49
knows that humidity in the summer can reach as high as 95 percent or more. A
device or material that is subject to high temperatures and 70 percent relative
humidity or higher for an extended period of time may experience problems with
curing time, chemical properties, and/or adhesion properties.
Years ago I worked with a company in Florida that manufactured an external
continence device. Part of the manufacturing process required that an adhesive be
used to bond two component parts together. In the summer it always took twice
as long for the parts to cure, and there were often adhesion problems reported,
for example, product duration of use was shortened. Instead of the device being
able to be worn for three to five days, the components would begin to come apart
after two or three days. As this was an external continence device, product failure
could prove quite embarrassing.
Temperature and humidity can also compromise the integrity of sterile packag-
ing and affect device shelf life. Annex I of the Medical Device Directive requires
that medical devices be designed and manufactured so that sterility will be main-
tained during storage or transport, providing that manufacturer’s stated storage
and handling instructions are followed. As a result, to ensure your device can
withstand the anticipated environmental factors, it is likely that you will need
to conduct accelerated aging studies and various environmental challenge tests
to establish and justify any expiry dates given on the package label. Any known
restrictions or constraints on storage and handling should be stated in the instruc-
tions for use or on the device labeling.
Problems attributed to the improper storage of medical devices are not new
phenomena. Back in 1999, the Medicines and Healthcare Products Regulatory
Agency (MHRA) issued a safety notice regarding the storage of sterile medical
devices. It indicated that medical devices manufactured using plastics, polymer
materials, and latex compositions and their packaging materials may become
embrittled, perished, stained, or malodorous due to the following:
• Excessive cold or heat
• Dust or other particulate contamination
• Excessive humidity or other wet conditions
• Direct sunlight or other strong light source (e.g., UV light)
• Prolonged storage
Use environment The use environment should also be carefully considered.

Use environments for medical devices can vary widely and can have major
impacts on device use and use-related hazards. Devices that can be used safely
under conditions of low stress could be difficult or dangerous to use under
conditions of high stress. Use environments can also limit the effectiveness of
visual and auditory displays if they are not designed appropriately. For devices
50
used in noisy environments, the user might not be able to notice alarms if they
are not sufficiently loud or distinctive. Similarly, motion and vibration can
affect the degree to which people are able to perform fine physical manipu-
lations such as typing on the keyboard portion of a medical device. Motion
and vibration can also affect the ability of users to read displayed informa-
tion. Important considerations for displays and device labeling should include
ambient light levels, viewing angles, and the presence of other devices in the
use environment. If the device will be used in low light conditions, display
scales or device status indicators might not be clear to the user. Other dis-
play information can be lost under brightly lit conditions because of insuf-
ficient contrast.
If a device is expected to be used in a room with an MRI machine (e.g., wheel-
chair, pressure gauge) or to be implanted into a patient who may be subject to an
MRI scan (e.g., intracranial aneurysm clip, bone screw), then you need to make
sure that all of the device materials are MRI compatible, and that appropriate test-
ing is performed to verify compatibility.
As you can see, there is a lot to consider during the design input stage, and this
process can take up to 30 percent of the total design and development time.
Sterilization characteristics
Many medical devices are provided sterile or require sterilization prior to use or
reuse. As a result, the PPS needs to identify the sterilant or sterilization method
and any associated parameters. For example, if sterilization is to be performed
using radiation, then the radiation dose needs to be indicated; if sterilization is to
be performed using ethylene oxide, then the maximum levels of EO residuals that
may remain on the device need to be indicated; if sterilization is to be performed
using moist heat (e.g., autoclave), then the configuration (e.g., gravity displace-
ment or prevacuum), temperature, and time need to be indicated. The sterility
assurance level (SAL) should also be indicated. An SAL of 10 –6 is expected for
most devices, unless the device is intended only for contact with intact skin. The
FDA recommends an SAL of 10 –3 for devices that only come into contact with
intact skin.
Methods of sterilization The sterilization method you select needs to be appro-

priate for your device and the materials of which it is constructed, as materi-
als may be adversely affected by the sterilant or sterilization process used. For
example, several polymers, both synthetic and natural, may degrade after being
exposed to ionizing radiation. It would be impractical and perhaps even danger-
ous to use an ethylene oxide sterilization process on a material or a device that is
a gas barrier, as removal of the ethylene oxide gas would be a significant problem.
51
Traditional sterilization methods include the following:

• High temperature/pressure: steam autoclave, dry autoclave
• Chemical: ethylene oxide gas, STERRAD®, STERIS®
• Radiation: gamma, X-ray, electron beam
Other nontraditional methods include ozone, chlorine dioxide, microwave radia-
tion, and ultraviolet light. Accordingly, there are various sterilization methods
and standards that exist. The most common or familiar are the following:
• ANSI/AAMI/ISO 11134 or EN 554 for moist heat
• ANSI/AAMI/ISO 11135 or EN 550 for ethylene oxide
• ANSI/AAMI/ISO 11137 or EN 552 for radiation
Aseptic processing If your device is intended to be sterile but cannot be termi-
nally sterilized (i.e., the device or materials cannot tolerate those methods), asep-
tic processing would be the chosen method of manufacture. Aseptic processing
requires that either the entire product is sterilized and then introduced into a ster-
ilized package or components of the product are sterilized, then further processed
and assembled, and the final product is packed into a sterilized package. Aseptic
processing requires the handling and filling of sterile containers and devices, or
their components, be performed in a controlled environment in which the air
supply, materials, equipment, and personnel are regulated to control microbial
and particulate contamination at acceptable levels. Subsequent sterility testing
would be expected to verify the product is sterile. Reference ANSI/AAMI/ISO
13408 or EN 556 for aseptic processing.
Reusable medical devices Reusable medical devices need to be designed to

function safely and effectively following sterilization in a health care setting. By
definition, they must be designed to withstand multiple exposures to sterilants
or disinfectants. The number of exposures to which the device can be subjected
without losing the ability to function effectively will help determine its useful
life. Therefore, if your device is to be reused, you want to make sure that the ster-
ilization method you choose not only is adequate to ensure sterility but will also
ensure proper functionality of the device, physical integrity, and biocompatibility
after reprocessing. Hence, you will need to identify the resterilization conditions
and the number of cycles the device or material can withstand in your instructions
for use. This will of course need to be supported with validation data to support
the sterilization process.
Many medical devices today are reprocessed. Reprocessing involves several steps
including cleaning, testing for device performance, and disinfection and/or ster-
ilization. Cleaning the device is a critical first step after a device has been used
on a patient. Failure to remove foreign material from both the outside and the
inside of the device can interfere with the effectiveness of subsequent disinfection
and/or sterilization.
52
Manufacturers of reusable medical devices are responsible for supporting any

claims for product reuse and must provide instructions on how to reprocess their
devices between patient uses. As a result, if your device can be reprocessed, then
you need to document in the instructions for use a validated method for cleaning
and disinfection or sterilization. Again, the method of cleaning and disinfection
or sterilization will depend on your device’s intended use. Consideration must be
given to the effect the exposure to chemicals, such as cleaning agents and ster-
ilants, and cleaning, disinfection, and sterilization processes could have on the
device, for example, functionality, leaching, crazing, accelerated wear, degrada-
tion, chemical reaction of materials, and so on, thereby affecting the safety of the
device and its effectiveness. The methods developed should take into account
the type of contamination expected for the device, the device design features,
and the potential for patient exposure to pathogens: high risk (critical devices),
medium risk (semicritical devices), or low risk (noncritical devices).
Packaging characteristics
A description of the specific packaging materials and the packaging configuration
needs to be defined from several points of view. First, the packaging needs to pro-
tect the device from the environment during transport and storage, and protect the
product’s sterility as appropriate. Second, the packaging should be clearly defined
in terms of its ease of use for the end user or patient.
A device intended for use in a sterile operating room will find few happy users
if the device is difficult to remove from its package when the user is wearing
surgical gloves. If the device’s intended user is physically handicapped, then it is
important that the package can be easily opened without necessarily requiring the
assistance of another person.
There are a number of questions you might want to ask when it comes to device
packaging requirements. The answers to these questions will of course trigger the
identification of outputs for verification and/or validation. For example:
• Is your device sterile? If so, you need to make sure that your packag-
ing materials are compatible with the method of sterilization chosen or
recommended in the instructions for use. Is it likely that there would be
an interaction between the device and its packaging that would have an
undesirable affect?
• How will the device need to be packaged to ensure protection from dam-
age and deterioration during shipping? Will transit trials be necessary?
• Does the device have a shelf life? If so, you need to make sure that the
packaging will appropriately maintain the device and ensure its func-
tionality for that stated period of time; you will likely need to conduct
accelerated aging studies and perform functionality testing.
53
A device’s shelf life should not be confused with its “useful life.” The FDA defines
the useful life of a device as the duration of actual use or the number and duration
of repeat uses before some change results in the device’s inability to achieve its
intended function. Shelf life is defined as the term or period during which a device
remains suitable for its intended use. An expiration date is the termination of
shelf life, after which the device may no longer function as intended.
To determine if a particular device requires a shelf life and the assignment of an expi-
ration date, you must consider a number of different parameters. The device must
be analyzed to determine if it is susceptible to degradation that would lead to func-
tional failure and the level of risk that the failure would present. For some devices,
for example, tongue depressors, it is not reasonable to assign a shelf life because of
the small likelihood of time-dependent product degradation and the lack of serious
consequences if it did fail to perform as designed. For certain devices susceptible to
degradation that are intended to treat life-threatening conditions, for example, pace-
makers, the failure rate should approach zero within the labeled shelf life.
Equipment interface characteristics

Manufacturers are encouraged to improve the safety of medical devices and
equipment by reducing the likelihood of user error. We already examined the
characteristics associated with user interface in the preceding section. Now it’s
time to look at the characteristics associated with the equipment that may inter-
face with your device. This section of the PPS should include a description of
any ancillary or adjunct equipment or devices necessary for the proper use of the
device being developed, including mating parts (e.g., power source, connections,
any compatibility requirements, standardized units, etc.). This is especially true
if they are not packaged with the device.
In an emergency, oftentimes emergency personnel need to intubate a patient expe-
riencing respiratory distress. There may be a couple of laryngoscope blades and
handles available on the crash cart or in the EMT vehicle. Accordingly, it will
be critical that the handle selected is compatible with the blade selected in order
for the laryngoscope to function as intended. Keeping this in mind, if you are
designing laryngoscope blades and/or handles, then you need to ensure the inter-
changeability of the connection between the blade and the handle. For example,
a conventional laryngoscope blade should be designed to engage with any other
conventional laryngoscope handle hook-on fitting but should not be able to be
engaged with a fiber-optic laryngoscope handle. As such, it shouldn’t matter if
the EMT uses your handle with a competitor’s blade if they have been designed
correctly. They should be compatible.
You will also need to consider the type of energy, if any, that your device will
need to function; for example, is energy to be delivered to the device (batteries,
electricity, gas), or is energy delivered via the functional aspect of the device
54
(laser, ultrasound, radio frequency)? Will your device be used with a medical gas?
If so, a gas-specific noninterchangeable connection is recommended. Is a safety
or shutoff valve required to prevent accidental over- or underflow (e.g., pressure)?
Some medical devices require routine maintenance or calibration (e.g., ultrasound
equipment). If this applies to your device, it will need to be accompanied by
instructions for maintenance and repair in order to maintain the safety level of the
medical device. This is specifically called out by the European Medical Device
Directive in Annex I. The maintenance and repair instructions should include the
nature and frequency of maintenance, safety checks, calibration requirements,
and internal and external quality control.
Among the most common errors reported to the FDA with regard to equipment
interface problems are improper installations of device accessories. Some com-
monly reported errors are as follows:
• Tubing connected to the wrong port
• Loose connections
• Accidental disconnections
• Electrical leads inserted into an improper power source
• Batteries or bulbs inserted incorrectly
• Valves or other hardware installed backward or upside down
This problem is made worse by the fact that many manufacturers sell a wide range
of accessories for a given type of device. Accessories for different models are
often similar in appearance and/or difficult to install, leading to misconnections
and disconnections. Such accidents can often be prevented through design solu-
tions. To do this will require that you look at device components and accessories
as part of a system and not as isolated elements.
The FDA’s guidance document Do It by Design recommends seven “Rules of
Thumb” for reducing the likelihood of confusion between similar components
and accessories and making improper connections. These rules are as follows:
1. Cables, tubing, connectors, luers, and other hardware should be designed
for easy installation and connection. If these products are properly
designed, incorrect installations should be impossible, extremely diffi-
cult, or so obvious that they can be easily detected and remedied.
2. User instructions should be understandable, and warnings should be
conspicuous.
3. If a hazard cannot be eliminated by a design solution, color codes or
other markings will help the user achieve proper connections and com-
ponent or accessory installation.
4. Positive locking mechanisms are desirable whenever the integrity of
connections may be compromised by such factors as component dura-
bility, motion, or casual contact.
55
5. Protected electrical contacts (e.g., the conductors are recessed) are

necessary for body leads that can be inadvertently introduced into
outlets, power cords, extension cords, or other common connectors. If
possible, exposed contacts should be avoided.
6. Components and accessories should be numbered so that defective ones
can be replaced with the proper items.
7. Textual complexity in maintenance manuals should be reduced by add-
ing graphics.
Although luer connector misconnections are a well-known and well-documented
issue, and each misconnection event carries the potential for a lethal outcome,
they continue to occur because luer connectors
• easily link many medical components, accessories, and delivery systems
• are widely available
• are easy to use
• are inexpensive
Examples of events reported to the FDA regarding the consequence of miscon-
nection include the following:
• A child’s oxygen tubing became disconnected from his nebulizer and
was accidentally reattached to his IV tubing. Although the connection
was broken in seconds, it wasn’t in time to prevent an air embolism that
caused the child’s death.
• A patient’s blood pressure tubing was inadvertently connected to the
patient’s IV catheter and delivered 15 ml of air. This patient also died as
a result of an air embolism.
• An infant’s feeding tube was inadvertently placed in the tracheal tube,
and milk was delivered into the infant’s lungs, causing death.
• An epidural set was mistakenly connected to a patient’s IV tubing thereby
delivering epidural medicine to the IV, which resulted in the patient’s death.
• IV tubing was mistakenly connected to a child’s tracheal cuff port caus-
ing the IV fluid to fill the tracheal cuff to the point of breaking and
allowing IV fluids to enter the child’s lung. The child died.
• A patient having a central line with three ports and a tracheal tube had
medicine intended for the central line inadvertently injected into the tra-
cheal cuff. The tracheal cuff was damaged, and the medicine entered the
patient’s lungs. However, a new tracheal tube was quickly inserted, and
the patient survived.
There are a number of standards that are available, depending on your device,
that provide basic requirements and/or dimensional requirements that should be
considered when designing your device for compatibility with equipment, other
devices, and mating parts. A few examples are as follows:
56
• ISO 5366: basic requirements for tracheostomy tubes made of plastics

materials and/or rubber that are primarily designed for patients who
require anesthesia, artificial ventilation, or other respiratory support
• ISO 5356: dimensional and gauging requirements for cones and sockets
intended for connecting anesthetic and respiratory equipment, for example,
in breathing systems, anesthetic-gas scavenging systems, and vaporizers
• ISO 5364: dimensional requirements for oropharyngeal airways com-
posed of plastics materials and/or rubber
• EN 60601-1: basic safety and essential performance requirements for
devices or components that qualify as medical electrical equipment
• ISO 7376: general requirements and critical dimensions for the handle
and lamp of hook-on-type laryngoscopes
Safety and reliability characteristics

This section of the PPS should specifically describe any conditions that will affect
the safe and reliable use of the product. This may include electrostatic discharge
hazards, specific voltage and grounding requirements, or protective clothing and
equipment that would be recommended for use when the device is being applied,
used, removed, or disposed of. In addition to requirements that are related directly
to the device itself, it is important to include other actions of people using the
device that may affect their safety. For example, any device that uses oxygen dur-
ing its operations should take into account the standard safe use of the gas.
We all know that our customers want a quality product, and customers associate
quality with reliability. Customers expect the devices they purchase to remain
functional and safe for their expected useful life. A key requirement or input
then is to design a reliable device that meets the requirements of the customer.
By definition, reliability is the probability that a component part, equipment, or
system will perform a required function without failure under stated conditions,
such as environmental conditions, limitations as to operating time, and frequency
and thoroughness of maintenance for a specified period of time. I think we can
all agree that if your device is unreliable, it will not be considered to be a quality
device, and your customers will likely look elsewhere.
With that being said, you should likely quantify reliability; that is, how long is
your device expected to function without malfunctioning? Conducting failure
mode and effects analysis (FMEA) will help to identify potential failure modes
so that design solutions can be adopted to remove these failures. Field failure data
from service, repair, and/or recalls from similar devices are invaluable to learn-
ing how components and devices behave in the field. Testing will then need to be
conducted to verify that the solutions adopted will confirm your device meets the
specified level of reliability. Accelerated life testing is often used to do this and
may involve the following:
57
• Increasing the use rate or cycling rate of the device

• Increasing the aging rate of the device (e.g., temperature, humidity)
• Increasing the level of stress under which test units operate (e.g., voltage
or pressure)
Marketing requirements
The purpose of this section of the PPS is to clearly define the marketing require-
ments applicable to your device based on where you want to market the device,
contractual requirements, regulatory or statutory labeling requirements, and the
claims you want to make for your device.
Intended marketplace
At this stage of the game, marketing staff should have a pretty clear idea of where
they want to sell the device in terms of geography. You would expect their fore-
cast to be based on market research and detail not only where they would like to
sell but also the anticipated market share or volume. Do not accept an answer of
“everywhere” or “internationally.” We would all like to sell our medical devices
globally, but it’s just not that simple. Generally speaking, each country has its own
governing regulatory body and regulatory requirements that must be met prior
to a medical device being allowed for sale in that country, and these regulations
are changing regularly. Sometimes a staggered approach is advantageous, as it
can take a significant amount of time to gather the required information for each
country and then receive approval.
Contractual requirements
Contractual requirements also need consideration, as these requirements will
likely result in additional steps or changes to the project plan. These may include
requirements or inputs related to special packaging, storage, handling, and deliv-
ery. These may also include quality management system agreements (e.g., ISO
13485) or even supply and pricing agreements with distributors and contract
manufacturers. For example, many distributors in Europe do not want to stock
a device that has less than an 18-month shelf life remaining on the device. As a
result, if your plan is to release your device to the market with accelerated aging
testing that justifies only a one-year shelf life, you will not meet this requirement.
Customers (e.g., doctors) may want the device packaged as a convenience kit,
in which case you will need to ensure that all components of the kit are appro-
priately controlled and regulated. Devices that are privately labeled will either
require you to generate the labeling and have it reviewed and approved by the
customer or the customer to provide the labeling for you.
58
Claims
This section of the PPS should include the specific claims that will be made about
the device; that is, what is your device indicated for and intended to do? Per 21
CFR 801.61 (Code of Federal Regulations), the principal display panel of an over-
the-counter medical device in package form is required to include a statement
of the device’s identity and a statement of the principal intended actions of the
device. In addition, the indications for use are to be included in the directions for
use of the device. If you market your device in the United States, any claims you
make regarding intended use are typically dictated by the FDA and the regulation
number the device falls under. Any claim over and above what is stated by the
regulation number will require subsequent approval (e.g., new 510(k) or PMA).
For example, per the FDA’s product classification database, the devices listed
below have the following intended uses:
1.
Sec. 868.5800, tracheostomy tube and tube cuff: A tracheostomy tube
and tube cuff is a device intended to be placed into a surgical opening of
the trachea to facilitate ventilation to the lungs.
2.
Sec. 892.2050, picture archiving and communications system: A pic-
ture archiving and communications system is a device that provides one
or more capabilities relating to the acceptance, transfer, display, storage,
and digital processing of medical images.
3.
Sec. 878.5650, topical oxygen chamber for extremities: A topical oxy-
gen chamber for extremities is a device that is intended to surround
a patient’s limb and apply humidified oxygen topically at a pressure
slightly greater than atmospheric pressure to aid healing of chronic skin
ulcers such as bedsores.
4.
Sec. 880.5210, intravascular catheter securement device: An intravas-
cular catheter securement device is a device with an adhesive backing
that is placed over a needle or catheter and is used to keep the hub of the
needle or the catheter flat and securely anchored to the skin.
In this section you will need to identify what performance claims you intend to
make for your device and whether or not you will be claiming compliance with
any performance standards.
You will likely want to consider the claims your competitors are making so that
you can make the same claims. You should specify all claims that are intended
to appear on the product label and instructions for use; in advertisement slicks,
posters, videos, tradeshow booth signage, and catalogs; and on your website.
Remember, however, that any claims you make need to be supported with data.
The wording of the claims should be done carefully and accurately represent any
scientific and clinical findings that are known and verifiable about the device and
its use for a specific indication.
59
A Product Claims Sheet is a useful document for documenting a device’s indica-

tions for use and claims in an effort to add consistency and predictability to the
generation of device labeling. Each claim that you want to make for the device
is listed and then the associated support data are indicated to support the claim
(e.g., testing). The claims that can then be made for the device will be controlled
by what has been substantiated on the Product Claims Sheet. An example of a
completed Product Claims Sheet for tracheostomy tubes is indicated in Figure 6.1.
Note the associated test/report numbers should be indicated.
The initiation and maintenance of a Product Claims Sheet is highly recommended
and should be completed and referenced by this section of the PPS. The Product
Claims Sheet should be updated if, and when, new information or data become
available. Appendix C includes a template of a Product Claims Sheet.
Other labeling requirements

In this section you should identify what labeling will be required for your device,
for example, product label, carton label, shipping label, instructions for use, oper-
ating manual, and so on.
As indicated previously, it is imperative that you identify the countries that you
would like your device to be distributed in, as many countries have specific lan-
guage requirements for labeling. Just look at Europe; although the CE Mark
allows trade into each of the countries in the Economic Community, each country
has its own specific language requirements for labeling. As a result, it is advanta-
geous to use symbols where practical, but understand that the symbols you choose
must be acceptable (i.e., use of a harmonized standard such as BS EN 980, BS EN
1041, ISO 15223, ISO 7000, ASTM F2508) as applicable.
This section should also be used to define any additional labeling requirements
not mentioned in the other sections. These include any precautions, warnings, or
contraindications associated with use of the device. This should also be docu-
mented on the Product Claims Sheet (see Figure 6.1).
Patents, trademarks, and licensing agreements

Before you begin the formal design and development of your product, your mar-
keting department should perform a patent and/or trademark search to make sure
that you are not infringing on any existing patents or trademarks and, if not,
initiate the application and/or registration process as needed. Any required distri-
bution or licensing agreements should also be considered and defined.
Clinical information
Per MEDDEV 2.7/4 Clinical Evaluation: A Guide for Manufacturers and Notified
Bodies,
60
Product/Product Family: Tracheostomy Tubes

Intended Use(s): General anesthesia, intensive care, and emergency medicine for airway
management and mechanical ventilation
Indications for Use: A tracheostomy tube is intended to be inserted into a patient’s trachea
through an incision in the trachea to facilitate ventilation to the lungs.
Product Claims Supporting Data (reference report/test numbers)
Sterile Sterilization Validation Report
Product General Description
Five-year shelf life Stability Report
Obturator and tube are clearly marked Design Drawings
to facilitate insertion of the tube and Test Reports
reduce trauma. Product General Description
Support Literature:
Tracheostomy Tubes and Related Appliances
All You Need to Know about Tracheostomy Tubes
Standard 15 mm connector swivel Design Drawings
adapter for proper connection with Test Reports
respiratory equipment Product General Description
X-ray opaque for secure positioning Design Drawings
Test Reports
High-volume, low-pressure cuff Design Drawings
provides an effective low-pressure Test Reports
seal and reduces pressure on the Product General Description
wall of the trachea.
Support Literature:
All You Need to Know about Tracheostomy Tubes
Comfortable cushion neck band Design Drawings
Test Reports
Nontoxic Colorite Certificate of Material—Compound No.
Material Safety Data Sheet
Figure 6.1 Sample product claims sheet.
Manufacturers are expected to demonstrate that their medical device achieves its
intended performance during normal conditions of use and that the known and
foreseeable risks, and any adverse events, are minimized and acceptable when
weighed against the benefits of the intended performance, and that any claims
made about the device’s performance and safety are supported by suitable evi-
dence. Generally, confirmation of conformity must be based on clinical data and
the kind and amount of clinical data needed will primarily depend on the specifics
61
Product Claims Supporting Data (reference report/test numbers)

Nonirritating Skin Irritation Test—ISO 10993-10
Muscle Implantation Test—ISO 10993-6
Nonsensitizing Delayed Contact Sensitization Study—ISO 10993-10
Noncytotoxic, nontoxic Cytotoxicity Test—ISO 10993-5
Muscle Implantation Test—ISO 10993-6
100 percent latex free Design Drawings
Soft medical-grade PVC softens at Test Reports
body temperature and conforms to Product General Description
the anatomy facilitating insertion of
the tube, reducing trauma and Support Literature:
increasing patient comfort. It also Tracheostomy Tubes and Related Appliances
resists kinking. All You Need to Know about Tracheostomy Tubes
Warnings/Cautions
Single use only.
Sterile if package is unopened and undamaged.
Test inflate cuff, pilot balloon, and valve prior to use (if present).
Deflate cuff before intubation or prior to repositioning the tube. (To aid insertion and avoid cuff damage.)
Do not overinflate cuff. Maximum air pressure of 25 mm Hg.
Prescription use only. Federal law restricts this device to sale by or on the order of a physician.
Exposure to elevated temperatures and ultraviolet light should be avoided during storage. Keep dry.
Store less than 49ºC, 120ºF.
Contains DEHP.
Do not resterilize.
Verify proper assembly/attachment of respiratory equipment prior to use.
Tracheostomy tube is recommended to be replaced within thirty days.
Contraindications
Care must be taken to avoid contact of a LASER beam or an electrosurgical active electrode with this
and other tracheostomy tubes.
Figure 6.1 (continued) Sample product claims sheet.
of the clinical claims with regard to clinical performance, considerations of clinical

safety, including determination of undesirable side-effects and on risk management
output, namely determination of residual risks and favorable benefit/r isk ratio.
Although the MEDDEV guidance document is meant to provide guidance on

the application of Europe’s medical device directives, the requirements are not
unique to Europe. Clinical data may be required in support of an FDA premarket
notification (510(k)) submission, and in most cases, in support of an FDA premar-
ket approval (PMA) application. As a result, it is important at this stage of the
design process that you determine and document what clinical data, if any, will
be required for your medical device.
62
If a clinical investigation or study is required to substantiate performance

claims, there are, of course, requirements that will need to be met with regard
to required approvals prior to the initiation of a study (e.g., IRB, 21 CFR Part
56). Documentation will be required prior to initiating a clinical investigation or
study (e.g., informed consent [21 CFR Part 50], Section 2.2 of Annex 7/Annex of,
Directives 90/385/EEC and 93/42/EEC, respectively) and development of an IDE/
investigation plan and proper monitoring during the conduct of the study (e.g., EN
ISO 14155 and 21 CFR Part 812 is also required).
Regulatory and contractual requirements

Relevant regulatory requirements
This section of the PPS should document all the relevant regulatory and statu-
tory requirements that need to be met before the device can be launched in the
geographical areas noted earlier in the PPS. Therefore, your first step should be to
determine and document the classification of your medical device. As explained
in Chapter 3, the class to which your medical device will be assigned is dependent
on where you want to market your device and the associated regulations or clas-
sification rules governing the device. If you plan on marketing your device to mul-
tiple countries, you should document the device class for each country on the PPS.
The subsequent marketing approval requirements will also be dictated by the
countries you wish to market to and the device class. Most countries require some
form of establishment registration and medical device listing or medical device
license by the manufacturer or his or her representative (e.g., distributor, importer,
authorized representative). In addition, medical devices are typically required to
be designed and manufactured in accordance with good manufacturing practices,
meet essential design requirements, and/or demonstrate compliance with a qual-
ity management system standard (e.g., ISO 13485 certification). For example,
to distribute a medical device in Europe, you need to meet the requirements of
the Medical Device Directive; Canada requires compliance with the Canadian
Medical Devices Regulations; Japan falls under JPAL and requires compli-
ance with Ministerial Ordinance requirements (e.g., MO 169); Australia has its
Therapeutic Goods Regulations; Brazil is regulated by ANVISA and primarily
RDC-185 and 56; and the United States requires compliance with various parts
of the Code of Federal Regulations (e.g., 21 CFR Parts 803, 807, 820). Notified
Body or government approval of the medical device (e.g., technical file, 510(k),
medical device license, etc.) may also be required, as well as representation and
designation of an authorized representative or market authorization holder. The
specific requirements applicable to each country should be documented on the
PPS and the associated activities and tasks accounted for on the project plan.
63
This section of the PPS should also include any relevant standards and test meth-
ods that you plan to comply with. These may include ASTM, ANSI, IEC, UL,
CANCSA, ASQ, EN, ISO, and so on related to labeling, packaging, sterilization,
biocompatibility, hardness, color, electromagnetic compatibility, risk manage-
ment, usability, and so on.
Financial requirements
An area that the PPS should likely include but I do not plan on covering here con-
cerns financial requirements. Financial requirements that should likely be consid-
ered and documented include the following:
• Potential market/volumes
• Cost projection
• Competitive environment (e.g., competitors, strengths, and weaknesses)
• Proposed forecast/profit
• Capital projection (e.g., tooling)
• Percent share of market (e.g., estimated shares)
• Total opportunity
• Resource assessment (e.g., facilities/space, personnel, systems, etc.)
• Medicare/reimbursement
Design input: One final word

I think it is pretty obvious at this point how important the design input stage is
to the design and development process. Development of a clear, comprehensive
list of requirements at the beginning of the design and development process will
likely take a significant amount of time; however, it should eliminate or at least
significantly reduce expensive redesign and rework that could be necessary later
in the design process. It is also important that you define your inputs in terms that
can be verified and validated; that is, each requirement or input should be able to
be verified by an objective method of analysis, inspection, or testing.
Remember that your design inputs need to be unambiguous and reviewed and
approved for adequacy. As a result, it would be advantageous for the review
team to be multidisciplinary and to have the appropriate authority. Once the
design inputs are initially approved, the design input document becomes a con-
trolled document.
Note, it is highly probable that verification activities will uncover discrepancies
that will result in changes to the design input requirements. Any changes, how-
ever, will need to be documented and controlled in accordance with change con-
trol procedures.
64
Chapter 7 Design outputs
From inputs to outputs

Once the design inputs have been reviewed and determined to be acceptable, an
iterative process of translating those requirements into a device design begins.
The first step in the process is to develop your design outputs by converting
the design input requirements into system or higher-level specifications. These
outputs will then be verified to determine if your specifications (i.e., design input
requirements) have been met.
The easiest way to understand design output is to think of design outputs as your
deliverables. They are the manufacturing and assembly procedures, inspection
and test methods, verification and validation protocols and reports, quality assur-
ance specifications, material and component specifications, labeling, service
manuals, and so on that need to be developed or used to show compliance with
design input requirements.
The FDA defines design output in 21 CFR Part 820.3(g) as follows:
Design output means the result of a design effort at each design phase and at the
end of the total design effort. The finished design output is the basis for the device
master record [DMR]. The total finished design output consists of the device, its
packaging and labeling, and the device master record.
As stated in this definition, each phase of the design and development process is
going to have outputs. These outputs will vary depending on the design phase and
the activities being performed and will often serve as inputs to the next design
and development stage. For example:
• At the end of the feasibility phase, the design output is your Product
Performance Specification (PPS). The PPS then initiates (i.e., serves as
an input to) the design and development process.
• Prior to performing any type of biocompatibility testing (i.e., entering
the verification phase), you will need to develop a test protocol or method
(output). The protocol will then be used to conduct the testing (input).
• Prior to conducting a user study (i.e., entering the validation phase), you
will need to manufacture a prototype (output). This sample device will
then serve as the input to the user study or validation (input).
• At the end of the design transfer phase, your design outputs will include
the device, its packaging and labeling, and the DMR. These outputs
serve as inputs to manufacturing and product realization.
65
It is important to note that there may not be an output for every input, but there
should be an input traceable to each output.
I O
I O
I O
Your design outputs are confirmed as meeting design input requirements during
design verification and validation. They are ensured during design review.
Design output requirements

Design output requirements fall under 21 CFR Part 820.30(d) and ISO 9001 and
ISO 13485 Section 7.3.3. They require manufacturers to establish and maintain
procedures for defining outputs in a manner that will allow an adequate evalu-
ation of conformance of design outputs to design input requirements. In other
words, outputs need to be stated or defined in a form that will enable subsequent
verification against design input requirements (e.g., pass–fail, within specifica-
tion, etc.). Manufacturers must also ensure that design outputs do the following:
• Meet design input requirements.
• Provide information for product realization (e.g., purchasing specifi-
cations, finished product specifications, manufacturing procedures,
inspection and testing procedures, servicing manuals and instruction,
device labeling and packaging, etc.).
• Contain or refer to acceptance criteria (e.g., pass–fail, tolerance or range,
measurement, etc.).
• Identify critical device characteristics (e.g., characteristics essential
to the safe and proper use of a device including any special handling,
storage, and/or maintenance of the device). Critical characteristics are
considered to be those aspects of the device whose failure could affect
safety, effectiveness, reliability, and so on. Critical or essential outputs
are typically identified during the risk analysis process.
Outputs must also be verified as suitable (i.e., reviewed and approved) before
becoming final product specifications and beginning production. This helps to
avoid what is commonly referred to as throwing designs “over the wall” to manu-
facturing for verification or tweaking.
A helpful template for capturing your design inputs and identifying the associated
design outputs is provided in Appendix D. Completion of this document will help
66
Design outputs
to identify the tasks and activities that need to be performed and captured on the
design and development plan.
Typical design outputs

Your design outputs are your design input requirements converted into system or
higher-level specifications; they are your deliverables. Design outputs that will
likely be generated during the design and development process may include the
following:
• Bill of materials
• Engineering drawings (e.g., components, assembly, finished product)
• Test methods and protocols (e.g., for verification and validation)
• Quality assurance specifications and inspection procedures
• Product specifications
• Packaging and labeling specifications and methods
• Assembly procedures, work instructions, work orders/travelers
• Installation and servicing procedures and manuals
• Component and materials specifications
• Equipment calibration and preventive maintenance requirements
• Results of risk analysis
• Biocompatibility results
• Prototypes for verification and/or validation activities
• Results of verification activities (e.g., test results)
Device master record

As indicated in the FDA’s definition of design output, your finished design outputs
from the design and development process are the basis for your DMR. Although
the term device master record is not specifically called out in ISO 13485, the
requirement to maintain such a record (“file”) is indicated in Section 4.2.1.
The DMR is an extremely important document to both the FDA and the company
undertaking the development. The DMR consists of a compilation of records that
define the complete manufacturing process and, if applicable, installation and ser-
vicing requirements for a finished medical device. Note the DMR is not a require-
ment of a product under development but the record of the finished device. If you
go back to the chocolate chip cookie scenario that was discussed in the design and
development planning chapter, the DMR would be considered the chocolate chip
cookie recipe and would include identification of all of the materials, equipment,
and instructions necessary for making chocolate chip cookies.
67
The FDA defines the requirements of a DMR in 21 CFR Part 820.181 as follows:
Each manufacturer shall maintain Device Master Records (DMRs). Each manu-
facturer shall ensure that each DMR is prepared and approved in accordance with
document control requirements. The DMR for each type of device shall include, or
refer to the location of, the following information:
Device specifications including appropriate drawings, composition, formula-
tion, component specifications, and software specifications;
Production process specifications including the appropriate equipment spec-
ifications, production methods, production procedures, and production
environment specifications;
Quality assurance procedures and specifications including acceptance crite-
ria and the quality assurance procedures to be used;
Packaging and labeling specifications, including methods and processes
used; and
Installation, maintenance, and servicing procedures and methods.
Think of it this way: if you want to tell people exactly what your product is, what
it is made of, how to make your product correctly and what equipment they will
need to do it, what constitutes acceptable quality and how to test for that quality
level, and even how to maintain and install the proper equipment, then simply
give them the DMR for the product. This makes the DMR one of the most propri-
etary files in your entire company. It essentially contains everything, even those
trade secrets that allow your manufacturing process to work better than conven-
tional processes. Treat the DMR with a high degree of confidentiality.
Remember the DMR is not a single document, like the Product Initiation Request
(PIR) and the PPS; it is a compilation of all documents that relate to the finished
product. Take advantage of this and the fact that the FDA and ISO allow the DMR
to refer to the location of the contents of the DMR and do not require that all of
the documents need to be kept in one discrete file or location.
68
Chapter 8 Design review
Not another meeting!

Although a face-to-face meeting is not a requirement, periodic formal design
reviews are. It is possible to have a design review without having people in the
room. It could all be done, at least theoretically, by shifting reams of paper back
and forth and having everybody sign off on everything, and you could always do
it on the Internet, but unless at least the majority of these design review meetings
are held in person, the real benefit of having them will be lost.
Right from the beginning of this book, we have mentioned these two things sev-
eral times:
• In the design controls process, what goes around comes around.
• The development of a product is the effort of a team made up of people
from different disciplines.
For everyone involved to be doing his or her “thing” correctly, each person needs
to know what everyone else is doing and has done. They need to hear what is
being said, not just see (or read) it. Design reviews should be conducted with as
much personal interaction among team members as possible, otherwise things get
lost in the translation. By the time I tell another person what happened, and add
my little agenda, and she tells the next person, and so on, the original informa-
tion is lost or distorted. People need to know as far in advance as possible what
is about to happen so that if it affects their contribution to the development effort
they can plan for the change.
FDA and design review

The FDA defines design review as follows:
Design review means a documented, comprehensive, systematic examination of a
design to evaluate the adequacy of the design requirements, to evaluate the capa-
bility of the design to meet these requirements, and to identify problems. (21 CFR
Part 820.3(h))
Design review requirements

As the design is developed, it must be periodically reviewed. Design reviews
should be conducted at major decision points or milestones in the device’s
69
development cycle to provide assurance that an activity or phase has been com-
pleted in an acceptable manner and that the next activity or development phase
can begin. The design stages must be formally defined in design control proce-
dures (see Appendix A), and the timing of design reviews should correspond in
most cases with completion of milestones and design phases. The design reviews
should also be indicated on the development project plan.
The design review meeting should include representatives of all functions con-
cerned with the design stage being reviewed. This is intended to prevent “over-
the-wall” designs from entering production. For example, what your R & D person
found to be feasible from a bench-testing standpoint may not be feasible in the
production environment at a large volume. Unless your production representative
is present at the design review meeting, he or she will be stuck with specifications
that may be impossible to meet.
Each design review needs to also include an individual who is independent
(objective) from the design stage being reviewed. This is done simply to ensure a
fresh perspective based on the principle that those who are too close to the design
may overlook design errors. In addition, any specialists who might be needed
should also be present. The specialist may have no particular responsibilities
within the company but could be a leading expert in sterilization, for example,
and his or her participation could be invaluable.
Design reviews must be comprehensive for the design phase being reviewed, and
the results need to be documented and maintained.
Design team members

The success or failure of your design and development project may be influenced
by your design team members. The composition of your design team will depend
on the type of formal design review, the type of product, and the specific capabili-
ties of persons available. Therefore, in determining who should participate, you
should give consideration to the qualifications of personnel, the type of expertise
required to make an adequate assessment, and the independence of personnel. In
addition to having professional expertise in a given field, design team members
should possess the following qualities:
• Competence
• Objectivity
• Sensitivity
Formal design reviews should be conducted by personnel who have the required
knowledge, experience, and personal attributes. The team members should be
able to independently represent their own particular fields and functions and to
present their opinions, recommendations, and requirements constructively.
70
Design review
Another important personal attribute of a team member should be objectivity.

Even though technical experience may lead to preexisting opinions and biases,
these should be put aside. Team members should evaluate information on its
merits without prejudgment or emotional involvement. Bias can seriously com-
promise the success of the design review process. If any member exhibits weak-
ness in this area, it can easily provoke similar behavior from other members and
destroy the effectiveness of the design review process.
A team member’s function is to ask and answer questions; he or she should be
encouraged to understand that even difficult or embarrassing questions should
be handled in a supportive and constructive way. It is always surprising to see
people nod their heads in agreement with something only to find out later that they
had no clue what was being said but they were too embarrassed to ask for clarifica-
tion. If you don’t understand, it is likely that there are others who don’t understand.
Design review focus

The design review has a dual focus:
• Internal focus: feasibility of design and produceability of the design
with respect to manufacturing and support capabilities
• External focus: user requirements
Each design review meeting should provide a careful assessment of the results of
the design and development activities to date. It should also provide feedback and
information on existing or emerging problems related to the product or its devel-
opment. For example, are activities on schedule, and are the results of testing to
date acceptable? Are there any conflicts that need to be addressed or unexpected
problems? Finally, the design review meeting should confirm readiness and
approval to proceed to the next phase or identify the need for new tasks or actions.
Design review elements

Each design review meeting should address three critical areas:
• Design evaluation
• Resolution of concerns
• Implementation of corrective actions
The purpose of any design review meeting is to evaluate the design at the particu-
lar design stage to determine whether design output results support or meet the
requirements or design inputs for the device. As a result, the design review meet-
ing should review and evaluate verification and validation data in order to deter-
mine whether (1) the design outputs actually meet the functional and operational
requirements for the device, (2) the design is compatible with all the components
71
and any other accessories, (3) the customer needs have been met, (4) the safety
requirements are achieved, (5) the reliability and maintenance requirements are
being met, and (6) the manufacturing, installation, and servicing requirements
are compatible with the design specifications.
The design review meeting should also be used to identify and resolve any prob-
lems encountered thus far in the design and development of the device; for exam-
ple, has the device failed a critical test? The design team should be encouraged
to work together to find solutions to any problems identified. The team should
then discuss the concerns raised during the evaluation portion of the meeting
and decide on an appropriate action for each one.
Not all identified concerns and problems will result in corrective action. The team
may decide that the issue is erroneous or immaterial. In most cases, however,
resolution will involve a design change, a requirements change, or a combination
of the two. Any actions identified and taken as a result of a problem (e.g., change
in specification, labeling, packaging, etc.) need to be documented, reviewed, and
approved. Some actions or changes may also require verification and/or vali-
dation of effectiveness. If the solution is not obvious, an action item should be
assigned to study the problem further, and any action taken should be reviewed
for effectiveness at a subsequent design review.
Design review stages

Formal design reviews should be planned to detect problems early. It is a well-
accepted fact that the cost to correct design errors increases as the design nears
completion and the flexibility to implement an optimal solution decreases. The
number of design reviews required, however, will be dependent on the complex-
ity of the design. A single design review may be appropriate at the conclusion
of a design project for a simple design or a minor change to an existing product.
Multiple reviews are typically conducted for more complex designs, with most
design and development projects having a minimum of three formal reviews.
Informal design review meetings may supplement formal reviews and are often
conducted continually throughout the design and development process and con-
sist of just a few individuals. It is up to the organization to use sound judgment to
determine the number and types of reviews.
The type of formal design review, its objectives and scope, and the nature of the
design review will change as the design evolves. During the initial stages issues
related to design input requirements will predominate. Next, the main function of
the reviews may be to evaluate or confirm the choice of solutions being offered by
the design team. Then, issues such as the choice of materials and the methods of
manufacture become more important. During the final stages, issues related to the
verification, validation, and production may predominate. It may be easier to
decide when a design review should be conducted if we create several somewhat
72
Design review
artificial stages and look at what the purpose of the review would be at that point
in the developmental project and some of the more important points that might be
included in an agenda.
Stage 1: Review immediately after initial design inputs are approved The pur-
pose of this initial design review meeting is to formally define and confirm the basic
requirements for the device (design inputs and expected outputs). It is also used to ini-
tiate the development and manufacturing phase and the beginning of design change
control. The initial design review meeting will also formally define the design proj-
ect team (see Appendix E: Project Approval Form). All the members of the project
team must be present at the initial design review meeting. In addition, an individual
who does not have direct responsibility for the design stage being reviewed needs
to be present. The presence of specialists who are capable of providing specific
expert guidance in critical areas may also be needed. The Product Performance
Specification (PPS) will serve as a critical element of the initial design review.
A typical agenda for this initial design review might include a review of the
following:
• The design inputs
• The expected outputs and any known outcomes
• The project plan: activities, resource assignments, and time lines for
completion
• The risk analysis
• The PPS
• Any other pertinent information
Stage 2: Mid-project design reviews The objective of these mid-project design

reviews is to determine whether prototypes produced by processes that are identi-
cal to (or simulate) actual production methods and procedures have performed
adequately in simulated use testing and clinical evaluations.
A typical agenda for a mid-project design review might include the following:
• Verification that the proposed design satisfies product or process
requirements
• Examination of the results of analyses, calculations, and tests to determine
whether design outputs meet functional and operational requirements
• Verification that the proposed design is compatible with components and
accessories
• Verification that safety requirements have been considered and addressed
• Verification that reliability and maintenance requirements are satisfied
• Evaluation of the cost-effectiveness of the product
• Evaluation of the product performance
• Evaluation of the manufacturability of the product
73
Stage 3: Final design review meeting After all verification and validation activ-
ities have been completed, a final design review meeting should be conducted.
The final design review should be held immediately prior to the transfer of the
device to manufacturing for production. The last design review meeting is the
final confirmation that the overall design output has met the overall design input.
All project team members should be present at the final design review meeting.
Any remaining changes or conflicting, ambiguous, or incomplete requirements at
this stage will need to be identified and resolved.
A typical agenda for a final design review meeting should include the following:
• A final review to ensure that the final design (output) satisfies design
input requirements
• Confirmation that all analyses, calculations, and tests have been suc-
cessfully carried out and that the final product can be manufactured,
inspected, assembled with adequate tolerances, stored, delivered, and
installed reliably, safely, and cost-effectively and will perform as expected
• Verification that all documentation for manufacturing, safety, installation,
operation, and maintenance of the device is ready for transfer to production
• A final review of the risk analysis to assess and ensure any additional
real or potential hazards associated with the device under normal and
fault conditions have been addressed
• Implementation and approval of any necessary changes needed prior to
transferring the design and development specifications and procedures
to production specifications and procedures
Stage 4: Use design review meeting It is important to understand that design

control does not end with the transfer of a design to production. Design con-
trol applies to all changes to the device or manufacturing process design, includ-
ing those occurring long after a device has been introduced to the market. This
includes evolutionary changes such as performance enhancements, as well as
revolutionary changes such as corrective actions resulting from the analysis of a
failed product (e.g., recalls). The changes are part of a continuous, ongoing effort
to design and develop a device that meets the needs of the user and/or patient.
Accordingly, the design control process is revisited many times during the life of
a device. These reviews are often referred to as “use” design reviews.
The objectives of the use design review meeting should be to do the following:
• Determine whether the product or process performance satisfies cus-
tomer perception (i.e., meets user needs)
• Identify possible modifications or improvements and to evaluate these in
terms of cost versus benefit
• Make recommendations for the design and development of similar
devices in the future
74
Design review
Input Output Result

(Requirement) (Test Method) (Outcome = Input?)
Input/Requirement Output Review/Result Change/Action

I=O
Min flow rate = 500 ml/hr Protocol 123 using ASTM Summary Report No action required
Method 123XYZ FR>500 ml/hr - Pass
Non-cytotoxic Protocol 100B - using Summary Report - Pass No action required
Agar Diffusion Method
3 Sizes: 4 × 4 Protocol 3S - Clinical Evaluation Report - Eliminate 4 × 4 size – report

2×4 Clinical Evaluation 4 × 4 not needed shows there is no market
1×4 for 4 × 4 size
Package integrity 49 CFR 173.465 & DOT Ship Testing Report - Change to foam packaging to
49 CFR 178.608 Fail eliminate damage & retest
2 Year Shelf Life Stability Protocol Shelf Life Stability Report - Stability data to support a 2
# 10-17-001 Pass year shelf life
Verification/Validation
Figure 8.1 Design review meeting table format example.
Documenting the design review

Each design review meeting will typically include a review of the design inputs,
any expected or known outputs, and any known outcomes. The project plan, risk
analysis, and PPS are essential documents that should be reviewed at each design
review meeting. A good way of documenting the design review is to put it in table
format (see Figure 8.1). This format ensures a complete evaluation and verifica-
tion of the outputs to the input requirements. Any required changes, concerns,
and so on should also be documented, and an action item matrix should be created
to track any actions needed. Appendix F includes a template for recording the
minutes of a design review meeting.
Meeting dynamics
As a successful design review depends almost as much on conducting a success-
ful meeting as having accurate data, it seems appropriate to review some things
that can be done to ensure a successful meeting. The comments and concepts
reviewed in this section should prove useful to all members of the design review
team, including managers. They are in fact useful, tested, and verified concepts
that will work in any business communication setting.
75
Communication skills
The design review runs on information. People need clear, concise, and complete
information to plan, organize, and execute their responsibilities. Whether you’re
leading the meeting, evaluating the outcome, or making a presentation, you will
succeed or fail based on your ability to communicate. Words are the vehicles
people use to communicate their goals, objectives, and performance standards.
Unfortunately, many words are ambiguous and are often interpreted in differ-
ent ways. The definition of what’s a “good wage” may depend on whether you’re
paying it or receiving it. The 500 most commonly used words in the English
language have an estimated 10,000 different meanings. When an engineer says,
“I will complete this assignment as soon as possible,” does that mean in the next
two minutes, two hours, two days, or two months? We need to define our terms to
make sure the receiver and sender are on the same wavelength.
Being sure that the product has “superior quality” is a great idea, but it may not
explicitly communicate the desired behavior or results the team hopes to accom-
plish. Staff members may have their own idea of what “superior quality” means.
Each person may leave the meeting ready to implement his or her own definition
of “superior quality.” When sending and receiving information, make sure the
meaning is clear. Try saying something like, “My definition of superior quality
is …” or “As it applies here superior quality means ….”
The vocabulary of product development includes many abstract ideas and con-
cepts like superior quality. Not only should you define the terms, but you should
also provide concrete examples to help explain the abstract idea. Examples and
illustrations can provide tangible reference points to drive home the point.
Abbreviations and jargon also pose potential hindrances to effective communica-
tion. In technical areas that cannot always be avoided, but as the design team is
composed of people from different disciplines, be sure that terms are explained
and clear. “The team is writing a revision to the PPS. We have new information
from ASQC and ANSI that suggests this will be wise when we prepare the PMA
for CDRH.” Chances are some people will not know what all the initials mean.
Spell out or define what abbreviations mean. This extra step can be the difference
between understanding and confusion.
Did they get it?

Remember the biggest problem with communication is the illusion it has been
achieved. Very often, defining a single word or concept is all that is needed to
successfully communicate a thought or feeling. At other times verifying someone
heard what you said is prudent to ensure the message was interpreted as intended.
The content and delivery of a message is obviously important, but what really
counts is what’s heard or interpreted by the receiver.
76
Design review
Verifying the message is a simple technique whereby the sender of the message
asks the receiver to explain his or her interpretation of the message. If the receiv-
er’s interpretation is accurate, then a successful communication has occurred. If
the interpretation is inaccurate, the sender needs to clarify and correct the mis-
understanding. People are much more likely to pay attention, concentrate, and
listen carefully if they know they may be called on to give their understanding of
the message.
Going one extra step to check out the receiver’s understanding can often save a
lot of grief. If the mirrored response is incorrect, the sender knows the message
needs to be restated. Of course, some breakdowns occur simply because the lis-
tener wasn’t paying attention.
The design team sits at the communication center of the development program
and is particularly vulnerable to communication breakdowns. The difficulty
of consistently verbalizing clear and accurate messages is immense. Never
underestimate that problem. Even the most carefully worded message can be
misunderstood. Periodic message verification can eliminate confusion and mis-
understanding and can prevent the small and large blunders that result from com-
munication breakdowns.
Listen and validate

Design team members are often on the receiving end of many bits of information.
It’s estimated that team members spend up to 40 percent of their time listening.
Being able to listen and accurately understand every message received is easier
said than done. Listening is not easy. It requires focus, concentration, and a moti-
vation to understand the point being made. Successful people realize that effec-
tive listening is as important as effective speaking.
How do you become an effective listener? For one thing, making eye contact
with the speaker helps one to focus and concentrate. Facing the speaker puts the
receiver in a good position to observe body language and other aspects of deliv-
ery. Words tell us the intellectual content of the message. Tone of voice and body
language tell us the emotional and energy level of the sender. Actively observing
how the message is delivered is often critical to understanding the total message.
Effective listening is an active process, not a passive one. The mind must be fully
engaged when listening. No other thought should be permitted to enter your mind
while listening. However, too frequently other thoughts do enter our mind, and we
lose focus. Some people are too busy listening to themselves to listen to someone
else. Others begin to think of what they will say back to the speaker even before
they understand the speaker’s point.
The best managers not only concentrate and listen to the message but also peri-
odically validate their own interpretation of the message. They feed back to the
77
speaker their understanding of what is being said. Factors like the complexity
and importance of the message determine how often validation should occur. In
the design review setting, it is something that should occur frequently. There are
three levels of validation:
• Level I: Validate by feeding back the exact words used by the speaker.
• Level II: Validate by feeding back a paraphrase of the message.
• Level III: Validate by feeding back your interpretation of the words and
body language.
Team members need to listen, not only to the words of the message but also to the
tone of voice and body language. At times, it’s necessary to feed back what you
think the sender really means but has not said. As shared understanding builds,
the sender is often motivated to share additional thoughts and feelings.
Accept the bad news

Bad news may well be the most useful information design team members receive.
One common reaction to bad news is to take it out on the person delivering
the message. Blaming the customer is another common response to bad news:
“The product failed because they didn’t follow our directions.”
A third response is to deny, deny, deny. Data indicating quality problems are criti-
cized for being inaccurate or incomplete. Negative feedback from the customer is
rationalized. All of these reactions are counterproductive. The bad news can be
helpful. It’s a way of telling the design team that something is wrong and a change
is needed. An upset customer sends two types of messages. One has to do with the
facts. The other has to do with feelings. If the team members react defensively and
don’t listen, there is no opportunity to improve the situation. If, on the other hand,
they listen with an open mind and acknowledge the problem, they have taken a
step toward improving the situation.
Monitor and measure

Measurements show how much progress has been made and what remains to be
done. The design team’s ability to measure, monitor, and control work product is
directly related to its ability to identify potential problems and to take corrective
action if needed. Decisions based on data are a lot better than those based on
speculation. Objective data take emotion and preconceived ideas out of an issue.
An effective design team gets the data before making a decision. Decisions based
on good data are a lot better than those based on emotions in this setting.
The team needs to draw out its members and find out who did what, where, why,
and how. Separate the facts from the feelings, assumptions, and opinions. This
78
Design review
information should be verified for accuracy with feedback received from others
and from personal observations. The purpose is not to affix blame but rather to
determine the facts. Given all the facts, almost anyone can make a proper decision.
Don’t confuse motion with progress

The design review is meant to achieve results. The results are the bottom-line measure
of performance for the design team. Activity, effort, and hard work are noteworthy
factors, but the correct output is what really counts. What has been accomplished?
What has been implemented? Some members of the team can project the appear-
ance of productivity through the beehive atmosphere of activity. The atmosphere is
tense, people speak rapidly, the phone rings frequently, and other employees come
and go providing various input. Lots of motion, but is there any progress?
The chaos of a product development can often make it feel like a lot of work
is being accomplished. Activity and effort can sometimes mislead a team into
thinking goals are being met. By focusing on results, the team can ensure that
activities are not ends in themselves.
The design team needs to learn a lesson from the military. A long time ago the
military learned that personally going, looking, and listening is the only reliable
feedback. A good military officer who has given an order goes out and sees for
himself or herself whether that order has been carried out and how well it has
been implemented.
Seeing and hearing things not only gives the design team direct, unfiltered feed-
back but also conveys to everyone involved in the project an interest in them, their
ideas, and the work they perform.
Meeting minutes
Many design meetings end with confusion as to who has to do what and when.
During a design review meeting, as new and different action items are identified,
they can be written down on a flip chart or whiteboard. The due date and person
or people responsible for each item should also listed. At the end of the meeting,
the team leader can do a quick review of all action items on the list. The team
members can then leave the meeting with a clear understanding of who is respon-
sible for which action items and when they are due.
Making decisions that solve problems

The last thing that we need to discuss before returning to information more spe-
cific to design controls is decisions. Effective design teams make decisions, from
simple to complex, so it’s important to know how the process works.
79
The ability to define and solve problems leads to progress and improvement.
Dealing with symptoms only wastes time, effort, and money. The process includes
the following steps:
• Define the problem
• Collect and analyze data
• Generate alternatives (i.e., brainstorm)
• Evaluate alternatives
• Select an alternative
• Implement the alternative
• Evaluate the result
In design review meetings, it is imperative to identify where the project is at any
given time so that a correction can be made if necessary. Many problems may
require multiple meetings, and different team members will frequently be at dif-
ferent points in the process. Little progress is made when everyone comes at a
problem from a different point in the process. An effective team leader brings the
group together by defining where they are in the process. Doing that improves
productivity by focusing the group to concentrate on one task.
Team leaders usually prepare what they are going to say but often don’t pre
determine what questions they will ask. An important aspect of leadership is the
ability to ask the right questions at the right time and to insist on answers that
make sense.
The answers to the right questions provide the team leader with the informa-
tion he or she needs to make decisions. These questions often touch on sensitive
or unpleasant topics. The questions should be simple, direct, and focused. They
should be framed to elicit a concrete, specific response. How the questions are
asked (choice of words, tone of voice, body language) is critical. It must be done in
a way that doesn’t cause defensive or adversarial responses. The questions should
be straightforward and asked from a neutral point of view, meaning not aggres-
sively or with strong emotion but not from a weak or passive position either.
Follow-up questions are often essential to achieve specific answers to the ques-
tions asked. If a person is unresponsive or vague, be persistent. Keep asking and
probing. Rephrase the question to get to the core of the issue.
Beware of people who know the solution before they understand the problem.
There is a tendency by some to go off designing systems, forms, and procedures
without understanding the real problem.
Design teams are confronted with a wide range of problems ranging from broken
machinery, to late deliveries, to unhappy customers, to conflicts among target
properties or people. Some problems are defined in such a way so that there is
only one obvious solution: “The problem is that the engineers aren’t working hard
80
Design review
enough.” Other problems are really symptoms of more basic underlying prob-
lems. Still other problems can be defined in such grand or global terms that it
paralyzes the ability to act.
In addition, design teams are often presented with problems that inspire futility.
After all, if the presented problem didn’t inspire futility, it would have already
been solved. Right?
The hardest part of problem solving is figuring out what the real problem is. As
indicated, sometimes the presented problem really isn’t the problem that needs
to be solved at all. Assess the accuracy of the data. Come to grips with reality,
as opposed to the images and perceptions. Break through the generalizations.
Complex problems should be broken down into smaller, simpler ones.
The problem statement should be free of either causes or solutions. The problem
should describe what currently exists versus what is desired. The more specific
and measurable the description, the better that description is. A problem state-
ment such as “How to reduce the scrap rate from 5 percent to 3 percent?” provides
specific and measurable criteria in the problem statement.
Once the problem is defined, the additional steps include the following:
• Collect and analyze the data
• Generate options or solutions
• Evaluate those options or solutions
• Make a decision
• Implement that decision
• Evaluate and measure the result to see if the problem has been solved
81
Chapter 9 Design verification
What is the purpose of design verification?

The purpose of design verification is to provide objective evidence that your
design requirements have been met and, if they have not been met, to show to
what extent they have or have not been achieved.
What is design verification?

Design verification is the process of checking at each stage whether the output
conforms to the requirements for that stage. For example, have the design inputs
been put in a format that allows for adequate verification? Do the actual device
dimensions match the engineering drawing? Does product packaging protect the
device from any adverse effects of storage and handling? Is the device capable of
withstanding the sterilization method chosen with no product degradation? Does
the sterilization method chosen result in a sterilized device?
Design verification requirements

Design verification requirements fall under Section 820.30(f) of the FDA’s
Quality System Regulation and Section 7.3.5 of ISO 9001 and ISO 13485. Before
we talk about the actual requirements for design verification, let’s take a look at
some basic definitions.
Verification means confirmation by examination and provision of objective evi-

dence that specified requirements have been fulfilled. (21 CFR Part 820.3(aa))
(emphasis added)
Specification means any requirement with which a product, process, service, or

other activity must conform. (21 CFR Part 820.3(y))
Design verification confirms whether the outputs meet the functional and opera-
tional requirements for the device; that the device is both safe and reliable; and
that the labeling and other regulatory requirements are satisfied.
In other words, did I make the product right (i.e., to specification), and can I
prove it?
83
Design verification activities should be conducted at all stages and levels of device
design and development and should be identified on the design and development
plan. Design verification is always conducted against specifications.
Manufacturers are expected to select and apply appropriate verification tech-
niques based on the generally accepted practices for the technologies employed in
their devices (e.g., look at what testing was done on predicate or similar devices).
Verification activities are required to be performed in accordance with estab-
lished procedures, and verification methods should clearly define (or reference)
acceptance criteria so that results can be evaluated to confirm whether the design
input requirements have been satisfied. This last statement cannot be stressed
enough. At this stage in the process, you are verifying the acceptability of the
device design, hence you need to know what is considered acceptable. There may
be some tweaking to the specifications that will result from this step, but this is
not the time to actually determine what is acceptable. This should have already
been determined. Some verification methods are highly standardized (e.g., steril-
ization to ISO 11135, 11137; biocompatibility to ISO 10993; medical device safety
to IEC 60601; etc.); however, in other cases manufacturers may choose from a
variety of applicable methods.
The results of all verification activities and any subsequent actions must be
recorded and include identification of the design, methods, date, and individual
performing the verification. This forms part of the Design History File. This will
include review and approval of protocols and results.
Verification activities
Any approach that establishes conformance with a design input requirement is an
acceptable means of verifying the design with respect to that requirement. The
nature of verification activities will of course vary depending on the design input
that you are verifying. Some verification activities will likely be pretty straight-
forward and simple (e.g., verifying device dimensions to an engineering drawing);
however, others will prove more complex (e.g., verifying device cleanliness and
sterility of a reusable device). The test methods that you use to conduct design
verification activities should be evaluated to ensure that they provide sufficiently
accurate, precise, and repeatable results under their usual conditions of use.
Analytical methods intended for identification, purity, or assay should be vali-
dated, as should methods developed to ensure cleanliness and sterility of devices.
Physical, electrical, mechanical, and performance measurement methods (other
than direct measurement by a capable, standard calibrated instrument) should be
considered for appropriate validation, especially if the method is for evaluating an
essential design output, that is, test method validation.
84
Design verification
Some examples of design verification activities include the following:

• Design reviews to confirm inputs = outputs
• Inspection or testing of the device to meet functional and operation
requirements, including mechanical, electrical, and functional tests such
as fatigue, wear, tensile strength, compression, flow rate, burst pressure,
static load, rigidity, and so on
• Inspection of labeling to ensure compliance with labeling and regulatory
requirements (symbols, languages, claims, etc.) and testing to ensure
legibility
• Biocompatibility testing of materials and the finished device (e.g., irrita-
tion, sensitization, cytotoxicity)
• Electromagnetic compatibility
• Risk analysis to identify possible hazards with the device design
• Worst case analysis of an assembly to verify components can handle the
foreseeable stresses during handling and use
• Thermal analysis of an assembly to ensure internal or surface tempera-
tures are not exceeded
• Fault tree analysis (FTA) or failure analysis of a process or design
• Safety and reliability testing of components, parts, alarms, and so on
• Review of the traceability matrix discussed under the design review
section
• Package integrity tests for holes, protection, sterility, and so on
• Bioburden testing of product to be sterilized
• Sterility testing
• Comparison of a device to a previous product having an established his-
tory of successful use (e.g., FDA 510(k))
• Verification of measurements and dimension to an engineering drawing
• Demonstrations to evaluate use and function of the device
• Alternative calculations using analytical methods or mathematical
models
• Compatibility testing of the device with mating parts and connections
• Compatibility testing of the device within the intended use environment
• Process validation to ensure that production can achieve the level of
quality designed into the device
• Review and approval of documentation for accuracy (e.g., design out-
put documentation: bills of material, assembly processes, software code,
labels, etc.)
85
Chapter 10 Risk management
Why?
Risk management has become a hot topic as of late with both government
Regulatory Authorities (e.g., FDA) and Notified Bodies. With the increasing
number of adverse event reports and recalls, it becomes more important than
ever to manage and control risks associated with the use of medical devices.
Consequently, the earlier in the design and development process that you begin
examining device risk, the better for everyone—especially the bottom line. We
all know that the earlier you can identify a potential and/or real problem and
fix it, the less costly and certainly less damaging to the company’s reputation.
It does absolutely no good to rush a device to market only to have to recall it
shortly thereafter.
How does risk management fit into design

and development?
With risk being so important, it is surprising that the requirement for risk man-
agement is not more obvious, but it is there. You just have to look a little closer.
The FDA’s Quality System Regulation calls out the requirement for a risk analysis
in Section 820.30(g), design validation. It is just one sentence: “design validation
shall include risk analysis.” However, if you look at the FDA’s Quality System
Inspection Technique handbook under the design controls section, you will note
that as part of an FDA inspection of design controls, the investigator will verify
that a risk analysis was performed. The requirement for risk management in the
ISO 13485 standard is a little more obvious. Section 7.1 stipulates that require-
ments for risk management be established and documented. OK, that’s a start,
but what does that mean? If you go with the FDA’s mantra, anywhere you see the
word establish, a procedure is expected. Furthermore, ISO 13485 Section 7.3.2
calls out the requirement to look at the outputs of risk management during the
design and development of inputs. Hence, it becomes fairly obvious that risks
need to be considered at the very beginning of the design and development pro-
cess and reviewed during the initial design and development review meeting in
conjunction with the review and approval of the design inputs. Even more impor-
tant is the fact that you will need to continually assess and evaluate device risk
throughout the design and development process and even after the device is trans-
ferred to production.
87
Risk management planning for a

D&D device based on the quality
Planning system policy and objectives, to Design Reviews
include the risk acceptability
criteria defined by management
No
• Intended use
• Functional, performance,
D & D Input and safety requirements • Identify list of hazards; Design,
• Applicable statutory and harms hazard and risk
regulatory safety • Risk estimation Assessment review – Is
requirements • Risk evaluation the hazard identification &
• Safety information from • Requirements for risk risk assessment
previous, similar designs control measures acceptable?
• Other requirements
essential for safety
No
Yes
D&D Yes Design of risk controls, including
Output Are risk
control measures device and process risk control No
feasible? measures, if necessary
No
D&D Yes
Verification Do Have
Determination of
Yes individual any new Individual
individual
residual risks meet Yes safety design residual risk review
residual risk after the No
the acceptability requirements been – Are residual risks
application of risk
criteria? identified during acceptable?
control
verification?
Yes
D&D No
Validation Have any
new safety design Do the Does the
requirements been benefits of use of the overall
identified during
No device out-weigh the No residual risk meet the
validation?
risks of using the overall acceptability
Project cancellation criterion?
device?
or device redesign
Design
Design transfer Yes
Transfer
Yes GHTF.SG3.N15-R8, P.20
Figure 10.1 Flowchart illustrates how risk management should be integrated into

the design and development process. (From the Global Harmonization Task Force,
Study Group 3.)
The Global Harmonization Task Force, Study Group 3 provides a flowchart that
illustrates how risk management should be integrated into the design and develop-
ment process (see Figure 10.1).
What is a risk analysis, and what is risk management?

Before we answer that question, let us first get an understanding of what we mean
by the term risk:
RISK = PROBABILITY + SEVERITY
In other words, risk is the combination of the probability that harm will occur
(i.e., how often or likely) and the consequence of that harm should it occur (i.e.,
how severe it might be, for example, the result or outcome).
88
Risk management
Given this definition we can then look at the terms risk analysis and risk manage-
ment. Risk analysis is really just a subset of risk management. In simple terms,
risk analysis is the process of collecting and examining information or data in
order to identify real and potential hazards associated with the use and misuse of
a device and then estimating the risk associated with those hazards. Risk manage-
ment includes risk analysis and the process of evaluating the individual risks and
the overall risk for acceptability, controlling any unacceptable risks or justifying
them, and then managing risks through postmarket experience.
Risk management process

The risk management process can be broken down into a series of steps:
1. Determine the levels of risk (e.g., low, medium, high) and identify what
is considered acceptable.
2. Identify and list those characteristics that could affect the safety of
the device.
3. Identify any associated hazards that could result from the correct or
intended use of the device, as well as the foreseeable misuse of the device.
4. Determine the source or cause of the hazard.
5. Assign a level of risk to each identified hazard (e.g., low, medium, high),
including the probability of its occurrence and the severity of the hazard
if it occurs.
6. Determine the acceptability of each risk.
7. Eliminate or reduce each risk (redesign, process validation or process vari-
ability reduction, labeling, user education, etc.) as far as feasible or practical.
8. Evaluate the controls and the solutions adopted (risk reduction measures)
and determine whether the solution caused new problems or risks and
repeat the steps if it has.
9. Evaluate the overall risk for acceptability.
10. Document the process and continue to monitor whether original assump-
tions were correct (e.g., probability and severity) and whether risks
remain acceptable throughout the life cycle of the device.
Note, the annexes in ISO 14971 provide some solid guidance for implementing
the risk management process.
Let’s take a look at these steps in a little more detail. Only two outcomes are pos-
sible in the development of a medical device, regardless of its specific intended
use. The finished device is “safe and effective,” or it is not. So how do we ensure
our device will be safe and effective? First, the design team needs to identify
and list all of the device characteristics that could pose a real or potential hazard
89
(i.e., affect the safety of the device) under normal and/or fault conditions. This
might require that the team formulate a series of questions concerning the man-
ufacture, sterilization, intended use and application, intended users, reasonable
foreseeable misuse, accessories and connectors to the device, environmental influ-
ences, device packaging, transport and storage, and ultimately device disposal.
These questions should be considered from the point of view of all individuals
involved with the device (e.g., assemblers, users, service providers, patients, etc.).
Again, Annex C of ISO 14971 provides a list of potential questions. The team
then needs to identify the hazards associated with the device characteristics if
used correctly, as well as incorrectly, and determine the degree of risk associated
with each hazard. Hazards and contributing factors associated with a device may
include environmental hazards, biological hazards, hazards relating to use of the
device, and hazards arising from function and aging. Most people have no trouble
identifying the really big problems. Actually, most design engineers “design out”
major hazards from the beginning. The problems and risks that are often over-
looked are the minor ones or the ones that are associated with misuse. As medical
device manufacturers, we can’t always account for every dumb or unexpected use
that someone tries with a product, but we must try. Although these minor prob-
lems don’t necessarily render the device unsafe or ineffective, they are often the
difference between a good product and a great product.
Risk analysis is not difficult if the team remembers to think of the customer. The
new device design has accomplished all of the hard stuff, but what happens to the
patient when he or she puts it on? It may help manage or treat whatever problem it
was intended to address, but shouldn’t it be as comfortable as possible? It should
also be as reliable as possible; does the design account for that? What about the
needs of the physician, the nurse, or the caregiver in the home health environ-
ment? Does the device become ineffective and perhaps create a hazard for any
of them? What happens to the device if it is used exactly as you intended and
instructed? It should work perfectly, and most design teams think about that. What
happens if someone uses the device in a manner that isn’t typical? What happens if
the device is used in an environment that the team did not take into account? What
happens when you put all these things together—the user, the environment, and
the device—and they interact in a manner that you didn’t think of?
The reason for risk management is to answer questions such as these. If the haz-
ard created by an atypical use of a device can be reduced or eliminated in the
design stage, then do it.
Hazards traditionally considered in risk analysis include the following:
• Mechanical hazards
• Operational hazards
90
Risk management
• Chemical hazards
• Biological hazards
• Electrical and energy hazards
• Storage and transport hazards
• Informational hazards
These hazards, however, typically result not from device use but rather from
instances of device or component failure.
Once you identify a hazard, it is important that you determine the source of the
hazard. If you do not know where or how or why the hazard is likely to occur, then
it is unlikely that your mitigating actions will be effective. Common techniques
that may be used to assess risk include the following: fault tree analysis (FTA),
failure mode and effects analysis (FMEA), failure mode effects criticality analy-
sis (FMECA), and a hazard and operability study (HAZOP).
Remember, risk = probability + severity. As a result, once you identify the possi-
ble hazards that may occur, you need to estimate the chance or probability that the
hazard will occur and the resultant consequences or harm in order to determine
the level of risk. It is the manufacturer’s responsibility to determine and establish
probability levels and severity levels and associate each level with some type of
descriptive or semiquantitative or qualitative measure. The number of levels is up
to you. A simple probability matrix and severity matrix are shown in Table 10.1
and Table 10.2.
Table 10.1 Probability Levels

Probability Level Possible Descriptive
High Likely to happen, often, frequent
Medium Can happen but not frequently
Low Unlikely to happen, rare, remote
Table 10.2 Severity Levels

Severity Level Possible Descriptive
Significant Death or loss of function
Moderate Reversible or minor injury
Negligible Will not cause injury or will injure slightly
91
In determining or estimating probability, remember that probability may be

impacted by how often the device is used, the lifetime of the device, or the user
or patient population. Whatever method you choose to estimate probability, it
should be based on sound data. Probability may be estimated by an analysis of
the following:
• Published standards
• Scientific technical data
• Clinical evidence
• Expert opinion
• Usability tests employing typical users
• Postproduction data (e.g., field data from similar devices), recall, com-
plaints, adverse events, and so on
The level of severity may be impacted by factors related to the significance of the
resultant harm. Annex D of ISO 14971 discusses some methods for risk estimation.
So now that we have determined probability and severity levels, it is time to estab-
lish associated risk levels. Risk is typically categorized as low, medium, or high
and may be defined as shown in Table 10.3.
The decision with regard to what is considered to be an acceptable level of risk
is up to the discretion of the manufacturer. Risks should always be reduced to
the lowest level practical, bearing in mind the state of the art and the benefits of
accepting the risk and the ability to further reduce the risk. Keep in mind that
practicality has two components: technical practicality and economic practical-
ity. Technical practicality refers to the ability to reduce the risk regardless of cost.
Economic practicality refers to the ability to reduce the risk without making the
device an unsound economic proposition. These decisions usually involve making
trade-offs between accepting risks and the availability of treatments or diagnosis.
As stated earlier, the process of identifying characteristics of the device that could
have an impact on safety, identifying the associated hazards, and then estimating
the probability that the event will occur and the severity if it does in order to deter-
mine the risk level is what is referred to as performing a risk analysis. A simple
way of performing and documenting a risk analysis is provided in Appendix G.
OK, so now that you have determined the risk level, you need to evaluate the
risk to determine if it is acceptable and/or whether you need to do something to
Table 10.3 Risk Levels

Risk Level Descriptive
Low Risk may be considered acceptable in view of the benefits.
Medium Risk must be reduced to the lowest level practical.
High Risk must be reduced to acceptable levels. This may require redesign of the device.
92
Risk management
eliminate the risk or reduce it to an acceptable level. There are a few different
ways in which you can reduce the risks associated with a medical device. Risk
control measures may be taken to reduce the severity of the harm or reduce the
probability of occurrence of the harm, or both. Some regulatory schemes pre-
scribe a fixed hierarchy for controlling risk that should be examined in the fol-
lowing order:
1. By direct safety means: Modify the device design to remove a hazard or
reduce its consequences.
2. By indirect safety means: Add protective measures or safeguard against
the hazard. For example, restrict accessibility (e.g., for radiation hazards),
shield users from the hazard by means of a protective cover (e.g., like
when you go in to get an X-ray), have a backup mechanism in case of
failure, use automatic cutoff or safety valves, or use visual or audible
alarms to alert the operator to hazardous conditions.
3. By redefining the intended use: Modify the use of the device to pre-
clude the hazard.
4. By descriptive safety means: Warn the operator of the hazard via warn-
ings in the labeling (see following text), restrict the period or frequency of
use of the device, or restrict the application, lifetime, or environment by
providing training to users and specifying necessary maintenance and
maintenance intervals, maximum expected product service life, or how
to dispose of the device properly.
Note that reducing the level of risk by descriptive safety means should be consid-
ered as a last resort. You should always try to fix potential problems and hazards
rather than put bandages on them. A bandage approach such as adding a warning
to an instruction for use (IFU) or reformatting the IFU rarely effectively prevents
use errors, as there is no assurance that the users will even read it. A combina-
tion of strategies is recommended. I saw a demonstration of this not too long ago.
A friend was doing rounds with a nurse in a veteran’s hospital. The nurse was
to inject insulin into a diabetic patient and was using a new type of device. The
nurse, however, did not bother to read the IFU because IFUs are typically just
thrown in a drawer somewhere, and she didn’t have time to go find it. My friend
said she watched the medicine spread out underneath the skin rather than go
into the vein. She was certain of this because of the change in coloration under
the skin and her professional experience. The nurse then proceeded to mark the
patient’s chart to show that the medication had been given and was about to go
on her way. Luckily my friend, who is a very well-educated medical professional,
insisted that the nurse take another look and remedy the situation. But had she not
noticed the error herself, the patient’s chart would have shown that the medica-
tion had been given to the patient, which would have left the professional staff in
a quandary if the patient began to exhibit symptoms related to a drop in insulin.
As you can see, even if you put all the detail in the world into the IFU, there is no
93
guarantee that anyone is going to read it. Consequently, even though your device
may be the latest and greatest thing and may be way better than the competition’s
device, if your device isn’t designed with the user in mind, and correct use of the
device isn’t known or shown to the user, the patient may suffer the consequences.
Keep in mind that the actions needed or taken to reduce risk may entail a great
deal of work and possible redesign of the product itself. It seems almost conde-
scending to mention it, but there are risks associated with most medical treat-
ments, and there may be risks and hazards associated with the use of a particular
device. However, these major risks are almost always known to the people doing
the design development and are either eliminated or minimized by the design
itself or handled in the labeling if the associated risk is outweighed by the benefits
delivered to the patient when using the device. Most engineers have completed a
reliability analysis related to the use of a particular device. They know what will
happen to the patient, the user (if other than the patient), and the surrounding
environment should there be a device failure. What usually needs more attention
is what will happen if someone tries an unexpected use of the product.
Remember, the team has been designing the device for use in a very particular
way and most likely with a specific environment in mind, but someone could use
the device in an entirely different way or in an unexpected environment. Suppose
that you manufacture a skin cleanser that has been formulated into a cream. What
will happen if the end user confuses the cleanser with his toothpaste tube and uses
it to brush his teeth? You may not be able to prevent the occurrence, but have you
done anything to minimize it? Both the development team and the manufacturer
have an obligation to minimize risks associated with the use of the device even if
the end user uses the device inappropriately.
It should be noted at this point that this is not often easy to do, since it is some-
times considered impossible to anticipate every way that a device may be used.
Even when a set of circumstances can be envisioned, it is often difficult to then
estimate how severe that particular hazard may be. But it must be done.
Remember that any action taken to reduce a risk may create a new risk or hazard
or increase the significance of other existing risks. As a result, you need to iden-
tify and evaluate any possible change in risk after implementing a risk control
measure by examining the residual risk. If the level of risk is still not acceptable,
further risk control measures or mitigation may be necessary, and/or a risk-benefit
analysis should be performed to justify the risk.
Once all individual hazards and associated risks have been identified and appro-
priately controlled (i.e., the residual risk is acceptable and/or justified), you need
to determine if the overall or total risk from all sources is acceptable. Just because
the individual risks may all be within the acceptable range, the summation of all
of these risks may not be acceptable. Think of an engineering drawing where
94
Risk management
each part in an assembly has its own individual dimensions and tolerances. If all
of the parts are at their maximum tolerance, the finished assembly or device may
not fit together, or it may no longer meet the user’s needs.
Human factors and the risk management process

A concern of great importance to both the FDA and the medical device com-
munity is the implementation of good human factors practices in the design of
medical devices. The requirement to consider human factors in the design and
development process is implied in the FDA’s Quality System Regulation in para-
graphs 820.30(c), (f), and (g). More specifically, as part of the design controls
process, manufacturers are required to conduct a risk analysis that includes risks
associated with device use.
Human error is typically the cause of most accidents. In the medical device envi-
ronment, however, errors can unfortunately result in serious injuries and even
death. In fact, human error is estimated to cause or contribute to up to 90 per-
cent of accidents both generally and in medical devices.*,† As a result, the design
team’s goal should be to design a device that will be relatively easy and safe to use.
Human factors is the study of how people use technology. Consequently, human
factors should consider the use-related hazards influenced by interactions between
the following:
• Environment
• User (typical and atypical use)
• Device (operating characteristics)
A medical device can be used safely and effectively only if the interaction
between the operating environment, user capabilities, stress levels, and the device
design is considered when the manufacturer designs the device. It is virtually
impossible to design out all user error; however, if you design your device with
the user in mind, it is more than likely that your device will accommodate a wide
range of users working under variable and often stressful conditions, and that it
will be less prone to user error, and will require less training.
* Bogner, M.S. “Medical Devices and Human Error.” In Human Performance in Automated Systems:
Current Research and Trends, edited by M. Mouloua and R. Parasuraman, 64–67. Hillsdale, NJ:
Lawrence Erlbaum, 1994.
† Nobel, J.L. “Medical Device Failures and Adverse Effects,” Pediatric Emergency Care 7 (1991):
120–23.
95
Use-related hazards occur for one or more of the following reasons:*

• The device use requires physical, perceptual, or cognitive abilities that
exceed the abilities of the user.
• The use environment affects operation of the device, and this effect is
not recognized or understood by the user.
• The particular use environment impairs the user’s physical, perceptual,
or cognitive capabilities when using the device to an extent that nega-
tively affects the user’s interactions with the device.
• The device use is inconsistent with user’s expectations or intuition about
device operation.
• The devices are used in ways that were not anticipated.
• The devices are used in ways that were anticipated but inappropriate and
for which adequate controls were not applied.
The best way to control errors is to stop them before they occur by designing
the device in a manner that will not allow the error to occur in the first place.
This requires anticipating and identifying the potential risks associated with both
normal use and misuse and then managing those risks during the design and
development of the device. The FDA identifies four essential steps associated
with this process in its guidance document titled “Medical Device Use-Safety:
Incorporating Human Factors Engineering into Risk Management.” These steps
1. Identify anticipated and unanticipated use-related hazards.
2. Describe how hazardous-use scenarios occur.
3. Develop and apply strategies to control use-related hazards.
4. Demonstrate safe and effective device use (e.g., simulated use testing
or validation).
An effective way of identifying use-related errors is to research the types of
errors associated with similar devices. This information is available in a number
of places (e.g., the FDA’s MAUDE database, the FDA’s Medical Device Recalls
database, the ECRI Institute’s Medical Device Safety Reports database, the
MHRA’s safety information page, etc.). You should include all known use errors
and problems in the risk analysis for a new device and take them into account
when selecting the critical tasks to be evaluated as part of your human factors
analysis (i.e., user validation).
Use-related hazards can be mitigated or controlled by modifying the device user
interface or the abilities of users to use the device. The user interface includes all
aspects of the device with which the user interacts while using it, preparing it for
* “Applying Human Factors and Usability Engineering to Optimize Medical Device Design,” FDA
Draft Guidance, June 22, 2011.
96
Risk management
use (e.g., calibration, setup, unpacking), or performing maintenance (e.g., cleaning,

repairing). It encompasses those parts of the device that users see, touch, and
hear, including the controls and displays, alarms, operating logic, and all manu-
als, labeling, and training materials necessary to operate and maintain the device.
The standard that addresses medical device usability is EN 62366, “Application
of Usability Engineering to Medical Devices.” This standard specifies a process
for analyzing a medical device, specifying its design, and verifying and validat-
ing usability as it relates to its safe and effective use. Annex A of this standard
provides a list of questions that can be used to identify medical device character-
istics associated with usability that could affect safety.
Risk management plan

Remember, your risk management plan should be reviewed at appropriate stages of
your design and development process. This should occur as an element of the design
review process. Design and development reviews should assess the following:
• Have all hazards been identified, has risk been properly assessed, and
have potential risk control measures been identified?
• What is the effectiveness of the risk control measures for individual risks?
• Have design validation activities effectively assessed the overall residual
risk associated with the use of the device by the intended user?
• Have new risk-related issues identified during the design transfer process
been controlled and verified?
97
Chapter 11 Design validation
Why validate?
Validation goes beyond the technical issues of verifying that output meets input
requirements. Validation is needed to demonstrate that the medical device meets
the user’s requirements and the intended use; that is, it is a product the market-
place needs. As a result, its purpose is to provide objective evidence that design
specifications (outputs) confirm predetermined user needs and intended uses,
given expected variations in components, materials, manufacturing processes,
and the use environment.
What is design validation?

Design validation requirements fall under Section 820.30(g) of the FDA’s Quality
System Regulation and under Section 7.3.6 of the ISO 9001 and ISO 13485 stan-
dard. However, before we get into the actual requirements for validation, I think it
is important to define what is meant by the term validation and more specifically
design validation.
• Validation means confirmation by examination and provision of objec-
tive evidence that the particular requirements for a specific intended use
can be consistently fulfilled (21 CFR Part 820.3(z)) (emphasis added).
• Design validation confirms whether the device meets user needs and
intended uses. In other words, “Did I make the right product, and can I prove
it?” rather than “Does the process consistently produce a product meeting
predetermined specifications, and can I prove it?” (i.e., process validation).
To explain the difference between design verification and design validation, let’s
go back to the chocolate chip cookie example. Verification would entail confirm-
ing that you measured out all of the ingredients correctly, added them in the order
that the recipe instructed, and baked the cookies at the temperature indicated and
for the length of time specified. Validation requires that you find out if the peo-
ple you baked the cookies for actually liked your cookies. For example, if your
“intended eaters” are gluten free, vegan, or on a diet, then your cookies are prob-
ably not going to be well received. Furthermore, if your intended eaters are aller-
gic to nuts or like thick and chewy cookies with lots of chocolate chips, and your
cookies have nuts and turned out thin and crispy with few chocolate chips, then
again you have failed to meet the needs of your intended eaters.
99
Design validation requirements

Design validation typically follows and may include design verification activities.
At this point the device has been verified as meeting device specifications, and
now you want to ensure that the device satisfies the user’s needs and intended
uses. Although certain aspects of design validation can be accomplished during
the design verification stage, design verification is not a substitute for design vali-
dation. Design validation will typically involve functional and/or performance
evaluations but not necessarily actual clinical studies and use. Any clinical studies
performed need to be conducted in accordance with national or regional require-
ments and regulations and should not be conducted before the results of appropriate
laboratory and animal testing are completed and have been analyzed and reviewed
and found to be acceptable. For example, the electrical, thermal, mechanical, and
chemical safety of the device can usually be determined by laboratory tests.
Design validation requirements include the following:
• First and foremost, validation activities must be performed in accor-
dance with established procedures and written protocols with clearly
defined or referenced acceptance criteria. Validation activities should
also be identified in the design and development plan.
• Design validation must be performed under defined operating conditions
and on the initial production units, lots, or batches or their equivalents to
ensure proper overall design control and proper design transfer. Testing
should be performed on production units under actual or simulated use
conditions. Note that if a production equivalent unit is used, you need to
document why it is equivalent.
• Validation activities must consider the capability and knowledge of all
relevant parties (i.e., patient, health care worker, physician, etc.) and be
performed for each application or intended use. For example, if you have
developed an ostomy pouch that can be used by patients with a colos-
tomy and patients with a urinary diversion, then the clinical validation of
the design must be demonstrated for both intended uses.
• Validation activities need to address the design outputs of labeling
(e.g., directions for use inclusive of warnings, contraindications and pre-
cautions, and operating instructions including setup and prep, assembly,
inspection and test and application, cleaning and disinfection, steriliza-
tion, maintenance, etc.).
• Validation activities also need to address the adequacy of packaging
(e.g., protects the device from conditions of transport, storage, and
handling), as these components may have significant human factors
implications and may affect device performance in unexpected ways
(e.g., functionality, sterility, shelf life, etc.).
100
Design validation
• Design validation will include software validation, as appropriate. This

includes software used as components in medical devices, software
that is itself a medical device, and software used in production of the
device or in implementation of the device manufacturer’s quality system.
Testing of device software functionality in a simulated use environment
and user site testing are typically included as components of an overall
design validation program for a software automated device.
• As discussed in Chapter 10, a risk analysis is required to ensure that any
known or expected risks are identified and eliminated or reduced to accept-
able levels and to ensure that the overall residual risk meets the overall
acceptability criteria. A final review of the risk analysis should be per-
formed prior to transferring the device design over to production.
• The results of all validations and any actions to resolve discrepancies
must be recorded. Validation records should include identification of the
design configuration, validation methods, date, and individual perform-
ing the validation. This forms part of the Design History File (DHF).
Design validation must be completed prior to delivery or implementation of the

product or device. If a medical device can be validated only following assembly
and installation at the point of use, delivery is not considered to be complete until
the product has been formally transferred to the customer. Provision of the medi-
cal device for the purpose of clinical evaluation and/or study is not considered to
be delivery.
Note, the use of prototypes in clinical studies is acceptable; however, when
prototypes are used on humans, they must be verified as safe to the maximum
extent feasible. Final design validation, however, cannot be done on prototypes
because the actual devices produced and distributed are seldom the same as the
research and development prototypes. Often changes not reflected in the proto-
type are made in the device to facilitate the manufacturing process, and these may
adversely affect device functioning and user interface characteristics. Therefore,
the final verification and validation must include the testing of actual production
devices under actual conditions of use or simulated use conditions in the actual or
simulated environment in which the device is expected to be used.
Design validation is completed when clinical evaluation is complete. Do not con-
fuse a “clinical evaluation” with a “clinical trial.” Clinical evaluation is the assess-
ment and analysis of clinical data pertaining to a medical device in order to verify
the clinical safety and performance of the device. The inputs for clinical evaluation
are primarily clinical data in the form of clinical investigation reports, literature
reports and reviews, and clinical experience (e.g., adverse event reports, recall,
etc.) (GHTF SG5/N1R8).
101
If you are looking to sell your product in Europe, you should be pretty familiar with
the requirements of a clinical evaluation, as a clinical evaluation is required for all
medical devices entering the European market per Annex I of the Medical Device
Directive. Appendix H includes a template for documenting a clinical evaluation.
It is based on Appendix E of the European Commission’s MEDDEV 2.7.1 guid-
ance document on clinical evaluation. A clinical trial, also referred to as a “clinical
investigation” or “clinical study,” is defined as any systematic investigation or study
in or on one or more human subjects, undertaken to assess the safety and/or per-
formance of a medical device with the objective to assess the safety and clinical
performance of the device in question and evaluate whether the device is suitable
for the purpose(s) and the population(s) for which it is intended (GHTF SG5/N1R8).
During design validation, deficiencies in original assumptions (e.g., device specs
and outputs) regarding user needs and intended uses may become apparent.
Design validation may also uncover new risks or hazards. As a result, any actions
taken to resolve deficiencies need to be addressed and resolved prior to the trans-
fer of the device design to production.
Including validation activities in a traceability matrix helps to demonstrate how
user needs were translated into design inputs and then linked to the validation
activities. Each test should link to a test report or study protocol and its final report.
Typical validation activities

Validation activities may include any or all of the following:
• Clinical studies and trials conducted through Institutional Review
Boards (IRBs) and with an Investigational Device Exemption (IDE)
(For nonsignificant risk devices, IRB approval is usually sufficient.)
• 510(k)/PMA historical database search for predicate (“substantially
equivalent”) devices
• Stability studies to determine device shelf life
• Clinical evaluations in clinical or nonclinical settings (market evaluation)
• Literature search (published journal articles)
• Review of labels and labeling for usability and ease of understanding
• Evaluation of product packaging for the protection of the device during
the customary conditions of handling
• Simulated use testing
• Transit trials to determine product packaging stability
• Performance tests and functional tests by the user
• Biocompatibility tests (irritation, sensitization, cytotoxicity, etc.)
• Software validation (beta testing)
• Risk analysis from the user perspective
102
Design validation
Risk assessment of medical device materials

and the finished device
Evaluation of any new device intended for human use will require data from
systematic testing to ensure that the benefits provided by the final product will
exceed any potential risks produced by the device materials. Therefore, the selec-
tion and evaluation of materials and devices intended for use in humans require a
method of assessment to establish biocompatibility and safety. In the design inputs
section of this book, we identified the need to define the biological characteristics
for a medical device and discussed some of the factors that needed to be con-
sidered when selecting device materials and components, for example, intended
clinical use of the device, duration of contact, and degree of invasiveness. At this
stage in the development process, you need to validate whether the materials and
components that you have chosen are safe and effective for the finished device’s
intended use (i.e., assess risk). The next chapter will look at assessing the biocom-
patibility of materials and the finished device in more detail.
103
Chapter 12 Biocompatibility
Ensuring that medical devices and their components and materials are biocom-
patible is an essential element of any design control program. Biocompatibility is
generally determined by using tests that answer two fundamental questions:
1. Is the material safe?
2. Does it have the necessary physical and mechanical properties for its
proposed function?
A biomaterial is usually a complex entity, and the material toxicity is affected by
both physical and chemical properties. Toxicity from a biomaterial or polymer
formulation often comes from components that migrate to the surface and are
extracted from the material. Material testing is performed to determine the toxic-
ity of the material, if there are any leachable substances, and if the material or
device is subject to degradation over time and in different environments.
Biocompatibility cannot be defined by a single test. As a result, it is necessary to
test as many biocompatibility parameters as possible. It is also important to test
as many samples of the material as possible. Suitable positive and negative con-
trols should be used and produce a standard response in repeated tests. The use
of an exaggerated challenge, such as using higher dose ranges and longer contact
durations or multiple insults that are more severe than the actual use condition, is
important to ensure patient safety.
Most of the biocompatibility tests to establish acute toxicity are short-term tests.
Data from these short-term tests should not be overextended to cover the areas
where no test results are available. Biocompatibility testing should be designed to
assess the potential adverse effects under actual use conditions or specific condi-
tions close to the actual use conditions. The physical and biological data obtained
from biocompatibility tests should be correlated to the device and its intended use.
Accuracy and reproducibility of these tests will depend on the method and equip-
ment used and often on the investigator’s skill and experience.
There are several toxicological principles that you should consider before plan-
ning biocompatibility testing. Biocompatibility depends on the tissue that contacts
the device. For example, the biocompatibility requirements for a blood-contacting
device would be different from those applicable to an external urinary catheter.
The degree of biocompatibility assurance also depends on the degree of invasive-
ness and the duration of contact with the human body. For example, some materi-
als, such as those used in orthopedic implants, are meant to last for a long time in
the patient. In this case a biocompatibility test needs to show that the implant does
105
not adversely affect the body during the long period of use. The possibility of bio-
degradation of a material or device should also not be ignored. Biodegradation by
the body can change an implant’s safety and effectiveness. For example, the mate-
rials leached from plastic used during a single hemodialysis procedure may be
very low, but the patient who receives dialysis three times a week may be exposed
to a total of several grams during his or her lifetime. Therefore, the cumulative
effects should also be assessed when appropriate.
It is also important to note that two materials having the same chemical compo-
sition but different physical characteristics, for example, particle size, may not
induce the same biological response. Past biological experience with seemingly
identical materials is also not necessarily a guarantee of biocompatibility in a
new application. Toxicity may come from leachable components of the material
because of differences in formulation and manufacturing procedures.
The challenge of biocompatibility testing is to use existing data as far as feasible
to reduce the degree of unknowns and to help make the logical decisions. The
hazard presented by a substance with its inherent toxic potential can be truly
known only when the material is actually exposed to a patient. Therefore, risk
is a function of toxic hazard and exposure. The safety of any materials that may
migrate from a device or be contained in the device or on its surface can be evalu-
ated by determining the total amount of a potentially harmful substance, estimat-
ing the amount reaching the patient’s tissues, assessing the risk of exposure, and
performing a risk versus benefit analysis. When the potential harm from the use
of biomaterial is identified from the biocompatibility tests, this potential must be
compared against the availability of an alternate material.
Regulatory aspects of biocompatibility

An assessment of toxicological risks is needed to ensure biological safety. The
main safety aim is that the device will not compromise the clinical condition or
safety of the patient or user or other persons, “provided that any risks which may
be associated with their use constitute acceptable risks when weighed against
the benefits to the patient.” Three basic types of information are required for a
toxicological risk assessment:
1. The chemical nature of the materials (including the toxicity of ingredients)
2. Prior use of the materials
3. Biological safety test data*
The ISO 10993-1 Standard and the FDA’s Blue Book Memorandum G95-1 include
a biological evaluation test matrix that designates the type of testing needed for
* Medicines and Healthcare Products Regulatory Agency, “Guidance on the Biological Safety
Assessment,” London, January 2006.
106
Biocompatibility
Table 12.1 FDA’s General Program Memorandum—G95-1, Attachment A. Initial

Evaluation Tests for Consideration
BIOLOGICAL TESTS
DEVICE CATEGORY Long Test
Short Test Duration
Duration
In-Vitro In-Vivo
Contact
Sub-chronic Toxicity
Pyrogenicty (Rabbit)
Duration
Hemocompatibility
Chronic Toxicity
1=Limited
Carcinogenicity
Acute Systemic
(<24 hr)
Implantation
Genotoxicity
Sensitization
Body Contact Cytotoxicity
2=Prolonged
Hemolysis
Irritation
Toxicity
(24hr –30days)
3=Permanent
(>30 days)
External Intact Skin 1
Devices 2
3
Intact 1
Mucous 2
Membranes 3
Breached 1
Surfaces 2
3
External Blood Path 1
Communicating Indirect 2
Devices 3
Tissue°Bone/ 1
Dentin 2
Communicating 3
Circulating 1
Blood 2
3
Implant Tissue/Bone 1
Devices 2
3
Blood 1
2
3
- ISO evaluation tests for consideration

- Additional tests which may be applicable
° - Tissue includes tissue fluids and subcutaneous spaces
various medical devices (see Table 12.1). Whether you choose to use the FDA’s
modified matrix or the ISO 10993-1 matrix, know that both provide only a frame-
work for the selection of tests and not a checklist of every required test. Again,
the number and types of specific safety tests required to assess product safety and
compliance will be dependent on the individual characteristics of the finished
device, its component materials, and its intended clinical use. The FDA’s Blue
Book Memorandum G95-1 also includes a chart to assist manufacturers in identi-
fying the toxicity tests that may be required for a 510(k) (see Figure 12.1).
Medical device manufacturers need to also be careful about using “generally rec-
ognized as safe” (GRAS) substances. GRAS substances can be found in 21 CFR
Part 182 and are applicable to food. As a result, any material or substance in
the GRAS list cannot automatically be assumed as safe and effective for medi-
cal devices.
107
Start BIOCOMPATIBILITY
REQUIREMENTS MET
Does the
device contact the No
body directly or
indirectly?
Yes
Is the
Same Same Same
material same as Same body
Yes manufacturing Yes chemical Yes Yes sterilization Yes
in the marketed contact?
processes? composition? method?
device?
No No
No No
No Yes
Acceptable
No Yes
justification or
test data?
Is the Is the Does it contain

device material a material metal, any toxic substances; No
No Yes
polymer? metal alloy or e.g., Pb, Ni, Cd, Zr?
ceramic?
Yes Yes
No
Consult device specific Adequate
tox profile for No justification
appropriate tests provided?
Master File, when

Consult referenced, has
toxicologist for Yes
No Tox Profile acceptable tox data
appropriate tests, applicable to the device
if necessary
No
Submission contains acceptable

Toxicologist
tox data and/or justification or risk
Yes concurrence,
assessment for not conducting
Consult modified ISO as necessary
appropriate tests
matrix for suggested
tests No Yes
TOXICOLOGICAL DATA BIOCOMPATIBILITY

REQUIRED REQUIREMENTS MET
Figure 12.1 Biocompatibility flowchart for the selection of toxicity tests for 510(k)s.
Biocompatibility testing programs

Manufacturers need to develop a biocompatibility test program that involves
some or all of the following activities:
• Gather available data on the materials and the finished device
• Complete a chemical characterization of the materials
• Identify rapid, sensitive, cost-effective screening tests
108
Biocompatibility
• Monitor incoming raw materials, the final product, and the manufactur-
ing process
• Define the product release tests and the pass–fail criteria.
In addition, manufacturers should select reliable, state-of-the-art bioassays to
demonstrate safety for the intended use of the device.
Regulatory issues are equally as complex as the scientific considerations. Some
regulatory issues are as follows:
• Anticipated human exposure to the device
• Biological resistance to chemical insult
• Testing variables
• Species differences
• Relevance of the test to the device and its use
• Substantiating the accuracy and predictive values of the test
• Proper interpretation
• The use of no observed biological responses (negative results) to chemi-
cal insult(s) to predict biocompatibility
Undesirable extremes should be avoided during the design of biocompatibility
testing programs. As indicated previously, it is important not to attempt to demon-
strate biocompatibility by a single test. More importantly, your biocompatibility
program should be based on the intended use of the device. Performing a large
number of tests with a number of test samples is as important as the accuracy,
specificity, significance, and economy of the testing. Medical devices vary widely
in their types, uses, functions, exposures, and contact ions. Therefore, one test
system cannot accommodate all applications. Manufacturers do not, however,
have to repeat extensive biocompatibility testing programs simply to fill the files
with evidence of safety if the device is constructed of well-known, previously
well-tested materials or only uses materials with a long, safe history for the same
intended use. Some tests may be inappropriate or unnecessary for the intended
use of the device. For example, pyrogenicity tests are appropriate for intravenous
catheters but not for topical devices that contact only intact external surfaces.
Phases of biocompatibility testing

Good biocompatibility testing programs for medical devices should follow three
levels of biocompatibility testing (see Table 12.2).
• Level I tests provide information on the physical, chemical, and toxico-
logical characterization of materials. Level I tests are generally not diffi-
cult to perform, require readily available equipment, and are considered
the initial characterization of biomaterials and serve as the foundation for
109
Table 12.2 Biological Tests: Biomaterials

Level I
Acute Screening tests Cytotoxicity
USP biological tests
Hemolysis
Other tests Irritation
Sensitization
Implantation
Hemocompatibility
Mutagenicity
Reproductive
Pyrogenicity
Subchronic and Irritation
chronic Sensitization
Implantation
Hemocompatibility
Reproductive and developmental
Level II
Chronic Implantation
Reproductive and developmental
Carcinogenesis
Additional tests based on Level I (e.g., pharmacokinetics)
Level III Clinical studies
all other testing conducted. These tests have broad application and low
resolution and are recommended for screening during the early stages of
development and continued monitoring of new lots of materials.
• Level II tests include acute toxicity tests and some subchronic and
chronic tests, if needed. Level II testing is basically an extension of
Level I and involves a variety of in vitro and in vivo testing of devices
that require additional testing based on the Level I screening test results.
This includes extensive preclinical tests such as pharmacokinetic stud-
ies and lifetime bioassays or special testing due to the complexity and/or
intended use of the device.
• Level III testing is the highest level of testing for a medical device and
involves clinical studies. This is especially important for implantable
devices. Manufacturers should determine whether to proceed to Level II
or Level III testing depending on the results of Level I tests.
110
Biocompatibility
Screening tests
There is a risk in testing finished devices without first developing data on com-
ponent materials. If an adverse event occurs, it may prove difficult to determine
which component is causing the problem. Screening device materials minimizes
this risk, allows a rapid and relatively inexpensive rejection of incompatible mate-
rials at an early stage, and can be used as a monitoring device of the manu-
facturing process. Cytotoxicity tests, intracutaneous and/or skin irritation tests,
and hemocompatibility tests are good candidates for screening material safety. In
addition, there are many cell or tissue culture methods that can be custom tailored
to biomaterials. Unless clearly contraindicated, both direct contact tests and tests
with extracts with polar and nonpolar extraction media should be considered.
Note these screening tests are intended not to demonstrate that the material is
biocompatible but to reject grossly incompatible materials.
Systemic toxicity
The risk of a medical device causing systemic toxic reactions during short-term,
long-term, or continuous application on or in the human body depends mainly on
the risk that relevant quantities of toxic substances may be released from the prod-
uct to become systemically available during its intended use. Systemic toxicity
refers to the way the animal/human body is affected as a whole. In systemic
toxicity testing, the animal is exposed to the test article or the extract of the test
article. Four categories of systemic toxicity testing exist, and each is based on the
duration of exposure:
• Acute toxicity: a toxic effect resulting from a single, short-term (24 to 72
hours) exposure to a chemical substance.
• Subacute toxicity: a toxic effect that results from a single dose or mul-
tiple doses to a chemical substance for 14 to 28 days (~ 1 month).
• Subchronic toxicity: a toxic effect resulting from prolonged exposure to
a chemical substance for up to 90 days (1 to 3 months).
• Chronic toxicity: a toxic effect from continuous and prolonged exposure
for over 90 days (typically 6 to 12 months).
Toxicity testing should be used in conjunction with chemical and physical analysis
to prevent costly development of unsatisfactory materials. Most medical devices
will not require chronic toxicity testing. The category of testing required should
be similar to the clinical intended use of the medical device.
The most common cause of acute toxicity of biomaterial is the presence and
leachability of toxic substances. Therefore, the detection of leachable substances
should be the principal focus of the test systems.
111
Tests for acute toxicity include but are not limited to the following:
• ISO 10993-11: Tests for Systemic Toxicity
• OECD 423: Acute Oral Toxicity
• USP <88>: in vivo Biological Reactivity Tests
• ASTM F-750: Standard Practice for Evaluating Material Extracts by
Systemic Injection in the Mouse
Acute systemic toxicity tests use extracts of the device or device material to detect
leachables that produce systemic (as opposed to local) toxic effects. The extracts of
the test material and negative control blanks are injected into mice (intravenously
or intraperitoneally, depending on the extracting media). The mice are observed
for toxic signs just after injection and at four other time points. The materials
biocompatibility matrix recommends this test for all blood contact devices. It may
also be appropriate for any other device that contacts internal tissues.
Subchronic toxicity tests are used to determine potentially harmful effects from
longer-term or multiple exposures to test materials and/or extracts during a period
of up to 10 percent of the total life span of the test animal (e.g., up to 90 days in
rats). Actual use conditions of a medical device need to be taken into account
when selecting an animal model for subchronic toxicity. Subchronic tests are
required for all permanent devices and should be considered for those with pro-
longed contact with internal tissues. Subchronic systemic toxicity tests include
ISO 10993-11.
A fourth type of systemic toxicity testing is pyrogenicity testing. It is used to
determine whether a test article has the ability to cause a fever-like response when
introduced into the blood. Devices in contact with circulating blood or cerebro-
spinal fluid are required by the FDA to be nonpyrogenic, as are intraocular lenses.
In the United States there are two types of tests for pyrogenicity: one is in vitro,
and the other is in vivo.
• The bacterial endotoxin (LAL) test is an in vitro test that detects pyro-
gens that are bacterial in origin, called endotoxins. The LAL test is used
for lot release testing and must be validated for each device or material
(USP <85>: Bacterial Endotoxins Test/ISO 10993-11).
• The rabbit pyrogenicity test is an in vivo biocompatibility test that detects
bacterial endotoxins and material-mediated pyrogens that may be found in
test materials or extracts (USP <151>: Pyrogen Test/ISO 10993-11).
Cytotoxicity and cell cultures

Cell culture tests including cytotoxicity are a good predictor of biocompatibility
when used together with other appropriate tests. Cell culture tests determine the
lysis of cells (cell death), the inhibition of cell growth, and other toxic effects
on cells caused by materials either by direct contact or by leachable substances
112
Biocompatibility
(extracts). Several highly specialized cell culture techniques are available to mon-
itor the biocompatibility of the raw materials used in manufacturing the device or
auditing the manufacturing process.
Cytotoxicity testing provides a rapid, inexpensive, reliable, convenient, sensitive,
and reproducible screening method to detect, at an early stage in the testing pro-
cess, cell death or other serious negative effects on cellular functions. Test results
should be used for evaluating and screening biomaterials prior to conducting
in vivo tests. If a sample is going to fail any of the biocompatibility tests, it is said
that 90 percent of the time it will fail the cytotoxicity test first. Cytotoxicity testing
is not a pass–fail test. Failure in cytotoxicity is generally grounds for performing
a confirmatory test such as an implantation or intracutaneous reactivity test.
There are many cytotoxicity test methods available for testing biomaterials. These
tests can be divided into three categories: tests using extracts, direct contact tests,
and indirect contact tests. Which test(s) to be performed will depend on the nature
of the sample to be evaluated, the potential site of use, and the intended use. The
three common in vitro tests discussed in ISO 10993-5 include the following:
• Minimum Essential Medium (MEM) Elution Assay
• Direct Contact Assay
• Agar Diffusion/Overlay Assay
Evaluation using extracts

Extracts of test devices and materials are tested by exposure to the cell culture
(e.g., L929 mouse fibroblast cell line). The presence of cytotoxic leachates is
indicated by loss of cell viability. Examples of cytotoxicity test methods using
extracts include the following:
• Fluid medium tissue culture assay (MEM Elution) evaluates the cellular
damage caused by the test extract on a confluent monolayer culture. This
method uses different extracting media and extraction conditions to test
devices according to actual use conditions or to exaggerate those condi-
tions. It is appropriate for high-density materials. After preparation, the
extracts are transferred onto a layer of cells and incubated for 24 hours or
more in the MEM. Following incubation, the cells are examined micro-
scopically for malformation, degeneration, and lysis of the cells.
• The inhibition of cell growth assay (Growth Inhibition Test) is a more
informative test requiring more time and skill and can be used for evalu-
ation of medical device plastics or intraocular lenses. Distilled water
extract is incorporated into the tissue culture medium and inoculated with
the cells in the tissue culture tubes. After the cells have incubated for
72 hours, the extent of cell growth is determined by the total protein
assay on the cells removed from the individual tubes.
113
• The cloning efficiency assay (Colony Formation Cytotoxicity Test) is even

more informative, sensitive, and quantitative and requires even more skill.
The cloning efficiency assay’s procedure and endpoint is similar but is
more accurate, sensitive, and direct than cell growth inhibition or fluid
medium methods. The cloning efficiency assay normally uses a Chinese
hamster ovary cell line and a single-cell cloning technique to estimate
the toxic insult induced in cloning efficiency. The cytotoxic effect of the
extract is determined by measuring the ability of the treated cells to form
colonies during seven subsequent days of incubation. The cloning effi-
ciency of the treated cultures is compared to that of the control. The agar
overlay method can be used to evaluate the toxicity of the extracts, but
it is primarily used for the direct contact cytotoxicity tests of the solid
test sample.
Evaluation by direct contact

Several tests are available to test cytotoxicity by direct contact. The direct contact
method is recommended for low-density materials, such as contact lens polymers.
Using this method, a piece of test material is placed directly onto cells growing on
culture medium. The cells are then incubated for twenty-four hours. During the
incubation of the cells, leachable chemicals in the test material can diffuse into
the culture medium and contact the cell layer. Reactivity of the test sample is indi-
cated by malformation, degeneration, and lysis of cells around the test material.
Direct contact methods include but are not limited to the following:
• ASTM F 813: Standard Practice for Direct Contact Cell Culture
Evaluation of Materials for Medical Devices
• ASTM F 895: Standard Test Method for Agar Diffusion Cell Culture
Screening for Cytotoxicity
• ASTM F 1027: Standard Practice for Assessment of Tissue and Cell
Compatibility of On Prosthetic Materials and Devices
Evaluation by indirect contact

The agar diffusion test may be performed using extracts or directly. The agar overlay
tissue culture method (agar diffusion assay) is appropriate for high-density materi-
als, such as elastomeric closures. In this method, the solid test sample is placed on a
layer of agar containing a stain on top of a monolayer of L-929 cells and incubated
for 24 hours. The leachable materials can diffuse into the agar and contact the cell
layer. Toxicity is indicated by a loss of viable cells around the test device.
Proper cytotoxicity testing must include at least one test with extract and one
direct contact test.
114
Biocompatibility
USP biological tests

To test biological reactivity, manufacturers often use USP procedures to evaluate
the biological risks of polymeric materials such as elastomers, thermoplastics,
and duroplastics. These tests are primarily applicable to the materials used to
manufacture a medical device rather than the finished medical device. These tests
include the USP <87> in vitro Biological Reactivity Tests and USP <88> in vivo
Biological Reactivity Tests (used to rate plastics in Classes I–VI). However, the
USP methods have largely been superseded by ISO 10993, and the USP test series
for plastic materials does not replace the evaluation tests requested in ISO 10993-1.
USP <87> in vitro Biological Reactivity Tests include the agar diffusion test,
MEM Elution, and the direct contact test that are found in ISO 10993-5 with some
minor differences.
USP <88> in vivo Biological Reactivity Tests include the following:
• The systemic injection test and intracutaneous test are designed to deter-
mine the biological response of animals to plastics and other polymers
by single-dose injection of specific extracts prepared from a sample.
• The implantation test is designed to evaluate the reaction of living tissue
to the plastic by the implantation of the sample into animal tissue. This
test is used to test the suitability of materials intended for use in fabri-
cating containers and accessories thereto, for use in parenteral prepara-
tions, and for use in medical devices, implants, and other systems.
The class plastics tests (i.e., USP <88>) consist of various combinations of the
tests using one or more combinations of four extracting media. Class plastics
tests have some value in a biocompatibility testing program, but a full Class VI
test is rarely needed for a medical device. As a general rule, the FDA’s Blue Book
Memorandum and ISO 10993 documents take a broader and more thorough
view of biocompatibility than does the US Pharmacopoeia, and they supersede
the USP for evaluating which studies to submit to the FDA in support of prod-
uct registration.
Irritation tests
Once in vitro testing has been completed (e.g., cytotoxicity testing), in vivo
biological testing can be done based on the device’s intended use. Irritation or
intracutaneous tests estimate the irritation and sensitization potential of devices,
materials, and/or extracts using appropriate site or implant tissue such as skin and
mucous membranes in an animal model and/or human. The route of exposure
(skin, eye, mucosa) and duration of contact should be appropriate to the antici-
pated clinical use of the device. For example, if the product is a contact lens case,
then ocular irritation should be performed.
115
Irritation and intracutaneous reactivity tests include but are not limited to the
following:
• USP <88>/ISO 10993-10/ASTM F-749: Intracutaneous Reactivity Test
• ISO 10993-10/OECD 404: Dermal Irritation (Draize Skin Test)
• ISO 10993-10: Mucosal Irritation Tests (vaginal, rectal, oral, penis)
• ISO 10993-10/OECD 405/FDA: Ocular Irritation Test (Draize Eye Test)
Testing of intracutaneous reactivity, dermal irritation, and ocular irritation are
the three most common irritation test procedures. However, depending on the
intended use of a medical device, other test procedures may be considered.
The intracutaneous test is a sensitive acute toxicity screening test for detecting
potential local irritation by using extracts of the test material and blanks and inject-
ing them intradermally. The injection sites are scored for erythema and edema
(redness and swelling). This procedure is recommended for devices that will have
externally communicating or internal contact with the body or body fluids. It
reliably detects the potential for local irritation due to chemicals that may be
extracted from a biomaterial.
The primary skin irritation test is performed to demonstrate the potential toxicity
of the device through its contact with the skin. As such, it should be considered
for topical devices that have external contact with intact or breached skin. In this
procedure, the test material or an extract is applied directly to intact and abraded
sites on the skin of a rabbit. After a 24-hour exposure, the material is removed,
and the sites are scored for erythema and edema.
Mucous membrane irritation tests are recommended for devices that will have
externally communicating contact with intact natural channels or tissues. These
studies often use extracts rather than the material itself. Some common proce-
dures include vaginal, cheek pouch, and eye irritation studies.
Sensitization tests
Sensitization studies help to determine whether a material contains chemicals
that cause adverse local or systemic effects after repeated or prolonged exposure
(i.e., an allergic response). Sensitization is a delayed hypersensitivity reaction
(an immune response that takes a couple of days to develop) and is manifested in a
variety of clinical complications. Studies to determine sensitization potential may
be performed using either specific chemicals from the test material, the test mate-
rial itself, or, most often, extracts of the test material. Guinea pigs are especially
suitable for the evaluation of possible sensitizing properties of medical devices,
raw materials, or extracts.
Sensitization tests include but are not limited to the following:
116
Biocompatibility
• ISO 10993-10/OECD 406/ASTM F-720: Guinea Pig Maximization Test

• ISO 10993-10/OECD 406: Murine Local Lymph Node Assay
• ISO 10993-10/OECD 406: Closed Patch Test (Beuhler)
The guinea pig maximization test (Magnusson- Kligman Method) is recom-
mended for devices that will have externally communicating or internal contact
with the body or body fluids. In this study the test material is mixed with complete
Freund’s adjuvant (CFA) to enhance the skin sensitization response. Guinea pigs
are treated intradermally and then dermally (topically) with the material extracts.
This method is considered to be a more sensitive test than the others.
The murine local lymph node assay (LLNA) determines the quantitative increase
in lymphocytes in response to a sensitizer. If a molecule acts as a skin sensitizer, it
will induce the epidermal Langerhans cells to transport the allergen to the drain-
ing lymph nodes, which in turn causes T-lymphocytes to proliferate and differ-
entiate. Using this method, mice are treated dermally with the material extracts
followed by an in vitro analysis of the lymphytic cells.
The closed patch test involves multiple topical doses that are applied topically and
is recommended for surface contacting devices.
Hemocompatibility tests
Hemocompatibility testing is required for any medical device or material that
comes into contact (directly or indirectly) with blood or blood components. In
practice, few materials have consistently shown good hemocompatibility. All
materials are to some degree incompatible with blood because they can either
disrupt the blood cells (hemolysis) or activate the coagulation pathways (throm-
bogenicity) and/or the complement system.
The ISO 10993-4 standard defines the categories of evaluations to be performed
for devices or components that come into contact with blood, and outlines which
types of medical devices need to have which test performed in Table 12.1. The
FDA, however, doesn’t agree with the chart but provides no guidance for testing.
The five categories of hemocompatibility testing outlined in ISO 10993-4 are throm-
bosis, coagulation, platelets, hematology, and complement system (immunology).
With the exception of thrombosis, which is in vivo, all of the other tests are
in vitro assays.
In the thrombogenicity (thrombosis) test, the test article is implanted into the
vasculature of an animal. After a given period of time, the implanted vessel is
removed, and the test article is observed for clot formations. Because thrombo-
genicity tests are usually difficult, controversial, and expensive, manufacturers
should contact the FDA to choose the proper model and test protocol.
117
The four remaining tests are carried out in test tubes and evaluate specific actions:
whether the test article has an effect on the blood’s ability to clot or coagulate,
can regulate an immune response, or can damage the cellular components of
the blood.
The hemolysis assay is recommended for all devices or device materials except
those that contact only intact skin or mucous membranes. This test measures the
damage to red blood cells when they are exposed by direct contact to materials or
their extracts and compares it to positive and negative controls. A hemolysis test
is a rather rapid test that requires simple equipment and provides easily interpre-
table quantitative results. The ASTM F-756 Standard Practice for Assessment of
Hemolytic Properties of Materials can be used to measure the hemolytic potential.
Coagulation assays measure the effect of the test article on human blood coag-
ulation time. They are recommended for all devices with blood contact. The
prothrombin time (PT) assay is a general screening test for the detection of coag-
ulation abnormalities in the extrinsic pathway. The partial thromboplastin time
(PTT) assay detects coagulation abnormalities in the intrinsic pathway.
Complement activation testing is recommended for implant devices that contact
circulatory blood. This in vitro assay measures complement activation in human
plasma as a result of exposure of the plasma to the test article or an extract. The
measure of complement actuation indicates whether a test article is capable of
inducing a complement-induced inflammatory immune response in humans.
The platelet test is performed to see how well platelets clump together and cause
blood clots. Using this method, a blood sample is obtained from an animal that
has been exposed to the intact material. The number of platelets per mm3 is
then determined.
Other blood compatibility tests (e.g., erythrocyte stability, protein absorption) and
specific in vivo studies may be required to complete the assessment of material–
blood interactions.
Implantation tests
Implantation tests are performed to determine the local and/or systemic effects of
implanted devices or materials. In implantation testing, the test material is surgi-
cally implanted or placed into the body or appropriate tissue of test animals. The
tissue chosen for implantation should be tissue that is most suitable for the test
article. When in doubt, do the muscle implant test.
The implantation study should reflect the intended clinical use and the intended
duration of contact with the body (e.g., short term or long term). Multiple time
points are conducted. For a permanent implant, a minimum short term of 1 to
4 weeks should be performed, and a long term should be conducted over 12 weeks.
118
Biocompatibility
Particular consideration should be given to the time-point selection when testing

resorbable or biodegradable materials. These time points should be chosen based
on the degradation rate of the test material.
Examples of implantation tests include the following:
• USP <88>/ISO 10993-6: Intramuscular Implantation
• ISO 10993-6: Subcutaneous Implantation
• ASTM F763: The Standard Practice for Short-Term Screening Implant
Materials
• ASTM F981: The Standard Practice for Assessment of Compatibility
Biomaterials for Surgical Implants with Respect to Effect of Materials
on Muscle and Bone
Mutagenicity tests (genotoxicity)

Genotoxicity testing evaluates a test article’s ability to cause damage to DNA, genes,
and chromosomes, thereby increasing the risk of cancer or inheritable defects.
Tests for genotoxicity are usually performed before considering tests for carcino-
genicity or reproduction toxicity because there is a significant correlation between
mutagenicity and carcinogencity, and reproduction toxicity is assumed. Most, if
not all, carcinogens are mutagens, but not all mutagens are human carcinogens.
Mutations may include a point mutation along a strand of DNA, damage to the
overall structure of DNA, or damage to the structure of the chromosome (which
contains DNA). Therefore, the material’s ability to cause point mutation (gene
mutations), chromosomal change (aberrations), or evidence of DNA damage
should be tested as a series or battery of tests.
Devices with long-term exposure (i.e., those that come in contact with the body
for over 30 days and anything that enters the body for more than 24 hours) gen-
erally require an Ames test and two in vivo methods, usually the chromosomal
aberration and mouse micronucleus tests. Devices with less critical body contact
may be able to be tested with only the Ames test.
ISO 10993-3 recommends that genetic toxicity be assessed with at least three
assays. Two of these assays should use mammalian cells as the test system, and
the test should cover the three levels of genotoxic effects: DNA effects, gene
mutations, and chromosomal aberrations. The testing can be done using the test
material extract or dissolved material.
Mutagenicity (genotoxicity) tests include the following:
• ISO 10993-3/OECD 471: Ames Bacterial Reverse Mutation Assay (Ames
Mutagenicity Assay)
• ISO 10993-3/OECD 476: Mouse Lymphoma Assay
119
• ISO 10993-3/OECD 473: Chromosome Aberration Test

• ISO 10993-3/OECD 474, 475: Mouse Bone Marrow Micronucleus Test
(Limit Test)
The Ames mutagenicity test is the most common test. This test detects point muta-
tions by using five strains of the bacteria Salmonella typhimuriun. A positive
result is seen by the growth of revertant bacteria (bacteria that reversed back to
wild-type bacteria).
The mouse lymphoma test uses a mutated mouse cancer cell line in which a par-
tially damaged gene exists. When this gene is completely damaged, this mutated
cell line is able to survive and replicate in the presence of a particular chemical.
The cells are incubated within that chemical after exposure to the test article. If
an increase in viability is detected, this indicates the test article was able to totally
inactivate or damage the gene.
The chromosomal aberration test typically uses cells derived from Chinese ham-
ster ovaries (CHO cells). These cells are encouraged to undergo mitosis, or cell
division. They are then exposed to the test article and a chemical that stops the
mitosis in the metaphase stage of mitosis. This is the stage in which all chromo-
somes are visible. At least 200 metaphase cells are evaluated for visible damage
to the chromosomes.
The mouse micronucleus test is an in vivo test in which mice are exposed to
the test article or extract. Bone marrow or peripheral blood is harvested from
the animals and is evaluated for the presence of micronuclei. Micronuclei are
composed of chromosomes or fragments of chromosomes and are indicative of
chromosomal damage.
Supplemental testing
Supplemental testing involves reproductive toxicity testing and carcinogenicity
studies and degradation studies. These are all long-term tests that can prove to
be quite costly.
Carcinogenicity testing
Carcinogenicity testing is used to determine the tumorigenic potential of medical
devices, materials, and/or their extracts from either single or multiple exposures,
over a period consisting of the total life span of the test animal (e.g., 2 years for
rats, 18 months for mice, or 7 years for dogs).
Carcinogenicity testing of devices is expensive, and manufacturers should con-
duct such tests only if data from other sources suggest a tendency for tumor induc-
tion. Situations where the need for carcinogencity testing should be considered
120
Biocompatibility
• Resorbable materials and devices for which the resorption time is greater
than 30 days, unless there are significant and adequate data on toxicoki-
netics or human use or exposure
• Materials and devices where positive results have been obtained in
genetic toxicity testing in both mammalian cells and in vivo
• Materials and devices introduced in the body and/or its cavities with a
permanent or cumulative contact of 30 days or longer, except when sig-
nificant and adequate human use history is available
Tests for carcinogenicity include the following:
• ISO 10993-3: Tests for Genotoxicity, Carcinogenicity, and Reproductive
Toxicity
• OECD 451: Carcinogenicity Studies
• OECD 453: Combined Chronic Toxicity/Carcinogenicity Studies
Reproductive and developmental toxicity

Reproductive and developmental toxicity studies evaluate the potential effects of
medical devices, materials, and/or their extracts on reproductive function, embry-
onic development (teratogenicity), and prenatal and early postnatal development.
Reproductive anomalies affect both males and females and range from slightly
decreased reproductive capability to complete sterility. Teratogenicity deals with
the adverse effects of a substance on the developing embryo and fetus. Toxic effects
to the offspring can range from mortality to morbidity as subtle as decreased body
weight at birth.
Reproductive toxicity tests should normally be considered for the following medi-
cal devices:
• Intrauterine devices (IUDs) or any other long-term contact devices likely
to come into direct contract with reproductive tissues or the embryo
• Energy-depositing devices
• Resorbable or leachable materials and devices
Tests for reproductive and developmental toxicity include the following:
• ISO 10993-3: Tests for Genotoxicity, Carcinogenicity, and Reproductive
Toxicity
• OECD 414: Teratogenicity
• OECD 415: One-Generation Reproduction Toxicity Study
• OECD 421: Reproduction/Development Toxicity Screening Test
Biodegradation
Careful consideration of the potential for intended or unintended degradation of a
material is essential to the evaluation of the biological safety of a medical device.
121
Per Annex A of ISO 10993-9, degradation studies should be considered if the fol-
lowing is factual:
• The device is designed to be bioresorbable.
• The device is intended to be implanted for longer than 30 days.
• An informed consideration of the material(s) system indicates that toxic
substances may be released during body contact.
Biodegradation tests how much of the product or material is absorbed by the
body and follows the product or material through the body after it has been
absorbed to determine the effects over time. Degradation products can be gener-
ated in different ways, either mechanically, by fatigue loading, and/or by release
from the medical device due to interactions with the environment or combinations
thereof. The level of biological tolerability of degradation products depends on
their nature and concentration and should be primarily assessed through clinical
experience and focused studies.
Biodegradation testing includes the following:
• ISO 10993-9: Framework for Identification and Quantification of Potential
Degradation Products
• ISO 10993-13: Identification and Quantification of Degradation Products
from Polymeric Medical Devices
from Ceramics
from Metals and Alloys
• ISO 10993-16: Toxicokinetic Study Design for Degradation Products
and Leachables
122
Chapter 13 Design transfer
What is design transfer?

When design controls first made their appearance, many people looked at the
section concerning design transfer and pointed to it as proof of the bureaucratic
nature of the new regulation. What else would you do with a newly developed
product but transfer it to production? The problem is that it’s not what you do at
this point in the development process but how—and sometimes even when—you
do it. The purpose of the design transfer phase is to make sure design outputs are
adequately and correctly translated into production specifications.
Check your attitude at the door

I am sure that nothing that is about to be said in this section applies to your com-
pany, but you know it happens. Design transfer is probably the most obvious phase
of the design and development process, and that in itself is the root of the problem.
Poor transfer often starts with manufacturing personnel, and this may often be the
fault of management. If there is a process engineering presence in the company, it
happens more frequently than you might think. Management may decide that the
participation of manufacturing personnel on the design team needs to be either
limited or worse, nonexistent. The rationalization for this is usually something
like, “We are working three shifts a day and overtime. Manufacturing people
simply don’t have the time, and the company can’t afford to take them away from
their jobs for a meeting. They’re too critical!”
During the design process, the manufacturing people may hear all sorts of things
about the new product, and most of them are out of context. Sometimes design
engineers ask them questions and a mental picture begins to form of a new prod-
uct that will at best be difficult to integrate into manufacturing and at worst be a
nightmare. As time goes on, the manufacturing people begin to form a defense
against this new product that often takes the form of, “When it gets to manufac-
turing, we’ll fix it.”
Never happens, right? It happens. Here are two instances that really occurred.
Both were at well-known and well-respected companies. In the first case, a device
was developed in-house, and R & D entirely handled the technical side of the
123
development. The manufacturing process was designed, debugged, and validated

by process engineering. The product was virtually demanded by the custom-
ers, and so its success was guaranteed. The first manufacturing line was built
in-house and tested, and the validation was without significant problems. The
machine was transferred to the manufacturing plant. For a period of three weeks,
on-specification product was made while the manufacturing personnel were
trained. Process engineering stayed with manufacturing and the product for the
entire three-week period. After everyone signed off his or her approval, the pro-
cess engineers left. Within one month of the transfer, all hell broke loose. A criti-
cal design dimensional specification could not be held, and manufacturing sought
approval to loosen the specification. When the original process design engineers
went to the facility, the reason for the sudden inability to hold the specification
was apparent. The manufacturing engineers had redesigned the production equip-
ment to increase efficiency and save floor space. In doing so they cut the frame-
work of the machine to rearrange its components. From that point on, the warped
frame made it impossible to hold the dimensional specification.
In another instance an outside source designed and built the manufacturing
process. The line was installed and validated. Everyone was in heaven, except,
as it turned out, some of the manufacturing people didn’t like the design of the
machine and thought they had a better idea. So the machine began to act errati-
cally. The cause for this sudden erratic behavior in the process was that someone
in the plant disconnected a circuit. The people responsible for the sabotage said
they knew the machine was no good, and they hoped that when it failed they
would get the chance to build their own.
How could this happen? The reason is simple really. The manufacturing people
were never involved; there was no ownership of the product from their point of
view. Whose fault was it? That answer is simple also. It was the fault of the senior
managers. It was their responsibility to ensure quality. It was senior manage-
ment’s responsibility to build the team. And one more important point: although
the two examples happened to put manufacturing folks in a poor light, it could
and does happen with other disciplines also. I used manufacturing people as the
example, because they are the ones most often left out.
FDA and design transfer

Design transfer requirements fall under 21 CFR Part 820.30(h). There is, however,
no corresponding design transfer requirement stated in the ISO 13485 standard.
The FDA requirement states, “Each manufacturer shall establish and maintain
procedures to ensure that the device design is correctly translated into produc-
tion specifications.”
124
Design transfer
Design transfer requirements

Design transfer activities during the development process ensure that design out-
puts are verified as suitable for manufacturing before becoming final produc-
tion specifications. As a result, design transfer activities typically occur at each
design and development stage. It is not uncommon, therefore, for sections of a
design to be transferred before the entire design is complete; for example, design
output documents that form part of the device master record (DMR) need to be
transferred in order for production units to be built for validation and verifica-
tion activities.
Once the design is complete, it is essential that you ensure that all required design
specifications have been correctly transferred over into production specifications
(e.g., DMR). As expected, the system for doing this needs to be defined and docu-
mented (e.g., Change Control/Engineering Change Order [ECO] process).
Your production specifications typically consist of written documents such as the
following:
• Product and assembly drawings
• Inspection and test specifications and instructions
• Finished product and material specifications
• Manufacturing instructions
• Training materials
• Tooling drawings, manufacturing jigs, or molds
At this point in the design and development process, all verification and valida-
tion activities should be completed and all personnel training should have been
conducted before initial production begins. This is a good time for a design review
meeting to ensure that all aspects of the design process have been reviewed for
adequacy and completeness and for a final look at the risk analysis to see if any
new risks have been identified.
A design transfer checklist may be used to ensure all required documents are
ready and approved for transfer and/or have already been transferred (e.g., DMR
is complete). The design transfer checklist should identify the outputs associated
with the activities identified on the design and development plan. It may also
require a final risk analysis, approval of the DMR, and review of the DHF for all
required elements. Sign-off of the design transfer checklist (or Change Request/
ECO) may be used to release the design to production. An example of a simple
design transfer checklist can be found in Appendix I. Note that process validation
may be initiated before or during design transfer.
Once all of the applicable documents are effective and marketing clearance has
been received from appropriate regulatory bodies (e.g., FDA 510(k) approval,
125
Canada Medical Device License, Europe CE Technical File), you are now ready
to release the product for distribution. An Approval for Sale Form is typically
completed prior to product launch to document the confirmation from all project
team members and management that all activities have been completed and the
device is ready for launch. An Approval for Sale Form template is provided in
Appendix K.
126
Chapter 14 Design change
Design change control

Why do we need to control changes during design and development? Aren’t we
still trying to figure it all out?
Design change control is just one more way to ensure quality. Anyone who has
ever been involved with the development of a medical device is aware that many
changes occur between the original concept and the device that is ultimately
transferred to production and released for distribution. If we remember that design
control is a cyclical process, then it is important to know where we’ve been and
how and why we got to where we are.
Just like the pitfalls that can occur during design transfer, similar events can hap-
pen if the design team does not have control of the changes that occur along
the way. If an overzealous design engineer decides to change a dimension with-
out telling anyone, and worse without noting the change, a disaster can occur.
Remember the First Law of Design Controls: document everything!
Design change control is the foundation of a good product development cycle and
the cornerstone of design controls. Design change requirements fall under Section
820.30(i) of the FDA’s Quality System Regulation and Section 7.3.7 of ISO 9001
and ISO 13485.
Design change requirements

It is almost inevitable that design verification and validation activities during
design and development will uncover discrepancies that will likely result in
changes to the design input requirements. However, any changes made to the
device design once you approve the initial design inputs (e.g., PPS) need to be
controlled. The system, of course, for making these changes needs to be defined
and documented in a procedure. It is not uncommon for the change control process
you implement during design and development to be different from the change
control procedure you use once the device has been transferred to production. A
simple Design Change Form that can be used to document changes during the
design and development process is provided in Appendix J. Reference the design
control procedure in Appendix A for proper use of this form.
127
Design changes include the following:

• Changes made to the device itself (specification, method, or procedure)
• Changes made to device labeling or its packaging
• Changes resulting from postproduction information (e.g., complaint
data, servicing and repair data, manufacturing nonconformance data,
requests from customers, clinical evaluations, etc.)
Your change control procedure needs to describe how changes are identified
and documented and how it is determined whether verification and/or validation
is necessary. Remember, changes need to be verified and/or validated prior to
implementation. You don’t want to implement a change without first making sure
that it will be effective.
Companies are required to maintain a defined and documented design change
procedure even if they have not completed any design projects and regardless
of whether they have any ongoing or planned design projects or changes. More
importantly, if your initial device design was released prior to implementation or
enforcement of design control requirements, any changes made to the device since
the requirements were enforced need to comply with design change requirements.
The degree of change control required will be dependent on the significance of
the change and the risk presented by the device. The concept of a significant
design change is relatively consistent among regulatory organizations, including
in the United States, Canada, and the European Union. The following definition
is taken from Health Canada:
A Significant Change is a change that could reasonably be expected to affect the
safety or effectiveness of a medical device. It includes a change to any of the following:
• the manufacturing process, facility or equipment;
• the manufacturing quality control procedures, including the methods,
tests or procedures used to control the quality, purity and sterility of the
device or of the materials used in its manufacture;
• the design of the device, including its performance characteristics, princi-
ples of operation and specifications of materials, energy source, software
or accessories; and
• the intended use of the device, including any new or extended use, any
addition or deletion of a CONTRAINDICATION for the device, and
any change to the period used to establish its expiry date.
Appropriate authorities should be notified of a significant change to a device in

commercial distribution (e.g., Health Canada, EU Competent Authority, FDA,
Japanese Minister, etc.) as applicable. For example:
• The FDA requires the submission of a premarket notification (i.e., 510(k))
or a supplement to a premarket approval (PMA) for significant changes
made postapproval or clearance, as applicable.
128
Design change
• Canada’s CMDR Sec. 34 requires an amended license application for a

significant change to a Class III or IV device or a change in intended use
of a Class II device.
Both the FDA and Health Canada have a guidance document to assist manu-
facturers in determining whether a change is significant. These two guidance
documents are very similar to each other and include flowcharts to guide you
through the process of determining whether changes in labeling, technology, or
performance specifications, manufacturing processes and procedures, and mate-
rials require notification. For example:
• A significant labeling change would include a change in the indications
for use.
• A change in performance specifications or even packaging or sterility
may represent a significant change.
• A change in the type of material, the formulation of the material, or the
material supplier may represent a significant change; for example, a change
in material may affect the rigidity or fatigue properties of the device.
Because many changes occur in the evolution of a device after transfer to pro-
duction, each change must be assessed individually and collectively with other
changes to determine if the individual change, or the sum of the changes as a
whole, could affect safety or effectiveness of the device and/or require a regulatory
submission or notification (i.e., Medical Device License Amendment, Notified
Body, 510(k), PMA supplement, etc.) and/or the initiation of a new design control
project. The modified device should be compared to the most recently cleared
version of that device and not to a version of the device that has not received clear-
ance. In addition, a review of the change or series of small or minor changes may
require a change to your risk assessment.
All changes need to be reviewed and approved prior to implementation by the same
individuals or functions associated with the original design to ensure the device
will continue to perform as intended.
Change records are also required to be maintained.
Engineering change order or change request form

The heart of controlling design changes, especially postproduction, is the
Engineering Change Order (ECO) or similarly called a Change Request (CR)
form. This form provides the necessary control by requiring the originator of any
change to think about what he or she is doing and what other documents, speci-
fications, and tests may be affected by the change. In many ways the engineering
change process should be handled like a mini design control project.
129
Chapter 15 Design history file
Why do we need a design history file?

The main reason for a Design History File (DHF) is to provide a record or evi-
dence of your compliance with the design control requirements. The DHF is the
final section of the design control subpart in the Quality System Regulation, and
it is by far the most simple.
What is a design history file?

The FDA defines the DHF as “a compilation of records which describes the
design history of a finished device” (21 CFR Part 820.3(e)).
Design history file requirements

The requirement for a DHF falls under Section 820.30(j) of the Quality System
Regulation. There is no direct callout for a DHF in the ISO 9001 and ISO 13485
Standard, but the file would be required to be maintained under Section 4.2.4.
A DHF needs to be maintained for each type of device or device family that
a manufacturer develops under design controls. The DHF should contain the
records necessary to demonstrate that the design was developed in accordance
with the approved design plan and the established design control requirements.
The elements of the DHF are depicted in Figure 15.1 and include the following:
• The design and development plan
• Design input documents
• Design outputs
• Risk analysis documents
• Design review records
• Verification methods and results
• Validation protocols and results
• Preproduction design change control records
• Design transfer records
• Records of product builds and testing
• The initial device master record (DMR)
• A DHF index
131
Risk Analysis
Design Changes
Design Reviews
Design Validation
Design Inputs
DHF
Design Verification
Design Outputs
Design Plans
Figure 15.1 Design history file elements.
Note that DHFs are typically frozen after the final design transfer. When design
changes are made postproduction, addendums can be created or the supporting
documentation can be maintained in accordance with the firm’s change control
process. The original DHF should be the embodiment of the new product as it was
released for commercial distribution.
Many of the design output documents that form part of the DMR will come
directly from design and development activities. The remaining elements and
documents will be created using design output data and information. For exam-
ple, finished device test methods and data collecting forms may be derived from
design verification protocols.
The DMR includes or refers to the location of the following:
• Device specifications, including drawings, composition, formulation,
component specifications, and software specifications
• Production process specifications, including equipment specifications,
production methods, procedures, and environment specifications
132
Design history file
• Quality assurance procedures and specifications, including acceptance

criteria and the equipment to be used
• Packaging and labeling specifications and drawings, including methods
and processes used
• Installation, maintenance, and servicing methods and procedures
133
Chapter 16 The FDA inspection
technique
Oh no! The FDA investigator is here
So you’re about to be inspected or audited for compliance with the design control
requirements. What can you expect? First of all, if you’ve been doing everything
correctly, there is not much to worry about. An inspection or ISO audit will hap-
pen sooner or later. If things are running smoothly and you are complying with
the systems you put in place to meet the requirements, you should be fine.
The drawing in Figure 16.1 represents the process flow or FDA’s Quality System
Inspection Technique (QSIT) for inspecting the design control requirement.
The primary purpose of the FDA design controls subsystem inspection is to eval-
uate the process, the methods, and the procedures that a manufacturer has estab-
lished to implement the requirements for design controls. Although this diagram
outlines the FDA’s approach to auditing the design control requirements, it could
just as easily be applied to an ISO 9001 or ISO 13485 compliance audit.
In addition to the material mentioned previously, there are some questions that
may likely arise during an inspection or audit. These include, but are not limited
to, the following:
• General design control requirements:
• What initiates a design project?
• When does the actual design and development begin (e.g., design
controls)?
• Design and development planning:
• How is each design and development activity identified and
documented?
• How are responsibilities defined?
• Are design and development activities assigned to qualified personnel?
• Are plans updated as the design evolves?
• Are the organizational and technical interfaces between different
groups that input into the design process identified?
• Do procedures exist for the documentation, transmittal, and review
of interdepartmental data exchanges?
• Design input:
• Do design inputs include customer requirements?
• Do design inputs include applicable statutory and regulatory require-
ments for those countries in which you are intending to market?
135
820.30(f ), 820.30 (g)
136
820.30(g)
Confirm acceptance criteria were est-
Select a single design project Confirm that risk anlaysis was
ablished prior to the performance of
performed.
verification and validation activities.
820.30(a), 820.30 (c)-(j) 820.30(f ) 820.30(g)

Have design control procedures that Determine whether design validation
address the requirements of the Determine if verification confirmed was accomplished using initial pro-
regulation been defined & documented? that outputs met inputs. duction devices or their equivalent.
820.30(b) 820.30(g) 820.30(i), 820.70 (b)

Confirm that the design validation data Confirm that design changes were con-
Review plan for defined activities, re-
showed that the approved design met trolled including verification or where
sponsibilities and interfaces. Evaluate
the predetermined user needs and inappropriate validation.
the firm’s conduct of risk analysis.
tended uses.
820.30(c) 820.30(g) 820.30(e)
Confirm design inputs were Confirm that unresolved discrepancies Verify that design reviews were
established left from the design validation were conducted.

resolved.
820.30(d) 820.30(g) 820.30(h)

Verify design outputs that are essential If the device contains software, confirm
Determine whether the design was
to the proper functioning of the device that the software for the device was
correctly transferred.
were identified. validated.
Figure 16.1 FDA design controls inspection technique.

The FDA inspection technique
• Do design inputs address intended uses, including the needs of the

user and patient?
• Are design inputs reviewed and approved?
• Does the company have a procedure or method to address incom-
plete, ambiguous, or conflicting requirements with those responsible
for imposing these requirements?
• Design output:
• Is design output documented and expressed in terms that can be
verified and validated against design input requirements?
• Are design outputs approved?
• Does design output documentation achieve the following?
−− Provide evidence that the final design meets input requirements
−− Identify or make reference to acceptance criteria
−− Identify characteristics of the design that are crucial to the safe
and proper functioning of the product (e.g., operating, handling,
maintenance, storage, and disposal requirements)
• Design review:
• At what stages are formal documented reviews performed?
• Do design reviews include representatives of all functions concerned
with the design stage being reviewed and an individual independent
of the design stage being reviewed?
• Are records of design reviews maintained? For how long?
• Do records include individuals in attendance, date, and design
reviewed?
• Do design reviews address the following, as applicable?
−− Comparison of customer needs with technical specifications for
materials, products, and processes
−− Validation of the design through prototype tests
−− Considerations of unintended use and misuse
−− Safety and environmental compatibility
−− Compliance with regulatory requirements, national and interna-
tional standards, and corporate practices
−− Comparison with similar designs, especially analysis of internal
and external problem history to avoid repeating problems
−− Permissible tolerances and comparison with process capabilities
−− Product acceptance–rejection criteria
−− Manufacturability of the design, including special process
needs, mechanization, automation, assembly, and installation
of components
−− Capability to inspect and test the design, including special
inspections and test requirements
−− Specification of materials, components, and subassemblies, includ-
ing approved suppliers
137
−− Packaging, handling, storage, and shelf-life requirements

−− Safety factors relating to incoming and outgoing items
• How are problems or action items identified during a review handled?
• Design verification:
• Do verification activities identify the method, date, and individual
performing verification?
• What types of design verification activities were performed?
• Are design verification records maintained as part of the Design
History File (DHF)?
• Are there alternative calculations to verify the correctness of origi-
nal calculations and analysis (i.e., risk assessment, etc.)?
• Are there experimental runs?
• Are there tests and demonstrations (model or prototype test)?
• Is there a comparison to similar proven designs?
• Are design verification records maintained as part of the DHF?
• If output ≠ input, how was discrepancy resolved?
• Design validation:
• What methods were used to validate the design?
• Were the first three production lots tested under actual or simulated
use conditions?
• If design validation is done on nonproduction devices, how were the
devices shown to be equal to production devices?
• How were unresolved discrepancies handled?
• If the device has software, how was the software validated?
• Design transfer:
• How are design specifications translated into production specifications?
• Design changes:
• When do changes to product design begin to fall under design control?
• How are design changes controlled?
• Are all design changes identified, documented, reviewed, and approved
by authorized personnel prior to implementation?
• Are design changes verified and/or validated as effective prior to
implementation?
• Are design changes under document control?
• How do design changes trace back to the initial design project?
• Design History File:
• What documents make up your DHF?
• How long are DHFs maintained?
• How are postproduction changes to DHFs controlled; for example, are
they linked or referenced to the original DHF?
138
Appendix A—QARA Compliance
Connection, Inc.: Design
control procedure
DESIGN CONTROLS
SOP No. 820.30.DES Rev: A Effective Date: 01-01-2013 Page 1 of 13
RESTRICTED—DO NOT COPY
1.0. Purpose
This procedure defines the method to be used to control the design and develop-
ment of all QARA Compliance Connection products that are required to meet the
FDA’s Quality System Regulation requirements and/or ISO 13485 requirements
for design control.
The requirements to initiate a design control project may arise for a variety of
reasons, such as the identification of a new product, a marketing need to sat-
isfy a customer’s request or problem, a cost savings to the customer or company,
the potential for a process improvement, a change or modification in an exist-
ing device that significantly affects safety or effectiveness, or a change that is
imposed by external circumstances.
The decision of whether an individual change or the cumulative sum of changes
to an existing product requires the initiation of a new design control project versus
a Change Request Form shall be made by consulting the FDA’s 510(k) Device
Modifications Document “Deciding When to Submit a 510(k) for a Change to an
Existing Device.”
In all cases, the design control or change control process shall be carried out
under controlled conditions.
139
Appendix A—Standard operating procedure
2.0. Application/responsibility
This procedure applies to all products developed by QARA Compliance
Connection that bear the QARA Compliance Connection name as manufacturer
and are required to meet design control requirements. Responsibility for con-
trolled design and development applies to the generation of new products, as well
as to the significant redesign of existing products.
Project team members are responsible for acting as department liaisons in support
of project requirements.
Management has the responsibility to adhere to the requirements of this proce-
dure and to ensure that employees comply. Management is also responsible for
making decisions relating to the viability of a project.
The project leader is responsible for coordinating all aspects of the design con-
trol project.
3.0. Reference documents
F 820.30.DPCS Design Project Cover Sheet
F 820.30.PPS Product Performance Specification
F 820.30.DIO Design Input/Output Matrix
F 820.30.DRM Design Review Meeting Form
F 820.30.DC Design Change Form
F 820.30.DTCL Design Transfer Checklist
F 820.30.AFS Approval for Sale Form
SOP 820.30.RISK Risk Management Procedure
SOP 820.40.DOC Document and Change Control Procedure
SOP 801.LAB Labeling Generation and Approval Procedure
F 820.180.RCI Record Control Index
See also the FDA’s 510(k) Device Modifications Document “Deciding When to
Submit a 510(k) for a Change to an Existing Device.”
4.0. Definitions
Design control project
A self-contained program of work initiated either to introduce a new product or
process or to make a change to an existing product or process that may require
redevelopment of that product or process.
Design history file: A file containing the complete history of the product’s design
process, providing historical traceability of design control. The file contains or
140
references documentation concerning inputs, outputs, verifications, validations,

and design reviews leading to design release and approval for sale.
Design inputs: These are the physical and performance characteristics of a device
that is used as a basis for device design. Those inputs essential or critical to the
proper function of the design, and necessary to meet the intended use and user’s
needs, must be clearly defined.
Functional specifications: These are the performance characteristics and prod-
uct requirements of the designed device and its components presented in general
terms. These values represent specific performance expectations of the device.
The functional specifications are composed of factors involving intended use,
user and physician needs, environmental requirements, safety characteristics, and
marketing characteristics. These critical requirements are defined at the begin-
ning of the design and development process. They are defined by examining and
documenting information from multifunctional sources such as market research,
consultants, literature reviews, regulatory agencies, and in-house expertise.
Design outputs: These are the results of a design effort at each design phase and
at the end of the total design effort. Output may consist of the actual device itself
or a component, drawings and specifications, a documented procedure, and/or
packaging and labeling. The finished design output becomes the basis for the
device master record. Design outputs include the methods developed to verify and
validate design inputs.
Design review: This is a formal documented review of a design to evaluate the
adequacy of the design requirements, to evaluate the capability of the design to
meet these requirements, and to identify problems. These reviews are scheduled
and conducted by the project team at appropriate stages of the product develop-
ment. Each design review is to include, at minimum, all members of the project
team or their delegates, as well as one objective member not directly responsible
for any tasks associated with the design phase under review.
Design validation: This includes the documented tests and analyses necessary
to confirm that the design itself meets the user’s needs and the intended use(s).
Validation efforts follow successful verification. Examples of validation activi-
ties include process qualifications, risk analyses, in vivo safety and efficacy stud-
ies, and clinical trials and evaluations. Design validation shall be performed
under defined operating conditions on initial production units, lots, or batches or
their equivalents.
Design verification: This includes the documented tests and analyses necessary
to confirm that design output(s) fulfill design input requirements. Examples of
verification activities include visual inspection and measurements, performance
bench testing, in vivo performance testing, biocompatibility assays, and so on.
Design verification shall confirm that each design output is verified as meeting
design input requirements.
141
Clinical data: These are the safety and/or performance information that is gener-
ated from the use of a device. Clinical data are sourced from the following:
• Clinical investigation(s) of the device concerned
• Clinical investigation(s) or other studies reported in the scientific litera-
ture of a similar device for which equivalence to the device in question
can be demonstrated
• Published and/or unpublished reports on other clinical experience of
either the device in question or a similar device for which equivalence to
the device in question can be demonstrated
Clinical evaluation: This is the assessment and analysis of clinical data pertain-
ing to a medical device in order to verify the clinical safety and performance of
the device when used as intended by the manufacturer.
Marketing evaluation: This is a study in which a marketed or nonmarketed test
article is not used on humans but rather gathers input from humans to assess
physical and chemical characteristics of the test article, or a study in which a mar-
keted test article is used on humans, but no individual medical data are collected
(e.g., questionnaire or survey).
Preliminary evaluation: This is work done to establish the basic merit of an idea.
Design phases: The number of phases for a design project is dependent on the
complexity of the project and will be determined by the project team. At a mini-
mum, each design project will contain the following phases (e.g., formal design
review meeting):
• Design and development phase: This phase marks the onset of formal
design control. All critical functional and design specifications for the
device design should be defined at this point. Design inputs shall be for-
mally documented and approved, and the design and development phase
will begin. Upon formal approval of the design inputs, changes to the
product’s design shall be controlled.
• Design transfer phase: This phase involves the process of translating the
product design into production specifications and procedures to ensure
accurate manufacture of the approved design. This phase shall include a
review of all design and development activities, final validation results,
a final risk analysis, and confirmation that all process validation and
associated training has been completed.
• Design release phase: This phase ensures that all project team members
and executive management agree on the relevance and suitability of the
verification and validation results and that all documents and data nec-
essary to ensure that the product is ready for distribution are in place.
142
5.0. Procedure: initiation of design and

development and design controls
5.1. Project approval
5.1.1. Once any feasibility work is completed, if management feels the poten-
tial exists to manufacture a viable product capable of meeting basic design input
requirements, a project leader and a project team shall be nominated by executive
management and documented on a Design Project Cover Sheet. An independent
team member should also be documented.
5.1.2. The project leader is responsible for initiating the project file (i.e., Design
History File) and completing the Design Project Cover Sheet. Approval by the
CEO/COO shall be documented on the Design Project Cover Sheet. The file shall
be updated as the design and development progresses and retained in accordance
with the Record Control Index.
5.2. Product Performance Specification (Design Inputs)

5.2.1. The project leader, with assistance from project team members, shall com-
plete a Product Performance Specification (PPS). The PPS shall document the
product (i.e., input) requirements inclusive of performance characteristics, prod-
uct characteristics, marketing requirements, quality assurance and regulatory
requirements, and financial requirements. All inputs defined by the PPS shall be
put in verifiable or quantifiable terms, where possible, and any essential known
outputs for a product, to ensure its proper performance, functioning, or use, shall
be documented on the Design Input/Output Matrix. This matrix shall be updated
as the design evolves through the design and development process.
Note that distinction should be made between desirable attributes and essential
requirements. Customer expectations, safety, and satisfaction must be taken into
consideration. If certain requirements are unique for a market (e.g., EU, Canada),
then it should be indicated as such within the appropriate section of the PPS.
Additional description areas may be added as needed.
As applicable, design inputs should consider the following:
• Intended use
• User/patient/clinical (interfaces or needs)
• Performance characteristics
• Risk and/or safety requirements
• Safety and performance parameters
• Toxicity
143
• Biocompatibility
• Electromagnetic interference
• Compatibility with accessories/auxiliary devices
• Compatibility with the environment of intended use
• Human factors
• Clinical reports
• Physical/chemical characteristics
• Labeling and packaging
• Statutory and regulatory requirements
• Past design history files
• Manufacturability
• Cleaning, disinfection, and maintenance requirements
• Registration and patents, trademarks, and licensing agreements
• Medical reimbursement considerations
5.2.2. The PPS shall be reviewed and approved by the project team at the ini-
tial design review meeting. Approval shall be indicated on the Design Review
Meeting Form. Any changes needing to be made to the PPS shall be identified on
the Design Review Meeting Form. The PPS shall be revised as needed, approved,
and controlled moving forward using the Design Change Form. The PPS is a
revision controlled document and shall be maintained as an element of the Design
History File.
5.3. Design project plan

5.3.1. Upon completion of the PPS, the project leader or designee, with input from
project team members as necessary, shall develop a project plan that will be used
to manage the design and development process. The project plan shall identify
the project tasks and activities (i.e., outputs), associated time frames, if known,
and project team member and department responsibilities and interrelationships,
major milestones, risk analysis, and anticipated design review meetings, as far as
practical. The detail in which planning is carried out may vary depending on the
complexity of the project or design.
5.3.2. The project plan shall be approved by all project team members as part of
the initial design review meeting. Approval of the initial project plan shall be doc-
umented on the Design Review Meeting Form. The project plan shall be reviewed
and revised, as needed, during the design and development process and reviewed
at each subsequent formal design review meeting. Changes to the project plan
shall be identified and approved via the Design Review Meeting Form. Updated
project plans shall be maintained as part of the Design History File.
144
5.4. Risk analysis
5.4.1. An initial risk analysis for the design shall also be conducted either prior to
or at the initial design review meeting to assess the risks and hazards associated
with use of the product in accordance with the Risk Management Procedure. The
outputs from the risk assessment should serve as inputs to the PPS, as applicable.
The Risk Analysis Master Record (RAMR), or alternative method, shall be used
to document the risk assessment process. The RAMR shall be approved by all
project team members as part of the initial design review meeting, and initial
approval shall be documented on the Design Review Meeting Form.
5.4.2. The RAMR shall be reviewed and revised, as needed, at each subsequent
formal design review meeting. Any changes needing to be made to the RAMR
shall be identified on the Design Review Meeting Form. The RAMR shall be
revised as needed and controlled (i.e., approved) using the Design Change Form.
The RAMR is a revision-controlled document and shall be maintained as an ele-
ment of the Design History File.
5.5. Design review meeting (start of formal design controls)

5.5.1. The project leader will then call a formal design review meeting to include
all project team members, plus the addition of one objective reviewer not directly
responsible for the design phase being reviewed. The purpose of the initial
design review meeting is to review and confirm the design inputs (PPS) and the
expected outputs (I/O Matrix), to identify and resolve any ambiguities and con-
flicts (Design Review Meeting Form), and to initiate the design and development
phase. The project plan, PPS, risk analysis, and any other pertinent information
shall be included in the initial design review.
5.5.2. Any incomplete, ambiguous, or conflicting requirements or proposed
changes shall be identified as part of the initial design review meeting and docu-
mented using the Design Review Meeting Form.
5.5.3. Approval of the Design Review Meeting Form by all project team members
shall signify approval to proceed to the design and development phase and the
onset of design controls. Alternatively, if management determines that the prod-
uct is not viable, cost-effective, and so on, the design project will be terminated,
in which case no further action is required.
5.5.4. All design changes from this point forward shall be documented and con-
trolled using the Design Change Form. Design Change Forms shall be main-
tained as part of the Design History File. The Design Review Meeting Form and
Design Change Form shall be used to formally document the results of any formal
design review meeting.
145
5.6. Design and development

5.6.1. Formal design review meetings shall be conducted at significant milestones
to verify and/or validate that design outputs meet design input requirements in
accordance with the project plan. These reviews shall be documented on the proj-
ect plan. Design reviews shall occur at the beginning of design and development,
after the evaluation of prototypes, prior to design transfer, and prior to release and
approval for sale. All project team members, as well as one independent reviewer
or member, are required at the initial design review meeting and at the final
design review meeting. Those project team members who have direct responsibil-
ity for the design stage being reviewed shall attend other design review meetings.
Specialists shall be included as necessary.
5.6.2. Formal design review meetings shall be documented on the Design Review
Meeting Form. Informal design review meetings may be documented using this
form as well.
5.6.3. As design and development progresses, design outputs will be generated.
The finished design output consists of documentation that defines the device and
ensures the finished design meets the design input requirements. This includes
the following:
• The device design (e.g., drawings, finished product specs)
• Requirements for purchase of materials (e.g., bills of material, material
specs)
• Directions for manufacture (e.g., assembly, inspection and test procedures)
• Device labeling (e.g., product label, instructions for use)
• Device packaging (e.g., immediate container, shipping box)
5.6.4. The identification of required outputs and responsibilities for developing
these outputs shall be identified on the project plan. The Design Input/Output
Matrix shall be completed and updated to identify and document the outputs
associated with each design input requirement. Note that there may be more than
one output for an input.
5.6.5. Design outputs shall contain or make reference to acceptance criteria and
identify any characteristics of the design that are crucial to the safe and proper
functioning of the product. These may include, but are not limited to, operating,
storage, handling, maintenance, and/or disposal requirements. Outputs will be in
terms that allow adequate evaluation of conformance to design input requirements.
Generated outputs may include, but are not limited to, the following:
• Prototype or samples for verification and validation
• First articles
• Product engineering drawings
146
• Bills of materials
• Product and design specifications
• Component and material specifications
• Equipment calibration requirements
• Equipment maintenance requirements
• Quality specifications
• Manufacturing assembly procedures
• Inspection and test methods
• Standard purchasing agreements
• Packaging procedures and specifications
• Labeling procedures and specifications
• Verification and validation protocols
5.6.6. Design outputs will be reviewed and approved (i.e., transferred) as needed
during the design and development process using the Design Change Form.
5.7. Design verification
5.7.1. As the design progresses through the development phase, various meth-
ods of verification shall be used to determine whether the design outputs meet
functional and operational requirements (e.g., design inputs). Verification and
acceptance criteria should be unambiguous, objective, and quantifiable. Design
verification will be performed on prototypes.
5.7.2. Verification may be accomplished using a variety of methods, including
inspection and testing under simulated used conditions, that is, performing bench
testing, biocompatibility testing, and/or package integrity tests; performing alter-
native calculations; comparing the new design with a similar proven design, if
available; reviewing data and results at design reviews, tests, and demonstrations;
and so on. Verification activities should take into account worst-case operating
conditions, where practical. Verification documentation will identify the design
project, verification method, date, results, and individual performing the verifica-
tion. Verification documentation is maintained as part of the Design History File.
5.7.3. Verification results are reviewed and discussed at design review meetings.
As such, results may require changes to design inputs, outputs, or product require-
ments. Any needed changes are identified on the Design Review Meeting Form,
and documents are revised as needed. The project plan may also be updated to
account for the changes.
5.7.4. Any risks and/or hazards exposed during the design and development phase
should be identified and addressed at the subsequent formal design review meet-
ing. The RAMR should be revised as needed to address any potential new or
unexpected risks and approved using the Design Change Form.
147
5.7.5. The project leader may call project team meetings as necessary as the proj-
ect moves forward through the design and development phase to review project
status, update schedule time lines, review and approve outputs, and so on. An
agenda will be issued to identify the topics of discussion and project team mem-
bers required in attendance.
5.7.6. All project team meetings shall be documented by the project leader or
designee. If the Design Review Meeting Form is used to document the minutes
of the meeting, indication should be made that the meeting is not a formal design
review meeting. Any changes or decisions to be made should be documented and
controlled using the Design Change Form and reviewed and approved at the sub-
sequent formal design review meeting.
5.7.7. After the development and verification of prototypes, the project leader will
call a formal design review meeting to include all project team members, plus the
addition of one objective reviewer not directly responsible for the design phase
being reviewed. The purpose of the design review meeting will be to ensure veri-
fication and any preliminary validation results confirm that outputs meet input
requirements prior to commencing manufacture of production runs under simu-
lated use conditions.
5.7.8. The results of the design review meeting and any changes that need to be
implemented shall be documented on the Design Review Meeting Form. Approval
of the Design Review Meeting Form will signify readiness to commence manu-
facture of initial production runs. Outputs shall be revised as needed, and approval
of these changes shall be documented on the Design Change Form.
5.8. Process validation
5.8.1. Process validation (IQ, OQ, PQ) may be initiated during the design control
process and finished after transfer of the design of manufacture. Process validations
shall be documented and performed, as needed, to validate production processes.
Validation documentation will include the design project, method or procedure,
date, and individual(s) conducting the validation.
5.9. Design validation
5.9.1. Design validation shall be performed to ensure that the resulting product
is suitable for its intended use and meets the user’s needs. Validations will be
performed under defined operating conditions on initial production lots that have
been produced under the same production and quality system methods, proce-
dures, and equipment that will be used for routine production. These final valida-
tion studies will involve test systems and environments representative of true end
use conditions. Design validation activities may include the following:
148
• Review of labels and labeling

• Stability studies
• Validation (process/product)
• Risk analysis
• Clinical evaluation
• Clinical studies or trials
• Literature search and predicate comparison
• Product and market evaluations
Multiple validations must be performed if there are different intended uses.
5.9.2. The results of all validation activities shall include the identification of
the design, method, date, results, and individual performing the validation. This
information will be maintained or referenced in the Design History File.
5.10. Design transfer phase (final review

and transfer of DMR)
5.10.1. After all verification and validation activities have been completed, the
project leader will call a design review meeting of the project team, plus the addi-
tion of one objective reviewer not directly responsible for the design stage being
reviewed. The purpose of the design review meeting is to ensure that the overall
design output has met the overall design input.
5.10.2. Any conflicting, ambiguous, or incomplete requirements shall be addressed
and resolved, and any final changes shall be documented on the Design Review
Meeting Form.
5.10.3. The design transfer review meeting will also include a final review of the
risk analysis to assess any additional potential hazards associated with the device
under normal and fault conditions not previously identified. Required changes
shall be identified on the Design Review Meeting Form. The RAMR will be
revised, as needed, and approved by all project team members at the final design
review meeting and included on the Design Change Form.
5.10.4. Any necessary changes will be identified and implemented prior to trans-
ferring design and development specifications and procedures to production spec-
ifications and procedures (e.g., the DMR). Changes shall be controlled using the
Design Change Form.
5.10.5. Completion and approval of the Design Transfer Checklist by the proj-
ect team shall indicate approval to proceed to the design release and approval
phase. Transfer of the DMR to production shall be documented using the Change
Request Form in accordance with applicable procedures. Any documents not pre-
viously transferred using the Design Change Form shall be identified and trans-
ferred using the Change Request Form.
149
5.11. Design release phase (approval for sale)

5.11.1. When all applicable documents are effective and marketing clearance has
been received from regulatory bodies (e.g., FDA 510(k) approval, Canada Medical
Device License, Europe CE Technical File), the project leader will initiate a final
design review meeting of the project team, plus the addition of one objective
reviewer not directly responsible for the design stage being reviewed. In addition,
members of management may be present, as applicable. The purpose of the meet-
ing will be to ensure that all project team members and executive management
agree on the relevance and suitability of the verification and validation results, all
documents and data necessary to ensure that the product is ready for distribution
are in place, and all members agree to proceed to launching the device as a formal
QARA Compliance Connection product.
5.11.2. An Approval for Sale Form will be completed, prior to product launch, to
document the confirmation from all project team members that all activities have
been completed and the device is ready for launch. The Approval for Sale Form
will be maintained in the Design History File. If members do not approve the
Approval for Sale Form, corrective measures shall be documented, and another
design review meeting will be scheduled to determine the device’s readiness
for release.
5.12. Post production design changes

5.12.1. Any changes once the design has been transferred to manufacturing shall
be made in accordance with Document and Change Control Procedures. Changes
shall be verified and validated, as necessary, and risks shall be assessed in accor-
dance with Risk Management Procedures prior to implementation of the change.
6.0. Record retention
6.1.
A Design History File shall be created for each new product and shall contain or
refer to the location of the records generated by this procedure.
6.2.
The project leader or designee will have responsibility for maintaining the Design
History File.
150
6.3.
The completed Design History File will be retained in accordance with the
Record Control Index.
Revision history
Rev Effective Date ECO/CR Number Description of Change
01 01-01-13 CR13-001 New procedure
151
Appendix B—QARA Compliance
Connection, Inc.: Product
performance specification
Project Leader:____________________________________________________
Product Name: ____________________________________________________
General description of device or system:
Performance definitions
Distinction should be made between desirable attributes (e.g., “want to haves”)
and essential requirements (e.g., “have to haves”). Layman terms should be used.
Customer expectations, safety, and satisfaction must be taken into consideration.
If certain requirements are unique for a market, then it should be indicated as
such within the appropriate section. Additional description areas may be added
as needed.
A. Performance characteristics
1. Indications for Use of Device (e.g., purpose):
Can the patient affect its use (e.g., limitations in hearing, sight, strength, etc.)?
153
Appendix B—Product performance specification
2. Clinical Procedure for Use (e.g., directions for use including assembly,
cleaning, disinfection, sterilization, inspection, and test):
3. Relevant Setting/Use Environment (e.g., home care, hospital, physician’s

office, nursing home, operating room, emergency room, ambulance):
4. Medical Specialty of User (e.g., doctor, nurse, technician, paramedic,

end user/layman):
Is any special training or special skills required to use the product?
5. Patient Population Inclusion/Exclusion Criteria (e.g., age, sex, color,

weight, height, disability):
6. User Interface/Ergonomic Considerations (e.g., one- or two-hand opera-

tion, size of print, color blindness, weight, size, portability, consideration
of special needs: elderly, children, handicapped):
B. Product characteristics
1. Functional Characteristics (dimensional: limits and tolerances, measur-
ing accuracy, color, shape, size, mobile or portable, etc.):
2. Chemical Characteristics (materials used; flammability; carcinogenic-

ity, toxicity, any chemical interactions of the product in preparation for
and during use: drugs [e.g., heparin], gases [e.g., oxygen], prep [e.g., wipe
downs], if applicable; material hardness, wear, and/or fatigue strength;
potential for substances to leach or leak from the device):
3. Biological Characteristics (indicate the maximum duration of product

use in vivo [wear time], body fluids, and tissue to which the item might
be exposed [degree of invasiveness/contact], toxicity, and biocompat-
ibility requirements):
154
4. Environmental Characteristics (describe anticipated conditions in trans-

port, storage, handling, and use: temperature, humidity, ESD, EMC,
shock, vibration, pressure, light, and/or any limitations; potential for
unintentional ingress or egress of substances into or from the device tak-
ing into account the device and its use environment):
5. Sterilization Characteristics (describe the type of sterilization to which

the product will be or can be exposed and the number of resterilizations
[doses] the product must be able to withstand, as applicable; cleaning and
disinfection/
reprocessing requirements; and disassembly/ reassembly
instructions):
Sterile or nonsterile Sterilized by the user Type of sterilization
Single use or reusable Number of reuse cycles
Single patient use or multiple patient use
6. Packaging (describe the packaging material and configuration in which

the product will be sterilized and/ or shipped, single-
use/
disposable
packaging, shelf life requirements, etc.):
7. Equipment Interface (describe any accessories necessary for use of the

product/device: e.g., power source, connections, and any compatibility
requirements; standardized units; etc.):
Also, are any medicines intended to be used with the device?
8. Safety and Reliability Requirements (e.g., known risks to users, patients,

and other persons during use or misuse; device maintenance or cali-
bration requirements; disposal requirements; software performance
requirements; need for audible or visual alarms; protection from ESD,
EMC, radiation [including ionizing, nonionizing, and ultraviolet/visible/
infrared radiation]; protection from mechanical risks: noise, vibration,
heat, electricity, etc.; protection posed by supplied energy or substances:
ionizing, nonionizing, ultraviolet/visible/infrared radiation, etc.):
155
C. Marketing requirements
1. Intended Marketplace (e.g., customer requirements, countries, key
markets/groups):
2. Labeling (product label, instructions for use, necessary precautions,

warnings, and contraindications, language requirements, symbols):
3. Claims (e.g., promotional claims, competitor’s features and claims to

which the device is to be compared, compliance/conformance with per-
formance standards, etc.):
4. Registration and Patent’s, Trademarks, and Licensing Agreements:
5. Clinical Information (evaluations, studies on predicate devices or simi-

lar devices):
D. Regulatory/quality assurance requirements

1. Classification of the Device (e.g., FDA, Europe, Canada, Japan, Australia,
etc.).
2. Market Approval Requirements (e.g., 510(k), PMA, Device Listing,

Medical Device License, CE Technical File, Notified Body Approval,
Establishment Registration, Authorized Representative, Marketing
Authorization Holder, etc.).
3. FDA Product Code: Regulation Number:
4. GMDN Code:
5. Relevant Regulatory or Statutory Requirements (e.g., standards/

test
methods: FDA, QSR, ISO 13485, 93/42/EEC [M5], ISO, ASTM, ANSI,
UL, EN, IEC, etc.):
6. MDR/MDV/Complaint Review (post-market data):
156
E. Financial requirements
1. Potential Market/Volumes (market the product/device is to perform in and
size):
2. Cost Projection:
3. Competitive Environment (e.g., competitors, strengths and weaknesses):
4. Proposed Forecast/Profit:
5. Capital Projection (e.g., tooling):
6. Percent Share of Market (e.g., estimated shares):
7. Total Opportunity:
8. Resource Assessment (e.g., facilities/space, personnel, systems, etc.):
9. Medicare/Reimbursement:
Revision history
Rev Revision Description/Reason for Change ECO Date
157
Appendix C—QARA
Compliance Connection, Inc.:
CE product claims sheet
Product/Product Family
Intended Use(s):
Product Claims: Supporting Data:
Warnings/Cautions:
Contraindications:
Approvals (Signature and Date):
Title/Function Date
Title/Function Date
Title/Function Date
Revision record
Rev Number Date ECO Number Description
159
Appendix D—QARA Compliance
Connection, Inc.: Design inputs
and associated outputs matrix
Product/Project____________________________________________________
Output(s)
Input (e.g., procedure, drawing, test method,
(Requirement/Specification) validation protocol, labeling, etc.)
161
Appendix E—QARA
Project approval form
Design Project Title

Project Leader:
Date Initiated:
Project/Product Description (goals and objectives, intended use):
Project Team:
Name: Title and Responsibility:
Independent:
Approval (signature): Date:

Project Leader:
CEO/COO:
163
Appendix F—Design
review meeting record
Project:
Design Review Meeting (Phase)
Date/Location:
Date:
Time:
Location:
Agenda:
Objective(s):
Attendees:
Function/ Team Role Sign In

Department Name or Title Signature/Date
165
Appendix F—Design review meeting record
Meeting Minutes:
Results/Review
Outcome
(Ver./Val.) Proposed Changes
Inputs Outputs Inputs = Outputs Conflicts/Comments
Decisions:
Issues/Action Items:
No. Description Owner Due Status
Approvals:
Signature confirms agreement that (a) this meeting as documented herein
occurred, (b) the listed attendees attended, (c) Project Decisions recorded herein
have been taken, and (d) the Action Items recorded herein in have been properly
dispositioned in writing and recorded in the DHF.
Title/Function Signature Date
166
Appendix G—QARA
Risk management plan
Product Name/Family:
Product Description:
Intended Use(s) and Intended User:
Evaluation Performed By Title/Function Signature Date
Revision History
Revision Description/Reason for Change ECO/PDCF No. Evaluation Date
167
Appendix G—Risk management plan
Heading:
Product Name/Family: Identify the product name or product family to which the
risk analysis pertains.
Product Description: Provide a brief description of the product.
Intended Use(s): Identify the intended use(s) of the product.
Evaluation performed by:

Record the names and titles of the individuals conducting the risk analysis.
Record the signature and date of each individual involved in the risk analysis.
Revision history:
Maintain the revision history for the risk analysis inclusive of a description of any
revision and/or the reason for revision (e.g., annual review, customer complaint(s),
nonconformance(s), literature search, field data, service data, etc.).
Record the Engineering Change Order (ECO) number or Product Development
Change Form (PDCF) number associated with the revision and the date of the review.
168
Risk Assessment ◻ Design ◻ Production ◻ Post-Production
Characteristics That Possible Hazard
Could Affect Safety Associated with Probability Risk Risk Probability Residual
(potential or Characteristic Probable of Potential Estimate Control of Potential Risk
real problems) (i.e., effect) Cause Occurrence Severity (L, M, H) Measure(s) Occurrence Severity (L, M, H)
Support Documentation (Attach) Yes No Comments

Sales Review
Post-Market Data Review (e.g., complaint history review, usability study)
Non-Conforming Product History Review (e.g., production problems (NCRs))
Predicate Device Data Review (e.g., adverse events, recalls, clinical evaluation, literature)
Conclusion: Overall Risk: ◻ Acceptable ◻ Not Acceptable
Comments: _________________________________________________________________________________________________________
_________________________________________________________________________________________________________________
_________________________________________________________________________________________________________________
169
Risk assessment: Identify the scope (i.e., life-cycle phase) of the assessment—
e.g., design, production, post-production.
Characteristics that could affect product, patient, and/or user safety:
i.e., problems
List all of those characteristics that could affect the device’s safety. Characteristics
should consider the following as applicable:
• Intended use or application of the device (e.g., intended user knowledge,
intended contact, duration/frequency of use, patient condition, con-
ditions for use, potential use error) improper use, re-use of single use
device, improper cleaning.
• Materials/Components used and/or accessories to the device (e.g., com-
patibility of materials, degradation of materials, toxicity, biological
safety of materials, physical and chemical characteristics).
• Risks from manufacture/assembly (e.g., contamination, residuals, incor-
rect assembly, incompatible accessory/substance, risk of substances
leaking from the device).
• Environmental factors (i.e., during transport, storage and use) (e.g., ESD,
EMC, temp, humidity, pressure, vibration, noise, fluorescent lighting,
risk of unintentional ingress from substances into device).
• Packaging (single or multi-use device, sterile or non-sterile) (e.g., pack-
age integrity, shelf life, useful life).
A non-encompassing list that may be used as a guide to identify characteristics is
provided in Appendix I of the Risk Management procedure.
Possible hazards associated with characteristics: (i.e., effect)
A hazard is a potential source of harm, resulting from a characteristic which
could affect safety. Compile a list of potential hazards (i.e., what happens if the
characteristic occurs) associated with the device in both normal and fault condi-
tions. A non-encompassing list of possible hazards and contributing factors is
given in Appendix II of the Risk Management procedure. For example; product
failure.
Probable cause:
Indicate the likely or probable cause of the problem.
Evaluation of risk:
Consider the probability of each hazard occurring and the associated implica-
tions (i.e., potential consequence/severity). For each possible hazard, estimate and
document the probability (e.g., 1,2,3,4,5), severity (e.g., A,B,C,D,E) and associ-
ated risk (e.g., Low, Medium, High) under both normal and fault conditions. Refer
to the Risk Assessment Matrix below and the Risk Management procedure for
assignment of risk.
170
SEVERITY (e.g., Result)

Catastrophic 1 HIGH
Critical 2
Serious 3 MEDIUM
Minor 4
Negligible 5 LOW
A B C D E
Frequent Probable Occasional Remote Improbable
PROBABILITY (e.g., Likelihood)
Risk control measures and responsible personnel: (i.e., mitigating actions)

Identify the action(s) taken to control and/or reduce any unacceptable risks
(e.g., design, testing, labeling) and responsible personnel. If the risk is high, per-
form a risk/benefit analysis and attach to RAMR form.
Residual risk:
Determine the residual risk (Low, Medium, High) after the control measures have
been implemented and verified.
Reviews performed/data analyzed: As applicable: (Y/N)
Document and/or attach sales data; the results of any post-market analysis
(i.e., complaint history review; the results of any nonconforming product history
review; and/or the results of any predicate device data review).
Overall risk:
Document if the overall risk is considered acceptable or unacceptable and docu-
ment any associated comments—e.g., acceptable risk taking into account the indi-
vidual hazards and control measures, production and/or post-market information.
171
Appendix H—QARA
Clinical evaluation report form
Device Name: Device Class:

Europe:
United States:
Manufacturer: Date:
General Description of Device (Provide a physical description of the device.):
Intended Application of Device (State the purpose of the device, duration of use, degree of
invasiveness, application.):
Intended Therapeutic and/or Diagnostic Indications and Claims (State the medical conditions to be
treated, outline any specific safety or performance claims.):
173
Appendix H—Clinical evaluation report form
Context of the Evaluation and Choice of Clinical Data Types (Is device based on a new
technology, a new clinical application of an existing technology, an existing technology, or an
incremental change of an existing technology. Is evaluation based on existing device data or an
equivalent device? Does device require the evaluation of any essential requirements related to
special performance or safety concerns?):
Summary of the Clinical Data and Appraisal (Identify clinical data used, appraisal process, and
relevance of data with regard to device performance and/or safety.):
Performance Data Analysis (Provide description of analysis used to assess performance.):
Safety Data Analysis (Describe the total experience with the device inclusive of device-related
adverse events and any user training requirements.):
Product Literature and Instructions for Use (Is product labeling consistent with clinical data
results? Address any hazards or other clinically relevant information.):
Conclusions (Provide conclusions reached about safety and performance, determination of whether
identified risks have been addressed to acceptable levels as evidenced by the clinical data,
statement of conformity with essential requirements.):
174
Appendix I—QARA Compliance
Connection, Inc.: Design
transfer checklist
Product/Project: Date:
Yes No NA
Is design verification testing complete and acceptable? ◻ ◻ ◻
Is design validation complete and acceptable? ◻ ◻ ◻
Is the risk analysis complete and up to date? ◻ ◻ ◻
Is the device master record (DMR) complete and include, as applicable: ◻ ◻ ◻
DMR index ◻ ◻ ◻
Bill of materials ◻ ◻ ◻
Component, material, subassembly, and finished product specifications ◻ ◻ ◻
Assembly drawings ◻ ◻ ◻
Manufacturing assembly/process procedures and specification ◻ ◻ ◻
Incoming inspection procedures ◻ ◻ ◻
Manufacturing in-process inspection and test procedures ◻ ◻ ◻
Finished product test and inspection procedures ◻ ◻ ◻
Labeling and packaging specifications and procedures, and acceptance criteria ◻ ◻ ◻
Device History Record (i.e., batch record) forms ◻ ◻ ◻
Copies of labeling (carton, product, instructions for use) ◻ ◻ ◻
Are supplier evaluations and approvals complete? ◻ ◻ ◻
Have equipment calibration and maintenance requirements been determined? ◻ ◻ ◻
Have personnel been trained? ◻ ◻ ◻
Have regulatory approvals been received? ◻ ◻ ◻
Has a change request been generated to release the product to production? ◻ ◻ ◻
Is the CE Technical File complete and include, as applicable: ◻ ◻ ◻
Essential Requirements Checklist (inclusive of Canada requirements) ◻ ◻ ◻
Technical Documentation Checklist ◻ ◻ ◻
Clinical Evaluation ◻ ◻ ◻
Product Claims Sheet ◻ ◻ ◻
Declaration of Conformity ◻ ◻ ◻
Product Classification Justification ◻ ◻ ◻
175
Appendix H—Design transfer checklist
Approvals:
Project Team Leader Date
Engineering Date
QA/RA Date
Marketing/Sales Date
Operations/Manufacturing Date
Purchasing/Production Planning Date
Other Date
176
Appendix J—QARA
Design change form
Product/Project Name:_____________________________________________
Date of Change:___________________________________________________
Proposed Changes:________________________________________________
Document From To Rationale
Approvals:
Project Team Leader Date
Engineering Date
QA/RA Date
Marketing Date
Operations Date
Other Date
177
Appendix K—QARA
Approval for sale
Product/Project Name:_____________________________________________
Project Team Leader:______________________________________________
Product Number(s):_______________________________________________
ECO Number:____________________________________________________
The activities detailed within this project are to be completed prior to obtaining
release for sale. If an activity has not been completed, and/or is not applicable, an
explanation in the form of a memo will be attached to the Approval for Sale Form.
Department/Individual Signature Date
Project Team Leader
Engineering
QA/RA
Marketing/Sales
Operations/MFG
Purchasing/Planning
COO/CEO
Other
Other
THE APPROVAL OF THIS DOCUMENT INDICATES THAT THE PRODUCT(S) DETAILED ABOVE HAS BEEN
APPROVED FOR SALE AND IS AVAILABLE FOR CUSTOMER PURCHASE.
179
References
ANSI/ASQC D1160-1995. “Formal Design Review.” 1995.

Bogner, M.S. “Medical Devices and Human Error.” In Human Performance in Automated Systems
Current Research and Trends, edited by M. Mouloua and R. Parasuraman, 64–67. Hillsdale, NJ:
Lawrence Erlbaum, 1994.
BS EN 62366:2008. “Medical Devices: Application of Usability Engineering to Medical Devices.”
2008.
Donawa, Maria E. “European Medical Device Usability Requirements.” European Medical
Device Technology, May 27, 2011.
Draft Guidance for Industry and Food and Drug Administration Staff. “Applying Human Factors
and Usability Engineering to Optimize Medical Device Design.” June 22, 2011.
FDA. “Design Control Guidance for Medical Device Manufacturers.” March 11, 1997.
FDA. “Design Input Guidance,” The Silver Sheet. June 1997, 11–14.
FDA. “FDA Medical Device 2010 Quality System Data: Analysis of 2010 Warning Letter Cites.”
July 27, 2011.
FDA. “Guidance for Industry: Q9 Quality Risk Management.” ICH, June 2006.
FDA. “Guide to Inspections of Quality Systems: Quality System Inspection Technique: QSIT.”
August 1999.
FDA. “Quality System Final Rule,” The Silver Sheet. Subpart C: Design Controls. June 1997.
FDA QSIT Workshop, Orlando, FL, Oct. 1999.
Federal Register. 21 CFR Part 820.30. 1996.
“Final Design Control Inspectional Strategy, CDRH.” February 1998, 1–10.
Gad, Shayne Cox. Safety Evaluation of Medical Devices. New York: Marcel Dekker, 2002.
GHTF SG3 N15-R8. “Risk Management in Design Control,” p. 20. May 20, 2005.
GHTF SG3 N99-8. “Guidance on Quality Systems for the Design and Manufacture of Medical
Devices.” June 29, 1999.
GHTF SG3 N99-9. “Design Control Guidance for Medical Device Manufacturers.” June 29, 1999.
ISO 13485. “Medical Devices—Quality Management Systems—Requirements for Regulatory
Purposes.” 2003.
ISO 14971:2009. “Medical Devices—Application of Risk Management to Medical Devices.”
2009.
ISO 9001:2008. “Quality Management Systems—Requirements.” 2008.
ISO Standard 10993. “Biological Evaluation of Medical Devices.” Parts 1–20. 2009.
Lister, Laurence. “Biocompatibility Testing: Tips for Avoiding Pitfalls, Part 2.” MDDI Medical
Device and Diagnostic Industry, February 1, 2010.
MEDDEV 2.7/4. Clinical Evaluation: A Guide for Manufacturers and Notified Bodies. European
Commission, Directorate General for Health and Consumers, December 2010.
Medicines and Healthcare Products Regulatory Agency. “Guidance on the Biological Safety
Assessment.” London, January 2006.
181
References
Nobel, J.L. “Medical Device Failures and Adverse Effects,” Pediatric Emergency Care 7 (1991):
120–23.
Saliterman, Steven S. “Biocompatibility, FDA and ISO 10993.” Department of Biomedical
Engineering, University of Minnesota. n.d.
Sawyer, Dick. “Do It by Design: An Intro to Human Factors in Medical Devices.” FDA, December
1996.
Stark, Nancy J., and Dan McLain. “Medical Device Biocompatibility.” Clinical Device Group,
May 2011.
Teixeira, Marie B. Design Controls Training Module. Odessa: QARA Compliance Connection, 2011.
Teixeira, Marie, and Richard Bradley. Design Controls for the Medical Device Industry. New
York: Marcel Dekker, 2003.
US Department of Health and Human Services, Food and Drug Administration, Center for
Devices and Radiological Health, Division of Device User Programs and Systems
Analysis, Office of Health and Industry Programs. “Medical Device Use-Safety:
Incorporating Human Factors Engineering into Risk Management.” July 18, 2000.
Use of International Standard ISO 10993. “Biological Evaluation of Medical Devices Part 1:
Evaluation and Testing.” Blue Book Memorandum G95-1. May 1, 1995.
182
Biomedical Engineering
Design Controls
For the
MEDICAL DEVICE
InDustry
sECOnD EDItIOn
the second edition of a bestseller, Design Controls for the Medical Device
Industry provides a comprehensive review of the latest design control
requirements, as well as proven tools and techniques to ensure your
company’s design control program evolves in accordance with current
industry practice. the text assists in the development of an effective design
control program that not only satisfies the us FDA Quality system regulation
(Qsr) and IsO 9001 and 13485 standards, but also meets today’s third-party
auditor/investigator expectations and saves you valuable time and money.
the author’s continual participation in FDA Qsr inspections and notified Body
IsO audits is reflected in updates to all chapters and appendices of the book,
now bursting at the seams with
• new coverage of IsO 9001 and 13485 design control requirements
• More real-world examples from the medical device industry
• Additional detail for greater understanding and clarity
• Fresh templates for practical implementation
• Extensive references for further study
the book addresses design control elements such as design planning, input,
output, review, verification, validation, change, transfer, and history, as well
as risk management inclusive of human factors and usability, biocompatibility,
the FDA Quality system Inspection technique (QsIt) for design controls, and
medical device regulations and classes in the us, Canada, and Europe.
K14470
ISBN: 978-1-4665-0354-0
90000
9 781466 503540

Design Controls For The MEDICAL DEVICE InDustry

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Design Controls For The MEDICAL DEVICE InDustry

Загружено:

Авторское право:

Доступные форматы

Marie B.

© 2014 by Taylor & Francis Group, LLC

No claim to original U.S. Government works

International Standard Book Number-13: 978-1-4665-0355-7 (eBook - PDF)

and the CRC Press Web site at

3 Overview of design controls . . . . . . . . . . . . . . . . . . . 9

4 Design and development planning . . . . . . . . . . . . . . 17

Design validation requirements 100

13 Design transfer . . . . . . . . . . . . . . . . . . . . . . . . . . 123

14 Design change . . . . . . . . . . . . . . . . . . . . . . . . . . 127

15 Design history file . . . . . . . . . . . . . . . . . . . . . . . . 131

16 The FDA inspection technique . . . . . . . . . . . . . . . 135

Appendix A—QARA Compliance Connection, Inc.: Design

Appendix D—QARA Compliance Connection, Inc.: Design

impossible, to include every opinion or interpretation of the requirements or

Teixeira holds a BS in industrial engineering and operations research from the

What is “design control”?

Why design controls?

allocation of resources to product development.* The FDA published the revised

FDA inspections reveal deficiencies

* The proportion was even greater for software-­related recalls at 90 percent.

Table 1.1 Design Control Subsystem

In Europe, device classification is determined using Annex IX of the Medical

Table 2.1 Medical Device Classes

Table 2.2 FDA’s Classification of Medical Devices

Table 2.3 Europe’s Classification of Medical Devices

Table 2.4 Canada’s Classification of Medical Devices

Design controls and the bottom line

Table 3.1 Class 1: Design Control Applicability

When might design controls be considered?

What are the benefits of design control

Ask the customers

Design controls and the customer

First phase: Definition and documentation

Definition Design V&V Transfer Pilot/Production

Figure 3.1 Design and development.

Second phase: inputs = outputs

Third phase: Verify and validate

Fourth phase: Transfer is inevitable

Fifth phase: Improvement and optimization

Do we really need a plan?

Design and development planning requirements

So what makes up the plan?

When is a good time to use a Gantt chart?

Figure 4.1 Gantt chart.

When might a Gantt chart not be appropriate?

What are the advantages of using PERT charts?

When might PERT charts not be appropriate?

06/11/12 06/15/12 06/15/12 08/15/12

All 1 Day Engineering/ 3 months

01/03/12 02/15/12 RA 3 months

Draft Initial Product Claims

Figure 4.2 PERT chart.

Microsoft Project© is a prime example of a software program that is available to

Project planning: How do I get started?

What are design inputs?

The foundation: Design input

Design input requirements

• Inputs need to identify the critical functional, performance, safety, and

The concept document

• A statement of the intended claims: What indications would you like to be

Product performance specification

Product/Project Name: Manometer (Disposable) Initiation Date: 06/01/2012

* The proportion was even greater for software-related recalls at 90 percent.

Author: _________________________ Date:

Relevant setting/use environment

Patient population: Inclusion/exclusion criteria

User interface/ergonomic considerations

Product/Product Family: Tracheostomy Tubes

Product Claims Supporting Data (reference report/test numbers)

Stage 2: Mid-project design reviews The objective of these mid-project design