As announced, the IMDRF is on the case for software, which shows how important this subject is becoming in the medical devices field. I notice this everyday in my medical devices practice, as more and more medical devices software work comes in. That is great for me, as I grew up around software engineers in aerospace and agriculture and picked up a lot about software engineering on the way. It is also important, because software plays a more and more important role as medical device in its own right.
IMDRF has just released a proposed document by the International Medical Device Regulators Forum (IMDRF) Standalone Medical Device Software Working Group on Standalone Medical Device Software: Key Definitions and invites comments on the document. Let me tell you right from the start that if you are a company or association of companies with international interests in medical devices software, this is too important to ignore.
Intention of the document
The document is the start of a bigger initiative of the IMDRF because it
” identifies key definitions starting with a common definition for “standalone medical device software.” These definitions are intended to serve as a foundation for further IMDRF work (identifying a risk framework and controls needed to address risks) to be conducted by this workgroup.”
For that reason, medical devices companies with an interest in software are well advised to take a look and decide if they like what they see, because the outcome of this exercise will set the goalposts for future IMDRF initiatives. But, mind you, so far we are only talking definitions. However, they do define the scope of any rules using them so the very foundation of future regulation.
The term “standalone medical device software” (SMDS) is defined as
“software intended to be used for one or more medical purposes and is able to perform its medical purpose without being embedded in a hardware medical device or being dependent on specific or proprietary medical purpose hardware.”.
This is a significantly richer definition than currently in the EU MEDDEV 2.1/6 on stand alone software (“which is not incorporated in a medical device at the time of its placing on the market or its making available”).
The proposal for the medical devices regulation contains a reference to ‘mobile computing platforms’ in the design requirements (14.3), which was left alone in all the amendments craziness currently going on. The IMDRF document defines ‘computing platforms’ as to
“include hardware and software resources (e.g. operating system, processing hardware, storage, software libraries, displays, input devices, etc.).”,
which tells us more about what is intended there, and specifically that a computing platform is not only hardware. That is certainly not evident from the text of the medical devices regulation proposal, which only refers to design features related to hardware. Companies will have to make up their mind if they agree with this open ended definition that also includes software.
The nested functional description of “operating system” (“may be running on a server, a workstation, a mobile platform, embedded system or other general purpose hardware platform”) may cause some demarcation problems because it refers to embedded systems to run on, while we in Europe would be quick to consider anything running on a embedded system in a device as not standalone. We would consider “software which is not incorporated in a medical device at the time of its placing on the market or its making available” as not standalone as per the definition of standalone software in MEDDEV 2.1/6.
The document explicitly allows for modularisation by stating that SMDS
“may be used in combination (e.g., as a module) with other devices”
“software that meets the definition of SMDS and is part of another software, regardless if the other software has a medical purpose or not, is still considered as a SMDS (i.e. medical device)”
This would seem to fit the EU thinking of modularization set out in the MEDDEV, which allows this too. The document can help the US make a nice step in modularization, because this is an area where the EU has so far been a lot more flexible. This will make a lot of companies with SMDS in the EU and US simultaneously very happy.
The medical purpose runs roughly along the lines of the GHTF medical device definition, but:
“For SMDS, the following purposes are specifically excluded as medical purpose for software since these purposes are not foreseen for software:
– disinfection of medical devices
– devices for in-vitro fertilization or assisted reproduction technologies”
I am not so sure that IVF devices or assisted reproduction technologies should be completely excluded for software. For example, I could envisage software used for screening embryos for IVF purposes or diagnostic interpretation of raw data for assisted reproduction purposes.
The term “software change” is defined as “any change made to software currently used or marketed for purposes that include corrective or adaptive purposes, or for change in functionality.” These changes would be seen as changes relevant for regulatory purposes, e.g. triggering the need to go back to the authorities or notified body to have design changes reviewed. The document contains non-limitative list of helpful examples of the kind of changes IMDRF is thinking about:
- changes associated with defect fixes, aesthetics, usability enhancements, security patches or operating efficiency’
- changes affecting the software’s original performance, safety and effectiveness, and/or intended use / purpose;
- changes to mitigate new risk(s) not previously identified, or change the probability that existing hazard(s) will occur;
- changes to adapt the software to new and / or different computing platforms (e.g., from an on-site server to an off-site “cloud” server.)
You can love or hate these examples, but that’s what the invitation to comment is for. Now is the time!
The document clarifies that a manufacturer of SMDS is manufacturer whether or not such a SMDS is designed and/or manufactured by that person himself or on his behalf by another person(s), which, again, is already firmly embedded in EU law, so no surprises there so far.
The document frames our EU “intended purpose” as the
“objective intent of the manufacturer regarding the use of a product, process, or service as reflected in the specifications, instructions, and other information provided by the manufacturer.”
which is similar to what EU law already provides with
“materials such as sales and marketing materials expressed by the manufacturer is considered as “information provided by the manufacturer” and therefore reflects the objective intent of the manufacturer.”
What is missing / first impression
My first impression is that he document is a very useful starting point, with some ifs and buts. But I understand that if you engage in international harmonization, you can’t always please everyone.
However, I really miss a discussion of the concept of accessory. This concept is completely missing in the document and is also a defined concept of the GHTF. This can mean that IMDRF (a) totally forgot about it (unlikely), (b) considers it not applicable to SMDS (in that case they would have probably said so) or (c) considers it politically sensitive (most likely because of the FDA’s difficult history with accessories in medical devices law). Another explanation is that the IMDRF considers the concept of accessory completely clear if the scope of the concept of medical device is clear. Anyway, I think the document cannot ignore accessories and their role in medical software given the important role that they play in EU medical devices law, just look at the MEDDEV and the Swedish Document Reloaded. Indeed, under EU law medical devices and accessories are mutually exclusive, but regulated similarly.
This is particularly relevant since the document uses the term “device” here and there (for example with respect to modules), and EU medical devices law defines “device” as to include both ‘medical device’ and ‘accessory’. For EU purposes this would also need to be cleared up, because without a discussion of how to apply the accessory concept to SMDS this document is not very useful starting material for EU purposes.
In addition, some discussion about how the definition of SMDS would play out in IVDs would also be very useful, as we Europeans introduced the concept of “expert function software” in this context (“For the purpose of this document, the ‘expert function software’ means software which is able to analyse existing information to generate new specific information according to the intended use of the software.”) and guidance or examples of SMDS in IVD regulated scope would be very useful indeed.
The deadline for comments inconveniently coincides with most people’s summer holidays, because comments are due by 30 August. While this is perhaps not very convenient for those leaving on holiday, it will give the IMDRF the opportunity to digest the comments with a view to its Brussels meeting from 12 to 14 November this year. So let’s engage. What do you think about this?
Thank you for this post. It is interesting for the SMDS manufacturers to understand the definitions and the implications of these on their business.
I agree that we miss the definition of accessories and modules.
It seems to me a good idea to collect the Dutch comments via the SAMDD platform.
Hi Olivier, thanks for the comment. I have already proposed to NEN to make this a work item for the SAMDD platform. Hopefully the summer holidays will not get in the way too much!