Class IIB Device - IEC 62304 Software Classification

[BargeSim]

Hi all,

I have a class IIb medical device (a CBCT scanner for extremities) for only diagnostic purpose; is there a required software classification.

The software manages images acquisition, 3D Reconstruction and visualization on the viewer; no further decision is taken automatically.
I suppose I can assume class B, due to the risk mitigation measures (other than the software).


But my question would be:

is there any guideline defining the difference between serious injury and not serious injury? I only found some docs produced by specific Department of Health, but not an international standard definition.

Thanks

 

[yodon]

In ISO 14973, they provide an example of severity levels for harm:

• Catastrophic - death
• Critical - permanent impairment or life-threatening injury
• Serious - injury or impairment requiring professional medical intervention
• Minor - temporary injury or impairment not requiring professional medical intervention
• Negligible - inconvenience or temporary discomfort

To me, anything, well, serious or above would be a good place to draw the line. Of course, this is just an example and you could have different levels but this seems to be a pretty common way to organize.

 

[Ronen E]

Hi all,

I have a class IIb medical device (a CBCT scanner for extremities) for only diagnostic purpose; is there a required software classification.

The software manages images acquisition, 3D Reconstruction and visualization on the viewer; no further decision is taken automatically.
I suppose I can assume class B, due to the risk mitigation measures (other than the software).


But my question would be:

is there any guideline defining the difference between serious injury and not serious injury? I only found some docs produced by specific Department of Health, but not an international standard definition.

Thanks

Can you please quote the classification rule that resulted in the class IIb classification decision? It might help answer your question.

 

[Kuldeep Singh]

Hi,

I have a question for classification of software, If we control all the risks through hardware control which arises from software ,then is it possible that , we can assume our software as class A rather than Class B?

 

[BargeSim]

Thank you all for your replies.

Further information: Classification based on rule 9: delivery of (hazardous) energy

 

[dgrainger]

To me CBCT = cone beam computed tomography, and will be class 2b by Rule 10. "Active devices intended to emit ionizing radiation and intended for diagnostic and therapeutic interventional radiology". Rule 9 applies to therapeutic devices.
As it is emitting ionising radiation there will always be a risk of serious injury. Class C?

 

[BargeSim]

Thank you all for your replies.

Further information: Classification based on rule 9: delivery of (hazardous) energy

To me CBCT = cone beam computed tomography, and will be class 2b by Rule 10. "Active devices intended to emit ionizing radiation and intended for diagnostic and therapeutic interventional radiology". Rule 9 applies to therapeutic devices.
As it is emitting ionising radiation there will always be a risk of serious injury. Class C?

Yes sorry, surely the Rule is 10.
I honestly had been thinking about class C, but my question is if it can be reduced to Class B, reducing risk, using measures other than the SW.

 

[Kuldeep Singh]

You can reduce the software classification by reducing the risk by hardware risk control measures. Here below the guidance given in IEC 62304 for sw classification.

 

[Franz]

Hi All, take care for a proper architectual design including a solid planning of the hardware measure which shall mitigate your risk.
Be aware, that you have to follow the IEC/EN 60601-1 and your hardware component will be automatically a critical component. Think about, how you can detect single fault failure events and how additional fault conditions can be detected. All safety relevant and critical component shall have a proper test report which includes evidences of related production process controls of incoming inspection, in process controls and end controls.
If you want to distribute the device internationally, a certification mark (like CSA [e.g., cCSAus], UL, NEMKO, DEKRA etc.) would ease the market access and also speed up the registration in e.g. Brazil. Even US customers may benefit: If there is a certification mark, hospitals can save insurance fees as they pay less. For negotiations with the hospital purchase that can be crucial.

 

[Tidge]

Hi,

I have a question for classification of software, If we control all the risks through hardware control which arises from software ,then is it possible that , we can assume our software as class A rather than Class B?

I would never recommend trying to change the classification of software (within a medical device) based on an analysis of the effectiveness of hardware risk controls. In my experience, the only clean way to have a 'lower' software safety classification (than otherwise would be naively assumed, based on the classification of the medical device) is to have a (product) system architecture that makes it clear that the software has not been allocated any functions that could contribute to the most serious harms.

In simpler terms: If you want a 'lower' classification, the design ought to be such that the software is neither a contributing factor nor a control of the risks associated with (non) serious injury.