Code review practice, unit testing, and documented acceptance criteria before integration — established development discipline.
Class B/C require formal unit verification records with defined acceptance criteria; Class C adds branch coverage and data range testing requirements.
Unit verification records — pull request approvals or code review records must link to acceptance criteria defined in the Software Development Plan.
Maps to
IEC 62304: §5.5 Software unit implementation
ISO 13485: §7.3.6 Design and development verification
Pre-QMSR Part 820: §820.30(f) Design verification.
Requirement text
The manufacturer shall implement each software unit [Class A, B, C].
Why this clause exists
Unit verification is the quality gate closest to the code — the point at which defects are cheapest and fastest to correct and where the assumption that software has been implemented per its design can be validated with evidence. IEC 62304:2006+A1:2015 clause 5.5 requires defined acceptance criteria for unit verification because acceptance criteria that are left implicit invite the conclusion that any code that compiles and does not obviously crash has passed — a standard that reliably allows latent defects in boundary conditions, error-handling paths, and safety-critical branches to survive into integration and system testing, where they cost orders of magnitude more to diagnose and fix. The requirement to record verification results is equally principled: without records, there is no evidence that verification was actually performed (as opposed to declared), and an audit of the verification record becomes an audit of nothing. For Class C software, the additional requirements for branch coverage and data range testing reflect the regulatory position that safety-critical software cannot be released on the basis of coverage of only the code paths that happen to be exercised by the nominal happy-path test cases — the paths that represent rare but safety-relevant conditions must be affirmatively tested, because those are precisely the paths most likely to be poorly exercised in field use and most likely to carry latent defects with patient-safety consequences.
What changed
Amendment 1 (2015) introduced a new compliance path for legacy software (Clause 4.4), allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
In Clause 4.3, Amendment 1 struck the 2006 sentence "The software safety classes shall initially be assigned based on severity as follows" and its three severity-based class definitions, and inserted class definitions that depend on whether the software system can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system, with the resulting possible harm being non-serious injury (Class B) or death or serious injury (Class C). Figure 3 states that the probability of a software failure shall be assumed to be 1 and that only risk control measures not implemented within (external to) the software system shall be considered. The 2006 text already allowed a hardware risk control measure to reduce the class (from C to B, and from B to A); Amendment 1 inserted a NOTE 1 stating that external risk control measures can be hardware, an independent software system, health care procedures, or other means. Amendment 1 also inserted a NOTE to clause 5.3.5 (Identify segregation necessary for risk control) that ends: "Other means of segregation can be applied when effectiveness can be ensured by the software ARCHITECTURE design (see B.4.3)."
The definition of SOUP was narrowed to apply only to software items — a complete medical device software system cannot be claimed as SOUP to bypass lifecycle requirements. New requirements were added for identification and avoidance of common software defects (5.1.12), IT security and networking considerations (5.2.2), and Class A software received additional testing, release, and monitoring requirements.
Common gaps (what we see in audits)
- Traditional code coverage insufficient for AI/ML components — For AI/ML software, traditional line-by-line code coverage metrics are insufficient. Regulatory expectations have shifted toward stratified testing using independent test datasets (not used in training) to prove performance across different demographic subgroups and clinical scenarios.
- Secure coding standards not tailored to health software — Organizations reference generic secure coding guidelines (e.g., OWASP) without tailoring them to medical device concerns such as fail-safe defaults for clinical alerting, data integrity for physiological signal processing, and safety-critical error handling.