|
|
|
|
|||
|
|
|
||||
|
|
Sec. 820.30f Design Controls. |
|
|
||
|
(f) Design
verification. Each manufacturer shall establish and maintain procedures
for verifying the device design. Design verification shall confirm that the
design output meets the design input requirements. The results of the design
verification, including identification of the design, method(s), the date,
and the individual(s) performing the verification, shall be documented in the
DHF. Interpretation:
Verification and validation are associated concepts
with very important differences. Various organizations have different
definitions for these terms. Medical device manufacturers are encouraged to
use the terminology of the quality system requirements in their internal
procedures. To illustrate the concepts, consider a building
design analogy. In a typical scenario, the senior architect establishes the
design input requirements and sketches the general appearance and
construction of the building, but associates or contractors typically
elaborate the details of the various mechanical systems. Verification is the
process of checking at each stage whether the output conforms to requirements
for that stage. For example: does the air conditioning system deliver the
specified cooling capacity to each room? Is the roof rated to withstand so
many newtons per square meter of wind loading? Is a fire alarm located within
50 meters of each location in the building? At the same time, the architect has to keep in mind
the broader question of whether the results are consistent with the ultimate
user requirements. Does the air conditioning system keep the occupants
comfortable throughout the building? Will the roof withstand weather extremes
expected at the building site? Can the fire alarm be heard throughout the
building? Those broader concerns are the essence of validation. In the initial stages of design, verification is a
key quality assurance technique. As the design effort progresses,
verification activities become progressively more comprehensive. For example,
heat or cooling delivery can be calculated and verified by the air
conditioning designer, but the resultant air temperature can only be
estimated. Occupant comfort is a function not only of delivered air
temperature, but also humidity, heat radiation to or from nearby thermal
masses, heat gain or loss through adjacent windows, etc. During the latter
design phases, the interaction of these complex factors may be considered
during verification of the design. Validation follows successful verification, and
ensures that each requirement for a particular use is fulfilled. Validation
of user needs is possible only after the building is built. The air
conditioning and fire alarm performance may be validated by testing and
inspection, while the strength of the roof will probably be validated by some
sort of analysis linked to building codes which are accepted as meeting the
needs of the user-subject to possible confirmation during a subsequent severe
storm. Validation is the topic of Section G of this
guidance document. The remainder of this section focuses on verification
principles. TYPES OF VERIFICATION ACTIVITIES. Verification activities are conducted at all stages and levels
of device design. The basis of verification is a three-pronged approach
involving tests, inspections, and analyses. Any approach which establishes
conformance with a design input requirement is an acceptable means of
verifying the design with respect to that requirement. In many cases, a
variety of approaches are possible. Complex designs require more and different types of
verification activities. The nature of verification activities varies
according to the type of design output. The intent of this guidance document
is not to suggest or recommend verification techniques which should be
performed by device manufacturers. Rather, the manufacturer should select and
apply appropriate verification techniques based on the generally accepted
practices for the technologies employed in their products. Many of these
practices are an integral part of the development process, and are routinely
performed by developers. The objective of design controls is to ensure
adequate oversight by making verification activities explicit and measuring
the thoroughness of their execution. Following are a few examples of verification
methods and activities.
For some technologies, verification methods may be
highly standardized. In other cases, the manufacturer may choose from a
variety of applicable methods. In a few cases, the manufacturer must be
creative in devising ways to verify a particular aspect of a design. Some manufacturers erroneously equate production
testing with verification. Whereas verification testing establishes
conformance of design output with design input, the aim of production testing
is to determine whether the unit under test has been correctly manufactured.
In other words, production testing is designed to efficiently screen out
manufacturing process errors and perhaps also to detect infant mortality
failures. Typically, a small subset of functional and performance tests
accomplish this objective with a high degree of accuracy. Therefore,
production testing is rarely, if ever, comprehensive enough to verify the
design. For example, a leakage test may be used during production to ensure
that a hermetically-sealed enclosure was properly assembled. However, the
leakage test may not be sensitive enough to detect long-term diffusion of gas
through the packaging material. Permeability of the packaging material is an
intrinsic property of the material rather than an assembly issue, and would
likely be verified using a more specialized test than is used during
production. DOCUMENTATION OF VERIFICATION ACTIVITIES. Some verification methods result in a document by their nature.
For example, a failure modes and effects analysis produces a table listing
each system component, its postulated failure modes, and the effect of such
failures on system operation. Another self-documenting verification method is the
traceability matrix. This method is particularly useful when the design input
and output are both documents; it also has great utility in software
development. In the most common form of the traceability matrix, the input
requirements are enumerated in a table, and references are provided to each
section in the output documents (or software modules) which address or
satisfy each input requirement. The matrix can also be constructed
"backwards," listing each feature in the design output and tracing
which input requirement bears on that feature. This reverse approach is
especially useful for detecting hidden assumptions. Hidden assumptions are
dangerous because they often lead to overdesign, adding unnecessary cost and
complexity to the design. In other cases, hidden assumptions turn out to be
undocumented design input requirements which, once exposed, can be properly
tracked and verified. However, many verification activities are simply
some sort of structured assessment of the design output relative to the
design input. When this is the case, manufacturers may document completion of
verification activities by linking these activities with the signoff
procedures for documents. This may be accomplished by establishing a
procedure whereby each design output document must be verified and signed by
designated persons. The presence of the reviewers' signatures on the document
signifies that the design output has been verified in accordance with the
signoff procedure. Reference:
www.FDA.gov The information provided here is for "public
consumption" and is open to interpretation. MedicalDeviceSchool.com is
not responsible for the content or the accuracy of the information. For all
official interpretation and accuracy we ask that you consult the FDA's website directly and
that you consult with your legal and regulatory experts on all matters of
interpretation. |
|
||||
|
|
|
||||
|
|
|
|
|||
|
|
|
|
|
|
|
