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 (legacy QSR): §820.30(f) Design verification.
Requirement text
The manufacturer shall implement each software unit in accordance with the detailed design. For Class B and C software, a unit verification process with defined acceptance criteria must be established and executed, with results recorded.
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) expanded the scope to explicitly include health software and Software as a Medical Device (SaMD), not just software embedded in physical medical devices. A new compliance path for legacy software (Clause 4.4) was introduced, allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
The software safety classification criteria (Clause 4.3) shifted from severity-only to include probability of hazardous situations. External risk control measures (hardware or clinical procedures) can now reduce the software safety class, but internal software mitigations cannot. The standard clarified that logical segregation (not just physical) is acceptable for classification purposes.
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 publishing known defects with risk assessments (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.