Adopters - Managing changes to medical devices after adoption

Managing changes to medical devices is the legal responsibility of the developer. But adopters support developers in these processes and are required to follow the clinical risk management standard. These help make sure devices stay safe and effective.

Changes to medical devices after you adopt them

Medical devices may change after you adopt them. There are 2 types of changes you need to consider:

• change to the device driven by the developer
• changes to the infrastructure and procedures of the deployed environment, driven by you as the adopter

Reasons for changes include:

• safety concerns
• updates to operating systems
• security patches
• user feedback
• design improvements
• testing out new features
• using the device in a new area of working

If performance drops for a medical device, the developer is required to update it and bring performance back in line with acceptable or prespecified levels. Developers may also want to add new functionality or improve other aspects of their devices.

Some changes (for example, new functions or changes in intended purpose) may require developers to go back to the beginning of the device life cycle and seek approval. They will have to generate the relevant evidence, meet appropriate standards for the updated device, make sure it is still operating legally and is safe and effective for its new purpose. They may also be required to consider whether previous evaluations (such as health economic modelling) are adversely impacted by the change and need re-evaluating.

Adopter’s responsibilities when a device changes

If you are an adopter only (that is, not involved in developing the device) you have no legal requirements under medical device legislation (UK MDR 2002) if a medical device changes after you adopt it. But the developer has legal requirements to maintain device safety and may need your help to meet them. Also, if you are in England and Wales, you are required to comply with clinical risk management standard DCB0160. For example, as part of your general monitoring of the device, you may need to consider whether re-evaluations of the clinical safety of the device are necessary when there is a significant change in it or the external operating environment.

You can work collaboratively with the developer to put in place agreements and processes for managing change without losing use of the device. You should also establish appropriate risk management and safety monitoring as required by DCB0160 and make users aware of these processes.

You will be routinely providing the developer with information and data about outcomes and performance to help inform device improvements and updates. This will have been agreed as part of the post-market strategy. You may need to provide more information and data after a major change (or safety investigation) to enable further assessment by the developer.

You need to be aware that any infrastructure or operational changes within your own working environment could impact the function of the device. These include changes in the target population or recommended use. You should inform the developer of any changes. If there is a change in use, the developer may need to apply for new approvals.

You need to be aware that any infrastructure or operational changes within your own working environment could impact the function of the device. These include changes in the target population or recommended use. You should inform the developer of any changes. If there is a change in use, the developer may need to apply for new approvals.

An example: changes to infrastructure

You adopted a medical device into your infrastructure and this infrastructure has a scheduled update of its operating system. The developer is legally required to make sure the device continues to perform within safe parameters after this update has been implemented. They need to test and adjust the device in a controlled manner before it can be deployed in the updated infrastructure. By planning the update in advance with the developer you avoid technical delays, drops in performance and potential safety issues.

Addressing concerns or incidents after changes to a medical device

If users experience any difficulties or concerns about the usability or outcomes after a change to the system that could impact the clinical safety of the updated device, you should report these. For example, if there is a clinical safety concern such as a pattern of incorrect diagnosis you would use the safety incident management process agreed in your DCB0160 report. You should also report your concerns to the developer and support them in their investigation and resultant updates. You should also report any concerns or adverse incidents after device updates to the MHRA using the Yellow Card reporting site.

An example: a poorly-performing device has resulted in an injury

A person has been injured as a result of a poorly-performing device. The developer is legally required to report this to the MHRA, who may require the developer to investigate the root cause of the event and take corrective action. The developer needs access to the specific inputs and outputs from the event. If this involves sharing personal data, you will need to follow legal requirements. The developer then needs to update the device and there are risks from using the device until the update is available. Working collaboratively with the developer, you make sure effective solutions are generated quickly and within regulatory requirements.

Your role as an adopter in managing change to a digital technology

Your role in making sure a medical device is safe to use includes understanding how the developer does post-market surveillance. This is the legal responsibility of the developer, but you play an important role in supporting it. For more information, see understanding post-market surveillance of medical devices

If you, as an adopter, are also the developer of the medical device you should read our website content on developer obligations.

Get more information on clinical risk management standard DCB0160 here.