4 ms·

I have no specific knowledge of GE CT scanners, and I've also seen some very crufty GE code which was full of potential issues. However, for what it's worth, t

by ska 7y ago

I have no specific knowledge of GE CT scanners, and I've also seen some very crufty GE code which was full of potential issues. However, for what it's worth, these sorts of safety systems (and similarly SAR monitors in MRI, etc.) tend to be well validated as part of the overall hazard and risk analysis, and people spend the time here, they tend to have interlocks and other often redundant safety subsystems that work. I guess what I'm saying is that I wouldn't expect bugs to trip you up in the primary-yet-dangerous function, as this is where the obvious problem areas are. This article describes how the attack surfaces on medical devices aren't good. This is definitely true. Especially with older designs that have been updated over the years but were designed with no network or private network in mind.

kwiens 7y ago
> Between June 1995 and January 1987, six patients were seriously injured or killed by unsafe administration of radiation from the Therac-25 medical linear accelerator. > The Therac-25 software errors that cause radiation overexposures can be reduced down to interface errors. The first of these errors involved the entering of treatment data by the machine operator. Once an operator enters treatment information at the terminal outside of treatment room, the magnets used to filter and control radiation levels are set. There are several magnets, and the process takes about 8 seconds. If the operator makes a very, very quick change of the treatment information, within 1 second, the change is registered. Or, if the operator is rather slow about it, takes more than 8 seconds, the change is also registered. However, if the change occurs within the eight seconds it takes to set the magnets, the change is not detected and the magnets continue to be set up improperly, and thus the level of radiation is set up improperly. > The last of the accidents occurred at the Yakima Valley Memorial Hospital. On January 17, 1987 an operator placed a patient on the turntable in the field-light position for small position verification doses. After attempting to administer the treatment dose, the machine shut down with a quick malfunction message and a treatment pause. The operator pushed the "P" button, and the machine paused again. The machine indicated that the patient had received his prescribed 7 rad of treatment. The patient, however, complained of a "burning sensation" and died three months later from complications related to the overdose (Leveson and Turner, 1993, p. 33) . http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.html http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.ht...
- ska 7y ago
  Yes, that happened. And partially because the industry learned from Therac-25 (and other issues), collectively it got much better at avoiding this sort of failure mode. I’m not saying it’s perfect, but it is not a high risk scenario for the poster I responded to.
  - colechristensen 7y ago
    The only complex systems I'm really comfortable trusting my life with are aircraft. Why is not the absence of accidents but the NTSB response to them and their public reports.
    - ska 7y ago
      They really do have a good system
    - deleted 7y ago
      [deleted]
- seren 7y ago
  Actually IEC62304, which describes Sw development lifecycle for medical devices, was precisely written in answer of the Therac accident. All medical devices with Software you use nowadays has to follow IEC 62304. It does not mean that medical device SW is perfect or bug-free, but it means that the manufacturer should demonstrate some level of risk management, verification and validation to the regulatory bodies before being allowed to sell a new product. It is not perfect but you should not get sick because someone pushed some untested bug fix on Friday night and you have an exam on Monday morning on an untested SW release, the process would not allow it.
  - ska 7y ago
    That's not quite right, these things didn't come in with 62304. For a (US based) example, before adopting it the FDA still expected you to demonstrate risk & hazard analysis, V&V, and generally SDLC lifecycle management to your SW products (just like hardware ones). However, they offered no opinion on how you should do it. But the overarching standard you were held to as a manufacturer is (still) ISO13485. And coming from a hardware centric view of things, the FDA wasn't sure how to evaluate SW processes, and different panels did things differently. What IEC62304 adds to the mix is specific guidance on your SDLC process. If I recall correctly you are still not required to audit to in the US but new projects should follow it or demonstrate why they are not.

by ska 7y ago

kwiens 7y ago

> Between June 1995 and January 1987, six patients were seriously injured or killed by unsafe administration of radiation from the Therac-25 medical linear accelerator. > The Therac-25 software errors that cause radiation overexposures can be reduced down to interface errors. The first of these errors involved the entering of treatment data by the machine operator. Once an operator enters treatment information at the terminal outside of treatment room, the magnets used to filter and control radiation levels are set. There are several magnets, and the process takes about 8 seconds. If the operator makes a very, very quick change of the treatment information, within 1 second, the change is registered. Or, if the operator is rather slow about it, takes more than 8 seconds, the change is also registered. However, if the change occurs within the eight seconds it takes to set the magnets, the change is not detected and the magnets continue to be set up improperly, and thus the level of radiation is set up improperly. > The last of the accidents occurred at the Yakima Valley Memorial Hospital. On January 17, 1987 an operator placed a patient on the turntable in the field-light position for small position verification doses. After attempting to administer the treatment dose, the machine shut down with a quick malfunction message and a treatment pause. The operator pushed the "P" button, and the machine paused again. The machine indicated that the patient had received his prescribed 7 rad of treatment. The patient, however, complained of a "burning sensation" and died three months later from complications related to the overdose (Leveson and Turner, 1993, p. 33) . http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.html http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.ht...

ska 7y ago
Yes, that happened. And partially because the industry learned from Therac-25 (and other issues), collectively it got much better at avoiding this sort of failure mode. I’m not saying it’s perfect, but it is not a high risk scenario for the poster I responded to.
- colechristensen 7y ago
  The only complex systems I'm really comfortable trusting my life with are aircraft. Why is not the absence of accidents but the NTSB response to them and their public reports.
  - ska 7y ago
    They really do have a good system
  - deleted 7y ago
    [deleted]
seren 7y ago
Actually IEC62304, which describes Sw development lifecycle for medical devices, was precisely written in answer of the Therac accident. All medical devices with Software you use nowadays has to follow IEC 62304. It does not mean that medical device SW is perfect or bug-free, but it means that the manufacturer should demonstrate some level of risk management, verification and validation to the regulatory bodies before being allowed to sell a new product. It is not perfect but you should not get sick because someone pushed some untested bug fix on Friday night and you have an exam on Monday morning on an untested SW release, the process would not allow it.
- ska 7y ago
  That's not quite right, these things didn't come in with 62304. For a (US based) example, before adopting it the FDA still expected you to demonstrate risk & hazard analysis, V&V, and generally SDLC lifecycle management to your SW products (just like hardware ones). However, they offered no opinion on how you should do it. But the overarching standard you were held to as a manufacturer is (still) ISO13485. And coming from a hardware centric view of things, the FDA wasn't sure how to evaluate SW processes, and different panels did things differently. What IEC62304 adds to the mix is specific guidance on your SDLC process. If I recall correctly you are still not required to audit to in the US but new projects should follow it or demonstrate why they are not.