Informational EU MDR Classification Rule 11 – what???

[Marcelo]

There’s a bit of discussion in Elsmar about EU MDR Classification Rule 11. – Please explain MDR Rule 11 to me. Please feel free to join the discussion there.

Here is my comment:

Heh. It’s curious how this is already creating a workload of discussions.

Anyway, some historical info:

– Everyone (medical device people) used to use the word “standalone software” when a software was itself a device. However, when we were discussing this in the IMDRF software working group, it was noted that “standalone software” could be understood differently by software programmers with no medical device experience (and those were a special concern for the working group) so we ended up “creating” the term Software as Medical Device for the IMDRF documents.

– One of the confusing things with SaMD is that most of them work as IVDs (thus the focus of the categorization IMDRF document) – let’s call it SaMD1 – but a small percentage works as a common medical device (therapy, etc.) – Let’s call it SaMD2.

– Initial drafts of the MDR used the word “standalone software”, but this was removed.



– GSPR item 17 is a little more clear on the distinction:

17. Electronic programmable systems—devices that incorporate electronic programmable systems and software that are devices in themselves

– So, we basically have two types of software under the MDR? – Soft1 – devices that incorporate EPS (including software), and Soft2 – SaMD (can be SaMD1 or SaMD2)(please note that the MDR do not use this terminology).

In fact, we have 3. Soft3 – software that is incorporated into a device but is commercially available on its own (see the UDI requirements on Annex IV 6.5. Device Software).

(historical note – Soft1 was usually called “embedded software”. Soft3 would be then something like “embedded software is commercially available on its own”)

– Finally, from a generic perspective, Soft1 is a device which is not software (and the software is part of it). Software 2 is a device in itself. Soft3 is like Soft1. This is important because, When the MDR mentions only software, it “may” talking about Soft1, Soft2, or both.

