Some time ago I already gave you a look under the hood of it and now it is here, the new MEDDEV on stand alone software: an interesting document that provides a lot of much-needed guidance for the developing software industry surrounding medical devices.

Since much of what I wrote about  it (here, here) is still accurate. Some additional points are made in the interview I had with MedTechInsider when the MEDDEV was just out. The interview has a nice overview of what I think will be the future issues with regulated stand alone software.

What I will do is give you a heads-up for a rather comprehensive article that will soon be published on EMDT (and a condensed version will appear in their glossy, European Medical Device Technology) in which I, Bradley Thompson and Jason Brooke compare the resulting EU regulation of clinical decision support systems to the US regulation of clinical decision support systems. Since clinical decision support systems are software, much of what we write in the article will apply to stand alone software in general. It will hopefully help companies to fine-tune their regulatory approach to software regulated as medical device in the two biggest medical technology markets. That’s useful, right?

Decision trees

Some other useful features that you should know about in the new MEDDEV: I like the new document because it contains really convenient decision trees for determining the scope of the medical devices directives with respect to software, and, as you know, a picture says more than a 1000 words, right? Also it contains many examples of regulated software.

First, you apply the tree for the Medical Devices Directive (which I reconstructed slightly, I could not help myself. It’s not identical to the one in the document but the tree runs exactly the same):

However, if you have standalone software that is used to analyse data coming for an in vitro diagnostic device, you should subsequently apply the below tree (as the definition of ‘in vitro diagnostic medical device’ contains the nested definition of ‘medical device’), starting at “stand alone software”:

Modules

I was a bit harsh perhaps about the merits of the possibility under the MEDDEV to CE mark software modules with ‘medical’ functionality in a larger suite separately from others in the same suit.  Having mulled it over, I still think it will be complicated to apply in practice. It is up to the manufacturer to define correctly the boundaries of the module(s) and to identify clearly what is regulated and what is not. The MEDDEV does not provide guidance on how to make such a determination but instead refers to the existing rule in Annex I MDD and IVDD for combination devices: “If the device is intended for use in combination with other devices or equipment, the whole combination, including the connection system, must be safe and must not impair the specified performances of the devices. Any restrictions on use must be indicated on the label and/or in the instructions for use.” ( see Annex I, 9.1 MDD and Annex I, B.3.1 IVDD).

I can imagine that it is difficult for manufacturers to identify how the different modules of a larger software system relate to each other and where medical functionality starts or ends. Indeed, the rule in Annex I that the MEDDEV refers to was written for modular physical medical devices rather than software. Furthermore they must ensure that the whole system is safe and does not impair the specified performance of the modules that are subject to the medical device directives if medical functionality modules are combined with non-medical functionality modules. On the other hand, medical device regulations in the European Union are appreciated for their flexibility, allowing manufacturers to present evidence in a way that works for them. Also, if the software is a class I medical device as a lot of this software will be, the manufacturer can decide this all on his own.

Accessories

We will see a lot of challenges with standalone software that functions as a accessory to a medical device. An accessory, as you know, is “an article which whilst not being a device is intended specifically by its manufacturer to be used together with a device to enable it to be used in accordance with the use of the device intended by the manufacturer of the device”.

Accessories of medical devices are regulated as medical devices in their own right. Software that is not itself a medical device nor constitutes an accessory to a device would typically be software for all types of use in a medical setting but not with a regulated intended purpose. An example would be software that is used for reimbursement purposes, staff scheduling, or some other similar purpose. Software that is an accessory will influence a medical device in some way and assists it to achieve its intended purpose but does not itself fall within the scope of the definition of a medical device. An example would be an iPad app that allows a nurse to monitor and control infusion pumps in the ward from the nurse’s station.

The accessory question will become interesting with software of which it may not be completely evident that the manufacturer intended it be used together with medical devices, e.g. very customisable software that is suited for controlling all types of external devices that the manufacturer says in a help forum topic that can be safely used to control infusion pumps at a distance, but they held back on the CE certification because their lawyers are difficult about product liability risks.

PMCF

Better start to think about your post marketing clinical follow-up for software too. If it is a medical device you have to do clinical evaluation and if you’re dealing with a class IIa or higher device, you have to explain to your notified body how you will fulfill your PMCF obligations, for example to fine-tune your algorithms via registry studies and how that relates to your EN62304 obligations for life cycle management of the software.