Medical software development according to Medical Device Regulation (MDR) – part 2: Conformity assessment route, software modules and impact of changes

Part 1. The MDR in brief and the software qualification and risk classification

The type of interconnection between the medical software and the device (e.g. embedded systems, wires, Wi-Fi, Bluetooth) does not affect the qualification of the software as a device under the MDR (e.g. whether the software is incorporated in a device or is at a different location). However, medical software can be placed on the market in two different ways: 

• As a medical device in its own right
• As an integral component or part of a hardware device

Software placed on the market as a device, or put into service in its own right, shall undergo an appropriate regulatory process that shall take into consideration the qualification, classification and intended purpose of the software.

Software that is placed on the market or put into service solely as an integral component or part of a (hardware) device may not have to undergo its own regulatory process. In this case, the software shall be assessed through the regulatory process applied to the device as a whole. 

Some medical device software may be segregated into several applications or modules. Some of these modules have a medical purpose, some not. The medical device modules are subject to the MDR and must comply with medical device requirements and carry the certification for CE marking.

The non-medical device modules are not subject to the requirements for medical devices. It is the obligation of the manufacturer to identify the boundaries and the interfaces of the different modules. The boundaries of the modules which are subject to the MDR should be clearly identified based on the intended purpose.

In such a combined system the whole computer program, including the connection system, must be safe and must not impair the specified performances of the medical device modules. Risk analysis should consider, e.g. a case when a non-medical device module eats system resources leading the medical device module to fail or to operate with unacceptable performance. 

A significant change in design or intended purpose of a device after the date of application of the MDR may prevent the manufacturer from continuing to place that device on the market until compliance with the MDR has been established (Article 120-3). In addition, the medical device qualification or classification may be impacted by any change when already applying the MDR. 

Here the focus is only on software changes. Other changes, e.g. to intended purpose, specifications or materials, must be analyzed separately.

Minor changes (if no impact to diagnosis or treatment delivered) may include:

• Correction of an error which does not pose a safety risk
• Security update
• New non-medical features
• Appearance of the user interface (e.g. new languages, layouts or graphics)
• Operating efficiencies

The following changes are considered significant (if they have an impact on diagnosis or treatment delivered):

• New or major change of operating system
• New or modified architecture or database structure
• Change of an algorithm
• Required user input replaced by closed loop algorithm
• New feature or new channel in interoperability
• New user interface or presentation of data (connected to medical data which are presented in a new format or by a new dimension or measurement unit)

If the assessment concludes that the change is a significant change in design, the implementation of the change prevents the manufacturer from continuing to place that device on the market with an MDD/AIMDD certificate after the MDR transition period end date (26-May-2020). MDR certification is required instead. 

Manufacturers shall evaluate the potential impact of any changes to the function, intended purpose, essential design, and manufacturing characteristics on the software’s qualification as MDSW and its classification (including the classification of the combination of the MDSW with another medical device).

It is to be noted that a change to or addition of functionality to software may lead it to be qualified as MDSW, or a revision of the classification of the MDSW. Similarly, a module that is added to a software system might be qualified as a MDSW on its own.

When determining the risk class of a combination of a modified MDSW and a medical device, the intended purpose and functionality of that (new) combination must be considered.

Download our free guide: Medical Device Regulation on Software Development – Key points to consider

References:

Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745
Guidance on significant changes (MDCG 2020-3)

Read more

Blog: Medical Software Development according to Medical Device Regulation (MDR) – Part 1: Software Qualification and Classification
Blog: Medical Software Development according to Medical Device Regulation (MDR) – part 3: Quality management system
Blog: Medical software development according to Medical Device Regulation (MDR) – part 4: Medical device software lifecycle processes
Guide: Medical Device Regulation and Software Development – Key points to consider
Evondos success story
Synoste success story
BioMediTech success story
Welfare and health technology