EN 62304 Safety Class of an ECG device designed to be used in clinical situations when patient is in immediate danger.

[paf94]

Hello everyone,

My team and I do not agree on the software safety class of the software embedded in a ECG device designed to be used in clinical situations when patient is in immediate danger.

As EN62304 software safety class is driven by risk analysis, the main question we don't agree on is : What is the criticity of the risk "ECG signal quality is degraded" ?

For now, we have considered that the criticity is maximal (Death of patient) as a misdiagnosis in an emergency situation could lead to the patient death but it is not straightforward so it might be too conservative.

What do you think ?

Thank you,
Best Regards,
Paul-Alexandre,

 

[shimonv]

Hi Paul,
Software malfunction in a critical care setting may result in serious injury or death.
Better to adopt the conservative approach.

Also, software safety classification "B" is such where software malfunction will not result in a serious injury. You need to be able to justify that.

Shimon

 

[yodon]

Our philosophy is that when in doubt, take the conservative approach (higher safety class). If you take the approach for the lower class and your regulatory body reviewer disagrees, it's going go cost you a lot of time and money to retrofit things. To me, the tasks in Class C, for the most part, are really just good software engineering practices and, if done right, should facilitate ongoing maintenance.

 

[Ed Panek]

If there is doubt go more conservative. It already indicates you are having trouble justifying it to yourself; arguing with an auditor will be harder.

 

[Tidge]

Our philosophy is that when in doubt, take the conservative approach (higher safety class). If you take the approach for the lower class and your regulatory body reviewer disagrees, it's going go cost you a lot of time and money to retrofit things. To me, the tasks in Class C, for the most part, are really just good software engineering practices and, if done right, should facilitate ongoing maintenance.

A million times this.

The actual increase in burden (both in terms of documentation and in development) going from class B to class C is negligible for competent software engineers.(*1)

If there is doubt go more conservative. It already indicates you are having trouble justifying it to yourself; arguing with an auditor will be harder.

Unrecognized by many development teams: treating any medical device software system as anything other than class C adds a burden of doing/documenting/maintaining the assessment of the alternative software system safety classification.

(*1) I often feel that arguing over "class B or class C" is like arguing over whether or not to add additional postage to a somewhat heavier piece of first class mail that needs to be delivered, when based on a person, uncalibrated sense of final weight... with no means of knowing what the postal system might believe the weight to be. Is it worth risking the letter won't be delivered because you simply don't want to put an extra stamp on the envelope that you happen to have on hand anyway?