Medical Device Software Quality Assurance and Risk Assessment

Tie DuanAndrew DunaganMichael HarrisAntoine Wilcher

9/22/2010 1

Introduction

1984, approx. 80% of all major medical system contains computerized components (1987, Anbar)

1983 to 1985, a total of 41 medical product recalls were concerned with software

1792, mathematician Pierre-Simon de Laplace estimated the probability of death with and without small vaccination

20th century, risk analysis developed in response to the safety of nuclear power plans and the establishment of government agencies such as EPA & OSHA

9/22/2010 2

Medical Device Software Failures Heart pacemaker incidents due to software

issues – 2 deaths Therac 25 (1985 – 1987) radiation overdoes – 2

deaths, 1 serious injury Baxter infusion pump recall – FDA mandated

recall due to software and usage failures causing the pumps to stop infusing fluids

London Ambulance Services (1992) – newly installed, and poorly designed, Computer Aided Dispatch (CAD) system caused massive delays in assigning of ambulances, with anecdotal reports of 11 hour waits

9/22/2010 3

Classifications of Medical Software Stand-Alone Software

Can be treated as medical device by itself Subject to all applicable FDA regulations Examples: Hospital information systems,

Osteoporosis diagnosis software Accessory Software

A component, part, or accessory to a device Regulated according to the parent device

requirements Examples: Pacemaker telemetry data conversion

software, pacemaker response rate computation software

9/22/2010 4

Framework for Defining Software Quality Assurance Programs

1. Collect requirements2. Establish a plan3. Develop mission statement4. Develop a policy and standard5. Highlight all relevant activities6. Develop appropriate operating

procedures7. Train and promote the program8. Review the program

9/22/2010 5

Software Design

45% of software system errors tend to be design errors (1987, Dhillon)

Top-level design Detailed design

Flowcharts, Warnier-Orr diagrams, Chapin charts are frequently used for design representations

9/22/2010 6

Software Design Methods

Modular DesignDecomposing complex software development into

various modules Advantages

Easy to write, debug and test Cheaper to change More reliable

Disadvantages Requires more effort May requires more memory space

9/22/2010 7

Software Design Methods (Cont.) Structured Programming

Avoids the use of GoTo statements, modular and top-down program design

Advantages Increasing programmer productivity Maximizing reusable codes during redesign Localizing error Understandable for designers and others

Disadvantages Requires more effort May require more memory space

9/22/2010 8

Software Design Methods (Cont.)

Top-Down ProgrammingDirects attention to the program flow of control Advantages

Lower testing cost Better quality More readable

Disadvantages Requires more effort

9/22/2010 9

Software Coding

Translate design specifications into source code

Use guidelines for good coding: Review each line of code Make code publicly accessible Require coding sign-offs Reward good coding practices

9/22/2010 10

Software Testing

Manual Software Testing White-box testing Error testing Free-form testing Safety testing

Automated Software Testing More accurate and complete Better test documentations

9/22/2010 11

Software Metrics

Used to measure software complexity McCabe’s Complexity

CN: complexity number, the higher the more difficult

µ: number of edges in the programθ: total number of nodes or verticesy: total number of separate tasks or connected components

9/22/2010 12

Software Metrics (Cont.)

Halstead MeasuresConsiders1. Number of distinct operators2. Number of distinct operands

Software Vocabulary

SV: vocabulary of the softwareα: total number of distinct operandsλ: total number of distinct operators

9/22/2010 13

Software Metrics (Cont.)

Program Length

PL: program length

m: total occurrences of operandsn: total occurrences of operators

Software Volume

VS: volume of the software

9/22/2010 14

Software Metric (Cont.)

Potential Volume

VS*: potential volume

9/22/2010 15

Risk Management and Program Steps

The systematic application of management policy, procedures, and practices to identify, analyze, control and monitor risk

1. Establish requirement & mechanisms to achieve it

2. Outline responsibilities3. Identify authorization4. Define skills and knowledge needed5. Develop documentation6. Develop cross-checking measures7. Conduct verifications

9/22/2010 16

Factors in Risk Managment

Design & Manufacturing Material Toxicity and Degradation Human Factors Interaction with Other Devices

9/22/2010 17

Integrating Risk Assessment into Medical Device Design Control

Project planning Design input Design output Design transfer Design verification Design validation

9/22/2010 18

Medical Device Risk Assessment-Related Data

Average Loss of Life Expectancy Due to Medical-Related Causes and All

Catastrophes CombinedCause Average Life Expectancy

Loss in Days

Legal drug misuse 90

Illicit drugs 18

Medical x-rays 6

Electrocution 5

All catastrophes combined 35

9/22/2010 19

Continuous Quality Improvement Using Intelligent Infusion Pump Data Analysis

Smart Pump Server-Based Safety Software

Drug Library Updating Safety Dosing Limits for Specific Drugs Real-Time Infusion Monitoring Alerts Reporting to Select Personnel for Analysis

Adverse Drug Event (ADE) Reduction!

9/22/2010 20

Failure Modes In Medical Device Software: An Analysis of 15 Years of Recall Data

Recall Failures: An alarm failed to sound Dosages were incorrect with displayed values Display metrics incorrect Total system failure Device performance issues due to certain conditions Lost data Calculation or other function missing, manual

Greater Prevention and Detection During Testing Allows for More Robust Software Development

9/22/2010 21

Building Quality into Medical Device Software

Challenge: Increasing Software Complexity Achieving and Maintaining Quality

Early Adoption of Rigorous Software Quality Assurance Minimize Software Problems and Avoid Errors Planning, Specifications, Coding, Testing, Measurements,

Change Control, Documentation

Software Validation Labor Intensive and Costly $$$ Essential for Safe and Reliable Medical Device Software.

9/22/2010 22

Questions?

9/22/2010 23

References

Bergeson, D. (n.d.). Building Quality into Medical Device Software | MDDI Magazine. MDDI Magazine. Retrieved September 21, 2010, from http://www.mddionline.com/article/building-quality-medical-device-software

Breland, B. D. (n.d.). Continuous quality improvement using intelligent infusion pump data analysis -- Breland 67 (17): 1446 -- American Journal of Health-System Pharmacy. American Journal of Health-System Pharmacy. Retrieved September 21, 2010, from http://www.ajhp.org/cgi/content/abstract/67/17/1446

Dhillon, B. (2008). Reliability Technology, Human Error, and Quality in Health Care (1 ed.). Boca Raton: CRC.

Dhillon, B. (1987). Reliability in Computer System Design. Norwood, NJ: Ablex Publishing.

Anbar, M. (1987). Computers in Medicine. Rockville, MD: Computer Science. Wallace, D. R., & Kuhn, D. R. (n.d.). FAILURE MODES IN MEDICAL DEVICE

SOFTWARE:. FAILURE MODES IN MEDICAL DEVICE SOFTWARE:. Retrieved September 21, 2010, from csrc.nist.gov/staff/Kuhn/final-rqse.pdf

9/22/2010 24