Software maintenance is the phase in which software is further developed, e.g., with the objective of
- rectifying errors,
- implementing new functionalities, or
- adapting the software to a changed runtime environment.
According to the FDA, 79% of all bugs occur during software maintenance. Accordingly, some regulations address this topic.
Update: Addition to software maintenance during development
Regulatory requirements for software maintenance
Requirements of the Medical Device Regulation MDR (2017/745)
The Medical Device Regulation requires medical device manufacturers to prepare a technical documentation and submit it to a notified body depending on the class (I, IIa, IIb, III).
If the software changes, the technical documentation must be updated in accordance with the document control requirements of ISO 13485. Read below to find out when a new submission is expected from the notified bodies.
If the modification changes the class of the device, it may even be necessary for you to go through another conformity assessment procedure.
Requirements of IEC 62304
IEC 62304 describes an explicit process for software maintenance. Note that other processes described in this standard also regulate the process of “software changes”:
When making changes, you must go through the software problem resolution process (IEC 62304 Chapter 9), the software configuration management process (IEC 62304 Chapter 8), and the software maintenance process (IEC 62304 Chapter 6). As a result, you must
- explicitly authorize the software to be changed,
- investigate causes for this change (these may lie, for example, in the process, the use of methods and tools and not just in a faulty line of code),
- analyze trends,
- document the new/changed software requirements, as well as possible changes to the software architecture,
- repeat the tests (unit tests, integration, and system tests) as regression tests depending on the safety class (more on this below), and
- release the modified software.
FDA requirements: Design change
The FDA‘s requirements are comparable to those in Europe. The FDA requires the following for design changes:
Each manufacturer shall establish and maintain procedures for the identification, documentation, validation, or, where appropriate, verification, review, and approval of design changes before implementation.
You should pay particular attention to consistently documenting individual development statuses in the Design History File DHF.
Software maintenance: Practical tips
Software maintenance during development
What to do if an error is discovered during development, for example,
- when reviewing a document such as a software requirements specification or the software architecture?
- during a code review?
- during programming?
- during software testing (e.g., unit testing, integration, or system testing)?
Strictly speaking, we must consider three different processes of IEC 62304:
- Problem resolution process
- Configuration management process
- Maintenance or development process
Let’s take a look at these three processes and discuss how we can do this without overhead:
ad 1. Problem resolution process
Legal requirement: The main requirement is to document and evaluate the problem. You must regularly assess the problem reports and analyze trends as part of continuous measurement and improvement.
Practical tip: You can do this with a simple “ticket system.” Simply entering the problem report should take just a few minutes. It’s best to enter the documents you want to change right away.
However, you only need to go through the problem resolution process and the following processes if a document or tested artifact that has already been released needs to be changed again. For example, if the developer discovers during the unit test that the code he has just written is not error-free, there is no need to write a problem report.
ad 2. Configuration management process
Legal requirement: Configuration management’s objective is to obtain permission to change a specific version of the document (this also applies to code). This release must be granted by the person identified in the configuration management plan.
Practical tip: Make sure that this person is available. If necessary, benefit from the same “ticket system” in which this person gives their approval and names the documents that may be changed. This should also only take a few minutes. Do not issue the release for individual code files, but for an entire software unit or software item.
ad 3. Software maintenance
Now the changes go through the normal development process. You determine which parts of your software need to be retested (see regression tests below).
General tips
Manufacturers are usually reluctant to subject changes to these three processes during development. This is generally because the release of the changes and the release of the changed documents or software is too time-consuming. However, this is a problem with your processes. Make sure that
- your standard operating procedures only involve those people in the inspections and releases who
- are really affected by it and have a good understanding of it. This does not necessarily include managers.
- are quickly available.
- you have clear criteria for inspections and releases so that people know exactly what needs to be done.
- your risk management and software architecture are known and documented, and you can determine the scope of regression testing based on this.
- changes are identifiable (e.g., revise mode in Word or diff in the version management system) to minimize the scope for regression testing.
You want your processes to be very effective and efficient. This means that you also experiment and regularly reflect on and revise your corresponding standard operating procedures. The same applies to the release of these standard operating procedures.
Clarify whether it actually is software maintenance
Some manufacturers debate whether a change to a language file or configuration file, for example, even counts as a software change subject to the software maintenance process. The answer to this question depends on whether the changes to these files are part of the intended purpose (more precisely, normal use).
For example, if a configuration file is intended to be used to customize network settings for a software installation by the customer or service technician, then this would not be considered software maintenance. Rather, risk management would have to have already examined what happens if someone makes a mistake or the file is faulty for some other reason.
If, on the other hand, the configuration file is a file in which the software developers have outsourced parameters, but which is not intended to be adapted by third parties, a change would be a “design change.”
Resubmission of technical documentation to a notified body
The maximum size of the changes that can be made to avoid resubmission varies from notified body to notified body. Some expect an update of the file even for minor bug fixes; some say, “Don’t bother us!”.
You can work with the following rule of thumb: A bug fix/reestablishing conformity with the specification (typically the third digit of the version number, e.g., 2.12.4) does not require notification unless you need to report, according to MDR vigilance requirements. Functional enhancements, new screens, and changes to the architecture (design change) require a new submission.
If you are unsure whether a new submission is necessary, always ask yourself whether the changes represent a change to the risk, no matter how small. If this is the case, please resubmit.
For MDR class I medical devices, submission of technical documentation is generally not required – neither initially nor in the event of changes to the device.
Risk management
In risk management, you need to think about the consequences and risks the change may entail. These are
- risks due to the change per se, e.g., due to new functionalities,
- risks resulting from newly introduced bugs,
- risks due to the (re)installation or update of the software (at the customer’s premises), and
- risks due to a lack of usability, for example, because users are unfamiliar with or misunderstand the new functions.
Regardless of whether you change the intended purpose, the software requirements specification (including the user interface specification), the software architecture, or the code, you will want to update the risk management files accordingly.
You will implement risk mitigation measures depending on the new risks arising from the software maintenance. These mitigation measures may also include further user training. Operators are also obliged to do this in accordance with the MPBetreibV.
Software tests and regression tests
As part of the software test, you must prove that
- the new or changed functionality (i.e., the new or previously unimplemented software requirements) has been implemented as specified, and
- the unaffected software requirements are still fulfilled as specified.
In the simplest case, you test the software again completely when a change is made. This will usually only be possible if the software tests are fully automated. If this is not possible, then “only” test the new functionalities and the functionalities that may be affected by the changes. Which ones these are can only be recognized or justified in the software architecture.
Renewed review of usability during software maintenance
IEC 62366 requires validation of usability. In the case of software maintenance, you would (re)test the use scenarios of changed user product interfaces (e.g., a GUI).
Remember to perform this usability validation with representative users (plural!) in a representative use environment.
Designing processes in compliance with the law
Would you like support to
- redesign your processes, e.g., the software maintenance process, to be legally compliant,
- select and adapt tools to support these processes effectively and efficiently, or
- review your QM manual, your process descriptions, and your documents (e.g., the Design History File) to avoid problems in the audit.
Then get in touch with us! We are specialized in these matters and can often help you within a few hours.
Change history
- 2024-01-19: References to the MDR added
- 2015-09-11: Initial creation of the article
