At "Transplant Team at Univ. of Pittsburgh Medical Center Missed Hepatitis Result" I wrote about a kidney transplant gone bad at UPMC that may have been due to a computer "glitch."
Now Allegheny General Hospital in Pittsburgh has suffered a "glitch" that shut down their entire health IT system for approximately 12 hours:
One might think the vendors of mission critical hospital systems would check their upgrades better before roll out to hospitals teeming with real, live, sick patients.
Of course, patient care was unaffected. It never is when a "glitch" occurs, despite the massive inconvenience to doctors who actually have patients to care for, and the need for backloading paper data - with inherent opportunity for error - after the computer system is resuscitated.
At a Jan. 2011 post "Orderless in Seattle: Software glitch shuts down Swedish Medical Center's medical-records system" I observed:
Same in this Allegheny General Hospital case:
If patient care is never affected by shutdowns even as long as an entire working day, one wonders why the tens or hundreds of millions of dollars spent on these systems is needed in the first place...
I have a solution.
Cloud computing!
-- SS
Now Allegheny General Hospital in Pittsburgh has suffered a "glitch" that shut down their entire health IT system for approximately 12 hours:
Allegheny General Hospital's records system back online
By Pittsburgh Tribune-Review
Wednesday, May 25, 2011
Last updated: 10:26 pm
Allegheny General Hospital's electronic medical records system was online Wednesday afternoon after a morning shutdown caused by a glitch in a vendor's computer software, a spokesman [Dan Laurent] said.
... The hospital's system underwent a routine upgrade during the weekend, Laurent said. Staff shut down the system about 5 a.m. Wednesday after noticing it was running too slow. New Jersey-based software vendor Allscripts made repairs, and the system was online by 5 p.m., he said.
One might think the vendors of mission critical hospital systems would check their upgrades better before roll out to hospitals teeming with real, live, sick patients.
Of course, patient care was unaffected. It never is when a "glitch" occurs, despite the massive inconvenience to doctors who actually have patients to care for, and the need for backloading paper data - with inherent opportunity for error - after the computer system is resuscitated.
At a Jan. 2011 post "Orderless in Seattle: Software glitch shuts down Swedish Medical Center's medical-records system" I observed:
There's that word "glitch" again that I see so frequently in the health IT sector when a system suffers a major crash that could harm patients. Why do we not call it a "glitch" when a doctor amputates the wrong body part, or kills someone? ... the shutdown likely affected about 600 providers, 2,500 staffers and perhaps up to 2,000 patients, but no safety problems were reported.
As I've noted at this blog before, it is peculiar how such "glitches" never seem to produce safety problems, or even acknowledgments of increased risk.
Same in this Allegheny General Hospital case:
... [spokesman] Dan Laurent said staffers took drug and lab orders on paper forms, and that patient care was not affected by the shutdown.
If patient care is never affected by shutdowns even as long as an entire working day, one wonders why the tens or hundreds of millions of dollars spent on these systems is needed in the first place...
I have a solution.
Cloud computing!
-- SS
