EMR Blues

I’ve been following in pained silence the saga of Medpundit and her transition to an EMR (electronic medical record). If it’s any comfort to her, I feel her pain.

The computerization of medical records has been the Holy Grail of medicine for many years now, the answer to all manner of problems in health care delivery. Yet while we scan our groceries, submit taxes online, get money from a teller machine thousands of miles from the bank where our account resides, print detailed driving instructions to an obscure address in a strange town, and enjoy many other marvels of computerization and networks, the sad and sorry fact is that most physicians today document your health care in much the same way their grandfathers did: scribbling with pen on paper, filing the paper in a manila folder, and placing the chart (eventually) in a massive rack of other records organized using an obscure color chart based on the first letter of your first name. In a profession so utterly transformed by technology — CT scanners, minimally invasive surgery, gene therapy, etc. — it is nothing short of amazing that such an anachronism remains the norm. Yet only about 10% of physicians use an EMR in their practices. So, wassup?

The answer — like most things in medicine — is far more complicated than it looks.

The appeal of an EMR is obvious, and akin to the benefits derived from computerization in general: instant access to information, organized and readily available. Piles of paper and disorganized files disappear, replaced by the warm glow of a computer monitor. Smiling, relaxed staff no longer run around like rats in some twisted neurophysiology study, demanding to know for the very last time where you’ve hidden Mrs. Jones’ chart. Lab results at your fingertips, sorted by date and test, annotated with appropriate alerts to notify Mr Smith about his elevated blood sugar. The doctor spends more time with you, sees you on time, goes home at 5 pm, and plays with his children until bedtime, arriving back at the office rested with his morning coffee just before the first appointment.

At least, that’s what they tell you. The reality is vastly different.

This is a subject with which I have a more than a passing familiarity, having designed and developed an EMR software application for my practice over the past 12 years. Using an obscure but wonderful database application platform called 4th Dimension, I began in the early 1990’s to seek a solution for the repetitive mindlessness of dictating or hand-writing charts. Needless to say, a small project to create a database of chart notes and templates got wildly out of hand, and has now grown to well over 100,000 lines of code. Don’t try this at home, folks — at least if you want a life. I became so engrossed in this project that I even considered abandoning medicine and doing it full-time — a delusion which by God’s grace has since passed. But the logical-sequential perfectionistic obsessive-compulsive in me found a natural home in software development.

