CDRH Software Regulation

1
CDRH Software Regulation

• John F Murray Jr..
• Center for Devices Radiological Health
• US Food and Drug Administration
• JFM_at_CDRH.FDA.GOV

2
Public Health and Software

• The Quality of Pubic Health is highly dependent
  on the Quality of Medical Software
• i.e. Medical Device Software, Clinical
  Information Systems, Hospital Information
  Systems, Manufacturing Systems etc

3
What type of Quality do we Want?

• To get some perspective lets try what I call the
  YB scale. yugo vs. bmw
• I ask the following questions
• Where would Microsoft be on this scale?
• Where do we want our software quality to be?

4
SOFTWARE IS DIFFERENT

• Software Quality - Primarily a design issue
• Custom developed components
• Complexity
• Structured development process plus testing
• Dormant latent defects
• Software is easy to change
• Difficult to control changes
• Significance of changes

5
SOFTWARE RECALLS1983 - 1996
6
SOFTWARE RECALLSBY DEVICE PANEL
7
Do the regulations recognize this need

• Yes they do
• 21 CFR 830.30
• 21 CFR 830.30 (a) (2) (i)
• 21 CFR 830.30 (g)
• 21 CFR 830.70 (i)

8
21 CFR 820.30 Design Controls

• Each manufacturer of any Class II or Class III
  device, and the Class I devices listed in
  paragraph (a)(2) of this section, shall establish
  and maintain procedures to control the design of
  the device in order to ensure that the specified
  design requirements are meet.

9
21 CFR 820.30 (a)(2)(i)

• Class I
• The following Class I devices are subject to
  design controls
• Devices automated with computer software

10
21 CFR 820.30 (g)

• Design validation shall include software
  validation and risk analysis where appropriate

11
21 CFR 820.70 (i)

• Automated processes
• When computers or automated data processing
  systems are used as part of production or the
  quality system, the manufacturer shall validate
  computer software for its intended use according
  to an established protocol. All software changes
  shall be validated before approval and issuance.
  These validation activities shall be documented.

12
What is the goal?

• By Law Medical Devices must be reasonable safe
  and effective
• By default Software must be safe and effective

13
Safe and Effective

• It depends!
• Cannot be easily defined
• What is safe and effective software
• Software Engineering
• Risk Management
• Quality System

14
CDRH Software Message

• The law and regulations are written in broad
  terms
• Software should be engineered using
• Software Engineering
• Risk Management
• Quality System
• This is the CDRH Software Message

15
Part 2 Regulatory Overview
Partial FDA Software Timeline
16
Documents to date

• General Principles of Software Validation Final
  Guidance for Industry and FDA Staff OC    
• Guidance for Off-the-Shelf Software Use in
  Medical Devices Final ODE  
•    
• Guidance for the Content of Premarket Submissions
  for Software Contained in Medical Devices Final

17
Other Works

• AAMI SW 68
• IEC/ISO International Version of SW 68
• AAMI TIR on Software Hazard Management
• AAMI TIR on Validation of High Risk Software
• AAMI TIR on Validation of Quality System and
  Manufacturing Software

18
We have been at this a long time

• Our first publication was 1991
• We continue to support standards development
• We continue to support the development of TIR
• Training to come