The Ultimate 510(k) Checklist

Introduction 🔗

Who Should Use This Checklist 🔗

If you’re preparing a 510(k) submission, especially for a device containing software, this checklist will help make sure you don’t miss anything. It doesn’t replace having a thorough understanding of the guidance, but it will help make sure you’re not missing anything.

If you haven’t completed a 510(k) before, it may also help you understand how big of a task it is to put together all of the documentation.

If you’re creating medical device software for the US market and could use help, we’d be happy to be a resource for you.

How We Made This Checklist 🔗

This is a version of the checklist we use internally at Innolitics when we’re creating and reviewing 510(k) submissions for our clients. The checklist applies to any SaMD 510(k) submissions made for medical devices. It is designed for submissions that use the eSTAR templates.

It combines regulatory requirements from the following FDA guidance documents:

How to Use This Checklist 🔗

Complete the following sections throughout the process of completing the 510(k) submission. Each of the top-level items in bold is a document or artifact for your submission, and below is a set of action steps to help you prepare that document.

Checklists are great. They help make sure you don’t miss anything. The main problem with checklists is that, to condense the FDA guidance into a checklist you must simplify away some context. Thus, you still need to think critically when filling this out and if there is a checklist item that seems irrelevant for your situation, go back to the original FDA guidance and think critically about it. Usually there is some room for flexibility in applying and interpreting the guidance.

If you’d like a Word copy of this document, let us know and we can provide you one.

How to Get Updates When We Update the Checklist 🔗

If you’d like to receive updates when this checklist changes, please signup for our email list at the bottom of this page or in the website footer. We also share other Medtech tips that will be of interest to anyone working in the medical device space.

Disclaimer 🔗

We offer this checklist as a public service as part of our mission to “accelerate progress in the medical device industry.” We put forward effort to keep it up to date, but we can’t guarantee it’s fully correct or complete. If you notice mistakes, please let us know!

Preparing for Submission 🔗

Regulatory Plan 🔗

This will provide an analysis of the regulatory requirements and potential market-access strategies which are applicable to the device.

Draft the Intended Use statement
Draft the Indications for Use statement, if appropriate
Identify at least one suitable predicate device
Review and take note of any applicable special controls for your type of device
Determine the “Documentation Level” (Enhanced or Basic) that will be required for the software, based on FDA’s Guidance for the “Content of Premarket Submissions for Device Software Functions”.

Small Business Determination Application 🔗

This determination could reduce your 510k submission fees if your business is eligible.

Determine whether there is an existing small business determination in place for your business.
- If so, check the date of expiration.
Gather your tax documentation for the previous year.
Obtain your Organization ID number for the FDA User Fee system.
Submit a small business determination application. Allow for 60 days of review by the FDA before your planned 510k submission date.

Pre-Submission Meeting 🔗

Request a Pre-Submission Meeting with FDA to discuss any areas of concern such as appropriateness of predicate device(s), test protocols, statistical analysis plans, predetermined change control plans, etc.

510(k) Submission Review 🔗

eSTAR Attachments 🔗

This section applies to all 510(k) submissions.

See the subsequent sections for checklist items that apply only to specific situations.

Cover Letter 🔗

Describes key information for initial processing and review of the 510(k) submission. An example is provided in Appendix A of the ‘Format for Traditional and Abbreviated 510(k)s’ guidance.

Letters of Reference (optional) 🔗

Letters of Reference (LoR) include letters from the sponsor relating to any separate documents referenced in the submission (e.g., previous marketing submissions) granting access to the information in the referenced documents. LoR are not commonly used in 510(k)s, unless the sponsor is using another party’s product or facility in the manufacture of the device.

Device Description and Principle of Operation 🔗

This section describes the performance specifications and the device design requirements.

Provide a detailed description of the device.
Include key design features for the principle of operation and how performance is achieved.
Identify all models, as well as all accessories included in the submission.
Include a description of design requirements that contributed to the design of the device.

Device Schematic 🔗

The eSTAR asks for a separate attachment for Device Pictures, Illustrations, Schematics, and/or Diagrams. For SaMD, we recommend creating a document named “Device Schematic” where you have completed the following:

Write a justification for the device not having a physical form.
Include a high-level architectural chart of the software (i.e., device schematic).

Substantial Equivalence Comparison 🔗

This is a detailed comparison between your device and the predicate sufficient to demonstrate the substantial equivalence of the devices.

