Medical Product Software Development and FDA Regulations4008

7/27/2019 Medical Product Software Development and FDA Regulations4008

1/85

Medical Product Software Developmentand FDA Regulations

Software Development Practices and FDA Compliance

IEEE Orange County Computer Society

March 27, 2006

Carl R. Wyrwa


2/85

2

Medical Product Software Development and FDA Regulations



Introduction

Regulated Software

FDA OverviewMedical Device Definition

Software Special Attention

Regulation Of Software

Basic RequirementsSoftware Quality Model

Software Safety Model

Software Maintenance

Corrective Action and Preventive Action (CAPA)Reference Material

Conclusion


3/85

3



The Intent Of Regulating Software

Patients

Operators Bystanders Service

Personnel

Environment

Medical Device Safety and Efficacy


4/85

4



People

Doing

TheWork

Reviewers

Internal AuditorsExternal Reviewers

Many Stakeholders Keeping A Total Solution In Mind

SafetyPatients

Operators

BystandersService People

Environment Customer

and

Business

Needs

Quality

Systemsand

Q&RA

Medical

Practitioners

All

Needs

Met


5/85

5



Many Stakeholders Keeping A Balanced Solution In Mind

People

Doing

TheWork

Reviewers

Internal AuditorsExternal Reviewers

SafetyPatients

Operators

BystandersService People

EnvironmentCustomer

and

Business

Needs

Quality

Systems

andQ&RA

Medical

Practitioners

All

Needs

Met


6/85

6



Introduction

Regulated Software








Conclusion



7/85

7



Types of Regulated Software

Medical Device Software

z Software that is actually a part

of the medical device itself

z Software that is an accessory

to a medical device

z Software that itself is a medical

device


8/85

8



Types of Regulated Software

Medical Device Software

z Software that is actually a part

of the medical device itself

z Software that is an accessory

to a medical device

z Software that itself is a medical

device

Non-Device Software that is part of:

z The production system

z The quality system

z Systems that are used to create

and maintain records required

by FDA regulations


9/85

9



Introduction

Regulated Software








Conclusion



10/85

10



FDA Overview

FDA is a public health agency, charged with:

z protecting American consumers by enforcing the Federal Food, Drug,and Cosmetic Act and several related public health laws.

It is FDA's job to see that:

z

the food we eat is safe and wholesome,z the cosmetics we use won't hurt us,

z the medicines and medical devices we use are safe and effective,

z and that radiation-emitting products, such as microwave ovens, won't do

us harm

z One of our nation's oldest consumer protection agencies.

z Located in district and local offices in 157 cities across the country


11/85

11



Medical Devices

32,358


12/85

12



FDA Overview

z Administrative Enforcement Powersz Unannounced and Announced Inspections

z Inspectional Observations - 483z Warning Letters

z Adverse Publicity

z FDA-Initiated Recalls and Monitoring Company-Initiated Recalls

z Delay, Suspension, or Withdrawal of Product Approvals

z Preclusion of Government contractsz Detention and Refusal of Entry into U.S. Commerce of Imported Products

z Judicial Enforcement Powersz Civil Enforcement Powers (Seizure)

z Criminal Enforcement Powers (Prosecution)


13/85

13



Introduction

Regulated Software








Conclusion



14/85

14



Medical Device Definition

z Medical devices range from

z Simple Devices

z Tongue depressors and bedpans

z Complex Devices

z Programmable pacemakers

z Laser surgical devices

z Medical Device Classification Class I, II, and III

z Class I devices include those with the lowest risk

z Class III devices includes those with the greatest risk.


15/85

15




"an instrument, apparatus, implement, machine, contrivance, implant, invitro reagent, or other similar or related article, including a component part,

or accessory which is: recognized in the official National Formulary, or the United States

Pharmacopoeia, or any supplement to them,

intended for use in the diagnosis of disease or other conditions, or

in the cure, mitigation, treatment, or prevention of disease, in man orother animals, or intended to affect the structure or any function of thebody of man or other animals,

