Interoperability between electronic health record systems has the potential to benefit patients, payers, health systems, researchers, and clinicians because interoperability enables data gathered as a part of care to be used to support care between systems, quality improvement, and research.  However, in actual practice, interoperability has been hard to achieve.

Historically, the focus of interoperability of data has been on the ability to share information between settings, and the strategy has been to identify various standards for data (eg, data formatting). Over the years, these standards have become more mature, and health organizations have growing incentives (due to both regulation and changes in healthcare reimbursement, and payment to reward quality care) to share patient data across care teams and organizations.

A final rule to implement provisions of the 21st Century Cures Act was intended to advance interoperability and support the access, exchange, and use of electronic health information by patients and their caregivers. The rule establishes the United States Core Data for Interoperability (USCDI) standard, which sets forth data classes and elements that support nationwide interoperability; it also includes a broad range of data elements, such as clinical notes, test results, and medications. Specific standards that are mandated as part of the final rule include:

• Systematized Nomenclature of Medicine – Clinical Terms (SNOMED CT)
  • SNOMED is a standard set of clinical terminology that includes clinical findings, disorders, and observable findings related to health, designed to support electronic health information exchange.
• Logical Observation Identifiers, Names and Codes (LOINC)
  • LOINC is a standard that allows users to map health data, such as labs, vital signs, and clinical documents to support data exchange across systems.
• RxNorm
  • RxNorm is a free, publicly available resource from the National Library of Medicine that provides “normalized” names and unique identifiers that make it possible to clearly identify a given drug. RxNorm coding allows information about medications to be exchanged across EHRs.
  • Concept Unique Identifier (RxCUI)
    • The RxCUI is a unique, unambiguous identifier that is assigned to an individual drug entity in RxNorm and used to relate to all things associated with that drug. The RxCUI is used to link one entity in RxNorm to every other entity it’s related to, such as name to ingredient to class.
• International Classification of Diseases, version 10 (ICD-10)
  • Provides standard codes for medical conditions, diagnoses, and institutional procedures

While having a defined interface standard solves one part of the interoperability problem (ie, syntatic interoperability), as long as data are natively captured in nonstandard formats such as using local codes for greater specificity, they will need to be mapped to terminologies before they are truly interoperable (ie, semantic interoperability). Previous federal attempts to foster interoperability resulted in highly variable implementations (D’Amore et al. 2014), so study teams should be prepared to validate the data that they receive via these new interfaces. Additionally, teams on retrospective studies also should be prepared to budget for staff to map internal use codes to standard terminologies. There have been efforts to define more standardized content that are exchanged between systems, such as through the US Core Data for Interoperability (USCDI), so the situation may improve over time. These efforts may have limited impact on data that have been previously collected, so teams on retrospective studies also should be prepared to budget for staff to map internal use codes to standard terminologies.

Historically, the exchange of data within the healthcare industry for operational purposes has occurred via the exchange of messages that often looked like structured documents, while researchers would often receive population or cohort-level extracts from reporting databases or data warehouses.  More recent efforts have established the use of techniques like application programming interfaces (APIs), which tend to send and receive data in more piecemeal fashion (e.g., a record or an observation at a time).  APIs provide a standard interface, make it easier to develop new applications that can interact with healthcare data, but given that data are requested an observation or a record at a time, it can be more difficult to understand the information that is NOT being delivered. For instance, if an investigator were interested in receiving hemoglobin lab results for a set of patients using an API, they would requesting results via a LOINC code.  That would return the lab results that have been mapped to LOINC, but they would not have knowledge about any hemoglobin tests that were not mapped to LOINC by the institution, for instance any historical results that were only mapped to an internal code or reference. Ideally all of them will be captured, but it is possible that the data were generated starting on the day they turned on the interface (ie, only prospective results), or perhaps represent results from the most recent lab system upgrade. Since it is not possible to request all data for an entire population via an API (the way data would be validated by looking at trends and distributions if extracted via a database), users view results one patient at a time, making it very difficult to identify problems since any given patient may have significant gaps in their data due to normal practice patterns. While the use of APIs and the adoption of standards like the USCDI have been generally positive for the healthcare industry in terms of standardization, we are still in the early stages, somewhere between “buyer beware” and “trust, but verify.”

Additionally, care must be taken to make sure that information collected at one site actually matches information at another site. The process of extracting, transforming, and loading data from one system to another can require the “janitorial” work of mapping and data cleaning (Lohr 2014).

To advance interoperability among EHRs and registries, the Pew Data Interoperability Project was developed as a collaboration between the Duke Clinical Research Institute and the Pew Charitable Trusts. In a Grand Rounds describing the project (Envisioning Data Liquidity – The Pew Data Interoperability Project). Dr. James E. Tcheng, suggests that standardization is best accomplished through “native” data standardization, as opposed to standardizing data after it has been collected. For registries, the keys to success are well-defined clinical concepts, specified representation of the concepts and data in database systems, and integrating data capture into the workflow.

Patient Access to Data

New developments in regulation and technology—particularly related to patient- or consumer-mediated data exchange—are changing the nature of how researchers might access data (Cimino et al 2014; Bracha et al 2019). To implement provisions of the 21st Century Cures Act, on May 1, 2020, the Office of the National Coordinator for Health Information Technology (ONC), now the Assistant Secretary for Technology Policy / Office of the National Coordinator for Health IT, and the Centers for Medicare and Medicaid Services (CMS) announced a final rule; one aspect of the rule is intended to support the access, exchange, and use of electronic health information by patients and their caregivers.

“Patients should be able to access their electronic medical record at no extra cost. Providers should be able to choose their IT tools that allow them to provide the best care for patients, without excessive costs or technical barriers.” —ONC Cures Act Final Rule Fact Sheet

To enable the access and exchange of healthcare data, the rule requires standardized, open application programming interfaces (APIs) to be built using HL7’s FHIR (Fast Health Interoperability Standard). Part of the intention of the rule is to promote competition and support provider and patient independence and prevent information blocking.