The Ultimate 510(k) Checklist

 September 06, 2024
SHARE ON

Regulatory

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
  • Identify at least one suitable predicate device
  • Identify any secondary or reference device(s), if appropriate
  • 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 510(k) 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 🔗

This document includes key information for initial processing and review of the 510(k) submission, such as:

  • Sponsor/applicant name (Company name)
  • Type of submission (e.g., Traditional 510(k))
  • Device trade name
  • Purpose of the application
  • Statement for continued confidentiality (21 CFR 807.95)

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.

Pre-Submission Correspondence & Previous Regulator Interaction 🔗

This section identifies any previous interactions with FDA (e.g., presubmission meetings) in reference to the device for which this application is being submitted. If there have been no prior regulatory correspondence, this section can be skipped.

  • Gather copies of any previous regulatory correspondence. This can include the following:
    • Presubmission meeting written feedback
    • Presubmission meeting minutes
    • Document addressing how previous concerns have been addressed in this 510(k) (we recommend doing this in a tabular format)

Standards 🔗

The eSTAR allows for FDA-recognized standards to be selected within the eSTAR.

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

Device Description 🔗

Device Description and Principles of Operation Documentation

This document provides a comprehensive description of your device, detailing its key design features, operating principles, and how it achieves its intended performance.

  • Provide a detailed description of the device. We also recommend including key marketing claims
  • Include key design features for the principle of operation and how performance is achieved
  • Identify all models, as well as any accessories included in the submission
  • Include the Indications for Use statement
  • Describe the intended user(s) of the device
  • Describe the intended patient population
  • Identify any special controls, standards, or guidance documents that are applicable to your 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” that includes the following:

  • A justification for the device not having a physical form
  • System-level architectural chart of the software (i.e., device schematic)
    • Make sure the architectural chart has a legend

Substantial Equivalence Comparison 🔗

This document includes a detailed comparison between your device and the predicate(s) sufficient to demonstrate the substantial equivalence of the devices.

  • Identify your predicate device(s)
  • Compare intended use/indications for use
  • Compare technology (similarities and differences). For any technological differences, explain why these differences do not raise any new questions regarding safety and effectiveness
  • If any reference device has been used to support a difference in technology, include an identification of such reference device and a description of how it is being used to support the substantial equivalence determination
  • Compare performance specifications, including any testing. Describe how testing supports substantial equivalence 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 to.

Labeling 🔗

Labeling material describes the device, its intended use and directions for its use (as appropriate). This can include the product label, user manual and marketing materials.

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

Software Label (About Box)

The software label contains the following items. Ideally, this label should be non-transient and accessible through the software.

  • 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 (this can be a placeholder for new devices)

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 instructions and technical support contact information
  • Manufacturer name and address
  • Symbols glossary
  • Any information required by the special controls or guidance applicable to your type of device
  • Revision history

Marketing Material

  • Include website information
  • Intended marketing claims

Software Documentation 🔗

This section contains software documentation as recommended by 2023 FDA Guidance - Content of Premarket Submissions for Device Software Functions.

Software Description 🔗

This document includes an overview of software features and functions, including details on programming language, operating system, and use of off-the-shelf software. For ML-enabled devices, provide detailed descriptions of algorithms, model development and training.

  • Identify device features that are controlled by the software, the programming language, hardware platform, operating system, and use of OTS software (if applicable)
  • Identify the software version being released, as well as the version that was used for verification and validation. 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 the device interfaces 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

Risk Management File 🔗

The risk management file includes the risk management plan, risk assessment (e.g. hazard analysis), and risk management report.

Risk Management Plan

This document describes your plan for identifying risks and evaluating them.

  • Describe the personnel responsible for risk management activities
  • Describe methods for identifying risks (e.g., MAUDE database search, FMEA, etc.)
  • Describe your risk acceptability criteria, including definitions of different levels of risk severity and probability
  • Describe how the need for risk control methods (RCMs) will be determined
  • Describe how acceptability of the overall residual risk will be evaluated
  • Describe methods of obtaining production and post-production information

Risk Assessment (e.g., Hazard Analysis)

This document describes 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, pre- and post-implementing RCM
  • Probability of occurrence, pre- and post-implementing RCM
  • Evaluation of risk acceptability, pre- and post-implementing RCM
  • Risk control method (RCM)
  • Verification that the method of control was implemented correctly (e.g., traceability to verification activities)
  • Assessment of whether risk control measures introduce new hazards or hazardous situations or impact the initial risk evaluation
  • If your device includes “other functions” or OTS, the risk assessment should these
  • Identify personnel who completed risk assessment

Risk Management Report