and which does not achieve any of it's primary intended purposes

through chemical action within or on the body of man or other animalsand which is not dependent upon being metabolized for the achievementof any of its primary intended purposes."


16/85


17/85

17



820.30 Design Control

820.30(a) General

z (1) Each manufacturer of any class III or class II device,

and the class I devices listed in paragraph (a)(2) of this section, shall:

z establish and maintain procedures to control the design of the device inorder to ensure that specified design requirements are met.

z (2) The following class I devices are subject to design controls:

(i) Devices automated with computer software; and (ii) The devices listed .. Below:

Catheter, Tracheobronchial Suction

Glove, Surgeons

Restraint, Protective

System, Applicator, Radionuclide, Manual

Source, Radionuclide Teletherapy


18/85

18




General Principles of Software Validation

3.3 Software Is Different From Hardware

z Because of its complexity, the development process for software should

be even more tightly controlled than for hardware, in order to prevent

problems that cannot be easily detected later in the developmentprocess.

z . software engineering needs an even greater level of managerial

scrutiny and control than does hardware engineering.

[1]


19/85

19



Introduction

Regulated Software








Conclusion



20/85

20



Regulation of Software

21 CFR 807Establishment Registration

21 CFR 807Medical Device Listing

21 CFR 807Premarket Notification 510(k)

21 CFR 820Quality System Regulation

21 CFR 801Labeling

21 CFR 803Medical Device Reporting

21 CFR 814Premarket Approval PMA

Basic RegulatoryRequirements


A - General Provisions

B - Quality SystemRequirements

C Design Controls

D Document Controls

E Purchasing Controls

F Identificationand Traceability

G Production & ProcessControls

H Acceptance Activities

I Nonconforming Product

J Corrective & PreventiveAction (CAPA)

K Labeling & PackagingControl

L Handling, Storage,Distribution & Installation

M - Records

N - Servicing

O Statistical Techniques

Quality System Regulation

C Design Controls

820.30(a)

General

820.30(b)

Design & Development Planning

820.30(c)

Design Input

820.30(d)

Design Output

820.30(e)

Design Review

820.30(f)

Design Verification

820.30(g)Design Validation

820.30(h)

Design Transfer

820.30(i)

Design Changes

820.30 (j)

Design History File

Design Controls


21/85

21








21 CFR 801Labeling







C Design Controls

D Document Controls









M - Records

N - Servicing



820.70(a)

General

820.70(b)

Production & Process Changes

820.70(c)

Environmental Control

820.70(d)

Personnel

820.70(e)

Contamination Control

820.70(f)

Buildings

820.70(g)

Equipment

820.70(h)

Manufacturing Material

820.70(i)

Automated Processes

Production & Process Controls


820.70(i)

Automated Processes


22/85

22








21 CFR 801Labeling







C Design Controls

D Document Controls









M - Records

N - Servicing




820.100

Corrective & Preventive Action

Quality SystemRequirements


23/85

23








21 CFR 801Labeling







C Design Controls

D Document Controls









M - Records

N - Servicing




820.25(a)

General

820.25(b)

Training

Quality SystemRequirements

820.22

Quality Audit

Procedures


24/85

24



Software Basic Requirements



C Design Controls

D Document Controls









M - Records

N - Servicing



SW Risk/Hazard Analysis

SW Human Factors (Use Errors)

SW Change Control

SW Configuration Management

SW Problem Tracking & Resolution

SW Traceability

Non-Product Software Validation

Design Transfer

Design History File

Training

Software Quality Audits

SW Architecture Verification

SW Detailed Design

SW Detailed Design Verification

SW Coding

SW Code VerificationUnit Test

Integration Test

SW System Test

Beta Testing

SW Verification

SW Validation

COTS Software Components

Plans

SW Life-Cycle Model

SW Requirements Analysis

SW Requirements Verification

SW Architectural Design

