The “design verification” requirement is not just a requirement of the FDA. This article describes what “design verification” means and which regulatory requirements medical device manufacturers should fulfill.
1. Design verification in a nutshell
Design verification is checking whether the development results (design output, e.g., design documents in the form of construction drawings) fulfill the requirements contained in the design input.
Because these checks require not only the documents but also the product, design verification should take place during the
- constructive phases (left in the V-model), for example, in the form of reviews, and the
- analytical phases (on the right in the V-model), typically in the form of tests.
Notes:
- In some cases, standards do not make a precise distinction between stakeholder and product requirements and, therefore, include legal requirements (stakeholder requirements) as design input, although reviewing stakeholder requirements is a validation activity.
- Development results in the form of (architecture) documents are often created as part of several development activities and phases. Therefore, these results may be verified several times.
- The final check as to whether the design input in the form of product requirements has been fulfilled is only carried out at the product level (referred to as the “product system test” in Fig. 1).
The derivation and discussion are in the third section of this article. The fourth section addresses common misunderstandings.
2. Regulatory requirements
FDA requirements for design verification
The FDA requires in 21 CFR part 820.30(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.
The “specified properties or requirements” are to be checked during verification; therefore, refer to the design input during design verification. The FDA also describes this design input:
Design input. Each manufacturer shall establish and maintain procedures to ensure 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. The procedures shall include a mechanism for addressing 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.
FDA 21 CFR part 820.30 (c)
As described in this article on design input, this primarily corresponds to the product/system requirements (Product/System Requirements Specification).
ISO 13485 requirements for development verification
Likewise, ISO 13485 also requires, in chapter 7.3.5, “Development verification,” that the development results fulfill the development specifications and that this verification be documented. ISO 13485 also includes “functional, performance, and safety requirements” among the development specifications, which are also at the level of the system requirements specification.
However, ISO 13485 also mentions legal requirements, which are classified as stakeholder requirements. A review of stakeholder requirements would be more of a validation.
3. Derivation
a) Definitions
In contrast to “Design Validation,” the FDA does not explicitly define the term “Design Verification.” However, it does define “verification”:
confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.
This corresponds to the definition of ISO 9000, which defines verification as a test using objective means to determine whether specified properties or requirements are fulfilled.
According to 21 CFR part 820.3 and ISO 13485, design verification corresponds to the (planned) activities to check (verify) the design output concerning whether it meets the design input requirements. To understand this in more detail, several questions need to be clarified:
- What is the design input?
- What is the design, and what are the design outputs?
- How should manufacturers verify the design?
The following sections provide answers to these questions.
b) Design Inputs
The design inputs are generally the product requirements, precisely requirements relating to the functionality, performance, suitability for use, and safety of the product. As explained above, ISO 13485 also includes regulatory requirements among the design inputs.
Regulatory requirements are stakeholder requirements. However, some regulatory requirements place specific demands on the product to the extent that manufacturers do not have to convert these stakeholder requirements into product requirements.
- Example: IEC 60601-1 specifies the maximum leakage currents of a PEMS. This is a (verifiable) product requirement.
- Counter-example: IEC 62366-1 requires manufacturers to minimize the risks due to usage errors. Manufacturers must translate this requirement into specific (and verifiable) requirements for the user interface.
The Practical Guide to ISO 13485 lists further elements of the design input:
- Experience with similar products
- “Benchmarking Results”
- Results of market surveys
- Packaging requirements
- Standards
c) Design & Design Outputs
The design is the conception of the product. The design activity results in many different artifacts (design output):
- Design drawings
- Component lists, component specifications
- Specifications for production, including product tests (e.g., processes, materials, tools)
- Software
- Instructions for use, installation, and service instructions
The Practical Guide explicitly includes the medical device itself in the design output..
d) Design Verification
ISO 13485 requires two verifications:
- according to Chapter 7.3.4, the elements of the design output should be (checked and) approved as to whether they are suitable (“suitable”) for design verification.
- in chapter 7.3.6, the standard requires “Design and Development Verification.” Similar to FDA 21 CFR part 820.30, manufacturers must check whether the design output fulfills the design input requirements.
The timing and type (methods) of the second verification (Design and Development Verification) depend on the item being verified:
- Documents
Some design outputs, such as documents like design drawings, can be checked immediately after their creation. It is also possible to check whether the system architecture can serve the interfaces specified in the product requirements (design input). - Product, components
Other design outputs can only be checked on the product or its components. For example, a product’s performance can only be verified on the product itself.
Depending on the type of review, different methods are used in design verification:
- Documents: reviews, checklists…
- Product, components: (bench) tests such as functional tests, load tests, simulations, and EMC tests; inspections and methods of formative evaluation such as cognitive walkthrough, heuristic evaluation
4. Practical implementation
a) Avoid misunderstandings
Manufacturers often refer to an FDA model (see Fig. 2).
However, this diagram can be misunderstood in several ways:
- Design verification is based on design output, but not necessarily (only) at the end of the development process. Furthermore, this process is usually non-linear.
- The diagram does not distinguish between activities and artifacts precisely. For example, the “Design Process” includes activities. However, the “Design Output” comprises artifacts such as documents and products.
- It appears the review is used to review the activities or artifacts. However, a distinction must be made between a “design review” and a review of intermediate results. These methods are not the same, as the article “Design review is not the same as a review of the design” explains.
- There is no legal requirement to carry out a “design review” for the respective activities.
- A review is only one of several possible methods for checking intermediate and final results.
However, not every verification of the design output is a design verification. Design verification aims to verify that the “design input requirements” have been met. Using the design outputs to confirm whether the design process has been adhered to would be more of a design review in the sense of ISO 13485.
b) Software example
The regulations require that the design verification ensures that development inputs such as the system requirements specification are fulfilled.
Design verification must, therefore, include at least the verification of this system requirements specification. This corresponds to the software system test.
It is often impossible to check the correct implementation of system/software requirements with sufficient “certainty” at the system level alone. That is why the tests at the lower test levels also count towards design verification.
Strictly speaking, the reviews of the software architecture also ensure that the selected planning/architecture is suitable for compliance with the “design inputs” (software requirements).
IEC 62304 explicitly refers to a verification of the software architecture and not to a review of the architecture. This is because a review is only one of many options for this review. Others include checking prototypes, determining dependency metrics, and benefiting from checklists.
It can be stated that the design verification of a standalone software always includes
- software system tests,
- ideally, the integration and unit tests (and static reviews of the source code) should also be included
- as should the verification of the software architecture.
5. Conclusion and summary
Design verification is subject to a misunderstanding similar to the term design review. This is also due to regulatory requirements that do not follow any recognizable and globally coordinated mental model.
This article has attempted to provide this model.
Please also refer to the article on design validation.
Change history
- 2024-12-05: Article almost completely rewritten
- 2015-10-15: Article first published
