Safety Classification in Medical Device Standalone Software

[theinonen]

Hi,

I feel a little inconvenient when thinking the safety classification. According to IEC 62304 the safety classification may be reduced (C->B, B->A) only by a hardware risk control measure.

In case of really huge standalone software systems (where medical device is the software) there really are no way or point to isolate hazardous software units. For example if the software uses database, every function can be used to manipulate database. "You can code what ever you want where ever you want". The whole software is hazardous because of chance of programming errors.

Using ISO 14971 becomes inconsequential because there is no way to reduce the safety classification. It's good to perform risk analysis but impossible to do risk control. Doing risk control to software by software only increase the amount of software. So there is a point in 62304 that safety classification may be reduced only by a hardware risk control measure. Of course it's important to keep in mind the possible hazards relating to software system..

Safety classification is anyway one of the most important aspects of 62304 and hence affects software development process. Also 5.5.4 specify lots of documentation for each software unit.

Does anyone have some experience concerning standalone software and safety classification?

[Marcelo Antunes]

Hum, i really didn´t understand some of your points.

According to IEC 62304 the safety classification may be reduced (C->B, B->A) only by a hardware risk control measu

Where is it?

Using ISO 14971 becomes inconsequential because there is no way to reduce the safety classification

The safety classification is not related directly to risk management. it´s related to the amoount of control youhave to perform (requirements of the standard) during your development lifecycle.

So there is a point in 62304 that safety classification may be reduced only by a hardware risk control measure.

Again, where?

For example if the software uses database, every function can be used to manipulate database. "You can code what ever you want where ever you want". The whole software is hazardous because of chance of programming errors.

Only if every function can lead to injury, you would need to perform an evaluation to ensure that. Anyway, as i said above, this would only determine the amount of control yoou would need to exert.

[theinonen]

In Reply to Parent Post by mmantunes

The safety classification is not related directly to risk management. it´s related to the amoount of control youhave to perform (requirements of the standard) during your development lifecycle.

That is true. And in case of really huge software it needs a lot of documentation.

In Reply to Parent Post by mmantunes

Again, where?

It can be found from 4.3 software safety classification. "-- from a software failure is subsequently reduced to an acceptable level (as defined by ISO 14971) by a hardware risk control measure -- software safety classification may be reduced from C to B --". As I understand it there is no other way to reduce classification for software unit.

In Reply to Parent Post by mmantunes

Only if every function can lead to injury, you would need to perform an evaluation to ensure that. Anyway, as i said above, this would only determine the amount of control yoou would need to exert.

That was my point. I mean can you really isolate some functions and be sure that there are no errors in code? What is acceptable rationale for some function to be A class if there is a possibility that someone code there some error that leads to injury even if there shouldn't be nothing leading to injury according to specification. It is in the end all about testing that everything is as specified. But if it's so then there is no possibility that any function can lead to injury. Because everything is tested and it works.

The problem is that software still can lead to injury or death if there is done some coding error somewhere. And that is why the software should be class C. And in standalone software there is no possibility to do hardware risk control.

But I'm not sure about my rationale if it is correct. I think the standard is intended for embedded systems that contains both hardware and software, not for information systems.

[Marcelo Antunes]

It can be found from 4.3 software safety classification. "-- from a software failure is subsequently reduced to an acceptable level (as defined by ISO 14971) by a hardware risk control measure -- software safety classification may be reduced from C to B --". As I understand it there is no other way to reduce classification for software unit.

I think you might have missed the beginning of the phrase:

If the RISK of death or SERIOUS INJURY arising from a software failure is subsequently reduced to an acceptable level (as defined by ISO 14971) by a hardware RISK CONTROL measure, either...

So no, hardware is not the only option of risk reduction.

This is also clear from the note one 7.2.1 - NOTE The RISK CONTROL measures can be implemented in hardware, software, the working environment or user instruction.

The problem is that software still can lead to injury or death if there is done some coding error somewhere. And that is why the software should be class C. And in standalone software there is no possibility to do hardware risk control.

That´s why you have to control the development lifecycle, tests should ensure that coding error are corrected before release.

But I'm not sure about my rationale if it is correct. I think the standard is intended for embedded systems that contains both hardware and software, not for information systems.

No, the standard is intented both to embedded software and stand alone as it´s a development lifecycle standard. In fact, the standard is nothgin more than general knowledge from the software engineering field which in general applies to all software, plus some concerns of the medical device industry.

Anyway, safety requirements for stand alone software are not taken into consideration (in the case of medical electrical equipment, safety requirements can be found in IEC 60601-1). In the case of standa-alone medical device software, a new standards is being developed (IEC 82304-1 Ed. 1.0 - Healthcare Software Systems - Part 1: General requirements) which will address safety requirements.

[Peter Selvey]

I believe the issues raised by "theinonen" is valid mistake in the standard that will likely be fixed in the future.

The standard explicitly refers only to a "hardware risk control" when determining classification, whereas in practice protection systems are often a combination of hardware and software, and could also be purely software. Provided such a protection system is reasonably isolated from the control system (including in the case of software, separation of data and algorithms), a reduction in software classification is justified.

For example, a dialysis system temperature control will normally be handled by one system containing hardware and software, while the protection relies on an independent system with separate hardware and software. One would reasonably expect that having implemented a fully independent system, the software for both control and protection can be reduced to Class B, rather than Class C.

However, according to IEC 62304 this is not allowed as the protection system also contains software.

[kasrt]

I was searching this forum for some guidance on tracing from software item to it's cause when i chanced upon this topic. Interesting was a reply from mmantunes wherein he mentioned that "The safety classification is not related directly to risk management. it´s related to the amoount of control youhave to perform (requirements of the standard) during your development lifecycle."

Isn't the safety classification for the software item (identified as hazardous), the result of the 'Severity' rating explained in ISO 14971? I would think they are directly related? For e.g. Severity as 'Catastrophical' or 'Critical' would probably be rated as class C...

My second query however which i also choose to post it in this topic is, can someone point me to an implementation solution wherein they have traced successfully from software item to cause. Or is there a way wherein we can trace from software item to risk control measure, bypassing the cause?

[Peter Selvey]

The point that mmantunes is saying is that ISO 14971 risk management is about deciding whether risk control measures are necessary, whereas classification in IEC 62304 simply decides whether additional design controls (procedures, records) are necessary. The key difference is that ISO 14971 risk controls apply to the medical device, while IEC 62304 design controls apply to the manufacturer.

Of course they are related but then everything about a medical device is somehow related to risk.

Tracing from software item to cause: I believe the point of view of the standard is to assume that a particular software item (module) has a software bug and then see what the impact is. In other words, a 100% assumption that the software module fails.

If this has a significant outcome, then you have two basic options: one is to put more effort into design specifications, unit breakdown, unit testing, integration and system testing (reduce the chance of a software bug); the other option would be to add a separate protection system which may be software, hardware, mechanical or even simply reducing the source of risk (inherent protection). Very much a case by case situation.

[kasrt]

Thanks Peter!

But im still unclear regarding my query, whether a software item (identified as hazardous) needs to trace to its cause. 62304 section 7.3.3 asks specifically to trace from software item to the specific software cause.

From what i understand from your reply, tracing from software item to risk control measure and to the implementation of the risk control measure is sufficient. Is that what you meant? Will this tracing help me to explain to my external auditor for 62304, clause 7.3.3?