Maps to
QMSR / ISO 13485: §820.30(e)
ISO 13485: §7.3.5
IEC 62304: §5.5
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.
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.
Atomic constraints
- •Each software unit must be implemented per the architectural and detailed design.
- •For Class B and C software, unit verification must be formally planned with acceptance criteria.
- •Unit verification results must be documented (e.g., code review records, unit test results).
- •For Class C software, additional acceptance criteria apply (branch coverage, data range testing).
- •Unit verification must be completed before integration.
Common gaps
Traditional code coverage insufficient for AI/ML components
majorFor 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
moderateOrganizations 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.
Evidence signals
- •
FILE_EXISTS
Unit.*Verification|Unit.*Test|Code.*Review.*Record|Verification.*Report
- •
CONTENT_MATCH
Does this document define unit verification acceptance criteria, describe the verification process (e.g., code review, unit testing), and indicate that results are recorded for each software unit?
Audit defense
Software unit verification for [your product] is performed via pull requests in our version control system. Each PR includes a code review by a non-author reviewer against documented acceptance criteria defined in the Software Development and Maintenance Plan. PR approval records constitute the IEC 62304 section 5.5 verification records.