Now, apart from the huge black hole of time and effort in its development, my EMR is about as good as it gets. The software is designed specifically for the way I practice, right down to the dictation, data entry, templates and formatting style. I know exactly how it works; no training or familiarization necessary (my staff begs to differ, of course). I can — at least in theory — make it perform any task, exactly the way I want. And don’t get me wrong: it’s my baby, and I love it, and couldn’t get by without it. But it largely disproves many of the purported benefits of an EMR. So where’s the problem? What happened to Nirvana? Hmm, where to begin — here’s a few thorns in the flesh for starters:

 • Data Entry — That cryptic scribble that doctors are known for — sometimes called handwriting — is actually a very efficient shorthand; it is one of the few things doctors learn in medical school that is useful later in life. Sure, it’s impossible for others to read, terse, loaded with obscure acronyms, but it’s fast. And those little sketches in the chart communicate a world of information. Now move to the computer: you have to sit at a keyboard, type full words, and have no easy way to reproduce your descriptive drawing. Sure, there’s lot’s of software tricks to speed things up, such as popup menus, glossaries (short phrases which expand to full text), checkboxes, etc. But it’s still tedious, and takes much more time for the same information. Granted, the information is readable and can be easily organized. But it adds a lot of time to a too-short day.

 • Depersonalization — I can make quick shorthand notes while still maintaining a conversation — and eye contact — with my patient (and yes, I know a lot of doctors stare at the chart, with no patient eye contact: BAD doctor! Shame!). Now bring a laptop, or even a new tablet computer in the room, and the dynamic changes: the focus is on the machine, the technology, the keyboard. The patient begins to feel like a spectator, akin to talking to someone who’s using a speaker phone: you know their focus is on something other than you. One more barrier has been thrown up in the relationship between doctor and patient.

 • What about the paper? — We’ve been hearing for years about the paperless office. Ever seen one? Neither have I. Even in a small solo practice, with an entirely electronic medical record, the amount of paper arriving daily is nothing short of staggering. Lab reports. Insurance forms. Hospital dictations. Work releases. Physician letters. Record requests. Notes and med lists from patients. It’s endless, and it’s brutal. It all has to be reviewed by somone (often the physician), and filed. Most of these items have to be associated with a specific patient’s chart, and this means one thing: scanning. The paper must be converted to a digital image — and that’s just the beginning. It has to be linked or imported to the patient’s record in the database, and then categorized and named. You see, an image is just that: a bunch of random dots which only have meaning when interpreted by the human eye and brain. Want to get the results of Mrs. Jones’ lab test you’ve scanned in last week? Computers are great at searching for text strings, but have no clue that this binary collection of black and white pixels contains your blood count results. A human has to enter linked information associated with the binary file in order to retrieve it. Yes, there are OCR (optical character recognition) programs to convert images to text, but they have an unacceptable error rate even on high-quality typed originals, and are useless for low-quality copies or faxes, or complex reports like lab. So the quick-and-dirty routine of read, pull chart, sign off, and stuff in the folder, becomes: read, scan, import, query database, link, name, categorize, save, sign off. Doesn’t sound too bad until you’re dealing with hundreds of pages a day, but there’s more steps, and each one is more time-consuming. Only after this process does the benefit of rapid information access accrue.

 • What about the old charts? — Oh yeah, those: thousands of ’em, with thick piles of paper in each. Loads of junk, like duplicate copies, insurance forms from 5 years ago, post-it notes, and lab results pasted like shingles on single pieces of colored paper, 5 or 10 to a page, different tests, different dates. And the staples — all have to be removed before scanning, lest the scanner jam and devour your only copy of a pathology report faster than a Rose Law Firm shredder. These charts are an absolute nightmare to convert to digital form for any size practice moving from paper to EMR. But if you don’t tackle this, you end up with a orcish mutant, with some information on paper and some on computer — the worst of both worlds. You can contract this job out, but it’s prohibitively expensive, quality is spotty, and the results are either unorganized or mis-organized. It has to be done in-house, in my opinion. And it’s not a job for your father’s scanner, the one you use to e-mail that 3×5 print of Junior to Grandma. High-speed document scanners are a must, and they are very expensive.

 • Legacy software — Almost all physicians have existing software in their office to handle insurance billing. It’s usually butt-ugly but functional, understood only by those coding specialists plying their arcane craft, squeezing blood out of Prudential’s rock. And the information therein — demographics, insurance data, coding information, phone numbers — is needed by your spiffy new EMR software. Simple data transfer? Fugeddaboutit. No electronic data export option available – or your billing software company will write a custom job for you (something which should take, oh, an hour of a competent programmer’s time) for a mere $10-20,000. Right. It’s called Square One: you have to manually enter all your names, insurance info, and — God forbid — accounting and ageing information into your new software. Cancel all staff vacations, call for Chinese carry out, limit bathroom breaks, and be prepared to spend many nights and weekends in the office.

 • Design issues — Did I mention that EMR software is very hard to design well, and very rarely well-designed? Medicine and health care problems don’t fit well into standard, cookie-cutter design models, unlike, say, accounting, banking or payroll. Lots of people and countless man-hours have been spent on medical informatics — the technology of mapping health care to computers — and there are miles to go before we sleep. Different areas of medicine are widely divergent problem domains: a pediatrician, a heart surgeon, a radiologist, an anesthesiologist, and a pathologist all have vastly different requirements for managing, organizing, and retrieving health information, and shoehorning them into a single off-the-shelf software package just doesn’t work.

And there’s another problem: the people who are skilled at designing software don’t understand the problem domain of medicine, and the users (doctors and office staff) on the medical side don’t understand or communicate their work flow well to the software designers. The result is software with lots of bells and whistles that programmers love, but which is hard to learn and use, and forces users to work inefficiently. This is a widespread problem in the software development world, and one reason why a staggering percentage of large custom software projects – greater than 80% – never reach completion.

 • Cost — In the final analysis, it is in large part about cost. The financial hurdles are legion: hefty hardware to run the applications; firewalls and tight security for protected health care information; fast networks to handle images and other large files; redundant and offsite backup; staff training and support; expensive software packages (often over $100,000); the enormous number of man-hours to input and archive legacy data. Are there huge benefits to be had once the transition to EMR has been made? Absolutely, but the time line is very long and the cost-benefit ratio simply does not make much sense for many physician practices. Margins are tight in health care, and growing tighter. Investing huge resources in information technology is not a high priority when many practices are struggling to meet payroll.

