• Close menu
  • Home
  • Consulting
    • Technical Documentation
      • Software (IEC 62304, FDA)
      • Risk Management (ISO 14971)
      • Clinical Evaluation
      • AI Medical Devices
    • Quality Management (QM)
      • QM System (ISO 13485)
      • Mock Audits & Inspections
      • Quality Representative
    • Services
      • Human Factors Engineering
      • Regulatory Affairs
  • E-Learning
    • Training videos
      • Market your medical device
      • Content
      • Premium Version
      • Watch training videos
  • Training Seminars
    • Medical Device Regulation
    • CPMS Seminar
    • Medical Device Software
    • Human Factors Engineering
    • Risk Management Seminar
    • Inhouse Seminars
    • Medical Device Regulatory Affairs
  • Articles
    • Regulatory Affairs
      • Medical Device Regulation
      • IVD Regulation (IVDR)
      • Medical Device Directive
      • Classification
      • CE Marking
      • Conformity Assessment
      • Harmonized Standards
      • Technical Documentation
      • MEDDEV 2.7/1
      • FDA
        • Breakthrough Devices
        • Safer Technologies Program
      • And more ...
        • CFDA, NMPA
        • Measuring Function
        • Distributor Requirements
        • Class 1 Medical Devices
        • 21 CFR Part 11
        • NAKI - The German National Working Group
        • Accessories for Medical Devices
        • Declaration of Conformity
        • Design input
        • Design Change
        • Measuring Function
        • Essential Requirements
        • GDPR
        • EUDAMED
        • Free Sales Certificates
        • Harmonized Standards
        • IVD Software
        • Laboratory Developed Tests
        • MDR Rule 11 (Software)
        • MEDDEV Documents
        • Notified Bodies
        • Periodic Safety Update Report PSUR
        • Post-Market Surveillance
        • Premarket Approval (510k)
        • Systems & Procedure Packs
        • Technical File versus DHF
        • Unique Device Identification
        • Physiological processes
        • Medizinprodukte-Durchführungsgesetz (MDG)
        • 3D Printing in Medicine: Avoiding Regulatory Traps
        • Qualified Person
    • QM System & ISO 13485
      • Audits
      • CSV
      • Document Control
      • ISO 13485:2016
      • MDSAP
      • Process Validation
      • Supplier management
      • Quality Policy & Objectives
      • Risk Based Approach
      • And more...
        • Electronic signatures
        • Unannounced Audit
    • Software & IEC 62304
      • Software as Medical Device
      • Software Lifecycle
        • Agile Software Development
        • Software Requirements
        • Software Architecture
        • Code Reviews
        • Coding Guidelines
        • Software Testing
      • Safety Classes & Level of Concern
      • SOUP and OTS
      • Medical Apps
      • IT-Security
      • Artificial Intelligence
      • And more...
        • Parameterization
        • Creating standard operating procedures for QM
        • Anonymization and Pseudonymization
        • IEC 60601-4-5
        • CVSS – Common Vulnerability Scoring System
        • Medical grade software
    • Risk Management & ISO 14971
      • Life Cycle Risk Management
      • Update 14971:2012
      • Harm and Severity
      • Hazard and Hazardous Situation
      • Risk Acceptance
      • Risk Mitigation
      • Risk Analysis
      • Software Specifics
      • Third edition of ISO 14971
    • Usability & IEC 62366
      • Main Operating Functions
      • ISO 9241
      • User stories
      • Usability Validation
      • Heuristic Evaluation
    • Product Development
      • Intended Use Description
      • System Architecture
      • Clinical Evaluation
      • Verification versus Validation
      • Biocompatibility - ISO 10993
      • And more ...
        • 2. Amendment to IEC 60601-1
        • Multiple socket-outlets on medical devices
  • Login
  • Logout
  • Contact Us
  • About us
Search
+1 (301) 244-6335

info@johner-institute.com
  • LoginI
  • Contact UsI
  • About us
