Dive Brief:
- The Food and Drug Administration issued final recommendations on when a modification to medical software requires new 510(k) clearance.
- The guidance, published Wednesday, discusses common types of software changes that could necessitate a 510(k) filing: infrastructure, architecture, core algorithm, and reengineering or refactoring. Two other types of changes — clarification of requirements and cosmetic changes — would likely not require a new submission if they don’t impact the device’s functionality.
- While welcome, Epstein Becker Green partner Bradley Merrill Thompson told MobiHealthNews the new guidance doesn’t go far enough. “If it’s an improvement, it’s only a marginal one,” he said. “Until we change the regulation and shift the agency’s focus to the software vendor, rather than engaging individual product review, any gains will be small at best.”
Dive Insight:
The FDA hopes the guidance and a similar one changes to existing devices will help to foster innovation by reducing unnecessary submissions.
‘These new guidance documents do not change the FDA’s review standard: A new 501(k) is required when a marketed devices has changes, including changes to software, that could significantly affect the safety or effectiveness of the device or when there are major changes in the intended use of the device,” FDA Commissioner Scott Gottlieb said a statement. “Instead, the new policies enhance predictability and consistency for innovators deciding when to submit new 510(k)s by better describing the regulatory framework, polices and practices underlying such a decision.”
Essentially, modifications that significantly alter a device’s clinical functionality or performance specifications would need the FDA’s okay, as would changes that pose a safety risk for patients.
Architecture changes are modifications to the overall structure of the device, such as changes to support new hardware or middleware, the guidance explains. Developers seeking changes to reengineering and refactoring, common software maintenance techniques, should consider the complexity of the change in deciding if a new 510(k) is required.
The 31-page final guidance, which replaces an August 2016 draft, includes hypothetical examples of software changes and detailed flowchart to help developers determine when to file a 510(k).