Standalone software: objects in the regulatory mirror may appear simpler than they are

  • Posted on 12.04.2012

Standalone software: objects in the regulatory mirror may appear simpler than they are

Erik Vollebregt

Erik Vollebregt

Life Sciences and IP Lawyer, and Founding Partner Axon Lawyers


January 2012 was a fruitful month for EU guidance on medical devices and produced among other MEDDEVs the MEDDEV 2.1/6 Qualification and Classification of stand alone software. This MEDDEV contains the latest thinking on how stand alone software, i.e. software that does not necessarily run on a medical device (but may have medical device functionality), qualifies as medical device under the three medical devices directives. If you are interested in a lot more background about the MEDDEV than I can provide in this blogpost (and especially nice flowcharts, which make life more simple for everyone), you can find it here.

The new MEDDEV is important for medical devices manufacturers, but also for software developers and companies that are not yet active in the medical devices field and may see their software regulated under the medical devices directives. More and more companies will deal with this as more and more health apps enter the market and existing functions of software used in the healthcare setting (like electronic health records) are expanded with additional functionality that would make it a medical device (e.g. an expert system for differential diagnosis or functionality that can assist in interpreting images). ‘Traditional’ devices manufacturers will be faced with this as they provide additional software to make their devices more user friendly or effective, like iPad apps that can control or monitor a group of infusion or food pumps in a particular ward remotely, f.i. from the nurses’ station. The same will happen in IVDs, where expert system functionality becomes more and more important as the amount and complexity of raw data produced by IVDs keeps growing. Furthermore, the way standalone software is delivered to the end user is often radically different from the traditional model, so manufacturers must start to adopt a ‘device as service’ strategy for these.

Many are wondering how one should actually CE mark an app. Well, there’s a commendable initiative by d4 Research  around the CE marked Mersey Burns app that resulted in a how-to guide that provides a good start and frame of reference.

There are four areas related to software as device that I think are of particular importance for manufacturers: 

  1. Accessories: the accessories rule applies to stand alone software as it does for anything else. This means that any app or other software that extends or assists the intended purpose functionality of the device, constitutes an accessory to the device and is therefore regulated as device in its own right with all bells and whistles that go along with that. I see that many companies overlook this in practice.
  2. Medical as service: many will be familiar with software as a service, but if software as services is regulated as a medical device, it’s a ‘medical device as service’. This offers opportunities for e-commerce as I have argued, but also necessitates thinking about your quality system and Post Market Surveillance (PMS)/vigilance in a completely different way.
  3. Modules: as stated, a lot of software will start to creep into the devices field as it extends its functionality into the scope of the medical devices directives. The MEDDEV provides a solution that allows for modular CE marking under the medical devices directives, so the software developer would only need to CE mark the module of the software that has medical devices functionality, provided the boundaries can be defined and whole combination, including “the connection system” (I suppose they mean interface(s)), is safe and does not impair the specified performances of the modules which are subject to the medical device directives. The methodology of this solution is however based on the current provision for modular physical medical devices in the essential requirements (as the use of ‘connection system’ in relation to software shows), and transposing this to software does lead to some complications in practice.
  4. Data protection: on 25 January 2012 the proposal for the General Data Protection Regulation went into the legislative process and although many things are still not completely settled, it’s safe to say that processing of health data will be regulated a lot more strictly and the EU will require a lot from the parties processing data in terms of ‘privacy by design’, consent from the patients to processing of their data and security. This has consequences for stand alone software design, because it is hard to conceive software as medical device that will not be processing health data in the current definition in the proposed regulation.

So, even though the new MEDDEV provides for a lot of good guidance, it also invokes questions. It so happens that EMDT is organising a webcast on these issues on 24 April, 15:00 CET, in which I will do my best to discuss these points and try to answer as many questions as possible. It’s not free, but if you register timely (before 16 April), it’s only € 49. You can register here.

– Erik Vollebregt, Life Sciences and IP Lawyer, and Founding Partner Axon Lawyers

The comments are closed.