US medical device market regulators have clarified their recommendations for when changes to software or firmware should prompt a manufacturer to file a new 510(k) premarket notification for a medical device.

New guidance from the US Food and Drug Administration regarding software changes was issued separately from guidance covering other changes to medical devices that require manufacturers to file new 510(k)s, reflecting the agency’s recognition of software’s more ubiquitous and complex role as a key component of device functionality.

Defining “software” in a medical device context

The FDA defines software in the context of the guidance as any set of electronic instructions that control the actions, input or output of a medical device. Softare that “is embedded within or permanently a component of a medical device...is an accessory to another medical device, or...that is intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device” fall under the scope of the guidance, states the agency.

The guidance does not cover software such as some mobile medical applications for which the FDA does not plan to enforce regulatory controls, nor does it pertain to software lifecycle issues, 510(k) documentation requirements for software changes, or principles for medical device software validation, all of which are addressed in other guidances.

(More information on issues related to this FDA guidance can be found via our whitepapers on the FDA 510(k) registration process and US medical device cybersecurity requirements.)

Software changes that do and do not require new 510(k)s

Included in the guidance is a flowchart intended to help manufacturers and developers determine which types of software changes mean new 510(k) filings and which do not.

Two major types of changes do not warrant new 510(k)s, according to the FDA:

• Changes made only to improve cybersecurity, with no other impact on the software or device
• Changes made only to return a device system into the specificatio of the most recently cleared version of the device

For such instances, the guidance recommends that registrants document these changes to their files.

The flowchart lists four major types of software changes, on the other hand, that usually do require new 510(k) filings:

• Changes that introduce new causes or modify existing causes of hazardous situations resulting in significant harm; this risk is not mitigated in most recently cleared version of the device
• Changes that directly introduce new hazardous situations resulting in significant harm; this risk is not mitigated in most recently cleared version of the device
• Changes that create or necessitate new risk control measures or modifications to existing risk control measures for hazardous situations that could result in significant harm
• Changes that significantly affect clinical functionality or performance associated with the device’s intended use

Software-specific guidance a welcome move from FDA

The fact that the FDA broke out software changes into a separate guidance from other device changes shows a better awareness on the agency’s part of issues particular to software products.

“The change cycle for software is much smaller than other changes like labeling or materials,” explains Richard Vincins, Vice President of Quality Assurance at Emergo. “This guidance is intended to support manufacturers when software changes are made, but still strongly advises the use of guiding principles and supporting justification for such changes.”