s**********8
发帖数: 25265 | 1 Design Controls
INTRODUCTION
Coverage
QUALITY SYSTEM
Personnel Training
DESIGN AND DEVELOPMENT PLANNING
Interface
Structure of Plans
DESIGN INPUT
Input Checklists
DESIGN REVIEW
Combination Devices
Preparation For Reviews
Why Design Reviews
Types Of Design Review Meetings
Design Review Requirements
End Of Initial Design
DESIGN OUTPUT
Documenting Design Output
Acceptance Criteria
Design Output Approval
DESIGN VERIFICATION AND VALIDATION
Design Evaluation versus Specifications
Software Validation
Labeling Verification
DESIGN TRANSFER
DESIGN CHANGES
DESIGN HISTORY FILE
EXHIBITS
Design Input Requirements Procedure
----------------------------------------------------------------------------
----
INTRODUCTION
The Safe Medical Devices Act of 1990 added design validation requirements to
the GMP requirements in section 520(f) of The Act. Section 820.30 of the
Quality System (QS) regulation lists the design control requirements that
manufacturers should satisfy to be in compliance. This chapter describes
design controls and provides guidance to assist manufacturers in complying
with design control requirements.
"Design Control Guidance for Medical Device Manufacturers" is another
document that may assist manufacturers in understanding the intent of the
design control requirements. This manual interprets the language of the QS
regulation and explains the underlying concepts in practical terms. "Do It
By Design: An Introduction to Human Factors in Medical Devices" is a
document that contains background information about human factors as a
discipline, describes and illustrates device problems and discusses human
factors principles and methods as a part of the design control system. Both
of these manuals are possible resources for manufacturers who are either
developing or improving their design control system. These manuals are also
available through DSMA.
Coverage
The design controls section 820.30 of the QS regulation applies to the
design of products, and processes and changes to existing designs and
processes. Changes to existing designs should be made in accordance with
design control requirement even if the original design was not subject to
these requirements. Design controls are not retroactive to completed
portions of ongoing design programs.
Each manufacturer of any class III or class II device, and class I devices
automated with computer software and those listed below shall establish and
maintain procedures to control the design of the device in order to make
certain that specified design requirements are met. Manufacturers of other
Class I devices should develop and document their devices under their own
design control system because the documentation is needed to help meet the
device master record requirements in 820.181 and marketing submission
requirements. Thus, manufacturers of exempt Class I devices are encouraged
to use 820.30, Design Controls, as guidance.
Classification Section Class I Devices Subject to Design Controls Listed in
Paragraph 820.30(a)(2)
868.6810 Catheter, Tracheobronchial Suction
878.4460 Glove, Surgeon's
880.6760 Restraint, Protective
892.5650 System, Applicator, Radionuclide, Manual
892.5740 Source, Radionuclide Teletherapy
All Sect. Devices automated with computer software
The design requirements for the device are primarily specified by the
manufacturer; however, FDA has a few design requirements in the 21 CFR Part
801 labeling regulations and in Parts 1000-1050 which cover radiological and
electronic products. A few of the FDA design requirements are in standards.
For example, some parameters for medical gloves are in standards by the
American Society for Testing and Materials (ASTM). (That is, medical gloves
are required to meet these standards in order to be substantially equivalent
to gloves already in commercial distribution.)
QUALITY SYSTEM
Each manufacturer is required to establish and maintain a quality system
that is appropriate for the specific medical device(s) designed or
manufactured [820.5 and 820.1(a)(3)], and that meets the requirements of
Part 820. Therefore, the details of design control systems will vary
depending on the complexity of the product or process being designed.
However, all non-exempt manufacturers including very small manufacturers and
manufacturers that design less complex devices or processes are expected to
define, document and implement design control procedures and other quality
system procedures as called for in the regulation. One of these, a sample
design input procedure, is exhibited at the end of this chapter.
Manufacturers may establish one design control procedure to cover the
various design control sections in 820.30; or, they may use one or more
procedures for each topic. Multiple procedures may be easier to develop,
update and implement. Medium to large manufacturers may have several
additional procedures to support their main design control procedures.
Design control procedures may be part of the quality system records (QSR)
noted in section 820.186.
Personnel Training
Personnel training in 820.25 is one of the quality system requirements,
which applies to employees that perform any activity covered by the QS
regulation including all design activities.
Manufacturers are required to establish procedures for identifying training
needs and making certain that all personnel are trained to adequately
perform their assigned responsibilities. Design personnel shall be made
aware of device defects which may occur from the improper performance of
their specific jobs. In particular, personnel who perform verification and
validation activities shall be made aware of defects and errors that may be
encountered as part of their job functions.
Most technical employees need various degrees of training, as appropriate,
in the medical device regulations, safety, labeling, human factors,
verification, validation, design review techniques, etc.
DESIGN AND DEVELOPMENT PLANNING
Developing a new device and introducing it into production are very complex
tasks. For many new devices and associated manufacturing processes that use
software, these tasks are further complicated because of the importance of
software, and the possibility of subtle software errors. Without thorough
planning, program control, and design reviews, these tasks are virtually
impossible to accomplish without errors or leaving important aspects undone.
The planning exercise and execution of the plans are complex because of the
many areas and activities that should be covered. Some of the key
activities are:
determining and meeting the user/patients requirements;
meeting regulations and standards;
developing specifications for the device;
developing, selecting and evaluating components and suppliers;
developing and approving labels and user instructions;
developing packaging;
developing specifications for manufacturing processes;
verifying safety and performance of prototype and final devices;
verifying compatibility with the environment and other devices;
developing manufacturing facilities and utilities;
developing and validating manufacturing processes;
training employees;
documenting the details of the device design and processes; and,
if applicable, developing a service program.
To support thorough planning, the QS regulation requires each manufacturer
to establish and maintain plans that describe or reference the design and
development activities and define responsibility for implementation.
The plans should be consistent with the remainder of the design controls.
For example, the design controls section of the quality system requires a
design history file (DHF) [820.30(j)] that contains or references the
records necessary to demonstrate that the design was developed in accordance
with the:
1. approved design plan, and
2. regulatory requirements.
Thus, the design control plans should agree with, and require meeting, the
quality system design control requirements. One of the first elements in
each design plan should be how you plan to meet each of the design control
requirements for the specific design you plan to develop; that is, the
design plans should support all of the required design control activities.
Such plans may reference the quality system procedures for design controls
in order to reduce the amount of writing and to assure agreement.
Interface
Design And Development Planning section 820.30(b) states:
"The plans shall identify and describe the interfaces with different groups
or activities that provide, or result in, input to the design and
development process..."
If a specific design requires support by contractors such as developing
molds, performing a special verification test, clinical trials, etc., then
such activities should be included or referenced in the plan and proactively
implemented in order to meet the interface and general quality system
requirements. Of course, the interface and general requirements also apply
to needed interaction with manufacturing, marketing, quality assurance,
servicing or other internal functions.
Proactive interface is a important aspect of concurrent engineering.
Concurrent engineering is the process of concurrently, to the maximum
feasible extent, developing the product and the manufacturing processes.
This valuable technique for reducing problems, cost reduction and time
saving cannot work without proactive interface between all involved parties
throughout all stages of the development and initial production program.
Structure of Plans
Each design control plan should be broad and complete rather than detailed
and complete. The plan should include all major activities and assignments
such as responsibility for developing and verifying the power supplies
rather than detailing responsibility for selecting the power cords,
fuseholders and transformers. Broad plans are:
easier to follow;
contain less errors;
have better agreement with the actual activities; and
will require less updating than detailed plans.
Over the years, several manufacturers have failed to follow this advice and
opted for writing detailed design control procedures. They reported being
unable to finish writing the over-detailed procedures and were unable to
implement them.
Regardless of the effort in developing plans, they usually need updating as
the development activities dictate. Thus, the QS regulation requires in 820.
30(a) that the plans shall be reviewed, updated, and approved as the design
and development evolves. The details of updating are left to the
manufacturer; however, the design review meetings are a good time and place
to consider, discuss and review changes that may need to be made in the
design development plan.
DESIGN INPUT
Design input means the physical and performance requirements of a device
that are used as a basis for device design [820.3(f)].
Section 820.30(c) Design Input, requires that each manufacturer shall
establish and maintain procedures to make certain that the design
requirements relating to a device are appropriate and address the intended
use of the device, including the needs of the user and patient. Also, a
design requirement in 820.130 requires that each manufacturer shall make
certain that device packaging and shipping containers are designed and
constructed to protect the device from alteration or damage during the
customary conditions of processing, storage, handling, and distribution. The
intent of 820.130 is to add the broad conditions that are considered for a
package design. Packaging design activities should be done according to
design controls. Likewise, the design of the content and physical parameters
of labeling are covered by design controls. Manufacturers that are exempt
from design controls shall labeling and packaging specifications in the DMR
(820.181) and are encouraged to use the QS design controls as guidance.
The input procedures shall address incomplete, ambiguous, or conflicting
requirements. The design input requirements shall be documented and shall be
reviewed and approved by a designated individual(s). The approval,
including the date and signature of the individual(s) approving the
requirements, shall be documented.
Under a design control system, manufacturers should identify device
requirements during the design input phase or beginning of the design
activity. Design input includes determining customer needs, expectations and
requirements plus determining regulatory, standards, and other appropriate
requirements. These various requirements are documented by the manufacturer
in a set of device requirements. A set of design input requirements, when
converted to engineering terminology, finalized and accepted as part of the
device master record is called a device or product specification.
The design input phase usually is a continuum because intensive and formal
input requirements activities usually occur near the beginning of the
feasibility phase and continue to the early physical design activities.
After the initial design input phase there are also intensive and formal
activities to reduce the input requirements to engineering-type input
specifications -- usually called a product or device specification.
At the opposite end of the design program, the last event is initial
production which may be pilot production or the beginning of routine
production. Whether a manufacturer starts with pilot or routine production
depends on the nature of the new device and associated production. Pilot
devices may be distributed after design validation of initial units is
completed if they meet all of the device master record and other GMP
requirements. Some manufacturers, however, use the pilot models in training
programs for technical writers, production and service personnel, etc. Pilot
models are also commonly used in early marketing displays.
After the concept of the new device design is established, the following
basic design input questions should have been answered:
1. What is the real need for the new device?
2. Where will the new device be used?
3. Who will use the new device?
4. How will the new device be used?
5. With what devices will the new device be used?
6. How long will the new device be used? and
7. Other questions related to the specific device to be developed.
Designing a device and verifying that it meets customer requirements are
expensive and time consuming activities. Therefore, to control these
activities and increase the probability of achieving desired safety and
performance characteristics, device, software, and process requirements and
specifications should be thoroughly reviewed and approved before physical
design and development begins. As the design evolves, the hardware, software
, packaging, labeling, etc., shall be verified [820.30(f)] and reviewed [820
.30(e)] versus their latest specifications to verify that design input
requirements have been met.
Input Checklists
Device requirements should identify all of the desired performance, physical
, safety and compatibility characteristics of the proposed device and,
ultimately, the finished device. Design input also includes requirements for
labeling, packaging, manufacturing, installation, maintenance and servicing
. The final device specifications should cover ALL of the device
characteristics. The device specifications may incorporate other
specifications by reference such as reference to the manufacturer's list of
specifications for a type of device, to specific paragraphs in standards, or
to all of a standard, etc. with respect to a referenced specification. It
should be very clear exactly what is going to be met. A failure to properly
address characteristics or factors such as immunity from transients in the
power source, thermal stress, electromagnetic compatibility (EMC), packaging
protection, shipping stability, proper maintenance, etc., can have
disastrous consequences.
It is possible to diligently develop device requirements and still forget
one or more elements in the final specification. Hopefully, no key factors
will be left out. To reduce the probability of a requirement or
characteristic being left out, a specification checklist(s) may be used
during the design input phase. A checklist should be developed that is broad
based but also germane to the product line of the manufacturer. If used, a
checklist should be part of a standard operating procedure such as a Design
Input Specification Procedure.
The input requirements should cover any standards that the manufacturer
plans for the device to meet. In the United States, information about
essentially all national and international standards may be obtained from
the American National Standards Association (ANSI), 11 West 42nd Street, New
York, New York, 10036, phone 212-642-4900. ANSI is a private organization,
which monitors most of the standards activity in the United States and
foreign activity in which U.S. citizens "officially" participate. Thus, ANSI
can supply addresses and other information about all well established
standards writing groups. Also, ANSI has for sale many different types of
standards including quality system standards. For example, the International
Electrotech Commission has a draft design review standard, "Guide on Formal
Design Review" (plus a supplement), which should be helpful to product
assurance/design control personnel.
The QS regulation requires that the input procedures shall address
incomplete, ambiguous, or conflicting requirements. Thus, every reasonable
effort should made to collect all of the requirements from which the
designers can generate detailed design specifications that are clear,
correct and complete.
At the end of the major aspects of the design input stage, the design input
requirements shall be documented and shall be reviewed and approved by a
designated individual(s). The approval, including the date and signature of
the individual(s) approving the requirements, shall be documented.
A documented device specification or set of specifications derived from the
input requirements should exist at the beginning of the physical design
project. The device and other related specifications should be kept current
as the design of the device, packaging, labeling and manufacturing processes
evolve during the development program. As the physical design evolves, the
specifications usually become more specific and more detailed.
The device specification will undergo changes and reviews as the device
design evolves. However, one goal of market research and initial design
reviews is to establish complete device requirements and specifications that
will minimize subsequent changes.
Old versions of the input requirements and later the input specifications
are put in the design history file (DHF) or indexed in the computer as part
of the DHF to help show that the design plan was followed.
DESIGN REVIEW
Design review [820.30(e)] is one of the key design control elements in a
quality system. The objectives of design review are stated in the definition
of design review in 820.3(h) as follows:
Design review means a documented, comprehensive, systematic examination 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.
To meet the systematic design review requirement, device design and design
reviews should progress through defined and planned phases starting with the
design input phase and continuing through validation of initial production
units or lots. Subsequent activities are usually design changes.
To meet the design review comprehensive requirement, assessments should
include a formal review of the main device and subsystems, including
accessories, components, software, labeling, and packaging; production and
resource needs; and installation and service, if needed. The scope includes
performance, physical safety, compatibility with other devices, overall
device system requirements, human factors, and environmental compatibility.
Even though users or medical practitioners will be aware of direct medical
requirements, they may not be fully aware of physical safety, compatibility,
system, human factors, and environmental requirements. Thus, the reviews of
the design input and the design should extend beyond merely satisfying user
-stated requirements in order to assure that safety and effectiveness goals
are met.
As the development program progresses, the reviews should cover
producibility and production documentation such as assembly drawings,
manufacturing instructions, test specifications, test procedures, etc.
The extent and frequency of design reviews depends on the complexity and
significance of the device being evaluated.
When the design program is a redesign of an existing device, a special
effort should be made to assure that data obtained from previous failures,
complaints, and service records are made available and reviewed by those
responsible for design, design input and design review.
Combination Devices
Marketing submissions to FDA for drug delivery, drug coated, etc., devices
are required to have appropriate data that supports combination claims. The
verification of combination devices requires interaction between device,
drug or other manufacturers. Records of this interaction, such as design
review meeting minutes, are required in order to meet the interface
requirements of 820.30(b), Design and Development Planning. The labeling and
particularly the cross-labeling of combination devices should be carefully
analyzed during verification and validation activities, and design review
meetings.
Preparation For Reviews
The designated moderator or other designated employee should announce the
formal review meetings with appropriate lead time and include an agenda.
Persons who are making presentations should prepare and distribute
information to help clarify review issues and help expedite the review.
However, the intent of the quality system is not that presentations be so
formal and elaborate that designers are spending excessive time on
presentations rather than on designing a safe and effective device.
Persons who plan to attend a review meeting should come prepared to discuss
the key issues on the agenda and issues related to the current design phase.
Design review meetings are a great educational forum. However, design
review meetings should not be used as a primary tool to educate or bring new
employees or unprepared employees up-to-speed. To do so detracts from the
intent of the meeting and detracts from the intent of the GMP requirements.
Obviously, design review is also an excellent educational tool. However, new
, or new-to-the-project employees should be primarily oriented by other
means that do not detract from the primary function of design review
meetings.
Why Design Reviews
Design reviews are conducted for design definition, selection and adequacy;
communication; and resolution of problems and issues. For example, the
design review of the design input requirements and subsequent design input
specifications for the device, labeling, packaging and accessories is
performed to help select the best and/or needed characteristics and
requirements, usually from among many available and sometimes conflicting
inputs.
The design review of the initial requirements allows input from all parties.
Various people may participate and "buy in" or "become part of the program.
" As the design input and review activities progress, any conflicts are
resolved and the preliminary specifications for the device, accessories,
labeling, and packaging are established. Herein, the device, accessories,
labeling and packaging is called the device system. Because of the
establishment of these input requirements and subsequent specifications,
plus interface and communication during the reviews, all personnel are
directed toward the goal of developing the "exact" same device system.
As the development progresses and the design and production processes evolve
, design reviews reduce errors, help avoid problems, help find existing
problems, help propose solutions, increase producibility and reduce
production transfer problems. The relentless inquiry during design reviews
will expose needed design input requirements and/or design corrections that
otherwise may have been overlooked.
Throughout the design program and particularly toward the end of the
development cycle, design reviews help assure that the final design of the
device system meets the current design requirements and specifications.
Types Of Design Review Meetings
Design review meetings may be grouped into two levels such as:
total or major program review meetings, and
sub-program or team review meetings.
Some of the review meetings need to be total or major program review
meetings because this is the only type of review meeting that will satisfy
all of the GMP review requirements, particularly the interface requirement
for interaction between or among different organizational groups. However,
sub-program, team and contractor review meetings are design review meetings,
are subject to quality system design controls, and should be conducted in a
manner that meets the GMP requirements. Sub-program or team meetings are
encouraged as these can be very effective and efficient in reviewing and
resolving sub-program issues.
The records of total program and team meetings are part of the device design
history file. The team review records or a summary of team records and the
current design documentation are to be available, as appropriate, at total
program review meetings.
Design review meetings are called under two scenarios:
first are the meetings that are preplanned and called at least on a per
design phase;
second are ad hoc meetings that are covered in the broad plans and are
called to review or resolve a specific problem or issue.
The preplanned design review meetings and ad hoc meetings are part of the
planning and interaction that are required in 820.30(b), Design and
Development Planning. That is, the manufacturer should expect, plan for, and
encourage appropriate ad hoc meetings as well as the major design review
meetings. Reasonable notes and copies of significant engineering documents
discussed during total device system, ad hoc, contractor, and other review
meetings are part of the device design history file.
Design Review Requirements
The objectives of design review are stated in the definition noted above.
How these objectives are to be achieved are presented in the design review
requirements. The main design review requirements are in 820.30(e) of the QS
regulation as follows:
Each manufacturer shall establish and maintain procedures to ensure that
formal documented reviews of the design results are planned and conducted at
appropriate stages of the device's design development. The procedures shall
ensure that participants at each design review include representatives of
all functions concerned with the design stage being reviewed and an
individual(s) who does not have direct responsibility for the design stage
being reviewed, as well as any specialists needed. The results of a design
review, including identification of the design, the date, and the individual
(s) performing the review, shall be documented in the design history file.
There are four requirements related to design reviews:
1. The meetings should be formal. That is, key attendees are designated and
the meetings are conducted at least once per stage/phase, are planned, are
announced or are periodic, have an appropriate agenda, notes are recorded,
etc., according to the manufacturer procedure for design reviews.
The design review procedure should be broad and complete in that it contains
information about all of the requirements. However, the procedure should
not be so detailed that it cannot be followed. Over the years, several
manufacturers have failed to follow this advice, tried to write detailed
design QA procedures, and have reported that they were unable to finish
writing the over-detailed procedures and were unable to implement them.
2. To meet the definition of design review in 820.3(h), the review should
include persons who are intimately knowledgeable about the technical
characteristics of the design such as performance, safety, compatibility,
etc. In many manufacturers this can only be done by those persons
responsible for the design. However, reviews are to be objective, unbiased
examinations by appropriately trained personnel which should include an
individual(s) not responsible for the design. The moderator of the review
meeting may be one of the persons not responsible for the design.
To meet interface and other review requirements, the review meetings should,
as appropriate, include representatives of R&D, Engineering, Technical
Support Services, Production Engineering, Manufacturing, Quality Assurance,
Marketing, Installation and Servicing, Purchasing and contractors. Design
review should, as applicable and at the appropriate phase, include those
responsible for coordinating or managing preclinical and clinical studies.
3. Pre- and post-review meeting significant responsibilities and assignments
should be documented [820.30(b)]. These assignments are not unusual -- they
are simply ordinary work required to develop a new product or modify an
existing product. The progress and/or results of such assignments would
typically be reported at the next review meeting. Documentation is not
required for detailed day-to-day development activities that are part of the
designers routine job.
4. The design review meeting results are made a part of the device design
history file. The results should include minutes and should include notes,
or annotated draft drawings and annotated draft procedures that played a
significant role during the design review. Such documents help show that
plans were followed, verification/validation was reviewed, and, to some
extent, how the design evolved.
The QS regulation does not require that every document mentioned, referenced
or used during a design review be placed in the design history file.
The device design review meeting minutes should include information such as:
moderator and attendees,
date and design phase/stage,
plans and/or agenda,
problems and/or issues to identify and solve,
minutes and reports, and
follow-up report(s) of solutions and/or the next review covers the solutions
and remaining issues.
Manufacturers may use a form to capture some of this information for minutes
such the device, date, moderator, attendees, major phase, problems,
assignments, etc. The device design review minutes are a key and required
part of the design history file. The minutes also help consolidate
development information and the current minutes are also a brief record of
some of the immediate development tasks to be done.
End Of Initial Design
The design control requirements, particularly design validation, give clear
insight into when the initial
design effort is completed. The end of the total design effort has not been
reached until it is known that the initial production devices, when
transferred to production and produced per the device master record, meet
all of the current design specifications. This fact can only be determined
by performing design validation on one or more samples of the finished
production units as required by 820.30(g). Initial production and subsequent
validation are well defined stages; and, therefore, design review(s) shall
be performed as required by 820.30(e), Design Review.
Thus the design validation of initial production should be followed by a "
final" design review to meet the design review requirement. If the
validation of the final design and subsequent design review(s) reveal design
problems, then design changes are required to correct these problems.
Design changes require another design verification and, where appropriate,
validation and review of all parts or the affected parts of the device
system.
DESIGN OUTPUT
Design output per 820.3(g) means the results 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. The total finished design
output consists of the device, its packaging and labeling, and the device
master record.
Device master record (DMR) means a compilation of records containing the
procedures and specifications for a finished device.
The design output at each phase are documents and physical design elements
that are either complete or are used to move the design effort into the next
phase. For example, the first design output will usually be the design
requirements document. From the requirements and their engineering knowledge
, the designers will derive the preliminary design specifications. Then the
physical design begins. For example, the designers may begin the selection
of known routine components that are part of the design and begin
documenting their purchasing and acceptance requirements documented to meet
820.50 Purchasing Controls, (b) Purchasing Data which requires that each
manufacturer shall establish and maintain data that clearly describe or
reference the specified requirements, including quality requirements, for
purchased or otherwise received product and services.
Other components will be selected as the design evolves. The design output
for some special or new components, or components in unusual applications,
will include verification protocols, purchasing and acceptance requirements.
Many of the design output documents are documents that directly form part of
the DMR. The remaining DMR documents are created by quality assurance,
production engineering, process engineering, technical writing, installation
and servicing, etc., using design output data and information. For example,
the finished device final-test methods and some installation and/or
servicing test methods and data forms may be derived from the design
verification protocol(s). When all of these design and documentation
activities are completed, the DMR is complete. When the DMR is complete and
initial production units, including packaging, meets all specifications, the
total finished design output exists.
To generate the design output per the QS regulation in 820.30(d), three
activities are required. Each of these is listed and discussed below.
1. 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.
2. Design output procedures shall contain or make reference to acceptance
criteria and ensure that those design outputs that are essential for the
proper functioning of the device are identified.
3. 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.
Documenting Design Output (1)
Documenting design output in terms that allow an adequate evaluation of
conformance to design input requirements is a significant requirement and
design activity. A common technique for achieving this conformance is listed
below.
Convert the general input requirements to specific design engineering
specifications and give each item a line/paragraph number.
Develop the design to meet all of the parameters and characteristics in the
design engineering specification.
Generate a verification requirement document(s) and test method(s) for the
design and give each requirement/parameter/characteristic the same line/
paragraph number that it has in the design engineering specification.
Generate a verification data form that lists each requirement/parameter/
characteristic and give each requirement/parameter/characteristic the same
line/paragraph number that it has in the design engineering specification.
Each of these documents has a different drawing number but the line/
paragraph numbers are the same. The first of these documents may be used as
the beginning format for the next one. Therefore, it is almost impossible to
leave out an element. Thereafter, when the verification is performed and
documented, conformance or lack of conformance from input to output is known.
Acceptance Criteria (2)
The verification documents and data contain more information than is
typically needed for production evaluation and acceptance of components, in-
process items and finished devices. Therefore, it is easy to copy and modify
verification documents to meet the quality system requirement that: design
output procedures shall contain or make reference to acceptance criteria and
ensure that those design outputs that are essential for the proper
functioning of the device are identified. In fact, this technique of
deriving test procedures from the verification protocols also yields the
test method(s) and data form(s) needed to meet the DMR requirements for QA
procedures and acceptance criteria in 820.181(c).
Design Output Approval (3)
The third and final output requirement is that: 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. This means that:
Manufacturers may choose to have a group review certain documents and have
individuals review other documents.
Output documents that are directly part of the DMR are reviewed, dated and
signed by the author which is current practice; and reviewed, dated and
approved by individual(s) designated by the manufacturer. As appropriate,
these reviews should cover technical issues as well as adequacy for use in
production, purchasing, servicing, etc. DMR documents that are generated and
approved under 820.30 automatically meet the approval requirements of 820.
40, Document Controls and do not have to be re-approved under 820.40.
Design output reports, data and any other document that will be used to
create documents in the DMR are reviewed, dated and signed by the author
which is current practice; and reviewed, dated and approved by individual(s)
designated by the manufacturer.
Design output also includes the physical design which, of course, is not
intended to be signed, and dated. The approval for the physical design is
the validation that is done on initial production units.
DESIGN VERIFICATION AND VALIDATION
Each manufacturer shall establish and maintain procedures for verifying the
device design. Design verification [820.30(f)] 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 DHF.
Validation [820.30(g)] means confirmation by examination and provision of
objective evidence that the particular requirements for a specific intended
use can be consistently fulfilled.
Process validation means establishing by objective evidence that a process
consistently produces a result or product meeting its predetermined
specifications.
Design validation means establishing by objective evidence that device
specifications conform with user needs and intended use(s).
Verification means confirmation by examination and provision of objective
evidence that specified requirements have been fulfilled.
Each manufacturer shall establish and maintain procedures for validating the
device design. Design validation shall be performed under defined operating
conditions on initial production units, lots, or batches, or their
equivalents. Design validation shall ensure that devices conform to defined
user needs and intended uses and shall include testing of production units
under actual or simulated use conditions. Design validation shall include
software validation and risk analysis, where appropriate. The results of the
design validation, including identification of the design, method(s), the
date, and the individual(s) performing the validation, shall be documented
in the DHF.
Design verification is always done versus specifications. Therefore, to
control the specifications and increase the probability of achieving desired
safety and performance characteristics, device, software, labeling,
packaging and any other specifications should be complete and thoroughly
reviewed before development commences. As the hardware and software designs
evolve, they should be evaluated versus their current specifications.
Verification and validation should be done with test equipment calibrated
and controlled according to quality system requirements. Otherwise, there is
limited confidence in the data.
Verification and validation should also be done according to a written
protocol(s). The protocol(s) should include defined conditions for the
testing. The protocol(s) should be approved before being used. Test protocol
(s) are not perfect for a design, particularly a new design. Therefore, the
designers and other verification personnel carefully annotate any ongoing
changes to a protocol. Likewise, the verification personnel should record
technical comments about any deviations or other events that occurred during
the testing. The slightest problem should not be ignored. During design
reviews, the comments, notes and deviations may be as important as test data
from the formal protocol(s).
Design Evaluation versus Specifications
The original design of devices and any subsequent changes should be verified
by appropriate and formal laboratory, animal, and in vitro testing. Risk
analysis should be conducted to identify possible hazards associated with
the design. Failure Mode Effects Analysis and Fault Tree Analysis are
examples of risk analysis techniques.
Appropriate laboratory and animal testing followed by analysis of the
results should be carefully performed before clinical testing or commercial
distribution of the devices. The manufacturer should be assured that the
design is safe and effective to the extent that can be determined by various
scientific tests and analysis before clinical testing on humans or use by
humans. For example, the electrical, thermal, mechanical, chemical,
radiation, etc., safety of devices usually can be determined by laboratory
tests.
Clinical testing is not needed for many substantially equivalent devices (
See 21 CFR Part 807 Subpart E Premarket Notification Procedure). Where
it is needed, such as for complex substantially equivalent devices or new
devices, clinical testing on humans should meet the applicable requirements
in the Investigational Device Exemption (IDE) regulations (21 CFR Parts 812
and 813).
The general IDE regulation (21 CFR Part 812) exempts a manufacturer during
the "premarketing phase" from the following provisions of the FD&C Act:
Misbranding,
Registration of the Establishment,
Premarket Notification [510(k)],
FDA Performance Standards,
Premarket Approval,
Production sections ONLY of the Good Manufacturing Practices,
Color Additives,
Banned Devices, and
Restricted Devices.
Don't be misled by this list of exemptions -- being exempted from these
provisions does not mean that a manufacturer may develop a new device under
uncontrolled conditions and then test it on humans. Devices being clinically
tested are not exempt from section 501(c) of the FD&C Act, which states
that a device is adulterated if it does not meet a manufacturer's quality
claims. Devices being manufactured for use in clinical studies under an IDE
are exempt ONLY from the production section of the QS regulation. They are
not exempt from design controls listed in 820.30. In addition, the IDE
regulation has labeling requirements in 812.5 and quality assurance
requirements in 812.20(b)(3) that shall be met. Further, manufacturers
should remember that human subjects are also protected through the courts
via product liability laws and actions. In summation, protection of
manufacturer interests, human test subjects, practitioners, and patients
requires that all medical devices be developed, evaluated, and manufactured
under a total quality system.
Laboratory testing to force a failure takes considerable time and the "
culprit" may not fail during the testing. Another evaluation technique is
Failure Mode and Effects Analysis (FMEA) in which failures are assumed to
occur. FMEA is useful for evaluating reliability, safety, and general
quality where, for example, the evaluator assumes that:
each component fails,
each subsystem or subassembly fails,
the operator makes errors, and
the power source is interrupted and immediately restarted.
The probability of each failure actually occurring and, if it does, the
resulting effect are analyzed. Then, where needed and feasible, hazards and
faulty performance are designed out of the device or reduced; or compensated
or prevented/reduced by interlocks, warning signs, explicit instructions,
alarms, etc. Risks, of course, cannot always be removed from medical devices
, but they should be known and controlled to the extent feasible with
existing technology.
Failure Mode and Effects Analysis (FMEA) is a very powerful and cost
effective technique. Note that it takes very little time to assume that a
component or subsystem is going to fail versus the time required to test to
failure. The idea is not to promote one method above the other because a
reasonable amount of both actual testing and failure mode and effects
analysis should be done before a device is clinically tested and/or placed
into production.
Besides using FMEA there are also other human factor and validation process
techniques that can be used in developing an overall risk analysis. These
techniques include: timelines, workload analysis, failure analysis,
alternative calculations, testing including animal testing, auditing the
design output, design reviews, demonstrations, and comparing a new design to
a proven design etc. The users should be considered components when
developing a fault tree and failure mode effects analysis.
All evaluation results should be reviewed by product development personnel
who compare the tests and FMEA results with specifications, including safety
and performance standards, to make certain that the desired level of
intrinsic quality has been designed into the device. Also, the appropriate
design of manufacturing processes, including validation where appropriate,
is needed to assure that production can achieve the level of quality
designed into the device.
Software Validation
Software is evaluated and reviewed versus the software specifications during
the ongoing development of the device design. When a "final" prototype(s)
is available, the software and hardware are validated to make certain
manufacturer specifications for the device and process are met. Some aspects
of hardware evaluation were discussed above. Aspects specific to software
are covered below.
Before testing the software in actual use, the detailed code should be
visually reviewed versus flow charts and specifications. All cases,
especially decision points and error/limit handling, should be reviewed and
the results documented.
In all cases, algorithms should be checked for accuracy. Recalls have
occurred because algorithms were incorrectly copied from a source and, in
other cases, because the source algorithm was incorrect. During the
development phase, complex algorithms may need to be checked by using a test
subroutine program written in a highorder language, if the operational
program is written in a lowlevel language.
The validation program is planned and executed such that all relevant
elements of the software and hardware are exercised and evaluated. The
testing of software usually involves the use of an emulator and should
include testing of the software in the finished device.
The testing includes normal operation of the complete device; and this phase
of the validation program may be completed first to make certain that the
device meets the fundamental performance, safety and labeling specifications
. Concurrently or afterward, the combined system of hardware and software
should be challengedwith abnormal inputs and conditions. As appropriate,
these inputs and conditions include such items as:
operator errors;
induced failure of sensors and cables or other interconnects;
induced failure of output equipment;
exposure to static electricity;
power loss and restart;
simultaneous inputs or interrupts; and,
as appropriate, deliberate application of none, low, high, positive,
negative, and extremely high input values.
The results of the software and combined device system validation are
included in the design reviews.
Labeling Verification
During verification, the complete device is exercised such that all labeling
, displays, and outputs are generated, reviewed, and the results documented.
During the verification, all displayed prompts and instructions are checked
versus the manufacturer's and FDA's labeling requirements and versus the
operator manual.
Printed labeling and screen displays should be checked to see if they are
directed to the user and not to the system designers, which is a common
fault found in labeling. Displayed text should be short and to the point.
Because displays are brief, keywords should be carefully selected to match
system characteristics, yet transfer the maximum information to the user.
The text of references to controls or other parts of the system should match
the labeling on the device. Data, identifications, or other key information
displayed should be current, complete, unambiguous, and accurate.
During verification, all prompts and instructions should be followed exactly
by the device test or other operators and such action should result in
correct operation of the device. Prompts and instructions should
appropriately match the instructions in the operator's manual. The
evaluation should include verification that any screen or other displays
meet the requirements of, and have been approved per, the manufacturer's
policy/procedure for design of labeling.
Patient and procedure data on printouts should be correct; therefore,
printouts should undergo a verification similar to that performed for the
screen or other displays. In addition, the printouts should be evaluated
with respect to their "cold" information transfer characteristics. Will the
printouts be quickly and clearly understood a few weeks later when the
reader is not reading the displays, operating the device, or looking at the
patient? All printouts should also meet the manufacturer's design control
policy/procedure requirements for labeling. Likewise, patient data or other
key information transmitted to a remote location should be correct;
therefore, it should be checked for accuracy, completeness, and
identification. Annotated copies of verified labeling, printouts, etc. and
associated notes and any checklists should be placed in the design history
file.
The overall device specifications usually have requirements that cover user/
operator error prevention and control. Along with operator training, such
errors are controlled by:
adequate instruction manuals,
adequate device labels,
display of adequate prompts and correct instructions,
status (history) reports,
exclusion of certain erroneous inputs or actions, and
adequate human factors design.
Also, for some devices, it may be important to control the order in which
data can be entered by the operator. In emergency situations or because of
distractions, it may be important to present the operator with a brief
history or status report of recent actions. During the verification, the
listed items should be evaluated versus the specifications, and checked for
completeness and appropriateness. A checklist or matrix may be used to aid
in the review of labeling.
DESIGN TRANSFER
The design controls require that each manufacturer shall establish and
maintain procedures to ensure that the device design is correctly translated
into production specifications.
It is common practice for sections of a design to be transferred before the
entire design is completed. The QS regulation does not prevent such split or
multiple transfers. Transfer is to be performed only for completed elements
of the design -- multiple transfers may not be used to bypass any design,
labeling or other GMP requirements.
A significant part of the transfer requirement is met when the design output
is being created. That is, some of the design output documents are part of
the DMR and are used directly for production. The remaining DMR documents
are based on design output information. A procedure is needed to cover the
generation of the remaining device master record documents based on
information in the design output documents.
Design transfer should assure that the section of the design being
transferred:
meets input requirements;
contains acceptance criteria, where needed;
contains design parameters which have been appropriately verified;
is complete and approved for use;
is fully documented in the DMR or contains sufficient design output
information to support the generation of remaining DMR documents; and
is placed under change control if not already done.
Design transfer may include training of production, installation and service
employees and such training should be covered by or referenced by the
transfer procedure.
DESIGN CHANGES
Changes to a design element are controlled per 820.30(i) Design Changes
which states that: each manufacturer shall establish and maintain procedures
for the identification, documentation, validation or where appropriate
verification, review, and approval of design changes before their
implementation.
The original design activities and subsequent change control activities for
the design are both done under the full set of the quality system design
controls. A manufacturer may not use a design change control procedure to
bypass part of the design controls. Thus, it is difficult to describe change
control before design transfer because both activities are done under
design controls.
Most of the details of the change control system are left to the
manufacturer to develop, document and implement. As the design activity
progresses toward the final stage, it is expected that the degree of change
control will increase.
Those elements of the design that have been verified and accepted obviously
should be under change control. A design that has been submitted to FDA for
marketing clearance should be under change control. A design undergoing
clinical trials should be under change control or the clinical data may not
be accepted by FDA. A design that is released for production should be under
design and general change control.
After design activities are begun and the physical design evolves into an
accepted entity, subsequent changes to the device specification(s) are
proposed, evaluated, reviewed, approved, and documented per all of 820.30.
The revised specification(s) becomes the current design goal in accordance
with the manufacturer procedures for: design control, design change control,
and document control.
A design change control procedure should at least cover:
under what conditions change control is required;
documenting the reason for the change;
any differences in the change control process when outside parties are
involved;
analysis of the design to identify other elements that are impacted by the
change; and
for significant changes which includes any change requiring verification and
/or validation, placing the reason for the change in the design history file
along with the required design verification, validation and review
documentation.
DESIGN HISTORY FILE
Design history file (DHF) means a compilation of records which describes the
design history of a finished device [820.3(e)].
The DHF covers the design activities used to develop the device, accessories
, major components, labeling, packaging and production processes.
The design controls in 820.30(j) require that each manufacturer shall
establish and maintain a DHF for each type of device. Each type of device
means a device or family of devices that are manufactured according to one
DMR. That is, if the variations in the family of devices are simple enough
that they can be handled by minor variations on the drawings, then only one
DMR exists. It is common practice to identify device variations on drawings
by dash numbers. For this case, only one DHF could exist because only one
set of related design documentation exists. Documents are never created just
to go into the DHF.
The QS regulation also requires that the DHF shall contain or reference the
records necessary to demonstrate that the design was developed in accordance
with the approved design plan and the requirements of this part. As noted,
this requirement cannot be met unless the manufacturer develops and
maintains plans that meet the design control requirements. The plans and
subsequent updates should be part of the DHF. In addition, the QS regulation
specifically requires that:
the results of a design review, including identification of the design, the
date, and the individual(s) performing the review, shall be documented in
the DHF.
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 DHF.
Typical documents that may be in, or referenced in, a DHF are listed below:
design plans;
design review meeting information;
sketches;
drawings;
procedures;
photos;
engineering notebooks;
component qualification information;
biocompatibility (verification) protocols and data;
design review notes;
verification protocols and data for evaluating prototypes;
validation protocols and data for initial finished devices;
contractor / consultants information;
parts of design output/DMR documents that show plans were followed; and
parts of design output/DMR documents that show specifications were met.
The DHF contains documents such as the design plans and input requirements,
preliminary input specs, validation data and preliminary versions of key DMR
documents. These are needed to show that plans were created, followed and
specifications were met.
The DHF is not required to contain all design documents or to contain the
DMR, however, it will contain historical versions of key DMR documents that
show how the design evolved.
Does the DHF have value for the manufacturer? Yes, when problems occur
during redesign and for new designs, the DHF has the "institutional"
memory of previous design activities. The DHF also contains valuable
verification and validation protocols that are not in DMR. This information
may be very valuable in helping to solve a problem; pointing to the correct
direction to solve a problem; or, most important, preventing the
manufacturer from repeating an already tried and foundtobe
useless design.
EXHIBITS
Design Input Requirements Procedure
A sample Design Input Requirements procedure is presented which covers basic
activities for obtaining data on requirements that is needed for employees
to develop device specifications. This procedure uses the multiple
specification approach; however, a single combined specification would use a
very similar procedure. This procedure should be modified to meet specific
needs before being adopted by a manufacturer.
----------------------------------------------------------------------------
----
C O M P A N Y L O G O
Title: Design Input Requirements Procedure SOP #: ___________ Page:__1_of_2_
____
Prepared by:__________________________________ App: ____________ Date:______
______
Prep. Date: __________________________________Rev: ____________ Date:_______
_____
ECN History:________________________________________________________________
_____
____________________________________________________________________________
_____
POLICY - Design specifications covering all design requirements shall be
established for all proposed devices before any significant physical design
activities are started.
SCOPE - This policy applies to all devices and accessories developed by the
manufacturer or developed by a contractor for us. For purchase of completed
designs, refer to SOP ####. The device specification(s) must exist or be
generated regardless of the source of the design.
CONFIDENTIALITY - Device development plans and activities are always
confidential. Market research reports and documents such as specifications
with parameter data shall be marked confidential.
Design control procedures, standard SOPs, blank forms, and required design
review and design verification/validation records may be shown to, and may
be copied by, FDA investigators as required by the QS regulation. Design
parameters are not covered by the QS regulation. Therefore, confidential
specification characteristics and parameters in the copies of these
documents shall be blacked out unless the document is being collected during
an inspection related to a marketing submission.
RESPONSIBILITY
Marketing and Engineering have the primary responsibility for determining
safety and performance requirements and developing input specifications;
however, all departments are expected to support the development of input
requirements and subsequent specifications.
MARKETING - Marketing shall plan and conduct all customer contacts to obtain
information on customer desires, needs, expected pricing, opinions about
existing devices, etc.
To the maximum extent feasible, market research shall be conducted in a
manner to reduce leaking of manufacturer confidential information and plans.
Design review meetings shall normally precede and follow all significant
outside market research activities. Initial market research activities shall
be previewed with top management.
Market research results are to be documented and marked confidential.
PRODUCTION - Production has primary responsibility for assuring
producibility and establishing manufacturing requirements. Some of these
requirements may be general during the early design stages.
ENGINEERING - Engineering is expected to supply design input information on
most requirements. Such inputs may parallel data obtained by market research.
Engineering has primary responsibility for specifying what technology to use.
Engineering shall analyze input data on requirements and reduce it to
preliminary specifications.
Engineering has primary responsibility for addressing incomplete, ambiguous,
or conflicting requirements and shall see that such issues are
appropriately discussed at design reviews.
----------------------------------------------------------------------------
----
Page 2 of 2
RA & QA - RA and QA managers or their designees shall attend all design
input or specification review meetings to provide input on, and to assure
that, regulatory, manufacturer, quality, safety, performance, etc.,
procedures are followed and that requirements are met.
SPECIFICATIONS
STRUCTURE - Multiple specifications shall be used except for very simple
devices. A separate specification shall be developed for accessories,
labeling, packaging, etc. An overall device specification shall be developed
and shall include an index that points to supporting specifications. The
specifications, among other factors, shall address:
1. Performance and Efficacy;
2. Human Factors;
3. Chemical Safety;
4. Electrical Safety;
5. Mechanical Safety;
6. Radiation Safety;
7. Thermal Safety;
8. Biocompatibility;
9. Device Compatibility;
10. System Compatibility;
11. Environmental Compatibility;
12. Packaging (in a separate specification document);
13. Any FDA design requirements in the Part 801 and Part 1000-1050
regulations; and
14. Labeling in a separate document and, as appropriate, in the device
primary specification.
CHECKLISTS - Checklists of requirements germane to our product line may be
used to develop and support specifications. If used, such checklists become
part of this procedure and part of the design documentation.
DESIGN REVIEW - Each specification shall undergo design review before it is
approved for physical design activities or is used as a background document
to support further market research. Such reviews shall be documented.
APPROVAL - The Marketing manager and Engineering manager shall approve all
input specifications after these have been subjected to design review.
DOCUMENTATION - The approved specifications shall be given document numbers
and become part of the device master record for the new device.
CHANGE CONTROL - The Engineering manager shall decide when design activities
have progressed to the stage that the various specifications shall be
subject to our Design Change Control Procedure. However, for our
organization, design change control can start NO later than the FIRST of the
following events:
- clearance of a 510(k), or
- start of a clinical investigation.
http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/P |
|
