Your SlideShare is downloading. ×

Medical device reliability program

2,727

Published on

The FDA has their Design Controls in the Code of Federal Regulations Title 21 Part 820.30, then for outside the US, we have ISO 13485:2003 Medical devices – Quality management systems – Requirements …

The FDA has their Design Controls in the Code of Federal Regulations Title 21 Part 820.30, then for outside the US, we have ISO 13485:2003 Medical devices – Quality management systems – Requirements for regulatory purposes, and finally there is ISO 14971 Medical devices — Application of risk management to medical devices.
How can the New Product Development (NPD) process make conforming to these standards into an advantage and accomplish the appropriate Reliability activities in their proper place and sequence to avoid those expensive “loopbacks” (which are really NPD rework)? Can a NPD project steer clear of situations requiring compromise in Reliability to avoid repeating clinical trials or to preserve the project schedule?
Can a company avoid recalls for Reliability issues by knowing what the Reliability will be before product release?
An optimal New Product Development process will be presented that successfully deals with these challenges.

Published in: Technology, Business
1 Comment
2 Likes
Statistics
Notes
  • Great article. I am new to medical device reliability and this article really open my knowledge. Thanks
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,727
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
190
Comments
1
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Improved Efficiency & Reliability for Servers using Immersion Cooling Chet Haibel ©2011 ASQ & Presentation Haibel Presented live on Apr 12th, 2011 http://reliabilitycalendar.org/webina rs/english/
  • 2. ASQ Reliability Division English Webinar Series One 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/webina rs/english/
  • 3. Medical Device Reliability Program Originally Presented April 12, 2011 Revised September 14, 2013 Chet Haibel
  • 4. 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
  • 5. Chet Haibel ©2013 Haibel Consulting LLC Some Controlling Documents FDA’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
  • 6. 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 Units Design Validation Production Units Design and Development Planning Design History File
  • 7. 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” of New Product Development to keep happy
  • 8. Chet Haibel ©2013 Haibel Consulting LLC Seven Sources of Critical Information 8 Specification Development System Requirements User Human Factors External Standards Service Internal Standards Safety Functional Requirements Usability Requirements Risk Control Requirements Consistency Requirements Maintainability Requirements System Requirements Specification Marketing Competitive Requirements Regulatory Requirements Requirements need to be developed into specifications Complete specifications are verifiable, including fraction conforming at statistical confidence
  • 9. Chet Haibel ©2013 Haibel Consulting LLC Setting Specifications Stress, Time, or Cycles Customer Application Low Specification (perhaps 1σ) Product Performance Stress, Time, or Cycles Test must show that large 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σ)
  • 10. 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 Customer Application Product Performance
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. Chet Haibel ©2013 Haibel Consulting LLC ISO 14971 Requires (continued 2) 14 Risk Evaluation per criteria in Risk Management Plan Probability of Harm Annual Probability per Device Negligible Marginal Critical Catastrophic Frequent Probable Occasional Remote Improbable Incredible Acceptable Acceptable Acceptable Tolerable 1 in 1,000,000 Acceptable Acceptable Acceptable Acceptable Severity of Harm Intolerable Intolerable Intolerable Intolerable 1 in 100 Tolerable Intolerable Intolerable Intolerable 1 in 1,000 Acceptable Tolerable Intolerable Intolerable 1 in 10,000 Acceptable Acceptable Tolerable Intolerable 1 in 100,000
  • 15. 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
  • 16. 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.
  • 17. 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 Wrong Infusion 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. 18 Wrong Infusion Rate Operator Error RAM Failure Motor Failure Dose Rate Calculator requires another offsetting input error Another independent failure in complementary (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
  • 19. 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)
  • 20. 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
  • 21. 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
  • 22. Chet Haibel ©2013 Haibel Consulting LLC Feasibility Design V and V Production Hazard Identification and Fault Tree Synthesis Application FMEA Design FMEA Review and Updates to Risk 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 architecture FMEAs guide design of product and manufacturing process Risk Control Measures are developed into specifications Design Verification achieves required verification of RCMs
  • 23. 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
  • 24. 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 Units Design Validation Production Units Where best should Reliability testing fit in?
  • 25. 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 conditions are 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
  • 26. Long-term Process Dynamics Guideline: over time, a process tends to shift by 1.5 LSL USL Shift Happens Short-Term Capability Cpk Long-Term Performance Ppk 26Chet Haibel ©2013 Haibel Consulting LLC
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. 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
  • 31. Discovery versus Verification Do this first, fast, and often Fly 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
  • 32. Chet Haibel ©2013 Haibel Consulting LLC 32 Operating Time (t) HazardRate-h(t) Useful-Life Failures Early-Life Failures Wear- Out Failures Life to the Beginning of Wear-Out Random-in-Time Failures Find by Cycle Testing Solution in Product Design or Preventive Maintenance Find by HALT Solution in Designing Product with Margin Find by HASS Solution in Mfg. Processes or Shipping, Handling, Storage Summary of Failure Types, How Found, and How Solved
  • 33. 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
  • 34. 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
  • 35. What Are Your Questions? Chet@HaibelConsulting.com

×