SBS - The Best Value in QMS software

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
L REACH compliance with MDR EU Medical Device Regulations 1
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 1
F MDR – Article 120 – Transitional provisions EU Medical Device Regulations 2
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 1
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 0
D Does Risk Management apply to re-labeler (MDR) EU Medical Device Regulations 1
H MDD VS MDR 2002-218 UK Medical Device Regulations 6
Ed Panek MDR Liability Insurance EU Medical Device Regulations 1
S MDD to MDR - Tallow Derivatives Impact EU Medical Device Regulations 1
P Update on NBOG 2014-3 to address MDR/IVDR, or any plan to do that? EU Medical Device Regulations 0
A MDR requirement where unit of use packaging is too small for UDI carrier EU Medical Device Regulations 1
S MDR GSPR Standards EU Medical Device Regulations 1
A MDR - Legacy Device Review Timeframe and Requirements EU Medical Device Regulations 3
J Translation requirements for the statement referred to in ANNEX XIII of MDR EU Medical Device Regulations 0
J EU MDR GSPR 10.4.3 and 10.4.4 EU Medical Device Regulations 2
F Labelling to comply with both FDA and MDR US Food and Drug Administration (FDA) 6
N EU MDR and its impact on existing Registrations EU Medical Device Regulations 1
M Post Market Safety Update Report for devices that will be up-classified under MDR but are currently under MDD EU Medical Device Regulations 3
Y MDR Transition - make "Available on the market" after CE certificate expiration EU Medical Device Regulations 3
C MDR Classification Rule 10 EU Medical Device Regulations 13
Y MDR requirements for Class I accessories EU Medical Device Regulations 2
M MDR legal actions - manufacturers CE Marking (Conformité Européene) / CB Scheme 8
R Products not within the MDR grace period EU Medical Device Regulations 1
shimonv MDR transition checklist EU Medical Device Regulations 0
K Re-packaging under MDR EU Medical Device Regulations 3
Ed Panek Upcoming NB MDD ---> MDR Crunch EU Medical Device Regulations 0
S MDR - System and procedure pack article 22 and all sub processes that apply ISO 13485:2016 - Medical Device Quality Management Systems 0
C Requirements for distributors under MDR: translation EU Medical Device Regulations 0
A Should we assign the PRRC before the date of application of MDR (26 May 2021)? EU Medical Device Regulations 0
N Looking for a recommendation for an EU MDR Importer EU Medical Device Regulations 1
JoCam Rental and MDD versus MDR EU Medical Device Regulations 1
A Can anyone share a Distribution Agreement template under MDR 2017/745? EU Medical Device Regulations 0

Similar threads

Top Bottom