Functional integration testing — verifying that combined software items produce the required behavior has always been part of the integration phase.
Class B applicability added by A1:2015. Normative scope for integration test content: risk control measures, interfaces, timing, and abnormal conditions including foreseeable misuse. [Class B, C]
Test plan coverage mapping to all five content areas, especially risk control integration test cases with traceability to the Risk Management File, and abnormal condition test coverage.
Maps to
IEC 62304: §5.6.4 Software integration testing content
ISO 13485: §7.3.6 Design and development verification
Pre-QMSR Part 820 (legacy QSR): §820.30(f) Design verification.
Requirement text
For software integration testing, the manufacturer shall address whether the integrated software item performs as intended. [Class B, C] NOTE 1 (non-normative) examples to consider include: the required functionality of the software; implementation of risk control measures; specified timing and other behavior; specified functioning of internal and external interfaces; and testing under abnormal conditions including foreseeable misuse.
Why this clause exists
Clause 5.6.4 specifies the content scope of integration testing, not just its execution. Without an explicit content requirement, integration testing could be limited to nominal functional checks while omitting the test scenarios most relevant to patient safety: risk control verification, interface behavior under error conditions, and performance under abnormal use. The explicit mention of risk control measures in the content scope is a key safety requirement — risk controls that span multiple software units must be verified in the integrated context, since unit-level verification may not exercise the control in the full combination of units that realize it. The foreseeable misuse testing requirement acknowledges that integration-level behavior under misuse often differs qualitatively from unit-level behavior.
What changed
Clause 5.6.4 was present in IEC 62304:2006. Amendment 1 (2015) added Class B applicability and made the content areas illustrative examples (using 'NOTE 1') rather than an exhaustive list, while the core requirement — addressing whether the integrated software item performs as intended — remained normative. The SaMD scope expansion makes this clause applicable to a broader range of software products.
Common gaps (what we see in audits)
- Risk control measures not included in integration test scope — Integration test plans cover functional test cases but do not include test cases for risk control measures implemented across multiple software units. Risk controls that span unit boundaries cannot be fully verified at the unit level — integration testing is the appropriate level for cross-unit risk control verification.
- Abnormal condition and foreseeable misuse testing absent from integration test plan — Integration testing covers nominal scenarios and does not include test cases for abnormal conditions or foreseeable misuse. Clause 5.6.4 explicitly requires abnormal condition testing as an integration test content area.