Corrective & Preventive Action (CAPA)


25/85

25



Introduction

Regulated Software








Conclusion



26/85

26



Procedures and Plans

Procedures

Plans

You must be able to demonstrate that you are

Operating In A State Of Control

PlansProcedures +

Establish, in advance of activities, what you are going to do.

Do what you say you are going to do.

Be able to provide objective (documented) evidence.


27/85

27



Software Development


SW Detailed Design


SW Coding

SW Code Verification

SW Life-Cycle Model





28/85

28



Testing

Unit Test

Integration Test

SW System Test

Beta Testing


29/85

29



Verification & Validation

SW Verification

SW Validation

Engineering Correctness Checks

Intended Use Confirmation


30/85

30



Supporting Processes



SW Change Control



SW Traceability



Corrective and Preventive Action (CAPA)


31/85

31



ReleaseDesign Transfer

Design History File


32/85

32



PersonnelTraining



33/85

33



Introduction

Regulated Software








Conclusion



34/85

34



The Reason

WHYwe need to have a comprehensive and effective

Software Development Life Cycle

Software Quality and Software Safety


35/85

35



The Intent Of Regulating Software

Patients


Personnel

Environment

Medical Device Safety and Efficacy


36/85

36



Understanding Defects

Start Development Process Ship

Defects

[2]


37/85

37





Defects

Defects

Injected

[2]

M di l P d S f D l d FDA R l i


38/85

38





}DefectsShipped

Defects

Defects Detected

And Corrected

Defects

Injected

[2]

M di l P d t S ft D l t d FDA R l ti


39/85

39



A Journey To Fewer DefectsOverall Software Quality


Defects

Inject

Fewer

[2]

M di l P d t S ft D l t d FDA R l ti


40/85

40



Software Quality Model

Understanding Defect Injection Rates

SoftwareDetailedDesign

SoftwareCoding

SoftwareHigh-Level

Design

SoftwareRequirements

Defect injection rates can bereduced

by

Performing these activities highly effectivelyand introducing Causal Analysis



41/85

41






SoftwareCoding

SoftwareHigh-Level

Design


Defect injection rates willincrease

if

You do not perform these activities wellor you decide not to do the activity at all



42/85

42






SoftwareCoding

SoftwareHigh-Level

Design


Defect Injection Rates are directly related to

the completeness and the effectiveness of eachof these activities



43/85

43



Software Quality ModelUnderstanding Defect Injection Rates

0

10

20

30

40

50

60

70

80

90

100

SysR

eqs

SWRe

qs

HLDe

sign

DetD

esign

Codin

g

UnitT

est

IntTe

st

SWSysT

est

SysV

alid

BetaTe

st

Custo

mer

Defects per 1000 lines of code

Defects

Injected

CumulativeDefects



44/85

44





DetectEarlier

Detect More

Effectively

Defects

Inject

Fewer

[2]



45/85

45



Software Quality ModelIncreasing Effectiveness

Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design


Verification Verification

IntegrationTest

SoftwareSystem

Test

SystemValidation

Beta SiteTesting

Customer



46/85

46





} FewerDefects

DetectEarlier

Detect More

Effectively

Defects

Inject

Fewer

Zero?

[2]



47/85

47



Introduction

Regulated Software








Conclusion



48/85



49/85

49

p g



Risk/Hazard Analysis & Use Error Analysis

Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation

Beta SiteTesting

Customer

Risk/Hazard Analysis

Use Error Analysis

Induced By:Basic Functionality

Software DefectsUse ErrorsEnvironmentInterfaces



50/85

50

p g


Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation

Beta SiteTesting

Customer





51/85

51

p g




Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation

Beta SiteTesting

Customer


Use Error Analysis



52/85

52



A Continuous Process Throughout the Life Cycle

Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation

Beta SiteTesting

Customer


Use Error Analysis



53/85

53




Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation

Beta SiteTesting

Customer


Use Error Analysis



54/85

54




Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystemTest

SystemValidation

Beta SiteTesting

Customer


Use Error Analysis



55/85

55


Software Safety ModelUse Error Analysis

User Error

Blames The User For Doing Something Wrong

Developer takes accountability for developing softwarethat allowed the user to make an error

User Error

Use Error

X

And..the developer incorporates Use Error Analysisinto the risk management process resulting inthe implementation of built-in safeguards to protectagainst Use Error



56/85

56


Software Safety ModelUse Error Analysis

Use Error (Human Factors) Considerations

z Skill Level Variation

z Environmental Variation

z

Compromising Factorsz Physical and Sensory Characteristics

z Perception

z Cognition

z Expectancies

z Mental Models

z Home Use


S ft D l t P ti d FDA C li


57/85

57


Software Safety ModelRisk/Hazard Analysis & Use Error Analysis

Interfaces

Environment

Use Errors

Defects

Basic

Functionality

Potential Harm

To

Environment

Potential Harm

To

Service

Personnel

Potential Harm

To

Bystanders

Potential Harm

To

Operators

Potential Harm

To

Patients

You are developing a

function where theuser will be asked to

manually enter a

patients age

YESYou realize that if the

age is entered incorrectly

that an incorrect diagnosis

might be made


S ft D l t P ti d FDA C li


58/85

58


Software Safety ModelRisk/Hazard Analysis & Use Error Analysis

Potential

Hazard

Potential

EventSeverity

Control

Mitigation

Post

Control

Severity

V&VFunction

Feature

PatientAge

Entry

Incorrect

Diagnosis

Incorrect Age

Entered(Use Error)

MajorEnter

Date of Birth

(cross check)

AcceptableTest

Procedure

12345


59/85


Soft are De elopment Practices and FDA Compliance


60/85

60


Introduction

Regulated Software

FDA Overview








Conclusion





61/85

61


Recall Statistics

FDA Analysis 3140 Recalls (1992 1998)

Software-related recalls 242Software recalls due to changes 192 (79%)

Of those software related recalls, 192 (or 79%) werecaused by software defects that were introduced whenchanges were made to the software after its initial production anddistribution

Software Related Recalls

Due To Changes(79%)

Initial(21%)

FDA Guidance (2002) General Principles of Software Validation




62/85

62


Maintenance Challenges

Maintenance

Challenges

Oversimplification of the taskCustomer and Patient expectationsIncreased requirements on system

ChangesDesign additions and/or modifications

State of the documentationKnowledge level

Personnel changesSoftware components (COTS)

Hardware componentsInterfaces

Cybersecurity issues




63/85

63


Creating A Balance

ChallengesOversimplification of the taskCustomer and Patient expectationsIncreased requirements on system

Changes

Design additions and/or modificationsState of the documentation

Knowledge levelPersonnel changes

Software components (COTS)Hardware components

InterfacesCybersecurity issues

Processes

Requirements managementAnomaly management

Technology transition management

Risk management

TrainingChange control

Software development life cycle

Technical reviews

Validation planningTesting

Configuration management

Documentation updates




64/85

64


Introduction

Regulated Software

FDA Overview




Basic Requirements





Conclusion





65/85

65


Corrective Action Preventive Action (CAPA)

Problem Encountered

Investigate

Find Root Cause

Correct The Problem

Same Product

Similar Problems?

Investigate

Find Root CauseCorrect The Problem

Other Products

Similar Problems?Investigate

Find Root Cause

Correct The Problem

Process Change

Prevent Similar

Problems From

Occurring InThe Future




66/85

66


Introduction

Regulated Software

FDA Overview




Basic Requirements





Conclusion





67/85

67


Quality System

Regulation

The Regulation The Quality System Regulation 21 CFR 820

General

Principles ofSoftware

Validation

Software

Pre-MarketSubmission

Guidance

Off-The-Shelf

Software

GuidanceFDA Software Specific References General Principles of Software Validation

Software Pre-market Submission Guidance Off-The-Shelf Software Guidance

