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 docu
ment 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.
Modules
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.
medicaldeviceslegal 
Thank you for an interesting blog.
Im really curious of the development of this. The Swedish MPA is already regulating the market in sweden. They follow the report issued in 2009. http://www.lakemedelsverket.se/upload/foretag/medicinteknik/en/Medical-Information-Systems-Report_2009-06-18.pdf
In this report it becomes clear that the swedish MPA regards electronic patient record systems as medical devices. Since i cannot see how a patient record system would pass question 3 in the decision tree that you mention, it would be in contradiction with the recommendation in the swedish report.
This is highly important for the manufacturers in sweden since they are currently in competition with non regulated manufacturers in the rest of the EU. A lot of swedish manufacturers are currently investing millions in the Technical documentation and their QMS to live up to the requirements of the MDD. I wonder what the reaction will be if and when these products are excluded from the requirements of the MDD. How will the swedish MPA act?
I would be amazed if the swedish MPA were not represented on the COCIR. It would be interesting to get some more information on the discussion during the meeting.
Hi Jakob, thanks for this observation. You hit the nail on the head here, and as I understand precisely this point is one of the political hot issues currently still being debated with respect to the draft MEDDEV, as it will essentially mean that the Swedish MPA will have to revisit the policy of treating any electronic patient record system as medical device. I am sure though that the Swedish medical technology association will be able to tell you more about this.
Hi Erik an Jakob
The questions that will rise after the publication of the new EU-guideline (MEDDEV) will be numerous. There are some wordings in the draft guideline that could have been better, especially among the examples.
I just want to mention some traps to avoid for manufacturers and regulators:
– to make qualification decisions merely based on the name of the software system.
o Qualification shall be based on how the manufacturer has defined the intended use, whether or not the software has a medical purpose according to the definition of a medical device in the medical device directives.
– to divide the system into too small modules.
o Don’t divide the system into ”screws and nuts”. A screw or a nut seldom has a medical purpose. Neither does a single memory module or a single data transmitter. The devices we are interested in are most often composed by several software functions that each of them might not be ”medical” but that combines into a system with a medical purpose.
– To define the system only in technical terms
o A system that collects information from “A”, transmit the information to “B”, calculates (something) and then display the result in combination with other information on device “C”. That is not a medical purpose. The intended use has to describe the benefit for the patient relating to the prerequisites in the definition of a medical device, such as support for diagnosis, treatment or alleviation for handicap.
The example Electronic Patient Record systems is interesting. They are not defined by name since the might have a range of different functions/modules in combination. Most modern EPR’s have functionalities with a clear medical purpose, e.g. a medication module.
To divide an EPR in it’s different modules for different qualification, as MD or not, is not always appropriate. The combined system has a medical purpose that might be another than each module. Further the relation between the modules may be such that they are not independent. So EPR’s are definitively not excluded by the qualification criteria in the draft guidelines.
It is a foreseen problem that the draft guideline might give that impression.
Please note that whilst we are willing to give any help and advice we can, any views given by us on the interpretation of the Medical Device Regulations represent our best judgement at the time, based on the information available. Such views are not meant to be a definitive statement of law, which may only be given by the Courts.
Best Regards
Mats Ohlson
The Medical Products Agency, MPA, Sweden
Erik,
This is most interesting insight. A decision tree akin to what you describe above would provide some much needed clarity – the line between what is in scope and out of scope does seem some what subjective at present.
We will shortly publish a guidance document on the regulation of health apps, which as a UK focused non-profit we asked the MHRA to review for feedback, which we have subsequently incorporated. We think it therefore paints an accurate picture of the status quo, noting that a new MEDDEV on the subject of standalone software should be available this year. We will publish in the next few days so would be good to get your thoughts on this if of interest. Please email me if you would like a copy in advance.
Best regards,
James Sherwin-Smith
CEO, d4
James
Would be very interested to see your draft guideline on health apps. FYI we are working with an update to the Swedish guideline and there are a couple of EU-workshops i Brussels i January on the mHealth topic.
Regards
Mats