Why Early FDA Engagement Is Make-or-Break for Medical Device Startups

 

For many medical device startups and early-stage companies, the moment of reckoning comes when they’re ready to submit to FDA, only to discover they’re not actually ready at all.

 

No documented requirements. No risk file. No controlled manufacturing processes. Just a prototype that works and a timeline that’s about to blow up.

 

Jessica Schafersman, Subject Matter Expert at Regulatory Compliance Associates, sees this scenario play out regularly. Companies come to her thinking they’ve reached the finish line, when in reality, they haven’t even completed design verification and validation.

 

The result? Extended timelines, unexpected costs, and sometimes even design changes that could have been avoided with earlier planning.

 

MD+DI connected with Schafersman to break down the critical missteps that derail device development, and offer a roadmap for integrating FDA compliance from day one.

 

She discusses when and how to leverage FDA’s pre-submission programs, why regulatory strategy must be established before design inputs are defined, how to build design controls and risk management into the concept phase, and what foundational QMS elements companies should prioritize before putting pen to paper.

 

She also addresses clinical evidence planning, the most common documentation mistakes, and why buying procedures off the shelf—or worse, letting AI write them—is a recipe for compliance failure.

 

Watch the full video interview above.

 

Can you share an example of a situation where a company came to you late in the development process and might have faced significant setbacks? What could they have done differently from the beginning to prevent that?

Schafersman: It’s not uncommon. Clients will frequently come to us thinking that the device has been developed. They’ve got something that works, and they usually will come to us when it comes time to either draft the submission or figure out what testing is necessary for submission. They don’t realize that at the stage they’re at, they’re not actually ready for design verification and validation yet. They haven’t established controlled manufacturing processes. They don’t even have documented requirements or a risk file. They tend to not take the news very well that they haven’t gotten to the phase where they’re ready to do testing for submission yet. The timelines for submission, when that happens, is much longer than they expect. And there’s a bunch more cost that they have to incur that they weren’t ready for. And more development too. Sometimes we even have to make design changes to do things for them. The best advice is if your company doesn’t have a background in medical device development or experience, find someone who does to teach you the product realization process that’s outlined in ISO 1345 and the design control methodology. It’s not the kind of thing you can just wing or teach yourself.

 

FDA offers several pre-submission programs like Q-submissions and pre-sub meetings, can you explain when and how manufacturers should leverage these tools and what kind of feedback they can realistically expect from FDA?

Schafersman: From a product development perspective, there’s usually two main reasons you would do a pre-sub or a Q-sub. One is for your regulatory strategy. The other is commonly for your testing strategy. If you’re asking about your regulatory strategy, like you’re not sure of your device classification or if the predicate you found is accurate, earlier is better. Go into them as soon as you think you’ve got an idea and you can describe the device to them because your regulatory strategy, what your classification is, which sections of the CFR apply, those types of things are going to inform your design input requirements, which is step one. It’ll also inform manufacturing strategy, and can impact your supply chain decisions. But it will also have an impact on the testing strategy. So, very early on, ask if you’ve got the right device classification, ask for regulatory strategy, ask if you’ve got an appropriate predicate identified, and they will give you some solid yay or nay type of advice. If you’re asking about your testing strategy, it’s going to depend on how far into product development you are. If you’re fairly far into product development and you’ve got protocols that you can give them and say, is this sufficient to get you the data that you need? Especially for things like design verification testing or human factors validation, you will get really specific advice back from FDA, very clear guidelines. If you’re earlier in the product development and you’re giving them a plan of what testing you need to do, or you’re proposing a bracketing approach for how you’re selecting your samples or something like that, the feedback you’ll get will be less definitive. You’re going to get responses like ‘the proposed plan appears to be acceptable,’ which, you know, they can change their mind on later. So it’s not always the most valuable advice, but sometimes it just gives you enough of a push and enough guidance to get you to the next step of development.

 

Is there such a thing as being too early to engage with FDA? At what stage do you think companies should first start taking those steps?

Schafersman: With FDA, or at least with a regulatory professional, you need to know your regulatory strategy before you really get into design and development. Early is mandatory. You will not make the right decisions. You cannot go down the right path if you don’t have an accurate regulatory strategy set up from the beginning. So there is no too early when it comes to determining the proper regulatory strategy. They’ll give you the right product codes, device classifications, what type of submission you have to submit. Is it going to be a 510k? Is it going to be a PMA? Are you going to have to do clinicals? Things like that. You do that very first thing.

 

There is no too early for that. If there’s any uncertainty in any of these, don’t rely on any Joe Schmo regulatory professional. Go straight to FDA. But for the most part, regulatory professionals can help you nail these things down without having to engage FDA. It’s just going to depend on how novel your device is, how much you know about it, and what information there is out there about it.

 

Let’s talk about design controls and risk management. How can manufacturers build FDA requirements into their design and development process from the concept phase? And what do you think that this integration really should look like?

