In relative quiet the IMDRF has delivered its first deliverable in the series of documents relating to Software as a Medical Device (SaMD) on 18 December last year, together with a number of other documents, after it was adopted at the meeting n Brussels 12-14 November 2013. People that commented on the document will remember that the consultation conveniently spanned over the summer holidays last year.
This deliverable and the other documents that came out of the IMDRF meeting give a lot more insight in how the IMDRF views further regulation of SaMD.
The new document treats software as a medical device as a single and new concept. It is still unclear to me why you would want a separate definition for SaMD to replace the concept of standalone software as a medical device, but since the definition of medical device is nested in that definition, this would amount to having a separate species of medical devices, like active implantable medical devices, IVDs and now SaMDs. So far so good.
The problems start (not IMDRF’s fault) if we look at the EU’s plans with the definition of ‘medical device’ in the pending proposals, which seems to have spiraled out of control in the amendments of the Parliament by extending it to devices with an indirect medical purpose. The Parliament – without any apparent regard for international harmonization – decided it wanted its own definition and did not pay attention ton how this would sit with the GHTF acquis, which the SaMD document follows, and which the the Commission had initially proposed as update for the current definition. Let’s hope this will get fixed under the Council’s supervision, or in the next round if the regulation proposals do not complete before the EU elections.
The EU discussion tends to focus on the medical devices regulation proposal and the IVD regulation proposal does not get the attention it deserves. The IVD regulation proposal was not even discussed in the 10 December 2013 EPSCO Council meeting. The IMDRF approach underlines that we should really pay more attention to IVDs as well, because it proposes to regulate SaMD with logic similar to that of IVDs (underlining that the IMDRF sees SaMD as a species of medical devices like IVDs) as set out in FDA’s Bakul Patel’s presentation at the Brussels meeting on 14 November 2013:
Indeed, according to IMDRF IVDs and software share characteristics, for example
- An IVD examines a specimen or sample derived from the body, and is used to provide information for diagnosis, monitoring, or screening. A SaMD examines data derived from or concerning the body, and is used for diagnosis, monitoring, or screening.
- Neither IVDs nor SaMDs will have a direct, physical effect on a patient; rather the output from the IVD or SaMD will provide information that may contribute to a user’s decision to treat, diagnose, monitor, or screen a disease or condition.
However, if you want to rely on these arguments an even more convincing case can in my view be made by reference to diagnostic medical devices (which by the way normally run software to render the data they measure). I don’t see why you would particularly need a reference to IVDs. All of the arguments made in the IMDRF presentation apply just as as well to diagnostic medical devices, especially those for imaging. Maybe it’s just me, but I do not see the special case for IVD analogy here.
SaMD that controls a hardware device is component of hardware device?
The SaMD definition document delivered on 18 December 2013 and the working document that is currently being developed and that has been made available to stakeholders contains one regulatory choice that jumped out at me as fundamentally inconsistent with current EU regulatory logic, and that is the choice that
“Software that drives (or controls the function of) a physical medical device, even if the software is run on a general purpose computer, is not considered a SaMD device. For example, software running on a general purpose computing platform that functions similar to an “embedded control” software of an MRI machine or an infusion pump, is not considered a separate SaMD device, but is considered to be a component of the physical medical device. “
There are several fundamental problems with this approach. For example, it complicates third party SaMD that controls an OEM hardware device. The third party software manufacturer is faced with the situation that his software is not a device as such, but he turns out to be a component manufacturer for a device that is not his. It would also have the freaky effect in CE marking logic that a third party software supplier can invalidate the CE mark for the hardware device by providing software that can control the hardware device, e.g. by implementing functionality that is not in scope of the existing CE mark.
Secondly, what is ‘similar to embedded control software’? That is difficult to say in case the SaMD that controls the hardware device adds functionality that the OEM hardware does not have, which is a normal commercial scenario.
Thirdly, this is incompatible with the EU medical devices classification rule about software controlling other devices, which assumes that the software is an independent device (“Stand alone software, which drives a device or influences the use of a device, falls automatically in the same class as the device. If stand alone software is independent of any other device, it is classified in its own right.”). This does not change under the new regulations for medical devices (so far).
Otherwise the definition document seems consistent with EU medical devices law, except that it still not does not address accessories, an important concept both in the current EU medical devices law revisions and with respect to software as medical device, especially in the networked and mobile space. So while the document is mostly well drafted, it still contains a big gap in the definition of software that should be regulated under medical devices regulation.
The SaMD project consists of three phases, of which the first has been completed. The second and third phases are currently underway with a working document that has been made available to stakeholders on SaMD controls, but which has not yet been made public. It contemplates a system of common controls and specific controls (based on the risk of the SaMD concerned).
This document will no doubt be discussed at the next meeting 25-27 March in San Francisco. The consultation is planned – again – during the summer holidays this year (better plan for some poolside quality time for that) with a view to closing the document during the 16-18 September meeting in Washington DC, to make it public shortly after that meeting.
A good opportunity to learn more about all of this is the upcoming Informa conference on The Medical Devices Directives and the Revision, which has a software section with a competent authority and with COCIR’s Software Task Force deputy chair, who will no doubt be able to say a lot more on this subject (and if they don’t they will be able to answer questions). That conference is a good opportunity in any event to be updated on the general state of the revision. I’m also there if you want to catch up, and will update you on the on the exciting but still rather opaque subject of the Eudamed cathedral.