7 Documentation Musts for All Software Device Premarket Submissions

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:

FREE CHECKLIST: Get your printable copy of the 7 essential documents you must include in a premarket submission for SaMD and devices containing software by clicking here.

1. Level of Concern (LoC) statement

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:

• Minor: Any failures or design faults are unlikely to cause injury

• Moderate: A failure or latent design flaw could result in minor injury

• Major: A failure or latent design flaw could result in major injury or death

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.

2. Device software description

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:

• Features and functionalities

• Intended use

• Programming language

• Hardware platform

• Operating system

• Any Off-the-shelf Software usage (if applicable)

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.

3. Device hazard analysis

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:

• Identification of each hazardous event

• Cause and severity of hazards

• Risk control methods

• Any corrective actions taken 

• Verification of the risk controls

Note: FDA also recommends you conduct an analysis of all foreseeable hazards, including any that may result from either accidental or deliberate misuse.

4. Software Requirements Specification

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:

• Hardware requirements

• Programming language requirements

• Interface requirements

• Software performance and functional requirements

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.

5. Verification and validation (V&V) testing

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:

6. Traceability analysis

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.

Or you can build out end-to-end traceability with Greenlight Guru, which is designed specifically for medical device companies to demonstrate closed-loop quality system traceability with zero hassle.

In addition, our Multi-level Design Control Software is purpose-built so that each individual module or software component of a device can be managed through its own design workflow, making it easy for teams to review and approve each component, while meeting the software requirements that apply to a specific device.

See how you can automatically maintain full traceability by scheduling your free demo of Greenlight Guru today.

7. Revision level history

Your revision level history should be logged in a simple format (such as a table) and should document all changes made to your software. Each entry should include the date of the change, the version number, and a description of how the change differs from the previous version.

If there are any differences between the tested version of the software and the released version, these should also be documented as part of your revision level history, as well as an assessment how those differences may affect the device’s safety and effectiveness.

Fortunately, Greenlight Guru's change management software makes it easy to track, trace, and collaborate on changes that impact your development and design. 

FREE CHECKLIST: Get your printable copy of the 7 essential documents you must include in a premarket submission for SaMD and devices containing software by clicking here.

Streamline the premarket submission process with Intelligent Document Management

Keep in mind that these are only the “must-haves” for all premarket submissions for software used in and as a medical device. Depending on the LoC of your specific device, you may need to submit substantially more documentation.

And the best way to store, retrieve, and organize those documents is with Greenlight Guru. Our cloud-based, secure, end-to-end solution helps you gain full visibility and traceability of all your documents within your QMS — improving your chances of getting the green light from CDRH upon successful review of your premarket submission.

Get your free personalized demo of Greenlight Guru today.

Looking for a design control solution to help you bring safer medical devices to market faster with less risk? Click here to take a quick tour of Greenlight Guru's Medical Device QMS software