Software in Medical Devices, by MD101 Consulting

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.

Qualification

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.

Classification

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).

Rules

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.

Modules

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.

Conclusion

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!