The Ultimate 510(k) Checklist

 July 09, 2023


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 🔗

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:

  • Table of contents
  • Indications for use
  • Contraindications
  • Intended user and user training
  • Intended patient population
  • Device description
  • Warnings and precautions
  • Operating information and instructions
  • Setup instructions, including software installation
  • Troubleshooting information (including work-arounds for unresolved anomalies)
  • Symbols glossary
  • Any information required by the special controls or guidance applicable to your type of device

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:

  • Related hazardous situation
  • Cause(s) of the hazard (e.g., sequence of events)
  • Severity (should include a definition of all severity levels)
  • Risk control method (RCM)
  • Probability of occurrence, pre- and post-implementing RCM
  • Evaluation of risk acceptability, pre- and post-implementing RCM
  • Verification that the method of control was implemented correctly
  • Assessment of whether risk control measures introduce new hazards or hazardous situations or impact the initial risk evaluation
  • If any residual risk is deemed “not acceptable” and further risk control is not possible, document a benefit-risk analysis
  • If the device includes “other functions”, the risk assessment should include the results of a risk-based analysis of any potential adverse impact or labeled positive impact of these functions.

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:

  • Describe processes, procedures, and deliverables that are part of the software development, verification, and validation.
  • Describe coding standards, methods, and tools used in software development.
  • Describe processes, procedures, and tools used for the Traceability Analysis.
  • Describe configuration or change management.
  • Describe processes and procedures used in software maintenance that includes risk assessment of software changes, initial testing, and regression analysis and testing.
  • 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.1, Software development plan
    • 5.1.2, Keep software development plan updated
    • 5.1.3, Software development plan reference to system design and development
    • 5.1.6, Software verification planning
    • 5.1.7, Software risk management planning
    • 5.1.8, Documentation planning,
    • 5.1.9, Software configuration management planning
    • 6, Software maintenance process
    • 8, Software configuration management process

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:

  • Provide a summary description of the testing activities at the unit, integration, and system levels. This should include:
    • Identification of the software version tested
    • Overall pass/fail test results for all test protocols
    • Description of the test configuration (including hardware and operating system)
      • Confirm this configuration is the same as the one recommended in your User Manual. If there are any discrepancies, make sure to justify them.
  • Describe any intentional changes made in response to failed tests
  • Provide a regression analysis and regression testing with test results to account for unintended effects of a software change (if applicable).
  • Provide a system level test protocol and report including:
    • Expected results
    • Actual results
    • Pass/fail determination
    • Identification of any unresolved anomalies

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:

  • Mechanisms to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including sources and agreements in place for discovery of cybersecurity vulnerabilities
  • Controls in place for maintenance of integrity of device software (e.g., malware-free status) from the point of origin to the point at which that device leaves the control of the manufacturer.
  • Availability of postmarket updates and patches to the device and related systems on risk-based timelines, i.e.,:
    • A reasonably justified regular cycle (to address known unacceptable vulnerabilities)
    • As soon as possible out of cycle (to address critical vulnerabilities that could cause uncontrolled risks)
  • Methods for validation and secure delivery of updates, including update/delivery mechanism(s) associated with firmware/software updates including for each mechanism and the controls on the software update process to prevent malware intrusion.
  • Frequency of periodic re-evaluation of device cybersecurity and delivery of updates and patches, including assessment of update delivery capabilities (e.g., X updates delivered in Y timeframe).
  • A coordinated vulnerability disclosure as an element of an effective postmarket cybersecurity program
  • Processes for handling end of service for your device and end of life for any 3rd-party software (including OS and antivirus updates).
  • SBOM may be included as a “Cybersecurity Management Plan / Plan for Continuing Support” attachment in the eSTAR (Note: Please ensure to include a human-readable version of the SBOM).

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”.

  • Define all electronic interfaces (EIs)
  • Provide the following information for all of the electronic interfaces:
    • Purpose of the EI within the interoperable system, including if the EI is meant to transmit, receive, or exchange information.
    • Anticipated users, clearly stating if the EI is meant only for manufacturer use.
    • Limitations, contraindications, precautions, and warnings.
    • Anticipated devices, clearly state if the EI is meant only for use with specific devices.
    • Standards used (if any) pertaining to the EI (e.g., ISO 14971 for Risk Control measures).
    • Requirements for timeliness and information integrity (e.g., sample rate, transmission rate).
    • Communication format, rate, and transmission method.
    • Functional and performance requirements.
    • Application Programming Interface (API), if the device or its component is software that can be used by other software, medical device, or system.

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.

  • Define the quantitative imaging function, its relationship to the measure and the use conditions.
  • Determine an appropriate reference standard and the performance metrics applicable to your device.
  • Characterize the performance of the quantitative imaging function under the conditions defined in the device labeling.
  • Define the experimental unit (e.g., per lesion, per patient).
  • Define the appropriate statistical estimates of performance (e.g., limits of agreement, total deviation index).
  • Define acceptance criteria.
  • Specify the elements of the statistical design, the necessary data, and the statistical analysis plan, based on the selected performance metrics.
  • Collect the relevant data.
  • Perform the statistical analysis.
  • Compare the analysis results to the pre-defined acceptance criteria.

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.

Get To Market Faster

Subscribe to Read the Full Article

Our monthly Medtech tips will help you get safe and effective Medtech software on the market faster. We cover regulatory process, AI/ML, software, cybersecurity, interoperability and more.