240 likes | 389 Views
Medical Device Software Quality Assurance and Risk Assessment. Tie Duan Andrew Dunagan Michael Harris Antoine Wilcher. Introduction. 1984, approx. 80% of all major medical system contains computerized components (1987, Anbar)
E N D
Medical Device Software Quality Assurance and Risk Assessment Tie Duan Andrew Dunagan Michael Harris Antoine Wilcher
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
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
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
Framework for Defining Software Quality Assurance Programs Collect requirements Establish a plan Develop mission statement Develop a policy and standard Highlight all relevant activities Develop appropriate operating procedures Train and promote the program Review the program
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
Software Design Methods • Modular Design Decomposing 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
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
Software Design Methods (Cont.) • Top-Down Programming Directs attention to the program flow of control • Advantages • Lower testing cost • Better quality • More readable • Disadvantages • Requires more effort
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
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
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 vertices y: total number of separate tasks or connected components
Software Metrics (Cont.) • Halstead Measures Considers • Number of distinct operators • Number of distinct operands • Software Vocabulary SV: vocabulary of the software α: total number of distinct operands λ: total number of distinct operators
Software Metrics (Cont.) • Program Length PL: program length m: total occurrences of operands n: total occurrences of operators • Software Volume VS: volume of the software
Software Metric (Cont.) • Potential Volume VS*: potential volume
Risk Management and Program Steps 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
Factors in Risk Managment Design & Manufacturing Material Toxicity and Degradation Human Factors Interaction with Other Devices
Integrating Risk Assessment into Medical Device Design Control Project planning Design input Design output Design transfer Design verification Design validation
Medical Device Risk Assessment-Related Data Average Loss of Life Expectancy Due to Medical-Related Causes and All Catastrophes Combined
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!
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
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.
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