Design Controls For Medical Devices - Part 4

Design Controls for Medical Devices: Part 4–Implementing the requirements of ISO 13...
Página 1 de 15
SEARCH
advanced search
Site Map Contact Help
Advertising
Professional Meetings & Publications & Members &

Development Training Certification Resources Bookstore Chapters Abou
INSIDE: Home Resources RA Focus Archives February

Current Issue 2005
Search
Archives
Writing for Focus
Regulatory Affairs Letter to the Editor
Email this page

Reprints
Editorial Calendar Focus Magazine Print this page
Departments
Archives
Member Login
Member ID: February 2005: Advertising, Labeling
and Promotion
Password:
Design Controls for Medical Devices:
Remember me Part 4–Implementing the requirements
Login of ISO 13485: 2003, ISO 14971:2000
and 21 CFR § 820.30 for the design of More Related Items
Forgot your medical devices
password?
Martin D. Sargent and Colin D. Jackson
Need Help? Related Products
The fourth article in this five part series Regulatory Update: US

Not a member? Medical Devices
discusses design outputs, verification testing Webcast (DV351)
Join us! Learn more...
and requirements traceability.
Fundamentals of US
Regulatory Affairs,
DESIGN OUTPUTS Fifth Edition (GN512)
Section 7.3.3 of ISO 13485:2003 states: Related Conferences

10 March 2008
The outputs of design and development shall Principles &
be provided in a form that enables Practices of EU and
US Medical Devices
verification against the design and
development input and shall be approved 12 November 2007
Principles &
prior to release. Design and development Practices of EU and
outputs shall: US Medical Devices
a) meet the input requirements for design Related Articles

and development,
A New Era of Risk
Management in the
b) provide appropriate information for Medical Devices
purchasing, production and for service Industry
provision, Device Design and

Improvements to ISO
13485, Clause 7.3
c) contain or reference product acceptance
criteria, and
http://www.raps.org/s_raps/rafocus_article.asp?TRACKID=&CID=61&DID=24839 20/7/2007
Design Controls for Medical Devices: Part 4–Implementing the requirements of ISO 13... Página 2 de 15
d) specify the characteristics of the product

that are essential for its safe and proper use.
Records of the design and development

outputs shall be maintained (see 4.2.4).
Note: Records of design and

development outputs can include
specifications, manufacturing
procedures, engineering drawings, and
engineering or research logbooks.1
Section 820.30(g) of 21 CFR § 820

states:
Each manufacturer shall establish and

maintain procedures for defining and
documenting design output in terms that
allow an adequate evaluation of conformance
to design input requirements. Design output
procedures shall contain or make reference
to acceptance criteria and shall ensure that
those design outputs that are essential for
the proper functioning of the device are
identified. Design output shall be
documented, reviewed, and approved before
release. The approval, including the date and
signature of the individual(s) approving the
output, shall be documented.
The US Code of Federal Regulations defines

design output as the result of a design effort
at each design phase and at the end of the
toal design effort. The finished design output
is the basis for the device master record. The
total finished design output consists of the
device, its packaging and labeling, and the
device master record2.
Examples of design outputs include assembly

drawings, component and material
specifications, production and process
specifications, software machine code (e.g.,
diskette or master EPROM), work
instructions, quality assurance specifications
and procedures, installation and servicing
procedures, and packaging and labeling
specifications including methods and
processes used.
ATTRIBUTES OF DESIGN OUTPUT
Design outputs:
z meet design input requirements.

z are provided in a form that allows
adequate evaluation of conformance to
design input requirements and enables
verification against the design inputs.
z provide appropriate information for
purchasing, production and servicing.
z contain or reference product
acceptance criteria.
z specify the characteristics of the
device, its packaging and labeling that
are essential for its safe and proper
use.
z are uniquely numbered and revision
controlled
z are documented, reviewed and
approved before release.
z are released prior to formal design
review and associated purchase,
fabrication, verification or validation
activities.
z are maintained in the design history
file.
21 CFR § 820.30(d) requires manufacturers

to establish and maintain procedures for
defining and documenting design output in
terms that allow an adequate evaluation of
conformance to design input requirements.
The preamble to the quality system
regulation states design outputs are the
design specifications that should meet design
input requirements, as confirmed during
design verification and validation and
ensured during design review5.
21 CFR § 820.30(d) requires that design

output procedures contain or make reference
to acceptance criteria. Typically, acceptance
criteria are specified through limits and
tolerances on assembly drawings,
component and material specifications,
production and process specifications, and
quality assurance specifications, among
others. Many manufactures implement
drawing conventions to denote critical
specifications, tolerances and required
acceptable quality limits (AQL). These types
of conventions can promote good
engineering practices, providing a formalized
way for engineers and designers to indicate
the specifications crucial to ensuring proper
functioning of the device.
Additionally, 21 CFR § 820.30(d) requires

that design output procedures ensure that
those design outputs that are essential for
the proper functioning of the device are
identified. The methods used by the
manufacturer for determining those essential
design outputs should be documented in the
project design and development plan, as well
as the governing standard operating
procedures (SOPs). One or more of the
following techniques may be used to identify
design outputs essential for the proper
functioning of the device:
z Failure analysis such as Fault Tree

Analysis (FTA), Failure Modes and
Effects Analysis (FMEA), Failure Modes
and Effects Criticality Analysis (FMECA)
or Hazard and Operability Study
(HAZOP)
z Known issues associated with specific
technologies, scientific literature,
customer complaints or service
histories of similar devices
z best experience, insight and
engineering judgment in using a
technology
The central idea is to identify those portions

of a design that are necessary and
indispensable to satisfy the user needs for
the intended uses. In essence, a critical list
of the components or subsystems that would
render the device unable to fulfill its
intended purpose, or worse, cause harm to
users, patients, bystanders, service
personnel or the environment. Consider a
hemodialysis machine and envision the
design outputs critical to the proper function
of the device. Failure analysis might reveal
the peristaltic pump assembly, among many
others, as a design output essential for the
proper functioning of the device. The design
output SOP in place should provide a
mechanism to identify this output as
essential, and given this status, one would
hope to see a commensurate level of design
and testing consideration.
Conversely, manufacturers of devices that

present low levels of risk to public health
may elect to identify all design outputs as
essential for the proper functioning of the
device.
DESIGN OUTPUTS VERSUS DESIGN DELIVERABLES
To clarify the difference between design

outputs and design deliverables, remember
that design outputs satisfy design inputs,
while design deliverables satisfy planning
requirements. Examples of design outputs
include assembly drawings, component and
material specifications, production and
process specifications, software (e.g.,
diskette or master EPROM), work instructions
and quality assurance specifications and
procedures. Examples of design deliverables
include design outputs, user needs
documents, design inputs, design and
development plans, quality plans, risk
management plans and reports, design
review reports, verification and validation
plans and reports, and requirements
traceability reports.
VERIFICATION TESTING
Section 7.3.5 of ISO 13485:2003 states:
Verification shall be performed in

accordance with planned arrangements
(see 7.3.1) to ensure that the design
and development outputs have met the
design and development input
requirements. Records of the results of
the verification and any necessary
actions shall be maintained (see
4.2.4).1
Section 820.30(f) of 21 CFR § 820 states:
Each manufacturer shall establish and

maintain procedures for verifying the
device design. Design verification shall
confirm that the design output meets
the design input requirements. The
results of the design verification,
including identification of the design,
method(s), the date, and the individual
(s) performing the verification, shall be
documented in the design history files
(DHF).
The US Code of Federal Regulations defines

verification as confirmation by examination
and provision of objective evidence that
specified requirements have been fulfilled 3.
The top-level verification activity is termed
"design verification" and refers to the test

activities performed to ensure the results of
a finished design effort meet the formally
documented design input requirements.
Design verification is performed per test
protocols containing predetermined
acceptance criteria based on each design
input requirement. Design verification test
reports document the objective evidence and
determine if acceptance criteria have been
satisfied.
Design verification test reports may refer to

results of other test reports as objective
evidence.
Consider a design input requirement for a

device to meet the applicable requirements
of IEC 60601-1:1988/A1:1991/A2:1995. The
design verification test protocol for this
design input might be to review an
independent third party safety testing report
for a conclusion that the applicable
requirements of IEC 60601-
1:1988/A1:1991/A2:1995 have been met,
and the report data supports the pass/fail
conclusion. The associated test report might
then refer to the test report document from
the independent third party safety test and
the actual pass/fail status.
It is important to ensure that design

verification activities are comprehensive with
respect to all of the interrelated processes
required to manufacture a device. To be
most effective, design verification should be
performed using devices that undergo the
same manufacturing and acceptance
processes as the final production devices.
Consider a design verification activity
performed on a device built and tested by a
select group of highly trained engineering
technicians using prototype parts received
and inspected by project engineers. The
results may be very different if performed on
a device manufactured by production
employees using initial production parts and
procedures.
Many manufacturers create a "pre-

production" manufacturing process that
provides an opportunity for manufacturing,
engineering, and quality assurance personnel
to build design verification test units using
draft manufacturing and inspection

instructions. These interactions between
manufacturing and engineering provide
feedback to the design and development
process and provide a basis for effective
design transfer.
There may be additional levels of verification

subordinate to "design verification," which
we will call "detailed design verification."
Detailed design verification refers to the test
activities performed to ensure design results
meet formally documented, detailed design
requirements.
Remember that formal documentation of the

detailed design may be contained in the
design input document (solution-based
design input), in a subordinate detailed
design document or only in design output,
such as a drawing or schematic diagram. A
manufacturer may choose not to implement
formal detailed design documents, in which
case formal detailed design verification
would not be performed.
For each formal detailed design document,

there should be a detailed design verification
protocol and test report to document that
detailed design requirements were satisfied.
Detailed design verification is performed per
test protocols containing predetermined
acceptance criteria. Detailed design
verification test protocols should be written
to test each detailed design requirement.
Detailed design verification test reports
document the objective evidence and the
determination if acceptance criteria have
been satisfied.
Consider that a detailed design document

specifying a printed circuit board design
must meet the applicable requirements of
IPC 2221/IPC 2222.4 The detailed design
verification test protocol for this detailed
design requirement could list the applicable
requirements IPC 2221/IPC 2222 clause by
clause, or review results of a separate IPC
2221/IPC 2222 compliance test report for a
conclusion that the applicable requirements
of the standard have been met. The
associated test report might then list or refer
to the objective evidence and the actual
pass/fail status.
Detailed design verification may address

material composition testing, performing
alternative calculation methods, stacked
tolerance calculations and automated design
rule checks, among others. Engineers
routinely perform redundant or alternative
checks informally to help ensure design
results will meet design requirements. These
additional levels of verification are
subordinate to "detailed design verification,"
which we will call "informal testing."
Manufacturers should define policies within
engineering organizations to document these
informal test activities in lab notebooks,
project notes or similar means. Informal test
activities may include:
z comparison of a design to a previous

product having an established history
of successful use
z stacked tolerance calculations
z alternate calculations to verify circuit
design
z design rule checks (DRC) of printed
circuit board (PCB) files
z checks of PCB netlists, hole diameters,
critical trace placements
z electrical ground system configuration
z worst case analysis of an assembly to
verify that components are not subject
to overstress during handling and use
z thermal analysis of an assembly to
assure that internal or surface
temperatures do not exceed specified
limits
z trial assembly of prototype
components
z testing by users unfamiliar with the
device
Verification testing should not be confused

with production testing. The goal of
verification testing is to ensure design
results satisfy design requirements. The goal
of production testing is to ensure a device
has been manufactured correctly. Production
testing is seldom comprehensive enough to
verify a design, but rather focuses on
identification of potential component and
manufacturing defects.
Consider modern requirements for

electromagnetic compatibility (EMC). As with
many design characteristics, electromagnetic
radiation and susceptibility are generally

tested during design verification for the EMC
design input requirement. When the final
design has passed EMC testing, routine
manufacturing testing for EMC is generally
not performed.
Statistical Requirements
Verification protocols should include

statistical requirements that will dictate
sample sizes and acceptance criteria,
reflecting the quality goals for the device
stated in the design quality plan. Generally,
the use, where possible, of variable data
(versus attribute data) may reduce required
sample sizes while maintaining statistical
confidence levels.
VERIFICATION TEST PROTOCOL CONTENTS
Verification test protocols should include the

following sections:
z date prepared
z prepared by
z related documents
z definitions
z required equipment
z defined operating conditions
{ environmental conditions (e.g.,
temperature, humidity, altitude)
{ other medical devices in use
during the verification activities
z identification of the design under test
{ references to released drawing
numbers with revision levels
{ references to uniquely identified
and documented prototypes or
finished devices, which include
drawings or specifications as
appropriate
finished devices where the
prototype is retained in the
design history file
{ photographs of prototypes or
finished devices under test with
supporting drawings or
specifications as appropriate
z verification tests
{ each test to be performed to
verify that the design meets the
Design Controls for Medical Devices: Part 4–Implementing the requirements of ISO ... Página 10 de 15
design input
{ any data required to be recorded
during the test
{ criteria used to determine if the
test passes or fails
z acceptance criteria
{ criteria used to determine if the
entire protocol passes
z statistical confidence
{ the minimum statistical
confidence level as defined in
each specific design quality plan
z revision history of the protocol
z review and approval
VERIFICATION TEST REPORT CONTENTS
Verification test reports should include the

following sections:
z document title
z number and revision level
z date
z name(s) of the individual(s) who
prepared the test report
z table of contents
z scope
z related documents
z definitions
z identification of the design
{ references to released drawing
numbers with revision levels
finished devices, with drawings
or specifications as appropriate
finished devices where the
prototype is retained in the
design history file
{ photographs of prototypes or
finished devices under test, with
supporting drawings or
specifications as appropriate
z defined operating conditions
{ environmental conditions (e.g.
temperature, humidity, altitude)
{ other medical devices in use
during the verification activities
z equipment section listing each item of
test equipment used in verification
testing with the calibration due dates
z test personnel
z design verification test results

{ each test performed, by
complete description or by
protocol reference
{ identification of the test
personnel that performed each
test
{ any data required to be recorded
for each test
{ the actual pass/fail status for
each test
z test personnel signatures
z conclusions section stating the
pass/fail status of the test activity,
including the statistical confidence
level indicated by the test results
z revision history of the report
z review and approval
REQUIREMENTS TRACEABILITY
Requirements traceability is a quality tool

used to ensure all functional and safety
requirements have been implemented in the
final product. Requirements traceability
should mark the trail of:
z each user need to the design input(s)

that satisfies the need;
z each identified risk to the
corresponding risk reduction measure
(s);
z each risk reduction measure to the
design input(s) that satisfies the safety
requirement;
z each design input to the detailed
design requirement(s) that satisfies
the design input;
z each detailed design requirement to
detailed design verification test that
verifies the detailed design
requirement;
z each design input requirement to
design verification test that verifies the
input requirement; and
z each user need to design validation
test that validates the need has been
met.
Methods of requirements traceability range

from manually inserted text identifiers in
traced documents to automated software
solutions. Traceability of requirements may
be addressed through the creation of a
"traceability matrix table," which assigns

unique tag numbers to each design input
requirement. These tag numbers are then
transferred to each succeeding phase of
design, through the requirement
specification(s), detailed design documents
(s), detailed design verification test
protocols, design verification test protocols
and design validation test protocols.
It should be noted that verification and

validation testing provide an adequate
mechanism to ensure that all functional and
safety-related requirements are
implemented in the final product, especially
if all requirements are tested in a one-to-one
fashion where the numbering of the test
protocol follows the numbering of the
requirement or specification document. One-
to-one testing ensures each functional and
safety-related requirement is satisfied in the
finished device, its labeling and packaging.
When test protocols do not provide one-to-
one testing of requirements, verification
activities to ensure each requirement is
traceable and implemented in the final
design can become very tedious and prone
to error.
EVALUATION OF DESIGN INPUTS TO DESIGN OUTPUTS
Confusion may exist between "requirements

traceability," a common completeness and
accuracy evaluation technique documented
in published FDA guidance, and "design input
to design output traceability," which has
never been a suggested practice of any
design control system based on the
harmonized European ISO 9001:1987
model.
FDA has clearly documented that evaluation

of design inputs to design outputs, as
required by 21 CFR § 820.30(d), is
accomplished through design verification,
design validation and design review
activities,3, 4, 5, 6 not the activity of tracing
design inputs to design outputs. Consider a
design input requiring the steering yoke of
an aircraft to shake when the nose of the
aircraft dips below a certain angle (generally
accompanied by the aural command, "Pull
up!"). Tracing this design input to the
associated design outputs implementing this
functionality would yield a list of perhaps

1000 design outputs in a modern aircraft, an
ineffective use of valuable resources that
provides little or no increase in safety or
reliability. A much more effective strategy to
ensure the design input has been
implemented in the finished aircraft is to
trace the design requirement to the
verification test demonstrating that the yoke
begins shaking when the nose angle falls
below the specified value.
Consider the design input, "The design shall

meet the requirements of IEC 60601-
1:1988/A1:1991/A2:1995," an important
electrical safety requirement for mains-
powered medical equipment. To trace this
input to the associated design outputs of an
electrical medical device would require the
identification of virtually all design outputs
created, including electrical, mechanical,
labeling, packaging, instructions for use, etc.
This activity is a poor use of valuable
resources that provides little or no increased
confidence in the equipment.
If a manufacturer wishes to provide

additional assurance that the finished device
meets the requirements of IEC 60601-1, a
much more effective strategy is to
implement the requirements traceability
technique per the FDA guidance, The Medical
Device Quality Systems Manual: A Small
Entity Compliance Guide, First Edition,
December 1996, HHS/FDA/CDRH, HHS
Publication FDA 97-4179 Section 3, "Design
Output, Documenting Design Output (1)."
FDA does not advocate the technique of

tracing design inputs to design outputs in the
quality system regulation (QSR), the
preamble to the QSR regulation, or in
published FDA guidance documents, nor
should they. Design input to design output
tracing is not an appropriate use of design
and development resources. It does not
provide substantiation that functional and
safety-related requirements have been
implemented in the final finished device, and
diverts resources from activities that could
provide for safer and more reliable medical
devices.
The final article in this series discusses
design transfer, design and development

review, control of design and development
changes, and design history files.
Examples of design verification and design

traceability documents may be obtained
free-of-charge from Regulated Engineering
Services, Inc. A password is required for
download. Please email document requests
to (articles@regulatedeng.com). Comments
may be emailed to
(comments@regulatedeng.com).
ACKNOWLEDGEMENTS
The authors wish to thank Christine S.

Guidry of Bayer HealthCare, LLC, Biological
Products Division for her contributions to this
article series.
Martin D. Sargent is the president and

principal regulatory consultant of Martin D.
Sargent & Associates, Inc. His device
experiences include intraoperative
neurophysiological monitoring, intracardiac
electrophysiology, cardiac catheterization,
and active implantable devices.
Colin D. Jackson is the president and

principal engineer of Regulated Engineering
Services, Inc. His device experiences include
ophthalmic devices, life-support ventilators,
and active implantable devices. His military
design experiences include optical systems
and laser interferometers.
NOTES
1. International Organization for

Standardization (ISO). This material is
reproduced from 13485:2003 with
permission of the American National
Standards Institute on behalf of ISO. No part
of this material may be copied or reproduced
in any form, electronic retrieval system or
otherwise or made available on the Internet,
a public network, by satellite or otherwise
without the prior written consent of the
American National Standards Institute
(ANSI) 25 West 43rd Street, New York, NY
10036. Copies of this standard may be
purchased from the ANSI, (212) 642-4900,
http://webstore.ansi.org
2. As defined in 21 CFR § 820.3(g).
3. As defined in 21 CFR § 820.3(aa).
4. IPC 2221 Generic Standard on Printed

Board Design, IPC 2222 Sectional Standard
On Rigid Organic Printed Boards, Institute for
Interconnecting and Packaging Electronic
Circuits (IPC).
5. Federal Register / Vol. 61, No. 195 /

Monday, October 7, 1996 / Rules and
Regulations 52619, Comment 76.
6. Federal Register / Vol. 61, No. 195 /

Monday, October 7, 1996 / Rules and
Regulations 52619, Comment 77.
7. FDA Guide to Inspections of Quality

Systems, (QSIT), August, 1999, Design
Control Subsystem, Question 5.
8. FDA guidance document, Design Control

Guidance for Medical Device Manufacturers,
Center for Devices and Radiological Health,
March 11, 1997, Section D, Pages 20-21.
9. FDA guidance document, The Medical

Device Quality Systems Manual: A Small
Entity Compliance Guide, First Edition,
December 1996, HHS/FDA/CDRH, HHS
Publication FDA 97-4179 Section 3, Design
Output.
© 2007, Regulatory Affairs Professionals Society

Making better healthcare products possible
5635 Fishers Lane, Suite 550, Rockville, MD 20852
Phone: 301.770.2920 Fax: 301.770.2924 Email: raps@raps.org
Privacy Policy, Terms of Use
Site Index

Design Controls For Medical Devices - Part 4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Design Controls For Medical Devices - Part 4

Uploaded by

Copyright:

Available Formats

Design Controls for Medical Devices: Part 4–Implementing the requirements of ISO 13...

Professional Meetings & Publications & Members &

INSIDE: Home Resources RA Focus Archives February

Email this page

The fourth article in this five part series Regulatory Update: US

Section 7.3.3 of ISO 13485:2003 states: Related Conferences

a) meet the input requirements for design Related Articles

provision, Device Design and

d) specify the characteristics of the product

Records of the design and development

Note: Records of design and

Section 820.30(g) of 21 CFR § 820

Each manufacturer shall establish and

The US Code of Federal Regulations defines

Examples of design outputs include assembly

ATTRIBUTES OF DESIGN OUTPUT

z meet design input requirements.

21 CFR § 820.30(d) requires manufacturers

21 CFR § 820.30(d) requires that design

Additionally, 21 CFR § 820.30(d) requires

z Failure analysis such as Fault Tree

The central idea is to identify those portions

Conversely, manufacturers of devices that

DESIGN OUTPUTS VERSUS DESIGN DELIVERABLES

To clarify the difference between design

Section 7.3.5 of ISO 13485:2003 states:

Verification shall be performed in

Section 820.30(f) of 21 CFR § 820 states:

Each manufacturer shall establish and

The US Code of Federal Regulations defines

"design verification" and refers to the test

Design verification test reports may refer to

Consider a design input requirement for a

It is important to ensure that design

Many manufacturers create a "pre-

draft manufacturing and inspection

There may be additional levels of verification

Remember that formal documentation of the

For each formal detailed design document,

Consider that a detailed design document

Detailed design verification may address

z comparison of a design to a previous

Verification testing should not be confused

Consider modern requirements for

radiation and susceptibility are generally

Verification protocols should include

VERIFICATION TEST PROTOCOL CONTENTS

Verification test protocols should include the

VERIFICATION TEST REPORT CONTENTS

Verification test reports should include the

z design verification test results

Requirements traceability is a quality tool

z each user need to the design input(s)

Methods of requirements traceability range

"traceability matrix table," which assigns

It should be noted that verification and

EVALUATION OF DESIGN INPUTS TO DESIGN OUTPUTS

Confusion may exist between "requirements

FDA has clearly documented that evaluation

functionality would yield a list of perhaps

Consider the design input, "The design shall

If a manufacturer wishes to provide

FDA does not advocate the technique of