Design Controls For Medical Devices - Part 1

Design Controls for Medical Devices: Part 1—User Needs and Project Planning 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 November 2004

Current Issue
Search
Archives
Regulatory Affairs Focus
Writing for Focus
Reprints Magazine
Editorial Calendar
Departments
Archives
Member Login November 2004: Over-the-Counter Products
Member ID:
Design Controls for Medical Devices: Part 1—User Needs and

Password: Project Planning
Martin D. Sargent and Colin D. Jackson
Remember me
Login
This is the first in a five-part series of features about implementing the
requirements of ISO 13485:2003, ISO 14971:2000 and 21 CFR § 820.
Forgot your for the design of medical devices. These articles are intended to share
password? authors’ experiences with and insights into the implementation of the
Need Help?
International Organization for Standardization (ISO) design control
model.
Not a member?
Join us! Learn more...
This series is organized into five articles on the following topics:
1. User needs and project planning

2. ISO 14971:2000 risk management
3. Design inputs
4. Design outputs, design verification and requirements traceability
5. Design review, design transfer, control of design changes, design
validation and design history files
Because design controls must apply to a wide variety of products, the I

model does not prescribe the practices that must be used. Instead, ISO
provides a framework that manufacturers must use when developing a
implementing design controls. The framework provides manufacturers
with the flexibility needed to develop design controls that are most
appropriate for their own design and development processes. Figure 1
depicts an example flow diagram of the initial portions of a product
realization process. Additional portions of this example diagram will be
shown in future articles.
PLANNING OF PRODUCT REALIZATION
Section 7.1 of ISO 13485:2003 states:
http://www.raps.org/s_raps/rafocus_article.asp?TRACKID=&CID=61&DID=24420 20/7/2007
The organization shall plan and develop the processes needed for
product realization. Planning of product realization shall be
consistent with the requirements of the other processes of the
quality management system (see 4.1). In planning product
realization, the organization shall determine the following, as
appropriate:
a) quality objectives and requirements for the product;
b) the need to establish processes, documents, and provide

resources specific to the product;
c) required verification, validation, monitoring, inspection and tes

activities specific to the product and the criteria for product
acceptance;
d) records needed to provide evidence that the realization

processes and resulting product meet requirements (see 4.2.4).
The output of this planning shall be in a form suitable for the

organization’s method of operations. The organization shall
establish documented requirements for risk management
throughout product realization. Records arising from risk
management shall be maintained (see 4.2.4).
NOTE 1 A document specifying the processes of the quality

