Skip to main content
eGEMs logoLink to eGEMs
. 2013 Dec 18;1(3):1024. doi: 10.13063/2327-9214.1024

Developing a Fully Integrated Medical Transport Record to Support Comparative Effectiveness Research for Patients Undergoing Medical Transport

Andrew P Reimer 1, Elizabeth Madigan 1
PMCID: PMC4371417  PMID: 25848576

Abstract

The consolidation of health care systems to develop centers of clinical excellence has led to an increased reliance on medical transport to move patients requiring time-sensitive interventions and specialized treatments. There is a paucity of outcomes data, specifically comparative effectiveness research, related to the efficacy of different transport services and the overall morbidity and mortality of patients that undergo medical transfer. The rapid development of electronic medical record (EMR) use has also occurred with transport charting. However, limited studies have incorporated transport chart data in outcomes analyses. We have begun development of a fully integrated medical transport record, combining transport and hospitals EMRs, to support research efforts and develop clinical decision support tools for transported patients. In this paper, we describe the elements necessary to develop a fully integrated medical transport EMR to support the conduct of comparative effectiveness research, outline the current limitations and challenges, and provide insight into the future direction in developing clinical decision support tools for patients requiring transport.

Keywords: Methods, Comparative Effectiveness, Health Information Technology

Introduction

Health care systems are increasingly developing centers of excellence for conditions such as stroke, trauma, and cardiothoracic surgery. These centers of excellence provide the ability to deliver highly specialized care while improving outcomes because of the high volume of patients treated. These specialized centers are commonly located at large academic tertiary medical centers in urban settings, often limiting access to timely care for patients residing in more remote areas, especially for time-sensitive conditions and treatments. As a result, air and ground medical transport has become a critical component for transferring patients to these centers to receive highly specialized care. Several studies provide evidence of positive outcomes for the transfer of patients who are experiencing time-sensitive emergencies such as trauma1 and myocardial infarction.2, 3 However, other studies have reported that some patients experience worse outcomes after undergoing critical care interfacility medical transport when interventions are not time sensitive,4, 5 with relative mortality rates ranging from 30 percent to more than 100 percent higher when compared with patients who were not transferred and directly admitted to an intensive care unit. Therefore, the purpose of this project is to merge electronic data sources for patients who undergo critical care interfacility medical transfer to create a fully integrated medical transport record to support comparative effectiveness research (CER) efforts.

Identifying the factors that contribute to increased mortality for patients who undergo critical care interfacility transport has proved difficult. One recognized limitation is related to the sources of data that have been used for analyses thus far. Data currently used include the Health Care Cost and Utilization Project national and individual state databases, national trauma registries, and registries of ST elevation and myocardial infarction. While useful to support large study sample sizes, these registries and databases often lack important variables for assessing outcomes specific to transported patients, including why the decision to transfer was made, what mode of transport was used, composition of the transport team, transport distance, and intratransport data that include interventions and vital signs. Transport data are now readily available in transport-specific electronic medical records (EMR). The primary challenge is the interoperability of the transport EMR with the hospital EMR, because the transport EMRs are created by proprietary third-party programs.

Recent research efforts focus on leveraging the large amount of data that is available to conduct CER and to develop clinical decision support tools. Merging the multiple data sources to support research and clinical decision support tools related to patients undergoing transport will require a multidisciplinary team. Combining these multiple, disparate data sources to enable CER can be accomplished via a fully integrated medical transport record. Development of a fully integrated medical transport record will provide the ability to address the complex questions related to patient’s clinical outcomes in a real-world clinical setting while providing a scalable electronic infrastructure that can provide high-quality, clinically rich, prospective, and multisite data collection for generating internally and externally valid conclusions in a timely manner.6 We have begun developing a fully integrated medical transport record that includes the electronic patient transport chart, and in this paper we present the challenges we are facing.

Setting

The setting for this project is the Cleveland Clinic Health System situated in northeast Ohio. The Cleveland Clinic is a regional health system with a main campus located in Cleveland, Ohio. The main campus is a quaternary center that has approximately 1,300 beds and serves as a regional referral center for critically ill or injured patients. The health system also includes 10 community hospitals and 14 family health and ambulatory surgery centers. Approximately 350 patients are transported monthly by the hospital-based critical care transport team via ambulance, helicopter, or jet from Cleveland Clinic and non–health system hospitals.

