Copy to clipboard 
Software systems have become key elements in the design and function of medical devices as orthopedic companies fill product portfolios with high-tech solutions. FDA is keeping pace with this evolving landscape with guidance documents that outline what the agency considers when reviewing premarket submissions of software-enabled devices.
In its latest guidance issued in June, the agency described the information that should be documented during software development, verification and validation to ensure the safety and effectiveness of devices. The guidance provides insights into the documents that device manufacturers need to include in premarket submissions, but questions remain.
Before looking ahead to what comes next, let’s look back at the history of FDA guidances on software development for some needed context.
Building Off the Basics
FDA’s “General Principles of Software Validation” guidance from 2002 included the classic chapter heading “Software is Different from Hardware.”
Well, yes, of course it is. But FDA also provided some specific and actionable details: software is inherently more complex than hardware; unlike hardware, most software defects arise during design and development; and unlike hardware, seemingly insignificant changes in software code can create unexpected and very significant problems elsewhere in the software program.
All this led FDA to the very reasonable conclusion that “the development process for software should be even more tightly controlled than for hardware.”
But what exactly should those tight controls be? FDA followed up in 2005 with another final guidance, “Content of Premarket Submissions for Software Contained in Medical Devices.” That guidance gave medical device manufacturers a pathway for determining the software’s Level of Concern (Major, Moderate or Minor), which would then be used to determine the documents required for submissions to FDA. The higher the risk of patient harm inherent in the device (the higher the Level of Concern), the more documents FDA wanted to see in the 510(k), De Novo or premarket approval (PMA) submission.
One interesting quirk of the 2005 guidance was hinted at by its title. It listed the documents that manufacturers needed to submit to FDA, but it didn’t list the additional (unsubmitted) documents that manufacturers should create and maintain in the Design History File (DHF).
So, how would manufacturers know if anything was missing from the DHF? Well, the few manufacturers that submitted PMA applications found out when FDA reviewed the submissions. But most manufacturers had to wait until FDA conducted onsite inspections. This could be a little nerve-wracking.
FDA’s 2005 guidance was followed almost exactly a year later by an International Electrotechnical Commission standard for medical device software development (IEC 62304). Just like FDA’s guidance, IEC 62304 had three risk levels, which it called Software Safety Classes (A, B, and C): “A” corresponded roughly to FDA’s “Minor” and “C” corresponded roughly to FDA’s “Major.”
IEC 62304’s document requirements were similar to FDA’s, though somewhat stricter and more detailed. Unlike FDA’s 2005 guidance, IEC 62304 listed the software documents that had to be created for the DHF, regardless of whether they would be submitted to a regulatory authority.
Overall, FDA’s guidance and the IEC standard were “harmonized,” meaning that, while not identical, they did not conflict with each other. Manufacturers could follow both as needed.
Keeping Up with the Times
A lot has changed in software development since 2005, to put it mildly.
In recent years, FDA has released a slew of new software development guidance, including the 2019 update, “Off-The-Shelf (OTS) Software Use in Medical Devices.” OTS software is important to address because many software systems combine the manufacturer’s own software with modules borrowed from other products.
OTS software inherently adds more risk to the product development equation because most commercial platforms aren’t specific to medical devices, and therefore weren’t developed according to strict FDA or IEC 62304 controls. Additionally, the medical device manufacturer has no direct control over the contents of OTS software. FDA’s OTS software guidance is intended to help manufacturers better manage this inherent added risk.
Any mention of cybersecurity — a significant concern in today’s digital world — is conspicuously absent from FDA’s 2005 “Content of Premarket Submissions” guidance. That same year, the agency did release a separate final guidance, “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software,” but it’s limited in scope.
FDA issued a final guidance on cybersecurity in 2016 “Postmarket Management of Cybersecurity in Medical Devices,” as well as a series of draft guidance for cybersecurity in device submissions. In April 2022, FDA introduced a new draft guidance, “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions.”
EDITOR’S NOTE: In September 2023, FDA issued a guidance document that provides final recommendations regarding cybersecurity device design, labeling and documentation that should be included in premarket submissions for devices with cybersecurity risk. This document supersedes the final guidance “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices” that was issued in October 2014 and discussed in a previous BONEZONE article.
Finally, in June 2023, FDA released a final “Content of Premarket Submissions” guidance that updated the 2005 version. It was hoped that this update would move FDA closer to IEC 62304, which would make regulated software development easier for everyone. But this was not to be. FDA made two specific changes that moved their guidance further away from IEC 62304:
- Instead of three Levels of Concern (Major, Moderate or Minor), the new guidance required only two documentation levels: Enhanced and Basic. For any software medical device manufacturer selling in the U.S. and international markets, this meant an additional burden of risk determination because there were no longer three parallel levels to compare between FDA guidance and the IEC standard.
- The new guidance specifically stated that IEC 62304-based reports could be used in place of FDA’s requirements only for certain areas of documentation: software development planning, software maintenance and configuration management. By calling out IEC 62304 only for these areas of planning and development, the software manufacturers were burdened with parallel (not shared) compliance requirements between FDA guidance and the IEC standard.
That said, there were some positive takeaways from FDA’s new guidance:
- By allowing IEC 62304-based reports in software development planning, software maintenance and configuration management, FDA has opened the door to future final guidance that could allow for the greater use of IEC 62304.
- The 2023 guidance omitted several documents required by the 2005 version, most notably the Software Hazard Analysis. This unnecessary document had parallel but non-identical requirements to those already listed in ISO 14971:2019 for medical device risk management. By telling manufacturers to simply use ISO 14971:2019 to manage software device risks, the 2023 final guidance is better aligned with IEC 62304.
- A snarky comment included in previous draft guidance was omitted from the 2023 final guidance: “The scope of IEC 62304 extends beyond the intent of this guidance and discusses broader perspectives that may not result in documents that are easily reviewed by FDA.” (In other words: “Don’t send us your difficult, IEC 62304-based reports to drag through.”) By omitting that comment, FDA extended an olive branch.
There was an awkward period from June to August of this year when the new final “Content of Premarket Submissions” guidance required Enhanced and Basic risk documentation levels, while the 2019 “Off-The-Shelf Software Use in Medical Devices” guidance still referred to the three Levels of Concern. But FDA released an updated “Off-The-Shelf Software Use in Medical Devices” guidance in August 2023, which aligned the recommendations in the two documents.
Important and Informative Update
While the 2023 final “Content of Premarket Submissions” guidance has been a disappointment in its non-alignment with IEC 62304, it does bring clarity to the differences between FDA’s and IEC’s approaches. It also clarifies the unsubmitted documents that are required for the DHF. In the rapidly evolving and expanding market for medical device software, this transparency is necessary and welcome.
Dan Goldstein, CQA, is Senior Director for Quality Assurance at MCRA, a Washington, D.C.-based medical device consultancy. Mr. Goldstein has worked since 2002 in medical device QA, with U.S. and international experience in devices for digital health, orthopedics, cardiology, neurology, wound care, and imaging. He is certified by the American Society of Quality (ASQ) as a Certified Quality Auditor (CQA), by British Standards Institution (BSI) as an ISO 13485:2016 Lead Auditor, and by Exemplar Global (RABQSA) as an Auditor for EU MDR, EU IVDR, and MDSAP.