management system (including the product realization processes
and the resources to be applied to a specific product, project or
contract, can be referred to as a quality plan.
NOTE 2 The organization may also apply the requirements given

7.3 to the development of product realization processes.
NOTE 3 See ISO 14971 for guidance related to risk management
IN THE BEGINNING . . .
The Greek philosopher Plato said, "the beginning is the most important
part of the work." Sir John Hardy observed that "planning is an unnatu
process; it is much more fun to do something."
For the unenlightened, planning activities are at best a drudgery and a

worst an onerous regulatory requirement. At their finest, planning
activities and their associated documents provide clear and concise
overviews of the predefined goals, tasks and activities required to
accomplish a design objective.
PLANNING METHODS
Numerous planning methods exist, ranging from simple spreadsheets a

flowcharts to feature-rich resource planning software tools. Regardless
the method used, all plans need to contain the same basic information
identification of the major tasks and activities, the personnel assigned
responsibility for each major task and activity, and the associated
schedules or timelines.
TYPES OF PLANNING
Planning activities should include design and development planning,

quality planning, risk management planning and regulatory planning fo
registrations, licensing, clearances and/or approvals, and conformity
assessment pathways. Additional planning activities may include globa
marketing planning, manufacturing planning, manufacturing quality
planning, supply chain planning and service and/or support planning.
PLANNING DOCUMENTS
Depth and Detail. Manufacturers must determine the appropriate leve

and depth of detail in planning documents. To the uninitiated, this can
a daunting task, and, unfortunately, experience in the best teacher. A
general rule is that planning activities should be commensurate with th
complexity of the device, its intended use, and the severity of risk that
could permit or inflict (directly or indirectly) on the patient, user or
environment.
Plans should be broad, covering goals, main tasks and essential activit
rather than too detailed and overly complex. It is preferable to identify
and assign responsibility for major subsystems rather than detailed
components of subsystems (e.g., the responsibility for a peristaltic pum
assembly as opposed to bearings and rollers within the assembly.
Early in the design and development) process, planning documents ten

to be immature, with unknown "to-be-determined" conditions. Planning
documents should be updated as necessary during the design process
refine schedules and resolve these conditions.
Contents of Planning Documents. One method of achieving the

appropriate planning level and depth of detail in planning documents
while maintaining required regulatory content is the application of a
content-based approach. Content-based planning procedures list sectio
or topics that must be included and addressed within a planning
document without prescribing the detailed requirements for compliance
For example, a content-based standard operating procedure for plannin
would require a planning document to include a service and support
section that lists or refers to the service and support plan for the proje
This section may fully describe the service and support plan or refer to
internal or external procedures. With this procedural flexibility,
manufacturers can customize service and support activities for individu
projects without inviting regulatory compliance issues associated with
inflexible, proscriptive standard operating procedures.
Creation of Planning Documents. Initial revisions of planning

documents should be created at the start of each design and
development project and should be completed before significant activit
begun on development of design inputs.
Review and Approval of Planning Documents. Guidance2 from the

Food and Drug Administration (FDA) suggests that initial revisions of
planning documents should be reviewed and approved prior to approva
design inputs.
Retention of Completed Planning Documents. All approved revisio

of all planning documents should be retained in the design history file
(DHF) as required by the manufacturer’s quality system.
Maintenance and Update of Planning Documents. Planning

documents should be reviewed and updated as the project evolves.
Although review and update may occur at any time, design review
meetings are a good time and place to consider, discuss and review
changes that may need to be made in planning documents.
TRAINING REQUIREMENTS
How many of us would commission the construction of our family’s new

house, or even the repair of our home’s existing roof, without critically
assessing the skills and qualifications of the contractors bidding for the
job? Hopefully, no one would. So, why would we not apply the same le
of consideration to the individuals and organizations providing services
a medical device manufacturer who is developing products that affect
public health?
Section 820.25(b) of 21 CFR § 820 states:
Each manufacturer shall establish procedures for identifying train

needs and ensure that all personnel are trained to adequately
perform their assigned responsibilities. Training shall be
documented.
(1) As part of their training, personnel shall be made aware of
device defects which may occur from the improper performance o
their specific jobs.
(2) Personnel who perform verification and validation activities sh
be made aware of defects and errors that may be encountered as
part of their job functions.
Planning activities require the assignment of personnel who possess th

education, training, background and experience to adequately perform
their assigned tasks. Many methods exist to fulfill this requirement. On
method is to establish training requirements for all job titles and ensur
that each person assigned to a specific task has received the appropria
training in the applicable standard operating procedures as well as the
general requirements for the specific position. This basic requirement a
extends to contractors.
Section 820.50(a) of 21 CFR § 820 states:
Each manufacturer shall establish and maintain the requirements

including quality requirements, that must be met by suppliers,
contractors, and consultants. Each manufacturer shall:
(1) Evaluate and select potential suppliers, contractors, and
consultants on the basis of their ability to meet specified

requirements, including quality requirements. The evaluation sha
be documented.
(2) Define the type and extent of control to be exercised over the
product, services, suppliers, contractors, and consultants, based
the evaluation results.
(3) Establish and maintain records of acceptable suppliers,
contractors, and consultants.
Manufacturers should ensure that appropriate processes are in place to

satisfy these requirements.
DESIGN AND DEVELOPMENT PLANNING
Section 7.3.1 of ISO 13485:2003 states:
The organization shall establish documented procedures for desig

and development.
The organization shall plan and control the design and developme
of product.
During the design and development planning, the organization sh
determine
a) the design and development stages,
b) the review, verification, validation and design transfer activitie
(see Note) that are appropriate at each design and development
stage, and
c) the responsibilities and authorities for design and developmen
The organization shall manage the interfaces between different
groups involved in design and development to ensure effective
communication and clear assignment of responsibility.
Planning output shall be documented, and updated as appropriat
as the design and development progresses (see 4.2.3).
NOTE Design transfer activities during the design and developme
process ensure that design and development outputs are verified
suitable for manufacturing before becoming final production
specifications.
Section 820.30(b) of 21 CFR § 820 states:
Design and development planning. Each manufacturer shall

