Many trauma programs have trouble maintaining a concurrent trauma registry. One reason is the difficulty of recruiting a full team of trauma registrars. Another problem, however, is inefficiency. Poor software setup and other issues force registrars to spend time on tasks that do not add value. The registry team has less time for chart abstraction, reporting, data analysis and other key activities.
According to Michelle Pomphrey, MLT, RN, CSTR, president of Pomphrey Consulting, the solution is to create more efficient registry processes. Recently, she discussed several problems that lead to inefficiency in a trauma registry.
1. Letting your software decide what data you collect
“Each of the major trauma registry software packages comes with up to 400 preprogrammed data fields,” Pomphrey said. “Very few trauma centers need to collect all these data elements, but in many hospitals there is a feeling that you absolutely have to fill in all the blanks.”
Cutting out unnecessary “pre-packaged” data elements will free up registrars to focus on key data. Pomphrey recommends performing a trauma registry software cleanup every 6 to 12 months. First identify the mandatory reporting fields in your registry, and then take a critical look at the remaining data elements. (For full details on how to analyze your trauma registry data fields and safely eliminate unneeded elements, download How to Perform a Trauma Registry Software Cleanup.)
2. Allowing obsolete data elements to accumulate
Many trauma registries continue to collect data elements for national databases long after those elements have been removed or altered. For example, data elements and definitions for the National Trauma Data Bank (NTDB) and Trauma Quality Improvement Program (TQIP) change every year.
“It’s like the story of the woman who always cuts off the end the pot roast, because that’s what it says to do in her grandmother’s recipe. Years later it turns out that her grandmother just had a really small roasting pan,” Pomphrey said. “In the same way, some data elements have been passed down from generation to generation of registrars, with people rarely questioning why they are being collected.”
3. Collecting redundant data
According to Pomphrey, many trauma registries use different data elements to collect the same information. “For example, in some software the ED pick list includes a checkbox for head scan,” she said. “But this is just a checkbox, not a procedure code, so if you are reporting to the NTDB, the registrar still has to enter a procedure code somewhere else. This is double entry.”
Removing redundant data elements can help streamline registrar workflows. “The key is to determine how many questions you are answering in multiple places within the registry,” she said. “Then ask how many of these elements you can get rid of.”
4. Creating data workarounds
Pomphrey cautions against creating unnecessary processes. “We recommend that trauma programs maintain an admission list, a bare-bones record that allows registrars to track patients who have not yet been added to hospital administrative reports,” she said. Information on an admission list should be limited — just patient name, date, and one or two other pieces of identifying data.
“The problem is that at some point someone says, ‘Let’s add initial vital signs to the admit list and maybe some data points to allow PI to get started earlier.’ But then you have additional data capture and additional work,” Pomphrey said. “The admit list is supposed to aid database management, not replace the registry. This is a workaround that creates double work for registrars.”
5. Collecting data the hard way
Some centers collect information in the trauma registry that could be captured much more efficiently elsewhere.
“Years ago, many programs would collect the ‘ED nurse name’ in the trauma registry for use in performance improvement, because trying to find this information later in the paper records and flow sheets was a pain,” Pomphrey said. “But now that most hospitals have migrated to an EMR, it takes just a minute to pull up the record and see who the nurse was.”
Pomphrey points out that ED nurse name might be needed for only 20 out of 1,000 patients. “Since this data is used so rarely, it’s more efficient to remove it from the registry and just have the registrar pull it from the EMR when needed.”
6. Failing to circumscribe research data
The trauma registry is an important research tool, but researchers sometimes fail to see trauma data management expertise as a finite resource. As a result, requests for data collection are broader than necessary.
“Research data requests should not be open-ended,” Pomphrey said. “For example, a researcher may ask you to add three sets of temperature readings to the registry. Your job is to ask questions. What has the IRB approved?” Data collection can often be cut down significantly by strictly defining the information need. “In this example, you may only need to capture the temperature data for the next 100 patients who have a certain liver injury.”
Let registrars be registrars
Removing unnecessary, obsolete and redundant data fields from your trauma registry will allow registrars to work more efficiently. But according to Pomphrey, trauma programs still need to work on streamlining the responsibilities of the registrar team.
“I visited one hospital where the trauma registrar was sitting at a glass window in the clinic,” Pomphrey said. “Not only did she have to answer the phone and schedule appointments, she could be interrupted by anyone who stopped by.”
After you have cleaned up trauma registry software, examine the registrars’ job duties. “Registrars should not be scheduling appointments, ordering supplies or tracking physician CMEs,” Pomphrey said. “Hire someone else to handle these tasks more cost-effectively, and let the registrars focus on abstracting charts, getting data into the registry and running reports.”
Did you like this article? Our free newsletter includes regular features on trauma registry topics. Click here to subscribe.