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.
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.
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.
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.
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.