FDA Unveils Plan for 'Software as a Medical Device' ReviewAgency Says It Would Assess Vendors' 'Cybersecurity Responsibility'
The Food and Drug Administration is proposing to pre-certify vendors of certain medical device software, including various mobile apps, allowing the companies to skip the agency's much more rigorous pre-market approval process for hardware-based medical devices.
The proposed voluntary program is for review of "software-as-a-medical-device" products, or SaMD - software that is "intended to treat, diagnose, cure, mitigate or prevent disease or other conditions." Today, such software faces the same regulatory review as medical device hardware.
Examples of SaMD range from software that allows a smartphone to view images obtained from a MRI for diagnostic purposes to computer-aided detection software used to help detect breast cancer.
The FDA says its current regulation of medical device hardware "is not well-suited for the faster, iterative design, development, and type of validation used for SaMD," according to the agency's draft "working model" document spelling out its proposals.
The draft pre-certification proposal comes as the agency is also seeking additional authorities and funding from Congress to advance cybersecurity of medical devices in general (see FDA Proposes Action to Enhance Medical Device Cybersecurity).
The FDA's proposed SaMD pre-certification program looks to evaluate the specific practices and organizational cultures of vendors that would voluntarily seek to be part of the program. A SaMD vendor's "cybersecurity responsibility" is one of five areas of excellence that the FDA would assess for participating in the pre-certification program.
Some security experts say the FDA's proposed plan could help promote innovation, but they stress that the agency must keep a close eye on vendors' cybersecurity practices to ensure patient safety.
The FDA initially announced plans for the SaMD vendor pre-certification program in 2017.
Last September, it selected nine technology companies to participate in a pilot to help develop the program: Apple, Fitbit, Johnson & Johnson, Pear Therapeutics, Phosphorus, Roche, Samsung, Tidepool and Verily.
The pre-certification program is a component of FDA's Digital Health Innovation Action Plan to "modernization to regulation of digital health," the agency said in statement issued Thursday.
"Our Digital Health Software Precertification Pilot Program ... provides our vision for the pilot while asking for specific input from our stakeholders to allow us to continue to improve this innovative program," said FDA Commissioner Scott Gottlieb, M.D.
The FDA's software pre-certification program would enable a more streamlined review of SaMD products. The draft working model - for which FDA is seeking public comment until May 31 - outlines the most critical components of the pilot. That includes pre-certification of companies, the pre-market review process and post-market surveillance.
The approach is intended to enable more efficient and streamlined oversight without compromising safety and effectiveness of SaMD products, the FDA says.
Under the program, SaMD developers would be assessed by the FDA or an accredited third party for the quality of their software design, testing, clinical practices, real-world performance monitoring, and other appropriate capabilities to qualify for a more streamlined pre-market review while better leveraging post-market data collection on the device's safety and effectiveness, the agency says.
"This new, organization-based approach enhances the ability to assure the safety and effectiveness of software products by using the pre-certification framework in addition to some aspects of the agency's traditional reliance on individual product-based oversight," the FDA says.
Areas of 'Excellence'
The FDA proposes to evaluate vendors for pre-certification based on five "culture of quality and organization excellence principles." In addition to cybersecurity responsibility, the FDA would also evaluate a company's approach to product quality, patient safety, clinical responsibility and whether it has a "proactive culture."
The agency says it would seek to adopt "a risk-based, streamlined regulatory approach to SaMD review to either replace the need for a pre-market submission or, for higher-risk products, to allow for streamlined pre-market review that maximizes efficiency and engagement."
When it comes to evaluating the "cybersecurity responsibility" of vendors participating in the pre-certification program, the FDA proposes that it would review the vendor's "demonstration of a commitment to protect cybersecurity and to proactively address cybersecurity issues through active engagement with stakeholders and peers."
Step in Right Direction?
Some security experts say they are hopeful that the pre-certification program will help promote technology innovation while keeping patients safe.
"Since software is so much more malleable than hardware, I think a streamlined regulatory pathway presents a good opportunity to hammer out some principles for all device makers to follow, including those that make hardware," says Ben Ransford, CEO and co-founder of healthcare cybersecurity firm Virta Labs.
"This mirrors a common practice in the world of unregulated electronics, where you can iterate designs in software before memorializing them in hardware."
In terms of the FDA evaluating a vendor's "cybersecurity responsibility," Ransford suggests the agency consider assessing a number of practices.
"I would start with adoption of an organized secure development lifecycle, patching, third-party testing, readiness to work with security researchers and a coherent commitment to patient privacy," he says.
"The true test of a vendor's security practices is how they handle a crisis."
—Ben Ransford, CEO at Virta Labs
"It's best to adopt a stance of 'trust but verify' when it comes to vendors' security claims," he adds. "The true test of a vendor's security practices is how they handle a crisis. But since we probably can't put every vendor through a crisis, we should subject vendors to real critical review including red-team testing."
While the FDA's focus is on patient safety, "we have to keep patients' privacy in mind too," Ransford suggests. "It's too easy for software companies to treat people as data fodder to feed shadowy revenue streams," he says.
"FDA has a chance to bare its teeth and make sure vendors commit to strict privacy protections. Breaches can't expose what hasn't been collected."
The FDA's Medical Device Safety Action Plan goal of spurring development of new software products that are safer is "completely laudable and certainly align with the Department of Health and Human Services' healthcare industry cybersecurity task force report," notes David Finn, a member of the task force. The report provided HHS recommendations for improving cybersecurity in the healthcare sector.
"Like so much in both healthcare and in government, the devil is in the details - the implementation and operationalization of the plan," says Finn, a former healthcare CISO who is now executive vice president of innovation at security consultancy CynergisTek.
"Anything that helps vendors get better products to market faster is a good thing," he says. "I believe if the right criteria are established and it is documented that they are being followed it could be [good] for vendors, patients and everyone involved in the process and the continuum of care."
But if the criteria don't include cybersecurity standards and minimal acceptable security practices, he says, "then it will all have been for naught - we may actually make things worse."
Finn notes that the FDA's pre-certification program could help raise the bar in terms of medical device cybersecurity expectations.
"The biggest issue, I believe, is that we write really bad software in this country - certainly from a security perspective but even from a functionality, reliability and documentation perspective," Finn says.
"SaMD vendors must formally adopt rigorous and secure development lifecycle standards." Security and risk management processes must be built into the lifecycle from concept to manufacture/development to deployment to end-of-life to data disposal, he says.
"Adding security after the fact, which has historically been our approach, always results in two outcomes: less security and privacy, and higher costs."