Of course you do! You can scroll through this FAQ list to find answers to common questions. If you have more questions, send them to me via my Ask Me Anything form below.
No, you do not need to open a business in the US to get a product approved by the FDA. They do ask that every non-US company appoint a US agent, which is essentially someone who officially resides in the US (but does NOT have to be a US citizen) so that they can receive mail from the FDA and help them arrange any logistics (e.g., scheduling inspection requests, etc.). This person does not take on any responsibility for product compliance. It’s as if the FDA is super cheap and wants to avoid having to pay for international postage and long-distance calling rates.
See 21 CFR 807.40 for more information.
You can (and should) meet with the FDA before submitting a De Novo request (assuming your device is nearing its final design and you want feedback on your path forward). The FDA provides this service free of charge! You’ll need to follow the FDA’s “Q-Submission / pre-submission meeting” rules.
You will need to prepare a package that includes a description of your device, its intended use, how it works, and any similar devices that might already exist. The FDA expects you to outline your testing plans, risk controls, and even draft labeling if available. Most importantly, you should include a clear list of questions you want the FDA to answer. Think of it as giving them a meeting agenda so they know what kind of feedback you are asking for.
You also need to propose a few possible meeting dates, usually about two months out. Attach any supporting documents, such as draft protocols or data tables, so the FDA can review them ahead of time. During the meeting you may present slides, but nothing should come as a surprise. After the meeting, you are responsible for drafting the minutes and sending them back to the FDA within fifteen days.
The FDA will first review your request before agreeing to the meeting. If your design is too early stage or your questions are too vague, they may ask you to wait until you have more details ready. The more specific and organized your request, the more useful the meeting will be.
An FDA product code is a 3-character alphanumeric label that categorizes devices based on their intended use and technological characteristics for the purpose of classification and review. You can look up product codes in the FDA product database. Since the FDA regulates devices based on the idea of equivalence (i.e., “show us that you are mostly equivalent to another marketed device and we’ll let you market your product.”), I suppose they thought it would be helpful to classify each type of device that’s out there (again, by intended use and technological characteristics). If you are manufacturing yet another blood pressure cuff, you’ll get the ‘blood pressure cuff code’ (or DXQ). If you are manufacturing a pressure cuff that is intended to measure, I don’t know, muscular resistance (making that up), then you would need a new product code. If you are manufacturing a blood pressure cuff that uses ultrasonic compression (again, making this up), then you’d need a new product code as well.
Why should you care about product codes? Well, for one, if there’s not one out there already that aligns with your product, you’ll likely have to use the De Novo pathway (assuming you are not risk class III). If there is one out there that aligns with your product, then you learn right away the expected requirements for marketing your product in terms of special controls. The product code will also tell you a lot about whether you can leverage the 510(k) route – and even if your product is 510(K) exempt (though very unlikely in the case of digital health products).
So it’s worth exploring your device’s likely product codes. You can figure out which product code aligns with your device by entering the name of a similar device into the FDA product database. You can skim all the product codes under the medical review panel best aligned to your product (also via the FDA product database).
Also, the FDA’s “Policy for Device Software Functions and Mobile Medical Applications” guidance discusses how software device functions are regulated and how those functions should map to regulatory constructs (including product codes). That’s definitely worth checking out.
Really. If you have a question, submit it through this form. I will try my best to respond within a business day. Good questions will get featured on my FAQs list.
Still have questions after exploring? Set up a quick meeting with me here.