MEDDEV Guidelines on Stand-Alone Medical Software Published

January 25, 2012 – 3:48 pm

The MEDDEV guidelines on stand-alone software have just been published, prompting the question: What does it all mean? We asked lawyer and blogger Erik Vollebregt. He had the answers (and a few more questions). Vollebregt is a partner at Amsterdam-based life sciences boutique law firm Axon Lawyers and maintains the medicaldeviceslegal blog.

Erik Vollebregt
Erik Vollebregt

medtechinsider: Can you give us some background on the genesis of this document and why it is needed?

Vollebregt: The MEDDEV basically came about as a result of the movement started by the now-famous report from the Swedish Competent Authority Lakemedelsverket: the “Proposal for guidelines regarding classification of software-based information systems used in health care.” This very useful document published in 2009 addressed issues involving both the classification of software as a medical device and risk management of software in a clinical environment. The report also contained a useful set of examples. COCIR later developed a flow chart that could be used for qualification under the medical device directives.

The current MEDDEV is a version of these two documents drafted by the Medical Device Expert Group minus the part on risk management of software and IT implementation in clinical settings from the Swedish report.

The guidance is needed because stand-alone software is playing an increasingly important role for clinical purposes: there is an app for everything these days. However, the current medical device rules in the European Union were drafted with embedded or pre-installed software in mind. For that reason, it is incredibly important to have guidance on how to deal with this for regulatory purposes.

medtechinsider: How does the MEDDEV address industry concerns and questions?

Vollebregt: It basically provides a frame of reference for stand-alone software under the three medical device directives, which is important for compliance purposes. Many companies don’t know how to comply because they are coming from a software background and are new to medical device regulations.

The MEDDEV provides clarification of definitions that link to the medical device and IVD directives. It gives guidance on how to determine if software qualifies as a medical device and, if so, whether it qualifies as a general medical device under the general medical device directive or as an in vitro diagnostic device under the IVD directive. It does not contain guidance on determining how stand-alone software could be covered by the active implantable medical devices directive but the qualification as a medical device theoretically makes that possible if the other scope-related criteria of the active implantable device directive are met.

medtechinsider: Are there any points in the document that you feel are particularly important?

Vollebregt: The decision trees and step-by-step instructions for qualification under the medical devices and IVD directive are really helpful.

The part about modules also is helpful. Although it is not as clear as one would like and it is derived from existing provisions in Annex I of the medical device directives about modular systems, it still recognises that it is possible to CE mark a part of a larger set of applications working together. This is the part that actually has the medical functionalities regulated as per the flow charts.

Also, it contains many useful examples and provides for the possibility of additional examples being added in the “Manual on Borderline and Classification under the medical devices directive.”

medtechinsider: Are there any ambiguities or other issues worth mentioning?

Vollebregt: Of course, a guidance document never answers all the questions. For example, it could be challenging for manufacturers to identify how the different modules of a larger software system relate to each other and where medical functionality starts or ends. Furthermore, they must ensure that the whole system is safe and does not impair the specified performance of the modules that are subject to the medical device directives if medical functionality modules are combined with modules that do not have a medical function. On the other hand, medical device regulations in the European Union are appreciated for their flexibility, allowing manufacturers to present evidence in a way that works for them.

Another concept that warrants attention is that of “accessory,” which will become increasingly important in the software context. An accessory is “an article which, whilst not being a device, is intended specifically by its manufacturer to be used together with a device to enable it to be used in accordance with the use of the device intended by the manufacturer of the device.” Since stand-alone software often needs specific hardware or other software for its input or output, such hardware or software may constitute an accessory. Accessories, mind you, are regulated as devices in their own right. This is why the step of determining if you are dealing with an accessory figures so prominently in the flow charts. If you place an iPhone add-on for measuring blood glucose on the market that uses an app that you can download from the app store to display, store and trend results, the add-on is an accessory to the app. The iPhone is not intended by its manufacturer to be used with a medical device, so it would not be an accessory. It would need to be taken into account, however, in the CE marking of both the app and the measuring add-on.

So, a lot of new guidance, but also a lot of new questions. And don’t forget there’s more in store with the review currently going on. Although this process will take  time and the new legislation probably will not be in force before 2015 at the very earliest, industry should prepare for the following, which will impact stand-alone software:

  • In terms of scope, more diagnostics will be covered under the medical device rules. The European Union intends to include within the scope of the new regulation genetic tests for lifestyle purposes and diagnostic services provided at a distance.
  • The requirements for clinical validation of software will become stricter. Specifically for IVDs, the European Union is contemplating evaluation of clinical validity and utility of IVDs.
  • The requirements for postmarketing surveillance of software will increase and be further streamlined. Just look at the new Post Marketing Clinical Follow Up MEDDEV that was released this month. This also applies to stand-alone software.
  • The European Union will impose further traceability requirements and is likely to start a register for the publication of summary information of higher risk devices, as is currently mandated by US FDA.

Then there are the following questions/issues that come to my mind:

  1. The types of data manipulation and mining that qualify for regulation. It often may be difficult to determine if the software concerned performs an action on data that goes beyond storage, archiving, communication or simple search, which would have it fall within the scope of a medical device. In all other cases, data-related actions that assist the user for a medical purpose probably would make the software a medical device.
  2. Marketing claims and labelling. Marketing claims for medical devices will have to conform to their labelling and intended use. The use of new software and IT-related terms—flags, integrated, personalised, artificial intelligence, decision support—may prompt discussions about off-label promotions or incorrect scope of the CE mark for specific software.
  3. The freedom of end-users to tailor software to individual needs without regulatory oversight. There has always been ambiguity around how much hospitals and other end-users can configure software before they become a regulated manufacturer. The current definition of manufacturer excludes assembly or adaptation of devices already on the market to their intended purpose for an individual patient (Article 1 (2) (f) MDD). This definition, however, was written with modular physical devices in mind rather than software, which may be configured to include functionality that the manufacturer did not intend.
  4. International harmonisation. Many of these software products are deployed globally. With the sunset of the Global Harmonization Task Force (GHTF) at the end of 2012, it will be interesting to see how its successor, the International Medical Device Regulators Forum (IMDRF), will continue to drive the successful international harmonisation project for medical technology in this area.
  5. Wellness versus disease. Intended use determines the regulatory status of a product. Sometimes the mere mention of the use of a product in connection with a disease is enough for it to be regulated as a medical device. Since the European Union uses a binary criterion to define whether or not the product is regulated as a device, software intended for general health and wellness purposes may fall into regulated territory. One could ask, for example, if software for patient education and lifestyle management relative to chronic diseases should be regulated.

Anyway, some food for thought. Read my medical technology regulatory and legal blog—I will be discussing many of these issues in the future and I invite everyone to participate in the discussion.

Related Posts Plugin for WordPress, Blogger...

Tags: ,

Bookmark and Share
  1. 1 Trackback(s)

  2. Feb 2, 2012: The new EU MEDDEV on stand-alone software as medical device « medicaldeviceslegal

Post a Comment