Case Example 33Challenges in Creating Electronic Interfaces Between Registries and Electronic Health Records

DescriptionThe IC3 Registry is a practice- based quality improvement program that aims to improve adherence to established, evidence-based best practices for the management of cardiovascular disease patients, as codified by nationally accepted performance measures for the treatment of patients with coronary artery disease, heart failure, hypertension, and atrial fibrillation. Data are collected by multiple means, including paper, a Web-based data collection tool, and electronic medical records.
SponsorBristol-Myers Squibb/Sanofi Pharmaceuticals and the American College of Cardiology
Year Started2008
Year EndedOngoing
No. of Sites173 practices in 48 States and 2 U.S. Territories
No. of Patients107,500 patient encounters


Nearly half of registry sites have some type of electronic health record (EHR) in place, and the creation of electronic interfaces between the EHRs and the registry would reduce the burden of data entry on participating sites. However, the creation of electronic interfaces between the registry and EHRs is hampered by the lack of generally adopted standards for data definitions, structure, and exchange. In addition, the inability to create robust interfaces is exacerbated by the fact that clinicians use EHRs in an ad hoc manner that is inconsistent across practices. EHR data collection is subject to data accuracy issues, largely arising from data entry errors that are not readily identifiable, as there are very few mechanisms for data validation. Lastly, the EHR environment is constantly evolving, so that there are frequent modifications in how the data are captured. Effective interfaces between the registry and EHRs are needed to reduce duplication of provider effort.

Proposed Solution

The IC3 registry was developed with these technological challenges in mind. The registry uses a standard set of 153 defined data elements and a structured XML format developed to facilitate export from various EHR systems. To address the EHR implementation issue, the registry has implemented robust data quality processes to review the data.


The integration of EHR data into the registry has proven enormously challenging due to both syntax and semantics issues. Because integration is not based on an open, adopted standard, each integration must be customized to the individual practice’s EHR, and the amount of information technology (IT) support at the practice varies significantly among sites. Data elements are also difficult to collect in a standard manner. For example, myocardial infarction may be defined differently within different vendors’ EHRs, and sometimes even within EHRs from the same vendor. The IC3 Registry took the approach of working directly with EHR vendors to certify that certain EHRs collect the registry data elements consistently according to registry definitions. Four EHRs are currently certified, meaning that they have embedded the prescribed data elements and definitions into their EHR. Unfortunately, this involves both custom effort by the EHR and inability to easily update the data dictionary.

The next issue involved transporting the data from the EHR to the registry. The registry tried using the continuity of care record (CCR) format, but found that this format is too often customized to meet the individual practices’ needs. Currently, the registry is working with a third-party company that provides data transfer services to physicians who wish to move from one EHR to another. This company has provided a data mapping technology that the registry can use to map data from an EHR to the registry.

Even when the data have been successfully mapped and transferred to the registry, there may still be hindrances to using the data in performance measures if the data are not from a certified EHR. Data from certified EHRs may also still be questionable, as it is difficult to assess whether changes made in the EHR were appropriately communicated to physicians, and whether physicians changed their documentation as a result. For example, an EHR may modify its definition of atrial fibrillation to conform to IC3 standards. But if the physicians do not change how they record the data, the data will still be inconsistent with the registry definitions. Data validation is difficult in these cases because there is no source documentation. Traditional methods of data validation are not feasible here, and there are few alternatives currently available.

These challenges demonstrate the need for generally adopted open standards to facilitate both data consistency and validation, and interchange between EHRs and registries. At the time of this case study, such standards were not broadly adopted in the EHR community.

Key Point

Effective integration of registries and EHRs requires standards for data definitions, structure, and exchange. These standards are critical for integration to become a viable method of reducing duplicate data entry.

From: Chapter 11, Interfacing Registries With Electronic Health Records

Cover of Registries for Evaluating Patient Outcomes: A User's Guide
Registries for Evaluating Patient Outcomes: A User's Guide. 2nd edition.
Gliklich RE, Dreyer NA, editors.

NCBI Bookshelf. A service of the National Library of Medicine, National Institutes of Health.