Update on IEC 62304 revision - May 2012 - 2013 (TBD)

The exact wording in the current standard is:

Quote:
Class C: Death or SERIOUS INJURY is possible
Under plain English interpretation, the words "is possible" effectively sets P2 as 100% irrespective of the actual probability.

Click to expand...

You are correct (- the original software safety classification was based only on severity, and this is part of the problem and misunderstanding that exists in the first edition of the standard (and when I say misunderstanding, I'm not saying misunderstanding only on the parts of the users, but also of the WG that created the standard).




I think part of the problem with the discussion resides in one topic you mentioned: P1, the critical failure of software.

The failure of software is not P1 (well, it might be if you want, but then everything you said is correct and we still have a problem).

The rationale behind the standard (and this was what was done wrong in the first edition, together with focusing on severity and not on risk)) is that the failure of software is the first of a sequence of events leading to a hazardous situation.

So,

1 - the software fails (Px)
2- something happens (Py)
3 - somethings happens (Pz)
4- a hazardous situations occurs, which has two components
5 - severity of harm
6 - probability of occurrence of harm, which has two components,
7 - probability of hazardous situation occurring (P1) which is equal to Px.Py.Pz or whatever way you want it
8 - probability of hazardous situation turning into harm (P2)

In the case of software failure, what the standards says is that Px is 1. It does not say that P1 is 1. Depending on Py Pz and any other, P1 surely can be different from 1.

Also, the standard should be focused in risk instead of only severity. This is the other part of the problem of the first edition.

Actually, if you study the subject carefully, the committee cannot avoid specifying specific risk limits for each software Class, or in effect specific probabilities for each type of severity. These are things which of course the committee wants to avoid, nobody wants to be writing probabilities into the standard.

Having varying controls based on risk is nothing new, but it is an extremely complicated subject. Consider in Europe, the classification scheme is based on 6 pages of rules (and a 52 page MEDDEV guide). Although the underlying concept is risk based, to make it consistent, those rules largely avoid references to risk, rather they look at the features of the device. So if the committee wants certainty without specifying specific risk levels, they would need to go in the same direction, i.e. feature based rules e.g. does the software control flow/energy where failure can lead to serious direct harm ... Class C; does the software monitor the patient where immediate action is required ... Class C; does the software provide complex user interface (more than 2 settings) ... Class B; etc etc .

Another option would be to open it up to manufacturer's risk management, for example:

The manufacturer shall select the level of controls (Class A, B or C) which ensures the risk is acceptable. .

That is way open to interpretation, but at least takes the committee out of the decision process. The standard would then need to give some overview of the different controls to allow the manufacturer to select the appropriate level e.g. Class A - black box, no refinement, no software verification; Class B - refinement, verification; Class C - refinement, verification and detailed design.

In fact my opinion at the moment is that we are making a lot of fuss in the classification scheme for almost nothing - the difference between the requirements from class B and C in the current draft is small (only 5 or 6 requirements if you simply count them - surely even those can demand a deal of work, however, they are very small in numbers).

My probable suggestion on the next comments on the next draft is to simplify things even more and have maybe only two classification, A or B - A when software clearly cannot lead to problems, and B when the software can, or the manufacturer is really not sure

For existing publication, the difference between Class B and C is small in clause count, but huge in effect. Class C requires detailed design, which means writing algorithms for each software unit. Also the verification criteria is much more detailed.

Does the new draft eliminate this? I think it's important stuff but a big amount of work and should be limited to Class C

For existing publication, the difference between Class B and C is small in clause count, but huge in effect. Class C requires detailed design, which means writing algorithms for each software unit. Also the verification criteria is much more detailed.

Does the new draft eliminate this? I think it's important stuff but a big amount of work and should be limited to Class C

Click to expand...

No, this didn't change, however, with all this discussion and general misunderstanding on the classification, I'm thinking that it might be better if we streamline some class C requirements and create a mix of class B/C which is a balance between requirements as of now and the need for a less complex classification.

An alternative approach would be to eliminate Class C through a protection system design. Like the SFC in hardware, you assume the software will fail and put in some independent system (which could also be software) that checks the output is within safe ranges.

Hello all,

I read with A Lot Of interest your lastest posts about safety class, risks and probability of sw failure vs probability of hazard.
I didn't want to add some more fuss to the discusion, so I kept silent.

However, the idea/proposition of reducing the number of safety levels to two levels is IMHO not a good option. I imagine that it would be a bit like
-class alpha = former class A, almost nothing to do (only requirements analysis + tests and risks assesment at device level)
-class beta = former class C, the full monty down to detailed design of sw units.
This is to big a step between these two (theoretical) levels. The consequence is to make every sw either a black box or a white box with deep detailed design that is relevant only for really mission-critical systems.
To make a comparison, airborne industry uses 5 levels (the two highest matching massive catastrophic situations).
Moreover, fda has 3 level of concerns that match very well safety classes of 62304.

I hope you understand my arguments and won't promote this dual classification.

Remark: the flow chart about safety classes is definitely a good idea.

Mitch.

IEC SC 62A meeting is just finished in Shanghai, anyone was there? Can anyone update us on any new development on IEC 62304 and also ISO 62366-1 and -2.

Many thx.

I am still struggling with the whole concept of this standard, more precisely with the fact that the determination of the safety classification should occur at the beginning of the development, whereas my experience is (could be only mine) that it will be accurate only at the end of the R&D, a wee before commercialization (if any).

I would appreciate if any fellow covers could share her/his view on this, particularly interested real world experience because I tend to believe there is a reasonable gap between the recollection of the regulators have and the understanding and experience the practitioners have.

Many thanks
Cheers!

However, the idea/proposition of reducing the number of safety levels to two levels is IMHO not a good option. I imagine that it would be a bit like
-class alpha = former class A, almost nothing to do (only requirements analysis + tests and risks assesment at device level)
-class beta = former class C, the full monty down to detailed design of sw units.

This is to big a step between these two (theoretical) levels. The consequence is to make every sw either a black box or a white box with deep detailed design that is relevant only for really mission-critical systems.
To make a comparison, airborne industry uses 5 levels (the two highest matching massive catastrophic situations).
Moreover, fda has 3 level of concerns that match very well safety classes of 62304.

I hope you understand my arguments and won't promote this dual classification.

Click to expand...

Just to make things clear, It?s my personal opinion that maybe we should go to two classes instead of 3, not an opinion of anyone else - and I?m even sure I will suggest that, but it?s something that I?ve been thinking at the moment because the sfety classification causes too much confusion.

I was in fact thinking about having a second class with a mix of Classes B and C, but more like B than C.

regarding the FDA level of concern or the airborne industry, they are not really the same as what IECV 62304 defines as the safety classification (in fact it?s also part of the confusion ).



I think the main problem regarding this that no ones seems to talk about is:

If you think about good practices for software design and development, it might be argued that all activities required by IEC 62304 might be required for general any software, but the effort in each activity should be based on a general idea of the problems the software might cause - this is something that the manufacturer should do better than any standard.

Also, an important concept is that, for good practices, you are usually required to do a lot of stuff - for regulatory purposes, if are usually required to show a summary of what you do during any given regulatory submission.

The problem in practice is that manufacturers, a lot of times, do not really know software design and development as this level, and then we have to create a standard to "guide" them. And then the standard has to create some level of guidance on the effort needed, and in the case of IEC 62304, it created the software safety classification. And then we really mix what is expected to be performed and what is expected to be showed to the regulator. And then people sees the safety classification of Class C as too much work and keep trying to avoid it. And then IEC 62304 becames "mandatory" in some way and the confusion only keeps growing...

So, it?s really impossible to have a standard like with requirements that everyone agrees.

That?s why I was thinking that a change in the approach of the standard in the level of effort might need a change.

Right now this approach is based on the classification, but this is the most misunderstand part of the standard - and it?s the first thing you need to do! No surprise a lot of people do not understand of fear the document - if I don?t even understand the initial step, what to say of the rest.

A solution might be to simplify this classification, but this always comes at the expense of another area - having two levels instead of 3 clearly simplificate things, but at the expense of maybe requiring more than having 3 levels.

Another better solution would be to let the manufacturer decide on the level of effort.

We?ve suggested this to the ISo 13485 requirement on software validation:

The organization shall establish, implement, and maintain documented procedures for the validation of the application of computer software used in the quality management system, including production and service provision. Such software applications shall be validated for their intended use prior to initial use, and after any changes to such software and/or its application. Record of such activities shall be maintained.

For each application of computer software used in the quality management system, the organization shall determine and justify the specific approach and the level of effort to be applied for software validation activities based on risk management.

Click to expand...

Something like this would be the what is really required in IEC 62304, but then we come to the problem that

1 - a lot of manufacturers really do not have the expertise to make such decisions

2 - regulatory authorities won?t like to give so much freedom to the manufacturers

And then we goback again to some "closed" classification system...and confusion