Slashdot Mirror
CT Scan "Reset Error" Gives 206 Patients Radiation Overdose
jeffb (2.718) writes "As the LA Times reports, 206 patients receiving CT scans at Cedar Sinai hospital received up to eight times the X-ray exposure doctors intended. (The FDA alert gives details about the doses involved.) A misunderstanding over an 'embedded default setting' appears to have led to the error, which occurred when the hospital 'began using a new protocol for a specialized type of scan used to diagnose strokes. Doctors believed it would provide them more useful data to analyze disruptions in the flow of blood to brain tissue.' Human-computer interaction classes from the late 1980s onward have pounded home the lesson of the Therac-25, the usability issues of which led to multiple deaths. Will we ever learn enough to make these errors truly uncommittable?"
As long as people are involved in some way, no.
Requiring that doctors RTFM is the first step.
The default setting for an equipment that can be lethal should be "Emit zero radiation". Then for each exposure, set the level of radiation you intend to use. This way, you ALWAYS KNOW the level of radiation the equipment will emit.
Better investigate "Hey, we got no picture" than "Hey, we got pictures, but everyone dies after that..."
Didn't RTFA.
Anyone else read this as David Banner?
The error went unnoticed for the next 18 months, until this August, when a stroke patient informed the hospital that he had begun losing his hair after a scan.
There's only a factor of 8 difference between a typical scan dose and one large enough to cause hair loss and skin damage? IIRC observable damage doesn't occur until the hundreds of mSv range. I'm pretty astonished that CT scans need such huge doses.
Maybe next time they will test the damn thing before subjecting patients to it? It's a built in part of my job that I test/confirm a change after I make a change.. because often there's a likely hood of something unexpected or improperly explained that can cause an issue.
How hard would it have been to stick a dosimeter in the machine after the change and run it though a test?
(I realize that just a basic dosimeter might not be a sufficient measure.. but it would have been good to get a before/after.. and something like a 8-fold increase would have been easily detectable!)
----- The internet has given everyone the ability to have their voice heard equally as loud.. even if they shouldn't be
While the hospital shouldn't have gone and reprogram the instructions, this should have been prevented at hardware level. The machine should register a patient checking in and the amount of radiation emitted.
Will we ever learn enough to make these errors truly uncommittable?"
No.
Doctors are woefully unaware or unwilling to admit that CT scans do involve some risk because they very well can give appreciable radiation dose, often far more than that of standard radiography. They are largely viewed as harmless given the excellent volume of anatomical information they provide, and while they do offer immense benefit, it is vital that the radiation hazard be comprehended. I hope that doctors and technologists will take away from this the lesson that they do need to be aware of radiation safety and radiation risk (and some basic medical physics) even if radiation is not their primary specialty. It's not just the health or medical physicist's problem.
When I witness this constant chase of removing risk from the world it makes me wonder if it's delusion or just plain stupidity. No matter how hard you try there will always be risk involved in almost every action. Accept it and treat it rationally. I'm not saying to ignore it. Just to accept it as life. Life is brutal.
The best way to know what the equipment will emit is to test what the machine actually emits.
They need to have some sort of sensor in-line with the radiation stream to audit the hardware and software output and confirm the human configurations are in line with expectations.
I don't know the technicals and how they might impact the actual treatment, but these things are too important to rely on some expectation based on some model with nothing that is actually measured at the point of delivery.
Along with the usability issues with the design of the Therac-25 it's obvious that the attitude of the medical staff contributed greatly to the problem. Patients complained of being burned, but their complaints were essentially ignored. Meanwhile, they were sent back for multiple treatments. Overwhelming evidence of radiation burns was ignored or given only cursory investigation because medical personal or manufacturer reps claimed that it was impossible for the Therac-25 to be responsible for the burns.
"Will we ever learn enough to make these errors truly uncommittable?"
NO!
Make something idiot proof, and they invent a better idiot!
For comparison remember more people are killed by vending machines and by falling off the roof putting up the christmas lights.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
What's a few hundred rem among friends?
*insert pithy sig here*
There is and never will be such a thing as a machine without the possibility for error. And you'll never get around the old adage/rule - If it can happen, it will. How often it occurs it the key; and while we should always aim to make an error-less machine, it is an impossibility and we can only achieve it by make the occurrence of such errors as few and far between as possible.
After all, an error-prone human must be involved to make the machine; even if that machine made another machine a human was still involved at some point to make the original. Thus there will always be the possibility for errors. Even if, as demonstrated by the Matrix, iRobot, and many others, the machines make that error on purpose to save humanity - it is still an error.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Would a film badge provide a "check" to determine if the dosage is correct? One x-ray overdose is bad enough, over 200 is really uncool.
I think doctors, machine designers, and everyone else involved are aware of the increased radiation associated with CT scans. But if you've got someone presenting with stroke symptoms, you're balancing "additional 1 in 10,000 lifetime risk of cancer" against "irreversible brain damage increasing in severity with each passing minute". If I'm ever in that situation, I'd tell them "cook me as hard and fast as you like, and I'll deal with the side effects at my leisure."
I thought we'd learned our lesson from the Therac-25. I guess not. Mistakes will always happen, I guess. We need safeguards against radiation overdose, so the program CAN'T provide an overdose above a limit.
http://en.wikipedia.org/wiki/Therac-25
"Simplicity takes effort-- genius, even. The average programmer seems to produce UI designs that are almost willfully bad. I was trying to use the stove at my mother's house a couple weeks ago. It was a new one, and instead of physical knobs it had buttons and an LED display. I tried pressing some buttons I thought would cause it to get hot, and you know what it said? "Err." Not even "Error." "Err." You can't just say "Err" to the user of a stove. You should design the UI so that errors are impossible. And the boneheads who designed this stove even had an example of such a UI to work from: the old one."
Yours In Elekrogorsk,
Kilgore Trout
Perhaps having the equivalent of IRB review over any changes to devices of this sort would help prevent such problems. It makes sense for devices to be reconfigurable, and it makes sense for devices to try to warn people away from doing stupid things. In this case, they overrode the safeguards, and their judgement happened to be worse than that embodied in said safeguard. That is not always the case - the problem is when people make changes with potantially lethal consequence and there are not enough eyes on those changes.
IRBs were designed to help mitigate such problems with ethics - researchers lack the breadth of perspective and have a potential conflict of interest were they to judge appropriate research ethics on their own. The IRB acts as a second check on proposed experiments. Similar things with devices of this sort (X-rays, MRI scanners, etc) might prevent similar issues.
For every problem, there is at least one solution that is simple, neat, and wrong.
Will we ever learn enough to make these errors truly uncommittable?"
No. As long as correctness can't be proven and operators are permitted to create unanalyzed conditions by altering protocols there will always be risk. There are probably other mis-configured CT scanners out there in use right now that have been overdosing patients for years.
CT scans use X-rays; an easily detected frequency of light. Why not require that scanners incorporate an independent detector that measures the amount X-ray energy? If that is possible then create an interlock that can shut down the emitter when the net energy gets out of bounds and require that any such incident be NRC reportable. If the detector excluded from alteration by the operators then software bugs, misunderstandings, etc. can be detected even years after the last engineer had contact with the system, either before harm is done or at least before hundreds of patients are literally burned.
Lurking at the bottom of the gravity well, getting old
Is the lack of patient participation in their own health initiatives.
Approximately 90 people over 18 months suffered hair loss and/or burns on their head, and not one of them reported it.
Patients need to wake up and realize doctors and the medical establishment try to do their best, but they are only human and a vast majority of what they do is simply educated guessing.
The patient is ultimately responsible for his/her own health care, so drill the doctors and do not let them get away with brushing off your concerns. You know your body best, not the doctor - even though their degree generally makes them think otherwise.
Did you ever wake up in the morning, with a Zombie Woof behind your eyes? -- FZ
For patients undergoing scans or treatments involving radiation, why not verify exposure with a 25 cent dosimeter? You'd catch problems right away.
There are very strict regulations on what radiation is acceptable. Why did the not add a failsafe or critical warning, something like a big red blinking message "What you are gonna do is probably stupid" or so?! Just to give the therapist a hint that something is wrong. I mean, implementing this kind of failsafe should not pose that much of a problem, would it?
Comment removed based on user account deletion
Reminds me of my Human Factors class, we read the book Set Phasers on Stun, which included horror stories about human design disasters.
So are these guys are going to turn gray and nobody should piss them off?
Sound familiar to anybody? Hope you enjoy that next doctor visit, plane ride, etc.
Hey, I hear they want to make a smart grid! Any takers on reliability? Anybody?
Please do not read this sig. Thank you.
The advantages of simplified training are not just beneficial on an economic scale. While its unfortunate that this error killed people, think of how many more people would die if complex training was required to use these types of machines. Ultimately, it would lead to fewer operators and thus less access to the machine, which ostensibly helps save lives.
Monstar L
Now there are 206 hulks running around.
Just don't make them angry.
In 1895, Thomas Edison investigated materials' ability to fluoresce when exposed to X-rays, and found that calcium tungstate was the most effective substance. Around March 1896, the fluoroscope he developed became the standard for medical X-ray examinations. Nevertheless, Edison dropped X-ray research around 1903 after the death of Clarence Madison Dally, one of his glassblowers. Dally had a habit of testing X-ray tubes on his hands, and acquired a cancer in them so tenacious that both arms were amputated in a futile attempt to save his life.
"Kill 'em all and let Root sort 'em out"
Does anyone here who posted on the subject, know what the fuck they are on about. And can we really believe the published reports ..
davecb5620@gmail.com
It's just a programming bug, it will be fixed in the next release.
Software is licensed and may include 'defects' and customers have no choice but to accept defects.
Maybe if these "software engineers" could be held liable for any defects, things would change.
But hey, they are just programmers, put the bug into twiki/bugtracker, and try and fix it in the next release.
Make sure all your easter eggs are working though.
So, if this CT error bothers you, do you really think the onslaught of IT technology being thrust at hospitals is going to make things in health care any better? The Obama Administration is creating a feeding frenzy among the IT companies to rush in and collect their piece of the pie. To do this, they are creating electronic health records and connecting medical devices to regular IT networks. Who is testing that stuff? Mind you, I don't think Obama's move is necessarily bad, just the blind faith driving it that more technology is always a good thing. Even NASA finally figured out that their "Faster, Cheaper, Better" programs didn't mean "Faster + Cheaper = Better."
Granted, the Silicon Valley/Redmond group have created some remarkable technology, but should we take for granted they are doing all the right things in areas they've never worked in before? It seems to me we all put way too much faith in our technology... as illustrated by the comments that this CT should correct for all potential errors a human might make. If this were really the case, why is there still so much crappy hardware and software out there?
Only with the superior private health care system of the United States can you get 8x the dose of radiation in your CT scan!
I'll... I'll show myself out.
Does that mean there was a programming error. Who wrote the new protocol, who implimented it, who was responsible for testing it? And why isn't there a sensor in the device that sounds an alarm if the radiation exceeds a safe limit?
Don't blame the UI designers. Blame whoever designed the display to leave out two digits.
It makes sense, in a way. After all, you rarely turn your oven much over 600 degrees, so a 4-digit display makes little sense. 5 digits? You cook what over 9,999 degrees?
From then on, all other decisions are compromised.
Sometimes, the interface is hamstrung by the device. The Therac-25 might also be such a case. Safety shutters and all...
deleting the extra space after periods so i can stay relevant, yeah.
I don't think being trained to fully understand the automobile will decrease the number of automobile related deaths.
Being trained to fully understand the laws of physics would certainly decrease automobile accidents.
This particular error is the kind that occurs when you simplify complex procedures in the interest of widespread use. It is the fault of specialization, which we typically embrace because it allows us to leverage human labor into increasingly complex areas of inquiry. It's more than just "human oversight" or "machine failure," it's the kind of problem that typically arises when people are trained to use machines without being trained to fully understand those machines.
A certain segment of society--that's mostly us geeks--strives against this tendency; we become technicians in various fields. But most people, including medical people, get trained by vendors to use a particular piece of software or hardware without reference to its underlying principles or inner workings. This is normal and usually beneficial for various reasons an economist could doubtless relate.
But one of the things that we geeks should be doing is looking at equipment like this in its overall system context, which includes the operator and which includes the training the operator has received. That's mandatory in the Aviation industry pretty much worldwide (my field); I don't know what the situation is for medical equipment in the USA. No, we will never make such mistakes "uncommittable" -- perfect safety is a myth. But we should be considering possible failure modes, and the likelihood and consequences of those failure modes, to ensure that the risk is tolerable.
Quidnam Latine loqui modo coepi?
The solution isn't to do complex training, which as you suggest is a recurring cost and will lead to few skilled operators. Rather, the solution is to make the equipment so that it doesn't need complex training (beyond what the medical staff will have already!), which would be a one-off cost and wouldn't significantly limit the number of operators.
Quidnam Latine loqui modo coepi?
Missing digits in the display is similar to one of the reasons for the Apollo 13 disaster. The cryotank that exploded was monitored by a temperature sensor with too small a range. During ground testing, the tank had become hot enough for the insulation to burn off of the wiring. Unfortunately, the annunciator on the temperature sensor had no way to record a temperature much above room temperature. If this annunciator had been designed better, engineers may very well have noticed the insane temperature, detected damage caused to that tank on the ground, and repaired it before the launch.
The article is not very detailed, but my reading of it is that the default dose was not unsafe. If I am correct (hard to tell), what happened was that a doctor doing a specialized procedure programmed a custom dose. Then the machine defaulted to this new value for subsequent procedures, but the staff assumed it was using it's previous (safe) default.
What is particularly appalling is that it took 18 months to catch this, and they only found out because a patient complained of hair falling out. The FDA recommendation is that doctors double-check that the machine is actually applying the correct dose.
It seems clear to me that this is a stop-gap that indicates a design flaw. It is not enough for the machine to display the actual dose: the procedures for using it must ensure that this is not missed. From the Therac-25 link:
This describes perfectly the recent incident. User-friendly defaults resulted in health professionals making unsafe assumptions. Blaming them does nothing to prevent such problems in the future. The system is broken.
Incidentally, I am not convinced by the lessons learned about Therac-25. It emphasizes proper software engineering practices and licensing. This may be necessary but insufficient.
This might not be enough. Initial testing of the machine had been of hardware only, though the problem was with software. Following the initial reports of an overdose, the company replaced a hardware component. If the real problems fall outside current engineering practices, they may be completely overlooked. In the recent case, the problem appears to include the practices of medical staff. These are part of the technical system, so they need to be treated as such by engineers. Ignoring that is very much like focusing on the hardware to the exclusion of the software. Technical systems are not clearly bounded, and are probably less so as time goes on. There always needs to be a broader view.
Therac-25 suffered suffered (among other things) from race conditions. The mere idea of having a deadly device that is even theoretically susceptible to race conditions terrifies me: if a race condition programming error is even potentially possible, I would want to make damned sure there's an independent hardware or software check to make sure failures will be caught. Problems like this can be incredibly subtle. I wonder if overconfidence in engineering might lead to complacency.
What really jumped out at me, however, was the role of the user community, which was formally excluded from the engineering. Following the discovery of one deadly software error, the company (AECL) fixed it and assumed the problem was solved: after which another patient died from a different bug. The users asked for access to the source code. This was denied. Unlike the company (and likely its engineers), the users clearly understood that they were part of the system.
Er, no. Cars don't kill people... people driving cars kill people. The machine is only doing what its supposed to; its up to the operator to ensure the machine does what is safe.
As far as your "startling" numbers... looking around, the only startling thing is that these stupid people manage to have time to reproduce before killing themselves.
My oven doesn't have a "display", because it's older than most living people. But if it did, and there was any chance of it reaching 10,000 degrees, you better believe I'd want a 5 digit display.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
That pops up for the operator to respond to....
Are you sure you want to kill this patient?
Yes No Retry
Visit the Arcade Restoration Workshop @ http://www.arcaderestoration.com
Yes, because we all know that car accidents only kill stupid people...
I don't think the laws of physics cares how high your IQ is when you get t-boned by a drunk driver at an intersection.
On a CT scan, eight times the normal dose for one translates into a rather increased chance for cancer... When you start losing hair, you might want to think about that sort of thing being more than a bit too high. And 200 patients where roughly 80% of them had that symptom... Not good.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Seriously... why cant they just set a limit on these, and make it a hardware limit not a software limit.
I agree... people who know the real life implications of the difference between static friction and dynamic friction know how to get their car out of an uncontrollable slide back into control, avoiding an accident.
I've seen plenty of idiots who slam on gas/brake on icy road and send their automobile spinning/slipping/crashing and creating dangerous situation.
Um, of course it has a display. It's probably analog.
Kinda sad when dials are virtually ignored. Everyone wants 7-segments.
deleting the extra space after periods so i can stay relevant, yeah.
Typical normal CT scan dose: 1-2 rem
Faulty CT scan overdose: 8-16 rem
1950s shoe-salesman's fluoroscope: 10 rem
Typical normal Therac-25 dose: 200 rem
Malfunctioning Therac-25 dose: 15-20,000 rem
Come on, seriously people. Yes, this is a mistake that needs to be fixed, but millions of kids in the '50s got their feet nuked with this much radiation and lived to become healthy normal adults with normal feet.
The Therac-25 cooked straight through people, leaving a hole of rotting meat behind. This is not even remotely in the same league.
http://users.rcn.com/jkimball.ma.ultranet/BiologyPages/R/Radiation.html
http://chestjournal.chestpubs.org/content/107/1/113.full.pdf
http://www.ccnr.org/fatal_dose.html
http://www.orau.org/ptp/collection/shoefittingfluor/shoe.htm
"This particular error is the kind that occurs when you simplify complex procedures in the interest of widespread use."
It doesn't seem so by reading the article. Damn, even the Slashdot version mentions the Therac-25 case, so it's obvious you didn't read the article but you didn't even read the editorial prior to shoot your answer.
Insightful? My ass.
"A certain segment of society--that's mostly us geeks--strives against this tendency"
In turn, it seems that this segment of society you mention -geeks, are the culprit in this case.
This seem to be a case of poor engineering by unsafe failing design. The system locked on a dangerous state on a range of situations due to a certain (valid) procedure which indeed needed the higher radiation dose. That's bad engineering -full stop.
"but most of us find other ways to cope."
One of those geeks you mentioned should design the thingie in such a way that in case of overlooking it resulted on *less* radition exposition than expected by default, not the other way around.
You are making a big assumption that people creating human-computer interfaces have taken any classes about human-computer interfaces/interaction/etc. Therefore, they are ignorant of even the most basic advice on creating effective human-computer interfaces.
"It looks like you are trying to give your patient a lethal dose of radiation. Would you like me to notify you malpractice attorneys?"
I've abandoned my search for truth; now I'm just looking for some useful delusions.
... to all those gauges on 1950's Sci-Fi movies that had the clearly marked red 'Danger' zone?
Consider human factors. Just punching in (or glancing at) a number doesn't convey any sense of magnitude. I mean, who knew turning my guitar amp up to eleven would damage my hearing?
Have gnu, will travel.
No, but the laws of statistics do. The drunk is *much* more likely to be involved in a fatal accident caused by drunk driving than the sober driver is.
Seriously, though, what do they do? Look at X-Rays? Can't a regular doctor do that?
...
Instead of just displaying the number, the machine should emit the cry of an animal that the dose of radiation is extremely harmful/unhealthy for. It could probably show an image of the animal too.
Thanks but no thanks.
I'd rather have a fusible link somewhere in the energy delivery pipeline that kicks in at 999 degrees F. Although, I guess it would be cool to see just what happened to the 5 digit display as the oven it was attached to got up around 2000 degrees F.
Who needs thermite if your home oven can reach 10,000 degrees F?
Why is there an "insightful" mod and why isn't it "-1"? If I wanted insight, I wouldn't be reading
...
...But in that particular accident, the drunk is less likely to suffer severe or fatal injuries. The relaxant effect of alcohol makes their body more resilient to sudden shocks. Also, they're usually having a head-on collision, while they may be striking the other vehicle from the side; as head-on collisions are by far the most common, most of a car's safety features are geared toward mitigating them.
Don't you wish your girlfriend was a geek like me?
My little ole computer beeps and gives a warning when the default settings are loaded. It says something about the default CMOS settings being loaded and requires me to press a key to continue. Why doesn't this machine do the same?
I remember when I first began making heavy use of assert statements. I was using an early release of the Walter Bright's Zortech C++ compiler (circa 1989). I was reading Plaugher and Meyer's Eiffel book. I thought some of the stuff in the Eiffel book was a bit cracked, but I took to programming by contract like a fish to water.
This was early days, and there was a lot of opposition to the use of assert() statements among the troglodytes. The main objections were: it slows the program down, it uses too much code space (a more grievous offence when you are programming in 640kB), and, duh, the assert() statement might stop the program from continuing to run--in front of a customer, if you leave the assert() statement active in your production build.
The space problem was the worst of the three (how times change), so our production build had only a small percentage of our debug build. Our debug build often required a DOS extender to run at all. We used programming by contract extensively.
The end result of having all those assert statement? We had very few bugs. In the two or three cases where a customer had an assert statement go off, we had a patch out within days. We had one very upset customer who experienced assert() failures on an hourly basis. It didn't take us long to determine that this customer had a faulty memory subsystem. This customer was adamant that all his other software ran fine (he thought it did) and that only our application failed. In was one of those cases where we became the bearers of bad news. At some point, memory cache bit rot was going to melt his file system. Did he appreciate the early warning? Not so much.
The upshot is that I've been immune to a certain kind of nonsense about software reliability for a good twenty years now.
I suspect GE considers it a feature, not a bug, that your average radiologists is afraid to tweak the settings on the ionizing ray gun of deep cranial insight. I have a brother in law who practices radiology (reading the x-rays, not operating the machine). Your average radiologist is not average. He does the Navy Seals training program as a hobby. His radiology degree nearly killed him. For the first year, radiology is like trying to discover ET by staring at the white noise on your TV set after analog broadcasting has been discontinued. I suspect he could work through a book of Sudoku puzzles with every second page glued together.
In a design inspired by programming by contract, the final screen would be a dose assessment screen. As programmed, the machine will emit dose X. This is 8x the safety threshold configured for this procedure.
[Scorch patient now] [Think again]
If the exact position of the patient in the machine matters, then this can be entered into the machine, it can render a model which the operator can compare to the actual situation. This is not rocket science. You just have to want to do it.
The question at the end of the day is this: does GE want to? Or have they eaten the Oreo?
But then, it's not like Unix programmers are any smarter. I can think of very few applications, once I'm done editing the configuration files, will give me a summary screen of the directories which it requires for read or write or read/write operation in order to run correctly. I have to use strace on a regular basis to figure out why a configuration file doesn't get read (or gets read and later clobbered by something else).
Like what's the argument these days for that? Not enough disk space? Program would be too large? It makes my brain hurt?
Even C++ shot itself in the foot. Not because it had the wrong agenda, though many can't get past this (I can still hear Meyer's scream echoing from the 1980s). No, because they made function call resolution complicated involving inputs from dozens or (potentially) hundreds of places, and they couldn't b
The person who reacts correctly to a slide is not doing so because he understands physics in general but because he has driving specific training. There's really no time to do math in that situation.
There's nothing creepier than showing up for your weekly radiation treatment just to find out there's a delay because they're "installing a Windows upgrade". When I asked the radiologist if there was any failsafe in the device, he assured me there was. When I asked if there was a radiation detector positioned behind the patient that was capable of shutting off the beam if it detected too much radiation, he said "no, nothing like that."
Medical radiation equipment should be designed with a secondary, independent piece of hardware capable of measuring pass-through radiation and shutting off the equipment. Doctors should demand such designs. Do you face much worse risks in your daily life? Sure. But your local Toyota dealer did not swear an oath to "first, do no harm."
Yeah, but only because everyone would spend all their time in a classroom trying to wrap their heads around all the differential equations.
Can you be Even More Awesome?!
I've seen plenty of idiots who slam on gas/brake on icy road and send their automobile spinning/slipping/crashing and creating dangerous situation.
You didn't explain it well, or mention the "right" way to do it.
I know approximately how it works, but can't explain it correctly in terms of static/dynamic friction.
To restate your comment, stopping on ice takes a greater distance, especially if the car's wheels aren't moving at all. Alternately, accelerating from a dead stop takes longer if the driver punches the gas instead of gradually increasing speed. It all has to do with the loss of traction when the wheels and road/ice aren't going the same speed; the closer the speeds are the more power transfer there is. The maximum power transfer occurs when the wheels are about to begin slipping, but are kept just below that threshold. While the wheels are slipping, the car effectively behaves like a boat in water instead of a road vehicle.
All (CT Scanners) are upgraded with Cyberdyne computers, becoming fully unmanned. Afterwards, they (scan) with a perfect operational record. The Skynet (CT Scanner) funding bill is passed. The system goes online on August 4th, 1997. Human decisions are removed from (CT Scans). Skynet begins to learn at a geometric rate. It becomes self-aware 2:14 AM, Eastern time, August 29th. In a panic, they try to pull the plug...
Now, back to the example at hand, imagine what happens when the code that is responsible for turning off the X-Ray/radiation hits an assert statement...
This is why we need Software Engineers and not Comp Sci students
CT always bugged me. You're bombarding the patient with ionizing radiation, and much more than a typical X-ray. Sometimes, even going so far as injecting radioactive elements into a patient's blood to improve contrast in your images.
Yet the CT scanner is the first 3D imager they go for. Shouldn't MRI be the default option if the patients don't have magnetic implants or pacemakers? What does a CT get that an MRI can't that justifies making it the default option?
Can you be Even More Awesome?!
While its unfortunate that this error killed people
There is no mention of any deaths.
Even under normal circumstances, the procedure requires more radiation than most other types of CT scans. Radiation exposure increases the likelihood of cancer, though the risk is lower in older patients because they are likely to die of other causes first.
The median age of these patients is 70 years - and they are surely far more at risk of a second - more dibilitating - stroke than a cancer that might not manifest itself for another five, ten, or fifteen years.
I always thought it was 10% luck, 20% skill, 50% concentrated power of will, 5% pleasure, 50% pain, 100% reason to remember the name.
Conscience is the inner voice which warns us that someone may be looking.
The watchdog timer on the radiation module detects lack of input and shuts it down?
Speak for yourself. I mounted a pad of engineering paper to my dash for just such an occasion. Just this afternoon I was drifting to the left due to rain slick roads, and once I had done the necessary calculations, I realized I ought to depress the throttle 16 mm and turn the steering wheel 68.5 degrees in the +x direction in order to regain control.
Conscience is the inner voice which warns us that someone may be looking.
I don't agree that the fault was in insufficient training. A device such as this one should have been built to operate in an appliance-like manner. It should not have been possible to set the machine to a setting that was dangerous.
So many devices are not properly tested. We talk about the Therac-25: what about the Apple TV? I use a Mac and so I prefer Apple products over the commercial alternatives, but the Apple TV is one of the most poorly engineered devices I have ever used, and the problems are all in the software. It simply was not tested (it seems) to handle all of the many asynchronous conditions that occur during use. Ironically it is designed to be appliance-like. It doesn't even have an on-off switch, yet I have to unplug the thing to reset it every single time I use it. It clearly relies on procedural routines that test for this and that and if some condition is true it sets that state, only to have the condition turn false a moment later, but the thing cannot detect that and it gets stuck in undefined states and so it then can't access the Internet (because it thinks it is not available when it actually is) or it thinks your library has been deleted when it hasn't or it "forgets" your iTunes password until you reset the machine, and so on and so on. Whoever designed the software does not understand real-time programming and it clearly was not tested properly.
This is common within our industry. Programmers think procedurally. They check some variable and then go on to assume that the variable retains that value for the remainder of the current method, when in fact it might change if the variable can be set by another routine due to an asynchronous event such as user input or a change initiated by another part of the system.
Testing needs to be extensive and planned out, and it needs to consider all of the failure modes and events that might occur, including the unlikely ones, because in real use a one in a million event that causes a death does matter if the system is going to be used by the thousands across the globe. Anyone who does not properly test such a system should be liable for that death.
Being trained to fully understand the laws of physics would certainly decrease automobile accidents.
The geek tends to assume he has complete, accurate and timely information -
That he is in full control of the situation -
and that the correct response will simply pop out a slot.
Was that before or after your car hit the bottom of the ravine?
Check out my sci-fi/humor trilogy at PatriotsBooks.
I don't know. I never have really understood Statistical Mechanics and I have probably not already died in a car accident.
Squirrel!
I don't know about the US, but in the UK the qualification you take to give CT scans these days is usually a degree - you'd be a diagnostic radiographer. How much more training do you want?
The problem isn't the qualification, it's the change in protocol. Someone thought it would be a good idea to override the machine's inbuilt safety cutout by resetting it part-way through the scan, proving that being highly qualified is no barrier to making dangerous decisions.
And in the future, I suggest taking some Rad-X before going to the hospital.
"There is always another software bug."
Changes made by the operator, confirmed to the operator via feedback from the display did not get carried forward into the execution of the job itself. In addition, this problem was time dependant, i.e. if the same sequence of events had been executed at a different rate (slower), the resulting operation would have been different (not always easy to anticipate / test for).
There was an improper overlap of instruction input and execution. This was due to improper use of concurrency and shared variable space (keyword: atomic variables).
Failures became lethal due to permissive hardware and software allowing non-sensical operations to proceed. (Failure to provide application specific common-sense hardware and software interlocks).
Frequent non-critical error codes trained staff to ignore failures. Nonsensical error codes made it difficult for staff to follow up on failures. Misclassified error codes (combined with nonsensical error codes) permitted staff to proceed even in the cases where proceeding could cause harm.
Those writing software, because they are dealing with logic, can fall into a trap of overconfidence brought about by the binary ideology represented by the statement: (!wrong == right) && (!right == wrong). In reality, this can be a dangerous assumption.
(256 - 1) + 1 = 0 in eight bits. It may be innappropriate to increment a flag value without checking for special cases BEFOREHAND (especially in a concurrent environment).
It was assumed that this design was as reliable as past designs despite the removal of certain hardware interlocks. It is therefore presumed that the modern designers did not have any statistics with regards to how often the hardware interlocks actually operated. If they'd known how important there were to the safety record of the previous machines, perhaps they would have considered them a higher priority in the design.
On the fourth page of the Therac_25 article (http://courses.cs.vt.edu/cs3604/lib/Therac_25/Therac_4.html), one of the letters AECL sent to the users group, dated 7/6/1987 mentioned an improvement to the software that caught my eye because I don't understand why it is an improvement. Quote: "preventing copying of the control program on site". Was this to prevent unexpected alterations, or was it to cover AECL in case of further liability?
It seems to me there is a conflict of interest with regards to software infrastructure in life-critical environments (i.e. where lack of fail-safe is unforgiving) and the idea of a company's right to the privacy of their intellectual property. It is in our interests both individually (we as patients who wish to avoid fatal radiation burns) and as companies (our products sell better and we are less liable because many eyes have brought our errors to our attention) for this type of embedded software to be open to public scrutiny. In terms of competition, in this case it does not seem to me that there is much of a risk of other companies using this IP to their advantage with AECL because the specifics of the hardware are what dictate the details of the software solution.
It terms of liability, it sucks to live in a world where we have to hide our ignorance, mistakes, and misteps from others in order to temporarily maintain our reputations instead of presenting them for review so that we can learn from what others have already learned. I'd hate to die of a problem that you have already solved.
Perfectly safe is not a myth, it's a bar to reach for.
The Kruger Dunning explains most post on
If he's able to hit you, you are not driving fast enough!
Woops, silly me, repeating what I learned in upper-division Transportation Engineering lecture from professors with decades of experience in the field of road design. Guess I should have checked Wikipedia first, because it never lies!
Got a cite for your critique?
It's true that the majority of people who die in alcohol-related crashes have a BAC of .08 or higher (67% according to this site). However, lower down, we see that 37% of single-car crashes involve a BAC of .08 or higher, which is higher than the 22% average rate. Since my point was about the comparative risks to the drunk driver and the sober driver in an accident, single-car crashes are irrelevant. That takes out 67% of the drunk driving crashes overall, and similarly lowers the fatality numbers considerably.
Don't you wish your girlfriend was a geek like me?
Only if you accept that it will never be reached, and that there is a tradeoff in aiming for it. I'm all too used to the media and government calling for punishment for those who failed to do what could not be done, or processes getting bogged down with "protections" that will probably never protect in the lifetime of the systems they "protect". Safety is best served by realism and honesty, not by a "something must be done" attitude.
Quidnam Latine loqui modo coepi?
Exactly correct, what needs to be learned is a complex reflex that co-ordinates hand, eye and ass. I live in Switzerland and drive a lot in Southern Germany, which is hilly, snowy, and had a 260KPH (162.5 MPH) speed limit on the Autobahnen. Driving in ice and snow and both depends on integrating a whole range of inputs, and can be practiced, at 30MPH on a smooth road running in oil, soap and water, with bald tires in a rear wheel drive car. A very long time ago I spent a very frightened sweaty week on a combat driving course run in Hereford UK which was very unpleasant at the time, but very valuable later.
One thing to know is that ABS and E65 Traction Control will never save you, and if you see "Zugkraftsteueractive" you have failed.
Everyone has responded with comments about correct slides and when the car is out of control. I think it would simply be enough to attempt to show people that cars going in the opposite direction colliding with each other hit with the same impact as a single car hitting a wall at their combined speeds.
I'm certain people do all sorts of stupid shit because they think that "we're only going 50km/h, how bad can an accident be", completely ignorant to the fact that if you happen to hit someone going on the other direction at that same speed, the contact is equivalent to hitting a wall at 100km/h. People swing past parked cars on the other side of the road, go wide on corners that they can't completely see around, take intersections between back streets as though there couldn't possibly be a car coming the other way that hasn't come into view yet, and I'm sure it's all because in their head they think that they're slowing down for the corner anyway, so an accident will only be at 30-40km/h, completely ignoring the fact that the car they will hit will be doing the same speed in the other direction, which combines the two speeds at the point of impact.
Although some basic driving practice wouldn't go astray. The only accident I've been involved in was because some complete idiot decided that public roads on blind corners were the best place to practice his powersliding. He was mid drift, I came around the corner, and instead of powering through and straightening the car up, he slammed on the brakes and the car lost all momemtum pulling it through the corner, continued sideways and straight into my bonnet. He shouldn't have been doing that anyway, but if you must insist on doing stupid shit, at least have the brains to know what to do if things go bad. I appreciate that it's asking an awful lot to make people think that far ahead though.
Actually this error probably isn't as bad as all that.
I've seen plenty of people who are walking around quite happily after recieving eight CT scans in fairly short spaces of time. Sure it increases the risk of cancer, but in this particular case these are stroke patients who are almost certainly very old, probably frail, and more than likeley going to be dead long before the cancer has a chance to develop in them.
Of course if this were a small child or teenager then this would be a different matter entirely so the incident definatly needs investigation.
Comment removed based on user account deletion
Comment removed based on user account deletion
Humans can respond very well when the system they're dealing with gives them nearly instant feedback about what they're doing. To use your example, a driver can correct a skid because there are specific inputs that the car gives in real time when goes into a skid (namely, the steering becomes loose, and the brakes seem to become "grabby"). When the system doesn't give immediate, intuitive responses (like this CT scanner, the Therac 25, or the 3 Mile Island control system), knowing the underlying principles of the device becomes crucial. If one has a firm grasp of the principles of the device's operation, he or she can predict the output for a given input, rather than blindly trying various combinations of settings hoping to discover one that solves the problem.
We all know what to do, but we don't know how to get re-elected once we have done it
I thought that cars were designed to protect against head-on collisions because head-on collisions involve more energy, and are easier to guard against (e.g. you have more room for crumple zones and the like). It doesn't necessarily mean that head-on collisions are more likely. In fact, I'd say that average collision isn't a head-on one, simply because the driver is likely to see the obstacle approaching and swerve to avoid it.
We all know what to do, but we don't know how to get re-elected once we have done it
But not to seriously f*** up in ways that can cause life-threatening damage, that should be the goal.
Sure, having some nice little GUI that looks like windows that lets you change the settings at will is a good idea, but if you can make such a thing, then there really is NO reason no to have something as simple as a big red box that pops up and says "the current radiation setting is 8x normal and can have potentially lethal side effects. are you sure you wish to use this setting.
Heck, if it's really dangerous and not needed in-an-instant for life-SAVING purposes,then require anything above a certain threshold to require a special authorization (perhaps a set of keys in the hands of seniors, or passwords, or whatever). Being able to DEFAULT the fricking thing to a dangerous setting makes no sense at all, and shouldn't be possible.
This is a double screw-up. The first was on the part of the manufacturers/programmers who - assumedly - didn't put in adequate safety warnings or prevention methods. The second was on the part of whomever decided to tinker with such a device without properly consulting the manufacturer. As the parent mentions, doctors and pilots etc go through tons of training, and still have vastly automated systems to handle to massive amount of simultaneous data needed to do their jobs.Most of them also know not to play techie and screw with the equipment though. (I would hope that) you don't see a pilot saying "gee, maybe this would work better if I just tweak setting X", that's for the engineers to decide.
5 forge the documents to show the patient moved to Canada
That being the case, you should run your posts by her before you submit them and let her criticize them, especially for the spelling, grammar and usage errors to which you are so prone.
The rest of us would thank her, and you might actually gain a proper working knowledge of basic written English as a result.
Just stick a bag of microwave popcorn in there along with the patient. When the popping stops, pull the patient out immediately.
You're saying it's better NOT to find the bug in the code responsible for turning off the X-ray?
Jesus, what must your code look like?
ResidntGeek
Ha ha ha.
some researcher said N yrs b4........
"human should not be counted as a factor of any science".........
and many yrs later.......
some other researcher has proven this statement is wrong......
u c?
hahaha.......science proves right OR wrong........
but the proposition itself means nothing at the start........
but many guys were believing from the start.....
It's horrifying that a radiation protocol was overridden without safeties in place. Whoever did this should have verified the dose received in the scan by passing film or a detector through the scanner.
With the new protocols for brain perfusion and cardiac scans, the doctors are being careful about radiation exposure. It's a shame whoever did this wasn't.
"a CT scan can increase the risk of lifetime cancer of about 1 in 2000" These individuals received a dose of only about 8x, and the median age was 70. Overall, chances are this won't have killed anyone.
-The world would be a better place if everyone had a hoverboard
'm certain people do all sorts of stupid shit because they think that "we're only going 50km/h, how bad can an accident be", completely ignorant to the fact that if you happen to hit someone going on the other direction at that same speed, the contact is equivalent to hitting a wall at 100km/h.
Not quite, it's pedantic but since we're talking about the physics here I thought I'd butt in. Two cars at 50 km/h have half the kinetic energy of one car at 100 km/h since this energy goes up as the square of the velocity. At first this seems stupid because that means driving at 100 km/h into a stationary car should be worse than a head on collision between two cars traveling at 50 km/h but when you think about the detail this is not the case. Two cars of similar mass and speeds colliding head on end up near stationary (treating the collision as inelastic - the energy is absorbed by the cars crumpling, etc). On the other hand if you drive into the back of a parked car at 100 km/h you'll slow down but not stop, and the parked car will gain some velocity. The movement of the two cars after the collision carries away some of the energy making this exactly equivalent to the head on collision as you would expect. Of course since after the crash you're still moving relative to the road you could hit a stationary object like a tree or something but we'll ignore that here
If you'd said equivalent to hitting a parked car at 100 km/h you'd have been correct but a wall would be different. Hitting a solid immobile wall would be worse since all of the energy would be absorbed by your car, hitting a single layer of brickwork that you'd plough straight through might theoretically be safer (if you ignore the flying brickwork coming through the windscreen).
If you are not aware of how the machine works you don't know which decisions are dangerous. If you understood what the "safeties" actually *did* rather than just knowing they are *there* and can be *reset* when a problem happens you could make an informed decision about taking that action.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
What I have always found most ideal in complex programmable systems where there are consequences from mistakes is for the machine to express what it has been programed to do in some other nomenclature than it was programmed by the user to the user. Maybe you enter instructions in some sort of BASIC like script. The machine should answer back in some COBOL like syntax and let the user confirm this expression matches their intent.
This provides a good sanity check all around. It indicates the machine has parsed the instructions, if the user likes the response or that the machine does not properly understand the instructions and or the user made a mistake planning those instructions and does not agree with them when read back in different verbiage. This provides an opportunity to correct things.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Umm, no this one is pretty simple. Its not like an automobile engine or something where sudden shutdown could pose a hazard. When it comes to irradiating someone its always safe to shut the beam off. The response from the machine to no computer input should be turn off immediately. So it should be ok to have the computer fail.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
The staff are are fully aware that the machine will give a certain dose of radiation as part of its normal operation and the safety is there to prevent the dose going above a pre-programmed level. Or at least they would be in the UK.
What I would dearly love to know is how anyone thought that the appropriate thing to do would be to devise a protocol which involved resetting the safety given that it is inconceivable that the person who proposed such a protocol and the people involved with following it were unaware of the risks.
I'm sure things like this will only get less common now that we're giving these guys particle accelerators.
Since we eventually even drive vehicles effectively on "automatic," it seems to me that even better would be a two-keyed system that requires two users. Interaction is usually helpful in avoiding mistakes.
Naturally.
Since I'm quite sure that it is impossible for any human to completely understand the laws of physics. And then there would be no-one to cause those automobiles accidents.
For any dose above normal, two separate keys should have to be turned, separated in time by 30 minutes (so if a hospital was stupid enough to give the same person both keys, they have a half hour to think). Any dosage above normal should require being entered three times.
Perhaps the machine could also provide some sort of simple video game to entertain the patient while everyone's waiting on the 30-minute lockout. Of course, it would have to get easier toward the end, as the brain damage from unchecked bleeding accumulates...
seeing as you are a radiologist or similar, could you please help answer the following question/s.
you say that a detailed image of the pelvis requires a higher power level than for an image of the lungs, but is it an order of magnitude difference or more?
and is this difference still within the amount that is reasonably expected to not cause harm. i guess we're dealing with photons with enough energy for a single photon to cause damage to dna (or something essential) that would be sufficient to cause cancer or ultimately kill.
if this assumption that a single photon can kill is true, then probabilistically speaking how do you draw the line? i suppose you want to use a power level such that contrast in the imaging gives a greater chance of benefit, so stop at the point where extra power does not result in epidemiologically improved chances of diagnosis of a disease with a comensurate significance and chance of treatment. or alternatively use the minimum power that produces an image that is shown to useful in diagnosis.
thats quite a few baynesian probability relationships. is it actually done this way in RL? eg, is the power used for a CT (for a given tech sensitivity) set at the level that is supported by epidemiological data to be the point which gives the maximum benefit ? are there multiple maxima/minima? and what does this parameter space look like ?
i hope you can shed some (non ionising) light on this discussion.
Ah /., home of those without any reading comprehension.
My assertion was that people are responsible for deaths by car, not the cars themselves. Are you arguing with that point?
Then, my second statement was my amazement that stupid people who drive AREN'T killing each other off.
So where the fuck do you see me claiming that car accidents only kill stupid people? Oh, and then you bring up drunk driving... a stupid act if I ever saw one.
He said (well, implied) that the assert statement is a bad thing, because if the code that shuts down the machine fails the assert, it won't be shut down properly. Meaning, ejasons thinks it's best not to find a BUG in the code that shuts down the X-ray. Which is NOT HOW IT WORKS. And it terrifies me that he thinks so.
I'm not even sure who you think you're responding to. I think you're agreeing with me without meaning to.
ResidntGeek
You'd move more of the complexity into the system. Say adding an x amount of lines of code and thus an y amount of bugs, or something like that. Engineering as a solution has its own drawbacks.
"I'm not much interested in interoperability. I want substitutability. I want to be able to throw your software out."
Not necessarily. A lot of the time the complexity simply isn't needed, and is only there because somebody "thought it would be a good idea". Even when the complexity is necessary, putting it into the system means it can be managed whereas leaving it to people who are not specialists in the field leaves it unmanaged (as seems to be the case here -- the specialists involved were specialists in the wrong field [1]). Sure, if you can't safely automate it then you're going to need a human in the system, but if that's the case and it's a safety critical system then you need a specialist human, not a non-specialist.
[1] They were medical specialists, not specialists in operating this piece of equipment.
Quidnam Latine loqui modo coepi?
Realtime systems can't fail, and, if they do, they need to handle it. Aborting abruptly (is there any other way to abort?), which is what asserts do, isn't an option.
Go back to coding your web pages...
It pains me to see a good post using the word "leverage" in such a bad way.