%20Process%20copy.png)
As the prevalence of software in medical devices and software as medical devices (SaMD) has increased, medical device regulators have been forced to keep up.
In the US, the Center for Devices and Radiological Health (CDRH) branch of the Food and Drug Administration (FDA) is in charge of regulating medical devices, whether they contain software or not.
But if you are building a medical device that contains software, or developing SaMD, that you intend to place on the US market, there are several software-specific guidelines from FDA that you are expected to follow and include in your premarket submission.
We’ve put together this list of seven must-have documents you’ll want to make sure your submission contains before you send it off to CDRH for final review. And while you may need extra documentation depending on the type of device you’re developing, these are the essential documents for your medical device software’s premarket submission:
The first step in creating your premarket submission is determining and documenting your device’s level of concern (LoC).
The LoC is simply an estimate of the severity of injury the device could inflict on a patient or operator, either directly or indirectly. However, making this determination is an important first step, as your device’s LoC directly affects the number and type of other documents you will need in your premarket submission.
FDA uses three levels of concern, and defines them as:
Keep in mind, although FDA uses three levels of concern, these are not to be confused with the three risk classifications for medical devices —Class I, Class II, and Class III. Your software’s LoC doesn’t necessarily correlate with its risk class. Software in a Class II device may have a minor LoC, for instance.
Your premarket submission must offer a determination of your device’s LoC, as well as the rationale you used for making that determination. Part of that rationale should be a description of the software’s role in causing, controlling, or mitigating any hazards that could result in injury.
For help determining your software’s LoC, reference Tables 1 and 2 in the FDA guidance for the Content of Premarket Submissions for Software Contained in Medical Devices .
The device software description is a comprehensive overview of both the device features that are controlled by the software and the intended operating environment. FDA recommends you provide the description in paragraph form and call attention to any significant software features.
Your device software description document should include:
You may already have this information recorded in another document, such as the Software Requirements Specification that is covered in number four of this article. If so, it’s acceptable to add an annotation to your submission explaining where to find the information.
All software devices should have a device hazard analysis included with its premarket submission. The purpose of this document is to identify and assess all known hazards—for both software and hardware—that are associated with the device’s intended use. Risk analysis, risk evaluation, and risk control should be conducted in accordance with ISO 14971:2019 and thoroughly documented.
If you already have this information in a comprehensive risk management document—such as your Risk Management Summary—FDA does allow you to use an extract of the software-related items in that document as your device hazard analysis.
FDA recommends that you include the following information in your device hazard analysis:
Note: FDA also recommends you conduct an analysis of all foreseeable hazards, including any that may result from either accidental or deliberate misuse.
The Software Requirements Specification (SRS) document requirements relate to function, performance, interface, design, and development of the software.
For software with a minor LoC, a summary of the SRS is all that’s required for a premarket submission. However, if your medical device software has a moderate or major LoC, it is recommended that you submit a detailed document that includes:
If the SRS seems similar to the device software description, that’s because it is. As previously mentioned in section number two of this article, the SRS may include the information you need for your device software description, and that’s perfectly fine as long as you make the necessary annotations.
Verification and validation are placed together on this spot in our list, but they are two distinct processes, and your documentation should reflect that.
Verification is the confirmation that specific outputs for a phase of development meet the required inputs. Validation, on the other hand, is the confirmation that device specifications conform with the intended use of the device and user needs.
Verification and validation documentation is required for all submissions, although the extent of what is required depends upon your LoC. The table below shows recommended documentation for each level:
Level of Concern
Verification & Validation Testing Documentation
Your traceability analysis document should provide a clear link between design requirements, design specifications, and testing requirements. It’s also an opportunity to show clear connections between any hazards you’ve identified and the mitigation methods you’ve implemented and tested.
You can use a matrix, such as the example below, to organize the traceability analysis using the reference numbers from your QMS.
User need
SRS
SDS
Hazards
