Development and implementation of an institutional enhanced recovery program data process

Introduction

Electronic health record (EHR) systems have revolutionised medical practice by giving physicians and other health care providers’ instantaneous access to patients’ entire medical histories. Because EHR systems were built with the point of care in mind, their users can at times be limited in their ability to use the vast amount of information these systems provide—simply obtaining data from EHR systems presents its own set of challenges (Christensen and Grimsmo, 2008). Elevating evidence-based, data-driven medical practice to the next level requires the development of EHR database management tools that not only ensure reliable data automation but that also overcome current challenges of data abstraction.

The flow of data in the Epic EHR system, one of the most common EHR systems, illustrates the complexity of attempting data abstraction with these systems. The Epic system’s underlying database, Chronicles, has a programming language that is very robust but exceedingly complex. In most cases, Epic is set up to transfer its data to secondary database applications (e.g., Clarity, Caboodle), which themselves store data in a complicated array of tables. A trained user must use structured query language (SQL) to query these databases, which even experienced SQL programmers can find difficult to navigate (Manion et al., 2012). Given this level of complexity, most research teams must employ informatics personnel to handle large-scale data abstraction.

Furthermore, the data that can be abstracted from EHR systems are often limited to structured data. Structured data—the only type of data SQL can be used to retrieve—are often discrete or continuous and are far more amiable to automation, rapid retrieval, analysis, and semantic interoperability (Yu et al., 2014). Conversely, unstructured data are often qualitative descriptions of encounters, such as progress notes. Even with intricate SQL queries, abstracting unstructured data requires more effort than abstracting structured data does. Abstracting unstructured data in a meaningful way often requires the use of both a NoSQL ( not only SQL ) database and a natural language processing programme. This requires great expertise in querying and managing heterogeneous data sources, thereby limiting users from accessing EHR systems’ vast data pools (Zheng et al., 2015). Thus, teams often use manual abstraction and utilise translational research tools to enhance their research capacity. Automating the data abstraction process would not only increase efficiency but also reduce the likelihood of human error, allowing for more reliable data use (McColm and Karcz, 2010; Stadler et al., 2016).

The University of Texas MD Anderson Cancer Center, a stand-alone comprehensive cancer center, Enhanced Recovery Program (ERP) is a collaborative patient-centric, recovery-focused care transformation initiative led by multidisciplinary team members, actively engaging caregivers and oncology patients in their treatment planning and care delivery. The programme’s vision is to minimise treatment-related complications by early intervention to prevent clinical deterioration, reduce patients’ symptoms burden, and enhance patients’ experience and functional recovery, thereby facilitating timely return to adjuvant oncologic therapies when indicated while improving cancer outcomes. The key components of this approach include pre-intervention optimisation of the patient, using multimodal opioid sparing preventive analgesia strategies, intra-operative administration of anti-emetic compounds, maintaining appropriate fluid balance and haemodynamic optimisation, early post-operative mobilisation, and early intake of fluids and solids (Ljungqvist et al., 2017).

To meet an increasing number of research, quality improvement, and reporting initiatives, the University of Texas MD Anderson Cancer Center developed the universe, a first-of-its-kind tool that simplifies querying Epic’s underlying database. A universe is a Business Objects tool that is a logical layer between a database and the user querying the database. This layer hides the typical database structure from the user to make it easier for the user to select the data elements for a report and join those elements to perform analysis. In technical terms – a universe defines the joins between tables in a relational database so when the data elements are placed onto a report, the SQL query is created dynamically behind the scenes to support the report.

MD Anderson currently has more than 40 universes. Each universe organises information about a particular topic. The Enhanced Recovery Universe was built in-hospital and combines all essential Enhanced Recovery variables from various universes into one universe, effectively reducing the time needed to create or run a report (Gertz, 2011). The universe allows for drag-and-drop query building that generates complicated, behind-the-scenes SQL language in real time. Whereas EHR systems utilise database management systems that store information (e.g., flowsheets, orders, medication administration records) in a relational format of tables, columns, and rows, the universe provides a logical layer between this system and the end user.

Several universes, each with its own objective field of data support, are already in use at MD Anderson. For example, the Anesthesia Universe, which obtains anesthesia data from the Epic application, can include data such as event times, providers, intra-operative medications, intra-operative fluids, and primary procedures. In contrast, the Patient Universe can pull demographics, registry information, allergies, hospital admissions, outpatient visits, and emergency department visits. Providers can be readily trained on each of these tools, thereby gaining greater efficiency in the management of patient cohorts. To manage ERP cohorts, however, a user must interact with five different universes to acquire every data element required for an ERP protocol. Interacting with multiple universes requires training in each one, and this may delay users in becoming proficient at them or may discourage them from investing the time to learn the programmes; for example, most institutional users do not utilise the universes and instead resort to manual chart review for data abstraction.