Method

The first step in developing the fully integrated medical transport record was data matching. The first phase of development used three primary data sources: (1) the hospital-based transport team’s mission log based in Excel, (2) the transport EMR data provided via Golden Hour7 charting systems, and (3) the Cleveland Clinic health-system Epic EMR. The fully integrated EMR is SQL based and is stored on a local server. All patients referred for transfer to Cleveland Clinic are included. Only patients transported by Cleveland Clinic’s critical care transport include the transport EMR. All patients transported by other transport programs are represented by the transport mission log referral data and main campus Epic EMR data.

Development and Challenges

Identification of Data Sources

Developing the fully integrated medical transport record requires the incorporation of individual data sources that exist across three primary domains: referring hospital data, transport data, and accepting hospital data (Figure 1). Within each domain there are individual sources of data that include patient charting, laboratory, pharmacy, vital signs, and demographics, to name a few. Given the breadth of data sources and scale of this project, we will focus on the first phase of development that incorporates data from the transport and accepting hospital domains. The next phase will include incorporating the EMR data from referring hospitals within the same health care system, completing the incorporation of data through the patient’s entire episode of care—from initial hospital admission at the referring hospital through transport and then eventual clinical disposition at the accepting hospital.

Figure 1:

Figure 1:

Primary Data Sources Incorporated into a Fully Integrated Electronic Medical Record (EMR)

EMR = electronic medical record

Incorporating transport data was the most difficult. Transport data include two sources: (1) the mission log from the hospital-based critical care transport team, which serves as an activating source to initiate a patient record for inclusion; and (2) the transport chart with all data related specifically to the transfer of the patient, including the variables identified as necessary to conduct more robust outcomes analyses. The transport mission log contains one entry per mission request and is used to initiate a new record in the system for each entry in the log. The transport chart contains data that include vital sign monitoring, interventions and medications provided, and the patient’s response to transport. The transport chart data are available via a third-party EMR that is not compatible with the Epic EMR used in the health system. Thus, a considerable amount of manipulation and restructuring was required to incorporate the data into the data warehouse.

Accepting hospital data sources include patient demographics, medical and surgical histories, procedures, laboratory, pharmacy, vital signs, billing data, and outcomes data. In the past, abstracting data from each of these sources was time-consuming and expensive, but recent work enabled through internal institutional funding has optimized the usability of the data from the clinical EMR for download into registries and study databases. The new streamlined process entails identifying each data source that is necessary, submitting a data request, and then downloading the data to the local data warehouse. Each data source is then provided as an individual table at the patient level.

Data Sources and Challenges

The primary challenge in conducting outcomes analyses of transported patients has been incorporating the patient transport EMR. Previous efforts have largely ignored these data because of the inability to obtain the physical chart or resource and time limitations in manually abstracting chart data. Most transport charting systems are now electronically based, enabling the user to incorporate the chart in electronic format. However, there are several companies that provide standardized transport charting programs, all of which are independent from any one of the hospital-based EMR systems.

Another problem was the availability of data export structures. Although XML data exportation is available, the size and structure of the data tables limited online generation and downloading when variables that had multiple entries such as vital signs and medications were included. Also, each individual patient chart download generated varying column structures between patient charts due to charting differences on differing patient types. For example, a table generated for a neonatal transfer varies greatly in the data columns that are generated when compared with a table generated for an adult stroke patient. As a result of this limitation, considerable time was invested in developing individual data download templates that created a new near-flat table structure that assured consistent column structure for each table download. Deconstructing and developing the data model for all of the variables available for inclusion from the patient chart into near-flat table structure format generated 42 individual tables. The 42 tables are static when downloaded and include several months of transport data in an individual table request download that can be completed in 1–5 minutes as opposed to 5–10 minutes per chart prior to the individual table formatting.

Matching Data Sources

