Condensed Guide to Medical Device Requirements Management

Most general guidelines for requirements management are an acceptable starting point for medical device developers. Basic instructions for requirements planning, defining, prioritizing, etc. applies to almost any industry. However, medical device requirements management has to include some extraordinarily important things that some other industries can get by without.

Compliance, risk management, and traceability are central to medical device development. They must shape early processes so that steps are not missed, and quality is not compromised. 

This guide aims to help you understand how to include these tenets in medical device requirements management to not only stay compliant, but also keep development on track and quickly prepare for compliance audits. We’ll cover:

• Medical Device Requirements Engineering
• Medical Device Requirements Specification
• Hazard/Risk Analysis and Management
• Medical Device Requirements Manufacturers
• Challenges for Medical Device Developers
• Why Traceability Matters to Compliance

Need to learn some basics first? See how to write a Product Requirements Document or Software Requirements Specification.

Medical Device Requirements Engineering

The advent of integrated, automated lifecycle management tools has helped establish the process of requirements engineering — which basically provides structure to defining, managing, and testing requirements.

Some of the steps and processes that fall under this umbrella include:

• Requirements gathering – defining requirements through discovery, analysis, specification, and verification
• Requirements specification – a use specification required by the FDA (details in the next section.)
• Requirements management – the planning, development, verification, validation, and change management of your requirements.

This entire process is meant to ensure collaboration and visibility so that requirements are thorough, prioritized, visible, and aptly tracked.

Medical device requirements engineering aligns with the above, but also accounts for compliance needs and traceability. That means that compliance is considered when you define your requirements, and you’re also establishing a way to track and trace requirements throughout development.

 The complexities of medical devices really make it necessary to use an automated tool to help with risk analysis, traceability, and team alignment to ensure the safety and compliance of your final products.

Medical Device Requirements Specification

As part of your FDA submission packet for your medical device, you’re required to provide a use specification that explains what the device does, how it works, who it serves, who it is for, and how it should be used.

Many people use  IEC 62366-1:2015 as a guideline for this document. Check that you answer all the questions required by the FDA and the regulatory bodies that govern you. We also found an industry white paper that provides this high-level overview of the basic questions your document must address about your product:

• Intended medical indication
• Intended patient population
• Intended part of the body or type of tissue applied to or interacted with
• Intended user profiles
• Intended use environment
• Operating principle
• The tasks users must complete to operate your device
• The user needs deriving from those tasks

While this does add more steps to your requirements management, answers to these questions can also help you write more thorough requirements.

Hazard/Risk Analysis and Management

Safety is one of the primary concerns in medical device development. From wearable devices to CT scan machines, product failure can potentially cause anything from injury to death. Therefore, analyzing and managing risk — the possibility of harm to an individual or the environment — is a foundational part of medical device requirements management.

From a compliance standpoint, ISO 14971 is the standard for medical device risk management. But risk management does more than meet one compliance standard. It helps you prioritize your requirements so that you can develop your product more efficiently. And by thinking through all the potential hazards and risks ahead of development, you save time (and potentially costly recalls) avoiding late-stage surprises. Risk management involves several steps:

• Define acceptance criteria (usually included in a risk matrix.)
• Conduct hazard analysis (identify hazards derived from the intended use of the medical device.)
• Perform risk analysis (calculate a risk priority number for each risk - further explained below.)
• Detail and implement risk mitigation for unacceptable risks.
• Analyze the new risk after mitigation (adjusted risk priority number.)
• Determine the acceptability of risks.
• Continue to analyze and update risks based on market surveillance.

Risk Analysis

Risk analysis is the process of outlining the risks associated with each potential hazard and rating each by severity, occurrence, and detection. (Not all companies include detection.) They are typically measured on a scale of one to five (five indicating the greatest risk.) These numbers are then calculated to provide a risk priority number (RPN) through a risk matrix. (For many, the calculation is S x O x D = RPN.)

Severity defines how severe the potential effect of the failure would be. Death is a class five hazard, as it is the most severe effect possible.

Occurrence describes how likely the failure is to occur.

Detection indicates the likelihood that the failure effect is detected. Electrical shock, for example, is easily detected, whereas detecting bacteria in what should be a sterile environment is very difficult (and would receive a higher rating.)

