An unsurprising case of software qualification with an interesting twist

logo-curiaThe unsurprising software qualification case that I wrote about earlier turns out to still have a little twist in the judgment that the European Court of Justice (CJEU) recently rendered in that case. The CJEU went into details that the Advocate General (AG) had not gone into so in the end the judgment turned out to be more interesting than expected.

Never a dull moment in medical devices regulation!

Unsurprising

As I blogged before when the AG opinion came out, it was completely unsurprising and expected that the the CJEU followed the AG and concluded that the software qualified as a medical device. The French government that was stubbornly defending its national rule requiring separate national certification of software that is used for support in prescription of medicinal products should have known better too, but it didn’t – as often happens with governments that should know better.

Still something interesting

The interesting thing happening in the CJEU’s judgment is the way the CJEU codifies crucial parts of the current MEDDEV 2.1/6 about software in case law. Why is this interesting? Three things:

Partial codification of the MEDDEV, which Member States may not depart from (anymore)

Because the CJEU borrows heavily from the MEDDEV and this way makes the MEDDEV law. All MEDDEVs state that the guidance is not authoritative and subject to interpretation of the directives by the CJEU. As a consequence, authorities can still do whatever they like and depart from the MEDDEV guidance even if this is totally clear (like the French State did in this case). However, they cannot do so anymore when the interpretation given in the MEDDEV is codified in case law because that constitutes a direct violation of EU constitutional law by the Member State.

In point 33 the CJEU renders the flowchart on p. 9 of the MEDDEV and its explanation in the MEDDEV case law:

“those guidelines indicate that software constitutes a medical device where it is specifically intended by the manufacturer to be used for one of the purposes set out in Article 1(2)(a) of Directive 93/42 and where it is intended to create or modify medical information, in particular by means of calculation, quantification or comparison of the recorded data against certain references, in order to provide information about a particular patient. Those guidelines further state that software that does not perform an action on data or performs an action limited to storage, archiving, lossless compression or, finally, simple search, that is to say, in the latter case, software that functions as a digital library and makes it possible to find information from metadata, without modifying or interpreting it, should not be considered a medical device”

It is now clear that the specific software, i.e. (point 34):

“software, of which at least one of the functions makes it possible to use patient-specific data for the purposes, inter alia, of detecting contraindications, drug interactions and excessive doses, is, in respect of that function, a medical device, within the meaning of Article 1(2)(a) of Directive 93/42, even if such software does not act directly in or on the human body.”

This quote also shows that the CJEU does not accept the theory that “the software only provides information but the doctor makes the decisions” some companies tend to propose when they want to keep their software outside the scope of medical devices legislation.

It’s not completely new however that the CJEU refers to MEDDEVs when deciding on a question of qualification of a product as medical device. It did so before in the Brain Products case, point 24, but in almost no detail and on a rather insignificant point (“medical devices are intended to be used for a medical purpose” – duh).

Software qualification under MEDDEV 2.1/6 codified in case law and dependency with new software guidance

Secondly, we have the new MDR and IVDR that go into a lot more detail on software but not on the question as to when software is a medical device. Because the MEDDEV was written for the directive and therefore would not be valid for the MDR and IVDR (or at least would give authorities the opportunity to argue so) the fact that it is now case law is relevant. Since the MDR and the IVDR do not intend to change the definition of ‘medical device’ this interpretation of the CJEU must be carried over to the MDR and IVDR, while the Commission otherwise could have just repealed the MEDDEV and done something different.

This is extremely relevant for the discussions that are currently ongoing about a new piece of guidance about software under the MDR and IVDR as announced in the CAMD roadmap that I wrote about earlier (see point 2.2 of the roadmap). This judgment may influence the final text of the guidance and it may influence discussions in the IMDRF software working group because the EU cannot depart from this judgment, whereas it had a lot more freedom when there was no case law on software as a medical device.

Modules codified in case law

Thirdly, the CJEU addresses the modules chapter of the MEDDEV (a subject that the AG had not touched upon) and codifies that chapter basically, while there is no direct specific basis in the current directives or the new regulations. Sure, it follows from the logic of the system that modularization would be possible and that the manufacturer can decide which parts of a software suite deployed in medical setting have a medical intended purpose. But it was also beyond doubt that we were dealing with a medical device in this case and yet the French authorities fought this pretty evident conclusion all the way to the CJEU.

This helps under the MDR and IVDR in case of discussions with authorities or notified bodies about whether and how modularization is allowed. The most important point the CJEU makes is when it repeats from the MEDDEV in point 33:

“Those guidelines state that it is the responsibility of the manufacturer to identify the limits and interfaces of the different modules which, in the case of modules subject to Directive 93/42, must be clearly identified by the manufacturer and based on the use which will be made of the product.” (underlining added)

I underlined the specific words in this quote because I often find that authorities especially have difficulties accepting that certain choices with regulatory effects are the prerogative of the manufacturer solely, such as what are modules of a particular software suite, whether products sold together constitute a kit for specific IVD purposes or a system in the meaning of article 12 MDD or 22 MDR, etc. I find that in practice authorities have the tendency to substitute their intended use for that of the manufacturer in order to arrive at a different conclusion as regards qualification (medical device or not?) or classification (which risk class or which list for IVDs). But that is not how its works, and the CJEU confirms with this reasoning that it is the manufacturer’s choice only. As a result, the authorities can only make marginal appreciation of the choices that the manufacturer made by looking at whether the discretion that the manufacturer exercised is consistent with the intended use of the product as such.

So

What turned out to be an uninteresting case of a Member State being difficult for the heck of it turned out to have some interesting implications for the future after all. More legal certainty under the MDR and IVDR in the field of software as a medical device, what’s not to like?

 


Navigate through our knowledgebase

Related articles

Article

Happy New Medical Devices Year!

Happy New Year everybody – may your transition to the MDR and IVDR be unproblematic and timely. May your management be convinced that making and selling medical devices is actually core business…

Read more

Article

A wave of MDR and IVDR rollout coming our way

With the clock for the countdown to the end of transitional periods for the MDR and IVDR ticking away, everyone is of course very interested what the competent authorities are doing regarding…

Read more

Article

MDR and IVDR workshop at Advamed on 4 December

At Advamed’s San Jose MedTech Conference this year it was quite a surprise for me to see how many US companies are still not doing what is necessary to become compliant with…

Read more