Literature on the management of ERP-specific databases is limited (Currie et al., 2019; Grieco et al., 2020). Therefore, we sought to consolidate all relevant structured data pertaining to enhanced recovery into a single tool that would allow for simple, intuitive query building. This desire for greater efficiency led to the inception of the ERP Universe, a first-of-its-kind query tool that can be used to obtain all data elements identified as essential in an enhanced recovery protocol. The aim of this article is to highlight the development of the ERP Universe and the benefits of its use.

Method

The Enhanced Recovery Universe project was approved by the MD Anderson Cancer Center Quality Improvement Assessment Board which is responsible for reviewing projects to: assure patient safety; optimise the potential benefits being sought; and discern which projects may be more appropriately designed or categorised as research studies requiring Internal Review Board oversight. To develop the Universe, our multidisciplinary workgroup of physicians, analysts, and information technology professionals reviewed nine established individual ERP team databases and data capture processes from June 2018 to June 2019. The multidisciplinary workgroup members were selected based on knowledge level and content expertise for data processes in the EHR system. All members were experienced end users of the current five-universe or manual abstraction data process. There were nine surgical service lines with established ERP programmes at the time of the inception of this project, all of which had an individual ERP team database. The nine surgical service lines were Thoracic, Spine, Bladder, Gynecology, Pancreas, Colorectal, Breast, Neurology and Head and Neck. We identified common variables across all service lines to create one standard data dictionary of ERP-specific variables. The data dictionaries for the different clinical databases were reviewed and compared in order to identify the variables or data elements that were common among them. As an example, for demographic and clinical characteristics all teams collected the American Society of Anesthesiologist (ASA) physical status, while only some collected the Eastern Cooperative Oncology Group performance status. Therefore, ASA was identified as a common variable. Similarly, within the anesthesia variables, all teams collected anesthesia/surgical times and fluid balance variables whereas there was no consistency regarding medications collected except for intraoperative opioids. Decisions were made to consider common variables anesthesia/surgical time, fluid balance and intraoperative opioids. To address data automation, all variables were mapped within the EHR and consolidated from five universes into a single universe.

To assess the efficiency of the ERP Universe we compared it with two other ERP data capture processes: a manual process and a five-universe process. The manual process consisted of using the EHR system to perform a manual chart review to capture the patient data. The five-universe process consisted of building eight separate queries to capture all ERP patient data elements from multiple universes. The ERP Universe process consisted of running a single query within the ERP Universe to capture all ERP data elements. Four experienced research coordinators used each of the processes to obtain data for 10 randomly selected surgery patient records from three participating ERP service lines (Pancreas Surgery, Bladder Surgery, and Gynecological Surgery). Each of these service lines utilised a different clinical database. Variables collected included demographic and clinical characteristics, anesthesia data elements (surgical times, fluid balance, intraoperative opioids) and postoperative medications. A REDCap database was created containing all variables of interest. Each coordinator entered the variables for the selected patients. The time it took each coordinator to use each process to review each patient’s data was recorded and timed in minutes. The REDCap time stamp logging system was used to calculate time for all three methods. Additionally, a timer was used to record time taken for running the five-universe and ERP universe query and added to the REDCap time calculated above.

Results

To increase data access and facilitate self-service data abstraction, the workgroup produced standard, validated institutional ERP reports geared towards programme compliance, finance, operations, and clinical outcomes. Our review of nine established individual team databases identified 120 common data elements compiled into 20 variables (Table 1) across all service lines. These common variables were included in the ERP Universe.

OPEN IN VIEWER

Table 1.

Enhanced recovery program compiled data variables.

Variable name	Source universe
Patient name (last name)	Anesthesia
Patient name - (first name)	Anesthesia
Birth date	Anesthesia
Sex	Anesthesia
Ethnicity	Anesthesia
Primary race	Anesthesia
Patient marital status	Patient
Height (cm)	Anesthesia
Weight (kg)	Anesthesia
American society of anesthesiologist physical status	Anesthesia
Primary surgeon	Anesthesia
Resp Anesthesiologist name	Anesthesia
Anesthesia start time	Anesthesia
Induction	Anesthesia
Intubation	Anesthesia
Incision	Anesthesia
Proc end	Anesthesia
Extubation	Anesthesia
Anesthesia stop time	Anesthesia
Blood product	Anesthesia
Labs	Patient warehouse
Medication name	Orders
Morphine equivalent daily dose (MEDD)	Orders
Pain score	Patient
Lines, Drains and Airways type	Acute care
Warming	Anesthesia
Core temp	Anesthesia
Transfusion management	Orders

