Mobile apps
In my experience those especially left out are the manufacturers of standalone software that is not intended for professional users, which is a quickly developing and fast growing market. While the regulation covers standalone software, this is limited to standalone software for professional use. Consequently, all other standalone software (yes, this includes all healthcare apps in scope of the medical devices directives) must be paper-labeled. I myself believe that the regulatory logic here leaves a lot to be desired.
Normally, the regulator would want to ensure that the user always has easy access to the IFU, no matter what the device itself does or where it is. This thinking is pervasive in the regulation and other labeling rules. However, this reasoning fails to take into account that for apps on mobile devices the best – no, the absolute very best – way to make sure that a user always has access to the IFU, is to make sure it’s embedded in the app itself. If the app functions, the user has access to the IFU and if it doesn’t the user can always find the IFU online on a website.
Although the EU is advocating the use of mobile apps in healthcare all over the place (for example as part of its eHealth Action Plan, it is doing a great job of making placing on the market of apps in a compliant way pretty much impossible at the same time. Really, the consequence of the current e-labeling regulation is that any app that is a medical device must have a paper IFU and other labeling. If not, it is not in compliance and must not be on the market. This also means that when the supply chain controls under the new medical devices regulation enter into force, distributors and importers of apps that are medical devices (Apple, Google, Microsoft, just to mention some of the big guys in app distribution) are going to be under an obligation to check all these apps for compliance with this requirement (and other requirements for CE marking).
This, of course, is an undesirable result and it is clear that the different directorate-generals of the Commission have missed out on an opportunity to talk to each other and make regulation better for everybody. DG Connect is going pedal to the metal stimulating healthcare apps that are medical devices wherever it can, while DG SANCO pulls the the handbrake.
My opinion is that we need a MEDDEV that provides for an exemption to allow e-labeling of apps – limited and conditional and of course taking into account risk management – just like happened for IVDs with MEDDEV 2.14/3. That should be doable because the Standalone Software MEDDEV 2.1/6 is currently under revision, so it can be written right in, provided that the member states authorities working on the MEDDEV in the software group want it. While this is not currently on the table as far as I know, I think it should be. Like with IVDs at the time, this is necessary now. Otherwise we would miss a good chance to remedy this and the apps market that we would like to see flourish will wither. If the Commission wants to empower patients with medical apps: big cheers and hands in the air. But: this will not work if it is made prohibitively difficult to do so in a compliance manner. Otherwise the Commission’s European Directory of Health Apps will be embarrassingly empty, only because the Commission is unable to sort this out within itself.
Enforcement climate
There is not much experience with enforcement by the respective EU authorities, so it’s too early to tell if there are marked differences between the respective national authorities’ interpretations. This also makes it difficult to predict if there would be momentum to amend the MEDDEV 2.1/6 to create an exemption for e-labeling of apps in scope of the medical devices directives. However, I’m sure the authorities will not disappoint us and create some interesting puzzles of diverging enforcement policies, regardless of the fact that we have a unified legislative instrument now – but that just says categorically “no”.
A flowchart
I found that the regulation is a bit dense, although it does follow a process that is logical to an extent. Logic allows for flowcharting, of which I am a big fan because it helps me immensely to understand regulation. So here is my interpretation of the process of the regulation. I cut some corners here and there meaning that the tree is a bit low on detail in some places, but it should be a helpful instrument for understanding the regulation in any event. If the below picture on your screen is too low-res (you can save it by right-clicking and then saving the picture), you can download the full resolution picture here. Feel free to use, spread and amend it for whatever purpose you like. The only thing I ask is that if you improve it or disagree with it, please let me know so I can incorporate your comments for everybody’s benefit.