Schafersman: I want to be careful about saying FDA requirements for design and development because FDA does not give you your design requirements. They spread it kind of all over the place. It’ll be in other approved 510Ks, guidances, consensus standards, and predicate information. It’s even in literature or it’s stuff you can get through pre-subs and questions like that. So you need to ensure that you’re assessing all of these, gathering them all together, and that you don’t miss any or forget any, because these are all sources for your design input requirements.

 

We probably don’t need to be worried too much about FDA requirements when we’re in proof of concept. The first thing you’ve got to do is prove that you can do what you expect to do with this device. This device can, is capable of doing the thing we need it to do. But then as soon as we get out of proof of concept and we’re into early design and development, the first thing we do is planning and inputs. And inputs come from all that FDA input, all the input out there about predicates, everything else that I mentioned. So when you learn through all that research that something is necessary for this device, you may get a design input requirement. And all design input requirements require verification evidence; design verification evidence. And so that helps lead you to an appropriate testing strategy and a plan that you can actually follow for development. When you know what testing you need and you know what your acceptance criteria will be, the design and development process goes much more smoothly.

 

So if you find that the predicate you’ve identified tested X, Y, and Z, you know you are going to have to test X, Y, and Z unless you have some reasonable justification not to. And you’ll need to have requirements for X, Y, and Z. And hopefully those requirements will have acceptance criteria associated with them. And those could come from standards. They might come out of the predicates submission summary. They might come from development work that you have to do to establish what those acceptance criteria are. But knowing that it’s a requirement up front, based on all this research and all the various inputs from FDA, we will make sure that you don’t let it fall off the page. You won’t forget about it somewhere during the development. FDA will list in special controls, things you have to have in your labeling, a warning for this, that, or the other thing. You need to know that. So you make a design requirement that the IFU must contain this warning. And if the CFR lists risks that are known to exist around a device, those risks have to go in your risk assessments. And those risk assessments have to tie to your design input requirements. So when you’re following the 14971 risk management process, you’re assessing the risks. It’s also going to help you identify more requirements you have. I mean, long story short, a complete and thorough identification of your design input requirements is the best way to have a predictable path to FDA submission.

 

Outputs and risks, and risks are connected to inputs and outputs, and verification testing is connected to inputs and outputs and risks. And so it all connects together, and it’s a big loop back on itself, over and over and over again. Everything needs to work together. And that’s what FDA expects you to be able to demonstrate in your design control documentation. That is the FDA requirement. So really, there’s no one way to do it, but there’s a lot of ways to do it wrong.

 

Clinical evidence requirements can be one of the biggest surprises for device manufacturers. How early should companies be planning their clinical strategy, and how can early FDA engagement help to shape that approach?

Schafersman: If there is any question in your mind as to whether or not you may need to do a clinical trial, you do an early pre-sub and ask FDA. Knowing early in the development process if you’re going to have to do clinicals is very important. Clinical trials are expensive and they’re long and it isn’t directly related to the class of the device. You can’t say because this is a class 2 device or because this is a class 3 device, I’m going to have to do a clinical. That just isn’t true. So having the regulatory strategy that we’ve already talked about up front will help with this. But also it’s just critical that you can build it into your development plan so you know when the clinical can start. Because frequently you won’t have to be fully completed with design, verification, and validation to start a clinical. So those two things can overlap somewhat in the development process. And that can save months of work and a lot of extra cost too. If you’re able to plan it from the beginning and overlap it where it’s possible, it would make a huge impact on your development plan.

 

QMS and design history files are critical for FDA submissions. What are the foundational elements companies should be building from day one? And what are the most common documentation mistakes that you see that you think could have been avoided if companies were planning earlier?

Schafersman: Document and records control procedures, a design control or product realization process procedure, and a risk management procedure are your three top priorities when you’re just starting out with medical device development. Without those in place, none of the work that you do to develop the device will be properly controlled or stored or revision historied or any of that. And you might have to start all over again with your documentation efforts. So as the manufacturer of record, the person who is submitting or the company who is submitting the device, you have to have evidence that you own and control the design of the medical device. And you do that through controlled documents, which is why you need the document and records control procedure, and by following your design control or product realization SOP. So all the documents you create through the development process need to comply with those procedures. And you need to be able to demonstrate that when you file the submission. So getting those three in place up front before you begin putting things down on paper will go a long way to making sure what you have when you’re ready for submission is all applicable and works.

 

If you personally were advising a startup or early-stage medical device company that’s just beginning product development, what would your roadmap look like for integrating FDA compliance from the ground up?

Schafersman: If you have the time and resources, the best thing to do is to take the time to develop reasonable standard operating procedures, SOPs, for 1345 and CFR compliance that your company can follow. Don’t buy a bunch of procedures off the shelf, or let AI do it, God forbid. But ensure it’s customized to the way your business functions and that it’s compliant to the standards and the CFR. And it’s something that you can read and understand well enough that you can follow it and maintain it. And then all you have to do is follow your procedures. You don’t have to do a bunch of external stuff to make sure that you’re compliant. If you get good procedures in place up front and you follow those procedures throughout the process, then you’re doing it the right way from the beginning. And it should be easy to be compliant to FDA.