I understand the point of view of the standard: assume software is unreliable and then decide on the level of design controls based the severity of the outcome.
Again to use the dialysis system example: they will normal use two independent systems for control and protection, each having both hardware and software components. The work required for Class C is quite large, in particular Clause 5.4.4 probably triples the amount of work per software unit. So this is not a simple case of just a few more pages of documentation, we may be talking about 1000's of pages for a dialysis system.
The fact that two independent systems are used should allow the manufacturer to drop the classification down to Class B for each system (protection and control). Class B is still a lot of work.
Again to use the dialysis system example: they will normal use two independent systems for control and protection, each having both hardware and software components. The work required for Class C is quite large, in particular Clause 5.4.4 probably triples the amount of work per software unit. So this is not a simple case of just a few more pages of documentation, we may be talking about 1000's of pages for a dialysis system.
The fact that two independent systems are used should allow the manufacturer to drop the classification down to Class B for each system (protection and control). Class B is still a lot of work.
Last edited:
K
kasrt
Thanks Peter and mmantunes for the detailed reply!
Was there a tool you used for tracing from software item to cause to risk control?
For implementing clause 7.3.3, one would need to define a hazard id to represent the hazard/harm, a software item id to represent the software item, a cause id to represent the specific software cause, a risk control measure id for representing the measures (mitigation) taken and also a requirement id, since most probably it will be mapped to a requirement within software as well.
software item and it's cause are additional requirements for tracing when compared to 14971.Again a hazard (related to software) can have multiple causes, which in turn can have 1 or multiple mitigations.
Is there a structure you came up with to handle the above?
Was there a tool you used for tracing from software item to cause to risk control?
For implementing clause 7.3.3, one would need to define a hazard id to represent the hazard/harm, a software item id to represent the software item, a cause id to represent the specific software cause, a risk control measure id for representing the measures (mitigation) taken and also a requirement id, since most probably it will be mapped to a requirement within software as well.
software item and it's cause are additional requirements for tracing when compared to 14971.Again a hazard (related to software) can have multiple causes, which in turn can have 1 or multiple mitigations.
Is there a structure you came up with to handle the above?
A
andreasm
Hi,
I have a related question concerning the safety classification for medical software. The company I am currently performing my master thesis at is developing a software for a prosthetic device. The software will be present inside a PC as well as the prosthetic and the two will occasionally share data through a plug connection to update data in the prosthetic.
Is it still possible to claim that the software items present in them are segregated enough to give them separate classification?
Secondly, the potential harm presented to the patient by the software is ultimately mitigated by user instructions. Is that a valid "risk control" to use for down grading the classification from a grade B to a grade A?
The only harm caused to the patient would be that the prosthetic would invoke an action contrary to the patients intent. (clutching of hand instead of opening etc)
Thirdly, is there a "default" safety classification for medical databases? I have not been able to find any references to such but figured that here would be the place to ask.
Thank you for your help
Regards,
Andreas
I have a related question concerning the safety classification for medical software. The company I am currently performing my master thesis at is developing a software for a prosthetic device. The software will be present inside a PC as well as the prosthetic and the two will occasionally share data through a plug connection to update data in the prosthetic.
Is it still possible to claim that the software items present in them are segregated enough to give them separate classification?
Secondly, the potential harm presented to the patient by the software is ultimately mitigated by user instructions. Is that a valid "risk control" to use for down grading the classification from a grade B to a grade A?
The only harm caused to the patient would be that the prosthetic would invoke an action contrary to the patients intent. (clutching of hand instead of opening etc)
Thirdly, is there a "default" safety classification for medical databases? I have not been able to find any references to such but figured that here would be the place to ask.
Thank you for your help
Regards,
Andreas
glork98
Involved In Discussions
I'll take a shot at two.
That's not the way it works. The software is classified by the largest risk prior to mitigation. This imposes the quality practices. If the risk analysis says that the software component can never, ever cause physical injury or treatment failure no matter how egregious its failure prior to mitigation, then you're Class A. If you don't have everything mitigated down to a low ranking you can't ship the product.
Yes. And the physical separation makes this easier to identify. You do have to consider the effects of what the PC can do through operator misuse and technical failures. As examples, can the user select incompatible options or select harmful configuration values?
That's not the way it works. The software is classified by the largest risk prior to mitigation. This imposes the quality practices. If the risk analysis says that the software component can never, ever cause physical injury or treatment failure no matter how egregious its failure prior to mitigation, then you're Class A. If you don't have everything mitigated down to a low ranking you can't ship the product.
A
andreasm
Thanks for the reply glork. That reassured me concerning the segregation 
Concerning the second question, in accordance with clause 4.3a)
Concerning the second question, in accordance with clause 4.3a)
it would be possible to reduce the initial software classification from B to A, or C to B, as long as sufficient level of risk control and mitigation has been implemented.
And then, in clause 7.2.1 it says
And then, in clause 7.2.1 it says
which makes me wonder if implementing user instructions as mitigating factor against a possible risk would count towards software classification reduction, or can that only be done through hardware?
Thank you
Thank you
C
coezbek
I would like to append another aspect of the security classification into the discussion:
How immediate does the software have to cause the danger?
glork98 argues that if "the software component can never, ever cause physical injury or treatment failure" it is A. But how much influence do we assign to the human user which acts upon information from a system?
Consider an thermometer which uses a LCD display to show the temperature. If a software failure leads to an invalid temperature, then a user/doctor might apply the wrong treatment, leading to the death of the patient.
Now the software in the thermometer can never ever kill/harm anybody (unlike a pacemaker, MRI, CT, or similar), but still 62304 seems to make it necessary to categorize the software as class C.
How immediate does the software have to cause the danger?
glork98 argues that if "the software component can never, ever cause physical injury or treatment failure" it is A. But how much influence do we assign to the human user which acts upon information from a system?
Consider an thermometer which uses a LCD display to show the temperature. If a software failure leads to an invalid temperature, then a user/doctor might apply the wrong treatment, leading to the death of the patient.
Now the software in the thermometer can never ever kill/harm anybody (unlike a pacemaker, MRI, CT, or similar), but still 62304 seems to make it necessary to categorize the software as class C.
P
PaulGr
Hi Andreasm, as mentioned before in this thread, the standard is clear: only hardware. And personally, for this clause I would not be able to write a rationale to support a deviation.
In general, if your software has the potential to cause injury to patients or users, it is wiser to focus on 'smart' implementation of class B or C requirements than on reducing the safety class.
And for your 3th question:
In my opinion a default classification would not be possible. Every database is used for a specific intended use and different possible effects on patients and users. Classifications range from no medical device to class C.
@coezbek: in your thermometer example the result of the software is evaluated by a user which has more inputs (skin color, sweating,...) which reduces the possibility on injury and possibly the safety class.
C
coezbek
Now, this is where it gets interesting. In the risk management view of 14971 a reduction in possibility will lead to a reduction in risk. But in 62304 you are not allowed to do that, because you have to assume 100% occurrence. In a strict view on 62304, the thermometer seems to be a class C product. (and I'd love if anybody disagrees ;-)
P
PaulGr
Ok, I start to understand your point. Now let me try to disagree
First ISO14971. Assume a sequence of events where the thermometer software gives a wrong reading, the nurse writes a wrong value in the medical file and after a lot of other events the patient dies. Severity is critical, probability of the software failure is assumed 100% but overall probability is (in this example) improbable.
Now IEC62304. Guidance B4.3 indicates that safety classification and ISO14971 risks are not aligned (as explained earlier in this thread). So we need to interpret the word 'possible' from the classification rules in 4.3(a). My interpretation is that death or serious injury is not possible based on the ISO14971 analysis above. Assuming that a sequence of events is possible which results in minor injury, the software would classify as B.
I think the point is that not every remote or improbable sequence of events - with a software item involved - which leads to serious injury or death automatically classifies the software item as C.
First ISO14971. Assume a sequence of events where the thermometer software gives a wrong reading, the nurse writes a wrong value in the medical file and after a lot of other events the patient dies. Severity is critical, probability of the software failure is assumed 100% but overall probability is (in this example) improbable.
Now IEC62304. Guidance B4.3 indicates that safety classification and ISO14971 risks are not aligned (as explained earlier in this thread). So we need to interpret the word 'possible' from the classification rules in 4.3(a). My interpretation is that death or serious injury is not possible based on the ISO14971 analysis above. Assuming that a sequence of events is possible which results in minor injury, the software would classify as B.
I think the point is that not every remote or improbable sequence of events - with a software item involved - which leads to serious injury or death automatically classifies the software item as C.