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.

Comments

Usability metrics, anyone?

[jeffb (2.718)]

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.

Re:Usability metrics, anyone?

[tlhIngan]

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.

The problem is not just that, it's that those companies don't actually pay that well, either.

Writing safety-critical code is not hard - there are plenty of guidelines on what you should and shouldn't do (e.g., memory allocation is verboten). It is a specialized skill, and the job should really be done by people who have the requisite training and knowledge and often even certifications (e.g., engineering certifications).

The problem is this is very specialized, and it costs a lot of money because those people know they are taking on professional risk (not unlike many other engineers - civil, mechanical, etc., who design stuff that could fail and take lives). Of course, the IT companies behind it all? They're not willing to pay for that enhanced risk - they're going to pay market rates.

Well geez, if I'm going to be paid market, I'm not going to put my name on anything to certify because that's a specialized skill that gets paid for. (hence, things like "approved drawings" which mean some engineer actually reviewed it all and put their stamp and certification on it).

There's a reason why NASA's software for the space shuttle costs 5+ times what a normal software project of similar size and scope would cost. It's not incompetence on NASA's part, and it's not just the extensive documentation and paperwork that goes along with it, but the fact that writing safety-critical software is hard, specialized, and for every line of code, probably generates a book's worth of documentation proving it fails safe, who wrote it, who changed it, who reviewed it, etc.

Yeah. Most IT companies for health don't even come close.

HHS Asleep At The Switch

[CAOgdin]

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..

Re:HHS Asleep At The Switch

[ColdWetDog]

The entire issue needs to be readdressed (and won't be). The 'old' system was pretty bad - spotty, inconsistent data that was impossible to read. But it was quick and easy. Worked OK if what you were doing really didn't make much of a difference, as was typical for medicine until fairly recently.

In the US, there are two overriding issues with the EHR - getting a bill out and getting a bill out. Everything else is really secondary. To get a bill out one has to follow a byzantine series of steps and (poorly documented, inconsistent) guidelines on what needs to be there and what doesn't. These guidelines change from time to time and from place to place (but we won't get into that here). The data needed for a physician bill includes a laundry list of things that are very likely completely irrelevant to patient care but have been stuck in the pile because 'more is better'.

And that was before EHRs became mandated.

Then, CMMS (Centers for Medicare and Medicaid Security) was told by our Congressional Overlords that EHRs were good and, more important, would save money and flay the beast of fraud and waste. So with little further ado they created even MORE guidelines and rules for billing and for just being an EHR (the "Meaningful Use" rules).

Then, they put a fairly tight deadline on this. For the hundreds of smaller companies in this business and the thousands of small hospitals in the country this has been a pretty much unmitigated disaster. Crappy legacy systems bolted on to insane "Meaningful Use" systems. Vendors buying out vendors and slapping disparate and inconsistent bits together (our idiot vendor, Healthland, has the nursing home module running under Net 1.1, the main module running under 1.0 and has managed to rig it so that you can't run both on the same machine without using VMs). User Interfaces straight from the 1990's. Work flows that are a hybrid (that's the nice word) of paper and poorly designed computers.

It's kinda like trying to design an airplane using a modern computer system and an abacus.

This unholy mess has been forecast with unerring accuracy. Our malpractice carrier flat up told us that we will probably get sued on the basis of EHR mistakes. The system is going to go through a decades long period of shakeout and Sturm und Drang while this gets sorted out.

Sucks to be us, I suppose.

Re:HHS Asleep At The Switch

[sribe]

Really? And let's say that instead of a normal adult visit, we're talking about a pediatric visit for a child or infant with a congenital heart defect. Will the oxygen-level gauge transmit whether the reading was from a finger or a toe? Will the manometers also transmit: 1) what side the pressure was taken from, 2) whether the pressure was taken from the arm or leg, 3) whether the patient was sitting, standing, or supine?

Yeah, that's the thing. When the /. crowd starts saying there should be a "single standard" for medical records, those of us who actually work in the industry just roll our eyes... You have no idea of the complexity of the problem, nor of how fast things change on the cutting edge of the specialties.

Re:Don't fix what ain't broke

[sandytaru]

Army hospitals too. My father worked in the records department of a 13 story giant Army medical center in the '80s and '90s. While the records themselves were fat paper folders, much of the patient information was kept in a database (which I think by the '90s was an AS/400) - and part of the job of the record keepers was to take the new information from the doctors and update the patient files in the database. So while the historical record was all on paper, the most up to date stuff was in the database where it belonged. They had about 30 people doing this kind of data entry full time for a hospital of 100 doctors.

Why store the patient's Age instead of Birth Date?

[DickBreath]

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!).

Feds

[sycodon]

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.

Re:Feds

[Enry]

That's an ICD-10 code, and the Feds don't generate them, WHO does.

If anything, codes like that standardize care, reporting, and billing. This way, two systems that are otherwise incompatible can have the following conversation:

What was the cause of injury? Sucked into an airplane engine
What treatment did the patient receive? (insert set of ICD codes for treatment)
Insurance company pays rates based off the ICD codes, done.

There's 68,000+ codes in ICD-10. There's going to be a few odd ones in there.

Re:Feds

[ColdWetDog]

Oh, the Feds have made a difference all right. Not the good kind. Yes, they've mandated that the systems 'talk' to each other but then watered things down to where all they have to do is talk to some third party reporting system. Sometimes. But mostly the Feds have spent their time and dime making sure that EHRs collect all sorts of useless data and follow clinically irrelevant workflows. Then they spend their time changing the rules in mid stream.

So the vendors, especially the smaller ones, spend the majority of time trying to keep their systems in compliance and avoiding doing anything clinically useful. The big systems (Epic, GE, McKesson, etc) have their own issues but generally have the resources to deal with the idiots. Even amongst the big guys there is very little work done on how to integrate all of this fancy data into something useful for the clinician and patient. It's mostly just capturing everything that every happened.

And printing it out on paper.

Re:Feds

[flink]

There are already industry standards for EMR

Common Document Architecture (CDA) - provides formats for the interchange of data built on the OASIS schema.
Integrating Healthcare in the Enterprise - defines profiles for implementing technologies in an interoperable manner.
Open eHealth - open source baseline implementation of the above.

That's just for clinical data. There are a whole other set of standard for financial/claims records (X12) and pharmacy records/scripts (NCPDP).

The problem is that medical data is pretty complicated and often the context of the document is as important as the content. You almost always have to massage documents coming in even if they are ostensibly formatted to a standard you consume. You have to normalize units, make sure all the fields are part of the subset of the standard your system supports, etc.

And that doesn't even begin to get into tracking patient consent, tracking identity across multiple orgs, depts, and visits (MPI,PIX/PDQ), plus access restrictions and emergency access exceptions.

Re:article is flamebait

[fredrated]

In other words, shitty software strikes again. Civilization won't end with either a bang or a whimper, but will be taken down by an avalanche of garbage software. Hardly a day passes where I don't want to club some moron that couldn't program their way out of an open paper bag.

Strong court judgements force change

[Bruce66423]

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!

Complex workflows + doctors = disaster

[ErichTheRed]

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.

Oh yeah, don't forget MUMPS

[ErichTheRed]

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.

Re:Oh yeah, don't forget MUMPS

[flink]

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.

When I first started in the healthcare industry almost in 1997 as an intern, my first job was writing MUMPS interface routines to extract referral data for a web interface. The system in question was running on a VAX/VMS cluster and ran a major midewestern HMO's operations.

The funny thing is when NoSQL became a buzzword a few years ago, thanks to my exposure to MUMPS, I instantly recognized it for what it was: 70's-era hierarchical database technology, repackaged for a new generation.

Re:Oh yeah, don't forget MUMPS

[podmate]

Epic is also built on top of MUMPS or 'M' as they call it. Epic uses a document database called Cache as its backend. The GUI is a web frontend.

Allscripts uses a subset of an obscure language called Arden Syntax. It is kind of like JavaScript but can do far less programmatically and often times will break the OO mold in weird ways. But, at least you can extend a Sunrise build as opposed to an Epic build which is virtually static.

I am currently working with an EMR built on top of a CRM tool. Talk about something that is a f'ed up. Oh baby jeebus, why!!!

Re:Don't fix what ain't broke

[xanthines-R-yummy]

I actually am a medical doctor and I can say that the VA EMR is very very good. It's not as shiny or pretty as some others out there, but it's solid, easy to use/learn, interconnected with every VA hospital and it's the same at every VA hospital. The scheduling problems largely revolve around lazy government employees (I'm a govt employee, so I can say that!) and trying to get doctors to work in the VA system. They only recently brought the salaries for physicians, but only for new hires, IIRC. I'm sure THAT's good for morale....

I'm also an armchair bioinformaticist (or whatever) and have seen the coding and modules behind EPIC, one of the most popular and widely-used EMRs around. It IS kludgey! I forget if the inpatient or outpatient systems came first, but the second had to be kludged in. THEN, when you factor in the very widely used radiology information system (PACS) you have to kludge that in. Then you have pathology and lab medicine using an entirely different system (CoPath, Soft, PowerPath, etc) you have to tie that into the EMR and PACS. Sometimes pathology and lab medicine use two entirely different systems, even though they're in the same department!

Yes, it's a mess!