Software in Medical Devices, by MD101 Consulting

Software is an active medical device

Software shall be considered an active device.

It's written at the end of the definition of active device. We were doubtful, we're reassured.
More, in the implementing rules of the classification rules in Annex VII, we have:

If the software is independent of any other device, it is classified in its own right.

Standalone software is then an active device and it is classified in its own right.

Classification rule 10a

The biggest change in the MDR is the introduction of a new classification rule, specific to standalone software:

Rule 10a

Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes, is in class IIa, except if such decisions have an impact that may directly or indirectly cause:
- the death or an irreversible deterioration of the state of health, in which case it is in class III;
- a serious deterioration of the state of health or a surgical intervention, in which case it is in class IIb.

Software intended to monitor physiological processes is in class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations is such that it could result in immediate danger to the patient, in which case it is in class IIb.

All other software is in class I.

This rule shows clear similarities with the works of the IMDRF on risk categorization of software as a medical device. The criteria of categories I to IV of IMDRF are close to the criteria of classes I to III of rule 10a.

A major change for standalone software

The rule 10a is a major change since the classification is based on the purpose and the risk assessment of the device, and not the purpose of the device alone. This notion of risk was already present in the directive 93/42/CE, in rules 6, 9, 11 (potentially hazardous) and 10 (immediate danger), shifting the class up one level for affected devices.
Now, for standalone software, the risk assessment is the keystone of the regulatory classification. A single risk with high severity can push a software medical device to a higher class.
The other major change is the possibility to have standalone software in class III. With the directive, it's only possible per the implementing rule 2.3 of annex IX.

No classification change for embedded software

The classification of embedded software is left unchanged in the MDR. Embedded software takes the class of its device.
Likewise, the implementing rule 2.3 is still present: software, which drives or influence a medical device takes its class. Unfortunately, the MDR doesn't define the word influence, leaving the rule to interpretation, like in the directive.

Advantage

The single advantage of this new rule is to better synchronize the definitions of IEC 62304 safety classes and the MDR classes. However, the last changes in the definition of safety classes in IEC 62304 Amd1 2015 are not present in the wording of MDR rule 10a.
We will have to wait for some feedback from the authorities to see if a software medical device with an improbable risk of severe injury (thus usually making the risk acceptable) will be put in class I or not.

Drawbacks

The main drawback of rule 10a (I take the point of view of manufacturers) is to likely push the regulatory class of software to levels higher than current rules of the 93/42/CE directive. It is possible to have software in class I per rule 12 of the directive. Eg: software delivering information but not for direct diagnosis.
With the new MDR, the rule clearly shows that:

• If software delivering information for diagnosis is in IEC 62304 class B (non-serious injury), it will be in MDR class IIa per rule 10a,
• If software delivering information for diagnosis is in IEC 62304 class C (serious injury but not death), it will be in MDR class IIb per rule 10a
• If software delivering information for diagnosis is in IEC 62304 class C (death), it will be in MDR class III per rule 10a

Examples

Since we don't have any examples of classification per the new MDR, we have to look elsewhere. Fortunately, the IMDRF risk categorization rules provide very interesting examples: they can be interpreted for rule 10a. Let's see examples for medical imaging post-processing software, which are usually in class IIa or class IIb per directive rule 10.

Still Class IIa with MDR

SaMD that interpolates data to provide 3D reconstruction of a patient’s computer tomography scan image, to aid in the placement of catheters by visualization of the interior of the bronchial tree; in lung tissue; and placement of markers into soft lung tissue to guide radiosurgery and thoracic surgery
It's category II for IMDRF, thus likely to be class IIa for MDR.

Still Class IIb with MDR

SaMD that is used to provide information by taking pictures, monitoring the growth or other data to supplement other information that a healthcare provider uses to diagnose if a skin lesion is malignant or benign
It's category III for IMDRF, thus likely to be class IIb for MDR.

Class III with MDR

SaMD that calculates the fractal dimension of a lesion and surrounding skin and builds a structural map that reveals the different growth patterns to provide diagnosis or identify if the lesion is malignant or benign
It's category IV for IMDRF as
SaMD is used to diagnose a disease that may be life threatening, may require major therapeutic intervention, and may be time sensitive,
thus likely to be class III for MDR.
BAM!

SaMD that performs diagnostic image analysis for making treatment decisions in patients with acute stroke, i.e., where fast and accurate differentiation between ischemic and hemorrhagic stroke is crucial to choose early initialization of brain-saving intravenous thrombolytic therapy or interventional revascularization
It's category IV for IMDRF as
SaMD is used to treat a fragile patient in a critical condition that is life threatening,
thus likely to be class III for MDR.
BAM!

Warning: all of this is speculation based on the IMDRF document. We have to wait for a new version of MEDDEV 2.4/1 or MEDDEV 2.1/6 to see the interpretation of this rule and what kind of examples will be given for class III standalone software.

What to do if your software is pushed to a higher class?

Market withdrawal

First and foremost solution: to withdraw your software. If the additional certification costs are not likely to be covered by the market (the market won't accept higher prices, despite the turmoil) then this is one possible solution.
For devices rocketed to class III, this is probably the only solution, given the additional costs incurred by clinical studies.

Do the job

The second solution is simply to determine the new regulatory class, do a gap analysis, and set a plan to make the software compliant with its new class. Something to do for the QMS whatsoever.

Change software

The third solution is to change the intended use and/or the critical functions to make it stay in its current class. It's possible if the functions, which put the device in a higher class per risk assessment, are a nice-to-have and not a must-have. You should remove/change them only if it won't make the end-users unsatisfied or the clinical outcome unsatisfactory.

Change software for bigger

The last solution is to seize the opportunity to implement all the functions, which were left apart, because they would have pushed your software to a higher class. Change software for better, and do the job!

Hello Notified Bodies!

We've seen that it is reasonably foreseeable to expect that a significant number of standalone software will be pushed to higher classes. Higher than class I. Thus Notified Bodies will have to absorb the overload of devices of class IIa or higher to CE mark.
The situation is not as bad as for IVD's. But NB's are already struggling to overcome the wave of denotifications, the unannounced audits, and the pressure of Competent Authorities. Manufacturers can expect long delays between their requests and the date of the NB 's audit.

Conclusion

Standalone software is put in the turmoil by the new MDR, like every other type of medical device. Manufacturers of low-class (mainly class I) devices will face changes of classification. Some manufacturer will see their devices propelled to class III. The transition period is at most of four years. It means that by 2020 all manufacturers will have to be ready for the new MDR.
Manufacturers, consultants and Notified Bodies, we have plenty of work ahead of us!


In a next article, we'll see other changes for software brought by the MDR. See also the interpretation of rule 11 by the MDCG (Medical Device Coordination Group) in the final version of the MDR.