establish and maintain plans that describe or reference the desig
and development activities and define responsibility for
implementation. The plans shall identify and describe the interfac
with different groups or activities that provide, or result in, input
the design and development process. The plans shall be reviewed
updated, and approved as design and development evolves.
Design and development plans should clearly communicate the design

objective, tasks and activities required to accomplish the design object
The design and development plan should "tell the story" about the des
goal and the means that will be used to achieve it. Comprehensive
product planning should cover all product life cycle phases, including u
needs, design input, functional specification, design implementation,
verification, design transfer, validation, final release, operation, suppor
maintenance and retirement.
Design and development plans should include or refer to the location o

the following:
z Design goals and objectives

z Product description
z Product trade names
z Intended use/indications for use
z Reference to applicable design control procedures with
requirements for creation, review and approval, retention, conten
maintenance, and update of design deliverables, and when the
project becomes subject to design controls
z Reference to applicable design change control procedures and wh
design results become subject to change controls
z Quality planning
z Global marketing planning
z Regulatory planning
z Service and support planning
z Manufacturing planning
z DHFs
z Electronic document retention
z User needs
z Design input
z Major design and development tasks and activities
z Qualified personnel responsible for planning, design input, design
output, design transfer, design change control and design history
file
z Organizational and technical interfaces that provide or result in
design input
z Personnel training requirements
z Use of standards
z Design output essential for the proper functioning of the device
z Design deliverables list
z Design transfer deliverables
z Essential requirements compliance reporting
z Technical documentation for CE marking
z Declaration of Conformity for CE marking
z European Commission certificate for CE marking
z Regulatory release requirements
z Commercial release requirements
z Revision history of the plan
z Review and approval
QUALITY PLANNING
At their best, quality plans clearly state the quality objectives, in

measurable terms, and the quality tools and methods that will be used
achieve those objectives. Quality objectives may be measured in a wid
variety of ways throughout the life cycle of the device. Metrics include
defects per million, scrap and yield percentages, number of engineering
change orders processed after the device has been commercialized, ou
of-box failure percentage, customer complaints per month or devices
sold, Medical Device Reports/vigilance reports per year, postmarket
studies, customer satisfaction surveys, and Corrective and Preventive

Action activities initiated, among others.
The "Quality Toolbox" consists of the means and methods that quality
professionals use to achieve objectives. Quality assurance tools are
intended to prevent defects, whereas quality control tools are meant to
detect defects.
Following is a partial list of quality tools:
z Application of a registered medical device quality system

z Design verification and validation
z Requirements traceability
z Risk management activities
z Design reviews
z Process qualification and validation
z Human factors testing (e.g., user range, fatigue)
z Stress and accelerated aging tests
z Completeness and accuracy auditing
z Design transfer document reviews
z Supplier partnering and development
z Supplier controls/quality metrics
z Process controls/quality metrics
z Six Sigma techniques
z Mistake proofing
z Manufacturing acceptance testing (receiving, in-process, final)
z Biosafety testing
z Field history of similar designs
z Comparison with similar proven designs
z Review of relevant scientific literature
z Historical evidence that similar designs and or materials are
clinically safe
z Statistical methods, alternative calculations and math models
z Clinical investigations or trials to ensure that the device performs
intended
z Life cycle models that include distinct design phases with associa
deliverables
z Feedback of technical and schedule information among life cycle
phases
z Defined processes for anomaly reporting and problem resolution
integrated into all phases of the design life cycle that return to th
source of the error, not necessarily the previous phase, and look
adjacent and similar areas in the design or documentation for
associated errors
z Full integration of development life cycle and risk management
activities
Quality plans should include or refer to the location of the following:
z Reference to quality planning procedures and requirements for
creation, review and approval, retention, contents, maintenance
and update of quality deliverables

