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.