If EU MDR still makes you scratch your head, then you’ve come to the right place. In this blog post, we’re discussing some of the most perplexing EU MDR-related questions we’ve come across.

All the answers are provided by our EU MDR expert, Krzysztof Minicki, Director of Healthcare and Life Sciences at Spyrosoft.

Is the clinical evaluation consultation procedure obligatory for all medical devices?

In the case of class IIb medical devices, the consultation procedure is optional. For class III devices, it’s obligatory.

Is software running on a medical device seen as a medical device accessory?

Software is considered as a medical device accessory when it can be treated as an addition to some kind of configuration. If software serves a specific medical procedure, or a specific functionality of a medical device, for example, a web app used for configuration of such a device, then this software can but doesn’t have to be, considered as a medical device accessory.

Mind you, firmware is not considered as a medical device accessory. For software to be considered a medical device accessory, it must be integrated externally with a medical device that works independently.

These are just the general rules. To ultimately determine, whether specific software qualifies as a medical device accessory or not, you need to take other factors and MDR rules into consideration.

When it comes to the classification of a medical device accessory, it always “inherits” the same class as the medical device it’s used with. That’s because it doesn’t have a separate Intended Use: it’s used only as an addition to the medical device.

Is it possible that a medical device and software have different classes?

Yes, it’s possible. For example, a class III medical device that has the highest risk level can be supported by software that includes only simple, basic functionalities, doesn’t impose any risk, and therefore qualifies to a lower class than the medical device.

Additionally, according to IEC 62304, it’s possible to declassify certain software components if specific criteria considering isolation and decomposition are met.

For example, let’s say your software has certain components that perform different functionalities, and these functionalities have different risk levels. You can decompose your software on the software architecture level into modules that belong to different software classes. For example, the whole device will be in class III (class C as software) due to a high-risk level, but certain modules that meet the isolation criteria will belong to lower classes (software class b or a).

This approach is often applied in the case of complex systems due to proper medical risk management and cost optimization (the higher the class, the more expensive the development and maintenance process).

What if a medical device isn’t used in line with its Intended Use? Who takes the responsibility: the party that bought the device or its manufacturer?

If someone uses a medical device not according to the expected Intended Use, the responsibility lies on them, not the manufacturer.

Find out more about EU MDR from our guide >>>

Can I add a disclaimer inside the system or app to avoid classifying it as a medical device due to a certain feature?

The scope of functionalities declared in the software’s Intended Use must be accurate and must reflect the real state of affairs. Adding a disclaimer is not an acceptable solution.

For example, if a medical device is used to monitor some aspects of a patient’s health and provides suggestions for medical diagnosis and treatment-related decisions based on the data gathered, while its Intended Use is limited to monitoring, you as a manufacturer aren’t allowed to add such a disclaimer.

When developing new functionalities of your software, keep in mind that you can’t add any features that would exceed the scope of its Intended Use. To be able to do that, you shall first make changes to the Intended Use, which may result in the reclassification of your device.

How to decompose software into modules to determine which one is considered a medical device?

It’s done based on a software architecture document. It should describe the Intended Use of the whole system and present the decomposition into medical and non-medical modules together with the justification.

Are there any good practices or hints for system decomposition?

There’s a simple rule: good software architecture is necessary. It serves both the developers and the whole regulatory strategy.

Firstly, you should think over the strategy, starting from defining the Design Input, which included the Intended Use, project requirements, determine the Intended Market and Intended User, etc. This will be the foundation for your further work.

You should also control every change made to the software, especially in terms of the Design Input. Before introducing any change, you should ask yourself:

  • Does it impact the current Intended Use or medical device classification? If yes, how?
  • Does it impact the current risk level?

You should also keep in mind that the modularity and architecture should serve your needs and be structured well enough so as not to increase the overhead. However, separating the medical modules from the non-medical ones implies architectural consequences. You must foresee all possible risk areas. This, in turn, leads to more complexity and more labour.

Didn’t find what you were looking for? Check also other posts regarding EU MDR on our blog:

If there’s something else, you’d like to know about EU MDR, don’t hesitate to use the contact form below and shoot us a message. We’ll get back to you ASAP.

About the author

Małgorzata Kruszyńska

Małgorzata Kruszynska

Business Researcher