What is eSTAR?

In parallel with issuing the RTA guidance, the FDA announced in June 2023 their pilot program for the Electronic Submission Template and Resource (eSTAR) mechanism for submitting 510(k)s and de Novo submissions. The pilot program is currently a voluntary process; however, starting Oct 1st all 510(k) submissions to Center for Devices and Radiological Health (CDHR) must be submitted as electronic submissions using eSTAR.

What is the eSTAR pilot program?

The eSTAR is an interactive PDF form that guides applicants through the process of preparing a comprehensive medical device submission. This program aims to enhance the “incoming quality of submissions for a wide range of medical devices by helping to ensure submitters provide quality, comprehensive data for premarket review” (FDA eSTAR program). Standardizing the process and format of submissions will enable efficiencies around the submission premarket review process, with the end goal of getting higher quality devices to market in a timely manner.

Why is this important?

In June 2023 the FDA released final guidance about eSTAR, but it hasn’t been framed in the same context as the RTA guidance. While the FDA issued this RTA guidance stating they will not start refusing to accept as of October 1, it’s actually not quite like that. The eSTAR template does not let a company submit to the FDA until the template has been completely filled in. The eSTAR requires the completion of all relevant cybersecurity information, such as identifying electronic interfaces. So theoretically, the eSTAR “refuses to accept” on behalf of the FDA because the applicant failed to identify something that they should have.

Due to the use of automatic verification, the FDA does not intend to conduct a Refuse to Accept review for submissions submitted as an eSTAR. They’re not going to Refuse to Accept because eSTAR is supposed to do it for them. But it gets even trickier. FDA will employ a virus scanning and “technical screening process” for each eSTAR they receive. Obviously, that’s FDA’s Cybersecurity diligence. The technical screening process lets them say, “oh, you told me you have no electronic interfaces, but right here you’re telling me you have USB, which is an electronic interface. You failed to submit any Cybersecurity documentation. We’re going to put your submission on hold.” So, if the eSTAR submission is not complete when submitted, FDA will notify the submitter by email, identify the incomplete information, and the submission is placed on and will remain on hold until a complete replacement is submitted.

What does this mean for you?

There’s not exactly going to be an RTA for Cybersecurity for 510(k)s come October. The RTA guidance doesn’t even point to this, but there’s going to be a mechanism either way by which FDA can say, you should have told us about this. You didn’t. We’re not reviewing it.

RTA has real teeth, and that’s really because the FDA has statutory authority written for the administration now. In the past, the agency has made recommendations. That’s what guidance documents are. They are a set of best practices, things that the FDA recommends, but you can always push back and contextualize for the regulator. That leads to a long cycle of the FDA showing why they disagree and trying to leverage the quality system regulation to demand the information they’re asking for. Manufacturers can’t push back with reviewers now because it’s no longer guidance, it’s not a set of recommendations. It is a set of statutory requirements, period.

The RTA guidance itself says, hey, we’re going to bring this to the table and enforce it starting in October at the Refuse to Accept point, rather than doing it interactively, which started in March, they’re going to be issuing deficiencies. The FDA will issue hold letters and files are going to come to a stop and go back to manufacturers. It’s a full stop. Cybersecurity is a requirement, and that’s really important to accept. It takes the burden off FDA reviewers to give a solid explanation through risk management principles and puts the requirement back on the manufacturer to design devices with security at the core.

‍