FDA Pre-Subs: Best Practices, FAQs, and Examples

Best Practices 🔗

• Timing
  • Pre-Sub’s may not be valuable if your intended use and device description aren’t set
  • Otherwise, do a Pre-Sub as soon as high-risk regulatory questions are identified
• Question selection
  • Focus on questions that eliminate regulatory or clinical risk. Consider that FDA allows a maximum of 4 topic (e.g., regulatory strategy, cybersecurity) categories
  • Write specific questions that lead FDA to the answer you want
  • Write questions that give the FDA an opportunity to disagree
  • Avoid questions that FDA won’t be able to answer in a Pre-Sub or can be answered using Guidance
  • Make sure you have appropriate supporting information for each of your questions. FDA will not answer questions for which they do not have sufficient information or do not understand
• Pre-Sub Preparation
  • Provide detailed background information for FDA to give accurate answers. See under the Examples section below.
  • Don’t provide extraneous background information
  • When providing background information, not only explain what approach you are using, but also explain why you are not using alternate approaches
  • Use FDA terminology
  • Quote FDA guidance back at the FDA
• The Call
  • Plan out expected FDA questions and responses
  • Keep in mind that FDA Pre-Subs can be somewhat of a negotiation with FDA; there is some give and take
  • Plan who will speak about which questions (we generally suggest having an regulatory consultant run the meeting)
  • Don’t waste time during the meeting on unimportant topics
  • If too much time is being spent on a single question with no end in sight, kindly suggest moving on to another question
  • Don't be afraid to ask the FDA for their reasoning behind certain feedback
  • Don't be afraid to ask for an "informal" follow up via email. FDA can be open to receiving some additional info/answering questions via email after the call

Basic 🔗

What is a Pre-Sub? 🔗

A Pre-Sub is a mechanism for requesting formal written feedback from the FDA, and (optionally) a one-hour meeting.

A Pre-Sub is appropriate when FDA’s feedback on specific questions would help guide product development, performance testing, predicate selection, or other aspects of a 510(k), De Novo, PMA, or IDE submission.

Does a Pre-Sub cost money? 🔗

There is no FDA fee, however, preparing a Pre-Sub package takes significant effort. There is also a 60 - 75 day delay from when you submit your Pre-Sub and when you receive feedback. Time is money, as they say.

How many Pre-Subs are you allowed to do? 🔗

You can do as many as you like.

Can you do multiple Pre-Subs at once? 🔗

Usually no, but if they are on unrelated topics, maybe.

Do you have to do a Pre-Sub? 🔗

No. They are always optional, but surely recommended in most cases.

How do Pre-Sub’s relate to 510(k)s? 🔗

Here is a diagram showing how pre-subs relate to a typical pre-market submission:

We recommend requesting a presubmission meeting with FDA early in the process (e.g., before preparing 510(k) submission, executing testing, collecting data) but once you have a clear regulatory strategy in place.

What is the process for doing a Pre-Sub? 🔗

The typical process looks like this:

1. Prepare the Pre-Sub
   1. Identify key questions
   2. Write intended use, indications for use, and device description
   3. Write any other documentation necessary for FDA to answer questions (e.g., test protocols)
2. Submit the Pre-Sub to FDA (Day 0)
3. FDA provides written feedback (Day 70)
4. Meeting (Day 75)
5. Respond with formal minutes (By Day 90)

If no meeting is requested, then steps 4 and 5 are skipped.

The day of the meeting is mutually agreed upon with FDA, and is typically between 70 and 75 days from submitting the Pre-Sub.

Although the actual timelines for the Pre-Subs can vary and have increased and decreased over time, as of April 2024, we’re seeing that FDA is typically hitting their 60 - 75 Day goals.

Where do Pre-Sub meetings occur? 🔗

We often do them over video calls, however, FDA has started allowing in-person meetings again post COVID.

What content goes into a Pre-Sub? 🔗

Here is a summarized list of content that’s included in a Pre-Sub. Note a lot of this is quoted and slightly modified from the FDA guidance:

