July 22, 2021

EU MDR Strategy for Configurable Software

For my clients that manufacture software-only medical devices, I have sought and implemented what I feel is the ideal:  The software design and architecture are such that there is one executable software file, but that can be configured via licensing to turn various modules on or off.  In this approach, all modules are always present in the software, yet not always turned on.  For the purposes of EU MDR conformity, this means there is one product, and thus one DoC, one NB certificate, and one technical documentation file.  The different licensing configurations are handled in the software and technical documentation via software installation controls.  This approach avoids the hassle of applying the EU MDR’s requirements for “accessories” (i.e., medical devices in their own right), such as the typical need for accessories to have dedicated (usually separate) technical documentation, labeling, DoCs, and/or NB certificates.

Noteworthy parts of the EU MDR’s definition [see Article 2(2)] for “accessory” are that a) it’s an article which intrinsically is not itself a medical device [i.e., it’s just a widget that doesn’t intrinsically meet the EU MDR definition in Article 2(1)]; and b) the main software medical device can’t function as intended (i.e., as labeled, advertised, etc.) without the “add-on”.  If the “add-on” doesn’t meet these criteria, then it’s not an “accessory”.  Instead, it would either be part of the main medical device software or else a separate medical device in its own right providing supplemental features/functionality or else or else a non-medical (e.g., an EU MDR preface item 19 general purpose, life-style, well-being, etc.) device all together.  In the approach I’ve modeled above in my first paragraph, all of the software modules and corresponding code, whether turned on or off, are still part of the same software medical device and executable file.

If on the other hand the “add-ons” are a) actually add-ons in the truest sense, meaning that they are separated software files/patches/code; and either b1) they actually meet the formal definition of “accessory” [meaning that they don’t intrinsically meet the definition of medical device yet enable the main software medical device to function as intended (rather than just providing supplemental features/functionality)], or b2) they just provide supplemental medical device features/functionality, then the manufacturer would typically be stuck handling such add-ons as “accessories” (i.e., as devices in their own right) or as separate medical devices altogether, where dedicated (typically separate) technical documentation, labeling, DoC, certificates, etc., would be required.