ISO 13485 · Expert · 14 min lesson
Software verification, maintenance, problem resolution and cybersecurity links
IEC 62304:2006+A1:2015 clauses 5.5 to 5.8, 6, 7.4, 8.2 and 9; MDR Annex I sections 17.2 and 17.4; MDCG 2019-16 Rev.1; IEC 81001-5-1:2021
What you will learn
- Plan and judge software verification from unit to system test and a release record that evaluates known anomalies (clauses 5.5 to 5.8).
- Run maintenance and problem resolution under clauses 6 and 9, including change analysis, regression retest and trend analysis.
- Link vulnerabilities, SOUP and security updates to the software lifecycle using MDR Annex I, MDCG 2019-16, IEC 81001-5-1 and FDA section 524B.
Key takeaways
- Verification runs through the lifecycle: architecture, design, unit, integration and system testing, with the class deciding which tasks apply.
- A release record confirms verification is complete and documents and evaluates every known residual anomaly (clause 5.8).
- Every software change needs a safety impact analysis, change control and a retest sized to the risk (clauses 7.4, 8.2, 5.7.3).
- Every problem gets a report, investigation, change control, verification of the fix and trend analysis (clause 9).
- Vulnerabilities are problem reports; the SOUP list underpins a software bill of materials (MDR Annex I 17.2 and 17.4, MDCG 2019-16, IEC 81001-5-1).
Free practice question
Halden's release record for DoseGuide 4.3.1 states 'No known anomalies'. The problem tracker holds PR-317, open, high severity: the displayed dose is rounded differently from the calculated dose on one phone model. The release manager says open items are tracked separately.
What does clause 5.8 require?
Document PR-317 as a known residual anomaly and evaluate its risk, or fix it before release.
Correct. Clauses 5.8.2 and 5.8.3 require known anomalies to be documented and evaluated for unacceptable risk before release.
Nothing, because separate tracking of open items is acceptable.
Not quite. Clause 5.8.2 requires the release record itself to document the known anomalies, so separate tracking is not enough.
Remove PR-317 from the tracker so the statement becomes true.
Not quite. Deleting a record to match a statement is falsification, and clause 9.5 requires problem records to be maintained.
Release and mention the anomaly only if a customer asks.
Not quite. Clause 5.8.3 requires the evaluation before release, so disclosure on request comes too late.
Key terms
- regression testing: Repeating tests after a change to show that existing behaviour and risk controls still work (clause 5.7.3).
- residual anomaly: A known defect that remains in released software and has been documented and evaluated for risk (clauses 5.8.2 and 5.8.3).
- problem report: The record of a software problem, its investigation, resolution and verification under clause 9.
- change request: A controlled request to modify released software, analysed for safety impact and approved before implementation (clauses 6.2, 7.4, 8.2).
- software bill of materials: A list of the software components in a product with versions, built from the SOUP inventory and used to monitor vulnerabilities.
- IEC 81001-5-1: A 2021 standard defining security activities in the health software product life cycle, building on the IEC 62304 structure.
- MDCG 2019-16: EU guidance (Rev.1, July 2020) on how manufacturers can meet the cybersecurity expectations of MDR Annex I.
- trend analysis: Review of problem reports across modules, versions and causes to find patterns that single reports hide (clause 9.6).
Official sources
- IEC 62304:2006 Medical device software - Software life cycle processes (with Amendment 1:2015), ISO catalogue entry
- MDCG 2019-16 Rev.1 Guidance on Cybersecurity for medical devices (July 2020)
- IEC 81001-5-1: The standard for secure health software (Johner Institute overview)
Go further
The full lesson has narrated slides, more scenario questions with explained answers and a simulation.
Open the AcademyWatch on YouTubeIllustrative example. Educational only, not legal advice.