In Search of a Data-in-Once, Electronic Health Record-Linked, Multicenter Registry-How Far We Have Come and How Far We Still Have to Go.

The learning health system is a framework in which new knowledge is translated into general clinical practice and clinical practice serves as the engine to generate new evidence and knowledge. One type of learning health system is an electronic health record (EHR)-linked multicenter registry. Significant investment has been made in recent years to spur the adoption of EHRs and to fund the creation of health information exchanges. Yet, given this investment, are we any closer to achieving the vision of a learning health system? What are the areas of success? What challenges remain? To answer these questions and using an EHR-linked multicenter registry as a model, we define a set of requirements that need to be met in order to achieve the goals of the learning health system. We then evaluate progress along each dimension by detailing our efforts to create an EHR-linked multicenter registry for ImproveCareNow, a quality improvement and research network focused on improving outcomes for children with inflammatory bowel disease (IBD).

Introduction

The vision of many within academic medicine is to move from our current health system to that of a learning health system,1,2 where every clinic visit provides an opportunity to generate new evidence and knowledge. Advances in technology are a vital part of that transformation, with electronic health records (EHRs) and health information exchanges (HIEs) being two of the more critical components.3 Recent years have seen the widespread adoption of EHRs, which allow condition-specific information to be captured discretely at the point of care and then used for analysis and reporting. Major investments in HIEs and related technology now make it possible to share patient records between hospitals. With these new tools, are we any closer to a national learning health system, where data can be collected through routine clinical workflows and be used for clinical care, quality improvement and research, achieving the holy grail of data-in-once?4,5

Before we can begin to answer the above question, we need to define the form that a national learning health system might take. There are several possibilities, but this analysis highlights one in particular, EHR-linked multicenter registries, an area of recent investment by the Agency for Healthcare Research and Quality (AHRQ). From a technical perspective, such a registry could be implemented in a number of ways. Rather than dictating a specific approach, we focus on general requirements, defining a “straw man” architecture that could be used to instantiate an EHR-linked multicenter registry. This is followed with a discussion of the successes and challenges that we faced in implementing such a registry for ImproveCareNow, a 46-care center quality improvement and research network focused on pediatric Inflammatory Bowel Disease (IBD).6,7

Requirements for an EHR-Linked Multicenter Registry

In order to keep the list of requirements tractable, we will evaluate progress towards the implementation of a learning health system by concentrating on four specific areas: data collection, data transmission, data processing (i.e., data management), and analysis. We define minimum technical requirements within each area as follows:

The main data collection requirement is to provide users with the ability to capture condition-specific information in the EHR in a visit-based form. The data would be captured during the visit through routine clinical work-flows and it should be stored in a discrete format so it can be queried or extracted from the EHR. At the same time, the EHR should permit the data to be incorporated into a progress note or referral letter. The ability to modify the form from time to time, as the needs of the learning health system change, is also necessary. In the ideal case, the EHR vendor would support the form and would make new revisions available to its customers through its normal upgrade channels.

The needs of the ImproveCareNow registry are somewhat different from those of a traditional research registry. ImproveCareNow operates as a learning network where there is a continuous focus on improving the quality of care received by patients. The data used for research are the same elements that constitute “Model IBD Care.” As a result, these elements should be collected on every IBD patient during each visit. That is why it is important for the form data to be pulled into a clinic note or referral letter. If that capability were not present, clinicians would have to retype the data, posing a significant barrier to adoption.

It is essential to be able to send all form data, plus additional information captured in the EHR such as laboratory information and medication information, to a third-party server or remote application in as close to real-time as possible. For registry data to be used effectively for quality improvement efforts and clinical care, it must be received in a timely manner. Monthly extracts are not sufficient if the data are to be used for clinical decision support. When feasible, the data elements should be coded to a standard terminology to aid re-use and analysis across projects. Suitable terminologies include Logical Observation Identifiers Names and Codes (LOINC) for laboratory results or RxNorm for medications. The Systemized Nomenclature of Medicine – Clinical Terms (SNOMED CT) would be a logical choice for coding the form questions and responses, though it may not be suited to all conditions or specialties. Pediatrics, for instance, is notorious for a lack of standardized terminologies.

The third party receiving the data must have capabilities for data management, monitoring data quality, computing outcome and quality measures, and making treatment recommendations (i.e., decision support), again in as real-time as possible. Data management is crucial to monitoring the quality of clinical data. Given the often-chaotic flow of the busy clinic, providing repeated feedback on data quality is often the only way to avoid the problem of “garbage in, garbage out.” Due to the specialized nature of data management, the centralization of this function can provide an efficiency gain, particularly when dealing with large networks.

