MDR software classification

Chr1sG

Starting to get Involved
#1
Hi there,
First time posting, hoping folks might chip in with their perspectives.

I'd like to get an opinion on how to classify the software elements of my product, and in order to do so, I'll give you all a quick idea of what it does and how it does it (without revealing too much that is confidential).

The system consists of 4 parts:
1. image acquisition unit (IAU) - takes photos of body part. It has embedded SW to acquire the images and provide limited user interfaces (on/off button, plus LED to indicate power/charging)
2. user app - wirelessly connects to the IAU and acts as the main UI to guide the user and to trigger/manage image acquisition. The images are sent onwards together with some user-provided patient info.
3. cloud store - receives images/info from the user app and stores them pending review.
4. clinical review client - web-based app which can access stored images and patient info, and allows a clinician to review them, and to create a clinical assessment report. Note: the software does not modify the data, nor assist the clinician in any way (other than maybe offering tick boxes, annotation/comment functions etc.)
The clinical report is sent back to the user app from the review client, via the cloud store.

I have read and re-read MDCG 19/11 but I am still not certain about how to classify the various SW elements.

Which are 'Software driving or influencing the use of a medical device'? Which are MDSW?
Assuming that the IAU is a Class 1 device, what class should the various SW applications be?

At the moment, I am leaning towards 1. and 2. being SW driving/influencing (=> Class 1), and the other two not being MDSW since they neither drive/influence nor have their own intended medical purpose (=> not covered by MDR).

Anyone care to comment?
 
Elsmar Forum Sponsor

Ed Panek

QA RA Small Med Dev Company
Staff member
Super Moderator
#3
I have had our NB in EU ask if we meet the FDA guidelines on cybersecurity. Be prepared.
 

Chr1sG

Starting to get Involved
#4
Seriously? Wtf?
How was the question justified?
Did your NB also ask if you meet the japanese ultimate frisbee rules?!

Anyway, any thoughts on classification?
 

yodon

Staff member
Super Moderator
#5
I don't presume you're marketing the individual components separately so the *system* needs to have a device class.

IEC 62304 (recognized consensus standard in the US and harmonized in the EU) lays out a decision tree for establishing software safety class. You can independently assess each of the software items. The safety class decision is based on the harms that can be realized if the software fails.

Note that the FDA has a similar decision tree in a guidance document but they use the terms major / moderate / minor level of concern.

Regarding:

I have had our NB in EU ask if we meet the FDA guidelines on cybersecurity.
The only thing I can think of is that this was an ISO audit, the scope of the QMS includes US, and the auditor was determining if they met the requirements of the "applicable standards." (I may be wrong but that would seemingly be the only logical explanation.)
 

Chr1sG

Starting to get Involved
#6
Thanks @yodon

After posting, I was thinking more about the problem, and had started to reach the same conclusion, namely that the product as a whole cannot deliver its intended use without all the software subsystems playing their respective parts.

I note that you use the word system - should I assume that you mean this as defined in the MDR? ('a combination of products, either packaged together or not, which are intended to be inter-connected or combined to achieve a specific medical purpose')

If so, what are the implications of our product being a 'system' vs a 'device'? I can only see that 'system' has any meaning within MDR in Article 22, so I suppose you are saying that paragraph 4. of Article 22 is where we would be covered, right?
 

Chr1sG

Starting to get Involved
#7
For what it's worth, I think part of the reason why I was tying myself in knots was because of the wording in MDCG 19/11:
"Software, which drives a device or influences the use of a device, shall fall within the same class as the device."

When a piece of software is a necessary component of a device, then this line would seem to be applicable, but on the other hand, if you imagine substituting a necessary hardware component into this sentence, it starts to make no sense:

e.g. "A printed circuit board, which drives a device or influences the use of a device, shall fall within the same class as the device." !!!

or "A gearing mechanism, which drives a device or influences the use of a device, shall fall within the same class as the device." !!!
 

yodon

Staff member
Super Moderator
#8
I do wonder sometimes if the writers get paid by the word. ;-) Seriously, your device, as you describe, comprises numerous components, many of which happen to be software. Untie the knots in yourself and just think of device class for the system.

Do recognize that the software safety class (or FDA level of concern) is different. There's correlation based on risk but they are independent. You may be able to ease the (documentation) burden if you can down-classify some of the software components.
 

Chr1sG

Starting to get Involved
#9
Yes, thanks.
I am now 99% sure that the device as a whole (sw, hw, mechanics etc.) is Class 1 according to MDR, so I'll try not to lose any more sleep second guessing the guidance.
And yes, the 62304 risk classification is next on my list :)
 