z Quality goals and objectives
z Quality tasks and activities
z Qualified personnel responsible for each identified quality task an
activity, including risk management, design review, design
verification, requirements traceability, design validation, anomaly
reporting and problem resolution systems
z Organizational and technical interfaces
z Personnel training requirements
z Risk management planning
z Quality deliverables
z Design reviews
z Manufacturing quality planning
z Statistical methods
z Design verification planning
z Design transfer activities
z Design validation planning
z Anomaly reporting
z Problem resolution
z Revision history of the plan
ISO guidelines for project quality plans and quality management3 shou
be consulted for additional quality planning information.
RISK MANAGEMENT PLANNING
Risk management plans should meet the requirements of ISO

14971:2000. Plans should clearly communicate risk management
practices, resources and activities and should establish a framework in
which experience, insight and judgment are applied to successfully
manage risk throughout the entire device life cycle. The risk managem
plan should "tell the story" of the risk management process: how risk
management activities will be integrated into the design control proces
and performed throughout the device life cycle, how safety-related
requirements will be identified, integrated into design inputs,
implemented in the final product, tested and verified, and evaluated fo
effectiveness, and how postmarket experience and information gained
about the device will be assessed in accordance with ISO 14971:2000.
Risk management plans should include or refer to the location of the

following:
z Reference to risk management planning procedures and
requirements for creation, review and approval, retention, conten
maintenance and update of risk management deliverables
z Scope of the planned risk management activities
z Assignment of responsibilities and authorities
z Life cycle phases for which the plan is applicable
z Risk analysis meetings
z Necessary qualifications for personnel performing tasks

z Risk analysis team participants
z Risk control implementation
z Policy for determining maximum tolerable individual risk level
z Criteria for maximum tolerable individual risk level acceptability
z Policy for determining overall residual risk acceptance
z Criteria for overall residual risk acceptability
z Requirements for formal design review of risk management
activities and approval of results
z Verification activities for risk reduction measures
z List of deliverables
z Methods for obtaining relevant post-production information
z Revision history
REGULATORY PLANNING
Perhaps the most important function of a regulatory plan is to clearly

communicate the tasks, activities and deliverables required to obtain
regulatory clearance and/or approval in the countries and geographies
where the product(s) will be marketed. The regulatory plan should "tel
the story" about the intended markets and rollout schedules, the
regulatory requirements in intended markets, the regulatory strategies
for each intended market, and the deliverables required for regulatory
submissions, registrations and/or licenses to support the marketing go
Regulatory plans should include or refer to the location of the following
z Intended use, indications for use and/or claims, including variatio
for specific markets
z Regulatory tasks and activities
z Product trade name(s) to be used for registrations
z Identification and relationships of involved parties
z Labeling strategy
z Domestic regulatory plan
z European Union/European Economic Area (EU/EEA) regulatory pl
z Rest of world (ROW) regulatory plan
z Domestic regulatory deliverables required prior to FDA submissio
z CE marking regulatory deliverables required prior to introduction
into an EU/EEA member state
z ROW regulatory deliverables
DETERMINATION OF REQUIREMENTS RELATED TO THE PRODUCT
The organization shall determine

a) requirements specified by the customer, including the
requirements for delivery and post-delivery activities,
b) requirements not stated by the customer but necessary for
specified or intended use, where known,
c) statutory and regulatory requirements related to the product,
and
d) any additional requirements determined by the organization.1
User requirements (user needs) are generally thought of as needs

