Software in Medical Devices, by MD101 Consulting

To content | To menu | To search

MEDDEV 2.1/6 Guidelines on classification of standalone software released!

New! MEDDEV 2.1/6 Guidelines on classification of standalone software released!
HIS, CIS, PDMS, RIS, PACS, LIMS … Which ones are medical devices, which ones are not?
To answer this question, the European Commission issued a new Guidelines document: MEDDEV 2.1/6, about the qualification and classification of standalone software as Medical Devices or In Vitro Diagnosis Devices.
Download here
After the draft guidance of the FDA about mobile apps, after the guide on regulation of health apps by a UK medical charity, this MEDEV is the third document released in a few months about standalone software.

Content of MEDDEV 2.1/6

Whereas the last two deal only with mobile medical apps, the MEDDEV 2.1/6 embraces all the categories of software dealing with medical data that can be found in a health care centre or at patients’ home.


It contains two decision diagrams to assist the qualification of standalone software as MD or IVDD. It contains also an annex with numerous examples about real cases. You’re certainly going to find yours.
Without surprise, information systems like HIS, CIS, PDMS, LIMS, RIS, are not medical devices. Online documentation is not medical device either. Information systems like PACS and Computer Aided Diagnosis, are medical devices.


If the software is qualified as MD or IVDD, then the document refers to the classification rules of the 93/42 CE directive: rules 9 to 12 about active medical devices. For PACS, nothing new, it refers to the manual on borderline classification (see my other post on classification of software).


One interesting part is about the rules in the decision diagrams to qualify a software as medical device. Every standalone software is an information system, which does at least these three generic operations: receiving, processing and sending data:

  • Receiving data from machines: loading data from mass storage, receiving data from network, receiving data from other devices (medical or not), from sensors …
  • Receiving data from humans: by keyboard, mouse, camera, microphone, …
  • Processing data: computing, sorting, extracting, duplicating, erasing, copying, pasting …
  • Sending data to machines: storing data on mass storage, sending over a network, sending to other devices, to printers …
  • Sending data to humans: screen, loudspeaker, any human machine interface.

I attempted to define a set of rules based on the three generic operations, from the questions in the decision diagram:

  1. If data are received from or sent to a medical device to influence its performance, then it is a medical device (whichever the data, embedded or not),
  2. If data are received or processed or sent for the benefit of one patient and for diagnosis or therapeutic purposes, then it is a medical device,
  3. Exception to rule 2, if data processing is for storage, simple query or data transformation without alteration and in a reversible manner (non destructive compression for example), then it is not a medical device.

I don’t want to replace the decision diagram! It is the result of long process of redaction of this MEDDEV. What I want to emphasize is that the basic question is whether the software manipulates data for diagnosis or treatment purpose of a single patient, these data being either technical, or clinical, or personal. My rules are not perfect and the exception to rule 2 is not a luxury. It prevents from qualifying, any computer, or router or hard disk in a hospital, as a medical device.


The most interesting part from the point of view of software design is certainly the section 4. It raises the issue about IT systems having some modules being medical devices, some other not. If only a part of the IT system can be qualified as medical device, the boundaries of the modules shall be clearly identified by the manufacturer.
I use “shall”, whereas the MEDDEV uses “should”. I think this difference is of most importance; hence not clearly identifying functional boundaries will lead to not clearly identifying technical boundaries.
On top of that, the MEDDEV insists on the conservation of safety and performances, when medical devices modules work in combination with other modules.
This is only achievable with a rigorous design.
Let’s imagine an IT system made of 3 main layers:

  • A basic layer on the operating system, it contains Soups
  • A middle layer organized in modules, which contain module specific software,
  • A top layer which contains GUI and other elements to “glue” modules one another


The module #3 falls into the qualification of medical device. Its functional boundaries shall be clearly identified. Eg: all functional performances listed in the intended use are handled by module 3. And the design constraints of module 3 are going to have fallouts on other modules or other layers. Especially, the risk analysis may have consequences on other modules, on basic layers and on the main GUI. If the system contains SOUPs, they shall be treated with the constraints of medical devices design.


If functional boundaries are important, technical boundaries linked to design constraints are important as well and may be more extended than functional ones. They also may be difficult to determine. Eg: to what extent the services in a basic layer are impacted by medical devices design constraints?


Existing vs new systems

If the module is a new one added to an existing system, the consequences on design constraints may lead to the redesign/refactoring of the system. Hence there is no proof that the existing system is safe according to the criteria of medical devices. It may need some separation or insulation of some components or any other design technique to ensure the safety. The final consequence may be additional costs of integration not forecasted when the design of the module was begun.

If the module is a part of a brand new system, the consequences are less important. The design is done at the very beginning with the constraints of medical devices. It’s a non-negligible cost but it has more chances to remain in the estimations.

