Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Businesses Medicine Privacy The Almighty Buck The Courts

Kludgey Electronic Health Records Are Becoming Fodder For Malpractice Suits 184

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.
This discussion has been archived. No new comments can be posted.

Kludgey Electronic Health Records Are Becoming Fodder For Malpractice Suits

Comments Filter:
  • by Enry ( 630 ) <<ten.agyaw> <ta> <yrne>> on Tuesday April 14, 2015 @10:07AM (#49470507) Journal

    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.

    • Re: (Score:3, Insightful)

      I don't think the VA is a model other healthcare providers should be trying to emulate.
      • by Enry ( 630 )

        From an EMR standpoint? I find that attitude disappointing and shortsighted.

      • Maybe one should look at Kiaser Permanente? Blue Shield? Anthem? Ka-Ching.
    • by sandytaru ( 1158959 ) on Tuesday April 14, 2015 @10:30AM (#49470727) Journal
      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.
      • by Enry ( 630 )

        Nice. I worked for the VA for a few years in the early 90s, which is why I know at least how they operate. I think the bigger issue in the future is going to be translating records between institutions, just like the DoD and VA can't easily move records. When each system grows organically over time and doesn't think it'll need to communicate with others, it creates a huge problem when you do.

        • by weszz ( 710261 )

          companies like Epic CAN, but OMG it costs a crapton for you to interface with them if you aren't on them already... and moving to them is incredibly expensive. it's a 15-20 year+ company decision to go with one of these companies.

          • EPIC itself is kludgey and cumbersome, but it somehow works. And yes, it's outrageously expensive.

          • I'll second this.

            Having worked on an Epic migration (Inpatient and Outpatient), I can say that Epic is a frigging mess. Massively expensive, almost totally inflexible by design, crap reporting (love reporting against a document database for up to the minute data), confusing to use and even more confusing to modify.

            Epic training in no way covers how you will actually use the product.

            Don't get me started on the Epic employees. Virtually every employee that came on-site was fresh out of college and only h

            • by weszz ( 710261 )

              It happens because Epic burns out employees. Give them good money out of school and work them till they drop.

              Still seems a step up from other systems right now.

    • by Anonymous Coward

      As someone who works for another government agency and has to read their records regularly... Their records are some of the most duplicative and annoying to read out of all EMRs. They frequently list medications a patient took a decade ago! They dump basically every single bit of medical evidence into every visit. Frequently every visit has uncompleted screenings for depression, PTSD, and alcohol abuse. There are other programs that are worse, but the VAs records are awful.

      We've noticed the copy-pasting, bt

      • by Enry ( 630 )

        EMRs are dangerous in the hands of lazy doctors,

        I'll grant you that. I think you'll see that over time doctors get better at it especially as older doctors retire and newer ones take their place. My daughter's pediatrician walks around with a tablet PC that he drops the information into and has already recorded things like the pharmacy we go to. "Still go to the CVS on Boston Road? Ok, it'll be ready when you get there"

        and having seen most of the programs available and their output, a lot of it is because of lazy programming that makes simple tasks difficult.

        That's just bad design. When I worked at the VA there was a good bit of discussion between developers and the people that actually u

    • by xanthines-R-yummy ( 635710 ) on Tuesday April 14, 2015 @12:05PM (#49471735) Homepage Journal

      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!

  • by sribe ( 304414 ) on Tuesday April 14, 2015 @10:15AM (#49470571)

    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.

    • The real problem is the byzantine UIs of these monstrous "Enterprise Medical Record" systems, if you get my pun

      No, but I'm sure it's terrible.

    • by fredrated ( 639554 ) on Tuesday April 14, 2015 @10:53AM (#49470983) Journal

      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.

    • by Bruce66423 ( 1678196 ) on Tuesday April 14, 2015 @10:54AM (#49470989)
      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!
  • by jeffb (2.718) ( 1189693 ) on Tuesday April 14, 2015 @10:16AM (#49470595)

    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.

    • by weszz ( 710261 )

      A big problem is most of these tried to duplicate the paper form that healthcare is used to.

      Computer forms shouldn't mimic paper as the workflow changes by just putting it on a computer... Add to this some crappy other things, like a McKesson program that doesn't show you all the information if the monitor's resolution is under x900... it just cuts it off and doesn't bother to tell you that you can't see everything. Was a very happy day when that was discovered... replacing thousands and thousands of monito

      • I would love an EMR that was as efficient as a paper record.
        • I agree. I know a physician who laments taking a mere HOUR to dictate the day's procedures, with the paper charting completed at time of visit. EMR takes 10x longer according to this physician.

        • I would love an EMR that was as efficient as a paper record.

          I think you probably mean, "I would love an EMR that makes my job easy." This is usually heard from doctors who are upset they have to actually take five minutes to put in what they mean and cross the t's and dot the i's of people's medical care rather than rattle off something and power sign whatever the transcriptionist types* letting the file room, techs, nurses, etc do hours of work to bring them a document and ask them to cross and dot stuff.

          In many other cases, the computer system is messed up because

    • by tlhIngan ( 30335 ) <slashdot@worfCOLA.net minus caffeine> on Tuesday April 14, 2015 @10:37AM (#49470793)

      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.

    • by sribe ( 304414 )

      ...but I'll bet that there's almost nothing concrete in them about usability.

      It's worse than that: 1) There's not even anything at all regarding usability, not even the most vague amorphous pablum; 2) Many of the regulations have the unintended side effect of pushing things toward poor usability.

    • Any competent development house should be doing task analysis...

      Of course they do usability, duh.

      But every use case is different: Routine visit? Emergency with patient not breathing? Surgery? There are endless different scenarios to be considered and tons of data that has to be captured.

      • by jedidiah ( 1196 )

        Then you run through every use case. Confer with the actual users to see what those are.

        Medicine is not the only field where you could have a highly complex system deployed that doesn't achieve anyone's requirements. I've seen that myself in banking (Fortune 500) and also in "startups".

        • by tomhath ( 637240 )

          Then you run through every use case. Confer with the actual users to see what those are.

          Don't even think about defining use cases unless you have a few hundred experienced clinicians working with you: dozens of different specialties of doctors, nurses, pharmacists, infection preventionists, various physical and occupational therapists, etc., etc.

          The list goes on and on and on. Now consider the variety of patients. Does the patient speak English? Is the patient psychotic and lying to you or violent? Do you even know who the patient is?

  • by CAOgdin ( 984672 ) on Tuesday April 14, 2015 @10:17AM (#49470607)
    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..
    • 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

      Why is that the government's job? Shouldn't that be the job of ISO, ANSI, or the AMA (all NGOs)?

      • Democrats burned 86 million dollars and a staff of hundreds on Obama Care web pages, when 3 students at Standford did the same job in two weeks. Ignoring MRI storage, a dusty Blade Server can hold all the medical records for planet earth for the next 20 years. These servers can be manned 7/24/365 by a 12 operator staff so that if someone trips over the power cable, it can be re-plugged back in before the backup batteries go flat. Doctors, if they want to get paid, perform certain tests, and procedures, in a
      • Why is that the government's job? Shouldn't that be the job of ISO, ANSI, or the AMA (all NGOs)?

        Because they failed. Standards organizations don't get involved unless the companies in that technical field want them to be involved.

        It looks like medical records companies don't want standards -- probably because they would prefer to seek an effective monopoly through proprietary standards. However, enforcing open standards benefits society and that's why government should be involved.

        Government doesn't

      • 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

        Why is that the government's job? Shouldn't that be the job of ISO, ANSI, or the AMA (all NGOs)?

        As far as I've seen, it's the same government employees attending ISO, ANSI and NIST forums. They are not functionally separate organizations.

    • by weszz ( 710261 )

      Which leader? McKesson, Epic, or Meditech? (I know there are others) but from my view of the world, it looks like Epic is taking over in the past 5-10 years.

      Epic does have a crapton of clicks for staff to go through, but McKesson is just outrightly terrible, buying up programs and then trying to mash them together... These two applications must be on the same computer. App A needs Java 1.4 and ONLY Java 1.4 on the PC. App B needs 1.6 and ONLY 1.6 on the PC, Go make that work out. (there are solutions like T

    • by sribe ( 304414 ) on Tuesday April 14, 2015 @11:14AM (#49471163)

      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.

      • by CAOgdin ( 984672 )
        Your ignorance of the issue is appalling. Yes, a single standard, so that vendors of software and equipment KNOW they can connect to existing systems without hassle and customization. The reason the HHS needs to do it, is a) they are the senior government authority with medical focus, and b) it needs to be open, not proprietary to be universally adopted.

        I suppose, with your rationale, we should have dozens of different standards with conflicting rules over the header of a TCP/IP packet...as we DID have
        • by sribe ( 304414 )

          Your ignorance of the issue is appalling.

          You're the one who is ignorant of the issue. I deal with it all the time. And, frustrating as it is, I, unlike you, am aware of the history of the various attempts, and the reasons they have failed. Primarily, you have absolutely zero concept of the overwhelming complexity of the data involved, how rapidly it evolves, and the cost to society if we retard that evolution via regulation. (The example I gave was a deliberately simple one, the simplest imaginable, so that anyone could understand it.)

          And, oh, by

  • by DickBreath ( 207180 ) on Tuesday April 14, 2015 @10:39AM (#49470801) Homepage
    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've seen several EMRs and I've never seen one that asks for patient age; it's always Date of Birth. And any one system won't request it a second time, the problem is when a hospital is using multiple systems that don't interface the EMR with each other.

    • You think you're funny? Laugh it up. An age? Simple subtraction, right? Not quite...

      Start with kids under an arbitrary cutoff limit (often customizable by HC org, department, and/or provider whose ages need to be given in months. Then you get bitching from neonatologists who want the age of kids under some other arbitrary limits to be displayed in days. This is for a relatively simple concept.

      Now, multiply the whole thing by about 25,000 concepts (many more complex than "age"), riddle the whole thing with m

    • Your comment is a testament to why EHR software are so bad. Because engineers with no knowledge or experience in the field of health care think they can simply decide to automate or standardize stuff, because of "things called computers", without knowing if said things should be automated or standardized. (also, four other engineers without knowledge in the field mod it insightful just like your comment here on slashdot, and consequently bad projects go ahead).

      So let me give you just one small reason (among

  • by EnempE ( 709151 ) on Tuesday April 14, 2015 @10:51AM (#49470953)
    For those that like to RTFA, It might have been
    http://www.computerworld.com/a... [computerworld.com]
    or
    http://www.healthcareitnews.co... [healthcareitnews.com]
  • by ErichTheRed ( 39327 ) on Tuesday April 14, 2015 @11:08AM (#49471119)

    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.

    • Just about every company needs to have some form of a "dogfood rule" that applies to ALL levels in the company - from the janitor to the CEO. You need to be actively using your product, and you need to prefer it above all others - even in it's most BASIC form.

    • 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 have certainly seen that. About as often are the times developers are handed a bunch of forms, and told, "just duplicate our paper workflow". Once they finish, they're told "now add in all these features that we want which are the reason we're creating this new software." Many customers and developers really don't want to put in the effort of hiring a workflow project manager to figure all this stuff out first.

  • by ErichTheRed ( 39327 ) on Tuesday April 14, 2015 @11:40AM (#49471407)

    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.

    • by flink ( 18449 ) on Tuesday April 14, 2015 @12:08PM (#49471767)

      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: (Score:3, Interesting)

      by podmate ( 1115907 )
      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 abo

  • The embedded link does not work.

    Good job Tim!

  • It is all together proper that this story would show up duplicated in my RSS feed.
  • Riight. More UIs designed by managers who Know How It Should Go, and wouldn't dream of letting a designer or (heaven forfend!) a programmer from talking to end users to find out how they need to *use* the software....

    Been there, dealt with that. The Scummy Mortgage* co, of Austin, TX, had software for its collection dept written that in in the late eighties, and the staff avoided using it as much as they possibly could.

    mark

    * Actual name of co available upon

    • I've seen one extremely frustrating EHR in action. And it's true, the UI is awful. I don't think it was a manger, though, it looked to me like it was designed by an techy, heh. I would have thought that generic non-techy PHB would want something like TurboTax.

      And it's not just the UI, it's also the specificity that is sometimes required - like, in medical history, someone says they broke their arm. There's no selection for "broken arm," it has to be a specific bone. So, patient who broke your arm when

It is impossible to enjoy idling thoroughly unless one has plenty of work to do. -- Jerome Klapka Jerome

Working...