Related to the original questions, it seems to me that the OP software is SaMD2 (most SaMD2 would be under the “software, which influences the use of a device (software with drives the device would be Soft1, although some SaMD1 could also influence the use of a device). Please note that, in this case, Rule 11 does not apply, because it’s a rule for software only, and the implementing rules says “Software, which drives a device or influences the use of a device, shall fall within the same class as the device”, meaning, you do not classify the software on it’s own.

Please note that rule 11 is mostly related to SaMD1, as it really mentions only the the types of software that works as IVDs, based on the IMDRF documents. I say mostly here because the second part is a bit weird (Software intended to monitor..) and it seems to be that it was included here as a general backup umbrella for some cases.

Posted at Marcelo's Medicaldevice.expert website...

You may comment and discuss in this discussion thread.

 

[Asia78]

Thanks Marcelo.
I have just one point I would like to understand better form you:
During the classification of your device, i was assuming the manufacturer has to classify only it's own device, excluding third party devices. Do you agree or disagree? Thanks

 

[Marcelo]

Thanks Marcelo.
I have just one point I would like to understand better form you:
During the classification of your device, i was assuming the manufacturer has to classify only it's own device, excluding third party devices. Do you agree or disagree? Thanks

Hello, not sure where the question com from, and the answer depends on more details. In general, year the manufacturer has to classify their device, but for example, your device use as an accessory a device from other manufacturer, you need to take this into account when classifying your device (for example, if your device is class IIa but the accessory is class IIb, the whole device is class IIb).

 

[Marcelo]

A correction of my original post which may be misleading – All rules are for medical devices, not for software. Rule 11 applies for a medical device that is a software in itself, that’s what I wanted to say. It does not apply to software embedded in a medical device because this software is not a medical device in itself, so classification rules cannot apply to it.

 

[Asia78]

Hello, not sure where the question com from, and the answer depends on more details. In general, year, the manufacturer has to classify their device, but for example, your device use as an accessory a device from other manufacturer, you need to take this into account when classifying your device (for example, if your device is class IIa but the accessory is class IIb, the whole device is class IIb).

I am not sure... The MDR says that accessories have to be classified by themselves, separately from the device. On the other hand, why should I classify my device taking into consideration an accessory which I am not sure I will use being that it is not a component? Doesn't make so much sense.

Would you pay the same concept if the other devices are not accessories but devices which are used in a sequence? Or would you classify them separately?

Example of a simplified radiation workflow:
1. One medical device sw decide how much radiation dose to give to a patient. It is a planning software, medical device by itself.
2. One additional software device gives input to put the patient in the correct position to receive the radiation
3. One third device irradiate the patient

All three devices are from different manufacturers. Compatibility tested, all good.
The third device is for sure a class IIb, easy, exact deinition is rule 9. Do you classify the others by themselves separately?
I have always done the classification of the device under classification

 

[Marcelo]

I am not sure... The MDR says that accessories have to be classified by themselves, separately from the device.

The reason you classify accessories separately is exactly because of the example I mentioned.

On the other hand, why should I classify my device taking into consideration an accessory which I am not sure I will use being that it is not a component? Doesn't make so much sense.

Unfortunately, what does make much sense is your comment. If you design a device, you HAVE to define it's accessories in the device design (including verifying and validating the device with all accessories). IT WILL be used with your device because you say so in your label.

From these comments, I understand that you may not be familiar with medical device regulations, are you new in the field? Because these topics are rather basic (although the application can be complex) and have been for decades now.

 

[Marcelo]

Would you pay the same concept if the other devices are not accessories but devices which are used in a sequence? Or would you classify them separately?

Example of a simplified radiation workflow:
1. One medical device sw decide how much radiation dose to give to a patient. It is a planning software, medical device by itself.
2. One additional software device gives input to put the patient in the correct position to receive the radiation
3. One third device irradiate the patient

All three devices are from different manufacturers. Compatibility tested, all good.
The third device is for sure a class IIb, easy, exact deinition is rule 9. Do you classify the others by themselves separately?
I have always done the classification of the device under classification

You do classify any medical device separately, but also in this case, their classification may be influenced by the other device.

 

[Asia78]

Hi Marcelo,
Thanks for the explanation. No, I am not new in the field, but on the classification yes.
My take away is:
Look at the intended use of the device and what you declare and the usage of other device sand...good luck!! But important to document well the decision on the chosen rule .

 

[Marcelo]

Hi Marcelo,
Thanks for the explanation. No, I am not new in the field, but on the classification yes.
My take away is:
Look at the intended use of the device and what you declare and the usage of other device sand...good luck!! But important to document well the decision on the chosen rule .

Ah ok, I just asked because, in the case of software, there's a lot of software engineering that have experience creating software but are new to medical device regulatory affairs, and thus some concepts might seem weird to them.

 

[Oskari Koskimies]

There is an interesting SaMD case related to this that I'm working on. It's a remote monitoring system that includes the following functionality:

• Manage the patient's measurement schedule and show alert when the next measurement is due
• Transfer data via Bluetooth from a measurement device (e.g. a blood pressure cuff) to patient's phone and from there to server
• Display data on the server to clinicians via a web-based user interface
• Interpret the data to provide quick overview for physicians, e.g. classify patients as more or less urgent

At first glance one might think that “Software, which drives a device or influences the use of a device, shall fall within the same class as the device” applies. This gets rather interesting because the system is used with many different measurement devices of varying classification, some of which are IVD devices.

However, classification rules only apply to devices which qualify as a medical device in the first place. And according to current MEDDEV 2.1/6, mere data transfer and display functionality does not qualify a software as a medical device. MEDDEV 2.1/6 does not directly touch on measurement schedule functionality, but that is just a glorifed calendar reminder, so it does not qualify either (which we confirmed with a regulatory authority). So it hinges on the functionality that interprets the data. Now, according to MEDDEV 2.1/6, simple comparison to clinician-supplied limits does not qualify as a medical device, so it is actually possible to do reasonable interpretation without qualifying, but for the sake of argument, let's say that the interpretation part does qualify (in any case trying to evade qualification entirely would be questionable in the current tightening regulatory atmosphere).

The nice thing about software is that you can easily divide it into different parts. So in this case you could create a separate interpretation part, which is a SaMD, whereas the rest is just regular software. Then the interpretation part would be classified according to the classification of the interpretation functionality itself and the classification of the measurement devices used, with the highest class being the one to use.

Of course, there is a new version of MEDDEV 2.1/6 coming, which might make the qualification and classification more based on intended use than the type of functionality, so this is all in flux right now. In particular, current MEDDEV 2.1/6 says that a SaMD which takes input from both IVD and MD devices, is an IVD device. If this is changed to be more about intended use than where the data is coming from, then the interpretation part might qualify as a MD instead and its classification would then likely be done purely based on rule 11, typically resulting in MD class IIa or IIb. That would be desirable; the interpretation part is not really an IVD, and IVDR does not cover SaMD properly, so it would be preferable to handle it under MDR.