Failure Mode and Effects Analysis (FMEA) Brainstorm may sound like an oxymoron to some, but application of Systems Engineering tailoring to the rigorous FMEA process has uncovered a powerful early-stage design input tool that we use at StarFish Medical. Read on to learn how you can put it to work for you too!

Failure Mode and Effects Analysis (FMEA) has origins in the US Military from the 1960’s and was developed to identify potential failure modes in military systems and prioritize what and how to address them. Over the years, variations on FMEA have evolved for different purposes and been adopted by numerous industries. Today you can find literature on Functional FMEA, Design FMEA, Process FMEA, and others. With the growth of variations of FMEA the xFMEA acronym was adopted (e.g. DFMEA for Design FMEA).

The concept of xFMEA paints a picture of a highly structured, systematic, and rigorous technique at odds with lean design and development programs. However, by reducing the process steps and clearly outlining an alternative value proposition, the framework of xFMEA may be used to rapidly identify numerous risks and generate design ideas during the product definition stage of a medical device program. This provides a launch pad for patient risk management content and technical project risk identification to help reduce the likelihood of late-stage design iterations stemming from unforeseen risks.

A typical xFMEA starts with identifying a list of input items: functions, use cases, design features, process steps, etc. The next steps are to identify potential failure modes, the associated effects, the cause(s), and the ability to detect the failure modes leading to harm. Once scored, the risk priority number helps triage where to focus design mitigation ideation and implementation efforts.

To convert this process into a brainstorm tool you need a few of the same ingredients, and a few from open ended brainstorming. The xFMEA Brainstorm process starts with a set of input items and a series of failure mode brainstorm prompts. It strips out all the scoring and culminates in a table of effects, categorized risks, and a list of potential ideas to address identified issues in the design. The figure below illustrates the process flow for Functional FMEA Brainstorming as implemented at StarFish Medical. To use the same framework for Use or Design FMEA brainstorming all that is needed is a different set of inputs (e.g. Use Case steps) and some tailored prompts.

To execute xFMEA Brainstorming, list out the input (e.g. functions) and then consider failure modes by combining the various prompts with each input statement. For example, if the function is to supply power: Over Power, Under Power, No Power, Intermittent Power, etc. should start to generate visions of failure modes and associated effects in the mind (power surge, dead battery, blown fuse, brown out). The key is to approach the activity with an unconstrained mindset and not spend too long on any one item. Let the mind wander to use errors, reliability issues, etc. beyond initial failure modes and associated effects generated from the input item and prompt. The goal is breadth of coverage unimpeded by consideration to severity or probability of occurrence.

Once a list of failure modes exists for each input, documenting the effects completes the picture of the risk. Some items may not be realistically realized and that’s OK. Others may be non-obvious epiphanies. Ideas to address may come to mind as you go; if they do: write them down. In general, we find it most efficient to work down each list as opposed to across line item by line item. But keep it loose – this activity is supposed to be fun too!

To aid in prioritizing – and ultimately sorting – the risks, some level of categorization is helpful. We chose a coarse binning of Patient/Operator Harm related items and Business Risk items. We tackled Patient/Operator Harm items first with an eye for anything that could impact physical design. An extra valve or button can have larger impact on design effort in terms of rework or backtracking than adding an icon on a GUI.

Finally, port your good work into formal Risk Management File and Design History File documentation where needed. Our approach is to move and combine Patient/Operator Harms into Risk Analysis for more thorough scoring and formal mitigation with traceability. Impactful items in the Business Risk category are captured in System Architecture or Design Description documentation. Technical project risks are moved to the Project Risk Registry. Some items need no further action – these are the table stakes items we know we’ll address as part of good engineering practices. Where required, bring the team together to generate risk mitigation ideas, or plan how to tackle a risk and triage where to take further action.

The concept of xFMEA Brainstorming is most effective during the early stages of development to inform design description and decisions as opposed to evaluating an existing design for what could go wrong. As designers, the more we envision future issues and mitigate them before detailed design, the closer we’ll be to a fully realized design the first time.

How has Systems Engineering tailoring of technical processes helped you elevate value on your projects? We’d love to hear from you!