FREQUENTLY Asked Questions
What are some additional factors to consider when determining when to submit a new 510(k) for a software change to an existing device?
View All FAQs
About the Author
Proxima CRO Team
Isabella Schmitt, RAC
Director of Regulatory Affairs

Prior to joining Proxima, Isabella served as the Senior Regulatory & Quality Manager at a medical device company, where she outlined the regulatory strategy & put together design controls & design history documentation. She was the Dir. of CMC & Quality at a biopharmaceutical company, where she oversaw all manufacturing and analytical processes and timelines and ensured CMC regulatory strategy was sufficient for filings in Europe and the US.

Medical device software is used in a wide variety of applications and is subject to a wide variety of changes. The impact of software changes on safety and effectiveness may not always be clear. This is often the case when making general code changes to software that are not necessarily intended to change function, but rather to perform what could be described as “code maintenance” or “infrastructure” modifications. These types of changes can, if not controlled properly, create unexpected changes to how the device functions. These types of changes should therefore involve a careful evaluation of their potential impact on device safety and effectiveness.

In addition to change management, these types of changes should also involve careful consideration of the overall architecture of the software. If the software architecture was developed in a planned, modular format, the likelihood of unintended impact to other areas of the code may be significantly reduced. On the other hand, if the software code was developed in a looser construct, without a clear architectural plan, the ability to clearly delineate between functional modules in the code may be reduced. The potential impact to device safety and effectiveness increases in code with looser construct, due to the inherent risk of unintended changes in code without clear boundaries in the functional modules.

The purpose of this section is to provide guidance regarding evaluation of certain types of software changes, such as “code maintenance” and “infrastructure” changes. Manufacturers are encouraged to discuss these “gray areas” with the relevant CDRH or CBER Office and Division if there are questions about whether to submit a new 510(k) for these or other types of software changes. In most cases, this will be the Division under which the device was originally cleared.

Related Terms:
Related FAQs:
More Questions? We're here to help!