medical device software quality assurance and risk assessment tie duan andrew dunagan michael harris...
TRANSCRIPT
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