I've been critiqued for posting in too gloomy a manner for some's taste, even those who like me are in the Medical Informatics field. For example, in the Feb. 2013 Kaiser Health News article "Health Technology’s ‘Essential Critic’ Warns Of Medical Mistakes" at http://www.kaiserhealthnews.org/stories/2013/february/18/scot-silverstein-health-information-technology.aspx:
... Many say he comes on too strong. Even admirers cringed when he began blogging about the 2011 death of his mother, which he blames in a lawsuit on a computer error that allegedly caused Abington Memorial Hospital to overlook a key medication. (Both he and the hospital said they couldn’t comment on a pending suit.) Personalizing his campaign, some thought, made him seem less objective.
Of course, if a close relative of these unnamed "many" were killed by, say, a drunk driver (something this unobjective group of mothers takes seriously: http://www.madd.org/), or if their child were abducted and decapitated (http://en.wikipedia.org/wiki/Murder_of_Adam_Walsh), or if something like this event (https://www.youtube.com/watch?v=55XJivhjB4U) happened, their response would surely be "oh well, stuff happens, let's all be 'objective', not 'personalize' things, not advocate with our personal stories, and above all, be happy!
I really do admire the unnamed "many" for their ability to detach, so am presenting the following story of "anecdotal" patient harm to a child in a pediatric ICU in the spirit of happiness, joy, and Mother's Day love!
Here's the event we should all be happy about, reported via FDA - I note the FDA's said these devices are not "sufficiently risky" to warrant a high level of their attention even though they secretly admitted in an internal memo that there's no way to really know te true level of risk and harm (http://hcrenewal.blogspot.com/2014/04/fda-on-health-it-risk-reckless-or.html), so clearly they're all a really jolly bunch:
FDA MedSun report
Type of device: medical device data system
Device brand name: PowerChart
Device manufacturer's name: Cerner Corporation
Date of this report: (mm/dd/yyyy) 03/04/2014
Describe the event or problem:
Medication Error. This event was related to Health Information Technology. Specifically, the manner in which the system processed an order for free water replacement. Order was intended to be 20ml/hr for 6 hours for a total of 120ml. It was a 1000 ml bag so first they put 20ml/hr which would have defaulted the infuse over time to 50 hrs. They tried to change the infuse over to 6 hours which then changes the ml/hr rate to 167 ml/hr. They did not notice this had changed.
Well, that's WONDERFUL!! :-) that the computer recalculates the flow rate for them when they change the infusion time, by paternalistically assuming that's what they wanted to do - change the RATE of infusion - when what they actually did is manually change the TIME (duration) of infusion.
How LOVELY of some programmer to have given them this FANTASTIC convenience!!
|Aren't computers wonderful!!!|
Even the following should not be cause for ardent technophiles to wipe the smile from their downside-ignoring faces!!
... They did not realize that they needed to go into details tab to show the time frame so the patient got 167ml/hr instead of 20ml/hr for 6 hours.
How obvious!!! Every doctor, nurse, medical student and janitor knows from time immemorial knows you have to go into the detail tab to show the time frame! (Smile)
... Order was verified by pharmacy and administered at that rate via peripheral IV. After approximately 1L of fluid had infused, patient showed seizure activity. PICU (pediatric ICU) team called to bedside. Treatment provided for seizures and critical sodium and potassium.
Awww ... some seizures and critical sodium and potassium levels in the PICU. Awww.....too bad!!! We should be happy anyway! For if this child died...the sacrifice would have been WORTH IT for the betterment of electronic medical records worldwide, and the parents no doubt would be flattered and joyous about their contribution to computing science. After all, how better to figure out how to make this technology work??
After all, it takes a few broken eggs to make an omelette, and a few bumps in the road (like grave mounds) should be of little concern.
Because, remember ... w.e. c.a.r.e!
|i c.a.r.e!!!! As at U. Arizona Healthcare System, let's only use Happy Words with our patients about these systems! (click to enlarge, see http://hcrenewal.blogspot.com/2013/10/words-that-work-singing-only-positive.html )|
Further, we should use only Words That Work to describe the wonders of these systems in their current state!!!
|Some flowers from Cerner CEO Patterson to momma to make up for her little baby having seizures and critically deranged potassium and sodium levels from those big, bad doctors' EHR mistake!|
... The Cerner powerchart software system has functionality for continuous medications/fluid ordering that does not prevent "user error."
Ut oh ... Looks like I'm going to have to be a sourpuss for just a moment and re-introduce the nasty, ill-tempered, non-objective idea of what the dastardly National Institute of Technology and Standards (NIST) calls "use error" (as opposed to "user error", A.K.A. "Blame the User", http://hcrenewal.blogspot.com/2011/10/nist-on-ehr-mission-hostile-user.html):
... The EUP (EHR usability protocol) emphasis should be on ensuring that necessary and sufficient usability validation and remediation has been conducted so that use error  is minimized.
 “Use error” is a term used very specifically to refer to user interface designs that will engender users to make errors of commission or omission. It is true that users do make errors, but many errors are due not to user error per se but due to designs that are flawed, e.g., poorly written messaging [or lack of messaging, e.g., no warnings of potentially dangerous actions - ed.], misuse of color-coding conventions [see below], omission of information, etc.
Awwwwww....aren't I just mean and non-objective?
That mean doctor Silverstein's just not happy and objective!! Bad, bad, bad man!
... When the provider orders the fluid, example is D5W, the screen opens to a "continuous details" ordering window. Within the screen, the ordering provider is presented with a preselected bag volume and type of fluid with a brownish background. They have the ability to modify bag volume but it was made this color to discourage that change by Cerner.
Golly gee! There's something to be happy about once again! Brown, the universally-understood color, in any language, means "Warning, do not change this value, it could kill someone!!!" See how GOOD this technology really is!!! Why use alerts and confirmation dialogs when a mere COLOR like brown suffices!!
... The rate and "infuse over" fields are a yellow color to show that they need to be completed. The intent [of the programmer, clearly an expert in human-computer interaction and communication by color and smoke signals - ed.] is for an ongoing continuous fluid and not to limit the time.
Golly Gee Times Two! Yellow, the absolutely universal color for "Warning, you need to complete this to prevent killing someone!"
|Yellow! Don't you just think every time you see this color that "warning, you need to complete data entry to avoid killing someone? Who needs WORDS?|
It's all so CLEAR!!!!
... Providers can misinterpret this field to mean the length of time they want the order to infuse over, when the system intent for that field is to be the system-calculated length of time until the next bag supply will need to be sent to maintain the continuous infusion.
See how simple!!!! Isn't it OBVIOUS!!!!
The completed fields turn white. Cerner does not have an intermittent fluid administration order [who the hell needs that, says Cerner and the hospital executives who bought this package for the PICU!! Never a need for that in ICU's!! - ed] so providers are expected to go to a second tab, the "details" tab, where they have the options for identifying the duration of the infusion in terms of # doses or time. If the provider does not have awareness of this intent and modifies the "infuse over" field from the "continuous details" tab, they may inadvertently order a higher rate than intended.
Ha ha! Those silly doctors can't even figure out a simple thing like that!! What stooges they are!!
See how much FUN health IT problems can be? After all, in this ANECDOTAL case, all that happened was:
The device(s) may have caused or contributed to: Potential for patient harm, Serious Injury
But nobody died of this particular problem (that we know of), so this technology is SAFE!!!!
Happy mother's day!!!
Additional not-so-funny thought: depending on brown, yellow etc. instead of clear, written alerts/warnings, plus the fact that the system likely "knew" the weight of the child and should have alerted that the infusion of a liter was a very dangerous thing, reflect Bad Health IT on its face:
Bad Health IT ("BHIT") is ill-suited to purpose, hard to use, unreliable, loses data or provides incorrect data, is difficult and/or prohibitively expensive to customize to the needs of different medical specialists and subspecialists, causes cognitive overload, slows rather than facilitates users, lacks appropriate alerts, creates the need for hypervigilance (i.e., towards avoiding IT-related mishaps) that increases stress, is lacking in security, compromises patient privacy or otherwise demonstrates suboptimal design and/or implementation.
Had I been a pre-marketing tester of this system working for FDA, those fluid-ordering characteristics would have been changed before the system would have been released to market.
Oh, wait ... there is no premarketing testing process for health IT, and FDA, via advice from the FDASIA committees as in the linked FDA-related post above, writes that none is really needed.
And who wants to damage TRUE INNOVATIONS like this - turning something that takes 5 seconds for a clinician to write, "D5W, 20 ml/hr x 6 hrs" (meaning dextrose 5% in water, 20 milliliters per hour for 6 hours) into a cryptic and muddled exercise with tabs, colors and numerous caveats - via regulation?