Not to be overlooked are the requirements for data security and data protection that govern both the transmission and processing of any personal health information (PHI). Federal regulations such as the Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health (HITECH) and state regulations often dictate the requirements for data security and data protection. Recognizing the complexity of data security/protection issues, this article does not address such matters but does stress that systems should be designed to minimize the amount of PHI that is transferred and that any transferred PHI should be encrypted. The preferred approach would be to either eliminate the need for PHI or to de-identify any PHI that remains. In addition, from a legal and regulatory perspective, the care centers participating in the registry and any external party providing data management or analysis services should execute business associate and data-use agreements to cover the registry’s functions (e.g., clinical support, quality improvement, research).

It must be possible to feed the information produced in the data processing step back into the source EHR, where it can be viewed and used in reports that are integrated into the clinical workflow. Examples include population management reports, which help identify high-risk subpopulations in need of follow-up care, and pre-visit planning reports, which provide patient-specific treatment recommendations based on a patient’s status for use in planning future clinic visits. In addition, provider-specific report cards can detail a provider’s performance against certain process or outcome measures as well as a provider’s performance against their peers.

Integrating reports into the EHR so they can be accessed as part of the clinical workflow is important for two reasons. First, if registries are used for decision support, the registry information should be included in the patient’s record so that clinicians do not run the risk of creating a “shadow chart.” Second, EHR integration increases the opportunity to identify and include the entire patient population in the registry, avoiding selection bias. Triggering registry enrollment through a problem list diagnosis, encounter designation, or other means would help narrow the gap between eligible and enrolled populations.

Successes and Challenges

Given the requirements stated above, is it possible to create an EHR-linked multicenter registry in today’s health care environment? What are the areas of success? What challenges remain? In the case of remaining challenges, are the barriers technological, social, or both? And, finally, is there any hope for change in the future?

In the sections below, we assign a grade—pass or needs improvement—to each requirement based on our experience in implementing the registry for ImproveCareNow. Even though the ratings are based on our experience, we believe that they are applicable to the larger health care landscape, given that the institutions participating in ImproveCareNow represent a wide cross-section of health care providers, from urban to rural, from public to private, and from large academic health centers to small private practices.

It is possible to satisfy the data collection requirement with today’s EHRs, though our passing grade comes with several major caveats. As part of our efforts with ImproveCareNow, we contacted the three EHR vendors that support the vast majority of the network: Epic, Cerner, and GE. Of the three, Epic was the only vendor that readily agreed to participate, providing internal (Epic) resources to create and support a form, which is now in production at several centers and undergoing implementation at several others. Though this form is targeted to ImproveCare-Now members, it is available to all Epic customers. Epic has also expressed a willingness to create subsequent revisions to the form based on the network’s evolving needs. Cerner and GE eventually agreed to support our efforts, which we greatly appreciate, though it took considerable time to identify someone willing to respond to our inquiries.

Given the demands on the various EHR vendors, one alternative to having them create the forms would be to have a care center create it and share the form definition with other centers that have the same brand of EHR. Such an approach is problematic, however, because the care center that creates the form would have to validate it through upgrades, assist with installation, troubleshoot problems, and perform other maintenance functions. It can be a major challenge to identify a center with sufficient expertise and bandwidth to assume such a role in view of competing priorities, such as Meaningful Use and the transition to ICD-10.

A third approach would allow EHR vendors to distribute the work involved in the creation of data capture forms without necessarily relinquishing control of the process. A single center could create the forms and then hand them off to the EHR vendor for support, perhaps for an annual fee to cover maintenance, distribution, and training. Modifications to the form could result in an additional charge. In addition to providing a healthy revenue stream for EHR vendors, such an arrangement would drastically lower the start-up cost for registries and networks. Instead of being installed and programmed at every participating center, forms would be programmed once and installed everywhere.

Even though the basic functionality exists within EHRs to transmit data in real-time to third-party servers, there are various limitations that prevent such transmission from occurring. For example, the Continuity of Care Documents (CCDs) that are frequently used to satisfy the data exchange requirements of Meaningful Use Stage 1 and to transfer information between health systems via HL78 include sections for allergens, medications, problems, and laboratory results. There is no natural home, for condition-specific form data, however. A program could be written to convert the form questions and responses into a text note for transmission as part of a CCD, but the information would later need to be parsed out before it could be stored. In addition, CCDs were largely designed as a mechanism to share summary clinical records between institutions or as part of a larger HIE. In many centers, attempts to leverage this operational infrastructure for research purposes will likely pose a challenge.

