“Swedish Document” reloaded – a new boost for medical devices standalone software regulation

Sweden is a lovely and industrious country that takes engineering very seriously; the small Scandinavian country that we know from its boxy but good cars also builds its own fighter jets (pretty good ones actually) and is determined to put its mark on the regulation of standalone software under EU medical devices law. The Swedish competent authority Läkemedelsverket has now issued a new version of the famous Swedish Document with the obvious agenda to influence guidance on standalone software under EU medical devices law in the way it has done before with MEDDEV 2.1/6.

Let’s take a look at the document, keeping in mind that the Swedish authorities tend to want to interpret the scope of ‘medical device’ with regard to standalone software wider than most EU countries. An indication of this is that on p. 17 it is stated that

“It is important to bear in mind that it is both the functionality of a product as well as the intended purpose stated by the manufacturer that determines whether software is qualified as a medical device.”

This is in contradiction with the case law of the European Court of Justice, which recently ruled in the Brain Products case that the intended purpose assigned to a device by the manufacturer determines its status as medical device, and not its functionality. Although the court was not as clear as it could have been – as I have argued – it held  that using functionality as a deciding criterion would lead to regulation as medical devices of many devices that could be used as a medical device but are intended for other purposes, so this is the wrong way to interpret the concept of ‘medical device’.

This agenda of  Swedish Authorities is pretty transparent when the report goes on to say that

“However, there are information systems for the health care sector where the manufacturer has not defined their device as a medical device, but still it could affect the safety for patients under certain conditions. Health care providers should in these instances still consider if those systems should be handled with the same awareness of safety as if it had been a medical device.”

and

“On the Swedish market most RIS are for instance CE marked as medical devices.”

In other words, we would actually like to regulate software of which the use in clinical settings could carry risk for patients, even though the report itself says that risk as such can never be a deciding criterion (p. 13). The report also doesn’t mention that the Swedish market is pretty unique in this respect and that this perspective is not shared by most other national authorities in the EU. I have it on good authority that there was also controversy about this between the member states when they were discussing the text for MEDDEV 2.1/6. Just so you know that this is clearly one view at one end of the regulatory spectrum.

As with the initial version the report provides a lot of useful detail and examples. Compared to the existing EU MEDDEV the report contains useful guidance on

- software as service (para 4.1.5), clarifying that this can of course also be a medical device;
- smartphone apps (para 4.1.6), clarifying that an app that qualifies as medical devices does not necessarily makes the phone as such or the combination of the two a medical device; and
- ‘home brew’ standalone software (para. 4.3), clarifying that one should approach this along the lines of the thinking surrounding home brew IVDs.

The appendix to the document is well worth reading and contains several separate annexes on interesting subjects with a lot of practical information and guidelines:

Annex 1. Risk management

Annex 2. Standards and recent development of standards

Annex 3. Clinical evaluation of medical information systems

Annex 4. Networks

Annex 5. Procurement and issues referring to CE marking (most interesting for me personally, as it discusses tendering strategy for software systems)

Annex 6. Product examples (the largest part of the document, with 19 case studies of software examples. Exercise with caution however, as the Swedish authorities tend to draw the scope of the concept ‘medical device’ wider than others).

All in all a very worthwhile read indeed and guaranteed to provoke discussion in the process surrounding the revision of the standalone software MEDDEV 2.1/6. Also, the annexes provide useful practical examples for the growing apps and other software industry about how conformity assessment for a software medical device works.

However, I think the report could have done better at discussion of the concept of accessory. The report stops at the statement that “[s]tandalone software can, without having a medical purpose of its own, be essential to maintain an intended function of another medical device. It can then be an accessory to a medical device.” This is not a very precise statement at all. I, personally, think that the definition of accessory is extremely important, as the discussion of several examples of modular systems in the report shows when it discusses how non-medical modules can still be regulated as accessories to the medical device module. I think it is even more crucial to develop a position on the concept of accessory in view of the considerable extension in scope in the current proposal for the new regulation on medical devices and the proposal for a new regulation for IVDs to include devices that not only “enable” but also “assist” a medical device in achieving its intended purpose. The definition of this humble little concept will have a severe impact on regulation of standalone software in networks and systems, and, consequently, all eHealth, telemedicine and mHealth services that rely on networks and systems.

Erik Vollebregt