Is my Software Application a Medical Device & if so, do I need to CE mark it?

This blog will show you the steps for categorising your software application & identifying the relevant regulations …

The world of #software is ‘fluid’ and ‘dynamic’, partly due to its virtual nature. Features can be added and removed, and this can impact the intended use and performance of software. As such, general use software (aka, that was not originally classified as a #medicaldevice under the #EUMedicalDevice Regulation (#MDR) 2017/745 or #InVitroDiagnostic Regulation (#IVDR) 2017/746), may now be qualified as a medical device and fall under the umbrella of these regulations.

How is medical device software described?

• Software as a medical device?(#SaMD)?is a standalone software; it does not integrate with hardware.
• Medical device software (#MDSW)?is defined as a medical device regardless of its location (i.e. in the cloud, on a computer/mobile etc). It must have its own medical purpose that drives or influences a hardware medical device.

MDCG 2019-11 describes an MDSW as software?that is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the medical devices regulation or in vitro diagnostic medical devices regulation”.

Let’s understand what distinguishes an MDSW from a general-use software

Decision Trees for Determining Software Type

Firstly, how do you determine if you have an MDSW as opposed to a general software application?

Within MDCG 2019-11, there are two useful decision trees to aid the classification of your software.??

The first decision tree features five steps to determine if you have an MDSW and whether it comes under the #regulations.

Once you have determined the status of your software as MDSW, the second decision tree guides you on whether your MDSW falls under the EU MDR or IVDR.

Case study?

NOT a Medical Device Software (MDSW)

Let’s say you have a software application that is used in the IT administration #network of a hospital setting. The software is handling and matches patient details to a schedule for #Invitro diagnostic tests or other procedures that a medical professional has logged for the patient. The software does not handle, match, transfer or have any processing interaction with the test results of the patient. It is an automated administrative hospital/laboratory planner to help organise and streamline internal processes for when tests or appointments are to be done and patient discharge.

In this scenario, it would?NOT?be classified as a software medical device. This is because the system is directly administered to bring benefit to #hospital workers, #health professionals etc., by streamlining the planning of work schedules.??

Becomes a Medical Device

Let’s think about #Electrocardiograph (ECG) Systems… A system for managing pre-hospital ECG that is a software-based system intended for ambulance services to store and transfer information from patients to a doctor at a #remote location. Usually, the system contains information about #patient identification, vital parameters and other documented clinical observations. These Pre-hospital Electrocardiograph (#ECG) Systems are not qualified as #medicaldevices.

Modules that create and provide new patient treatment information to the paramedics or to the doctor at a remote location to start the patient’s treatment while the patient is being transported, are qualified as medical devices.

Changes to Software Applications

Taking the case study above into consideration, it is important to evaluate the potential impact of any changes to the function, intended use, essential design, and manufacturing characteristics on the software’s qualification as an MDSW and its classification, including the classification of the combination of the MDSW with another #medicaldevice.

Changes in the software or the addition of functionality can affect your software being classified as an MDSW or a change to the classification of the MDSW. An addition of a new module to the software could be classified as an MDSW on its own.

It is important if changes are being made to your software that, you carry out a thorough review to determine whether it falls within the definition of MDSW.

Does the whole system need to be CE Marked or just the Software Application?

These case study examples raise the question of whether the applications need to be #CE marked or whether this would be dependent on each module.

If the modules are classified as MDSW, and it’s intended for use in combination with other modules not classified as MDSW or other devices/equipment, the whole combination needs to be proven as safe and that it does not impair the performance of the MDSW.

Note: The manufacturer must determine the boundaries and interface of the different modules with a clear intended use documented.

EU MDR

Under Annex VIII –?classification rules of the MDR, Rule 11 will need to be applied for your MDSW. The rule has been broken down into sub-sections below with the applicable class:

Class III:?Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes only if these decisions can lead, as a consequence, to “death or an irreversible deterioration of #health conditions“

Class IIb:?software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes, or to monitor vital #physiological parameters, only if these decisions can lead, as a consequence, “a serious deterioration of a person’s state of health or a surgical intervention”.

Class IIa:?Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes, or to monitor vital physiological parameters, only if these decisions cannot lead, as a consequence, to “death or an irreversible deterioration of health conditions” or “a serious deterioration of a person’s state of health or a surgical intervention”.

Class I:?Any other software.

EU IVDR

Under Annex VIII –?classification rules of the IVDR, all classification rules under this annex will need to be taken into consideration as the application of the classification rules is governed by the intended purpose of the MDSW.

Software Safety Classification to IEC 62304?

Alongside the classification of a #softwaredevice under the #MDR or #IVDR, #MDSW is required to be classified under #IEC 62304 – Medical device software – Software Life Cycle Processes. The international standard documents a safety classification system based on the risk of harm to the user and the probability of occurrence.??

• Class A – no injury,
• Class B – non-serious injury
• Class C – serious injury or death.

The classification identified within IEC 62304 is used for the basis of determining how rigorous the software development process will need to be. Although classification under IEC 62304 is separate from device classification under the #EU MDR 2017/745 or IVDR 2017/746, the classifications correlate between the requirements, e.g. the higher the classification under the regulations, the higher the risk class under IEC 62304.

LFH Regulatory can help…

We have a team of experts who can assist with the classification of your Medical Device Software and gaining market access. Contact us today on?tel: +441484662575?or via?[email protected]?to see how we can help.

References

MDCG 2019-11 – Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR (October 2019)

IEC ISO 62304-2015 Medical device software – Software life cycle processes

Co-authored by:

Laura Friedl-Hirst ,?Managing Director and Principal Consultant. Laura has over 11 years of experience within the medical device and IVD industry, working with a vast range of product types which include SaMD, custom-made, active and implantable devices. She has expertise in regulatory affairs, quality assurance and clinical evaluation writing.

Ashfaaq Ismail ,?Regulatory & Quality Consultant. Ashfaaq has over ten years of experience within the medical device/IVD industry from a regulatory and quality perspective, including GMP and ISO13485. He has spent over four years of this concentrating on software as a medical device/IVD.