medical product software development and fda regulations

Medical Product Software Development and FDA Regulations

Software Development Practices and FDA Compliance

IEEE Orange County Computer SocietyMarch 27, 2006Carl R. Wyrwa

2

Medical Product Software Development and FDA RegulationsSoftware Development Practices and FDA Compliance


IntroductionRegulated SoftwareFDA OverviewMedical Device DefinitionSoftware – Special AttentionRegulation Of SoftwareBasic RequirementsSoftware Quality ModelSoftware Safety ModelSoftware MaintenanceCorrective Action and Preventive Action (CAPA)Reference MaterialConclusion

3


The Intent Of Regulating Software

Patients

Operators Bystanders ServicePersonnel

Environment

Medical Device Safety and Efficacy

4


PeopleDoingThe Work

ReviewersInternal Auditors

External Reviewers

Many Stakeholders – Keeping A Total Solution In Mind

SafetyPatients

OperatorsBystanders

Service PeopleEnvironment Customer

andBusiness

Needs

QualitySystems

andQ&RA

MedicalPractitioners

AllNeeds

Met

5


Many Stakeholders – Keeping A Balanced Solution In Mind

PeopleDoingThe Work

ReviewersInternal Auditors

External Reviewers

SafetyPatients

OperatorsBystanders

Service PeopleEnvironment

Customerand

BusinessNeeds

QualitySystems

andQ&RA

MedicalPractitioners

AllNeeds

Met

6




7


Types of Regulated Software

Medical Device SoftwareSoftware that is actually a part of the medical device itselfSoftware that is an accessory to a medical deviceSoftware that itself is a medical device

8


Types of Regulated Software

Medical Device SoftwareSoftware that is actually a part of the medical device itselfSoftware that is an accessory to a medical deviceSoftware that itself is a medical device

Non-Device Software that is part of:The production systemThe quality systemSystems that are used to create and maintain records required by FDA regulations

9




10


FDA Overview

FDA is a public health agency, charged with: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:the food we eat is safe and wholesome, the cosmetics we use won't hurt us, the medicines and medical devices we use are safe and effective, and that radiation-emitting products, such as microwave ovens, won't do us harm

One of our nation's oldest consumer protection agencies.Located in district and local offices in 157 cities across the country

11


Medical Devices32,358

12


FDA Overview

Administrative Enforcement PowersUnannounced and Announced InspectionsInspectional Observations - 483Warning LettersAdverse PublicityFDA-Initiated Recalls and Monitoring Company-Initiated RecallsDelay, Suspension, or Withdrawal of Product ApprovalsPreclusion of Government contractsDetention and Refusal of Entry into U.S. Commerce of Imported Products

Judicial Enforcement PowersCivil Enforcement Powers (Seizure)Criminal Enforcement Powers (Prosecution)

13




14


Medical Device Definition

Medical devices range from Simple Devices

Tongue depressors and bedpans

Complex DevicesProgrammable pacemakers

Laser surgical devices

Medical Device Classification – Class I, II, and IIIClass I devices include those with the lowest riskClass III devices includes those with the greatest risk.

15


Medical Device Definition

• "an instrument, apparatus, implement, machine, contrivance, implant, in vitro 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 or other animals, or intended to affect the structure or any function of the body 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 animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes."

16




17


820.30 Design Control

820.30(a) General(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:

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

(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 SuctionGlove, Surgeon’sRestraint, ProtectiveSystem, Applicator, Radionuclide, ManualSource, Radionuclide Teletherapy

18


Software – Special Attention

General Principles of Software Validation3.3 Software Is Different From Hardware

“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”.

“……. software engineering needs an even greater level of managerialscrutiny and control than does hardware engineering”.

[1]

19




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


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







21 CFR 801Labeling

















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







21 CFR 801Labeling

















M - Records

N - Servicing




820.100Corrective & Preventive Action

Quality SystemRequirements

23







21 CFR 801Labeling

















M - Records

N - Servicing




820.25(a)General

820.25(b)Training

Quality SystemRequirements

820.22Quality Audit

24


Software Basic Requirements













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 Verification

Unit Test

Integration Test

SW System Test

Beta Testing

SW Verification

SW Validation

COTS Software Components

Procedures

Plans

SW Life-Cycle Model

SW Requirements Analysis

SW Requirements Verification

SW Architectural Design

Corrective & Preventive Action (CAPA)

25




26


Procedures and PlansProcedures

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


Software Development


SW Detailed Design


SW Coding


SW Life-Cycle Model




28


TestingUnit Test

Integration Test

SW System Test

Beta Testing

29


Verification & ValidationSW Verification

SW Validation

“Engineering Correctness Checks”

“Intended Use Confirmation”

30


Supporting Processes



SW Change Control



SW Traceability



Corrective and Preventive Action (CAPA)

31


ReleaseDesign Transfer

Design History File

32


PersonnelTraining


33




34


The Reason

WHY we need to have a comprehensive and effective

Software Development Life Cycle

Software Quality and Software Safety

35


The Intent Of Regulating Software

Patients


Environment

Medical Device Safety and Efficacy

36


Understanding Defects

Start Development Process Ship

Defects

[2]

37




Defects

DefectsInjected

[2]

38




}DefectsShipped

Defects

Defects DetectedAnd Corrected

DefectsInjected

[2]

39


A Journey To Fewer DefectsOverall Software Quality


Defects

InjectFewer

[2]

40


Software Quality ModelUnderstanding Defect Injection Rates

SoftwareDetailedDesign

SoftwareCoding

SoftwareHigh-Level

Design

SoftwareRequirements

Defect injection rates can be reduced

byPerforming these activities highly effectively

and introducing Causal Analysis

41




SoftwareCoding

SoftwareHigh-Level

Design


Defect injection rates will increase

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

42




SoftwareCoding

SoftwareHigh-Level

Design


Defect Injection Rates are directly related to the completeness and the effectiveness of each

of these activities

43



0102030405060708090

100

Sys Reqs

SW Reqs

HL Design

Det Design

Coding

Unit Test

Int Test

SW Sys Test

Sys Valid

Beta Test

Customer

Defects per 1000 lines of code

DefectsInjected

Cum

ulat

ive

Def

ects

44




DetectEarlier

Detect MoreEffectively

Defects

InjectFewer

[2]

45


Software Quality ModelIncreasing Effectiveness

Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design


Verification Verification

IntegrationTest

SoftwareSystem

Test

SystemValidation

Beta SiteTesting Customer

46




} FewerDefects

DetectEarlier

Detect MoreEffectively

Defects

InjectFewer

Zero?

[2]

47




48


Software Safety ModelRisk/Hazard Analysis & Use Error Analysis

Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation


Risk/Hazard AnalysisUse Error Analysis

Harm To:PatientsOperatorsBystandersService PersonnelEnvironment

49



Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation



Induced By:Basic FunctionalitySoftware DefectsUse ErrorsEnvironmentInterfaces

50


Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation



51



Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation



52


Software Safety ModelA Continuous Process Throughout the Life Cycle

Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation



53



Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation



54



Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation



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 protect against Use Error

56


Software Safety ModelUse Error Analysis

Use Error (Human Factors) Considerations

Skill Level VariationEnvironmental VariationCompromising FactorsPhysical and Sensory CharacteristicsPerceptionCognitionExpectanciesMental ModelsHome Use

57



Interfaces

Environment

Use Errors

Defects

Basic Functionality

Potential HarmTo

Environment

Potential HarmTo

Service Personnel

Potential HarmTo

Bystanders

Potential HarmTo

Operators

Potential HarmTo

Patients

You are developing afunction where the

user will be asked tomanually enter a

patient’s age

YESYou realize that if the

age is entered incorrectlythat an incorrect diagnosis

might be made

58



PotentialHazard

PotentialEvent Severity Control

Mitigation

PostControlSeverity

V&VFunctionFeature

PatientAge

Entry

IncorrectDiagnosis

Incorrect AgeEntered

(Use Error)

MajorEnter

Date of Birth(cross check)

AcceptableTest

Procedure12345

59



60




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%) were caused by software defects that were introduced when changes were made to the software after its initial production and distribution”

Software Related Recalls

Due To Changes(79%)

Initial(21%)

FDA Guidance (2002) General Principles of Software Validation

62


Maintenance Challenges

MaintenanceChallenges

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


Creating A Balance

ChallengesOversimplification of the task

Customer and Patient expectationsIncreased requirements on system

ChangesDesign additions and/or modifications

State of the documentationKnowledge level

Personnel changesSoftware components (COTS)

Hardware componentsInterfaces

Cybersecurity issues

ProcessesRequirements management

Anomaly managementTechnology transition management

Risk managementTraining

Change controlSoftware development life cycle

Technical reviewsValidation planning

TestingConfiguration management

Documentation updates

64




65


Corrective Action – Preventive Action (CAPA)

Problem EncounteredInvestigate

Find Root CauseCorrect The Problem

Same ProductSimilar Problems?

InvestigateFind Root Cause

Correct The Problem

Other ProductsSimilar Problems?

InvestigateFind Root Cause

Correct The Problem

Process ChangePrevent Similar Problems From

Occurring InThe Future

66




67


Quality SystemRegulation

The Regulation• The Quality System Regulation 21 CFR 820

GeneralPrinciples of

Software Validation

SoftwarePre-MarketSubmissionGuidance

Off-The-ShelfSoftwareGuidance

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

Medical DeviceQuality

System Manual

Design ControlGuidance

Do It By Design

Guide ToInspections Of

Quality Systems(QSIT)

Medical DeviceUse Safety

Human FactorsRisk 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 References• ANSI/AAMI SW68• ISO 62304

ANSI/AAMISW68:2001

SoftwareProcesses

ISO62304

ISO13485

ISO14971 • ISO 13485

• ISO 14971

68



Software Validation



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

Industry References• ANSI/AAMI SW68• ISO 62304

ANSI/AAMISW68:2001

SoftwareProcesses

ISO62304

69


FDA Software-Specific Guidance Documents

70


FDA Software-Specific Guidance Documents

71


ANSI/AAMI SW68:2001 Medical Device Software - Software life cycle processes

72


AAMI TIR32:2004Medical device software risk management

73


FDA Website www.fda.gov

Click On“Medical Devices”

74


FDA Website CDRH A-Z Index

Click On“CDRH A-Z Index”

75


FDA Website

Click On“S” For Software

76


FDA Website

Scroll Down To “Software”

77


FDA Website

78


FDA Websitehttp://www.fda.gov/cdrh/humanfactors/

79


AAMI Website www.aami.org

80


Quality SystemRegulation

Medical DeviceQuality

System Manual

Design ControlGuidance

Do It By Design

Guide ToInspections Of

Quality Systems(QSIT)

Medical DeviceUse Safety

Human FactorsRisk Mgmnt


Software Validation



ANSI/AAMISW68:2001

SoftwareProcesses



SW Change Control



SW Traceability


Design Transfer

Design History File

Training



SW Detailed Design


SW Coding


Unit Test

Integration Test

SW System Test

Beta Testing

SW Verification

SW Validation


Procedures

Plans

SW Life-Cycle Model




Corrective & Preventive Action (CAPA)

81




82


Software Quality Model

Verification

UnitTest

Verification


SoftwareCoding

SoftwareHigh-Level

Design



IntegrationTest

SoftwareSystem

Test

SystemValidation


Low Defect Injection Rates

Early and Highly Effective Defect Detection Steps


CAPA

83


Patients


Environment

It’s All About Making It SafeYour Families! - Your Loved Ones! - Your Friends!

Each and Every One Of YOU!

84


Carl R. [email protected]

UC Irvine Extension ProgramMedical Product DevelopmentMedical Device Engineering

BME X401Software-Controlled Medical DevicesSoftware Engineering & Compliance

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

85


References

[1] – FDA (2002). General Principles of Software Validation; Final Guidance for Industryand 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 regulations

Documents

quality system software

fda compliance fda overviewfda

fda compliance medical

medical deviceand

fda compliancethe intent

softwaremedical device

public health agency

total solution