Tag Archives: Trauma flow sheet

The Electronic Trauma Flow Sheet: What Does(n’t) Work – Part 1

There are two major problem areas using an electronic trauma flow sheet (eTFS): the front end and the back end. Today, I’ll discuss the front end data entry problems.

Trauma activations are very data intensive events. Beginning prior to patient arrival, there are registration activities so the electronic health record (EHR) can begin accepting other information about the patient. Once they arrive, there is a continuous stream of information regarding observations, actions, results, medications, fluid, blood, and much more. All of these occur during a relatively brief period of time. Some are simultaneous.

This stream of information continues after the patient leaves the trauma bay for CT, imaging, interventional radiology, operating room, ICU, or ward bed. The flow sheet scribe is charged with recording all of this information as contemporaneously as possible. This ensures accuracy of the data, particularly with events that occurred at the same time.

But there is a major difference in input between the paper trauma flow sheet and the eTFS. The paper sheet is typically a three or four page form that is laid out in front of the scribe. All of the data blocks are readily visible, and are grouped in logical clusters: prehospital information here, primary survey data there, procedures in that one, vitals and narrative there.

Unfortunately, it’s not so simple with the eTFS. The scribe can view whatever content fits on a single screen. And it is just not possible to display all of the needed info on that one screen. The software developers addressed this problem by creating multiple screens that can be accessed by clicking on various tabs or buttons. The problem is that the human cannot see where the blocks are and must be very familiar with the tabs and buttons. And to make it worse, they must shift between mouse click and keyboard to move between them and record data.

This results in a stream of input that can’t be recorded quickly enough to stay current. It is very common to see a “cheat sheet” next to the input terminal so the scribe can add quick handwritten notes when they get behind. This information is entered later, but as you may imagine, accuracy suffers. It is very common to see events or results that do not fit the timeline. Once this occurs, the entire record is suspect and will not represent the true flow of the resuscitation. And what about events that occur during patient transport, between computer workstations?

The difficulty of entering trauma resuscitation information in true real time results in a Garbage In situation. Tomorrow, I’ll continue with problems on the back end that can result in Garbage Out.

 

The Electronic Trauma Flow Sheet: Why Hospitals Want You To Switch

Today, I’ll kick off my series on use of the electronic trauma flow sheet (eTFS) with a list of the typical reasons used to justify it. 

Typically, hospital administrators pressure trauma programs to adopt an eTFS at some point after implementation of an electronic health record (EHR). For the most part, they give two reasons:

  1. We need to go paperless! The assumption is that all of the rest of the charting will be electronic, so the trauma flow sheet should be moved to this format as well.
    The reality is that there will always be some good, old-fashioned paper parts to the patient’s chart. Every hospital ward has a little cubby with some old-timey three ring binders for putting the scraps of paper that accumulate. These may be records from an outside referring hospital, a pre-hospital run sheet, blood bank tags from units of blood products, and other stuff. What typically happens to it? It gets scanned into the chart at some point. 
    So there is no reason that a paper trauma flow sheet can’t be scanned as well. The key move is that it should be scanned early so that it is available in the EHR as soon as it is complete.
  2. We need to see patient flow, vitals, meds, etc from the time they hit the door. We don’t want to miss the activity that occurs in the trauma bay, right?
    The care typically received in the trauma bay is what I would consider a singularity. It is like nothing else in the hospital stay in terms of pace, intensity, and level of activity. Being able to trend medication or blood administration from arrival through discharge is not that important. Vital signs during resuscitation may be nothing like those of the rest of the hospital stay. It’s just not that helpful to be able to connect that phase of care with the rest of it.
    But having said that, it may be helpful to be able to see all of the medications given during a hospital stay. Ideally, someone should go back and reconcile the medications after the fact. A pharmacist, perhaps?

Neither of these excuses really hold any water, so don’t get talked into trying out an eTFS because of them.

Tomorrow, I’ll write about why the eTFS doesn’t work during the trauma resuscitation phase of care.

Next Week: The Electronic Trauma Flow Sheet

It’s been a while since I visited the topic of the electronic trauma flow sheet (eTFS) for trauma activations. A few years have passed, the software engineers have gotten smarter (hopefully), so let’s look at it again.

