The MHRA's new guidance on standalone software as medical device and DIA Euromeeting update


A nice repack, with some additional little gems. That’s how I would describe the recently released MHRA guidance on standalone software as a medical device.

The guidance of course has to color between the lines of the existing MEDDEV on standalone software (which itself is under revision currently but seems to have been bogged down considerably in the responsible MDEG because of a competence struggle between the software MDEG and the borderline MDEG), so the added value is limited for those that already are familiar with that MEDDEV. On the other hand, if you compare it to the Swedish guidance 2.0, you can clearly see that the MHRA is much closer to the scope of the MEDDEV than the Swedish MPA, which in itself is also added value.


The guidance contains a convenient list of words commonly associated with medical device functionality, or, in the words of the MHRA are “likely to contribute to a determination by the MHRA that the app they were associated with is a medical device”:
  • amplify,
  • analysis,
  • interpret,
  • alarms,
  • calculates,
  • controls,
  • converts,
  • detects,
  • diagnose,
  • measures,
  • monitors

This list is slightly different from the list of operations of ‘altering’ of medical data given on p. 10 of the MEDDEV because it goes quite a lot outside the scope of that concept of altering and, therefore, is of interpretative value. Officially this is only the MHRA’s view, and not all other EU competent authorities may share this interpretation, even if that would be a good idea.

Paper IFU

The guidance also confirms the official need of a paper IFU for an app for lay persons, which, as I have blogged before, is a very unhelpful rule that really needs to be revisited if we want to take the eHealth, mHealth and apps sector to the contemporary reality of things. However, I have found the delegation from DG Connect very receptive to the need for change here at the DIA Euromeeting in Vienna today when I presented in a session on mHealth, eHealth and apps with them (see below for my presentation). Hopefully their colleagues at DG SANCO will share their concerns.

[slideshare id=32813545&style=border: 1px solid #CCC; border-width: 1px 1px 0; margin-bottom: 5px; max-width: 100%;&sc=no]


More guidance on classification would have been nice, because I experience more and more that rule 10 does not work for standalone software that is somewhere the middle as an active device for diagnosis between medical devices that measure vital physiological parameters and a clinician, particularly because the classification MEDDEV only mentions the devices that do the actual measurement on the patient as “intended to allow direct diagnosis or monitoring of vital physiological processes”. When I tweeted the MHRA about this, I was referred to the general classification guidance, which is exactly what does not solve the problem.

Schermafbeelding 2014-03-27 om 12.40.41

Yet, the connected devices guidance is useful. It confirms the distinction between CE marking of a system as a whole and the logic of EU medical devices law that says that each device need to be classified in its own right based on its own intended purpose.

More guidance on the application of classification rule 2.3 (“Software, which drives a device or influences the use of a device automatically falls into the classification of that device”) would have been nice with regard to standalone software in the middle, as mentioned above.

Green Paper and expanding definitions

An important contribution to the discussion about borderlines between medical devices and general health/wellness software will come from the Commission’s Green Paper that  will be published shortly – likely end of April – with a consultation running until June this year. The green paper will be accompanied by a Staff Working Document on legal issues in this respect, I expect much along the lines of the SWD on telemedicine. This was confirmed by the European Commission at the DIA Euromeeting today. Paul Timmers of the Commission’s DG CONNECT gave a great comprehensive overview of the eHealth Action Plan, where that is now and where it is heading. It was very nice to see how open the Commission’s DG CONNECT people are to hearing about regulatory Catch-22s that limit the possiblities of eHealth, like the eLabeling regulation.

Moving and shaking

That’s what the standalone software field under EU medical devices regulation currently is. Watch this space for discussion of the Green Paper and the SWD when they are published.

Navigate through our knowledgebase

Related articles


Happy 26 May 2024!

The MDR and IVDR are now in force for seven (7) years, and they are not in good shape. I think it is safe to say that they did not deliver on…

Read more


A case of so-called fiscal neutrality

Sometimes you come across cases that violate Mandalorian Creed: “One does not speak unless one knows.”. This happened to me last week when I read the Dutch Supreme Court’s judgment in a…

Read more


Can we fix / improve the MDR and the IVDR?

Or in other words that I’ve asked on this blog before: can the maker repair what he makes? This blog will argue that he can and he should. It still happens to…

Read more