|WikiProject Medicine||(Rated Start-class, Mid-importance)|
What language does the phrase "beam flattener" come from? The English term for the object which converts an electron beam to X-Rays is "target".
Atlant 01:01, 28 Feb 2005 (UTC)
- the "beam flattener" would probably be the "flattening filter", which is required to produce a 'flat' beam profile at a depth of 10cm (usually). it is a component in the chain after the target. the target dose not produce a uniform beam profile, hence the reason for the flattening filter.... —The preceding unsigned comment was added by 126.96.36.199 (talk • contribs) .
- Atlant 18:26, 27 July 2006 (UTC)
- I read the accident report, and it's fascinating! When used in high-power mode, the beam is supposed to pass through a metal plate which spreads the X-rays out over a large area. This plate absorbs most of the energy hitting it, so they have to crank up the voltage to compensate. Since the plate wasn't in position, not only did the patient receive a lethal 25,000 MEV blast, but it was concentrated into a tight beam. OWWW! TechnoFaye Kane 01:39, 20 February 2008 (UTC)
The article mentions that victims received tens of thousands of rads, but makes no mention of what amounts of rads are deemed dangerous (such as a maximal treshold permitted by health authorities). —Preceding unsigned comment added by ToohrVyk (talk • contribs) Pjacobi 00:00, 29 December 2005 (UTC)
- You're right. The information is hidden at Sievert#Explanation and the reader is rquired to do the unit conversion and the application of the Q-factor. I'll put this on my to-do-list. --Pjacobi 00:00, 29 December 2005 (UTC)
- In the case study written by Nancy Leveson (Univ of Washington) and Clark S. Turner (Univ of Cal, Irvine), the following information is given: "Typical single therapeutic doses are in the 200-rad range. Doses of 1,000 rads can be fatal if delivered to the whole body; in fact the accepted figure for whole body radiation that will cause death in 50 percent of the cases is 500 rads." [bweable]
- So why no discussion about what happened to the company? Were they sued? Who are the victims? What was the quality of life like for those who survived? I'm too lazy to login, but I am ClintJCL. [clintjcl]
- They make nuclear reactors now. They were sued and all of them were settled out of court. — Preceding unsigned comment added by 188.8.131.52 (talk) 05:29, 21 August 2019 (UTC)
3 or 5 deaths?
The (summary) reference lists 3 radiation-induced deaths (out of 6 accidents), while the article says 5 (of 6). I won't change it myself because the reference may be dated but in that case this should perhaps be remarked upon@?
How does Assembly Language have anything to do with this? It's just a language, debugging isn't the point. The point is that it didn't have any hardware implementations as a fail-safe.
- Klasanov —Preceding unsigned comment added by 184.108.40.206 (talk) 17:48, 14 October 2007 (UTC)
possible incorrectly stated energies for the 2 modes of operation?
"The failure only occurred when a particular nonstandard sequence of keystrokes was entered on the VT-100 terminal which controlled the PDP-11 computer: an "X" to (erroneously) select 25,000 EV mode followed by "cursor up", "E" to (correctly) select 200 EV mode, then "Enter". This sequence of keystrokes was improbable, and so the problem did not occur very often and went unnoticed for a long time."
Aftermath of the Incident
Were there any lawsuits involved, and how have the survivors gone on to live – any major ailments from the radiation? Also, does anyone know where there are photos of the patient injuries or the Therac-25 machine itself? I feel these would add greatly to the article. —Preceding unsigned comment added by 220.127.116.11 (talk) 02:44, 16 October 2008 (UTC)
- According to Nancy Leveson's comprehensive analysis of the entire Therac-25 incident (see the External Links section), there were a number of lawsuits filed against AECL, all settled out of court.
== Well, found this on Google: In 1986, Ray Cox went into the clinic for his usual radiation treatment in his shoulder. The technician mistakenly typed "x" into the computer, which signified x-ray beam, then immediately realizing the error, changed the "x" into an "e" for electron beam, and hit "enter", showing the machine that they were ready to start treatment. This sequence occurred in less than 8 seconds.(This particular sequence, in this time frame, was never tried in the original testing of the machine.) The computer gave the signal of "beam ready", and the technician pressed "b" to deliver the beam to the patient. But then the computer responded with an error message. Usually this message meant that the treatment had not been delivered. So the technician repeated the process and delivered another beam to the patient. And yet again, an error message occurred. Meanwhile,Ray felt sharp stabbing pains in his back, which was much different than his usual treatments, and removed himself after three shocking attempts. Because the commands were changed in such a short period of time, the computer did not respond properly. The metal plate moved away showing the technician that it was in low energy electron beam mode. But the beam that actually came from the machine was a blast of 25 000 rads with 25 million electron volts, the maximum setting, which is more than 125 times the regular dose. Ray’s health quickly became worse, and he died 4 months later from complications of major radiation burns. == —Preceding unsigned comment added by 18.104.22.168 (talk) 03:38, 29 December 2008 (UTC)
Not a "race condition."
It's stated at the end of the "Problem Description" section that this is a race condition.
This does not appear to be the case.
A race condition is when the potential timing of preceding conditions is not correctly accounted for in software (or hardware) and cause an unexpected or undefined state to occur.
Timing was not relevant to this sitution. That is, the particular situation resulted because certain predicate conditions were not specified as required or were not verified to be in the required state*. Specifically "don't use the high power beam unless the target is in place."
It was not because they were specified but occurred in an unaccounted for sequence. ______
- The malfunction alert and the trivial override indicate that, perhaps, the situation WAS detected but was simply bypassed. If so, then it's even more clearly not a race condition.
- Did you deduce that just by reading the article or did you get that from an external source? The Wikipedia description doesn't explain the issue in sufficient detail to tell what exactly was the underlying software flaw.
- This link claims that "Race conditions resulting from this implementation of multitasking played an important part in the accidents." and explains in limited detail the disregard for issues arising from concurrent programming.
- That document is part of An Investigation of the Therac-25 Accidents, published in IEEE Computer, Vol. 26, No. 7, July 1993, pp. 18-41. This is a quite often-cited paper and is used as an example in many university CS courses. According to Google Scholar, this paper has 551 known citations -- intgr [talk] 12:45, 15 October 2009 (UTC)
Would it not make more sense to write it as "The software flaw was the result of a race condition bug in the safety subsystem."? Something to make it more clear that the selection of beam mode isn't a race condition. —Preceding unsigned comment added by 22.214.171.124 (talk) 18:32, 12 December 2010 (UTC)
- Why the hell are they using concurrent programming in a procedural device. There's no reason why input flow in such a device should be allowed at the same time the device is in a mechanical transition. Input all variables ahead of time and then operate, only allowing concurrency for an emergency cancel, which would kill the laser... — Preceding unsigned comment added by 126.96.36.199 (talk) 13:23, 3 July 2012 (UTC)
The IEEE paper explains the flaw in great detail. The "not a race condition" commenter proposes that the cause of the accident was that the software failed to verify that the machine's components were in the required state, but this is an effect, not a cause, of the underlying problem. The IEEE paper describes that the Therac-25 had removed the hardware interlocks that were present on previous models, depending instead on software interlocks for safety. The software interlock failed due to a race condition. The defect was as follows: a one-byte counter in a testing routine frequently overflowed; if an operator provided manual input to the machine at the precise moment that this counter overflowed, the interlock would fail. This is a classic race condition. For reference, see the section titled "The Yakima software problem" in the IEEE paper. —Preceding unsigned comment added by 188.8.131.52 (talk) 20:57, 28 December 2009 (UTC)
What does scanning mean when talking about radiotherapy? I had an idea that scanning meant sending some pulses/particles/something onto/through an object and getting some knowledge about the shape/content/material/constitution by looking at what is reflected or what gets through.
But it must mean something else here. The wiki article only talks of "scanner magnets" but the article by Leveson and Turner for example says something about that the machine could turn on the beam without scanning.
Kinda like the scanning motion of a CRT's electron beam, scanning in this context refers to moving the therapeutic beam over the treatment area rather than simply leaving it focussed in one place. You'd do this for much the same reason as in a CRT: you want to treat a (relatively) large area with an even dose rather than zapping a tiny area specifically.
While it's true that a software issue was at the root of the problem, I read elsewhere that operators walked away from the machine in operation. This contributed to the disbelief of there being a problem. Dlamblin (talk) 21:43, 10 August 2012 (UTC)
The software interlock could fail due to a race condition
Such incidents would not have been an issue in a single-use machine and unlike previous models, the Therac-25 relied on software rather than hardware safety interlocks. What happened was the operator using a keypad would select a particular mode. The machine would then start a programmed cycle and move plates into position. This normally could take up to a minute. Meanwhile, the operator then realizing his mistake would re-enter the correct mode. The machine continued to run the old cycle and ignored inputs from the keypad, but the display showed the new settings. The operator, not realizing this then switched on the machine and gave the patent the wrong dose of radiation.
"lack of synchronization between Datent, Ptime, and Magnet subroutines caused a change in data entry to remain undetected to the device" — Preceding unsigned comment added by Codeusirae (talk • contribs) 23:30, 29 October 2013 (UTC)
When was the machine Made?
- According to the Nancy Levenson source, a prototype was made in 1976 and a commercial version was available in late 1982, so I am using the latter date. I have added the information. Opencooper (talk) 00:04, 3 January 2016 (UTC)
Thousands vs. 100
- According to page 23 of this source by Nancy Leveson, typical radiation doses are in the 200-rad range, while a patient at Kennestone (Katie Yarborough) received dosage in the range of 15,000 to 20,000 rad. Additionally, this source says that Ray Cox was supposed to receive 180 rads, but got 15,000 to 16,000 rads. That is a factor of 100 so I am changing the lead to match the body. Opencooper (talk) 23:54, 2 January 2016 (UTC)
half the issue was need for operator in a boring simple task
There is plenty study in eg. Military air operations that pilots use stimulants when there's nothing happening.
The error here was that the operation consisted of selecting a mode and starting the machine then leaving the room. A cow would have been a better operator than human for such task, especially given the lack of requirement for any ancilliary functions such as measuring the device functions as intended before patient uses it.
I've been to ultrasound three times now and each operator of the ultrasound used significant force in pressuring the probe such that I had discomfort for several days. And each time nothing was found while the issue was definitely real and in the area probed. After looking at some ultrasound images i have to conclude ultrasound should not be human operated but only use through 3d scanner tomography that is possible to be operated by the patient. The way this would function is like the ipad fingerprint scanner. The computer informs the patient-operator when there is no longer new information arriving and asking patient to move the probe. Since it is a tomography, the results can also be interpreted without doctor assistance by computerized correlation to healthy reference data. — Preceding unsigned comment added by 184.108.40.206 (talk) 00:55, 9 December 2018 (UTC)
A Commons file used on this page or its Wikidata item has been nominated for deletion
The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion: