FMEA 4.0 Re-Thinking DFMEA Organization (ARTICLE 3)

Re-Thinking DFMEA Organization

From Process Functions to Use Cases & Event Trees

Abstract

Design Failure Modes and Effects Analysis (DFMEA) is a cornerstone of medical device risk management. Yet many DFMEAs remain organized around process functions—a legacy structure that obscures system intent, weakens traceability, and collapses under product complexity.
This article presents a regulator-credible, systems-engineering-aligned alternative: organizing DFMEA around Intended Use → Use Cases → Event Tree Analysis (ETA), then assigning DFMEA attributes to each path.
The result is a DFMEA that is complete, scalable, auditable, and AI-ready.

1. The Legacy Model: DFMEA Organized by Process Function

How It Typically Looks

In the traditional approach, DFMEA rows are grouped by “process functions” such as Power On, Deliver Therapy, Monitor Sensor, or User Interface. Each function becomes a container for potential failure modes, effects, causes, and controls.

Why This Model Persists

• Familiarity and inertia

• Ease of starting from a requirements list

• Spreadsheet convenience (one tab, one list)

Unfortunately, these conveniences mask structural weaknesses that grow with device complexity.

2. The Hidden (and Not-So-Hidden) Problems

Below is an expanded and systematic critique of the process-function-based DFMEA.

2.1 Incomplete Coverage Is Hard to Detect

• No objective way to confirm all relevant functions have been captured

• Functions are often derived informally, not from a formal system model

• Missing functions remain invisible until late design reviews—or worse, post-market

2.2 No Natural Ordering or Hierarchy

• Functions appear as a flat list with no system context

• No distinction between primary, secondary, or conditional behavior

• Cross-cutting functions (e.g., alarms, data handling) get duplicated or fragmented

2.3 No Traceability to Intended Use or Use Environment

• Functions rarely map cleanly to Intended Use statements

• Use environments (home, clinical, emergency) are implicit or ignored

• Reasonably foreseeable misuse is difficult to integrate coherently

2.4 Weak Alignment with System Architecture

• Hardware, software, and human interaction blur together

• Subsystem boundaries are unclear

• Integration failures are discovered late because the DFMEA is not system-aware

2.5 DFMEAs Become Unmanageable

• Large devices produce hundreds or thousands of rows

• Navigation, filtering, and review become error-prone

• Excel-based DFMEAs become brittle, slow, and audit-unfriendly

2.6 Redundancy and Inconsistency

• Same failure mode appears under multiple functions

• Severity and occurrence rankings drift over time

• Control effectiveness is assessed inconsistently

2.7 Poor Support for Top-Down Risk Analysis

• Process functions encourage bottom-up thinking only

• Failure propagation paths are not visible

• System-level hazards are back-filled rather than derived

2.8 Lifecycle and Change Management Failures

• Design changes require manual scavenger hunts

• Variant and accessory impacts are hard to assess

• Post-market data does not map cleanly back to functions

2.9 Audit and Regulatory Risk

• Traceability is implicit, not explicit

• Justifying completeness during audits is difficult

• Reviewers must infer logic rather than verify structure

2.10 Not AI- or Database-Ready

• Flat spreadsheets resist relational modeling

• No semantic structure for automated reasoning

• Limits future digital transformation

3. A Superior Model: Use Cases + Event Tree Analysis

To fix DFMEA, we must change the organizing principle.

Instead of asking:

“What functions does the design perform?”

We ask:

“How is the system intended to be used, and what can go wrong along each usage path?”

This aligns DFMEA with systems engineering and risk management best practices as expected under International Organization for Standardization risk frameworks.

4. Step 1 — Start with Intended Use & Use Cases

Intended Use as the Anchor

Every DFMEA must be traceable to:

• Intended medical purpose

• Target population

• Use environment

• User profile

Deriving Use Cases

Use Cases describe real operational scenarios, such as:

• Normal therapy delivery

• Setup and configuration

• Interrupted use

• Maintenance and cleaning

• Foreseeable misuse

Each Use Case becomes a first-class DFMEA container, replacing “process functions.”

Benefits

• Forces completeness

• Makes assumptions explicit

• Naturally includes user interaction and environment

5. Step 2 — Apply Event Tree Analysis (ETA)

Why Event Trees?

Event Tree Analysis models what happens after an initiating event, capturing:

• Normal progression

• Deviations

• Detection points

• Failure propagation

ETA in DFMEA

For each Use Case:

1. Identify initiating events

2. Map success and failure branches

3. Capture conditional paths (e.g., alarm works vs. alarm fails)

4. Identify end states (safe, degraded, hazardous)

This creates a top-down, causal structure that process functions cannot provide.

6. Step 3 — Assign DFMEA Attributes to Each Path

Instead of one monolithic table, DFMEA attributes are contextually assigned.

For each Use Case × Event Tree Path:

• System and subsystem requirements

• Functional intent

• Potential failure modes

• Failure causes

• Local, system, and user/patient effects

• Existing design controls

• Detection and prevention mechanisms

• Risk estimation parameters

• Risk control measures

• Verification and validation activities

This preserves DFMEA rigor while dramatically improving clarity.

7. Structural & Practical Advantages

Completeness

• Coverage is proven by Use Case enumeration

• Gaps are visible immediately

Traceability

• Intended Use → Use Case → Event Tree → DFMEA

• Clean linkage to hazard analysis and risk controls

Scalability

• Large systems decompose naturally

• Variants and accessories map to specific Use Cases

Lifecycle Maintainability

• Design changes impact specific paths

• Post-market signals map cleanly back to scenarios

Audit Readiness

• Logical, defensible structure

• Reviewers can follow reasoning without inference

AI & Digital Readiness

• Natural fit for relational databases

• Enables future AI-assisted risk reasoning

• Supports knowledge graphs and structured analytics

8. Comparison: Old vs. New

9. Common Objections — and Why They Fail

“This is too complex.”
Complexity already exists—it is merely hidden. This model reveals it early.

“Regulators expect traditional DFMEAs.”
Regulators expect effective risk management, not legacy formatting.

“Our tools don’t support this.”
That is a tooling limitation, not a risk-management justification.

10. Conclusion

Organizing DFMEA by process function is no longer sufficient for modern medical devices. A Use Case– and Event Tree–based DFMEA restores system intent, strengthens traceability, and aligns DFMEA with how regulators, engineers, and—soon—AI systems reason about risk.

This is not DFMEA 2.0.
It is DFMEA done right.