Search
Logo Johner Institut
  • Display menu
  • Close menu
  • Home
  • Consulting
    Technical Documentation
    • Software (IEC 62304, FDA)
    • Risk Management (ISO 14971)
    • Clinical Evaluation
    • AI Medical Devices
    Quality Management (QM)
    • QM System (ISO 13485)
    • Mock Audits & Inspections
    • Quality Representative
    Services
    • Human Factors Engineering
    • Regulatory Affairs
  • E-Learning
    Training videos
    • Market your medical device
    • Content
    • Premium Version
    • Watch training videos
  • Training Seminars
    Medical Device Regulation
    CPMS Seminar
    Medical Device Software
    Human Factors Engineering
    Risk Management Seminar
    Inhouse Seminars
    Medical Device Regulatory Affairs
  • Articles
    Regulatory Affairs
    • Medical Device Regulation
    • IVD Regulation (IVDR)
    • Medical Device Directive
    • Classification
    • CE Marking
    • Conformity Assessment
    • Harmonized Standards
    • Technical Documentation
    • MEDDEV 2.7/1
    • FDA
    • And more ...
    QM System & ISO 13485
    • Audits
    • CSV
    • Document Control
    • ISO 13485:2016
    • MDSAP
    • Process Validation
    • Supplier management
    • Quality Policy & Objectives
    • Risk Based Approach
    • And more...
    Software & IEC 62304
    • Software as Medical Device
    • Software Lifecycle
    • Safety Classes & Level of Concern
    • SOUP and OTS
    • Medical Apps
    • IT-Security
    • Artificial Intelligence
    • And more...
    Risk Management & ISO 14971
    • Life Cycle Risk Management
    • Update 14971:2012
    • Harm and Severity
    • Hazard and Hazardous Situation
    • Risk Acceptance
    • Risk Mitigation
    • Risk Analysis
    • Software Specifics
    • Third edition of ISO 14971
    Usability & IEC 62366
    • Main Operating Functions
    • ISO 9241
    • User stories
    • Usability Validation
    • Heuristic Evaluation
    Product Development
    • Intended Use Description
    • System Architecture
    • Clinical Evaluation
    • Verification versus Validation
    • Biocompatibility - ISO 10993
    • And more ...
  • Regulatory Affairs
    • Medical Device Regulation
    • IVD Regulation (IVDR)
    • Medical Device Directive
    • Classification
    • CE Marking
    • Conformity Assessment
    • Harmonized Standards
    • Technical Documentation
    • MEDDEV 2.7/1
    • FDA
    • And more ...
      • CFDA, NMPA
      • Measuring Function
      • Distributor Requirements
      • Class 1 Medical Devices
      • 21 CFR Part 11
      • NAKI - The German National Working Group
      • Accessories for Medical Devices
      • Declaration of Conformity
      • Design input
      • Design Change
      • Measuring Function
      • Essential Requirements
      • GDPR
      • EUDAMED
      • Free Sales Certificates
      • Harmonized Standards
      • IVD Software
      • Laboratory Developed Tests
      • MDR Rule 11 (Software)
      • MEDDEV Documents
      • Notified Bodies
      • Periodic Safety Update Report PSUR
      • Post-Market Surveillance
      • Premarket Approval (510k)
      • Systems & Procedure Packs
      • Technical File versus DHF
      • Unique Device Identification
      • Physiological processes
      • Medizinprodukte-Durchführungsgesetz (MDG)
      • 3D Printing in Medicine: Avoiding Regulatory Traps
      • Qualified Person
  • QM System & ISO 13485
    • Audits
    • CSV
    • Document Control
    • ISO 13485:2016
    • MDSAP
    • Process Validation
    • Supplier management
    • Quality Policy & Objectives
    • Risk Based Approach
    • And more...
  • Software & IEC 62304
    • Software as Medical Device
    • Software Lifecycle
    • Safety Classes & Level of Concern
    • SOUP and OTS
    • Medical Apps
    • IT-Security
    • Artificial Intelligence
    • And more...
  • Risk Management & ISO 14971
    • Life Cycle Risk Management
    • Update 14971:2012
    • Harm and Severity
    • Hazard and Hazardous Situation
    • Risk Acceptance
    • Risk Mitigation
    • Risk Analysis
    • Software Specifics
    • Third edition of ISO 14971
  • Usability & IEC 62366
    • Main Operating Functions
    • ISO 9241
    • User stories
    • Usability Validation
    • Heuristic Evaluation
  • Product Development
    • Intended Use Description
    • System Architecture
    • Clinical Evaluation
    • Verification versus Validation
    • Biocompatibility - ISO 10993
    • And more ...

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.

  Summary of contents

1. What it means »

2. Regulatory requirements »

3. Reporting to the notified bodies »

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.

Design Change Picture

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.

Company

  • About us
  • Contact
  • About Prof. Dr. Johner
  • Our customers
  • Imprint
  • Privacy Policy

Links

  • Consulting
  • Login Auditgarant
  • Trainings
  • Articles

Products

  • Auditgarant (E-Learning)
  • CPMS Seminar
  • Usability Seminar

Free offers

  • Starter-Kit
  • Ask an expert
  • SSRS-Checklist
ISO 13485:2016
Logo Johner Institut

This site uses cookies. By using this website, you agree to the use of cookies.

For more information see our Privacy Policy