Scribd
Upload
120 views

FDA Software Development

This document discusses software regulation by the FDA's Center for Devices and Radiological Health (CDRH). It provides an overview of CDRH's perspective on software quality for medical devices and clinical information systems. Regulations recognize that software quality is primarily a design issue and require design controls, validation, and risk analysis for medical device software. The goal is for software to be reasonably safe and effective by following principles of software engineering, risk management, and quality systems. CDRH has published several guidances and supported standards development around software validation over the past several decades.

Uploaded by

JOhn Strupat
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
120 views

FDA Software Development

This document discusses software regulation by the FDA's Center for Devices and Radiological Health (CDRH). It provides an overview of CDRH's perspective on software quality for medical devices and clinical information systems. Regulations recognize that software quality is primarily a design issue and require design controls, validation, and risk analysis for medical device software. The goal is for software to be reasonably safe and effective by following principles of software engineering, risk management, and quality systems. CDRH has published several guidances and supported standards development around software validation over the past several decades.

Uploaded by

JOhn Strupat
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 18

CDRH Software Regulation

John F Murray Jr..


Center for Devices & Radiological Health
US Food and Drug Administration
[email protected]
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
SOFTWARE RECALLS
1983 - 1996
50
45
40
35
Number of Recalls

30
25
20
15
10
5
0
83 84 85 86 87 88 89 90 91 92 93 94 95 96
Year
SOFTWARE RECALLS
BY DEVICE PANEL
Radiology

InVitro Diagnostic

Cardiovascular

Anesthesiology 1983-91

General Hospital 1992-96

Other

0.0 2.0 4.0 6.0 8.0 10.0 12.0 14.0

Average Number of Software Recalls Per Year


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
Part 2
Regulatory
Overview

Partial FDA Software Timeline


1983 1985 1987 1989 1991 1993 1995 1997 1999

a c d e f g h j l p q t
b i k m r u
n s v
o
a. Guide to Computerized Systems in Drug Processing
b. Software Development Activities Reference Materials and Training Aids for Investigators
c. Draft FDA Policy for the Regulation of Computer Products
d. Draft Application of the Medical Device GMPs to Computerized Devices and Manufacturing Processes (Final 1992)
e. Draft Guidance for the Content and Review of 510(k) Notifications for Picture Archiving and Communications Systems(PACS)
and Related Devices
f. Reviewer Guidance for Computer Controlled Medical Devices Undergoing 510(k) Review
g. Draft Guideline for the Validation of Blood Establishment Computer Systems (Version 1 issued Oct-94)
h. Letter requiring submissions for Blood Bank Information Systems
i. Proposed Electronic Records: Electronic Signatures Rule
j. Glossary of Computerized System and Software Development Terminology
k. CADx Initiative
l. Telemedicine Related Activities Report
m. Public FDA Software Policy Workshop
n. Public Draft ODE Guidance for the Content of Premarket Submission for Medical Devices Containing Software
o. New Quality System Regulation
p. Do It By Design
q. Blood Bank Software Submission Guidance
r. Software Quality Audit Initiative
s. Final Rule Electronic Records: Electronic Signatures
t. General Principles of Software Validation - Draft Guidance
u. Guidance for Off-the-Shelf (OTS) Software Use in Medical Devices - Draft
v. Letter to Manufacturers Regarding the Year 2000 Computer Problem
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
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

You might also like