eLabeling decision treeFurther to my recent post about e-labeling and my appeal to take more account of the specific mHealth market needs I had a discussion with another devices expert who suggested that the majority of medical apps will be in class I anyhow, in which  case these apps can be used safely without instructions, because the Medical Devices Directive provides for an exception in that case and no IFU is needed. Consequently, the app could contain e.g. an electronic application guide only.


This argument refers to the exemption in Annex I, 13.1 Medical Devices Directive:

“Instructions for use must be included in the packaging for every device. By way of exception, no such instructions for use are needed for devices in Class I or IIa if they can be used safely without any such instructions.”

The IVD Directive has a similar exemption in Annex I, 8.1:

“In duly justified and exceptional cases no such instructions for use are needed for a device if it can be used properly and safely without them.”


While this argument is completely correct in its regulatory logic, I have several thoughts on this:

  1. There is a catch 22 in the EU medical devices rules because the consequence of this argument is that you can only provide the IFU electronically in the cases where you don’t need one because they can be used safely without. My point is that you should be able to elabel on cases where you do need an IFU.
  2. This situation may well lead to a race to the bottom, with app manufacturers understating risks in order to be able to rely on this exemption. That is something we don’t need in the wild west market that the medical apps market currently mostly is. This is certainly not a hypothetical risk if you only look at the current tendency of quite a number of app makers to on the one hand declare medical intended use (e.g.: “use this app to check for melanomas”) but then on the other hand disclaim it in terms and conditions as to try to stay out of the scope of medical devices rules (e.g. “this app does not provide a medical diagnosis , always ask your doctor too and we are not liable for consequences of you relying on the information provided by this app”).
  3. Personally I think that the majority of medical apps that will make really a difference in healthcare (and that policy makers bet on to reduce costs of healthcare) will mostly be in class IIa and occasionally in IIb because they monitor vital physiological parameters, such as heart rate and blood pressure analysis over time and conclusions drawn from that will be important to combat and manage modern diseases caused by obesity. That is not class I functionality but at least class IIa, according the EU MEDDEV on classification. I am not sure at all how authorities would view mHealth solutions that are intended for monitoring of non-vital but still important physical parameters in view of the exemptions for IFU inclusion referenced above. It’s like they will err on the side of caution. I have already seen notified bodies operate quite cautiously in this respect with class IIa apps, for which you could also argue that no IFU is needed.
  4. In the case of IVDs and IVD accessories (like blood glucose management apps) no e-labeling is possible under the regulation and only in exceptional cases under the IVD directive the IFU can be left out (and the same race to bottom considerations mentioned above apply). This is a different and arguably higher burden of proof than the Medical Devices Directive provides.


While reliance on low-risk character of the software concerned to escape e-labeling obligations may look like an attractive strategy for apps I do not recommend as a long term strategy in the EU apps market. Still, the compliant companies on the medical apps market will be bogged down by regulatory obligations that have not been written with the realities of the mHealth market in mind. The EU needs a more nuanced regulation of standalone software as medical device for consumer end-users.