How to move fast and not break things

A Software as a Medical Device proposal for change management guidance under the Medical Device Regulation

color blob

On May 26th 2021, the EU Medical Device Regulation 2017/745 (MDR) passed the date of application, meaning that it is now in full effect. At Aidence, we were one of the first to obtain our CE certificate for an AI-based medical device under MDR in October 2020. Since then, a question we often get is: how do you deal with changes and upgrades to your software components and AI algorithms?

Many software companies apply the “move fast and break things” principle. But when the software is a medical device, these words sound concerning, to say the least, for quality and regulatory professionals. Whilst there may be some room within our procedures and regulations to allow for going fast, we want to prevent anything from breaking – especially when it could put users or patients at risk.

In this article, we address the benefits and the potential downsides we notice under the MDR with regard to change management and examine if there is some room for going fast. In addition, we will discuss how we, as Aidence, implement change management for our class IIb AI application.

Change management before MDR

To properly understand the impact of changes introduced by the MDR, we’ll first explain how change management worked under the previous regulation, the Medical Device Directive 93/42/EEC (MDD).

“Substantial changes”

Under the MDD Annex II, device manufacturers (class IIa, IIb, and III) were obliged to inform the Notified Body of substantial changes to the quality management system or the product range. The Notified Bodies organisation (NB-MED) published helpful guidance to support a manufacturer’s understanding of which changes are considered substantial:

Changes are “substantial“ and (depending on the chosen conformity assessment route) the manufacturer must inform the Notified Body where:

(i) for product changes, the change would affect conformity with (a) the essential requirements and/or (b) the conditions prescribed for the intended use of the device.

(ii) for changes to the quality system, either (a) the change would affect compliance of the devices covered by the quality system with the essential requirements or the approved type/design or (b) the change means additions to the product-range covered by the quality system.

Notified Body assessment

Once informed of a change to the quality system or approved device design, Notified Bodies would assess whether the change affects compliance with the essential requirements or the conditions prescribed for use. When needed, they would review the change documentation and issue a supplement to the CE certificate.

For the conformity assessment of entirely new devices, the Notified Body would look at either:

  • The technical documentation for a single representative sample of each device category (class IIa) (e.g. per Annex V or II);
  • One representative sample of each generic device group (class IIb, when a device category is broader than a generic device group.) (e.g. per Annex V);
  • Each device (class III) (e.g. per Annex II).

An important note here is that for class IIb devices, sampling of technical documentation for review under the MDD was not accepted under Annex V. The reason was that quality system audits excluded the review of design and development procedures.

A new approach under MDR

Change management has been adapted substantially under the MDR, but questions and uncertainties remain. How change management is applied becomes confusing in section 4.10 of Annex IX (for some class IIb (per article 52(4) and all class III):

Changes to the approved device shall require approval from the Notified Body which issued the EU technical documentation assessment certificate where such changes could affect the safety and performance of the device or the conditions prescribed for use of the device. Where the manufacturer plans to introduce any of the above-mentioned changes it shall inform the Notified Body which issued the EU technical documentation assessment certificate thereof.

The Notified Body shall assess the planned changes and decide whether the planned changes require a new conformity assessment in accordance with Article 52 or whether they could be addressed by means of a supplement to the EU technical documentation assessment certificate. In the latter case, the Notified Body shall assess the changes, notify the manufacturer of its decision and, where the changes are approved, provide it with a supplement to the EU technical documentation assessment certificate.

And as follows for class IIa and class IIb medical devices:

The manufacturer in question shall inform the notified body which approved the quality management system of any plan for substantial changes to the quality management system, or the device-range covered. The notified body shall assess the changes proposed, determine the need for additional audits and verify whether after those changes the quality management system still meets the requirements referred to in Section 2.2.

It shall notify the manufacturer of its decision which shall contain the conclusions of the assessment, and where applicable, conclusions of additional audits. The approval of any substantial change to the quality management system or the device-range covered shall take the form of a supplement to the EU quality management system certificate.

In short

Every change that could affect the safety or performance of some of the referred class IIb devices and all class III devices needs to be reported to the Notified Body, which may then decide on its own whether to review the change. The threshold applied can vary per reviewer and per notified body. For class IIa and most class IIb devices, such reporting needs to be done when changes are substantial in terms of their effect on the QMS or device range covered.

Although the Medical Device Coordination Group (MDCG) issued guidance for the transition from MDD to MDR regarding change management, it hasn’t released any ‘business as usual’ guidance. This topic is also not included in their future roadmap.

Possible implications

Of course, manufacturers and Notified Bodies must ensure that devices are brought to the market safely. It is also understandable that sampling should be allowed in conformity assessment of class IIa and class IIb devices (since quality systems, including design procedures, are reviewed under Annex IX).

However, the regulation also implies that substantial changes to the device range or QMS or minimal (safety or performance) changes might require Notified Body review or additional audits. Notified Bodies can request a conformity assessment for each reported design change and charge manufacturers for it. Consequently, as manufacturers and Notified Bodies, we are faced with:

  • An unclear threshold for substantial changes to the device range or QMS and/or safety and performance changes. Many changes could ‘potentially’ be substantial to the QMS or affect safety and performance, especially for software;
  • An incomplete description of how a Notified Body should assess the planned change and decide whether the change requires a new conformity assessment. There is no support for whether the change should be reviewed or not.

This creates an unlevel playing field, mainly as each Notified Body might set the threshold differently.

As for AI-based medical devices, fast performance improvements would immediately benefit patients and healthcare professionals. Having to report every performance change slows down the release of product upgrades. Manufacturers may not be motivated to release performance improvements due to the potential costs and timelines associated with the additional review. Or, they may postpone the release to combine multiple changes in one submission.

Bringing new devices to the market

MDR Article 52 states that for, class IIb devices (with some exceptions):

4. Manufacturers shall be subject to a conformity assessment as specified in Chapters I and III of Annex IX, and including an assessment of the technical documentation as specified in Section 4 of that Annex of at least one representative device per generic device group.

Further in Annex IX, 2.3, it is specified that:

Moreover, in the case of class IIa and class IIb devices, the quality management system assessment shall be accompanied by the assessment of technical documentation for devices selected on a representative basis in accordance with Sections 4.4 to 4.8.

In choosing representative samples, the Notified Body shall take into account the published guidance developed by the MDCG pursuant to Article 105 and in particular the novelty of the technology, similarities in design, technology, manufacturing and sterilisation methods, the intended purpose and the results of any previous relevant assessments such as with regard to physical, chemical, biological or clinical properties, that have been carried out in accordance with this Regulation.

As mentioned, from discussions with our Notified Body, we understood that we could add products that fall in the same generic device group to our MDR certificate. These device groups are determined through the CND nomenclature codes (e.g. our code is: ‘Various digital bioimaging management instruments – software (Z110690)’). Any new device falling within the same code and classification (e.g. class IIb) can be added under the existing certification without updating its scope by sending in the Declaration of Conformity.

When judged against the fact that one could bring an unreviewed medical device class IIb to market with a (to the Notified Body) unknown safety and performance profile, the requirement to report every performance improvement to the Notified Body seems not only unnecessary but also disproportionate.

Change management for AI devices

How to deal with changes to AI-based medical devices is a more relevant question compared to other medical devices because:

a) AI-based medical devices are software devices (or software embedded in hardware), which nearly always have faster release cycles compared to hardware devices;

b) AI has the opportunity to train on new data and improve its performance.

With regards to b), some AI systems also have the potential to retrain and update in a fully automated manner. However, this comes with difficult questions that have not been answered yet (e.g. how to perform adequate quality assurance activities). And, the legislation does not seem to allow for such systems so far.

So, how do we deal with AI model changes?

How we do things

At Aidence, we have strict change management procedures. Our approach, in brief, entails:

  1. For any change to our AI model, we must run all relevant statistics for its current and previous versions on an unchanged version of the dataset. We do this to fully understand the impact of the changes and identify any unanticipated adverse effects. If needed, we perform additional validation against an updated version of the test set (to avoid overfitting on the test set and data drift), as suggested in the Good Machine Learning Practice, guiding principles set out by the US Food and Drug Administration (FDA), Health Canada, and the United Kingdom’s Medicines and Healthcare products Regulatory Agency (MHRA).
  2. Secondly, if there are any statistical differences in the results of the model versions, each change in statistics must be explained in our model change assessment report. We investigate why the statistic is impacted, the relevant clinical consequences, and how these changes affect the established clinical evaluation and, consequently, the device’s safety and performance.
  3. If we identify positive differences, we determine whether these are solely improvements to the model (e.g. our sensitivity/specificity trade-off improves). If so, we proceed with the release of the new model, without notification to the Notified Body.
  4. In the event of any negative impact (e.g., sensitivity improves, but specificity decreases), we assess whether the benefits of the update outweigh the adverse effect. Should we want to proceed, we document our rationale and inform the Notified Body of the planned design change.

We have thoroughly documented these considerations and processes in our Clinical Evaluation, together with the standard operating procedures regarding clinical evaluation and change management, which were reviewed and approved by our Notified Body. However, each Notified Body can take a different approach, and therefore guidance from MDCG or NB-MED is highly desired.

What we propose


All the above considered, this is our high-level proposal for Software as a Medical Device (SAMD) change management definitions. An algorithm change represents any change to the algorithm, for example, changes to the coding or improved performance due to retraining.

We built our suggestion on the MDCG 2020-03 and the FDA guidance on ‘Deciding when to submit a 510(k) for software changes to existing devices’.

SAMD change management definitions - Aidence proposal
SAMD change management definitions – Aidence proposal


Algorithm changes

Our assumption is that any safety-impacting change should be reported by the manufacturer, as it would alter the risk assessment. This includes reporting changes in the performance of AI algorithms that would negatively impact the device’s performance (to the extent of affecting risk outcomes or requiring additional mitigation).

The flowchart below presents an overview of algorithm changes, their required evidence, and the subsequent need to report to the Notified Body. This setup would allow manufacturers to quickly implement and release performance updates that do not negatively impact the clinical benefit/risk profile associated with the product. We emphasise that manufacturers need to have strict procedures to ensure that such an assessment of the impact on the clinician benefit/risk profile is made. International standards could support this process.

We suggest including this flowchart in the guidance on algorithmic change management.

SAMD change management definitions - Aidence proposal
SAMD change management definitions – Aidence proposal


We anticipate that changes affecting the clinical performance should allow for automation in the future, except where these would affect the clinical benefit/risk ratio. The automation would warn the user if a change in benefit/risk ratio were to occur (e.g. increase in sensitivity at the cost of specificity). The manufacturer would then consider whether such changes would be acceptable and inform the Notified Body accordingly.

Such automation goes hand in hand with streamlined documentation updates (e.g. testing, clinical evaluation, risk management, instructions for use, training materials), with a human-in-the-loop evaluation and approval of a Declaration of Conformity by the PRRC or other assigned responsible person.

A call for guidance

In conclusion, we call for the MDCG or NB-MED to provide more support on change management, aiming to:

  • Avoid arbitrary review requests from Notified Bodies to manufacturers and support a level playing field on the market;
  • Resolve the disproportionate burden of design changes for class IIa and class IIb products as compared to the relatively low evidence approach of introducing entirely new devices onto the market;
  • Ensure timely availability of improvements to AI-based medical devices to support product improvements for healthcare organisations and patients.

We propose to add AI-specific change management requirements in the MDCG deliverable “Artificial Intelligence under MDR/IVDR framework”, pending planning as in this list from the European Commission.

This guidance would support SAMD (and non-SAMD) manufacturers in innovating as fast as possible without compromising on patient safety.


About Leon

Leon Doorn is Regulatory Intelligence and DPO at AidenceLeon (Doorn) started working with Aidence in 2017. After finalising his bachelor's in nursing, and having worked as a nurse, he found that there is a lot of room for improvement within healthcare that cannot be achieved when working within a healthcare organisation. Therefore, he went on to study health sciences at the Vrije Universiteit in Amsterdam. After his studies, he worked as a consultant in the medical device industry for more than six years, writing technical documentation and implementing quality systems. The opportunities and challenges associated with AI made him decide to join Aidence to help further improve healthcare.

Connect with Leon on

About Ricardo

Ricardo is Compliance Officer at AidenceAfter finishing his BSc in European Public Health, Ricardo went on to study for the MSc Healthcare Policy, Innovation & Management at Maastricht University. During this time, he joined Aidence as a regulatory team intern. He became invested in AI as he believes it will have a massive positive impact on healthcare in the future and is fascinated by the amount of (regulatory) developments in this field. After graduating, he joined Aidence as Project Support Officer, facilitating and coordinating various regulatory compliance and product development projects. He is grateful to work among driven colleagues and keen to have a positive impact on patient health.

Connect with Ricardo on

Aidence is now DeepHealth. Learn more about our AI-powered health informatics portfolio on


Book a demo

    * Required fields.
    For more information on how to unsubscribe, our privacy practices, and how we are committed to protecting and respecting your privacy, please review our Privacy Policy.
    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.