3 ms·

Great write up ! I am working in medical devices but I am more familiar with the FDA regulations. What I wonder regarding risk management is how you justify t

by seren 8y ago

Great write up ! I am working in medical devices but I am more familiar with the FDA regulations. What I wonder regarding risk management is how you justify the safety of QT /iOS / Android. In its risk management, the FDA asks you to list of your SW dependencies you are using "off the shelf", and you have to analyze how any failure of any of your dependencies could lead to a failure of your device/application (which is good sense really). So usually for a simple library it is easy to justify and identify the failure mode, but you look at the OS or big frameworks, it is always harder to find a clear mitigation. Especially at the OS level where potentially any part of memory could be corrupted, your thread not being scheduled, etc. For example, in your case imagine you have a driver or QT rendering bug that makes the red overlay layer becoming transparent on some HW. That would lead to the user not identifying the correct area and in the end lead to a wrong computation. (I can see on some screenshots you have the percentage displayed so that could be a mitigation in itself) I am working in the embedded space so generally we have less dependencies and a simpler code base, but we are always reluctant to use off the shelf SW because of the added risk management required. This is counter intuitive for safety but from a regulatory stand point it is sometimes easier to reimplement some features, than using a proven library, because this is less a hassle to justify or maintain. So was it something raised by the regulator ? Can you give us some example of how you addressed it?

chrisseaton 8y ago
I don't think you should think about the risk in isolation like that. Yes, you can't reasonably control the risk of iOS not working as intended, and Apple will never guarantee it does work, and I'm not sure there is anything anyone can do about that on a consumer device. So there's a risk there. But what's the risk of not having the app because you were afraid of the other risk? Doctors getting fluids wrong - and we found in practice they did get them wrong regularly and significantly. Reduce one big practical risk, but yes introduce one smaller more theoretical risk. And mitigate where reasonably possible. These aren't official statements on UK app regulation or the NHS's policy on Mersey Burns, though.
- seren 8y ago
  > I don't think you should think about the risk in isolation like that. I don't disagree with the sentiment but FDA asks you precisely to do this analysis piecewise by what they call "SW units". And for each SW unit, you have to define a severity of hazard that can result from a malfunction of that SW unit. (from minor injury to death or irreparable damage) Now you can always say you have a single "SW unit" to not have to check the boundaries or interactions, but then all the SW should have been developed with the same methodology/process, and this is not possible when you are using SW coming from an external source. (because you have no idea how it has been developed, and it was likely not targeting medical devices) As as aside, the recommendation by the FDA is that, prior any mitigation, you have to assume that a SW bug as a 100% chance of happening. (That tells you how confident are the regulators..) But all SW bugs do not necessarily create an hazardous situation. > But what's the risk of not having the app because you were afraid of the other risk? Doctors getting fluids wrong - and we found in practice they did get them wrong regularly and significantly. You are allowed to use the benefits risk analysis by the FDA, but you have to demonstrate first there are no other mitigations possible, that you are ALARP (As low as reasonably possible) [0]. You need to explicitly write it in a risk management document to demonstrate you have analyzed that source of hazard. To be fair, I am not anti regulation, but I think most of these standards are more applicable to SW written in the 80s or 90s when the SW stack where a bit smaller and simpler. And I have hard time to understand how they can be applied in practice in complex SW stacks like iOS. That's why I was interested by your experience, but it seems NHS did not challenge you on the finer implementation details. I understand this is complex because we are talking about 2 different regulation frameworks, so it is not necessarily transferable. Thanks for chiming in, that is still great to know that is is possible to get something approved on a modern tech stack. [0] https://en.wikipedia.org/wiki/ALARP https://en.wikipedia.org/wiki/ALARP

by seren 8y ago

chrisseaton 8y ago

I don't think you should think about the risk in isolation like that. Yes, you can't reasonably control the risk of iOS not working as intended, and Apple will never guarantee it does work, and I'm not sure there is anything anyone can do about that on a consumer device. So there's a risk there. But what's the risk of not having the app because you were afraid of the other risk? Doctors getting fluids wrong - and we found in practice they did get them wrong regularly and significantly. Reduce one big practical risk, but yes introduce one smaller more theoretical risk. And mitigate where reasonably possible. These aren't official statements on UK app regulation or the NHS's policy on Mersey Burns, though.

seren 8y ago
> I don't think you should think about the risk in isolation like that. I don't disagree with the sentiment but FDA asks you precisely to do this analysis piecewise by what they call "SW units". And for each SW unit, you have to define a severity of hazard that can result from a malfunction of that SW unit. (from minor injury to death or irreparable damage) Now you can always say you have a single "SW unit" to not have to check the boundaries or interactions, but then all the SW should have been developed with the same methodology/process, and this is not possible when you are using SW coming from an external source. (because you have no idea how it has been developed, and it was likely not targeting medical devices) As as aside, the recommendation by the FDA is that, prior any mitigation, you have to assume that a SW bug as a 100% chance of happening. (That tells you how confident are the regulators..) But all SW bugs do not necessarily create an hazardous situation. > But what's the risk of not having the app because you were afraid of the other risk? Doctors getting fluids wrong - and we found in practice they did get them wrong regularly and significantly. You are allowed to use the benefits risk analysis by the FDA, but you have to demonstrate first there are no other mitigations possible, that you are ALARP (As low as reasonably possible) [0]. You need to explicitly write it in a risk management document to demonstrate you have analyzed that source of hazard. To be fair, I am not anti regulation, but I think most of these standards are more applicable to SW written in the 80s or 90s when the SW stack where a bit smaller and simpler. And I have hard time to understand how they can be applied in practice in complex SW stacks like iOS. That's why I was interested by your experience, but it seems NHS did not challenge you on the finer implementation details. I understand this is complex because we are talking about 2 different regulation frameworks, so it is not necessarily transferable. Thanks for chiming in, that is still great to know that is is possible to get something approved on a modern tech stack. [0] https://en.wikipedia.org/wiki/ALARP https://en.wikipedia.org/wiki/ALARP