• Purpose. The overall purpose of the Pre-Sub including goals for the outcome of the interaction with FDA.
• Agenda. A draft agenda proposing the topics to be presented and the estimated time for each agenda item.
• Preferred Meeting Dates. Three (3) or more preferred dates and times when you are available to meet.
• Attendees. The planned attendees, including each attendee’s position, or title, and affiliation.
• FDA Experts. Any appropriate FDA staff that are requested to attend the meeting if specific expertise may be needed.
• Device Description. Listing of any relevant previous communications with FDA about the subject device An explanation of how the device functions, the basic scientific concepts that form the basis for the device, and the significant physical and performance characteristics of the device.
• Proposed Indications for Use or Intended Use. This should include a description of the disease(s) or condition(s) the device will diagnose, treat, prevent, cure or mitigate, and a description of the patient population for which the device is intended.
• Regulatory History. Listing of any relevant previous communications with FDA about the subject device.
• Planned Follow-On Submission. FDA recommends that you clearly indicate what type of future submission (IDE, IND, CW, Accessory Classification Request, or marketing submission) is the focus of your Pre-Sub questions to help direct FDA’s feedback.
• Background Information. FDA recommends that you include sufficient background information and supporting documents to allow them develop feedback for the Pre-Sub questions you pose. This information might include:
  • literature articles
  • full device description with engineering drawings
  • proposed labeling
  • videos
  • red-lined protocol revisions
  • how you addressed, or plan to address, relevant guidance documents, regulations, special controls, or other applicable sources for your device or submission type.
• Specific Questions. A Pre-Sub should include clear, specific questions to allow FDA and the submitter to focus their efforts on issues most relevant to moving a project forward. You may wish to describe your perspective on the questions you provide FDA to inform FDA’s review.

How do you prepare a Pre-Sub? 🔗

We suggest using the PreSTAR dynamic PDF to compile a Pre-Sub. You can download the PreSTAR template here. Once you download it, you can select the options for a Pre-Sub and then fill in the various sections.

Once you have filled in this information, you can see the detailed fields related to the Pre-Sub.

When is a good time to do a Pre-Sub? 🔗

It is generally too early to do a Pre-Sub if you don’t have a somewhat settled indications for use and device description. Once these are settled, we suggest doing a Pre-Sub about as early as key regulatory risks have become clear.

Do you always do Pre-Subs? 🔗

Unless there are time-constraints for the submission and the regulatory strategy is very clear, we almost always suggest doing a Pre-Sub.

What are typical Pre-Sub subjects? 🔗

At Innolitics, we focus on Software as a Medical Device (SaMD) products. We most typically do Pre-Subs for the following topics:

• Clarifying a regulatory strategy or predicate-device selection
• Requesting feedback on non-clinical or clinical study plans
• PCCP design

In general, we suggest Pre-Subs to de-risk expensive medical-device development activities. Risk is higher when activities are more expensive, take a long time, or there isn’t much FDA guidance on a topic.

What is a Q-Sub? 🔗

The term “Q-Submission” or “Q-Sub” refers to the system used to track a few different types of interactions with FDA. Pre-Sub is a particular type of Q-Sub.

Informational meetings are another useful type of Q-Sub in some cases.

An Informational Meeting is a request to share information with FDA without the expectation of feedback. This information sharing can be helpful in providing an overview of ongoing device development (particularly when there are multiple submissions planned within the next 6-12 months) and familiarizing the FDA review team about new device(s) with significant differences in technology from currently available devices. While FDA staff may ask clarifying questions during an informational meeting, they will generally be listening during the meeting and not prepared to provide any feedback.

You can read more about other Q-Sub types here.

Where can I learn more about Pre-Subs? 🔗

The key FDA guidance is here: 2023 FDA Guidance - Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program

The following podcast episode with Mike Drues includes a lot of great advice for running successful Pre-Subs: June 2021 - Preparing Your Pre-Submission with the Content FDA Wants to See - Greenlight Guru Podcast.

Examples 🔗

Bad Example #1: Too Many Algorithms 🔗

Background 🔗

In a past presubmission meeting, we presented a device with multiple AI algorithms, each targeting different anatomical areas and providing distinct outputs. Our aim was to maximize the meeting's value by seeking FDA feedback on as many algorithms as possible. However, upon receiving the written feedback, we realized this approach had backfired. We had overwhelmed the FDA with information, obscuring the device's overall intended purpose. Consequently, the FDA couldn't address many of our original questions. This misstep forced us to spend a significant portion of the meeting clarifying our device description, workflow, and intended use. Even then, the FDA couldn't offer final recommendations during the call due to their initial lack of understanding about the device.

Pre-Sub Excerpt 🔗

Sponsor Question

Does the FDA have any concerns about the proposed marketing claims and the methods for supporting them?

Official FDA Response
We are not able to answer this question before we fully understand the intended use of your device. Please see the FDA’s response to Question 1, which discusses our current thinking of the functionalities and indications of the device, the choice of predicates, and regulatory strategy currently proposed.

CLIIP Background Information for SaMD 🔗

In one of our recent presubmissions, FDA shared a "CLIIP Questions for Software Review" document with us. CLIIP stands for “clinical, labeling, indications for use, intended use, and performance testing”. This document is a way for the FDA to share informal recommendations to provide some guidance for all the information for a SaMD that may be required for a review of the device.

Below is a copy of the CLIIP questions.

1. Please ensure that your device description addresses as many of the following questions and
   considerations, thinking of the clinical context of your software and how that relates to the intended use, software environment, and the analysis capability of your software.
   1. *Software Environment (Inputs and Outputs):*
      1. What are the major inputs (data, images, measurements, sensors/attachments etc…), and who provides these inputs? What is the format (e.g. questionnaire, image, report, etc…) of the inputs? Are there any specifications that must be met for the SaMD to work with associated hardware? What are the primary outputs, and to whom are they provided? What is the format of the output, and what is the end user or patient expected to do with these outputs?
      2. What is the data or information flow of your device – are inputs provided or outputs delivered locally, via cloud, by disk or drive, wirelessly/RF etc…?
      3. Does, or how does, your software interface with a networked device, any off‐the‐shelf software (medical or non‐medical), cloud or network storage, etc…?
   2. *Analysis:*
      1. Does your software perform an analysis? Please describe the analysis environment [simple rule-based calculations, online administering of a test, AIML, neural network, fixed or adaptive algorithm].
      2. Does it replace any part of what a physician does (e.g. automates steps, triages patients, provides a definite diagnosis or recommends/performs treatment), or does it perform clinical decision support functions? For example, triages priority cases for physician review, identifies region of interest for further review, suggests likely diagnosis but requires confirmation by physician, recommends treatment plan?
   3. *Clinical Context:*
      1. What is the intended use of the software device?
      2. Who operates the software, and who is the patient? Is the user the patient, a caregiver, or a healthcare professional? Does the software focus on a specific disease, condition, or patient characteristic/demographic? Does the software provide information that is directly applicable to a specific disease or condition? How does your software change or support current clinical workflow?
2. How does your proposed testing plan align with how your software is intended to be used?
   1. What clinical evidence have you acquired to demonstrate that clinical performance goals are met?
      1. What published literature or other real‐world evidence exists that supports your
         software’s clinical use?
      2. What modeling/simulation or other alternative methods did you use in lieu of clinical
         testing to support your software’s clinical use?
      3. How do the results of the clinical evidence discussed above align with your software’s intended use and design (#1 above)
   2. How does your proposed non‐clinical testing plan and validation align with your high level
      design requirements? With identified hazards/vulnerabilities?
      1. What bench testing or non‐clinical validation was performed to meet device
         specifications / high level design requirements?
      2. What testing or validation that was performed to address your device’s most significant hazards (identified above) and to mitigate associated risks?
         What testing was performed to ensure that interfacing hardware (sensors, accessories, other systems) successfully integrates with the SaMD?
      3. What testing was performed to ensure that the SaMD communicates with other
         components of the system (e.g. SaMD on one mobile platform communicating with
         SaMD on another platform)? This includes software environment testing for networked devices.
3. How have you considered and addressed your software’s most significant risks or vulnerabilities through your Quality system? Specifically, are there and how have you considered and addressed:
   1. Device‐specific hazards that could change the risk categorization of your software (by
      changing either a) the state of health care situation or condition, or b) the significance of
      information provided by the SaMD to the health care decision)?
   2. Hazards unique to your software based on its clinical or medical use (relating to missed or inappropriate diagnosis, incorrect or delayed treatment, corruption or lost patient data,
      adaptive algorithm impacting clinical intended use or context or introduce new risks, etc..?)
   3. Failures distinct to your software’s use environment (mobile, cloud, short range RF, etc…?)
   4. Hazards of misuse arising from labeling?
4. How does your software’s labeling align with its intended use and the results of your performance testing?
   1. How does your labeling explain or summarize the performance of the software (clinical and/or performance testing endpoints) and the safety and effectiveness of the software?
   2. Depending upon the certainty of the output, are there situations where your software could cross the line between different IMDRF categorizations (informing/driving clinical management/ diagnosing or treating)? If so, how does your labeling clearly identify when such situations could happen and that your software is performing within its intended use?
      1. If applicable, does your labeling clearly identify how your device outputs could
         potentially alter clinical workflow? How does your labeling ensure that the end user will operate to correctly apply outputs according to its intended use?
   3. What information or training will the end user need to have to operate the software as intended (including how to ensure that the inputs are appropriate and that the outputs are used correctly)?
   4. Are your considering making any claims in the future (in labeling or promotional literature) such as:
      1. Claims outside the current stated intended use
      2. Claims not currently supported by clinical or non clinical testing
      3. Claims that change the clinical context of the software (e.g. relating to improved
         treatment, reduced side effects, diagnosis of a disease, etc…)

Revision History 🔗

Date	Changes
2024-04-23	Initial Version
2024-08-22	Added a couple of examples, including the CLIPP questions. Clarified a few of our earlier points.