A deep description of EMR terminologies and ontologies is beyond the scope of this paper, but are required to structure terminology to provide for similar definitions between two or more EMRs. The definition of one term in one EMR needs to map to the same term in another EMR. This mapping then guides the software linking the data sources to allow for interoperability. For example, the HL7 organization (Health Level Seven International) has developed a clinical data architecture standard that “specifies the structure and semantics of ‘clinical documents’ for the purpose of exchange between healthcare providers and patients.”8 HL7 standardization will be addressed in phase II development of the fully integrated medical transport record.

The transport mission log is the first table in the structure of the database (Figure 2). Each entry is a request for transfer and activates the system to then link to the next data source, the patient transport EMR. Considerable effort is required up front for exporting the transport mission log for use in the fully integrated medical transport record. Initial transport team compliance of accurately completing the transport mission log ranges between 90 percent and 98 percent. Manual review by a department billing and coding analyst is completed monthly to reconcile any missing data that were not initially entered. Once the monthly quality assurance check is complete, the mission log is exported as an individual table. Linking between the transport mission log and transport EMR was accomplished via the following linking variables: patient medical record number (MRN) at accepting hospital + transport date + last name + first initial. This linking algorithm automatically matched 98 percent of the records between the transport mission log and the transport chart.

Figure 2:

Figure 2:

Stage I—Data Management Structure

EMR = electronic medical record

MRN = medical record number

The next link is adding in the accepting hospital Epic EMR, which includes each table listed in the accepting hospital domain. Interoperability between the transport EMR and the Epic EMR is the primary challenge for this project. Initial efforts to link the Epic records yielded a 90 percent match for each originating MRN from the transport mission log. The primary discrepancy was between the initial MRN that is assigned to a patient during the transfer request with the final MRN that is permanently assigned. These discrepancies occasionally develop when a new MRN is issued upon the transfer request and is then later reconciled within the Epic system to a previously established MRN. Other discrepancies are simply due to transcription error at the time of referral into the transport mission log that is then continued to the transport chart. Once the permanent medical record has been established and linked to the Epic EMR, a patient encounter number that is directly related to that patient’s episode of care related to the transfer is entered into the system. The encounter number then pulls each of the tables listed in the accepting hospital domain from the Epic EMR into the data warehouse.

Data Management

Because no previous registry was available, building the fully integrated medical transport record required us to develop a new data model. The data is managed via a relational Oracle database. Individual data sources included in the fully integrated medical transport record are maintained and stored as individual tables within the data warehouse. In production mode, the fully integrated medical transport record is locked and only allows data inquiries from registered users. Current access is limited to only the research personnel from the hospital’s transport team.

Unlinked and/or missing data occur at each phase of matching, with the most significant amount of unlinked data occurring when incorporating the Epic data tables. We are currently optimizing the linking algorithm to reduce the overall percentage of unlinked data during this phase. However, manual investigation and rectification of discrepancies between the transport mission log and Epic MRN need to be completed after each monthly upload of new data. A graphical user interface tool is being developed that flags each transport mission log entry that remains unlinked to an Epic EMR record; this tool will help an end user identify and correct each entry manually. Manual correction is simply accomplished by reviewing the available hospital admission records for the unmatched patient’s MRN, identifying the correct admission encounter number, and clicking the correct entry that automatically uploads the correct encounter number and related EMR into the data warehouse.

Duplicate data may occur in relation to the transport mission log and transport chart entries. Occasionally several entries can be generated for the same MRN on the same date. For example, one entry is generated for the dispatch of a helicopter, but when the helicopter experiences bad weather or mechanical problems en route, that helicopter will return to base and another helicopter or ambulance will be dispatched. This scenario can generate two or more transport records with the same patient MRN and transport date; however, only one transport chart will be generated that contains the 42 tables of patient information. Duplicate data within the fully integrated medical transport record will be cued to the graphical user interface tool for manual correction during each data check after each new data upload to the data warehouse.

Limitations

There are several limitations associated with this approach. The primary limitation is the use of the health system Epic EMR. Although Epic is commonly used in many hospitals and health systems, differences between Epic platforms can limit the generalizability of scaling this integrated EMR to include other health systems. The diversity of EHRs used by other referring hospitals will present another challenge going forward. Additionally, this database is specific to the hospital-based transport team’s unique clinical log and transport EMR templates, also limiting the generalizability of this approach. The database specificity could be overcome by transforming the data into a common data standard such as HL7. Although beyond the scope of this paper, transforming data using HL7 standards will provide the platform to exchange data with other health systems and transport providers and will be addressed in phase II development.