expressed by users from their point of view, or "the words of the
customer." They are generally expressed in nontechnical terms and
should focus on a need, not a solution.
Many methods exist for gathering user needs, including focus groups,
surveys and testing. Manufacturers can consult marketing experts or k
opinion leaders to identify unmet user needs. Psychologists can help
identify needs that users are unaware of or are unable to articulate. An
advanced degree in marketing may be required to fully appreciate all t
possible methods available.
However, regardless of the methods used to determine user needs, the

following information is needed to document user needs:
z Each user need (user requirement) to be satisfied

z User population and/or human factors
z Environment of use
z Evaluation method for determining success
z Importance of each need to the user
The following sections explore each of these points in more detail.
GATHERING USER NEEDS
Defining User Needs. While gathering user needs for formal

documentation, it is important to focus on the actual need, not on a
solution. Defining a need without imposing a preconceived design solut
can help drive creative problem solving for those responsible for
developing a solution to meet user needs. For example, a user may sta
that he or she needs a saw, when in fact the user needs to remove a
tree. There are many ways to remove a tree. By identifying the real ne
creative solutions can be developed to meet that need.
A useful approach in gathering user needs to be satisfied is to identify

"high-level" functionality required by the user. As an exercise, consider
of the types and configurations of clinical thermometer technologies
available, such as mercury, electronic and chemical patch for infants.
Next, consider the user needs that these devices satisfy. What high-lev
user needs would require one type of configuration over another?
Information for obtaining example user needs documents is included at
the end of this article.
User Population and Human Factors. When gathering user needs, i

important to understand the entire user population and any limitations
they might have. A device designed for use by geriatric patients might
very different from the same device designed for a younger patient
population. Identifying and accommodating user limitations (for examp
with regard to visual acuity, hearing or manual dexterity) can
dramatically improve the ability of a device to meet its user needs.
Environment of Use. It is important to understand all of the places a

conditions where the product will be used, shipped and stored. This
information will assist engineers in developing appropriate design input
and verification test criteria for a device and its packaging configuratio
Consider a device that administers a specific percentage of oxygen to a

patient. Fuel cell oxygen sensor technologies are stable and reliable, bu
require compensation for altitude. If engineers are unaware that the
device will be used in life-flight operations and have not designed the
device to operate across a wide range of continuously varying
atmospheric pressures, a fuel cell-based sensor may be inaccurate whe
used in a helicopter at changing altitudes.
Consider the differences between a clinical setting and a home setting

with children, pets and so forth. These two very different environments
use might have an impact on the design of a medical device.
Evaluation Method for Determining Success. Understanding and

documenting how the user will determine that each defined need has
been met is very important. This information will be used to develop th
validation protocols demonstrating that the user needs for the intended
uses have been met.
In practice, design validation plans and protocols should be developed

early in the design and development process, concurrently with
documentation of user needs. Developers of validation protocols must
have a clear understanding of how the user will determine whether the
needs have been met.
Design validation will be discussed in more detail in a future article.
Importance of Each Need to the User. Finally, it is important to

establish a metric that defines the relative importance of each need to
user. This information will help engineers make wise design trade-offs.
For example, in portable, internally powered equipment, there is
generally a trade-off between battery life and weight of the device.
Knowing whether longer battery life or lower weight is more desirable t
users will help engineers make better design decisions.
DOCUMENTING USER NEEDS
User needs should be documented in a way that facilitates their update

Intended use and/or indications for use, user population and/or human
factors, environments of use, and the defined user needs should be
documented, as well. Each user need should be uniquely numbered, w
one need per number, and should include the validation methodology a
the metric representing the importance of each need to the user.
Unique numbering of user needs provides the basis for "requirements

traceability," a quality tool used to ensure that all functional and safety
related requirements are implemented in the final product. If a user ne
is deleted for any reason, the user need number should be carried in
subsequent updates with "need deleted" or a similar statement.
It is important to note that a company may choose not to implement a

