Sometimes you have to go far away to learn a lot about thing close to home and that is what happened to me at the RAPS Regulatory Convergence Conference that I am currently attending in Indianapolis. There was an interesting presentation of Gregory Martin from BSi Healthcare about the developments in EU medical device law with respect to standalone software and I bumped into a bunch of other interesting people that I had chats with, and voila, I was able to reverse-engineer the following about the MEDDEV in the works on EU regulation of standalone medical devices software. More in general the conference has been very interesting and I have learned more than on many conferences I attended in the EU.

In any event I thought it was a good occasion to continue the feuilleton on developments in regulation of software as medical device further to the COCIR workshop I attended recently.

The tree for MDD

I learned that the document will contain two convenient decision trees, one for stand alone software under the Medical Devices Directive (MDD) and the other for stand alone software under the in vitro diagnostics devices directive.

Based on the presentation and the conversations I had I could more or less reverse engineer the decision tree for the MDD, which seems like a refined version of the COCIR version published some time ago and according to my prediction will look more or less like this (abbreviations: SW means software and MD means medical device and MDD means Medical Devices Directive). I knocked it together quickly with NoteTaker HD on my iPad so apologies for the rough graphics. Some clarification:

  • if you answer “no” to question 1, the software does not contain any instructions or subroutines in any programming language and you are probably dealing with an electronic document containing a protocol, for example;
  • if you answer “no” to question 4, you are probably dealing with software for statistic purposes, which – even if used in clincal trails – is not a medical device.
  • if you answer “no” to question 6, you are dealing with software for all types of use in a medical setting but not with a regulated intended purpose, like reimbursement software, staff scheduling etc.
  • if you answered “yes” to question 6, you are probably dealing with software that influences a medical device one way or the other and assists it to achieve its intended purpose while not falling within the scope of the definition of medical device itself, like for example an iPad app that allows a nurse to monitor and control infusion pumps in the ward from the nurses station.

I expect that especially question 6 will be very difficult to work with in practice and will cause a lot of interesting borderline problems.

There should be an IVD decision tree in the document too, but I was unable to get enough information about that to make a reliable recontruction. Maybe at a later stage!

Placing on the market / putting into service

Another interesting observation was that internet software may be covered if the application of it is triggered by the concepts of “placing on the market” and “putting into service”. That does not sound like a surprise, as the FDA draft guidance on mobile medical apps also explicitly proposes to regulate this. the consequence is that it  would bring many websites containing virtual doctors into the scope of the MDD, as I have argued is the case already, without needing to resort to guidance. It will lead to many unhappy doctors needing to CE mark their websites. The concept of “placing on the market” is not suited to deal with this at all if we look at the Commission Interpretative Notice on this Point, as it is written mainly for physical devices, which standalone software might be only if sold on a physical carrier. That is usually not the case with apps, to “putting into service” seems more relevant to delivery of functionality via the web, whether or not is is subsequently run locally or not. Putting into service happens at “the stage at which a device has been made available to the final user as being ready for use on the Community market for the first time for its intended purpose”. So, that happens already when offered in the app store for Apple or Android apps or when otherwise offered for download, and not only when the device actually starts to run. This will have regulatory consequences for intermediaries selling apps.


Some words on modules. I heard that the guidelines in their current draft (which is still under discussion and there is disagreement on specifically this point) contains a module on modular software that proposes to only regulate those modules of a larger interoperable package of which the intended use falls within the scope of the MDD. However, it is up to the manufacturer to define the boundaries correctly in this respect and to identify clearly what is regulated and what is not. This is of course not very helpful and rather difficult for a manufacturer. What is more however the draft guidance proposes that if modules are intended for use in combination with other modules in a software structure, the whole system architecture, including all connections must be “safe” and must “not impair the specified performance of the regulated modules”. This looks complicated and likely unworkable to me, because it creates an additional evaluation criterion under the MDD that is not required under the statutory instrument itself. Also, the notion of “safe” is something that really clashes with all that is known about risk management and risk/performance evaluation (only the cornerstone of the MDD), because when is a risk sufficiently managed to be “safe”? And how do you prove that in the technical file? This criterion raises more questions than it answers, but then again I understand this is one of the points that is still debated between those involved. My advice: remove this and either certify the system as a whole or justify why a module is stand-alone (yes, stand-alone so not dependent on other software) software and can be certified as device as such. We don’t need guidance to make this already existing possiblity more complicated.

So, food for thought

At least, for me, and I will mull this over and most likely there will be more to say about this, sooner or later.