Tag Archives: Trauma flow sheet

The Electronic Health Record And Productivity In The ED

In 2009, the Health Information Technology for Economic and Clinical Health (HITECH) act was passed. This provided an incentive for all US hospitals to demonstrate “meaningful use” of the EHR. For those of you interested in the details, check out the related post link at the end of this article.

Hospitals rushed to comply, shelling out lots of money to try to recoup some of it through these incentives. In theory, using an EHR should allow better record sharing, increase patient satisfaction, reduce unnecessary testing and medical errors, and ideally, improve billing. But does it work?

A community hospital with a medium-sized ED looked at physician productivity in the ED while using an EHR. In this case, the software product was McKesson, and 16 clinicians were monitored prospectively over a 30 hour period.

Here are the factoids:

  • The group consisted of attending physicians, residents, and nurse practitioners / physician assistants
  • The distribution of how they spent their time is shown below:
  • In order to complete an assessment in the EMR, it took an average of 160 mouse clicks
  • On average, clinicians saw 2.12 patients per hour, requiring nearly 4000 mouse clicks to complete their charting

Bottom line: Overall, this is not a very good or coherent or even well-designed study. But it does show us one thing. Clinicians spent only 28% percent of their time seeing patients, and 56% of their time reviewing or entering data into the EHR! Note the blue and green wedges in the pie chart. How can they possibly earn their salaries? Other studies have confirmed that using an EHR does decrease throughput slightly, yet reimbursements increase anyway.

How can this be? EHRs were originally designed to facilitate billing, and it looks like they still do, making up for the fact that fewer patients can be seen. But this seems like a perverse incentive to me. Adopt the EHR, see fewer patients, get paid more!?

Related posts:

Reference: 4000 Clicks: a productivity analysis of electronic medical records in a community hospital ED. Am J E Med 31:1591-1594, 2013.

A Brief History of the Electronic Health Record

The EHR has been around longer than you think. Even before the current desktop style microcomputers existed, a few hospitals implemented early versions of this product. One of the first was the Latter Day Saints Hospital in Salt Lake City. It installed what it called the HELP system, an acronym for Health Evaluation through Logical Programming.

As computing power increased and the size of the computer box and its cost decreased, a series of advances in medical software systems began to occur. In 1983, a software product geared toward resource scheduling was introduced, and became one of the leading applications of its kind. Most people recognize the name Cadence, but few realize that this was one of the earliest product releases from Epic Systems Corporation.

In 1988, the US government contracted out to develop an electronic record system for the military, much of which is still in use today. On a smaller scale, PC type computers were almost 10 years old in 1990 when Microsoft introduced what I consider the first real version of Windows, version 3.0. Epic was once again an innovator, and it released a product called EpicCare for Windows.

Beginning in 2004, there was a move within the government to emphasize implementation of EHRs across the US, spearheaded by President George W. Bush. And as expected, this led to a number of products developed by a variety of software makers. The push to roll out an EHR universally continues to this day, with no end in sight.

Is this a good thing or a bad one? Although much maligned, the EHR can certainly offer benefits. However, like anything touted as a miracle drug or device, there are always downsides. I’ll review both over the course of the week, but my focus will be on one very specific trauma problem: use of the EHR during trauma resuscitation. Many trauma programs either voluntarily adopted the use of an electronic trauma flow sheet (eTFS), or were forced into it by their hospital administration or IT department. Good idea or not?

We shall see…

Trauma And The Electronic Health Record

I’m going to dedicate this week to discussing the impact of the electronic health record (EHR) on trauma care.

First, I’ll talk a little about the history of the EHR, how it came about and why it was “encouraged” of all hospitals. I’ll also look at who the big players are. Next, I’ll review two studies of the impact of the EHR on ED productivity and patient stay.

And finally, I’ll really dig into using an electronic trauma flow sheet that interfaces with the EHR. My thinking has slowly been changing, but not by much. I’ll review my reasons, and talk about the (few) success stories that are out there.

Stay tuned!

EMR vs Trauma flow Sheet: The User’s Perspective

Well, you’ve read me railing against the (current) use of an electronic medical record in place of a paper trauma flow sheet for days. I’d like to share some comments from an end user (nurse) who started using the Epic Trauma Navigator last year:

I am really not impressed with the Trauma Narrator for a few reasons: 

  • Bulky & cumbersome to access during a trauma team activation. Our build team promised us that this would be an efficient model of documentation, however, that has not been the case. It takes more steps to document than before and the output is in so many different places review of the chart is extremely difficult to do. You need to know exactly where to look for this information.
  • While the rest of Epic has a feature that allows for the automatic integration of vital signs from cardiac and NIBP monitors, Epic does not allow this feature in the Trauma Narrator.  All vitals need to be entered manually which can be time consuming. Knowing this up front, I think I would have advocated for not using the Trauma Narrator at all.
  • Vital signs and GCS are not displayed within the same flowsheet in Epic. You can find VS in several places, however GCS are in one specific location and if you don’t have the secret treasure map to find them, you will be searching the high seas of frustration for a long period of time.
  • During our build, there were several requests that were not included in the build. I am told that the once Epic goes live, there is a lock-out of up to 12 months before any “optimization” occurs. My advice to you all who are going to Epic is to be adamant about what you want and ensure it is there before go-live. We are missing small things like “logroll time” and level of activation among other “simple” items.
  • Massive transfusions are difficult to document as you need to address each blood component separately and there are several steps in the process for each component. Again, not a user-friendly system at this point for that.
  • Our training was done concurrently with our build so our training was on a generic template/flowsheet within the Epic playground that did not mirror our live version. This was not at all what our production/end-user system looked like at all, so our employees had to be retrained on the job on how to document with the Trauma Narrator.
  • Order sets are available within Epic, however not all staff use the trauma order sets. This creates confusion and the incorrect items being ordered. Again, bird-dogging is required to assure compliance.
  • Once the patient is “arrived” within the Epic system (aka patient chart is noted as the patient actually being in the ED) you cannot go back and document on the EMS radio/report sheet. Staff need to be diligent to assure that documentation is completed before the patient arrives. We have had scenarios where there have been multiple trauma patients arriving and once the nurse begins the documentation of the trauma team, the ED Charge nurse could not go back and enter the radio report in the proper section. 

… remember, Epic is a documentation tool, and as a tool, it depends on the user. Some will continue to document incredibly well and others not so much.

Bottom line: I have absolutely nothing against Epic. I consider it to be one of the best EMRs out there, and I’ve been exposed to quite a few. As you can see though, even it suffers from many of the input problems I’ve written about in the past. And trauma flow products on other EMRs don’t even come close to this one. So for now, buyer beware! Wait until the input technologies and report capabilities become so intuitive that anyone can use them.

Related posts:

Yet More On The EMR / Trauma Flow Sheet Debate

My opinions about using an electronic medical record (EMR) system for recording trauma activations are well known. I received this well thought out response that I wanted to share and comment on:

My quote: “I defy any of them to come to a trauma resuscitation and rapidly and accurately transcribe all of the information presented, or try to review a PI case based on a printed EMR report.”

Their response: I’m a nurse informaticist, I’ve been a trauma nurse for 15 years, and I review PI cases using the electronic record. I work in an inner city Level 1 trauma center that’s associated with a large academic institution. We have recently implemented an ED Information System in our department and I have documented major traumas electronically. My trauma charts beat my colleagues written flowsheet in accuracy, comprehensiveness, and detail, hands down.

Your blog entry on this topic seems very close-minded. The “flowsheet” is not the silver bullet for trauma documentation. I agree that an EMR can be lengthy but it, by far, surpasses the flowsheet in thoroughness in detail. They both have their pros and cons, why be so quick to pick one? Yes, flowsheet data might be convenient for the reviewer but have you considered the effect on workflow for the frontline staff? An ED that has a comprehensive information system (CPOE, electronic tracking, physician and nurse documentation) must pull out a piece of paper and write on it so that a reviewer can find things easier retrospectively? It seems to me the priority should be the appropriate care for the patient and positive outcomes versus a reviewer being inconvenienced by having to read a long chart.

My response: My main problem with using an EMR to record a trauma activation is that the current human interface technology (keyboard, mouse) do not allow for rapid data entry and movement between different screens of input boxes. If a scribe such as yourself becomes extremely familiar with the system, it is certainly possible to overcome these difficulties with sheer skill and familiarity. However, your response implies that you are the only one capable of doing this. Your colleagues must still use the written trauma flow sheet.

The purpose of the flow sheet is to allow any scribe to record meaningful data that can be used to document patient care and to review and rebuild a complex resuscitation for performance improvement purposes. It is not designed to please trauma center reviewers. But the process the reviewers use to reconstruct a trauma activation is the same one that the hospital’s trauma program must use to dig into the events that occur in a trauma activation. If the input data is faulty because the scribe could not keep up in the EMR or had to enter it later, or if the output is dozens of pages of data that is difficult to sift through, the trauma program manager must spend an inordinate amount of time trying to figure out exactly what happened. The “thoroughness and detail” you mention in the EMR can be a hindrance if the quantity of data eclipses its quality. I have reviewed EMR records with 30 pages in the trauma flow sheet report!

The reviewers look for some kind of trauma flow data that they can use to rapidly rebuild what happened in the trauma room. If the reviewers can’t do it, then the trauma program probably can’t do it either. Neither I nor any of the other reviewers I have worked with have found an EMR trauma flow sheet that matches the utility of paper. Yet. The day will come, but it’s not here yet.

I welcome any additional opinions on this debate. Please leave a comment!

Related posts: