Slashdot Mirror
Kludgey Electronic Health Records Are Becoming Fodder For Malpractice Suits
Lucas123 writes The inherent issues that come with highly complex and kludgey electronic medical records — and for the healthcare professionals required to use them — hasn't been lost on lawyers, who see the potential for millions of dollars in judgments for plaintiffs suing for medical negligence or malpractice. Work flows that require a dozen or more mouse clicks to input even basic patient information has prompted healthcare workers to seek short cuts, such as cutting and pasting from previous visits, a practice that can also include the duplication of old vital sign data, or other critical information, such as a patient's age. While the malpractice suits have to date focused on care providers, they'll soon target EMR vendors, according to Keith Klein, a medical doctor and professor of medicine at UCLA. Klein has been called as an expert witness for more than 350 state or federal medical malpractice cases and he's seen a marked rise in plaintiff attorney's using EMRs as evidence that healthcare workers fell short of their responsibility for proper care. In one such case, a judge awarded more than $7.5 million when a patient suffered permanent kidney damage, and even though physicians hadn't neglected the patient, the complexity of the EMR was responsible for them missing uric kidney stone. The EMR was ore than 3,000 pages in length and included massive amounts of duplicated information, something that's not uncommon.
While there's problems scheduling at the VA and getting in to see a doctor, they've had EMRs for 50 years. It's all online and easy to search.
Really. ZOMG! LAWYERS!
In the case mentioned, the patient suffered permanent damage because he did not receive appropriate care. It doesn't really matter whether it was the doctor, or a nurse, or improperly maintained equipment, or a frickin' janitor's laziness, or the EMR--the hospital is responsible for providing appropriate treatment to patients.
Yes, I'm sure there's a small number of sleazy lawyers who will latch onto harmless mistakes in the EMR to try to invent a case where there is none, just as they have always done with all mistakes, long before EMRs existed.
But the real problem is not the lawyers. The real problem is the byzantine UIs of these monstrous "Enterprise Medical Record" systems, if you get my pun ;-) After all, some data entry mistakes do cause actual harm.
I haven't read the relevant regulations, and I hope I'll never have to -- I'm not sure I have that much time left on Earth -- but I'll bet that there's almost nothing concrete in them about usability.
EMR capture happens in a time- and attention-constrained environment. Any competent development house should be doing task analysis to ensure that their system meets the time constraints found during a doctor visit.
EMR search -- oh, I don't even want to start thinking about this. The relevant tasks could be anything from an auditor fine-toothed-combing records for an insurance claim, to an EMT trying to get a blood type or allergy info before a victim bleeds out.
I've consciously avoided jobs where my code is responsible for life-and-death decisions. The problem, I guess, is that too many other good people have made the same decision, and there aren't enough good people available to do what needs to be done. I'm not sure what to do about this.
This is another example of government not doing their job. We have needed a single, comprehensive standard for the form and format of Medical Health Records (MHR) for a long, long time. They needn't mandate specific products, but those products should all comply with one, universal and constantly-updated standard. But, nooo! We have to let Republicans exercise their fantasy that government can't do it, it has to be the "private sector" (in other words, reward the people who pay them to sit on their hands instead of solving problems). What was once a rich and vibrant marketplace of products has narrowed down to one industry leader who does NOT have patient information reliability and quality on their list of priorities.
We should have seen thermometers and scales and manometers and oxygen-level gauges (all standard tests on any pnysician visit) automated to send the information to the currently-opened patient record in the examining room over secure WiFi a decade ago...insofar as I can see, there are still no such products. These Electronic Medical Record (EMR) software products (especially from the "leader") are designed to impose the maximum load on professional staff, because it's easier to code them that way. I'm surprised they aren't designed to require staff to use green-screen, text-only monitors!
So, yes, lawyers are making money. And, I'm glad those lawyers are starting to attack the EMR system providers. But the Department of Health and Human Services (and, truth be told, the Republicans who think that underfunding government agencies to cripple them is a good idea) are a root cause of the problems..
If physicians have to keep updating the patient's age, then something is wrong. But good news! We have these new fangled things called computers! These computers can calculate the patient's age on the screen at the time the record was entered (by doing this patented new thing called date subtraction to get number of days and thus the age!).
I'll see your senator, and I'll raise you two judges.
This is one of those rare instances where the Feds CAN make a difference by mandating specific medical record formats, import and export of data, standard reporting functionality, etc.
Many EMRs are in "island" systems that you can't easily get the data out of or bring data into, stranding important information and raising the costs of moving from provider to provider. How many fucking times have you filled out the stupid medical history forms?
Where the data is kept is up for discussion, but the format and content should be standard across all systems.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
For those that like to RTFA, It might have been
http://www.computerworld.com/a...
or
http://www.healthcareitnews.co...
Legitimate court rulings that demonstrate real harm as a result of bad software design are a means of achieving change; the alternative is that the providers get to hide behind the claim that they are complying with all the regulations - despite providing a product that doesn't work. Whilst much lawyering is unhelpful, the reality is that SOMETIMES it does enable good things to happen!
It's not limited to electronic medical records -- it's the insane user interfaces in modern software that were obviously coded by a developer who never has to use the systems for work.
I'm not a doctor, but know many. Most of them are not happy at all with the shift to EHR, for the reasons cited. Most of the doctors I see for actual visits are attached to the large state university hospital nearby, and so they all use the same EHR system (I think it's McKesson.) The doctors often spend half the visit clicking through mandatory screens and cursing the computer. The insanely complex workflow is the problem. I work in airline IT, and the main reservation system providers do absolutely everything in their power to eliminate duplicate keystrokes and actions when booking a reservation or doing a check-in. It's optimized so much that agents trained on the system can do the entire transaction in real time while talking to the customer, with very few pauses. The real expert agents can eliminate any delays by using the terminal provided they've memorized the insane commands to do various tasks. The main reason for this is that airlines are insanely stingy, low margin businesses. Any delay for the agent decreases customer throughput and increases the chance they will need to put more agents on a shift.
In the IT world, I can't count the number of crappy end user applications I've integrated, where I've just shaken my head and thanked $deity that I don't have to use them for my job. And also, don't forget the ITIL-driven service desk and change management applications. The big vendors (Remedy, CA, etc.) will sell a company the "cheap" out-of-box package that implements _every single feature_ but charge them millions to customize it. Most companies don't bother, and you end up with systems where you spend almost an hour filling out a change request.
I'll bet most of this problem stems from that "out of box" deployment syndrome...where you get a product that technically functions, but is suicide-inducing unless the customer pays for customizations, in the "light a bag of money on fire" realm. How many hundreds of integration points does an EHR product have? Prescribing systems, records storage, insurance company connections, etc, etc, etc... Doctors must hate it because they can't just order a PA or nurse to do their transcriptions for them like they used to.
Sorry for double posting, but one other thing to note is this...behind all the whizzy new web interface screens, many EHR systems are based on some of the oldest, creakiest standards imaginable, including a programming language-and-database combo called MUMPS. Look it up - it's positively ancient, and it should be obvious why they have trouble finding people willing to specialize in writing code for it.
The VA system has one of the oldest EHR implementations in the country, and even though the GUI is semi modern, the guts of the system are this MUMPS mess. (You can download most of the source code for the system online since it's a government created product. The language was designed in an era where preserving memory was the only concern, all variables are global (!!), and keywords can be abbreviated to one letter...that should tell you enough about MUMPS right there!) Any industry you can think of that has used computers long enough has problems like this -- my area of expertise (airline systems) has standards going back 40-50 years, from when every single byte sent down a communications link was precious.
Most systems like this do a very good job of hiding the complexity from the end user, but it also reduces the amount of spontaneous change you can introduce. For example, in airline reservation systems, no one would dare change the layout of the mainframe emulator screens because so many up-level systems depend on scraping that data exactly the same way they've been doing it for 30 years. Everything an end user sees passes through many layers on the way down to the core, and systems like this are built on nested layers of wrapper code.