Classification of modules

The design constraints range from light for class I to paranoiac for class III medical devices. Class IIa and IIb are at intermediate stages. In my own opinion, medical devices modules integrated in systems with modules for other purposes shall not be classified more than IIa:

  • If it’s class I or class IIa, it may be part of a system,
  • If it’s class IIb or class III, forget it.

Even if it’s in class I or class IIa, you should be cautious and insulate as far as possible your module from the rest of the system. For example, by running it on a separate process or a separate machine. Insulating also means taking actions on design. You should separate the module from the rest of the system. It may require duplication of basic layers in specific configuration branch, to ensure that any change in the system will not compromise the safety of the medical device module.


Depending on the architecture of the system, this may be seen paranoiac, or too much a precaution, or a source of duplicate code. But don’t underestimate the growing entropy of successive versions of systems. When in a few years another module is upgraded and refactored, such a design may save your system.


The MEDDEV 2.1/6 Guidelines are a real step forward. They gather in one document the criteria to determine if an IT system is a medical device or not. The document gives a lot of examples and your case is most probably inside. It warns also about constraints on heterogeneous systems, which integrate medical devices. We've seen that there is no specific design recommendation about this kind of system; hence this is not the level of detail of this document.

A very good guidance on standalone software!


1. On Saturday, 2 February 2013, 21:05 by carla

Hi mitch,
i've been reading lot of your stuff, grat job! and thanks for all information you create and share.
i still have a question which i cant' find an ultimate answer to.
Let's say a manufactirer have developed a stand-alone software which handles data in such a way that according to meddev 2.1/6 could be classified as medical device.
Yet the manufacturer hasn't stated that the software is specifically intended for diagnostic and/or therapeutic purposes (see a) decision step 5 in meddev and b) medical device definition in Directive 2007/47/EC).
This being the situation (no intended use stated as diagnosis, prevention, monitoring, treatment) is the software still a medical device? Does the manufacture need CE mark in order to sell the software or can the manufacturer state the software isn't a medical device (say 'cause it doesn't fulfill all the directive requirements) and sell it simply as a software?
Hope my question is clear enough :)
thanks in advance, have a nice sunday
carla (italy)

2. On Tuesday, 5 February 2013, 09:33 by Mitch

Hello Carla,

Good question, I don't have the answer. Maybe this is the job of a lawyer to answer that kind of question!

My own opinion is that it's possible to "avoid" claiming an intended use for medical purposes if it's obvious that the device was not specifically designed for medical purposes.

3. On Tuesday, 5 February 2013, 20:06 by carla

Hi Mitch,
thank you so much for your kind reply;
I know it's a complicated question
my guess is this: let's say i've got a software that allows collecting, store and communicate patient data: they're medical data, of course.
According to decision step 3 in Meddev 2.1/6 as long as the software performs no actions on data other than those previously listed, the software is not a medical device.
But they're medical data: i collect, store and communicate them in order for someone (a practitioner?) to review them and, maybe, support medical care, or just monitoring health state. However, I do not state an intended use, which doesn't mean someone could use the software as indicated (as well as exploit software for other uses).

And then say I'm not ready to put it on the market as medical device (quality management system is not ready yet even though i'm working to its fine-tuning, no clinical investigations ready yet, and lack of conformity with other requirements for the time being,...)

If i go back to MDD 47/2007, to iso 13485, to iso 14791, to iec 62304, to TR80002-1, i can't say how many references I've found to "manufacturer specified intended use". So, shall i infer that an intended use unambiguously declared by the manufacturer is an unavoidable requirement for a software product to claim it to be a medical device?
And therefore: no unambiguously stated intended used => no medical device => I can go to market safely now with my product as plain software, and in the meantime do all what needs to be done to issue a software medical device later?

I know it's a complicated matter, but though I've read so many things about MDs and related regulations and standards, I can find nowhere someone who's addressed the matter.

Thank you again for reading, have a nice week

4. On Friday, 8 February 2013, 13:02 by Mitch

Hi Carla,

Complicated, as you say!

"all i infer that an intended use unambiguously declared by the manufacturer is an unavoidable requirement for a software product to claim it to be a medical device?"

Yes, true.

And therefore: no unambiguously stated intended used => no medical device => I can go to market safely now with my product as plain software, and in the meantime do all what needs to be done to issue a software medical device later?

Probably yes. I can't say more, unfortunately.

5. On Friday, 8 February 2013, 14:05 by carla

hi Mitch, so kind of you
i'm reading back all stuff you posted here, very useful indeed!
thanks a lot!

6. On Tuesday, 6 August 2013, 11:48 by MassimoM

I think it's clear that it's up to the manufacturer to declare a product as a medical device. You can choose not to declare this. But probably no medical operators will use your system, as they must use only CE marked products

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed