nanordrecon
Registered
Should it even be on the hazard analysis (software)?
We have a software that creates reports that can tell a patient about their usage of a drug. No real time messages, but if they go through enough clicks, they can find this report.
Our reports follow what the regulatory body told us to do, to minimize, no, ELIMINATE the risk of misinterpretation causing too much or too little medicine. The medicine is not potent, so would one would have to really take a lot, or stop for a long time, for it to be a serious harm.
We have previously run human factors studies showing these reports, and other text that has now been removed, did not cause the patients to take any type of action that they wouldn't normally do - as in, they still take the medicine based on they are feeling, nto based on what the report says.
Now we are trying to classify from an IEC 62304 persepective, and debating whether this should be even be on the hazard analysis. Some of us say that based on the DESIGN of the wording of these messages, a patient would not take more or less medicine based on what the report said (correct or incorrect), so it doesn't even belong on the risk analysis. The text can be on a user risk analysis, but not on this software hazard analysis
Others state that the software could malfunction, produce incorrect data on the report, the possibility a patient might then misinterpret it, the remote possibility a patient would then significantly over or under dose, and then cause a harm. Therefore, it would belong on the risk analysis with a low probability, but high harm. Since per IEC 62304, probability is considered 100%, and before mitigation so human factors is not considered, it then pushes us into level C. But others disagree with this since the messages have been DESIGNED (as told by the regulatory body) so people will not take action on them independent of how they are feeling, and so the human factors is not a mitigation, but part of the design, and therefore, should not even be on the risk analysis.
How can we resolve this from a risk management perspective?
We have a software that creates reports that can tell a patient about their usage of a drug. No real time messages, but if they go through enough clicks, they can find this report.
Our reports follow what the regulatory body told us to do, to minimize, no, ELIMINATE the risk of misinterpretation causing too much or too little medicine. The medicine is not potent, so would one would have to really take a lot, or stop for a long time, for it to be a serious harm.
We have previously run human factors studies showing these reports, and other text that has now been removed, did not cause the patients to take any type of action that they wouldn't normally do - as in, they still take the medicine based on they are feeling, nto based on what the report says.
Now we are trying to classify from an IEC 62304 persepective, and debating whether this should be even be on the hazard analysis. Some of us say that based on the DESIGN of the wording of these messages, a patient would not take more or less medicine based on what the report said (correct or incorrect), so it doesn't even belong on the risk analysis. The text can be on a user risk analysis, but not on this software hazard analysis
Others state that the software could malfunction, produce incorrect data on the report, the possibility a patient might then misinterpret it, the remote possibility a patient would then significantly over or under dose, and then cause a harm. Therefore, it would belong on the risk analysis with a low probability, but high harm. Since per IEC 62304, probability is considered 100%, and before mitigation so human factors is not considered, it then pushes us into level C. But others disagree with this since the messages have been DESIGNED (as told by the regulatory body) so people will not take action on them independent of how they are feeling, and so the human factors is not a mitigation, but part of the design, and therefore, should not even be on the risk analysis.
How can we resolve this from a risk management perspective?
Last edited:
