The electronic Submission Template And Resource (eSTAR) is a great aid for medical device submissions to the U.S. Food and Drug Administration (FDA). The eSTAR is “an interactive PDF form that guides applicants through the process of preparing a comprehensive medical device submission” (https://www.fda.gov/medical-devices/how-study-and-market-your-device/estar-program).
However, the form can lull submitters into unduly delayed cybersecurity work.
For cybersecurity, the eSTAR requires specific outputs from a cybersecurity process. What eSTAR does not require (at least in version 7) is a cybersecurity development-related plan that generates the outputs. This “black hole” may suck you into believing that cybersecurity requirements and controls development can be delayed until before submission.
“You can pay me now, or you can pay me later” … revisited for cybersecurity
“You can pay me now, or you can pay me later” was the punch line of a memorable TV commercial by the FRAM® company about their oil filters around 50 years ago. The “me”: a car mechanic.
Their point: paying (a little) now to replace your oil filter regularly was a far better choice than paying (a lot) later to repair the car.
It’s a great way to remember that there are tradeoffs in business. Medical device development and operation is no different. You can “tradeoff” doing something now and maybe, or maybe not, take care of it later with little added cost/impact. The commercial punch line implies the odds are not in your favor. You will likely pay much, much more later.
An earlier post on this highlighted the tradeoffs and dangers with delaying DHF documentation.
We are finding that companies are also often taking the “pay later” route when it comes to cybersecurity … and sometimes paying much more than if they had done it earlier.
You may pay (a lot) more later with delayed cybersecurity work
Delaying cybersecurity work can cost a lot more at least these reasons:
- A submission will be delayed until the cybersecurity is adequately addressed to fulfill submission expectations.
- Waiting too long or inadequately addressing cybersecurity can lead to device design changes and added development, potentially substantially increasing development cost and submission/time to market.
- A submission will be denied or endure more questions and more scrutiny if cybersecurity is inadequately addressed.
- The submission may get approved, but the device is deficient in some way leading to major reinvestment, recalls, or worse.
- Not being prepared for postmarket cybersecurity issues
Submission delay
The first reason is somewhat obvious … deferring any development activities until just before submission will delay submission and, at best, be a one-for-one increase in time for the time to do the activity.
Increased development cost and added time to market
Delaying cybersecurity activities, especially adding controls, can create a chain reaction of changes “backwards” into design, architecture, and requirements that can create the dreaded “multiplier effect.” The “multiplier effect” is where every development stage affected backwards can increase change cost up to an order of magnitude/10x.
More submission scrutiny than otherwise
The third reason is not as obvious as it seems and is underappreciated. Since cybersecurity has received much emphasis in recent years, reviewers will be very focused on the submission cybersecurity portions. Issues found with cybersecurity, particularly any may appear to have been obvious gaps to a manufacturer prior to submission, may cause broader submission concern. Reviewers may associate a lack of cybersecurity attention with a lack of attention to the rest of the submission. The rest of the submission beyond cybersecurity may then be subjected to more review.
Answering more reviewer questions = more time. Any corrections = more time. Regulator review of corrections = more time. The more review and remediation cycles, the more time. Again, a multiplying effect delaying successful submission beyond just the time to correct any cybersecurity submission issues.
Device deficiency
The fourth reason is a subtle and dangerous one. Creating documentation retrospectively can result in a device being shipped that is unsafe or that has other critical design flaws. Or – all too often – a team inadvertently adds a defect during an update to already released software because the documentation doesn’t provide good support for software maintenance. This is also true for cybersecurity just as for software in general.
For a startup this can be a company killer, but even large companies can struggle after a safety incident. Even if people aren’t harmed, it could take a major investment to redesign the product to a safe state.
Postmarket issues
There are two types of general postmarket issues:
- Not conducting postmarket cybersecurity surveillance and gathering cybersecurity metrics, or doing so inadequately.
- Not being prepared for performing out-of-cycle cybersecurity releases.
Regulators expect (and reasonably so) that manufacturers conduct postmarket surveillance for device cybersecurity just as they are expected to do for device safety and effectiveness. Otherwise, cybersecurity issues may not be corrected or corrected in a timely manner.
Once a manufacturer discovers and assesses a cybersecurity issue, they may need to release a device update out-of-cycle from pre-planned releases. If the manufacturer does not have the processes in place to do so, the first (or several) cybersecurity releases may be later to market than otherwise. This can create problems both from a business perspective (e.g., reputation, legal, sales, etc. impacts) and regulatory perspectives (e.g. audits, recalls, warning letters). This can also expose the manufacturer to safety and effectiveness device issues created by the cybersecurity issue.
From an eSTAR perspective, the FDA intends for the Cybersecurity Management Plan submission deliverable to lay out how manufacturers will accomplish cybersecurity updates and patches. However, we have seen few manufacturers to date with a sufficiently thought through and detailed plan initially that will likely pass regulatory scrutiny and meet business needs.
Need assistance?
SoftwareCPR can help you with cybersecurity work efficiencies. For almost 3 decades, we have helped clients with medical device software development and operation, along with navigating regulations and standards in general.
We can help you with:
- Training. Popular training courses, including for cybersecurity, are listed at https://www.softwarecpr.com/training/, and customized training is available.
- Customized advice. If you need tailored consulting assistance for your specific situation, contact us at https://www.softwarecpr.com/leave-a-message/
- Updates on regulatory, software, and other pertinent matters via our mailing list; join at https://www.softwarecpr.com/join-mailing-list/