Next week, I’ll be covering the eTFS in detail again. Here is what I will touch on:

  • eTFS: Why Hospitals Want To Switch
  • What Does(n’t) Work
  • Oops! Now What Are My Options?

I’d also like to spend a day on Q&A. To that end, please start emailing, commenting, or tweeting your questions so I can answer them in detail at the end of the week. Let the games begin!

The Electronic Trauma Flow Sheet – Final Answer

After more than 10 years of experience, moving to an electronic trauma flow sheet is still not ready for prime time. I’ve seen many, many hospitals struggling to make it work. And all but a very few have failed.

There are two major problems. First, existing computer input technology is underdeveloped. Trying to rapidly put information into small windows on a computer, and having to switch between mouse and keyboard and back is just too slow. And second, output reports are terrible. Humans cannot scan 26 pages of chronological data and reconstruct a trauma activation in their head. There is so much extra data in the typical computer-generated reports, the signal (potential PI issues) gets lost in the noise.

The technology exists to remedy both of the problems. However, the EHR vendors keep tight control over data exchange in and out of their products. Sure, there is CareAnywhere and it’s ilk, but the user is still forced to use the vendor’s flawed input and output systems.

Bottom line: You can’t make a complex system (trauma care) easier or safer by adding complexity (the EHR). Yet.

The electronic trauma flow sheet will never work as well as it could until all the vendors settle on a strong data interchange standard to put data into and get reports out of the EHR. Once that happens, scores of startup companies will start to design easy input systems and report outputs or displays that are actually meaningful. There’s not enough interest in this niche market to make it worthwhile for a company the size of Epic or McKesson, but there is definitely enough for a lot of young companies just chomping at the bit in Silicon Valley.

The Electronic Trauma Flow Sheet – Part 1

I started voicing my concerns about trying to use an electronic trauma flow sheet (eTFS) way back in 2008. There are very few reports in the literature that specifically detail using the EHR as a trauma flow sheet. The first (see reference 1 below) described an early experience with the conversion process. It outlines lessons learned during one center’s experience, and I’ve not seen any published followup from that center.

Now, on to a report of a “positive” experience. A Level I pediatric trauma center made the same change to the eTFS. They designed a custom menu-driven electronic documentation system, once again using Epic. Specific nurses were trained to act as the

electronic scribe, and had to be present at every trauma resuscitation. The goal of the study was to compare completion rates between paper and electronic documentation. One year of experience with each was collected.

Here are the factoids:

  • There were about 200 trauma activations each year that were admitted, and only 50 or so were highest level activations (in a year!)
  • 11 data elements were compared, including treatments prior to arrival, vitals, fluids, primary survey, level and time of activation, patient and surgeon arrival, and disposition
  • The eTFS was better at capturing time of activation, primary survey components, attending arrival time, and fluid administration

Yes. That’s it. They looked at 11 data points. It says nothing about the wealth of other information that has to be recorded and needs to be abstracted or analyzed. And nothing about the reports generated and their utility. Or how much additional time must be spent by the trauma PI program to figure out what really happened. Or how good their paper documentation was in the first place (not so good, apparently). Or the bias of knowing that your documentation under Epic is being scrutinized for the study.

And to get to that level, this hospital had to maintain a complement of highly trained nurses who were facile with their customized Epic trauma narrator. And they had to maintain their skills despite seeing only one highest level trauma activation patient per week, or one activation at any level only every other day.

I’ve had a few discussions with the trauma program manager from this hospital, and I am convinced that they have managed to make it work well at their center. However, I’m not certain that their system can be generalized to hospitals with higher volumes and and degree of staffing restraints.

In my final post of this series, I’ll tell you what I really think about using the electronic trauma flow sheet in your trauma resuscitations, and why.

References:

  1. Using the electronic medical record for trauma resuscitations: is it possible? J Emerg Nursing 36(4):381-384, 2010.
  2. A comparison of paper documentation to electronic documentation for trauma resuscitations at a Level I pediatric trauma center. J Emerg Nursing 41(1):52-56, 2015.