particular user need for a variety of reasons, particularly when a user
need conflicts with a safety requirement.
DOCUMENTING BUSINESS NEEDS
Manufacturers frequently identify needs that they wish to document an

track but that are needs of the manufacturer and not the users of the
product. For example, a manufacturer may have a business need for a
maximum burdened manufacturing cost or minimum gross margin.
Although important to the business, these are not user needs and wou
not be appropriate contents of documents available to customers and
regulators.
One solution is for manufacturers to create a separate "business needs

document to record these requirements. This strategy allows the
manufacturers to document important business needs outside of the us
needs and validation process.
REVISING USER NEEDS DOCUMENTS
User needs documents should be revised as required. The initial revisio

of user needs documents should be created at the start of each design
and development project and should be completed prior to any signific
development activity of the associated design inputs. Each approved
revision of a user needs document should be uniquely numbered and it
revision controlled as required by the manufacturer’s quality system. U
needs documents should be reviewed and approved prior to approval o
associated design input documents (the subject of a future article in th
series). All approved revisions of user needs documents should be
retained in the DHF as required by the manufacturer’s quality system.
REVIEW OF REQUIREMENTS RELATED TO THE PRODUCT
The organization shall review the requirements related to the

product. This review shall be conducted prior to the organization
commitment to supply a product to the customer (e.g., submissio
of tenders, acceptance of contracts or orders, acceptance of
changes to contracts or orders) and shall ensure that
a) product requirements are defined and documented,
b) contract or order requirements differing from those previously
expressed are resolved, and
c) the organization has the ability to meet the defined
requirements.
Records of the results of the review and actions arising from the
review shall be maintained (see 4.2.4).
Where the customer provides no documented statement of
requirement, the customer requirements shall be confirmed by th
organization before acceptance.
Where product requirements are changed, the organization shall
ensure that relevant documents are amended and that relevant
personnel are made aware of the changed requirements.
NOTE In some situations, such as internet sales, a formal review

impractical for each order. Instead the review can cover relevant
product information such as catalogues or advertising material.1
FORMAL DESIGN REVIEW OF USER NEEDS
User needs should be reviewed by a cross-functional team for adequac

ensuring documentation of user population and/or human factors,
environment of use, each user need to be satisfied, evaluation method
determining success, and importance of each need to the user.
Additionally, user needs should be reviewed to ensure they:
z Are appropriate and address the intended use of the device, the
needs of the user and patient, and the environment of use
z Are comprehensive, with an adequate level of detail based on the
complexity and risk of the device
z Are consistent, in agreement, compatible, and not in conflict with
other needs
z Are unambiguous, having or exhibiting no uncertainty
z Can be validated such that the need can be confirmed by
examination and provision of objective evidence and can be
consistently fulfilled for a specific intended use
z Include compatibility with other devices, if applicable
Formal design review will be discussed in more detail in a future article
CUSTOMER COMMUNICATION
The organization shall determine and implement effective

arrangements for communicating with customers in relation to
a) product information,
b) enquiries, contracts or order handling, including amendments,
c) customer feedback, including customer complaints (see 8.2.1)
and
d) advisory notices (see 8.5.1).
Most medical device manufacturers maintain effective systems for

communicating product information, customer inquiries, contracts and
order handling. Ideally, these systems adequately address amendment
to contracts. Most medical device manufacturers maintain effective
systems to acquire and process customer feedback, including customer
complaints and advisory notices, through complaint handling and
postmarket vigilance systems. Establishing and maintaining effective
customer communication systems during the development of medical
devices may be more daunting.
Most medical device professionals have had to address issues that

occurred as a direct result of inadequate communication between
customers and a design and development organization. Determining an
implementing the processes necessary to ensure effective communicat
with customers is critical to the success of any business. Procedures m
include identification of required functional contacts within each

organization, assigning a primary and secondary contact, providing for
scheduled status meetings at one or more functional levels, and
processes for reporting exceptions.
Examples of user needs documents may be obtained free of charge fro

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.
The next article in this series will discuss the ISO 14971:2000 risk
management process.
NOTES
1. International Organization for Standardization (ISO). This material is

reproduced from 13485:2003 with permission of the American Nationa
Standards Institute on behalf of ISO. No part of this material may be
copied or reproduced in any form, electronic retrieval system or otherw
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 ANSI, (212) 642-4900,
http://webstore.ansi.org.
2. Quality System Inspection Handbook, US Food and Drug

Administration, Center for Devices and Radiological Health, October 19
draft, page 33.
3. ISO 10005:1995 and ISO 10006:2003.
Martin D. Sargent is regulatory affairs manager at Medtronic Xomed. H

device experiences include intraoperative neurophysiological monitorin
intracardiac electrophysiology, cardiac catheterization, and active
implantable devices.
Colin D. Jackson is 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.
ACKNOWLEDGMENT
The authors thank Christine S. Guidry of Bayer HealthCare, LLC,

Biological Products Division, for her contributions to this article series.
© 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 1

Uploaded by

Copyright:

Available Formats

You might also like

Design Controls For Medical Devices - Part 1

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 1

Uploaded by

Copyright:

Available Formats

Design Controls for Medical Devices: Part 1—User Needs and Project Planning Página 1 de 15

Professional Meetings & Publications & Members &

INSIDE: Home Resources RA Focus Archives November 2004

Design Controls for Medical Devices: Part 1—User Needs and

1. User needs and project planning

Because design controls must apply to a wide variety of products, the I

PLANNING OF PRODUCT REALIZATION

Section 7.1 of ISO 13485:2003 states:

a) quality objectives and requirements for the product;

b) the need to establish processes, documents, and provide

c) required verification, validation, monitoring, inspection and tes

d) records needed to provide evidence that the realization

The output of this planning shall be in a form suitable for the

NOTE 1 A document specifying the processes of the quality

NOTE 2 The organization may also apply the requirements given

NOTE 3 See ISO 14971 for guidance related to risk management

For the unenlightened, planning activities are at best a drudgery and a

Numerous planning methods exist, ranging from simple spreadsheets a

Planning activities should include design and development planning,

Depth and Detail. Manufacturers must determine the appropriate leve

Early in the design and development) process, planning documents ten

Contents of Planning Documents. One method of achieving the

Creation of Planning Documents. Initial revisions of planning

Review and Approval of Planning Documents. Guidance2 from the

Retention of Completed Planning Documents. All approved revisio

Maintenance and Update of Planning Documents. Planning

How many of us would commission the construction of our family’s new

Section 820.25(b) of 21 CFR § 820 states:

Each manufacturer shall establish procedures for identifying train

Planning activities require the assignment of personnel who possess th

Section 820.50(a) of 21 CFR § 820 states:

Each manufacturer shall establish and maintain the requirements

consultants on the basis of their ability to meet specified

Manufacturers should ensure that appropriate processes are in place to

DESIGN AND DEVELOPMENT PLANNING

Section 7.3.1 of ISO 13485:2003 states:

The organization shall establish documented procedures for desig

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

Design and development planning. Each manufacturer shall

Design and development plans should clearly communicate the design

maintenance and retirement.

Design and development plans should include or refer to the location o

z Design goals and objectives

At their best, quality plans clearly state the quality objectives, in

studies, customer satisfaction surveys, and Corrective and Preventive

Following is a partial list of quality tools:

z Application of a registered medical device quality system

Quality plans should include or refer to the location of the following:

and update of quality deliverables

RISK MANAGEMENT PLANNING

Risk management plans should meet the requirements of ISO

Risk management plans should include or refer to the location of the

z Necessary qualifications for personnel performing tasks

Perhaps the most important function of a regulatory plan is to clearly

Regulatory plans should include or refer to the location of the following

DETERMINATION OF REQUIREMENTS RELATED TO THE PRODUCT

Section 7.2.1 of ISO 13485:2003 states:

The organization shall determine