Medical Device Software: Top Regulatory Submission/File Deficiencies and Requests for Additional Info From Both FDA and Notified Bodies

Medical devices that fall into the category of software as a medical device (SaMD) are on the rise as technology continues to evolve. Although these products have proven to be highly beneficial to patients and end users, manufacturers must overcome many regulatory challenges.

Common Deficiencies for Software as a Medical Device

Understanding the common hurdles and how to avoid them helps improve submission efficiency and allows you to get to market faster.

Incorrect Classification of Risk

In the U.S., devices are classified into three different classes based on the level of risk (class I, II or III). However, for SaMD devices, the FDA also requires that you determine the Level of Concern (LOC) — major, moderate or minor depending on the level of risk —  using questionnaires outlined in Tables 1 and 2 in the FDA’s “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” (issued May 11, 2005). Confusion can arise as the LOC for the software can differ from the device classification. For example, Class II 510(k) devices can have a major LOC. 

The EU software classification rule is based on the International Medical Device Regulators Forum (IMDRF) risk classification matrix, which designates devices as class I, II, III or IV from lowest to highest level of risk. This classification approach factors in the seriousness of the condition and whether the device is used to treat or diagnose, drive clinical management or inform clinical management.

The LOC and risk classification should be driven by the hazard analysis and based on how the operation of software could affect the patient or user. An incorrect LOC or risk classification could indicate an error in the risk analysis, which could impact the software documentation created and their contents. 

Appropriately classifying your products the first time will help avoid delays in regulatory review and findings due to missing documentation. Unless the designated risk classification can be appropriately justified in the EU MDR technical documentation or FDA regulatory submissions, the reviewer is likely to question it, leading to rejected submissions or supplemental information being requested, delaying the review.

Software Design Specification (SDS) Lacks Sufficient Detail

The Software Design Speciation (SDS) is supposed to provide details about how the requirements detailed in the Software Requirement Specifications (SRS) are implemented. The SDS should contain sufficient information to explain to the FDA how the device will do what it is supposed to. The details of an SDS can be a bit confusing because the level of information that the manufacturer feels is sufficient for how a requirement should be implemented (i.e., a design specification) is sometimes not clear to the FDA reviewer, and it's not always clear to the manufacturer how much detail is necessary. 

We have seen companies whose SRS and SDS are the same document or read very similarly. The SRS and SDS should be two distinct documents and both contain sufficient information for the FDA to understand all the requirements (e.g. functional, performance, interface, design, developmental) and how they are implemented. 

Traceability Between Documents 

Requirements for software as a medical device must be traced throughout the product development lifecycle. It is important to link the requirements, design specifications, hazards, verification and validation activities, and potentially any unresolved anomalies. Because manufacturers use various document formats and present the information differently, the FDA sometimes has trouble tracing a requirement all throughout the product development lifecycle. Therefore, it is important that the traceability matrix is clear and that the manufacturer performs the exercise of tracing several requirements throughout the documents to ensure that the FDA can do the same.

Cybersecurity Risks

Manufacturers must properly address cybersecurity risks through their device hazard analysis and a cybersecurity risk management plan. These can be their own separate documents or incorporated into the existing software documentation. Cybersecurity risks should also include those from software of unknown provenance such as off-the-shelf software, public web platforms and privately developed software. Authentication controls such as security, privacy, password requirements and wireless communication issues must be considered and mitigated. Furthermore, depending on the device, it must be made clear who has access to various back-end functions, data and more. Finally, cybersecurity labeling should be included.

Impacts of SaMD Deficiencies

When reviewers respond with findings or deficiencies, the impact on manufacturers depends on how serious the findings are. In some cases, it’s a simple matter of clarification, but sometimes manufacturers must invest in additional testing or other resource-intensive activities. 

Delayed Approvals Due to Additional Documentation Gathering and Testing

In the U.S., the LOC determines the documentation requirements. In the EU, device classification informs the conformity assessment process, which is one of the first elements reviewers look at. If it’s wrong, you have to rework your submissions and may need to provide additional documentation or gather additional clinical evidence. Many manufacturers assume they don’t have to perform unit testing because it’s only required for higher-risk devices. However, if your risk classification is wrong, you might have to do unit testing anyway, which will set back the clock.

Delay to Market

Delayed approvals result in delays in getting your products to patients. For products already on the market, software updates are an important consideration. Are they considered a significant change, or can it be documented as a letter to file? The FDA provides a separate guidance document just for evaluating software changes. The answer depends on the update, but you need to be able to justify your decisions to regulators. 

Extra Cost

Additional testing and documentation come with additional costs that might not have been budgeted. Further burdening resources leads to extra costs and additional opportunity costs if people are redirected away from other projects because they are needed to respond to deficiencies. Software recalls also come at a high cost to business, loss of reputation and loss of use, which is why conforming post-market submissions is so critical.

How To Avoid Common Pitfalls With SaMD Submissions

Review IEC 62304 62304:2006/A1:2016 “Medical Device Software - Software life cycle processes” and Applicable Guidance Documents Early in the Device Development Lifecycle

Get an understanding of what documentation will be required and the specifications of each document so you can create conforming documents during the development process. This saves time and resources because conforming documents don’t have to be created retroactively.

Map Requirements to Documentation

Make it easy for reviewers to find the information they need. Map out where each requirement can be found in your documentation so they don’t have to waste time hunting or cause delays with questions because they couldn’t find the info they needed.

Trace Hazards Through to V&V Testing

Reviewers start by spot checking or skimming documentation before they start with a deeper review. Do an internal gap assessment of each hazard by tracing it through your documentation from the device hazard to software requirement to design specification to implementation and V&V testing. If you can’t trace it from beginning to end, neither can a reviewer. Identify the gaps and fill them before submitting your files. Provide a trace matrix to the reviewer so they can follow along.

Design Validation

Root your design validation in both the intended purpose, intended patient population and the target end user. Usability and risk assessment feed into final validation, and you must demonstrate that you have addressed those elements of your device.

Consider the Worst-Case Scenario

Don’t start with the risk level you want your device to be at; start with the worst-case scenario to more easily demonstrate why that case will never happen and use this to inform the LOC and risk classification for conformity assessment requirements. This mindset will also inform how you develop design and technical documentation, your design validation approach and the arguments you make to reviewers. Reviewers like to see pre-mitigation risk assessments in the hazard analysis, and taking this approach contributes to a more robust justification of risk classification and why the device does not fall into a higher risk category. 

Address Operating System Changes

Include in your software development environment plan documentation how you will address future changes to the operating system that your software runs on (e.g. Apple, Android). Preparing for these types of changes is essential when evaluating risk.  

How RQM+ Helps

RQM+ can help with the initial EU or FDA submission for software as a medical device or with remediating files after reviewers find deficiencies. We have submitted numerous 510(k), De Novo, Breakthrough Designation/STeP and pre-submissions for SaMD devices so you can rely on our regulatory experience for your software devices, no matter what stage of development they are in. 

To learn more about this topic, check out our on-demand webinar, “Common FDA and Notified Body Software Deficiencies and How to Avoid Them,” with Kevin Go, RQM+ expert and this blog post’s author.