Tag Archives: Trauma flow sheet

Trauma Patient Stay In The ED After Implementing an Electronic Health Record

So as we discovered, we may spend less time and see fewer patients if we use an EHR. One would think that ED length of stay (LOS) would then increase. But does it?

A 2 year observational study from Greece looked at ED throughput before and after implementation of an electronic trauma documentation system. A total of 101 trauma patients were processed under the paper charting system, and 99 were handled after implementation of the electronic system.

Here are the factoids:

  • Injury severity was high overall, with half going for emergent surgery and an overall mortality rate of about 12%
  • Total ED LOS decreased from 206 to 127 minutes with the EHR
  • This was accomplished by decreasing time between arrival and completion of care from 149 to 100 minutes, and from completion of care to leaving the ED from 47 to 26 minutes

Bottom line: Looks great! Badly hurt patients, moving through the ED at breakneck speed after implementation of an EHR. The problem is that it was not really an EHR, but an “electronic documentation system.” Upon close inspection, this is a homegrown system with very specific functionality for monitoring care, providing checklists, and offering case-specific guidance. This is not the type of complex documentation system one usually thinks of when visualizing an EHR. But it does go to show that well-designed and focused software can be beneficial.

Tomorrow, I’ll start to focus specifically on the electronic trauma flow sheet (eTFS).

Reference: The effect of an electronic documentation system on the trauma patient’s length of stay in an emergency department. J Emerg Nursing 40(5)469-475, 2014.

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: