FMEA is a recommended tool for identifying potential failures early in the development phase, as well as their effects and the recommended actions to be taken. Global organizations such as the Six Sigma Institute recognize FMEA as a critical tool. The FMEA tool can be more dynamic in various ways, considering the technological advancements today and in the future. Using AI can analyze large amounts of data for patterns. It can be used to monitor for potential risks and initiate prompt responses, thus improving periodic reviews of FMEAs. 

Another way would be to incorporate feedback from customers and suppliers, thereby adding more experience for a multifaceted team. Additionally, FMEA can be applied more regularly to support continuous improvement efforts, such as better procedures for preventative maintenance. Medical devices require more communication with customers via labelling, IFUs, and advertisements. Sales reps checking in regularly with customers also serves as a means to reduce user error. Therefore, there are ways through training and maintenance that can mitigate risks. These would be examples of supporting scenario-based risk thinking or human factors. An FMEA can still be used, but it depends on the company whether or not they are using the tool adequately and sufficiently. 

I agree that a more dynamic approach to each device would be the best way to handle risk management on any individual project. I do think that you are correct, that maybe there may not be enough emphasis on scenario based risk or human factors. However, one problem I think that may arise from requiring dynamic risk modeling is consistency of the application. It would be very difficult to create a broad enough dynamic risk model, that can doesn't leave too much room for individual interpretation that may make compliance unclear. If there isn't a single model, than for every project a new unique risk model will have to be created, which may be difficult to do. Ultimately, FMEA provides good consistency and is reasonably robust, can be paired with more unofficial scenario-based risk model for projects that need it. Overhauling the required risk modeling to be more dynamic can result in wildly inconsistent interpretations and applications. 

FMEAs are indeed a useful tool for evaluating the types of failures a system could experience if one (or several) of its components fail. This is especially true for medical devices, which include various components/subsystems that, when under the right circumstances, can cause destructive issues.

To answer your first question, it can make the process “mechanical,” but in the sense of having a structure to risk analysis; it makes the process linear and as unambiguous as possible. That way, when analyzing a system, we can evaluate it thoroughly with little to no discrepancies. However, I will concede that we cannot EVER look at one system the same way we’d look at another. No two systems are the same, and thus should have their FMEAs tailored towards them in the sense of failure mode description, risk analysis, and potential recommendations/mitigations. That said, it’s truly impossible to think of EVERY kind of failure for any given product, and some afterthoughts are very much doable. This is why we conduct design reviews even into the postmarket period.

Regarding your second question, there are methods of analysis that can complement an FMEA and better prepare for most hazards. For example, I’ve learned to use a Preliminary Hazard Analysis (PHA) in a systems safety course I’m currently taking. This tool’s purpose is exactly for your suggested solution: providing scenario-based risk considerations via an analysis of hazard groups. This tool includes naming a specific scenario based on given conditions & circumstances for a product/system, which are then translated into recommendations for control. This is typically performed during the conceptual & design phases of a project, which would roughly correspond to the pre-market phase of the product life cycle. To complete a PHA, one has to evaluate the overall operation and its components. These are categorized into several key descriptors, including but not limited to collision/mechanical damage, contamination, corrosion, electrical shock, explosion, loss of habitable atmosphere, radiation, and so on. Then, causes and effects are listed and are scored via the risk matrix to assign a “risk analysis code” or RAC (which is the score itself). Finally, initial assessments and recommendations are made based on the RAC, giving personnel a clearer picture of potential dangers within the product’s scope, requirements, and desired specifications before advancing to the realization & postmarket phases.

For your final question, I would be surprised to see if QMS regulations (namely ISO14971) don’t already reference dynamic risk requirements. However, we should recall that these regs only provide a framework for these best practices, thus would benefit from emphasizing the need to incorporate any and every kind of risk beyond what is indicated on paper. For example, ISO14971 mentions PHAs alongside the tools we’ve discussed while encouraging a flexible approach to refine RM via continuous monitoring and post-production data collection. That way, companies can always ensure they catch all pitfalls before and after the product is in the market.

This post brings up an important point about whether the use of FMEA has become too rigid for the reality of modern devices. FMEA is a useful starting tool but it usually fails to capture the unpredictable ways failure can happed. When teams focus mostly on checklists and scoring tables, they can miss important insights from human factors work. The question about whether FDA or ISO should push for more flexible and dynamic approaches is relevant as devices become more complex and interconnected. At the end, a stronger approach may be to keep FMEA as a foundation but combine it with human factors analysis and broader system level risk evaluations to get a better understanding of risk

One issue I see with depending too much on FMEAs is that they are predicated on the idea that failures occur one component at a time in predictable ways. However, contemporary medical devices do not malfunction in neat, linear sequences, particularly those with software, connection, or closed-loop automation. They fail due to interactions: a little software timing error, an unforeseen user action, and a network delay might all come together to create a failure mode that would never be captured by a single FMEA row. 

This leads to another drawback: FMEAs are only as good as the team's conscious imagination. They capture the known knowns, but they fail to reveal blind spots or the peculiar, multi-step failure chains that frequently occur in practical applications. And because everything appears defined and structured, it can give a sense of “we covered everything,” even when the most dangerous problems are the ones nobody thought to put on the list in the first place.

I don’t think this means we should abandon FMEAs, but it does mean they shouldn’t be treated as a full model of system behavior. For today’s devices, we probably need complementary tools that uncover emergent or unexpected risks. Things like scenario-based simulations, stress testing, or even software fault injection to capture the interactions that checklist-based approaches inherently miss.

To build upon what was mentioned in the post before mine, FMEAs are only as effective as the team who constructed it. Relying on checklists can be the result of inexperience and/or the reluctance to challenge the design of a device. A FMEA can look like an effective tool, but can still miss properly identifying risks in a medical device if the team responsible for the FMEA are not comfortable, either through pressure or inexperience. The obvious example of this is for devices which incorporate a lot of software. The team may not be completely familiar with the software, and may not understand what kind of assumptions are being made. Software can be a lot of "checking boxes", but verifying the outputs of the software is more difficult, which is where I think the current FMEA falls short on. I do agree that dynamic risk modeling should be incorporated because risk in medical devices now and in the future won't be completely evaluated with yes or no checkboxes.

FMEA is useful, but it can create a false sense of completeness because it treats failures as isolated, linear events, while real-world medical-device failures often emerge from interactions, cognitive overload, software complexity, and unexpected use scenarios that don’t show up in a worksheet. Companies sometimes lean too heavily on checklists, RPN scores, and predefined failure modes, which can crowd out human-factors analysis, usability studies, STPA-style system thinking, and scenario-based testing that better capture emergent risks. FDA and ISO standards don’t forbid these richer methods, but they also don’t strongly require them, so organizations default to the familiar spreadsheet-driven approach. A more dynamic risk-management framework—one that blends FMEA with human-factors engineering, simulated-use studies, software hazard analysis, and system-theoretic models—would better reflect how real failures actually happen and help prevent the kinds of interaction-driven incidents that traditional FMEA alone can miss.