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.

Here is a word copy of the checklist:

The_Ultimate_510k_Checklist.docx

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:

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:

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.

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:

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:

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:

Risk Management - Cybersecurity Risk Assessment 🔗

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

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.

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.

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.

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.