Software as control or protection will lead to different Software Safety Class?

[VinceTech]

Hi,

There are two design:
1. A control system is hardware and its protection system is software. Without software protection system, the control hardware failure will lead to serious harm.
2. A control system is software and its protection system is hardware. Without hardware protection system, the control software failure will lead to serious harm.

Would the software be classified to the same Safety Class B according to IEC 62304?

Thanks,

Best regards,

 

[Peter Selvey]

Depends on whether amendment 1 is included. The original publication in 2006 specifically refers to a hardware risk control, but the amendment in 2015 changed to "additional RISK CONTROL measures external to the SOFTWARE SYSTEM".

Although we often refer to independent control and protection, what the real target is two identifiable, independent means of protection similar to electrical safety. It does not matter what form they take (hardware, software, mechanical etc). The control system can be one of the means of protection.

 

[VinceTech]

Hi Peter

In IEC 62304:2014 Figure 3, there is a note: "A SOFTWARE SYSTEM which implements RISK CONTROL measure may fail, and this may contribute to a HAZARDOUS SITUATION. The resulting HARM may include the HARM which the RISK CONTROL measure is designed to prevent (see 7.2.2b)"

To the design 1 (Hardware Control + Software Protection), for assigning a class to the SOFTWARE based on Figure 3, is it reasonable to consider the Hardware Control is the RISK CONTROL measures external to the software? In this case, I treat Hardware Control is one means of protection while Software Protection as another means of protection fails with probability =1.

Thanks,

 

[Peter Selvey]

To be clear, the classification method in 62304 is flawed because it tries to take a simplistic approach to a complex situation.

Most regulations have three or four "Classes" for devices: low, medium high; A, B, C; I, IIa, IIb, III etc. To determine these classes there are two options: #1 (USA, Japan, Canada, China?) - make lists with the classification pre-determined by people with experience; or #2 try to make some rule based approach (EU, and those that copied the EU), and, somewhat conspicuously, IEC 62304.

The EU's rule based approach deserves a lot of respect, they have done a pretty good job but it requires many rules with over 2000 words of text in the regulation, plus a 51 page MEDDEV guidance to help explain the nuances. In other words - not as simple as A, B, C. Brexiters might complain but I think their kudos is well deserved. Complexity does not mean "too hard" or "impossible", it just means a little more detail is required.

IEC 62304 tries to make 3 classes in roughly 200 words. Sorry, but that's an abject failure of the standards committee to appreciate the complexity of the situation. It is possible to classify software, but my guess is at least 1000 words of text would be needed to handle all the different situations, plus 2000-3000 words in guidance to flesh out the nuances.

Anyway ... the point is that you need to apply some common sense in determining the classification. Don't read the literal words in the standard.

 

[VinceTech]

Hi Peter,

We do feel the process of defining Software Class is a bit odd. Our engineers may not read the literal words but using common sense. The concern is if Regulatory bodies will read literal words in the standard.

I have another question regarding the process defined in IEC 62304:2015 Figure 3. The second step in the process is 'Evaluate effectiveness of RISK CONTROL measures external to the software.' Could you please comments if the 'effectiveness includes the consideration in the probability of RISK CONTROL measure failure occurrence?

Thanks,

Best regards,

 

[Peter Selvey]

Yes, probability of failure of the risk control is a factor. But you need to consider the whole sequence, including failure of the software and even factors external to the device (some devices, the probability of harm from device failure is high, other cases the doctor or user would normally notice and intervene, or some other reason why device failure doesn't always lead to high severity harm).

There are times when even two means of protection are not enough. In those cases, the solution usually involves some adding some periodic checks for the protection system, such as an automated start up test or inter-comparison of the data from sensors used for control and protection. It's rare to see three means of protection in a medical device.

 

[VinceTech]

Hi Peter,

As process in Fig 3 assumes Software Failure is 1. This will normally lead to a high reliable protection external to the software (such as high reliable independent hardware protection). However, as most hardware protection with more than 10 components will have a level of 1/1000 failure/year based on Military handbook. This is not sufficient for the serious harm if the hazardous situation is not obvious to the operator or patient. Also, most the self initial check is done by software. This means the selfcheck will not be effective in the software classification process.

Could you please advise.

Thanks,

 

[Peter Selvey]

The assumption of 100% failure is just for classification, not risk evaluation. It just determines the parts of the standard that apply (A, B, C requirements).

Once you get into the actual risk analysis there is no normative requirement to assume 100% failure for software. There may be some poorly worded guidance floating around but usually the context is in determining if a risk control is required, it simply cannot work to continue to assume 100% failure rate in the the final residual risk evaluation.

I understand the original thinking behind the "100% failure of software" logic but I don't agree because it is too easy to misconstrue.

 

[VinceTech]

Hi Peter,

Process in Fig 3 does confuse me. The 3rd step is "Does failure of the software result in unacceptable RISK." This step sounds I will need to conduct the proper risk analysis under assumption of Software Failure 100% and hardware protection failure 1/1000/year. This leads to total 1/1000 failure in total. for a serious harm, the risk is unacceptable. This means all medical device with 2 means protection will be ended up with Software Class C if the harm is serious.

Thanks,

Best regards,

 

[Peter Selvey]

Hmm, I never looked at it that closely. There seems to be a more fundamental mistake than I had thought. Weird that it has not been challenged.

You would expect that a high risk medical device (e.g. infusion pump, dialysis, incubator etc) would start out as Class C, and then drop to B once an external risk control is applied. Class B is still important to keep the overall probability low. Class A controls are too weak.

However, the flow chart indicates that for a high risk device, the only possibility is either Class A or Class C. No middle ground solution. And, as you point out the external risk control would have to have a failure rate of ~0.000001/year in order to justify A, otherwise, the software has to stay at Class C.

Wrong. Wrong. Wrong.

Marcelo, any insight?