For the manual chart abstraction process the average time for collecting data for all 10 patients among the four study coordinators was 510 min. For the five-universe process the average time, which included time needed to execute eight separate queries to capture all ERP data elements, was 111 min. In contrast, the ERP Universe required only one query to capture the same data elements, resulting in average collection time of 76 minutes—a 32% reduction compared to the five-universe process (Figure 1). Inter-rater reliability was calculated to capture variables times for the data extraction process (Figure 2). Overall, shifting the process completely from manual data abstraction to the ERP Universe approach resulted in time savings of 434 minutes—an 85% time-reduction. At the time of this analysis, only three teams were using the five-universe process to capture ERP data elements; all other teams were using a manual chart review process.OPEN IN VIEWER

OPEN IN VIEWER

Figure 2.

Inter-Rater Reliability.

Discussion

Our implementation of the ERP Universe, a data system designed to serve as a central repository for all ERP-relevant data, proved successful for several reasons. Most notably, transitioning from a manual process to the use of the single universe reduce the time necessary for data abstraction. In addition, streamlining the data process into a single universe increased reporting capability to support ERP protocols in daily operations.

A standard data dictionary was established and validated to ensure appropriate EHR mapping, reporting, and analysis. The ERP Universe reduced process redundancy by eliminating some of the steps necessary to compile relevant data, including accessing different universes to create multiple queries. The ERP Universe also reduced user error: it created a unique identifier that could be applied to multiple reports within one universe, and without the need to generate individual queries multiple times across several universes.

The ERP Universe also had a positive impact on personnel workload. The ERP Universe enabled an 85% decrease in data abstraction time, which allowed departmental personnel to be reallocated from data sourcing and management activities to other duties and tasks. Personnel costs often present a significant barrier to enhanced recovery implementation and sustainability (Stone et al., 2016; Kruse et al., 2020). The ERP Universe can help overcome this restriction by diminishing personnel resource needs. Although building the ERP Universe was resource-intensive, a future return on this investment could be realised. Previously, ERP data processes were supported by a small cohort of data managers and analysts funded by individual services or departments. Because the ERP Universe is available to all ERP stakeholders at MD Anderson, it allows for the employment of a smaller contingent of institution-level analysts in lieu of these service- and department-level analysts.

The ERP Universe also allows for the expansion of data operations. While we acknowledge the small sample size, the implication of time saved by usage of the ERP universe is exponential. There would be no significant difference between running a query containing 10 or 500 patients using this method, whereas in manual entry the increase in time spent in acquiring data is linear. We found that cohort size did not limit data analysis at the micro or macro level, indicating that the number of patients queried does not impact the timeliness of the data abstraction. We also found that using the single universe could facilitate upgrades to Epic. An Epic upgrade may change data mapping, necessitating updates and re-validation of data within the universes and underlying queries. The five universes previously in use by the ERP would have had to been updated individually, but with the single ERP Universe, this task can be performed more quickly.

Few studies have demonstrated the benefits of a single universe that can not only support research efforts but also facilitate internal benchmarking, quality improvement, institutional reporting, and clinical operations and decision-making. In one internal analysis, Kruse et al. found that a lack of data collection resources, standard processes, and reporting mechanisms limited data management in an ERP and recommended that improvements be made with minimal operational disruptions and costs (Kruse et al., 2020). The findings of the present study show that the single ERP Universe allows institutional ownership of the data to support not one service but an entire program. This not only reduces the need for individual data resources at the service or department level but also enables centralised data management and metrics reporting. Furthermore, our findings show that the ERP Universe upholds data integrity by storing data internally, without the need to share data with external companies or organisations (and pay the associated fees).

Conclusion

The single ERP Universe improved systematic data collection and analysis and the reporting of ERP elements without increasing operational costs or interrupting existing workflows. This simplified process increased data abstraction efficiency in the form of time savings. Other institutions should consider a similar data approach as data increasingly becomes a valuable commodity. Data entry, abstraction, and analyses should be standardised to ensure a high level of reporting and data integrity.

Although building and implementing an ERP universe requires a resource allocation investment, the long-term benefits of data standardisation can present quality improvement opportunities, which ultimately lead to greater outcomes under value-based care models. We recommend undertaking further studies to ascertain the ERP Universe’s return on investment and its potential to be expanded into non-surgical service lines.