Over the last 12 months, many trauma programs have migrated from their old trauma registry software to a new trauma registry system.
Overall, these new data systems offer exciting new features and capabilities, and they promise to expand the amount of rich clinical information that is available to program leaders.
However, new software always creates new challenges. Based on recent conversations with trauma leaders across the country, the migration to new registry software has been bumpy for most centers.
Registrars are experiencing the learning curve of acclimating to a new system and adjusting to new productivity expectations. Registry leaders are finding that migrating legacy data to their new system is turning out to be unusually complex.
The bottom line is that your new trauma registry software may be up and running, but your team is struggling with a new set of issues and obstacles. What should you do next?
The key is to develop and implement a tailored set of data quality processes that ensure accuracy, consistency and reliability.
Make plans for handling legacy data
The first challenge is technical — data from the legacy registry system may not transfer accurately to the new platform. This problem can have several causes, but for most trauma programs the root issue is widespread discrepancies between the labeling conventions of older and newer systems.
Some data field labels are very logical, so mapping the old field to the new is not a major problem. For example, the patient name format in a legacy software might be “First_Last” while the same data in a new software might be “First.Last”. These differences are small and the fields are easily matched up. Consequently, the flow of data from the old system into the new system is seamless.
However, other data field labels are idiosyncratic. For instance, a data element is labeled “RFS_ETOH_BAC_SCRN_C_AS_TEXT” in your legacy software but “alcohol_screen.desc” in your new system. This increases the chance that legacy data will end up in the wrong location. The practical result is that teams cannot use the new registry to report on older data.
In our experience, knowledge of older registry languages is becoming rare among current software development teams. These developers are developing amazing systems, but they are simply unaware of the many labeling idiosyncrasies that make data migration a challenge.
How can registry professionals address this problem?
First, audit your data to check for complete and accurate transfer of key data elements as well as elements that are most vulnerable to migration errors. For example, create a report on patient dispositions per time period and make sure that the number and type of dispositions in your new system matches the same data in your legacy software. We also recommend adding a high-level data migration review as a standing item in your performance improvement (PI) plan.
Second, incorporate into your data quality plan any measures you take to ensure legacy data is accessible and accurate. This would include logical reporting checks (like the above example) for matching concurrent registry data against data extracted from legacy systems. It could also include any data validation processes that specifically address registrar performance with regard to legacy data, such as comparing inter-rater reliability (IRR) results under the old and new systems and the IRR results of data transfer audits.
Create data submission review process
Traditionally, registry professionals have had the opportunity to scrub their data before submitting it to the Trauma Quality Improvement Program (TQIP). This typically involved running data logic reports and performing a final review of data records against charts to confirm accuracy before data submission.
In contrast, some newer trauma registry systems automatically upload patient data to TQIP as soon as the record is closed. This is a great feature, because it automates the complicated process of packaging and uploading benchmarking data. However, it means that the traditional “final scrub” is not possible.
The fact is that newer systems do not necessarily have robust logic checks built in. To mitigate this weakness, we now recommend that registry teams perform regular retrospective data quality reviews prior to any TQIP call for data deadline.
At the close of each month, run logic checks on all automatically uploaded records to make sure that transmitted data is complete, accurate and free of logical errors. One simple strategy is to review all patients who fit submission criteria to ensure the TQIP data center has the same number of patients in your submission. Correct any errors that are flagged by this process and then resubmit any corrected records.
Build an internal data dictionary
Maintaining a hospital-specific trauma data dictionary has long been a best practice in trauma data management.
An in-house data dictionary supports data quality by providing a data collection hierarchy that is customized to your electronic health record (EHR) and other data sources. This helps ensure that all registrars are collecting data in a uniform manner. It also supports registrar onboarding and training.
Based on the current environment in trauma registry tech, we believe that maintaining an internal data dictionary is more important than ever.
By creating new integrations that pull data directly from the EHR and other sources, new registry systems have significantly changed abstraction processes. As a result, registry teams need well defined guidelines on where to find data elements and in what order.
Here are three important points to keep in mind about building and maintaining an internal data dictionary:
- Any EHR update can cause data elements to begin populating the wrong registry fields. For this reason, it is important to update your internal dictionary anytime the EHR is updated.
- With that in mind, we recommend maintaining a change log (like the NTDS change log) for your internal data dictionary. This will not only help registrars stay up to date on registry changes, it will help users understand the meaning of registry data across changing definitions. This is important for both researchers and program leaders who are involved in trauma PI.
- Finally, keep in mind that as new registry software systems evolve, your data dictionary will need to evolve with it. As you add or subtract data fields or change software configurations, review and update your internal dictionary accordingly.
Expect impact on benchmarking reports
Many U.S. trauma centers transitioned to a new registry system on January 1 of this year. Given all the migration issues and system idiosyncrasies discussed above, these centers may soon begin to see significant variances in their TQIP benchmarking reports.
Our recommendation to trauma program leaders: When examining any outlier values on your report, give extra attention to the possibility of an underlying data quality issue. Any new variance calls for a careful look at data mapping, data entry and other links in the data quality chain.
While this is a short-term challenge, there is an upside: The coming year will be a great opportunity to identify and fix mapping issues and strengthen your total approach to trauma data management.
The next 12 months
Overall, data quality efforts need to move further upstream.
Trauma programs that have recently migrated to a new registry system — or which are about to take the leap — should prioritize upfront efforts to audit, verify and ensure data quality.
Pomphrey Consulting offers a full selection of education and support services that can help trauma data professionals adapt to the changing registry environment. To view all the options, visit us online at Pomphrey Consulting.