Compare indications for use.
Compare technology (similarities and differences). For technological differences, explain why these differences do not raise any new questions regarding safety and effectiveness.
Compare performance specifications, including any testing. Describe how testing supports SE determination.

Formatting Tip: We recommend comparisons be made in a table format. A good strategy is to look at your predicate’s 510(k) summary and use their comparison table as a guide for which features you should compare.

Labeling (e.g., user manual, product label, e-label) 🔗

Labeling includes the device label, instructions for use and marketing materials. A 510(k) must include proposed labeling in sufficient detail to satisfy the requirements of 21 CFR 807.87(e)-Information required in a premarket notification submission.

For SaMD, the “product” label will typically be the e-label or software “about” label.

Software Label (About Box), including: 🔗

Device trade name
Common name
Software Version
Manufactured by symbol (see ISO 15223-1:2021 symbol 5.1.1),
Manufacturer name and manufacturer address
Rx-only symbol and/or the following statement: “Federal law restricts this device to sale by or on the order of a physician.” (if applicable)
See IFU symbol (see ISO 15223-1:2021 symbol 5.4.3)
UDI (humanly readable)

User Manual 🔗

For the user manual or instructions for use, include the following:

Marketing Material 🔗

Include website information
Intended marketing claims

Software Documents 🔗

Software Description 🔗

Include the identification of the device features that are controlled by the software, the programming language, hardware platform, operating system, and use of OTS software (if applicable).
Provide software version naming rules.
Identify the software released version, as well as the version used for testing. If these are different, provide a justification.
If ML models are used by the software, describe the methods, models, data and data collection, identification of potential biases and limitations, and methods to provide transparency on model (e.g., development, performance and limitations).
Describe software inputs and outputs, who or what provides them, their format, who or what receives them, and if the software is intended to replace or impact any actions otherwise performed manually by user.
If the device is designed to be interoperable, describe what other products does the device interface with (i.e., electronic interfaces), and what specifications are used to interact and/or communicate with other medical/non-medical products.
If the device includes “other functions”, these should be described following the same recommendations above.

Device Hazard Analysis 🔗

Describe all device hazards associated with the device’s intended use, including both hardware and software hazards. We recommend that you present the information in tabular form with a line item for each identified risk that describes the following:

Software Requirement Specification (SRS) 🔗

In this section, describe what the software device should do.

Include functional, performance, interface, design, developmental, and other requirements for the software.
Include hardware, programming language, and interface requirements.
Format the SRS to be well-organized, and easily readable.

Architecture Design Chart 🔗

This chart shows the layout of software components and the relationships between them.

Describe the relationships among major functional units in the software, including relationships to hardware and data flows.
Include major external systems that interact with the device.
If multiple diagrams are used, communicate the relationship between the diagrams.
Include a legend to communicate the meaning of colors or other visual indicators in the diagrams.
Check that the diagrams indicate OTS modules.
Check that the diagrams distinguish “other functions” from the device functions-under-review.

Software Design Specification (SDS) 🔗

This section describes how the requirements in the SRS are implemented. Note: If your device has been determined to require Basic Level Documentation, then the SDS is not required to be part of the submission.

Provide the technical design details of how software functions, how the software design implements all the requirements of the SRS and how the software design traces to the SRS in terms of intended use, functionality, safety, and effectiveness.
Include information that demonstrates that the development of the software function was clear and unambiguous, with minimal ad hoc design decisions (i.e., SDS is expected to have been created prospectively and used as a guide for design, development, and testing of the software).
Describe any expected relationship, utility, reliance, or interoperability with any “other function”.

Traceability Analysis/Matrix 🔗

This document shows the relationships between the following:

Trace Requirements to Risks
Trace Requirements to Design Specifications
Trace Requirements to Verification Activities
Trace User Needs to Requirements
Trace User Needs to Validation Activities

Software Development Environment Description 🔗

For software that requires Basic Documentation Level:

For software that requires Enhanced Documentation Level:

Provide the documentation required for Basic Documentation Level software.
Provide documents implementing the configuration management and maintenance plans.
Alternatively, you could provide a Declaration of Conformity to specific clauses (or full version) of the FDA-recognized version of ANSI/AAMI/IEC 62304 or the FDA-recognized version of IEC 62304. Recommended sub-clauses and clauses include:
- 5.1, Software development planning
- 6, Software maintenance process
- 8, Software configuration management process

Verification & Validation Documentation 🔗

For software that requires Basic Documentation Level:

For software that requires Enhanced Documentation Level:

Provide the documentation required for Basic Documentation Level software.
Provide unit and integration level test protocols and reports, including:
- Expected results
- Actual results
- Pass/fail determination
- Identification of any unresolved anomalies

Additionally, we recommend the following should be included:

Date of completion
Person who completed it
Traceability to requirements and specifications (for verification)
Traceability to user needs (for validation)

Software Version History 🔗

Describe the history of software revisions (i.e., major changes) generated during the course of product development. Should include the following:

Date of version
Version number
Description of changes in version relative to previous version
Check that the last entry in the revision list is the final version to be incorporated in the released device.
- If there are any differences between the tested version and the released version, an assessment and justification of the potential effect of the differences on the safety and effectiveness of the device should be made
If the device includes “other functions”, the recommendations above should be considered for the revision history.

Unresolved Anomalies 🔗

Provide a list of unresolved anomalies, containing the following information for each anomaly:

Description of the anomaly, how it was discovered, and where possible, an identification of the root cause
Evaluation of anomaly’s “impact on device performance”
Risk-based rationale for not correcting the anomaly for this release
Include traceability to risk assessment of impact of unresolved anomalies on cybersecurity

Cybersecurity - Risk Management 🔗

Identify assets, threats and vulnerabilities
Assess impact of threats and vulnerabilities on device functionality and end users/patients
Assess the probability of a threat and of a vulnerability of being exploited
Determine risk levels and suitable mitigation strategies
Assess risk acceptance criteria and residual risk
Include Threat Model, and any other cybersecurity testing (e.g., static and dynamic code analysis, malformed input (fuzz) testing, vulnerability testing, and penetration testing)

Cybersecurity - Management Plan / Plan for Continuing Support 🔗

Should include:

OTS/SOUP Report 🔗

This report documents all of the off-the-shelf (OTS) software and software of unknown provenance (SOUP) involved in your device.

Provide basic documentation for OTS software, as described in FDA’s 2019 FDA Guidance “Off-The-Shelf Software Use in Medical Devices” Section V. A. This should include:
- Title and manufacturer of the OTS software;
- Version Level, Release Date, Patch Number, and Upgrade Designation, as appropriate;
- Any OTS Software documentation that will be provided to the end user;
- Why this OTS Software appropriate for this medical device;
- What are the expected design limitations of the OTS Software;
- What is the OTS Software intended to do and what are the links with other software including software outside the medical device
Include assessment and information of OTS software hazards in Device Hazard Analysis

Misc. 🔗

Performance/Bench Testing Test Reports (if applicable, does not include software verification and validation)
Literature References (if applicable)
Executive Summary (optional with eSTAR)
- The Executive Summary is very similar to the 510(k) Summary in content. We recommend not creating an Executive Summary, unless you’d like to summarize or clarify anything in the submission that 1) has not been clarified anywhere else and 2) includes confidential information that you don’t want to be part of the public-facing 510(k) Summary.

510k Summary 🔗

The eSTAR gives you two options for the 510(k) Summary:

eSTAR can automatically generate a 510(k) Summary based on the inputted information, OR
The sponsor can attach their own 510(k) Summary (Recommended). If sponsor chooses to create and attach their own 510(k) Summary, the following items must be included:
- Date 510(k) Summary was prepared
- Sponsor information
- Predicate device identification
- Indications for use
- Device comparison table (we recommend including the same one created for the Substantial Equivalence Discussion document)
- Summary of testing, including a discussion for how testing supports SE determination
- Conclusion on SE determination based on safety and effectiveness

Make sure that all provided information is not confidential, as 510(k) summary will be made publicly available after clearance.

Voluntary Standards 🔗

If general use, explain how standard was followed within submission
If declaring full conformity, submit Declaration of Conformity (DOC)

MDUFMA User Fee Form 🔗

Create User Fee account (Note: if you applied for small business determination, you will already have a User Fee account).
Pay 510(k) submission fee (Note: Please be sure to submit your user fee payment at least three business days before submitting, to ensure the payment is processed and your submission is not placed on user fee hold).
Print Coversheet and include in submission.

Truthful and Accurate Statement 🔗

Needed as attachment if primary correspondent is not a company representative. If primary correspondent is company rep, then they can sign truthful and accurate statement in eSTAR.
Perform a comprehensive review of the entire submission to assure completeness, flow and quality goals are met.
- Ensure Indications for Use statement are identical across all submission documents. (At Innolitics, we use Notion synced blocks to ensure we keep this consistent across all our documentation.)
Create a Customer Collaboration Portal (CCP) account.
Submit 510(k) via CCP.

Cybersecurity 🔗

This section includes requirements from the Untitled

Hazard analysis, mitigations, and design considerations pertaining to cybersecurity risks including the following:
- List all cybersecurity risks that were considered in the design of
  your device.
- Provide a list of and justification for all cybersecurity controls that were
  established for your device.
Include a traceability matrix that links your actual cybersecurity controls to the
cybersecurity risks that were considered.
Include a summary describing the plan for providing validated software updates and
patches as needed to continue to assure device safety and effectiveness.
Include device instructions for use and product specifications related to recommended cybersecurity controls appropriate for the intended use environment.

Interoperability 🔗

This section includes 510(k) requirements, as described in the 2017 FDA Guidance “Design Considerations and Premarket Submission Recommendations for Interoperable Medical Devices”.

Quantitative Imaging 🔗

This section includes requirements from the 2022 FDA Guidance “Technical Performance Assessment of Quantitative Imaging in Radiological Device Premarket Submissions”.

This section only applies to devices that generate quantitative imaging values across different radiological imaging modalities, intended uses, levels of automation, and complexity of algorithms.

In the device description or software documentation (e.g., software description) describe the quantitative imaging function.
- This should include level of automation (e.g., manual, automatic, or semi-automatic), information about input data (e.g., target population, limitations), image acceptance activities, information presented to user about the derived values, and the level of intended user interaction.

Technical Performance Assessment 🔗

This information describes how you establish the technical performance of each quantitative imaging function.

Uncertainty Assessment 🔗

The uncertainty assessment should be performed under conditions that reflect the intended use of the device.

For each quantitative imaging function, provide uncertainty information in the units of the measurand.

Labeling 🔗

The labeling should include sufficient information for the end user to obtain, understand, and interpret the values provided by the quantitative imaging function, including the following:

Description of measure and and the units in which it is measured
Description of the algorithm inputs, including any restrictions
Performance specifications, including uncertainty information, that cover the entire operating range of the quantitative imaging function
Instructions for image acceptance or quality assurance activities to be performed by the user
Description of the user qualifications and training needed
Quantitative imaging functions that provide a comparison to a reference database should include information about the composition of the reference database

For details and examples, please refer to the guidance document.

Multi-Function Devices 🔗

This section includes requirements from the Untitled. It only applies if the product has “Other Functions.”

The device description lists the device function-under-review as well as other functions of the device.
- Details the impact of the other functions on the device function-under-review
- For each other function, determine whether there could be an increased risk or adverse effect on the device function-under-review
  - Document risk mitigation for any risks identified related to other functions
In the product labeling, include additional information or limitations related to the other functions of the device
In the cybersecurity risk assessment and/or threat model, include all end-to-end elements of the system, including “other functions”

During 510(k) Submission 🔗

If applicable, implement ISO 13485:2016/USFDA QSR compliant Quality Management System (QMS). This is necessary prior to commercialization in the USA (would not apply if the Manufacturer does not intend to commercialize under their own name (i.e., sell the 510(k) to a 3rd party).
FDA Review Timeline Here’s what to expect as the FDA is reviewing your submission:
- Day 1: FDA receives 510(k)
- By Day 7: FDA sends an Acknowledgement Letter (please note acknowledgement might happen faster with eSTAR)
- By Day 15: FDA conducts Acceptance Review. FDA informs applicant if 510(k) continues to Substantive Review or placed on RTA Hold.
  - If submission is placed in RTA Hold, FDA will grant applicant 180 days to respond to deficiencies.
- By Day 60: FDA conducts Substantive Review. FDA informs applicant if 510(k) continues to Interactive Review or asks for Additional Information.
- By Day 90: FDA sends final decision through SE letter.

After 510(k) Clearance 🔗

Register Establishment with FDA.
List Device with FDA.
Assess and document changes which may have been implemented in the interim between submission and clearance. This will result in a ‘Letter to File’ or possibly indicate that a new submission is necessary.