This document summarizes the risk assessment and demonstrates that the risk management plan was properly implemented.

  • Demonstrate that the overall residual risk is acceptable
  • Demonstrate appropriate methods are established for the collection and assessment of
    production and post-production information
  • If any residual risk is deemed “not acceptable” and further risk control is not possible, document a benefit-risk analysis

Software Requirement Specification (SRS) 🔗

This document describes 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
  • Include cybersecurity requirements, including:
    • Authentication controls
    • Cryptography controls
    • Code, data, and execution integrity controls
    • Confidentiality controls
    • Event detection and logging controls
    • Resiliency and recovery controls
    • Firmware and software update controls
  • Format the SRS to be well-organized, easily readable, and traceable

System and Software 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
  • Describe how users or major external products interact with the system and software
  • 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 document 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 510(k) 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”.

Software Life Cycle Process Description / Software Development, Configuration Management, and Maintenance Practices 🔗

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.
  • Software version naming rules
  • 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

Software Testing as Part of Verification & Validation 🔗

Provide verification and validation testing protocols and reports. We also recommend providing a standalone document that summarizes all of the V&V activities.

Verification

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)
  • For system level tests, provide a protocol and report that includes:
    • Expected results
    • Actual results
    • Pass/fail determination
    • Identification of any unresolved anomalies discovered during testing

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 discovered during testing

Additionally, we recommend the following should be included:

  • Date of completion
  • Person who completed it
  • Traceability between requirements and verification activities

Validation

Provide detailed protocol(s) and report(s) that include:

  • Test steps
  • Expected results
  • Actual results
  • Pass/fail determination
  • Date of completion
  • Validation participants and their qualifications
  • Traceability between user needs and validation activities
  • Identification that validation was conducted on a production equivalent version of the device

Traceability Analysis/Matrix

We recommend providing a standalone document that shows traceability between the following:

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

Software Version / Revision Level History 🔗

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

  • Version number
  • Release date
  • 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, including safety and cybersecurity
  • Risk-based rationale for not correcting the anomaly for this release
  • Include consideration of any present Common Weakness Enumeration (CWE) categories (cwe.mitre.org)

Cybersecurity 🔗

This section contains cybersecurity documentation as recommended by 2023 FDA Guidance - Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions

Cybersecurity Management Plan 🔗

This document should:

  • Identify the responsible personnel
  • Identify and address vulnerabilities identified in CISA Known Exploited Vulnerabilities Catalog (www.cisa.gov/known-exploited-vulnerabilities-catalog)
  • Describe any periodic security testing
  • Describe availability of post-market 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)
  • 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
  • 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)
  • Describe how forthcoming remediations, patches, and updates will be communicated to customers

Risk Management - Cybersecurity Risk Assessment 🔗

The cybersecurity risk assessment document should be separate from the safety risk assessment process.

  • 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
  • Identify security controls
  • Determine risk levels and suitable mitigation strategies
  • Assess risk acceptance criteria and residual risk
  • Include a Threat Model that includes the following:
    • Threat model methodology and a rationale for selecting such methodology
    • Description of threats
    • Sequence of events leading to threat
    • Description of any mitigations or risk controls

Risk Management - Report 🔗

Provide a security risk management report document that includes the following:

  • Risk analysis, mitigations, and design considerations for cybersecurity risks
  • Traceability between security risks to security controls
  • Traceability between security controls and verification activities
  • A description of when and how security updates/patches will be provided
  • A description of the steps taken to assure devices will be delivered malware-free
  • Document the residual risk conclusion

Software Bill of Materials (SBOM)

The following should be provided for an SBOM:

  • Manufacturer-developed components as well as third-party components, including package name, version number, license(s), format
  • Provide the software level of support and end-of support date for each component identified in the SBOM. For any component where this information was not available, provide a justification
  • Provide SBOM in machine-readable format
  • Provide SBOM in human-readable format

Security Assessment of Cybersecurity Vulnerabilities

We recommend providing a vulnerability report that includes:

  • An assessment of each known vulnerability
  • Details of any security or safety risk controls to address the vulnerability

Cybersecurity Metrics 🔗

This document should include data from monitoring cybersecurity metrics.

  • Percentage of identified vulnerabilities that are updated or patched (defect density)
  • Duration from vulnerability identification to when it is updated or patched
  • Duration from when an update or patch is available to complete implementation in devices deployed in the field, to the extent known
  • If metric data are unavailable, provide a justification

Cybersecurity Controls 🔗

The following categories of cybersecurity controls should be identified and documented, as appropriate. We recommend including them as part of your software requirements, and referencing them in the Security Risk Assessment.

  • Authentication controls
  • Authorization controls
  • Cryptography controls
  • Code, data, and execution integrity controls
  • Confidentiality controls
  • Event detection and logging controls
  • Resiliency and recovery controls
  • Firmware and software update controls

