Just how resilient is your Medical Device?

Tweet

 

I attended COFES 2014 this past week.   It was an excellent event bringing together some of the world’s best engineering minds.

One of the many excellent round-table sessions discussed the notion of improving product resilience.   At the session there was a diverse group including: architects, engineers and scientists with astonishing backgrounds including NASA engineers, cool surf board inventors, weapon specialists, medical device engineers and many more.

We as humans can last 100+ years and can withstand a wide variety of damaging external forces (sun, wind, bodily damage, drug abuse, to name just a few).  That’s far better than most commercially available products.  We also can heal ourselves but with assistance (hospitals for example).  Can we get as good as nature at making products resilient?

Being a practical sort of person, I asked the group if during the discussion we could identify some of the things that are important in a product lifecycle to address the question of resilience.    Many of these are already steps Integware suggests when advising clients.  From what I had learned I attempted to go a little further and isolate how these steps apply specifically to resilience and as opposed to robustness.  I sought to integrate the ideas into my own experience in helping medical device manufacturers improve product quality.

Here are a few ideas:  

1. Document the Importance of Resilience: We must understand and document the product’s resiliency requirements. In medical device we think so often about quality, but not all medical device products need to be tremendously resilient to be perceived as high quality or having a high safety or efficacy profile.  A syringe probably doesn’t need to be very resilient.  It gets used once and is tossed aside.   However, if the power fails on a heart bypass machine, one would hope that there is backup power available and the functionality continues uninterrupted.   
2. Voice of Customer: For medical device manufacturers, resilience might not only be a safety question, we need to consider the perception of the buyer and user and what will be important to them.   Talking to clients about what is it really like to use something and what’s going on around them when they do so as opposed to assuming a perfect working environment.    Going one step further, can we even leverage the power of crowdsourcing to understand how people might use the product, under what circumstances and where their perceptions lie in terms of what is considered quality and what might failing gracefully look like so that it doesn’t endanger a patient or caregiver and limits damage to your brand.
3. Document Product Assumptions and Identify Biases: Documenting, challenging and tracing product assumptions around resilience seemed to be key.   What assumptions are we making on how the device will be used and under what circumstances?   What can we assume about external forces and environment?    Is it reasonable to consider that every subsystem or component has the potential for failure either independently or simultaneously and if so can the system recover or provide warning to prevent a surgical procedure that might endanger the patient?   
4. System/Environment Study:  We need to understand the entire system in which the product will be manufactured, distributed and used.    This includes environmental and user factors.     Under what circumstances will the product used, what temperatures are possible, could it be dropped or get wet?     Separately, I considered that FDA provides some guidance on these kinds of things such as Human Factors Guidance.  
5. Risk Management: Building on our assumptions and requirements, conduct a hazard analysis and risk analysis tools (like FMEA and FTA) and control plans can be used to evaluate risks and put in mitigations.  These in turn lead to a better understanding of requirements and validation needs.   ISO 14971:2008 requires us to consider all the events that can lead to a hazard, how can that data be used to tease out the resiliency of the device in the context of the system it is being used?
6. Industry Failure Studies: For medical device we can take this one step further and look at recalls related to similar products, and consider how resiliency might have helped prevent the adverse events from occurring or allow the device to recover under those failing circumstances.   The FDA’s TPLC database and other FDA databases can be helpful here.
7. Specification:  Once the resiliency requirements are understood, specifications can be developed.     This includes considering what variable ranges are acceptable to achieve the resiliency requirements.   
8. Simulation: Simulation early on can be helpful to see how the product responds to external forces, component failure or other adverse situations that require resilience.   The COFES group pointed out to be careful not to overly rely on simulation as it provides sometimes a false sense of security but equally encouraged its use as an important tool.    The problems with the new Boeing 787 might provide a case study for simulation overuse.
9. Early Warning: Designing in early warning systems was suggested.   Assisted resilience can then be adopted to overcome the impending issue.   
10. Verification and Validation: Testing and traceability back to requirements and throughout the design to ensure all resiliency requirements are properly verified and validated.     
11. Don’t forget the (P) side:  Much of what is stated above applies to the design side of development, but what about the “processing” or manufacture, distribution and use.   Many of these principles could be reapplied to the (P) side just as much as the (D) or design side.  For example, can we simulate problems in the supply chain to ensure continued production at a level of quality required?
12. Leverage PLM technology:  To do all this effectively it would be helpful to organize, automate and integrate many of these processes using PLM technology.   This will provide a single version of the truth, ensure knowledge can be captured and reused on subsequent projects and make it easier to bring together thought leaders in each space (vs.  using point-problem databases that limit knowledge and traceability to a single or a handful of processes).