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


This blog series discusses the Medical Device Regulation (MDR) in brief and how it affects software development for medical devices. In this second part we will discuss the conformity assessment routes, software modules and impact of changes.

Read the first part of the blog series about software qualification and risk classification here.

Checklist for Medical Software Development (2/4) 

The key points to consider regarding the conformity assessment route, software modules and impact of changes:

  • Confirm the conformity assessment route for the medical device/software
  • Identify the medical device modules in healthcare software systems and analyze their risks
  • Assess any change to a MDD/AIMD certified device for its significance
  • Evaluate the potential impact of any change on qualification and classification

Considerations on Placing Medical Software on the Market

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. 

Software Modules

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. 

Impact of Changes


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. 

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. 

Identifying significant software changes

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. 

Impact of changes on qualification or classification

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

Juha Sippola

Juha Sippola

I work as a software developer and quality control manager in the health and wellness technology unit at Pinja. I’m very interested in quality control, and I have over 15 years of experience in tasks related to mobile devices and health tech. In my free time, I exercise by skiing, cycling and going to gym, among other things.

Read more from this author