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. Before the patient arrives, 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. Several are simultaneous.

This stream of information continues after the patient leaves the trauma bay for CT, imaging, interventional radiology, operating room, ICU, or floor bed. The flow sheet scribe is charged with recording all of this information as contemporaneously as possible. This ensures the 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 laid out before the scribe. All data blocks are readily visible and are grouped in logical clusters: prehospital information here, primary survey data there, procedures in that one, vital signs and narrative there. They are equally and immediately accessible for input.

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 widespread 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 and between computer workstations?

During chart reviews, I have seen numerous examples of fluids,  vital signs, and drug administration recorded well after the patient has been declared dead!

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