How to classify medical signal or image analyser software

One question we at Hardian get asked a lot is how to classify products for regulatory purposes that take an input from a sensor, and then process that signal using software. The answer depends on the intended purpose of the sensor, and the intended purpose of the output.

In many system architectures, we have some kind of sensor, which is normally ‘smart’ in that it is microcontroller or microprocessor-based, feeding an algorithm. This could be an ECG device, OCT scanner, wearable or digital thermometer, for example. The processing algorithm can be artificial intelligence or machine learning – but any type of process or rules for calculations or problem-solving counts.

There are two types of software here:

Software in a Medical Device (SiMD) – software embedded in a device with a fixed purpose, e.g. the software in a digital thermometer.

Software as a Medical Device (SaMD) – that is our software running on a general computing platform e.g. cloud server, or even in a smartphone or smartwatch.

To put it in the form of a diagram:

Before we can classify our processing software, we need to consider the classification of the input device, as the classification of that can have a bearing on the classification of our product as a SaMD (from the European Union perspective, for CE marking).

Note, we are working on the assumption that no analysis with a medical purpose is carried out in the input device, rather the input device is purely to capture data that will be analysed by our SaMD.

Intended purpose of the sensor	Classification (EU)
To capture images of skin lesions – for the detection of conditions such as cancer, not actually carried out in the input device	Class I Medical Device <= EU MDR Annex VIII Rule 10 “Active devices … intended to illuminate the patient’s body in the visible spectrum” or not a separately classified medical device <= EU MDR Article 22(c)
To capture breath samples – for the detection of conditions such as Chronic Obstructive Pulmonary Disease (COPD), not actually carried out in the input device	Class A In vitro Diagnostic Medical Device <= EU IVDR Annex VIII Rule 5(b) “instruments intended by the manufacturer specifically to be used for in vitro diagnostic procedure”/ EU Borderline Manualsection 2.1.1 Borderlines between IVDs and medical devices which makes the point that “exhaled air is no longer part of the human body and therefore the exhaled air is considered to be a gaseous specimen derived from the human body, which is subsequently analysed by a device outside of the body” If classified as a general medical device then this would be in Class IIa <= EU MDR Annex VIII Rule 10 “Active devices intended for diagnosis and monitoring are classified as class IIa”/ MDCG 2021-24 Note 3 on page 43 “… medical devices intended to be used to obtain readings of vital physiological signals as part of routine checkups or self-monitoring are in class IIa” or not a separately classified medical device <= EU MDR Article 22(c)
To capture an electrocardiogram (ECG) signal – for the detection of conditions such as heart arrhythmias	Class IIa Medical Device <= explanation of EU MDR Annex VIII Rule 10 on page 42 of MDCG 2021-24even when the analysis is not carried out on the sensor hardware, but instead e.g. in the cloud
To capture an electroencephalogram (EEG) signal – for the detection of conditions such as epilepsy
To capture images of the human eye using Optical Coherence Tomography (OCT) – for detection of various retinal conditions
To capture diagnostic x-ray images – for triage/ detection/ diagnosis of various conditions	Class IIb Medical Device <= explanation of EU MDR Anne x VIII Rule 10 on page 42 of MDCG 2021-24even when the analysis is not carried out on the sensor hardware, but instead e.g. in the cloud
To capture heart rate using the PPG sensor on a consumer-grade smartwatch	Not a medical device until a processing algorithm with a medical purpose is added – see also our article about wearables and their companion apps in the EU regulatory framework
To collect patient information into an electronic health record (EHR) for clinical decision support (CDS)

Here are some examples of the processing and output software that go with such input devices, and their classification:

Intended purpose of processing + output	Classification (EU)
To triage/ detect/ diagnose lesions that are suspicious of skin cancer	Class IIa or higher Medical Device depending on setting <= EU MDR Annex VIII Rule 11/ MDCG 2021-24explanation of Rule 11 on page 44
To triage/ detect/ diagnose conditions such as Chronic Obstructive Pulmonary Disease (COPD)	Class IIa or higher Medical Device depending on setting <= EU MDR Article 2(1) definition of a medical device, which is a better fit for the SaMD’s intended purpose than the EU IVDR Article 2(2) definition of an in vitro diagnostic medical device/ MDCG 2021-24explanation of Rule 11 on page 44
To triage/ detect/ diagnose conditions such as heart arrhythmias from ECG signal	Class IIa, IIb or III Medical Device depending on setting <= EU MDR Article 2(1) definition of a medical device/ MDCG 2021-24explanation of Rule 11 on page 44; also depending on whether the device is driving or influencing the use of the input device e.g. software is controlling laser power (for OCT) or x-ray dose
To triage/ detect/ diagnose conditions such as epilepsy from EEG signals
To triage/ detect/ diagnose particular conditions from OCT images
To triage/ detect/ diagnose particular conditions from x-ray images
To detect cardiac arrhythmias from the PPG sensor built into consumer-grade smartwatches
To triage/ detect/ diagnose particular conditions from the underlying data in a patient’s EHR

So, there you have it - a simple guide to finding the correct classification for CE marking for your signal processing software.

Hardian Health is a clinical digital consultancy focused on leveraging technology into healthcare markets through clinical strategy, scientific validation, regulation, health economics and intellectual property.