R
the only problem with this scheme is that the diagram in ISO 14971 clearly shows that the hazard precedes the hazardous situation, which precedes the harm, and the diagram shows that the sequence of events are between the hazard and the hazardous situation. for software, the only way I know how to assess its risk is to include things that start with the software not operating the way designers think it's supposed to. some of these are design flaws, some are coding errors, and some are system integration problems, but they are all collectively referred to as bugs, or software defects. the word defect is a bit misleading, because it comes from a testing and SQA viewpoint, but if ISO 14971 is to be applied, this seems like a compliant way to do it.
You called the burn the hazard and the harm. this is what confuses people. the harm is definitely the burn, if one occurs. the hazard is that the software makes a bad calculation. another hazard is the user enters data incorrectly. both of these hazards should be in the risk assessment. the first one is pure software defect, the second has to do with training, IFU, and usability of the user interface.
You called the burn the hazard and the harm. this is what confuses people. the harm is definitely the burn, if one occurs. the hazard is that the software makes a bad calculation. another hazard is the user enters data incorrectly. both of these hazards should be in the risk assessment. the first one is pure software defect, the second has to do with training, IFU, and usability of the user interface.
Last edited by a moderator: