Medical device reliability program
-
Upload
asq-reliability-division -
Category
Technology
-
view
2.962 -
download
3
description
Transcript of Medical device reliability program
Improved Efficiency & Reliability for
Servers using Immersion Cooling
Chet Haibel©2011 ASQ & Presentation Haibel
Presented live on Apr 12th, 2011
http://reliabilitycalendar.org/webinars/english/
ASQ Reliability Division English Webinar SeriesOne of the monthly webinars
on topics of interest to reliability engineers.
To view recorded webinar (available to ASQ Reliability Division members only) visit asq.org/reliability
To sign up for the free, and available to anyone,live webinars visit reliabilitycalendar.org/webinars
http://reliabilitycalendar.org/webinars/english/
Medical DeviceReliability Program
Originally Presented April 12, 2011
Revised September 14, 2013
Chet Haibel
Chet Haibel ©2013 Haibel Consulting LLC 4
Agenda
• Some of the many process-controlling documents
• Simplest process per the QSRs, MDD, ISO 13485
• Gathering all the Requirements and Specifications
• Making Risk Management (ISO 14971) painless
• Using Risk Management to highlight issues
• The shortest path is to add a step to the process
• Overstress testing substitutes for quantity and time
• Good Reliability Procedures
Chet Haibel ©2013 Haibel Consulting LLC
Some Controlling DocumentsFDA’s QSRs: Title 21 CFR Part 820, esp. 820.30
European Union’s MDD 93/42/EEC
ISO 13485:2008 Medical Devices – Quality Management Systems – Requirements for Regulatory Purposes
ISO 14971:2007 Medical Devices – Application of Risk Management to Medical Devices
IEC 62304:2006 Medical Device Software – Software Life Cycle processes
IEC 62366:2007 Medical Devices – Application of Usability Engineering to Medical Devices
These don’t tell you how to make your product reliable!
5
Chet Haibel ©2013 Haibel Consulting LLC
Simplest Medical Device Program
6
Validate: Designed the right product
Verify: Designed the product right
Product Development /
Innovation
Design Verification
Design Inputs
Design Outputs
User Needs
Prototypes
Design Transfer
Production
Initial UnitsDesign
Validation
Production Units
Design and Development Planning
Design History File
Chet Haibel ©2013 Haibel Consulting LLC
Focus on Gathering Design Inputs
7
Last minute changes really hurt reliability, cost, and schedule, so do an exceptional job of gathering all the inputs at the very start of the development project
There are actually a lot of “customers” ofNew Product Development to keep happy
Chet Haibel ©2013 Haibel Consulting LLC
Seven Sources of Critical Information
8
Specification Development
SystemRequirements
User
Human Factors
ExternalStandards
ServiceInternalStandards
Safety
FunctionalRequirements
UsabilityRequirements
Risk ControlRequirements
ConsistencyRequirements
MaintainabilityRequirements
SystemRequirementsSpecification
Marketing
CompetitiveRequirements
RegulatoryRequirements
Requirements needto be developed into specifications
Complete specificationsare verifiable, including fraction conforming at statistical confidence
Chet Haibel ©2013 Haibel Consulting LLC
Setting Specifications
Stress, Time, or Cycles
CustomerApplication
Low Specification(perhaps 1σ)
ProductPerformance
Stress, Time, or Cycles
Test must show thatlarge fraction of product meets
specification
To demonstrate that a large fraction of the product meets specification requires large sample size, long test time, or large number of cycles
Low Specification(perhaps 1σ)
Chet Haibel ©2013 Haibel Consulting LLC
Setting Specifications
High Specification(perhaps 3σ)
Test must only show that product
typically meets specification
High Specification(perhaps 3σ)
Stress, Time, or CyclesStress, Time, or Cycles
To demonstrate that a specification is typically met requires small sample size (three?), short test time,or small number of cycles
CustomerApplication
ProductPerformance
Chet Haibel ©2013 Haibel Consulting LLC
Setting Specifications
Tough Specifications mean Faster, Cheaper, Better Testing!
Better because testing to tougher specifications produces failures,
and failures are good!Failures show how much Design Margin exists
Failures produce numbers (Variable data) which are much better than pass / fail (Attribute data)
Failures can be analyzed,which leads to root cause understanding,which gives opportunities for improvement
Chet Haibel ©2013 Haibel Consulting LLC
ISO 14971 (Risk Management) Requires
Risk Management Plan, which has six requirements:the scope of the planned risk management activities,
identifying and describing the medical device and the life-cycle phases for which each element of the plan is applicable;
assignment of responsibilities and authorities;
requirements for review of risk management activities;
criteria for risk acceptability, based on the manufacturer’s policy for determining acceptable risk, including criteria for accepting risks when the probability of occurrence of harm cannot be estimated;
verification activities; and
activities related to collection and review of relevant production and post-production information.
12
Chet Haibel ©2013 Haibel Consulting LLC
ISO 14971 Requires (continued 1)
Risk Analysis (typically FTA or FMEA)
Identification of the device and accessories
Identification of the persons / organization who did the analysis
Date of analysis
Intended use / intended purpose of the medical device
Identification of reasonably foreseeable misuse
Identification of qualitative and quantitative characteristics that could affect safety
Identification of known or foreseeable hazards
Estimation of the risks for each hazard(combination of Probability and Severity of each Harm)
13
Chet Haibel ©2013 Haibel Consulting LLC
ISO 14971 Requires (continued 2)
14
Risk Evaluation per criteria in Risk Management Plan
Probability of HarmAnnual Probability per Device Negligible Marginal Critical Catastrophic
Frequent
Probable
Occasional
Remote
Improbable
Incredible
Acceptable Acceptable Acceptable Tolerable1 in 1,000,000
Acceptable Acceptable Acceptable Acceptable
Severity of Harm
Intolerable Intolerable Intolerable Intolerable1 in 100
Tolerable Intolerable Intolerable Intolerable1 in 1,000
Acceptable Tolerable Intolerable Intolerable1 in 10,000
Acceptable Acceptable Tolerable Intolerable1 in 100,000
Chet Haibel ©2013 Haibel Consulting LLC
ISO 14971 Requires (continued 3)
15
Risk Control
Risk reduction using “option analysis,” an integrated approach of prioritizing risk control measures among three broad categories: inherent safety by design, protective measures, and information for safety
Verification of implementation of risk control measures
Verification of effectiveness of risk control measures
Identification whether new hazards have been introduced by risk control measures
Assurance that all identified hazards have been evaluated
Evaluation of overall residual risk acceptability
Chet Haibel ©2013 Haibel Consulting LLC
ISO 14971 Requires (continued 4)
16
Risk Management Report, summarizes a review of the risk management process:
Reviewed by persons with appropriate authority;
Ensures the Risk Management Plan has been appropriately implemented;
Ensures that the overall residual risk is acceptable;
Ensures that appropriate methods are in place to obtain relevant production and post-production information.
Risk Management File, containing all risk management documents; which is reviewed whenever conditions change and is kept current as new information becomes available.
Chet Haibel ©2013 Haibel Consulting LLC
Painless Risk Management
As soon as the product concept exists, identify the hazards, their worst outcomes, and do Fault Tree Analysis (FTA) with each of these outcomes as Top Event of a Fault Tree
17
WrongInfusion
Rate
Motor Failure
Example: IV Pump
How can we “architect” the product so these single failures do not lead to this Top Event?
RAM Failure
Operator Error
18
WrongInfusion
Rate
Operator Error
RAM Failure
Motor Failure
Dose Rate Calculator requiresanother offsetting input error
Another independent failure incomplementary (shadow) RAM
Precise interfering quadrature signals like the shaft encoder’s
Painless Risk Management (continued 1)
Fault Tree Synthesis
During Product Architecture
Chet Haibel ©2013 Haibel Consulting LLC
Chet Haibel ©2013 Haibel Consulting LLC
Identify all hazards at the initial concept phase and “architect” the product to eliminate all single failures that lead to high Severity Harm (I call this Fault Tree Synthesis)
19
Single Failures No Single Failure Results
in the Wrong Infusion Rate!
Initial Fault Tree
Painless Risk Management (continued 2)
Chet Haibel ©2013 Haibel Consulting LLC
Painless Risk Management (continued 3)
As soon as the steps in using the product can be listed, generate an Application FMEA that deals with user misunderstandings, omissions, commissions, and any user interface issues including potential misuse and abuse
The aFMEA assumes the product will be designed and manufactured correctly and deals with the whole system
As soon as key components & parts have been conceived, generate a Design FMEA which considers what happens if the part fails to do all its functions correctly
The dFMEA assumes the product will be manufactured correctly but considers misuse and abuse from aFMEA
20
Chet Haibel ©2013 Haibel Consulting LLC
Painless Risk Management (continued 4)
21
As soon as the earliest sketch of the production flow can be made, generate the Process FMEA which examines the effects of errors, commissions, and omissions at each step in the manufacturing process
The pFMEA assumes the product will be designed cor-rectly but considers misuse and abuse from the aFMEA
As soon as the field replaceable units (FRUs) can be identi-fied, list the steps in diagnosing, removing and replacing FRU, and verifying the repair; generate the Service FMEA considering errors, commissions, and omissions in repair
The srFMEA assumes the product will be designed and manufactured correctly but considers misuse and abuse from the aFMEA
Chet Haibel ©2013 Haibel Consulting LLC
Feasibility Design V and V Production
Hazard Identification andFault Tree Synthesis
Application FMEA
Design FMEA
Review and Updates toRisk Management File
Complaints
Risk Management Plan
Verify RCMs are Implemented and
Effective
Process FMEA
Post-Production
Risk Management Report
ServiceYields
Regulatory Submittals
Product Architecture
Painless Risk Management (continued 5)
22
Risk Control Measures
Fault Tree Synthesis guides product architectureFMEAs guide design of product and manufacturing processRisk Control Measures are developed into specificationsDesign Verification achieves required verification of RCMs
Chet Haibel ©2013 Haibel Consulting LLC
Why This Emphasis on Risk Management?
The harm outcomes with high severity indicate where verification must be done with larger reliability (fraction conforming) at good statistical confidence Example:
Also, harm outcomes which require low probability of occurrence are where reliability effort must be focused
Think it through carefully, record it in the Risk Management documents, then let them guide product / process design and reliability effort
23
Severity of Potential Harm Negligible Marginal Critical Catastrophic
Reliability (Fraction Conforming) 0.80 0.90 0.95 0.99
Chet Haibel ©2013 Haibel Consulting LLC
Simplest Medical Device Program
24
Validate: Designed the right product
Verify: Designed the product right
Product Development /
Innovation
Design Verification
Design Inputs
Design Outputs
User Needs
Prototypes
Design Transfer
Production
Initial UnitsDesign
Validation
Production Units
Where best should Reliability testing fit in?
Where best to integrate Reliability?
The regulations lead one to think the shortest path is to submit
prototypes directly to Verification Testing to qualify the design
Trying to find reliability issues during Verification is ineffective
because:
Large sample sizes are too expensive unless tooling is done
Changes after tooling are expensive and schedule-destructive
Customer conditionsare too mild
Sample Size is too small
Can’t see issues that will be caused by long-term manufacturing variation
25Chet Haibel ©2013 Haibel Consulting LLC
Long-term Process Dynamics
Guideline: over time, a process tends to shift by 1.5
LSL USL
Shift Happens
Short-TermCapabilityCpk
Long-TermPerformancePpk
26Chet Haibel ©2013 Haibel Consulting LLC
Marginal Component’s Strength and Load
Torque, Voltage, Current, etc.
One can build quite a few prototypes before encountering the tails of the strength distribution
Customer Conditions
But when many units are built and used by many different customers, a number of components will fail under normal customer conditions
Long-term Performance
Most of the components have been applied with excellent design margin and can take much more than worst case customer conditions
Design Margin
Long-term PerformanceCustomer
Conditions
27Chet Haibel ©2013 Haibel Consulting LLC
Trying to find reliability issues
during Verification is ineffective
WRONG !! RIGHT !! Insert Rapid Discovery Step
28
Where best to integrate Reliability?
Chet Haibel ©2013 Haibel Consulting LLC
0
0.2
0.4
0.6
0.8
1
1.2
0
0.2
0.4
0.6
0.8
1
1.2
Drive this overlap area up
Increase the load until the first few components fail
These are components with marginal applications:design weaknesses
This will necessitate going beyond customer conditions
29
Rapid Issue Discovery
Wide-Ranging and Increasing Load
Chet Haibel ©2013 Haibel Consulting LLC
Chet Haibel ©2013 Haibel Consulting LLC
Rapid Issue Discovery
We are substituting overstress testing for sample size and time
Big Issue: Are failures found relevant or foolish?
WRONG METHOD !! Judging by the stress level which caused the failure to occur
RIGHT METHOD !!Perform Failure Analysis to
gain Root Cause Understanding, then decide
whether customers will see the failure mode
30
Discovery versus Verification
Do this first, fast, and oftenFly Through Verification
Result: Shorter Schedule and Product that Doesn’t Fail
31
Signed-Off Protocol with
Criteria for Succes
Test to Requirements
Represen-tative
Samples
Goal is to Pass
Statistically Significant Quantity
Formal Report Demonstrating
Criteria for Success Are Met
Test Beyond Requirements
Earliest Prototypes
Force Failures
Minimum Quantity
Short Report: What was Done, Failures to be Analyzed
Chet Haibel ©2013 Haibel Consulting LLC
Chet Haibel ©2013 Haibel Consulting LLC 32
Operating Time (t)
Haz
ard
Rat
e -
h(t)
Useful-LifeFailures
Early-LifeFailures
Wear-Out Failures
Life to the Beginning of Wear-Out
Random-in-Time Failures
Find by Cycle Testing
Solution in Product Designor Preventive Maintenance
Find by HALT
Solution in DesigningProduct with Margin
Find by HASS
Solution in Mfg. Processes orShipping, Handling, Storage
Summary of Failure Types, How Found, and How Solved
Chet Haibel ©2013 Haibel Consulting LLC 33
Accelerated (Wear-Out) Test
If possible, set up a repetitive “cycle test” which removes the “dead time” between cycles. But brainstorm what artifact the test may be adding and / or what the test may be concealing
Test until a minimum of five failures are produced [Haibel’s rule]
Use Weibull Analysis to fit a distribution to the failure data
If life is not sufficient, determine the reservoir of material and the process consuming the reservoir. Increase the reservoir of material and / or slow down the process consuming it
If necessary, replace the reservoir of material periodically with a scheduled preventive maintenance program
Chet Haibel ©2013 Haibel Consulting LLC 34
Deductive Accelerated (Wear-Out) Test
• Run three unequally sized groups of components (1, 2, 4 quantity ratio) at three levels of stress acceleration– Smallest quantity run at 10% below the “foolish” level– Middle quantity 20% below the “foolish” level
• Analyze failures: using Physics of Failure and Weibull Analysis, estimate the life vs. stress relationship and whether the component is on track to qualifying
• Based on Project Time resources, establish the lowest stress level for the largest quantity group– As close to customer conditions as time permits– Conservative enough to finish within allotted time
• Project life at customer conditions from all three groups