It’s important to calculate a risk priority number that takes at least two factors into account because something that has a high severity but rarely occurs will take less priority than something with high severity and is very likely to occur.

Risk Management and Risk Matrices

While Failure Mode and Effects Analysis (FMEA) used to be an industry standard for risk management, it is a bit outdated. If you’re still approaching risk with FMEA, learn how to replace FMEA risk assessment  to avoid gaps in visibility and quality that can potentially lead to product recalls and regulatory actions.

The best way to assess and manage risk is through a tool that can populate a risk matrix for you. For example, Helix ALM not only calculates your RPN and adjusted RPN in a risk matrix, but also provides comprehensible visibility to your risk management process. Here’s an example of a risk matrix in the ALM tool.

At the end of the day, risk management helps you set and prioritize requirements that impact the safety of your medical device, and helps other teams in the product lifecycle understand the concerns and functionality that apply directly to their role in development.

If you need help with the risk management process, read Risk Management: Scoring that Matters to Product Developers. It identifies types of risk and explains risk assessment in more detail.

Medical Device Requirements Examples

Written requirements must be extremely clear and comprehensive. Good requirements specify the component, criteria to meet, and the expected test result (definition of done.) If you are new to writing requirements, we recommend you read our blogs on functional requirements and non-functional requirements.

What’s important to remember about medical device production is that you may need to decompose large-spectrum requirements. If your device must be waterproof, for example, you might have a requirement for the device itself that looks like:

The device must withstand a consistent flow rate of [x][fluid measurement] per [time unit] for [X] [time units].

Depending on the device, you may also need to specify more granular requirements to make sure that components like buttons can also withstand the defined flow rate. Packaging can be another granular requirement to include if, say, it cannot be exposed to a certain level of heat.  

Again, these requirements are associated with potential risks if they are not met, and those risks need to be prioritized in your risk matrix.

Challenges for Medical Device Manufacturers

Despite the number of integrated ALM solutions, it’s still common to see hardware and software teams using disparate systems. This can make traceability and tracking requirements difficult. Plus, it can add time to production as teams have to hunt down status reports, changes, and other details they need to complete their jobs.

We can see why this happens. Different teams involved in the product lifecycle will work best in different ways. They’ll use unique workflows, and they won’t necessarily align on desired functionality in a tool.

However, because traceability and safety are so critical in medical device manufacturing, finding a way to bridge this gap makes the process much more efficient.

Here again, if you use the right tool, you can solve this fairly easily. For example, Helix ALM can be configured to match your existing workflow. It also can establish security groups, which separate individual components of the software to be viewable and changeable only by specific groups — while still providing overarching visibility to those who need a larger-spectrum view of the project.

Another challenge specific to the medical device field is the frequency in which changes are made to compliance parameters.Sometimes new regulations are established, or existing ones revised. Using a tool that is designed specifically for regulated industries will help you keep up with changes. Most of these vendors are diligent about staying current and releasing updates with new regulations in mind.

For instance, it wasn’t long ago that 21 CFR Part 11 was introduced. In the case of Helix ALM, its traceability and capacity to let you set security parameters and other rules enable customers to meet 21 CFR Part 11 compliance.  

If you’ve struggled with these challenges, it may behoove you to find a quality application lifecycle management tool with embedded risk management to connect your requirements, tests, and issues in a single, automated platform.

Case study: read how Fractyl achieved compliance in record time >>

Why Traceability Matters to Compliance

Traceability certainly makes things easier for product developers. Tracing requirements to artifacts lets teams see project updates in real time, access the latest requirements, view progress, and know what has been done in development. This all reduces the amount of time it takes to track down information, and it helps you avoid mistakes that stall production. 

But for regulated industries, traceability is integral to compliance. That’s because compliance audits require a detailed audit trail that can literally take weeks to put together if done manually. If you use a tool with automated traceability, you can prove compliance in minutes.

Watch on demand: How to Manage Risk with Traceability >>

Find out how end-to-end traceability and risk management fit seamlessly into requirements management. Watch the Helix ALM demo and see how it can simplify your most time-consuming processes.

WATCH THE ON-DEMAND DEMO