Future Development/Directions

Successfully completing phase I of developing the fully integrated medical transport record will provide the ability to conduct retrospective analyses of all data currently loaded into the data warehouse. Registered users will be able to query the fully integrated medical transport record via Tableau,9 which will allow the end users to search the data warehouse for available patient populations to assess the feasibility of conducting a study based on a particular research question. Once it has been determined that the sample size available is adequate to answer the research questions, that investigator can link the necessary data tables and generate a study database that is exportable to common statistical analysis programs.

Initial matching efforts yielded limited matches between data sources. After manually reviewing both matched and unmatched records, we were able to refine the matching algorithm and increase the matching efficiency to 90 percent matched. Validation of the fully integrated medical transport records will be conducted at completion of phase I via the standardized data quality assessment approach proposed by Kahn et al.10 Future efforts will include random record audits to validate that matched records are accurate, continued refinement of the matching algorithm, and incorporation of standardized variable formatting and value rules.

After phase I is completed, CER efforts can be initiated. The primary impetus for creating the fully integrated medical transport record was to develop a robust platform to support CER efforts across transported patient populations. The initial CER efforts will be focused on comparing similar patients that undergo non-urgent interfacility critical care transport by either ground or air to assess clinical outcomes between transport groups. Delineating whether patients experience improved outcomes when transported by one mode versus another has major implications for large health care systems and regional referral centers, as administrative and regulatory agencies continue to focus on cost-effective interventions and increasing the efficiency of health care delivery.

Results from the CER efforts will then be used to develop a triage tool. The large amount of retrospective data can be used to develop evidence-based guidelines to support triage decisions in clinical practice. Development of the evidence-based guidelines will include analyses for significant predictors of the appropriate level of care required during transport and the appropriate mode of transport given the patient’s current clinical needs. Clinicians could then use the evidence-based guidelines in the form of a triage tool to triage requests for transfers by providing data to support clinicians in deciding how (e.g., air vs. ground) and when to move a patient.

Phase II will involve transforming the fully integrated medical transport record data into the HL7 common data standard format to enable importing and exporting of data with other transport programs and hospitals. Transforming the fully integrated medical transport record into HL7 format will transition the EMR into a true electronic health record (EHR) and align with national health care reform initiatives for transportability of patient’s health care records. Completing the transformation of the data into HL7 formatting will also enable additional data collection with other hospital-based transport programs. Data collection during this phase will be facilitated by the common data set that is developed with the variables from the clinical triage tool. The collection of external transport program data can be facilitated through the Critical Care Transport Collaborative Outcomes Research Effort. The Critical Care Transport Collaborative is a multicenter research group of medical transport programs that contribute individual program data to specific studies that enables the development of a large nationally representative sample.11

Future development of the fully integrated medical transport record will focus on automating the system to incorporate data in real time as it is generated. Once automated, the fully integrated medical transport record will be able to support the development of dynamic clinical decision support tools. A dynamic clinical decision support tool would provide the capability of real-time query of the existing database via a computer-based triage tool that the clinical provider can complete as he or she receives patient information during the referral phone call. The system would then, in real time, process the current patient’s clinical information against previous similar patients’ clinical information contained in the database and recommend the appropriate level of care and mode of transport for the referred patient to optimize use of resources while maximizing patient care and clinical outcomes.

Conclusion

There is national interest and some progress on a health information exchange—a patient-specific repository that represents all the electronic health components for a particular patient, regardless of the provider. Much of the national attention has been understandably on hospital and primary care practice settings. However, a true health information exchange would include all components of the EMR, not just the hospital and primary care records. Because the transport period represents “critical care in the air,” the events, medications, and patient responses to treatment (to name just three) during this time should be represented in the EMR. As is common in other areas of health information technology, the exclusion of some segments of care diminishes the understanding of the treating clinicians in providing comprehensive care; it also reduces the likelihood of including all the relevant data and information for CER and quality improvement.

