Medical Device Software

Garðar Þorvarðsson

Kvikna ehf

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

Scope

• Development

• Issue resolution

• Configuration management

• Maintenance

• Risk management

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.

Step 1: System Design

• Divide the Medical Device into subsystems.

• Examples:

– Electronics

– Enclosure

– Firmware

– PC SW A

– PC SW B

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

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

Software Development Plan

• Roles

• What, who, when.

– Development activities

– Documentation

– Verification

– Risk

• Configuration: tools, code, documentation repository

Requirements specification

• Medical Device Requirements

– Assumed input to the process

• Software System Requirements

– Derived from MD requirements

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

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

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

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.

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