FMEA in Jira: 10 Steps for Medical Device Risk Management

[#1]

Risk management in the medical device industry isn’t optional – it’s literally life or death. If you’re developing medical devices, you need to identify, assess, and mitigate risks throughout your entire product lifecycle. Patient safety depends on it.

Watch this step-by-step guide to implementing FMEA for medical device risk management.

Last week I covered hazard analysis based on ISO 14971. This week, we’re diving into FMEA – one of the most powerful methodologies for medical device risk management, especially when software is involved.

What FMEA Actually Does (And Why You Need It)

FMEA stands for Failure Modes and Effects Analysis. It’s a detailed, bottom-up risk analysis approach that identifies potential failure modes in components, processes, or software. Unlike hazard analysis, FMEA gets granular – examining exactly how things can fail and what happens when they do.

Here’s what makes FMEA different from hazard analysis:

• Quantitative approach: Uses Risk Prioritization Numbers (RPNs) to rank risks numerically
• Component-focused: Looks at specific parts, processes, or software elements 
• Bottom-up methodology: Starts with individual components and works up to system effects
• Detailed causation: Maps failure modes to root causes and downstream effects

FMEA typically complements hazard analysis. While hazard analysis is a top-down, qualitative method that addresses system-level hazards, FMEA provides the granular, quantitative analysis needed for targeted risk mitigation.

The 10-Step FMEA Process for Medical Devices

Let me break down the FMEA process into manageable steps:

Step 1: Define Your System Scope

Start by clearly defining what you’re analyzing – the system, subsystem, or component under review. Consider the entire product lifecycle from design to disposal.

Review your device specifications, design documents, and regulatory requirements. You need crystal-clear understanding of:

• Intended use;
• Operating environment; 
• User profile;
• Regulatory constraints.

Step 2: Assign Risk Owners

Assemble experts from engineering, quality, regulatory affairs, and clinical departments. Don’t just assign responsibility – give your risk owners the authority and resources to actually manage the risks they own.

Establish clear communication processes for effective collaboration throughout the FMEA analysis.

Step 3: Identify Device Functions and Requirements

Break your medical device into its functions and sub-functions. Identify performance requirements for each function, including regulatory, user, and safety needs.

Create functional diagrams to visualize the system and identify critical or life-supporting functions. This visual approach helps ensure you don’t miss anything important.

Step 4: List All Possible Failure Modes

For every identified function or software component, brainstorm all possible failure modes. Consider how each function or component might fail.

Use:

• Brainstorming sessions with your team;
• Historical data from similar devices;
• Customer complaints and feedback;
• Test results and validation data.

Don’t skip this step – overlooked failure modes become real-world problems.

Step 5: Identify Effects of Each Failure Mode

Evaluate how each failure mode impacts:

• The device itself;
• The patient;
• The user;
• The environment.

Look at both local effects (within the device) and broader system-level effects. Include clinical perspective when identifying potential patient or user harms.

Step 6: Analyze Root Causes and Failure Mechanisms

Dig into the root causes that could trigger each failure mode. Explore potential errors in:

• Design;
• Software;
• Manufacturing;
• User handling.

Understanding the “why” behind failures is essential for effective mitigation.

Step 7: Evaluate Risk Using RPN Scores

Here’s where FMEA gets quantitative. Assign scores for severity, occurrence, and detectability for each failure mode using your predefined ranking system.

Calculate the Risk Prioritization Number (RPN) by multiplying these three scores:

RPN = Severity × Occurrence × Detectability

The RPN gives you a numerical value to prioritize which risks need immediate attention.

Step 8: Identify Risk Mitigation Actions

For unacceptable risks, propose and document appropriate risk control measures. These usually include:

• Design modifications;
• Software updates;
• Enhanced user instructions;
• Manufacturing process changes.

Focus on reducing probability of occurrence and improving detectability of failures.

Step 9: Reassess Residual Risk Post-Mitigation

After implementing risk controls, recalculate the RPN to verify that residual risk falls within acceptable limits as defined in your risk management plan.

Confirm that all mitigations have been properly verified for effectiveness. This step is critical – mitigation without verification is just wishful thinking.

Step 10: Document and Maintain Your FMEA

Document all steps, findings, and decisions in your FMEA worksheet. Maintain it as a living document that reflects:

• Design changes;
• Manufacturing improvements; 
• Post-market surveillance data;
• User feedback. 

Everything must be documented for regulatory compliance and audit readiness.

FMEA vs. Hazard Analysis: How They Work Together

These approaches are complementary:

• Hazard Analysis: Top-down, system-level, qualitative approach identifying hazards and hazardous situations;
• FMEA: Bottom-up, component-level, quantitative approach examining specific failure modes.

The main connection point is at the cause level – certain failure modes can result in hazardous situations, and hazards can be caused by specific failure modes.

Real-World Example: FMEA for Glucose Monitoring App

Let’s walk through a practical example. Imagine we’re developing a smartphone app that records glucose levels, insulin doses, and meal logs for diabetes management. The app syncs with cloud storage and shares patient data with healthcare providers.

We need to analyze how software security failures in data handling and access control could compromise both app functionality and patient confidentiality.

Key failure modes might include:

• Misconfiguration of permission management;
• Encryption failure during data transmission;
• Lack of audit logs preventing breach detection.

System effects could be:

• Data exposure beyond authorized user scope;
• Storage or transmission of unencrypted data;
• No record of access and activity logs. 

Root causes might include:

• Weak authentication/authorization controls;
• Inadequate data encryption;
• Lack of activity logging.

After scoring severity, occurrence, and detectability, we’d implement mitigation actions like:

• Review and test access rights;
• Implement dedicated encryption key management;
• Establish regular log documentation and review processes.

Implementing FMEA in Jira

Tools matter. Here’s how you can conduct FMEA in Jira using the Risk Manager Plus from SoftComply – one of the most configurable risk management apps available today.

The process starts with defining your risk model based on the three risk characteristics: severity, probability of occurrence, and detectability. Risk Manager Plus provides templates you can customize or you can create your risk model from scratch.

Once your risk model is set up, you can use the FMEA risk register (from template) and customize it for your specific needs. The app supports:

• Risk owner assignments with notification systems;
• Automatic RPN calculations;
• Traceability between failure modes, mitigation actions and verifications;
• Integration with other Jira projects for requirements traceability;
• Risk reporting in Confluence (with the free risk reporting extension) or Jira dashboard.

Check out SoftComply products for risk management or schedule a demo call to learn how you can streamline your FMEA process.

Documentation and Regulatory Compliance

Remember, ISO 14971 is the international standard for medical device risk management, and compliance is required by regulatory bodies. Your FMEA documentation becomes part of your overall risk management file.

Everything needs to be documented:

• Risk management plan;
• Risk management report;
• FMEA worksheets and analysis;
• Post-market surveillance.

The documentation isn’t just for compliance – it’s your roadmap for maintaining device safety throughout its lifecycle.

The Bottom Line on Medical Device FMEA

FMEA isn’t just another regulatory checkbox. It’s a systematic way to think through how your device might fail and what you can do about it before those failures reach patients.

The quantitative nature of FMEA makes it particularly valuable for prioritizing your risk mitigation efforts. When you have limited resources (and who doesn’t?), the RPN scores help you focus on the highest-impact risks first.

Used together with Hazard Analysis, FMEA provides comprehensive risk coverage – from high-level system hazards down to specific component failure modes. This dual approach gives you confidence that you’ve identified and managed the risks that matter most.

The key is treating FMEA as a living process, not a one-time activity. As your device evolves through design changes, manufacturing improvements, and post-market feedback, your FMEA should evolve too.

Patient safety depends on getting this right. Take the time to do thorough FMEA analysis – your users’ lives may literally depend on it.

This article was originally published on SoftComply blog. 

[vikram]

Hi @Marion Lepmets _SoftComply_ 

Thank you for sharing the info, very useful .

Vikram p