One problem with relying on electronic health record (EHR) data as part of a longitudinal data collection strategy is obtaining data from all the sites where a patient is treated. How does the study team obtain EHR data from a hospital that is outside the participating healthcare system? If a patient has a heart attack while on vacation, how will the study team capture that information? It is generally recommended to use multiple mechanisms to obtain secondary use data on longitudinal outcomes, such as directly from patients via a mobile app or call center, or through sources like administrative claims.

An important factor with EHR data, compared with sources like administrative claims, is that there is considerable variation in the ways data are captured in the EHR, as well as the terminologies used to represent those data. This challenge makes harmonization a key step in the use of EHR data. Although the Office of the National Coordinator for Health Information Technology (ONC) is creating a framework for greater standardization and research capacity for EHR systems, the use of these standards is variable across the healthcare industry (ONC 2022).

The “Data Formats” section of this chapter describes some of the common data formats that are used to represent real-world data. This section describes some of the challenges that arise in obtaining EHR data from the enrolling healthcare system and other healthcare systems for 3 of the most frequently used approaches: (1) database extraction from individual sites, (2) use of a common data model (CDM), and (3) use of an application programming interface (API).

Database Extract

One of the more straightforward approaches for obtaining EHR data is to work with a site’s IT staff or an EHR vendor–based IT resource to generate a database extract at a given site. These extracts, which often are delivered as flat files or database tables, can be large in scale and automated, but complex queries rely on the skills of the local analyst, and extracts are more difficult to do at smaller sites that may not have the resources (Marsolo 2019). Hence, while this method requires fewer site resources than something like a CDM, it still may have limited applicability in multicenter pragmatic trials.

Common Data Model

Information can be recorded in different ways across sites (and across diagnoses). Sites that participate in distributed research networks (such as PCORnet and Sentinel) and national registries (such as the American College of Cardiology’s National Cardiovascular Data Registry) have agreed to harmonize their source data in a prespecified way by using a CDM. CDMs that are populated from sources like EHRs and administrative claims typically contain data that are captured in those sources in a structured format (such as diagnoses, procedures, laboratory results, medication orders, and medication administrations). Information captured in an unstructured format or with varying reliability may not be present in a CDM. For example, if a cause for an event is needed, the level of specificity required may or may not be available in the CDM because of variability in how that information is documented in the source system. In such cases, manual chart review may be a more efficient way of obtaining the cause of an event.

CDMs often use standard controlled terminologies to represent data, such as ICD-10 codes for diagnoses or RxNorm or the National Drug Code (NDC) for medications. However, these terminologies alone do not guarantee that data from different facilities are comparable. For example, different site coding practices can cause differences in whether patients are counted as having one condition vs another. Moreover, CDMs require mapping data from an EHR repository or institutional data warehouse to the target definition. In many cases, the latter is a more abstract model, and useful context and other detail can be lost in mapping the data to the CDM (Garza et al 2016). As an example, the encounter endpoints that include hospitalization for PCORnet and Sentinel’s CDMs are described below.

Sentinel is a US medical product surveillance system designed to monitor medical products regulated by the US Food and Drug Administration. The Patient-Centered Outcomes Research Institute (PCORI) funded the National Patient-Centered Clinical Research Network (PCORnet) to build a network-of-networks to support clinical research. Their CDM was built based on the Sentinel model but was extended to support many of the data elements found in EHRs. The table below shows the “type of encounter” definitions for the Sentinel CDM and PCORnet.