Design change: examples and requirements

When they hear the term design change, many immediately think of the FDA. The administration makes specific demands as to how design changes are to be managed.

However, in Europe too there are regulations that you must take into account.

Find out here what they are and see typical examples of design changes that must be reported.

1. Design change: what it means

a) Definition

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

Design change not only refers to a change in the graphic design of a product but to any change to the conceptual design of a device after its release.

b) Examples

When a software developer detects during unit testing that there is a bug and then corrects it, this is not a design change. However, if they detect that the approved design has an error and then change it (implicit in the code and/or explicit in the design document) a design change has taken place.

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

• the layout of a circuit board
• the user to device interface
• the device functions (because something needs to be changed in their design)
• the size, weight or materials that a device is made of.

But how small must a change be to avoid reporting it to a notified body? Find out more about this below.

c) Relevant documents

A design change not only affects system and software designs but also changes to mechanisms, electronics, materials and even the design input itself.

2. Regulatory requirements

a) FDA design change requirements

The FDA has established that solutions to problems often lead to 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 correspondingly (e.g. the version number is correct and they are approved).
2. Ensure through verification and validation that the problem that is to be solved with this design change is actually solved.
3. Make sure that the changes are approved and assess that no new problems can be 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

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

The requirements are the same as those of the FDA: the changes must be

• approved
• reviewed
• verified and validated and
• documented.

c) MDR

The EU Medical Device Regulation MDR discusses design changes at several points, such as:

• 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 context of 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.

3. When a design change needs 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 is to be considered substantial and so must be reported. This concerns any change to a device that could influence conformity with the basic requirements or the scope of application or contraindications established by the manufacturer.

More specifically, the document mentions changes

• to the intended purpose, indications, contraindications
• to performance specifications
• 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 yet been taken into account by the clinical evaluation
• resulting from actions arising from post market surveillance including incidents, recalls or complaints
• driven by the development of the state of the art (e.g. latest technology)
• that influence production
• that affect the safety and performance of the device.

b) Software design changes that must 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 any change to the intended usage environment and the intended users;
• you rectify an error in the software or corresponding instructions for use in order to minimise risks (> recall);
• you change the user to device interface (except for insubstantial changes such as the correction of spelling mistakes). This particularly applies if you add, change or remove warning messages;
• in this context the new or changed user scenarios or even their criticality would consequently need to be reported;
• you use a new technology, e.g. a new framework, new SOUPs or a new (version of the) programming language;
• you create developments for another runtime environment (operating system or version, processor, screen size/resolution);
• you change a central algorithm, e.g. to calculate medicine doses, for radiation treatment planning or for image processing.

Here too, Johner recommends that you make clear arrangements with your notified body. The aim of the above list is to help you with this.

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

We also recommend that you read the document NB-MED/2.5.2/Rec2. It contains specific definitions and examples of design changes that do and do not need to be reported.