Transcript Sept30 Ch 5 Medical Device Software Quality Assurance Graduate

Medical Device Software
Quality Assurance and Risk
Assessment
Tie Duan
Andrew Dunagan
Michael Harris
Antoine 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.
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)
 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 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
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 Programming
Directs 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:




9/22/2010
Review each line of code
Make code publicly accessible
Require coding sign-offs
Reward good coding practices
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 vertices
y: total number of separate tasks or connected
components
9/22/2010
12
Software Metrics (Cont.)
 Halstead Measures
Considers
1. Number of distinct operators
2. 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 operands
n: 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
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




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 AssessmentRelated 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
 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