Just had a ct scan from a GE machine. Can’t say I wasn’t wondering about the likelihood some bug would give me too much radiation...
back
4 comments
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.
> 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.ht...
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.
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.
They really do have a good system
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.
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.
Thanks for the historical perspective.
It's not terribly likely IMO. (I worked on a CT scanner design team). Worst case scenario IMO is that the scanner would halt mid-scan and the CT tech would repeat the scan, causing accumulated dose. If this iterated several times it could be cause for concern. I think those outcomes are extremely rare and most techs would give up after a couple of aborted scans.
It's happened before and is taught in every human factors course
Yeah, it's not that something like that could never ever happen w a CT scanner but Therac-25 was intended as a Radiation Therapy device. The vast majority of CT scanners are strictly diagnostic. So the magnitudes of dose that could even be produced are limited. [1]
I encourage concerned customers to ask for their dose report. IMO it's mildly interesting on its own. It's more interesting if your physician or surgeon prescribes follow up tracking to see if tumors return/grow. In that case you have repeated scans over a period of many months to track lesions/tumors and the accumulated dose at the same body location becomes worth more concern.
The prescribing physician should balance the harm of dose with the diagnostic concern/risk being evaluated, but there's nothing wrong with advocating for yourself. In general I think the cases where you have repeated scans it's because something terribly serious has been diagnosed that far outweighs the impact of the dose.
Also if you're concerned about dose you might be able to use CT scanner dose features as a tool when evaluating different outpatient imaging options. Feel free to debate this with your physician and not necessarily go to the one that they get a kickback from.
[1] For a stunning counter-example to my claim here, you can look at the case where the CT tech completed MANY repeated cranial CT scans of a toddler (scanner was mfd by Picker IIRC) -- https://www.diagnosticimaging.com/articles/california-blames...
CT scanners should have a hardware interlock to prevent that.