Medical Device

QualitySystem Manual

Design ControlGuidance

Do It By

Design

Guide To

Inspections Of

Quality Systems

(QSIT)

Medical Device

Use Safety

Human Factors

Risk Mgmnt

FDA General References Medical Device Quality System Manual Design Control Guidance Do It By Design Medical Device Use Safety (Human Factors/Use Errors)

Guide To Inspections Of Quality Systems (QSIT)

Industry ReferencesANSI/AAMI SW68 ISO 62304

ANSI/AAMI

SW68:2001

Software

Processes

ISO

62304

ISO13485

ISO14971 ISO 13485

ISO 14971




68/85

68


GeneralPrinciples of

Software

Validation

SoftwarePre-Market

Submission

Guidance

Off-The-ShelfSoftware

Guidance

FDA Software Specific References General Principles of Software Validation Software Pre-market Submission Guidance Off-The-Shelf Software Guidance

Industry ReferencesANSI/AAMI SW68

ISO 62304

ANSI/AAMI

SW68:2001

Software

Processes

ISO

62304




69/85

69


FDA Software-Specific Guidance Documents




70/85

70

p p

FDA Software-Specific Guidance Documents




71/85

71

p p

ANSI/AAMI SW68:2001

Medical Device Software - Software life cycle processes




72/85

72

p p

AAMI TIR32:2004

Medical device software risk management




73/85

73

FDA Website www.fda.gov

Click On

Medical Devices




74/85

74

FDA Website CDRH A-Z Index

Click On

CDRH A-Z Index




75/85

75

FDA Website

Click On

S For Software




76/85

76

FDA Website

Scroll Down To

Software




77/85

77

FDA Website




78/85

78

FDA Website

http://www.fda.gov/cdrh/humanfactors/




79/85

79

AAMI Website www.aami.org



Procedures

Plans

SW Life-Cycle Model


80/85

80

Quality System

Regulation

Medical Device

Quality

System Manual

Design Control

Guidance

Do It By

Design

Guide To

Inspections Of

Quality Systems

(QSIT)

Medical Device

Use Safety

Human Factors

Risk Mgmnt

General

Principles of

Software

Validation

Software

Pre-Market

Submission

Guidance

Off-The-Shelf

Software

Guidance

ANSI/AAMI

SW68:2001

Software

Processes



SW Change Control



SW Traceability


Design Transfer

Design History File

Training



SW Detailed Design


SW Coding

SW Code Verification

Unit Test

Integration Test

SW System Test

Beta Testing

SW Verification

SW Validation





Corrective & Preventive Action (CAPA)




81/85

81

Introduction

Regulated Software

FDA Overview




Basic Requirements




Corrective Action and Preventive Action (CAPA)

Reference Material

Conclusion





82/85

82


Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation

Beta SiteTesting

Customer

Low Defect Injection Rates

Early and Highly Effective Defect Detection Steps


Use Error Analysis

CAPA




83/85

83

Patients


Personnel

Environment

Its All About Making It Safe

Your Families! - Your Loved Ones! - Your Friends!

Each and Every One Of YOU!




84/85

84

Carl R. Wyrwa

[email protected]

MedicalDeviceSoftware.com

UC Irvine Extension Program

Medical Product Development

Medical Device Engineering

BME X401

Software-Controlled Medical Devices

Software Engineering & Compliance

http://unex.uci.edu/certificates/life_sciences/medical_products/details.asp




85/85

References

[1] FDA (2002). General Principles of Software Validation; Final Guidance for Industry

and FDA Staff. FDA website: http://www.fda.gov/cdrh/comp/guidance/938.pdf

[2] Pietrasanta, Alfred M. (1990). Defect Prevention. Software Quality Improvement

Module 9: Software Engineering Institute, Carnegie Mellon University.

Medical Product Software Development and FDA Regulations4008

Documents

Transcript of Medical Product Software Development and FDA Regulations4008