Thread starter Similar threads Forum Replies Date
M Informational EU – Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR Medical Device and FDA Regulations and Standards News 2
dgrainger Informational MDCG 2019-11: Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR Medical Device and FDA Regulations and Standards News 0
G EU MDR 2017/745 Rule 11 interpretation - Re-classification of a Software as Medical Device Other Medical Device Related Standards 0
S MDR GSPR Clause 17 - Software Requirements EU Medical Device Regulations 2
B Notified Bodies for Software (MDR) EU Medical Device Regulations 1
C MDR - Question around software accesories EU Medical Device Regulations 2
JoCam Software Translation under MDR requirements EU Medical Device Regulations 6
R MDR Software Rule 11 Formal Interpretation EU Medical Device Regulations 7
J Qualification of a Software as a Medical Device (SaMD) guidance under MDR EU Medical Device Regulations 9
M Reworking MDD product w MDR labeling CE Marking (Conformité Européene) / CB Scheme 0
A MDR and Poland EU Medical Device Regulations 6
Ed Panek Invitation to the MDR Dance EU Medical Device Regulations 5
M EU MDR language-Translation requiremens CE Marking (Conformité Européene) / CB Scheme 1
I What are suitable indicators and threshold values in MDR/IVDR? Medical Device and FDA Regulations and Standards News 3
A Sell-off legacy devices MDR EU Medical Device Regulations 0
A Eudamed actor registrations if you change AR for MDR product EU Medical Device Regulations 0
Ed Panek Which choice of the following most closely matches the MDR compliance of your company? EU Medical Device Regulations 0
K Definition of SAE under MDR EU Medical Device Regulations 3
Q Harmonised Standards (EN ISO 13485 / EN ISO 14971) in MDR (2017/745/EU) ISO 13485:2016 - Medical Device Quality Management Systems 3
Ed Panek Clarity from EC on Importer/Distributor roles in MDR EU Medical Device Regulations 9
Pmarszal BS EN 20417:2021 - Implementation Timeline Aligned With MDR? Other ISO and International Standards and European Regulations 1
T Dental lab acrylics and MDR EU Medical Device Regulations 0
S Biggest issues when producing MDR compliant Technical Files / DD EU Medical Device Regulations 4
A Declaring Conformity with MDR Article 120(3) for an MDD Legacy Device EU Medical Device Regulations 1
D EU MDR - Change of device name (legacy device) EU Medical Device Regulations 4
J Technical Documentation as per MDR / subpoint 6.1 EU Medical Device Regulations 3
M EU MDR - Retrospective Study for expanding indications of a legacy device EU Medical Device Regulations 0
B MDR Technical Structure EU Medical Device Regulations 3
D Notified Bodies - ISO 13485 & MDR Technical Files ISO 13485:2016 - Medical Device Quality Management Systems 3
L Configurable UDI mdr EU Medical Device Regulations 0
O EU MDR labels EU Medical Device Regulations 1
S Summary of safety and clinical performance and Article 120(3) of the MDR EU Medical Device Regulations 4
M MD Class I transition period MDD to MDR - changes? EU Medical Device Regulations 1
C UDI for consumable/replacement components under the MDR EU Medical Device Regulations 2
E Article 17 MDR - (Re-)Processing EU Medical Device Regulations 0
H Article 22 MDR System EU Medical Device Regulations 16
L REACH compliance with MDR EU Medical Device Regulations 4
L EU MDR Ramifications for no expiration date on labeling EU Medical Device Regulations 1
R How to obtain OBL licence under Indian MDR, 2017 Other Medical Device Related Standards 2
F MDR – Article 120 – Transitional provisions EU Medical Device Regulations 8
H MDR Article 13(c) EU Medical Device Regulations 6
Ed Panek Auditor MDR (Presub audit) finding EU Medical Device Regulations 2
M Classification of Instruments under EU MDR EU Medical Device Regulations 1
M Procedure for vigilance system according to new MDR EU Medical Device Regulations 0
M Procedure for clinical evaluation according to new MDR EU Medical Device Regulations 11
R MEDDEV 2.12-1 rev 8 (Vigilance guidelines) still applicable with the MDR implementation? EU Medical Device Regulations 1
S Determining a device category according to the MDR EU Medical Device Regulations 3
A Transactions under MDR Medical Device and FDA Regulations and Standards News 3
H Has anyone undergone MDR FQA review yet? EU Medical Device Regulations 10
S UK MDR + EU MDR Declaration of Conformity UK Medical Device Regulations 2

Similar threads

Top Bottom