Euro Convergence: Experts discuss device software deficiencies in the US and EU

AMSTERDAM – Whether you are trying to get medical device software on the market in the United States or the European Union, the key is to show regulators you’ve thoroughly considered the risks and conducted the necessary testing. It also helps to make it easy for regulators to find the necessary documentation in your premarket application, according to experts who spoke at RAPS Euro Convergence 2023 on 12 May.

While the medical device software sector is booming, regulatory oversight of such products is also rapidly evolving, leaving sponsors scratching their heads about what is expected of them.

Nancy Morrison, vice president for intelligence and innovation RQM+, and Abtin Rad, global director for functional safety, software and digitization at TÜV SÜD, walked attendees through some of the common issues sponsors face with medical device software at the premarket applications stage and how to address them.

US submissions

Morrison listed several key deficiencies she’s seen in premarket submissions for medical device software or software as a medical device (SaMD) in the US.

One of them is that sponsors often fail to provide enough information to FDA about what the device does and how it does it.

“We see over and over and over again, the deficiency is coming because the agency didn't understand what the device is,” said Morrison.

She said the agency has raised concerns that submissions often don’t have "clear and accurate" product descriptions, including the complete functionality of the software. Similarly, she noted that US regulators often ask sponsors to provide more detailed instruction for use (IFU), so users can better understand how a product should be used.

"For the most part [FDA] will give you one chance to respond, so if you start off on the wrong foot, it's really hard to get back on the right foot and resolve all the issues in that single submission,” Morrison warned.

One of the best ways to present a product description is to get help from marketing, Morrison said, as marketing departments tend to have to put together “elevator pitches” that are used to inform management about what a product is to get their buy-in.

“Use that language you already have,” she said. “Give FDA the big picture before you get into the details that will help set the stage and get them looking the right way.”

Another area that FDA often encounters deficiencies is in understanding a device’s functionality is how the software algorithm works and the rationality behind how it was designed, and often ask for additional documentation to help regulators better understand the algorithm.

Morrison said it’s important that FDA has a clear description of the device for them to complete their review, and if sponsors don’t get it right early on, then the rest of the review will be painful.
She adds that the agency will often provide advice on how to address the deficiency in their usual communications with sponsors, such as by asking them to update the IFU. This is in strong contrast to notified bodies, who are not allowed to consult, and therefore sponsors are left to figure out how to best address such deficiencies on their own.

Another tip Morrison said might be helpful to sponsors is to ask a third party to read the description and then describe what they think the product does. If their description isn’t accurate, the sponsor should consider reevaluating how they’ve described their product.

Another issue FDA often runs into with software products is that the agency doesn’t understand the sponsor’s algorithm. She said FDA views the algorithm as a “black box” and sponsors should try inform the agency by providing detailed descriptions of what the algorithm does, the input and output parameters, the data used to inform the algorithm and identifying what is proprietary in the algorithm.

Morrison also touched on predetermined change control protocols (PCCP) for digital health products, especially those with artificial intelligence or machine learning (AI/ML) capabilities.

PCCPs have been a topic of interest for FDA in recent years, as it has tried to strike a balance between allowing software makers to update their products quickly, while also ensuring that products continue to maintain their level of safety and efficacy. The agency has issued guidance on the topic and more recently, Congress passed a law explicitly giving regulators the authority to facilitate PCCPs.

Morrison said it's important for sponsors to ensure their PCCP management follows a clear and well-defined path, and she recommended they use FDA's presubmission process to talk about the issue before making a submission. She also said it's important sponsors reference the IEC 62034 standard, Developing Software Precertification Program, and FDA's draft guidance on modifications to AI/ML-based SaMD.

“If FDA doesn't understand the guardrails of your change control, or you didn't submit a change control plan in terms of how you're going to manage that software going forward, you're going to find yourself in a situation where you have to do new submissions more often than you'd like, versus being able to include that up front,” said Morrison. She added that the agency will likely want details about how the product will be managed and recommends holding pre-submission meetings to hash out the details.

Defining a product’s risk, tends to be another major deficiency, according to Morrison. She said it’s the sponsors responsibility to make it clear to FDA they have tried to account for all potential risks and how those should be addressed. She noted that FDA’s definition of low-, moderate-, and high-risk assessments tend to be on the conservative side, which means that many products a sponsor might consider low-risk products get kicked into the moderate-risk category.

Morrison noted that there are other major deficiencies that seem to surface regularly, such as regression testing and concerns about a product’s cybersecurity, which includes providing a software bill of materials. She also focused on documentation deficiencies and said that while a sponsor may provide all the documentation that is being asked of them, it is a smart move to provide a trace matrix that lists all the documentations that the agency may ask for and where to find those items in the submission.

“FDA doesn’t have extra time, making their job easier, makes your job easier,” said Morrison. “Try to be kind to your reviewers, and trace matrix can help guide them to find those things.”
Finally, the big takeaways for Morrison are that sponsors should plan on implementing IEC 62304 as a baseline for all their software development and documentation, and they take shortcuts in their design control steps. She added that reading up on current guidance will go a long way in reducing the number of questions they may have to ask FDA.

“Every time I submit a submission I pull the latest guidance,” said Morrison.

Navigating notified bodies

On the European side, Rad discussed the most common deficiencies he sees with submissions to notified bodies. The issues on his list largely paralleled those presented by Morrison, and includes incomplete or inadequate documentation, lack of validation, inadequate risk management, inadequate change control, inadequate complaint handling and inadequate training.

Rad had similar advice to avoid deficiencies but added that often manufacturers upclassify their products without any real justification, which then sets them up for additional scrutiny and advised they refrain from doing so. He also noted that sponsors should remember that they not only have to adhere to ISO 14971, which lays out risk management requirements for medical devices but also parts of IEC 62304, which sets analysis requirements for software.

Based on his experience, Rad said that software manufacturers should also list all hazardous situations that may be introduced by the software in their application and advised sponsors to look at all potential standards out there, even if they don’t think those standards fully apply to their product.

Rad said FDA and the notified bodies approach medical device software regulation very similarly, though notified bodies tend to focus more on patient data privacy while FDA focuses more on disclosure policies.

Morrison noted that FDA has a tendency to push medical device software into the de novo pathway instead of the 510(k) process, which means sponsors may have to provide clinical data and evidence that they otherwise wouldn’t have to submit.

Euro Convergence: Experts discuss device software deficiencies in the US and EU

Related topics

Recommended content

Welcome to the new RAPS Digital Experience