There remain substantial challenges and limitations to the development of a fully integrated medical transport record, including the potential for inaccurate data due to either human error (e.g., entering a weight of 2225 pounds for 225 pounds) or machine error (e.g., the medication component of the EMR is out of service for a specific period of time because of catastrophic error and the entry of medications is not completed before the data are pulled into the data warehouse). More specifically, there are several limiting factors that preclude the fully integrated medical transport record from becoming fully automated, those primarily being the need to manually incorporate the transport EMR and poor matching between the transport mission log and accepting hospital EMR MRNs.

As noted above, the interoperability issues required extensive and expensive programming within the health system. Terminology issues remain a challenge despite HL7 standards and national movements such as the creation of a Continuity of Care Document.12 A major advantage of developing a fully integrated medical transport record is that it includes all of the data sources related to a transferred patient’s entire episode of care and provides the broad clinical representation of the data, or data from “real-world” clinical settings. The data contained in the fully integrated medical transport record can support CER efforts, be rapidly translated back into practice, and support real-time clinical decision support tools. Despite the many challenges, the explosion of EMR data holds promise for improving our provision of patient care, the ultimate goal.

References

  • 1.Galvagno SM, Jr, et al. Association between helicopter vs ground emergency medical services and survival for adults with major trauma. JAMA. 2012;307(15):1602–10. doi: 10.1001/jama.2012.467. [DOI] [PMC free article] [PubMed] [Google Scholar]
  • 2.Fosbol EL, et al. The impact of a statewide pre-hospital STEMI strategy to bypass hospitals without percutaneous coronary intervention capability on treatment times. Circulation. 2013;127(5):604–12. doi: 10.1161/CIRCULATIONAHA.112.118463. [DOI] [PubMed] [Google Scholar]
  • 3.Grines CL, et al. A randomized trial of transfer for primary angioplasty versus on-site thrombolysis in patients with high-risk myocardial infarction: the Air Primary Angioplasty in Myocardial Infarction study. J Am Coll Cardiol. 2002;39(11):1713–9. doi: 10.1016/s0735-1097(02)01870-3. [DOI] [PubMed] [Google Scholar]
  • 4.Hill AD, et al. Interhospital transfer of critically ill patients: demographic and outcomes comparison with nontransferred intensive care unit patients. J Crit Care. 2007;22(4):290–5. doi: 10.1016/j.jcrc.2007.06.002. [DOI] [PubMed] [Google Scholar]
  • 5.Rosenberg AL, et al. Accepting critically ill transfer patients: adverse effect on a referral center’s outcome and benchmark measures. Ann Intern Med. 2003;138(11):882–90. doi: 10.7326/0003-4819-138-11-200306030-00009. [DOI] [PubMed] [Google Scholar]
  • 6.Randhawa GS, Slutsky JR. Building sustainable multi-functional prospective electronic clinical data systems. Med Care. 2012;50(Suppl):S3–6. doi: 10.1097/MLR.0b013e3182588ed1. [DOI] [PubMed] [Google Scholar]
  • 7.Golden Hour Live. 2013. [cited 2013 August 22]; Available from: http://www.goldenhour.com/clinical.html.
  • 8. HL7. Health Level 7 International. Clinical and Administrative Data Domains 2013 [cited 2013 April 4]; Available from: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7.
  • 9. Tableau. 2013 [cited 2013 April 9]; Available from: http://www.tableausoftware.com/products/desktop.
  • 10.Kahn MG, et al. A pragmatic framework for single-site and multisite data quality assessment in electronic health record-based clinical research. Med Care. 2012;50(Suppl):S21–9. doi: 10.1097/MLR.0b013e318257dd67. [DOI] [PMC free article] [PubMed] [Google Scholar]
  • 11. CCT CORE. [cited 2013 April 17]; Available from: http://www.cctcore.org/index-2.html.
  • 12. HL7. HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD). 2006; Available from: http://www.hl7.org/search/index.cfm?x-=0&y=0&criteria=continuity+of+care+document.

Articles from eGEMs are provided here courtesy of Ubiquity Press

RESOURCES