In summary, registries are patient-centered, purpose-driven, and designed to derive information on defined exposures and health outcome. In contrast, EHRs are visit-centered and transactional. Despite these differences, EHRs capture a wealth of data that is relevant to patient registries. EHRs also may assist in certain functions that a patient registry requires (e.g., data collection, data cleaning, data storage), and a registry may augment the value of the information collected in an EHR (e.g., comparative safety, effectiveness and value, population management, quality reporting).3
The Meaningful Use program (see Chapter 1) has propelled the development of both EHR-linked and EHR-integrated registries. For example, EHR-integrated registries have expanded to meet EHR certification requirements and to help health systems meet requirements for workflow efficiency and quality improvement to achieve value-based criteria (e.g., improving population health). EHR-linked registries have grown as the Meaningful Use program specifically requires the reporting of EHR data to external registries (e.g., public health registries, quality reporting registries).4 Meaningful Use Stage-1 provided an optional objective (which became a mandatory objective in Meaningful Use Stage-2) for eligible hospitals and professionals to submit EHR-extracted electronic data to immunization registries.5 Meaningful Use Stage-2 further expanded EHR reporting to cancer registries and other specialized registries (e.g., birth defects, chronic diseases, and traumatic injury registries).6
Driven in large part by Meaningful Use, EHR vendors and clinical providers are incentivized to develop processes that would facilitate the design and launch of EHR-based registries in the United States. Yet, despite these incentives, the practice of using EHR-based registries is still relatively immature and, like all evolving research programs, faces many challenges.7
The purpose of this chapter is to describe the opportunities and challenges related to fully integrating or linking EHRs and patient registries. The chapter reviews common and emerging EHR data types that can be incorporated in registries, provides sample use cases of integrating EHRs and registries, and proposes a series of hypothetical technical architectures to link or integrate a registry with an EHR. The chapter closes with a discussion of possible future directions for EHR-registry integration. Key questions to consider when planning to incorporate data from EHRs as well as other sources are provided in Appendix B.
EHRs provide various types of data that can be linked, integrated, or merged directly into a registry. The Meaningful Use program has led to the collection of a Common Clinical Data Set (CCDS) across most providers. These data are now generally available in EHRs; the data that are commonly available will likely continue to expand as Office of the National Coordinator, under the 21st Century Cures Act, moves toward building Core Data for Interoperability (USCDI) requirement.8 EHRs can also provide data types of emerging interest to registries. Both types are described in Tables 4-1 and 4-2.
In addition to these data, EHRs capture a considerable amount of unstructured data (e.g., clinical notes) that can be further processed to extract specific data of importance to a registry (e.g., specific information extracted from radiology reports to determine eligibility).
Data types commonly extracted from EHRs and imported into registries are patient identifiers, demographics, diagnoses, medications, procedures, laboratory results, vital signs, and utilization events. These are discussed further below.
Conditional to receiving proper consents and adhering to Health Insurance Portability and Accountability Act (HIPAA) policies,10 patient identifiers stored in EHRs can be used to merge patient EHR records with a patient registry. For example, a registry may collaborate with a statewide HIE to locate the master patient indexes of all registry patients and then ask multiple providers to locate the EHR records of those individuals using the HIE-issued patient master indexes. However, many registries do not have the option of acquiring master patient indexes from an HIE. These registries typically use alternative methods for matching patient identifiers and importing EHR data. Potential mistakes in matching registry patients with EHR patients may lead to quality issues such as incomplete or inaccurate data.
Coding standards for demographic data have been published but are not always used. Demographic data such as education and nationality are often not coded in a standardized approach. Age data are governed by HIPAA and have sharing limitations if they contain a certain level of granularity (e.g., age represented by the exact date of birth or if ages above a certain limit).17 Demographic data are often used by registries to match patient records across data sources. Thus, legal limitations to sharing demographic data may hinder the development of multi-source/multi-site EHR-based registries that require demographic data for these purposes.
In addition to diagnosis, registries often use medication data as eligibility criteria. Many registries also capture medication data to study treatment effect and/or safety. EHRs contain information on prescriptions that are written, while pharmacy claims data contain information on prescriptions that were filled. When EHR medication data are coupled with pharmacy claims data, a number of important constructs, such as medication adherence and reconciliation rates (e.g., medication regimen complexity index)24 can be derived and reported to a registry.
Potential semantic interoperability issues may arise when medication data are combined from multiple sources and mapped from one coding system to another. For example, an RxNorm code (drug class) may map to multiple NDC codes (packaged drug). Furthermore, some EHR-derived medication information may not be specific enough for research purposes (e.g., data on generics, like biosimilars, generally do not reflect which generic product was supplied to the patient).
Procedure data include clinical procedures such as surgery, radiology, pathology, and laboratory. Procedure data can be extracted directly from EHRs and reported to registries; however, procedures reported from one EHR generally only include those procedures taking place within the premises of a provider using the same EHR and may not include procedures that occurred elsewhere.
Currently, the best sources of laboratory data are the information systems used by standalone laboratories, which are frequently but not always incorporated into the EHR. Laboratory data include both lab orders and lab results. Coding standards for lab orders and lab results include the Logical Observation Identifiers Names and Codes (LOINC),30 the Systematized Nomenclature of Medicine (SNOMED),20 and the Current Procedural Terminology (CPT).28 Currently, there are no mandated laboratory coding system for certified EHRs, and the majority of healthcare providers rely on local coding systems for lab orders/results. This limits the interoperability of multi-site EHR-derived lab data for registries.
In addition, different healthcare facilities may use different laboratory tests to measure the same analyte, each of which has a different laboratory code. Discussion is needed across the provider network on how to link lab items, preferably using automated tools and not a manual process, so that a single query across the network will return all the desired data from multiple EHRs for a single registry. In addition, certain lab results are protected by federal and state laws (e.g., lab tests revealing HIV status) and thus might be missing from EHR-extracts reporting to external registries. Further, some laboratory data are accessible to clinicians without incorporation into the EHR; in fact, some lab data require active steps by the clinician to import into the EHR. Inaccurate interpretations may be made without understanding why some lab data are missing from an EHR.
EHRs are a primary source of vital sign data. Vital sign data include physiological variables such as height, weight, body mass index, pulse rate, blood pressure, respiratory rate, and temperature. LOINC is the common coding standard for vital signs. Most provider organization, however, do not actively use LOINC codes to capture vital signs in their EHRs as it is not mandated by the Meaningful Use program.
The completeness of EHR-derived vital signs such as height and weight is often acceptable for use in registries. Issues with human errors and units of measurement may affect data quality; thus, data cleaning is essential before use for registries.31 For example, weight and height data may include incorrect units (e.g., pounds reported as kilograms). EHR also may lack proper meta-data that are important for the clinical interpretation of the data (e.g., sitting versus standing blood pressure measurements).
There are no specific standard utilization coding terminologies for EHRs; however, most EHRs adhere to the utilization guidelines of claims submission policies. A number of reimbursement policies recommend specific reference-coding systems to encode utilization events. Certain utilization events are protected by various federal and state-level laws (e.g., mental health visit), and a registry may not receive utilization data related to those conditions from an EHR.
Survey data are usually collected from self-reported questionnaires; however, clinical data captured by surveys are increasingly stored within EHRs for various purposes. Some EHRs provide standardized surveys that can be accessed via patient portals to capture patient reported outcomes or symptoms (i.e., Patient-Reported Outcomes Measurement Information System or PROMIS).32 Risk factors and self-reported behaviors often are important to registries, and such data can be derived from EHR-integrated surveys (e.g., smoking status, socioeconomic status, housing condition). Also, registries may add and integrate their own customized questionnaires in EHRs so that patients can directly enter the necessary information needed for a registry (e.g., determine eligibility; collect additional data for a study).
3a8082e126