So, will we ever get there? Yes, eventually — I anticipate 10 or more years before this is nearly universally implemented. And don’t be surprised if the touted benefits for cost reduction and efficiency never materialize as predicted, although the clinical benefits will be substantial. Blending the art and science of medicine in this area is a formidable task. Like emulsifying lemon and egg yolk in a fine Bearnaise, this transition will take lots of patience and see slow progress, with lots of scrambled eggs in the interim, but the results will be well worth the wait.

9 thoughts on “EMR Blues

  1. Doc,

    excellent analysis.

    You’re right, a software firm will charge you an obscene amount of money for an hour’s (actually, probably a day’s) work coding an effective data-transfer program from the Legacy software.

    Of course, if the programmer wants to increase his billable hours, he can spend several weeks testing every obscure borderline-case in the source data-set, and produce a really robust piece of code.

    (The really thorny part of this problem is that weeks and months may be needed to solve the problem. Imagine that the old programmer may have retired, and not left a clean set of “patient charts” about the various problems he had to fix during code development. Without this kind of documentation, the reverse-engineering required to extract the data can become astronomically complex. For a worse complication, imagine that the company that produced the code went out of business 5 years ago, and you had to hire a kid fresh out of college to do the transfer…)

    I think the heart of the problem is the extremely small intersection between computer scientists and databasing experts and medically-savvy people, as you pointed out.

  2. Pingback: GruntDoc
  3. I got out of software nearly 6 years ago, after 15 years of arguments over those useless bells and whistles. The problems with EMR are not, as you know, unique to EMR. The problem is that software engineers and designers consistently fail to realize that the purpose of the software is to make someone else’s job easier, not to “look cool.”

    People ask me if I’d ever go back. The money was great but the frustrations were greater. In truth I’d love to work on a project like an EMR system — with the right users in place to consult on design issues, and the right staff in place to design and code to what the users really want and need.

    I have an enormous medical history and I’m only 41 years old. I would love it if I didn’t have to fill out that same “health history” questionaire every time I walk into a doctor’s office. It would be so great if I could just hand the receptionist a card to swipe so they’d have access to everything! Maybe someday. God help the folks building that system.

  4. The promise of an EMR is nothing short of revolutionary… patient information at your fingertips, easy to use, linked to constantly updated pharmacy information that prevents errors in prescribing, etc. What most of us (myself included) are forgetting is that progress in the software world occurs gradually, and we cannot expect a rapid and successgful implementation of EMRs across the country.
    Remember the early days of the IBM PC, with the competing Apple platform? Most of us in the medical world paid little attention, but there was a very intense battle over which platform would be the “business standard.” While many institutions and companies have spent years trying to develop EMR systems, there is NO standard platform; without that standard, it is very hard to move forward.

  5. The last practice I worked at had a true EMR system – all notes were computerised, lab and radiology reports all came in via email, there was an intra-office email system via which we could flag results for the nurses to follow-up on, computerised prescribing, and much more.
    I gather this had been a big drama to implement but by the time I started there it was running very smoothly. The benefits were huge – all the doctors could actually read what the others were writing, we had copies of all referral letters etc, and we could instantly access a file we wanted to view without having to ask reception staff to go and retrieve it for us.
    Now that I’m back working at a prectice with a very rudimentary and haphazard computer system it feels like returning to the dark ages.

    So I do think an EMR is worth the pain, but agree the challenges of implementing it on a wide scale are huge.

  6. Hello!
    I’m a health informatics student and I fully agree with your points, esepcially the one on “Design Issues”. Coming from a computer science background, and then taking years of health informatics classes has really helped in bridging the two fields of medicine and computers.
    Thanks for your thoughts on that, I really enjoyed reading…

  7. Okay … I’m still trying to dig back up to the surface after reading this post …

    Considering changing my major from Medical Informatics to … uhm … well … any suggestions? :(

    *Tries to remember all of the reasons she was so gung-ho to being wth!* 0.o

  8. Thanks for the great article. Great to have some Dr/Tech person perspective.

    One other thing to think about converting from a legacy system is when the Legacy system has poorly implemented processes and therefor has poor data. Not a good thing to convert. You don’t really want to make your EMR out of whack from day one.

    I agree with so many of the experiences you described. Here’s an article that I found described the emotions of implementing a new EMR.

    Finally, what are you going to do with your 4D EMR system? What would the practice do if(God Forbid) you got hit by a bus? Anyway, just wondering what kind of pains your “baby” would go through if your “baby” should lose you.

  9. Ok, so this is like sending an email and forgetting the attachment. Here’s the link to the article I talked about in the previous post:
    Tense Moments When Implementing an EMR

Comments are closed.