Design Changes: Examples and Requirements

Tuesday, March 24, 2020

A design change is a change in the design of a device. It is important to understand when such a change is considered a significant design change because the regulatory authorities and notified bodies usually have to be informed of significant design changes and the device usually has to be re-authorized.

Manufacturers in Europe can no longer make use of the transitional periods established in Article 120 of the MDR when making a significant design change.

Manufacturers whose existing class I devices have to be reported to notified bodies for the first time under the MDR are also affected.

This article will explain to you which design changes are considered significant and help you avoid breaking medical device law, something which can even be punished by imprisonment!

1. Design change: what it means »

a) Definition

Whenever something is changed in the design of a medical device, a design change is implemented.

Therefore, a design change is not (just) a change in the (visual) design of a device.

Rather, it is any change to the conceptual design of a device after its release, regardless of whether this change has to be reported or not.

b) Examples

We would also talk of a design change when the manufacturer changes:

• The layout of a circuit board
• The user interface
• The device functions (because something needs to be changed in their design)
• The performance information, e.g., the accuracy of a diagnostic device or the energy emitted by an HF surgical device
• The materials that a device is made of

If a software developer detects a bug during unit testing and then corrects it, this is not a design change. However, if they detect an error in the approved architecture and fix it (implicitly in the code and/or explicitly in the design document), a design change has taken place.

As we have already mentioned, the MDR also considers a change in the intended purpose, e.g., new indications or a different user group, to be a design change.

c) Relevant documents

In addition to system and software designs, design changes can also involve changes to mechanisms, electronics, materials and even the design input itself, including the intended purpose(!).

2. Regulatory requirements

a) FDA design change requirements

The FDA has realized that solutions to problems often cause new problems. For this reason, they demand that manufacturers assess these “solutions” (changes) very carefully before implementing them.

More specifically 21 CFR § 820.30(i) “Design changes” states that:

Each manufacturer shall establish and maintain procedures for the identification, documentation, validation or where appropriate verification, review, and approval of design changes before their implementation.

To reiterate what the FDA says in this paragraph:

1. Ensure that your documents are revised and managed accordingly (e.g., the version number is correct and they are approved).
2. Ensure, through verification and validation, that the problem that is intended to be solved with this design change is actually solved.
3. Make sure that the changes are approved and check that no new problems have been caused by the change and that the previous requirements are still met.
4. Communicate the changes so that other development departments, the production and sales departments, and customers know about them.

b) ISO 13485 regarding design and development changes

There are requirements as to how to handle design changes in Europe too. In section 7.3, ISO 13485 sets out how design and development changes should be managed.

The requirements are the same as the FDA's. So the changes must be:

• Approved
• Reviewed
• Verified and validated
• Documented

c) MDR

The EU Medical Device Regulation (MDR) discusses design changes at several points, for example:

• Article 10(9): “Changes in device design […] shall be adequately taken into account in a timely manner.”
• Annex VI, part C, 6.5.2 (Software): “A new UDI-DI shall be required whenever there is a modification that changes the original performance; the safety or the intended use of the software; interpretation of data. Such modifications include new or modified algorithms, database structures, operating platform, architecture or new user interfaces or new channels for interoperability.”
• Annex IX, 4.10: “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.”  

Design changes also play a role in the transitional arrangements:

By way of derogation from Article 5 of this Regulation, a device with a certificate that was issued in accordance with Directive 90/385/EEC or Directive 93/42/EEC and which is valid by virtue of paragraph 2 of this Article may only be placed on the market or put into service provided that from the date of application of this Regulation it continues to comply with either of those Directives, and provided there are no significant changes in the design and intended purpose. 

MDR, Article 120

Many manufacturers find it hard to assess when a design change is substantial and needs to be reported. This is one of the reasons the MDCG published Guideline 2020-03 (see below).

d) Health Canada

Although a little older, Health Canada's guidelines are still helpful, up-to-date and very comprehensive. The authority published the “GUIDANCE DOCUMENTfor the Interpretation of Significant Change” back in 2011.

The flowcharts on IVDDs and on changes to manufacturing, facilities and labeling are particularly worth looking at.

3. Significant design changes: when does a design change need to be reported?

a) NBOG guidance document

The Notified Body Operations Group (NBOG) has published a “Guidance for manufacturers and Notified Bodies on reporting of Design Changes and Changes of the Quality System” that aims to provide more clarity.

Here the authors explain when a design change should be considered substantial and must, therefore, be reported. Any change to a device that could influence conformity with the essential requirements or the scope of application or contraindications established by the manufacturer is considered a substantial change.

More specifically, the document mentions changes:

• To the intended purpose, indication, or contraindication
• To the performance specification
• Of suppliers(!)
• Due to hazards that have not previously been addressed
• To warnings
• Of the intended user groups
• Of the intended use
• To characteristics that have not previously been taken into account in the clinical evaluation
• Resulting from actions taken related to concerns arising from post-market surveillance including incidents/recalls/complaints
• Driven by the development of the state of the art (e.g. latest technology)
• That affect production
• That affect the safety and performance of the device

b) MDCG 2020-03

In March 2020, the MDCG published the guideline “MDCG 2020-03” entitled “Guidance on significant changes regarding the transitional provision under Article 120 of the MDR with regard to devices covered by certificates according to MDD or AIMDD.”

The aim of this guideline is to clarify to manufacturers when a design change has to be reported and when it does not.

Design changes that do not have to be reported

The MDCG explains which design changes it deems do not have to be reported:

• Administrative changes
  • Changes to the manufacturer's name and address
  • Changes to the manufacturer's legal form e.g., from GmbH to GmbH & Co. KG
  • Changes of authorized representative
• Organizational changes
  • New manufacturing sites, relocation of manufacturing sites
  • New or changed suppliers and service providers
  • Certain changes to the QM system
• Limitation of the intended purpose
• Corrective actions
• Non-significant changes to the device

According to MDCG 202-03, manufacturers can obtain confirmation from notified bodies that a design change is not significant. However, this does not constitute the issuance of a “supplemented certificate.”

Design changes that have to be reported

The MDCG defines the following changes as “significant”:

• Extension of or changes to the intended purpose, e.g., new indications, new patient population, different clinical use
• UI changes that require further usability data
• Changes in the performance specification, particularly if they require new clinical data to be considered
• Design changes that either increase risks or affect existing risk-minimizing measures, e.g., alarms
• Replacement or change of materials, unless they come from existing suppliers and take and occur within unchanged specifications
• Changes to the sterilization process or packaging that could have an effect on sterility

A lot of software changes

By its very nature, the document leaves questions open. We would have liked answers to the following questions in particular:

• How should manufactures decide when it comes to changes in the manufacturing process? With the exception of sterilization, the MCDG does not offer any help.
• Does it really want to wave through all corrective actions, even if they involve significant design changes? The sequence of the flow chart suggests exactly that.
• Why does it want to wave corrective actions through but not corrections? Software bug fixes are not considered “significant.”
• Does “New user or patient population” also include “Changed user or patient population”? I’d guess so.
• Does “existing risks negatively affected” mean that the existing risks are higher?
• Does every change to a risk-minimizing action really have to be considered a significant design change? Including a preventive action, e.g., the more effective design of such an action? This could set false incentives.
• Should every change to a database structure really be considered significant? Every new column in a database?
• Which changes to the user interface (for software) are now significant? Even if you add the missing spaces to the text, it is still unclear.
• What changes to improve IT security do the authors want? If the change is a “major change of a component”, then it would not be allowed. The replacement of a cryptography library or a corresponding procedure would surely be “major.” Decision C6 reaches a different conclusion.

c) Guidance from the notified bodies (NB-MED)

The document NB-MED/2.5.2/Rec2 contains concrete definitions and examples of reportable and non-reportable design changes.

d) CAMD FAQs

In its FAQ, the CAMD (Competent Authorities for Medical Devices) also addresses the question of when a design change is “significant.” However, the answer to question 17 does not really contain anything new that is not in the MDCG document.

e) Scope of the certificate

The scope of the certificate is also decisive. If you want to modify your device that you have placed on the market via Annex II of the MDD or Annex IX of the MDR in a way that means it no longer falls within the scope of these annexes, you cannot do this without involving the notified body.

The certificates only allow you as a manufacturer to develop and place on the market (without asking the notified body for permission) devices within the certificates. However, notified bodies often request to be informed.

4. Software - a special case

This chapter summarizes the legal requirements and guidelines for software.

Software design changes that have to be reported

A software design change would presumably have to be reported under one of the following conditions:

• A change has been made to the intended purpose, including
  • the intended use environment
  • the intended user groups
  • new or other indications
  • fewer contraindications (i.e., an extension of the intended purpose)
• You rectify an error in the software or corresponding instructions for use in order to minimize risks (> recall)
• You change the user-device interface (except for insubstantial changes such as the correction of spelling mistakes). This particularly applies if you
  • add, change or remove warning messages
  • add new safety-related use scenarios
  • change critical UI elements (formerly main operating functions)
• You use a new technology, e.g. a new framework, new SOUPs (or a new (version of the SOUP), or even a different programming language
• The software is to be used in a different runtime environment (operating system or version, processor, screen size/resolution)
• The software has to operate a new data interface.
• The developers add new tables or external references to a database
• The developers change a central algorithm, e.g., algorithms for calculating medicine doses, for radiation treatment planning or for image processing
• This applies in particular to the replacement of conventional algorithms with AI algorithms or a change in AI model (e.g., boosting technique instead of a neural network).

Software design changes that do not have to be reported

Usually, the following changes to software do not have to be reported:

• Bug fixes
• Security patches
• Updating of a SOUP to a newer version
• Small refactorings e.g., within a method
• Changes to non-critical parts of the user interface
• Adding an attribute to a database or changing the data type of an attribute
• Adapting the software in order to work with new versions of an existing interface specification (e.g., updating from HL7 V2.7 to 2.8)
• Small design changes to the user interface
• Small measures to improve non-functional properties, such as robustness (e.g., additional value checking)

General tips

The Johner Institute recommends making clear arrangements with your notified body. The aim of the above list is to help you with this. The free micro-consulting service is available to a limited extent to manufacturers, regulatory authorities and notified bodies for such assessments.

The differentiation the MDR and IVDR make between software changes that require a change to the UDI-DI and those that “only” require a change to the UDI-PI may be useful for helping you decide what is a reportable change and what is a non-reportable change. A change in the UDI-PI does not usually have to be reported.

5. Conclusion and summary

With its document 2020-03, the MDCG provides a good tool for differentiating between significant and non-significant design changes.

In a second version of the document the authors should

• Remove the obvious errors (we manufacturers wouldn’t let something like that through)
• Provide even more clarity with additional examples and explanations regarding the decision points (as, for example, in MDCG 2019-11)
• Add the missing references, e.g., to the CAMD document
• Add information regarding for manufacturing changes, IVDDs and labeling
• Check whether the effects caused by, for example, the sequencing of the sequence of questions are really what they intended

The extent to which manufacturers and notified bodies adhere to the MDCG's specifications remains to be seen. Sometimes, as a consequence of both sides being overloaded, there seems to be a tacit agreement that a design change is non-significant.

The large number of regulatory requirements means that global harmonization would be very welcome.