The document outlines the IEC 62304:2006 standard for the software lifecycle of medical devices, emphasizing compliance with safety and risk management requirements. It details a classification system for software subsystems based on risk levels and outlines essential processes like development, verification, issue resolution, and maintenance. The standard is recognized by various regulatory bodies including the FDA and provides guidance on handling software updates and user feedback.

1. Medical Device Software
Garðar Þorvarðsson
Kvikna ehf

2. IEC 62304:2006
Harmonized standard for Medical Device Software
Lifecycle
• CE: Can be used to demonstrate compliance with
Essential Requirements.
• Replaces 60601-1-4
• FDA: Recognized, recommended for premarket
submissions.
• China: Recognized from 1st June 2009
• Canda: Recognized

3. Scope
• Development
• Issue resolution
• Configuration management
• Maintenance
• Risk management

4. Safety Classification
• Very central in the standard
• Important for manufacturers to divide the
software such that bulk of the software is
considered low risk.
• Classification in three easy steps follows.

5. Step 1: System Design
• Divide the Medical
Device into subsystems.
• Examples:
– Electronics
– Enclosure
– Firmware
– PC SW A
– PC SW B

6. Step 2 : Classify subsystems
Class A: No injury or damage to health is
possible
Class B: Non-serious injury is possible
Class C: Death or serious injury is possible

7. Step 3: divide B and C subsystems into
software Items, classify each software
Item

8. Software Development Plan
• Roles
• What, who, when.
– Development activities
– Documentation
– Verification
– Risk
• Configuration: tools, code, documentation
repository

9. Requirements specification
• Medical Device Requirements
– Assumed input to the process
• Software System Requirements
– Derived from MD requirements

10. Design documents
• Only classes B and C.
• Refine Software Systems to Software Items
– Specify interfaces between Items
– Refine SW Items to SW Units for class C.
– Specify SOUP Items = Software Of Unknown
Provenance

11. Verification
• Only for classes B and C!
– Still, note FDA, CFR 820 verification requirements.
1. Test software system requirements.
2. Unit tests.
3. Integration tests.
• Issue resolution procedure

12. Release
• Known issues
– Evaluate that known issues do not contribute to
risk.
• Book keeping
– Version control
– Ability to access code & documentation for any
release version
• Validation is outside the scope of 62304

13. Maintenance
• Receive, evaluate, resolve user feedback
– Evaluate if reported issue contribute to risk
– Notify authorities about problems (recalls etc.)
• Processes for SW updates
– Service Packs or Patches
• Processes to evaluate and implement changes
to SOUP‘s.

14. Risk Management
• Use 14971
• Identify all software items that could
contribute to hazardus situations
• Implement risk control similar to 14971
• Evaluate risk every time the SW is updated
– New versions
– Patches