How to Plan Verification and Validation According to IEC 62304?

Deriving Tests from Risk and Intended Use

IEC 62304:2006+A1:2015 defines processes, activities, and tasks for the development and maintenance of medical software. Therefore, a test plan does not start with a list of technical test types, but with intended use, software requirements, architecture, and risk documentation. Each safety-related requirement needs a traceable proof; conversely, each test must indicate which requirement or risk control it is verifying.

The standard distinguishes software safety classes A, B, and C based on the potential harm that a failure can contribute to. Simplified, A stands for no potential health damage, B for potential non-severe damage, and C for potential death or severe injury. The classification determines the depth of the required activities but does not replace the MDR risk class of the product. Both classifications answer different questions.

Verification at Multiple Levels

A robust plan covers the steps of the software lifecycle:

• Check requirements for clarity, consistency, and verifiability,
• Verify architecture and detailed design against requirements and risk controls,
• Implement software units and verify them according to their criticality,
• Integrate units and test interfaces, data flows, and error handling,
• Check the software system against the approved requirements,
• Evaluate open anomalies, document configuration, and release a reproducible version.

Test types may include unit, integration, system, and regression tests. For medical software, depending on the product, boundary and fault injection tests, data integrity, roles and rights, timing behavior, compatibility, installation, updates, and safe fallback levels are added. Risk controls must not only be present; their effectiveness must be verified.

Validation Includes the Finished Product

Verification answers whether a development result meets its specified requirements. Validation answers whether the finished product meets the intended use and user needs. The IEC explicitly points out that it does not fully cover the final validation and release of the medical product – even if the product consists solely of software. Additionally, MDR Annex II number 6, usability according to IEC 62366-1, and clinical evaluation must be considered.

Release with Objective Criteria

Before each release, the test scope, accepted residual deviations, traceability, risk impact, known anomalies, configuration baseline, and responsible parties should be documented. Changes trigger a justified selection of regression tests; a blanket repetition of all tests is as unsubstantiated as tests without documented selection. The plan thus remains risk-based, version-related, and auditable.