# Presentation: 778586

## CDRH Software Regulation

- John F Murray Jr..
- Center for Devices & Radiological Health
- US Food and Drug Administration
- JFM@CDRH.FDA.GOV

## 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

## 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?

## 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

**Notes:**

Testing alone is not sufficient to show that software implementation is correct and complete.  Need a structured and controlled development process that includes testing as one component.

## SOFTWARE  RECALLS1983  -  1996

- SOFTWARE  RECALLS1983  -  1996

## SOFTWARE  RECALLSBY  DEVICE  PANEL

- SOFTWARE  RECALLSBY  DEVICE  PANEL

## 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)

## 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.

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

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

## 21 CFR 820.30 (g) 

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

## 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.

## What is the goal?

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

## Safe and Effective 

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

## 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

## Partial FDA Software Timeline

**Part 2**
**Regulatory**
**Overview**

**Notes:**
New draft of  submission guidance to be reissued for industry comment Dec. or Jan.
FDA initiative via AAMI for new international software standard for medical device software.
Revision of ISO 9000-3 in process and very different.

## Documents to date

- General Principles of Software Validation; Final Guidance for Industry and FDA Staff OC
-  _[ ](http://www.fda.gov/cdrh/comp/guidance/938.html)_
- 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

## 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

## 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