Medical Device Software Quality Assurance and Risk Assessment

Medical Device Software Quality Assurance and Risk Assessment Tie Duan Andrew Dunagan Michael Harris Antoine Wilcher 9/22/2010 1

Introduction o 1984, approx. 80% of all major medical system contains computerized components (1987, Anbar) o 1983 to 1985, a total of 41 medical product recalls were concerned with software o 1792, mathematician Pierre-Simon de Laplace estimated the probability of death with and without small vaccination o 20 th 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 o Heart pacemaker incidents due to software issues – 2 deaths o Therac 25 (1985 – 1987) radiation overdoes – 2 deaths, 1 serious injury o Baxter infusion pump recall – FDA mandated recall due to software and usage failures causing the pumps to stop infusing fluids o 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 o Stand-Alone Software n Can be treated as medical device by itself n Subject to all applicable FDA regulations n Examples: Hospital information systems, Osteoporosis diagnosis software o Accessory Software n A component, part, or accessory to a device n Regulated according to the parent device requirements n Examples: Pacemaker telemetry data conversion software, pacemaker response rate computation software 9/22/2010 4

Framework for Defining Software Quality Assurance Programs 1. 2. 3. 4. 5. 6. Collect requirements Establish a plan Develop mission statement Develop a policy and standard Highlight all relevant activities Develop appropriate operating procedures 7. Train and promote the program 8. Review the program 9/22/2010 5

Software Design 45% of software system errors tend to be design errors (1987, Dhillon) o Top-level design o Detailed design Flowcharts, Warnier-Orr diagrams, Chapin charts are frequently used for design representations 9/22/2010 6

Software Design Methods o Modular Design Decomposing complex software development into various modules n Advantages o Easy to write, debug and test o Cheaper to change o More reliable n Disadvantages o Requires more effort o May requires more memory space 9/22/2010 7

Software Design Methods (Cont. ) o Structured Programming Avoids the use of Go. To statements, modular and top-down program design n Advantages o Increasing programmer productivity o Maximizing reusable codes during redesign o Localizing error o Understandable for designers and others n Disadvantages o Requires more effort o May require more memory space 9/22/2010 8

Software Design Methods (Cont. ) o Top-Down Programming Directs attention to the program flow of control n Advantages o Lower testing cost o Better quality o More readable n Disadvantages o Requires more effort 9/22/2010 9

Software Coding o Translate design specifications into source code o Use guidelines for good coding: n n 9/22/2010 Review each line of code Make code publicly accessible Require coding sign-offs Reward good coding practices 10

Software Testing o Manual Software Testing n n White-box testing Error testing Free-form testing Safety testing o Automated Software Testing n More accurate and complete n Better test documentations 9/22/2010 11

Software Metrics Used to measure software complexity o Mc. Cabe’s Complexity CN: complexity number, the higher the more difficult µ: number of edges in the program θ: total number of nodes or vertices y: total number of separate tasks or connected components 9/22/2010 12

Software Metrics (Cont. ) o Halstead Measures Considers 1. Number of distinct operators 2. Number of distinct operands n Software Vocabulary SV: vocabulary of the software α: total number of distinct operands λ: total number of distinct operators 9/22/2010 13

Software Metrics (Cont. ) n Program Length PL: program length m: total occurrences of operands n: total occurrences of operators n Software Volume VS: volume of the software 9/22/2010 14

Software Metric (Cont. ) n Potential Volume VS*: potential volume 9/22/2010 15

Risk Management and Program Steps 1. 2. 3. 4. 5. 6. 7. The systematic application of management policy, procedures, and practices to identify, analyze, control and monitor risk Establish requirement & mechanisms to achieve it Outline responsibilities Identify authorization Define skills and knowledge needed Develop documentation Develop cross-checking measures Conduct verifications 9/22/2010 16

Factors in Risk Managment o o Design & Manufacturing Material Toxicity and Degradation Human Factors Interaction with Other Devices 9/22/2010 17

Integrating Risk Assessment into Medical Device Design Control o o o 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 Combined Cause Average Life Expectancy Loss in Days Legal drug misuse 90 Illicit drugs 18 Medical x-rays 6 Electrocution 5 All catastrophes combined 9/22/2010 35 19

Continuous Quality Improvement Using Intelligent Infusion Pump Data Analysis o Smart Pump n Server-Based Safety Software o o o Drug Library Updating Safety Dosing Limits for Specific Drugs Real-Time Infusion Monitoring Alerts Reporting to Select Personnel for Analysis n Adverse Drug Event (ADE) Reduction! 9/22/2010 20

Failure Modes In Medical Device Software: An Analysis of 15 Years of Recall Data o Recall Failures: n n n n 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 o Greater Prevention and Detection During Testing Allows for More Robust Software Development 9/22/2010 21

Building Quality into Medical Device Software o Challenge: Increasing Software Complexity o Achieving and Maintaining Quality n Early Adoption of Rigorous Software Quality Assurance n Minimize Software Problems and Avoid Errors n Planning, Specifications, Coding, Testing, Measurements, Change Control, Documentation o Software Validation n Labor Intensive and Costly $$$ n Essential for Safe and Reliable Medical Device Software. 9/22/2010 22

Questions? 9/22/2010 23

References o o o Bergeson, D. (n. d. ). Building Quality into Medical Device Software | 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. 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: . Retrieved September 21, 2010, from csrc. nist. gov/staff/Kuhn/final-rqse. pdf 9/22/2010 24