Why Verification Records Are Required for All Specifications

In the development of medical device software, the IEC 62304 standard requires that verification activities be performed on deliverables created at each stage of software development, and that records of these activities be maintained. Deliverables from each development stage, including requirements specifications, architecture design documents, and detailed design documents, are subject to verification. While this requirement may initially seem excessive, it holds extremely important significance in ensuring the safety of medical devices.

Background of the Verification Record Requirement

In traditional software development, quality is often considered guaranteed if the final testing is passed. However, for medical device software where human lives may be at stake, this approach is insufficient. IEC 62304 is based on the recognition that “testing alone cannot guarantee quality.”

Why is testing alone insufficient? The answer is that there are limits to the defects that testing can discover. Defects introduced during the design stage, in particular, become increasingly difficult to detect in later stages, and the cost of correction escalates. In the case of medical devices, if defects are discovered after products reach the market, they may lead to harm to patients’ health.

The Importance of Defect Removal at the Design Stage

The primary reason IEC 62304 requires verification records for deliverables at each development stage is to ensure thorough defect removal during the design phase. This is based on a quality assurance concept called “shift left.” By building quality into the early stages of the development process (the left side), it becomes possible to prevent rework in later stages and enhance the safety of the final product.

For example, if there are ambiguous descriptions or contradictions in the requirements specification stage, these will affect subsequent design and implementation. If safety is not considered in the architecture design, fundamental problems cannot be resolved no matter how carefully implementation is performed. By conducting appropriate verification at each stage, it becomes possible to discover and correct these problems early.

What is crucial is that these verification activities are implemented through a risk-based approach according to the software safety class (Class A, B, or C). For Class C software, which directly relates to human life, more rigorous verification is required.

Content Required in Verification Records

What is important to understand is that simply conducting reviews and obtaining signatures is insufficient. IEC 62304 requires documentation of specific verification content. Regulatory authorities and certification bodies seek evidence of substantive verification activities, not just formal signatures. Verification records should include the following elements:

Verification Planning and Methods: Clearly define from what perspectives and by what methods verification will be conducted. Document specific techniques such as whether checklists will be used, whether walkthroughs will be conducted, or whether formal verification methods will be applied.

Verification Implementation Records: Record when, who, and what verification was conducted. Include problems or questions discovered and the content of discussions about them. Rather than simply recording “no problems found,” clarify what perspectives were used for confirmation and what judgment criteria led to the conclusion of no problems.

Evaluation of Verification Results: Clarify how problems discovered during verification were resolved, whether residual risks exist, and whether criteria for proceeding to the next stage are met. When problems are discovered, also record the response status and results of re-verification.

Traceability: Maintain evidence that the deliverable being verified meets higher-level requirements and regulatory requirements. For example, make it traceable whether the detailed design document meets the architecture design requirements, and whether the architecture design meets the requirements specification.

Practical Approaches

Creating verification records for deliverables at each development stage is certainly a labor-intensive task. However, there are methods to implement this efficiently.

First, embed verification activities into the development process. Rather than treating specification creation and verification as separate activities, plan them as an integrated process. By involving verifiers with different perspectives from specification creators from an early stage, quality improvement and reduction of rework can be achieved simultaneously.

Second, standardize verification methods. By developing checklists and templates, efficiency can be improved while maintaining verification quality. However, it is important to leave room for utilizing the specialized knowledge and judgment of verifiers to avoid falling into mere formal checking. Since IEC 62304 does not specify concrete formats, organizations can select optimal methods according to their characteristics.

Additionally, utilizing a risk-based approach is important. Rather than verifying all items at the same level, adjust the depth of verification according to the degree of impact on safety. Conduct more detailed verification for designs related to critical functions, and verify low-risk parts efficiently.

Regulatory Authority Perspective

In regulatory authority reviews, not only the presence or absence of verification records but also the validity of their content is evaluated. With formal review records alone, there is a possibility of being judged that substantive quality assurance activities have not been conducted. Verification records serve as important evidence demonstrating that the development organization is seriously considering the safety of medical devices and implementing appropriate processes.

In particular, regulatory authorities such as the FDA (U.S. Food and Drug Administration) and PMDA (Pharmaceuticals and Medical Devices Agency in Japan) carefully confirm whether verification activities were conducted in a planned manner and whether the results were appropriately documented. Verification records become an important component of technical documentation demonstrating the basis for product safety and effectiveness.

Summary

The reason IEC 62304 requires verification records for deliverables at each development stage is an inevitable requirement to ensure the safety of medical device software. This is not merely a burden of document creation but an investment to enhance the safety of the final product through quality building at the design stage.

While creating verification records certainly requires effort, considering the quality improvement gained and the reduction of rework in later stages, it is a sufficiently valuable activity. Furthermore, appropriate verification records become essential documents when submitting to regulatory authorities and are also important elements for smoothly advancing product market introduction.

As those involved in medical device development, we are required to understand the safety considerations behind this requirement and to conduct effective verification activities. Rather than ending with formal document creation, we should approach the creation of verification records as quality assurance activities that truly protect patient safety.

Software Safety Class	Verification Rigor	Key Requirements	Examples
Class A	Basic	Standard verification and documentation	Software with no injury or health damage possible
Class B	Moderate	Enhanced verification including architecture review	Software that could cause non-serious injury
Class C	Highest	Comprehensive verification including detailed design and unit verification	Software that could cause death or serious injury

The shift left approach advocated by IEC 62304 emphasizes that quality cannot be tested into a product at the end; it must be built in from the beginning. Early verification activities, though requiring upfront investment, ultimately reduce costs, improve safety, and facilitate regulatory approval. By embracing this paradigm, medical device software developers can deliver products that meet both regulatory requirements and the highest standards of patient safety.