Architecture Views 🔗

Diagrams and explanatory text should be provided for the following cybersecurity architecture views:

  • Global System View
  • Multi-Patient Harm View
  • Updatability/Patchability View
  • Security Use Case Views

Cybersecurity Testing 🔗

Cybersecurity testing may include to security requirement testing, threat mitigation testing, vulnerability testing, and penetration testing.

  • For any performed testing, provide a description of the testing performed and test reports
  • For any third-party testing, provide the original third-party test report as well as your assessment of the findings
  • For any particular tests that were not performed, provide a justification

Cybersecurity Labeling 🔗

Cybersecurity labeling can be provided as a standalone document, or as part of any user or operator manual. This may include:

  • Recommended cybersecurity controls appropriate for the intended use environment (e.g. anti-malware software, use of a firewall, password requirements)
  • List of network ports and other interfaces that are expected to receive and/or send data
  • Supporting infrastructure requirements so that the device can operate as intended (e.g. minimum networking requirements, supported encryption interfaces)
  • Description of how a machine-readable SBOM can be obtained by users
  • Instructions on downloading and/or installing software, as well as details on how users will know when a new release is available
  • Information on securely decommissioning devices

Interoperability 🔗

This section includes 510(k) requirements, as described in the 2017 FDA Guidance “Design Considerations and Premarket Submission Recommendations for Interoperable Medical Devices”. We recommend providing this information as part of the Software Description document.

  • Identify and describe 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.

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 the Risk Assessment

Performance Testing 🔗

This section should include any bench, animal or clinical testing included in submission. It does not include software verification and validation. We typically skip this section in the eSTAR, as for SaMD, most of the times testing will go under the Software Documentation section.

  • Provide any test protocols and reports.

References 🔗

  • Gather any literature references used to support the submission
  • Provide a description of how each reference supports the submission

Administrative Documentation 🔗

Executive Summary 🔗

  • The Executive Summary is optional and 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.

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.

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.

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.

Special Considerations 🔗

The following subsections describe special considerations for specific types of devices.

Quantitative Imaging Devices 🔗

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.

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

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

Predetermined Change Control Plan (PCCP) 🔗

This section applies to devices that include a predetermined change control plan for future device modifications. It includes high-level requirements from 2024 FDA Guidance - Predetermined Change Control Plans for Medical Devices.

Components of a PCCP

The following components should be included in a PCCP:

  • Description of modifications
  • Modification Protocol
  • Impact Assessment

Identifying a PCCP in the Submission

If including a PCCP in your submission, the following documents should describe it:

  • Cover letter, should prominently identify and discuss PCCP
  • Device Description
  • Labeling
  • Any other relevant relevant sections used for determining substantial equivalence or reasonable assurance of safety and effectiveness

Final Review and Submission 🔗

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
  • Create a Customer Collaboration Portal (CCP) account
  • Submit 510(k) via CCP

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 a technical screening hold
    • If submission is placed on a 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.

Revision History 🔗

Date Summary of Changes
July 9th, 2023 Initial release
September 6th, 2024 1. How We Made this Checklist: Removed reference to obsolete 2019 FDA Guidance “Format for Traditional and Abbreviated 510(k)s”; Added reference to 2023 FDA Guidance - Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions; Added reference to 2024 FDA Guidance - Predetermined Change Control Plans for Medical Devices.

2. Regulatory Plan: Separate checkboxes for intended use and indications for use; added checkbox for considering a reference device.

3. Cover Letter: Added checkboxes with high-level requirements.

4. Updated section and document names to comport to latest eSTAR naming conventions.

5. Added section for Risk Management File, and broke it down into three necessary documents. Added checkboxes for each document.

7. Software Testing as Part of Verification and Validation: Broke down into verification and validation. Cleaned up verification section and added more details to validation section.

8. Cybersecurity Management Plan: Added text boxes to cover specific recommendations in eSTAR.

9. Cybersecurity: Added subsections for new eSTAR sections (Cybersecurity Testing, Cybersecurity Metrics, SBOM, Architecture Views, Risk Management Report) as well as relevant checkboxes.

10. Cybersecurity, Risk Management - Cybersecurity Risk Assessment: Added details for threat model.

11. Added section for Performance Testing, References, Administrative Documentation to comport with eSTAR.

12. Added section for PCCP, and added high-level checkboxes.

13. Added a Special Considerations section to bucket some specific sections that are not always applicable, such as Quantitative Imaging, Techincal Performance Assessments, Multi-function Devices and PCCP.

14. Replaced “RTA hold” with “technical screening hold” per new eSTAR process.

Get To Market Faster

Subscribe to Read the Full Article

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

SHARE ON
×