An alternative model of transmission could be to use web services, which are commonly used in web-based applications to send and receive data. Most major EHR vendors have some support for web services, though access is heavily restricted at most care centers. Further, allowing access to a remote application may prove to be politically untenable. In addition, at least one major vendor forbids the sharing of its “non-public” interfaces with non-customers, a potential problem if registry participants are customers of several EHR vendors. The Retrieve Form for Data Capture (RFD) protocol, 9 designed for clinical trials, could be another alternative, but it, too, falls short. RFD retrieves a form from a remote server and presents it within the EHR. Users complete the form and the results are sent back to the remote server. Unfortunately, none of the form data is persisted in the EHR, which is a necessity for clinical registries.

With the ImproveCareNow registry, we have elected to use the decidedly low-tech approach of having a research coordinator at each center generate a flat file from the EHR containing the form data that was collected during the previous week/day; the data are then manually uploaded to a website and transferred to the registry. This solution is not optimal, but, given the registry’s budgetary limitations and the social and technical challenges listed above, it was one of the few alternatives open to us.

The field of data management, well established within the world of clinical trials, now often supports quality improvement registries.10 The main challenge we have faced results from the desire for measures to be calculated in real-time rather than on a monthly or quarterly basis. The result is a tradeoff between the desire for data correctness and the desire for speed and automation. The other major challenge is associated with the query process for dealing with missing values or data entry errors. In a clinical trial, participants are obligated to correct errors. Such an expectation is typically not found in the case of a registry, where data collection is an artifact of the clinical workflow. One promising strategy that we have used involves sending exception reports to the centers that list their data entry failures. While centers may not go back and fix every issue, they can institute processes to prevent similar errors in the future.

While it is the dream of projects like SMArt to have third-party applications that can seamlessly integrate with many different EHRs,11 with most of the commercial products on the market today, the ability to write data and integrate external reports and recommendations, particularly from a third party, remains a practical impossibility. Barriers include concerns about allowing non-hospital IT staff to make changes to the EHR, the effect of integration on the stability of the EHR, responsibility for technical support of third-party applications when issues arise, and potential infringement on intellectual property. In time, these barriers may be broken down.

Until then, groups looking to create a similar system are left with the following options: (1) develop and host applications outside the EHR, recognizing that this results in a suboptimal workflow for clinicians; (2) work with each care center to deploy and integrate the application locally; and (3) work with each vendor to create a version of the tool for deployment to that vendor’s customers. The last option may not be technically possible for every vendor, so it still might be necessary for groups to work with individual care centers (option 2). In addition, not every care center may be interested in EHR integration, thus necessitating remote deployment (option 1). While we have settled on remote deployment for the current implementation of the ImproveCareNow registry, we hope to explore the possibility of vendor integration in the future.

Discussion

EHR-linked multicenter registries that are used for clinical support, quality improvement, and research are one approach to realizing the vision of a learning health system. Given the geographic distribution of care centers, the mix of EHR vendors, and the centers’ institutional characteristics, the participants in ImproveCareNow are fairly representative of subspecialty care at a national scale. Using the proposed framework of requirements to assess our experiences as a case study, we conclude that there is still a way to go before we can claim to have achieved a national learning health system.

For each of the required elements of the system—data collection, transmission, processing, and analysis—the necessary technical components exist, but a host of social and policy roadblocks remain. These roadblocks range from determining how to fund and use clinical or operational IT infrastructure for research purposes, to untangling the intellectual property issues that arise from interfacing external applications with proprietary EHRs, to developing the governance policies that allow for third-party integration without threatening the stability of the clinical infrastructure or leading to a loss of control. Federal regulations such as Meaningful Use may force a resolution of some of the issues, particularly around the sharing of patient data, but real change will need to come from the health care community itself.

We predict that a few enterprising health care centers will conclude that there is a business opportunity in developing and supporting learning health systems and that they will make it a priority to overcome the above barriers. Once they succeed, the rest of the health care community will be forced to play catch-up. Success will take an incredible amount of hard work and require the management of a number of competing forces, but the potential upside is enormous for patients, providers, payers, and the nation.