OUP user menu

What makes an EHR “open” or interoperable?

Dean F. Sittig, Adam Wright
DOI: http://dx.doi.org/10.1093/jamia/ocv060 ocv060 First published online: 15 June 2015


We have identified 5 use cases that comprise a useful definition of an “open or interoperable electronic health record (EHR).” Each of these use cases represents important functionality that should be available to 1) clinicians, so they can provide safe and effective health care; 2) researchers, so they can advance our understanding of disease and health care processes; 3) administrators, so they can reduce their reliance on a single-source EHR developer; 4) software developers, so they can develop innovative solutions to address limitations of current EHR user interfaces and new applications to improve the practice of medicine; and 5) patients, so they can access their personal health information no matter where they receive their health care. Widespread access to “open EHRs” that can accommodate at least these 5 use cases is important if we are to realize the enormous potential of EHR-enabled health care systems.

  • electronic health record
  • health information technology
  • medical informatics


Since enactment of the Health Information Technology for Economic and Clinical Health Act, a portion of the American Recovery and Reinvestment Act of 2009, over $26 billion in federal incentives have been paid, through December 2014, to both eligible professionals and hospitals for the adoption and “meaningful use” of electronic health records (EHRs).1 Although the great majority of US hospitals now have some type of EHR system, effective clinical interoperability between disparate EHRs is lacking.2 In addition, major developers of EHR systems such as Epic Systems (Verona, WI)3 have become the subject of scrutiny and criticism4 (including Congressional hearings5) for their alleged lack of interoperability. There has been much discussion of the importance of “open” or interoperable EHRs for effective health information exchange,6 including a recent report to the US Congress from the Office of the National Coordinator for Health Information Technology that addressed “information blocking.”7 Various clinicians,8 researchers,9 and even politicians10 have used these terms as if there were a standard, well-understood definition. This is not the case.

Many commentators assume that an open EHR shares some of the qualities of “open-source” software, which usually implies that the application’s source code is available, often free of charge, for review, use, and even modification. While we support the open-source concept, it has no bearing on whether an EHR satisfies the definition we propose below. On the other hand, we strongly believe that EHR developers should provide customers with access to an “escrowed” copy of their current source code to help mitigate health care business continuity problems in the event the developer goes out of business.11

Some have argued that underlying data structures or the language used to access data are critical to the openness of an EHR—more specifically, that systems that use relational databases and support structured query language are inherently more open than those that use hierarchical databases (e.g., Cache). Although structured query language is more familiar to many users, particularly those outside of healthcare, we disagree that the choice of database technology is an important indicator of openness. Regardless of the EHR’s internal selection of database technology (e.g., relational, hierarchical, or object-oriented), data exchange with another application requires significant effort to transform the data into an agreed-upon format with agreed-upon meaning. This transformation must take into account the data’s syntax (i.e., the format), semantics (i.e., the meaning), and pragmatics (i.e., the way the data are used in context, to create a meaningful clinical application). The heaviest part of the burden lies in agreeing on a data model for sharing information and translating the stored data to that model. The internal representation of the data, in either the sending or receiving EHR, is largely immaterial.

On the other hand, we are strong supporters of the “open” concept as described in the 2013 JASON report to the Agency for Healthcare Research and Quality entitled, “A Robust Health Data Infrastructure”; that is, the data within an EHR should be available via programmatic interfaces for secondary use (e.g., data sharing between systems for research and population health)12 (see Table 1).

View this table:
Table 1:

The EXtract, TRansmit, Exchange, Move, Embed (EXTREME) use cases with requirements for an open, or interoperable, EHR

EXTREME use casesRequirements
An organization can securely extract patient records while maintaining granularity of structured data.
  • Secure login and role-based access controls

  • Structured data importable programmatically into another database (unstructured formats; e.g., PDF, do not suffice)

  • Audits of extracted records

  • Sufficient metadata included in the extract to ensure interpretability (e.g., units and normal ranges for lab results)

  • Freely-available data dictionary indicates where data are stored and what they mean

An authorized user can transmit all or a portion of a patient record to another clinician who uses a different EHR or to a Personal Health Record of the patient’s choosing without losing the existing structured data.13
  • Data selection methods that allow users to identify which data to include or exclude

  • Standard method to structure data (e.g., Consolidated-Clinical Document Architecture (C-CDA)) or portions thereof (e.g., Digital Imaging and Communications in Medicine (DICOM),14 ePrescribing15)

  • Standard methods used to describe the meaning of the data (i.e., controlled clinical vocabulary used) Note: conversion of structured data to an unstructured format (e.g., Portable Document Format (PDF) would not meet these requirements)

An organization in a distributed/decentralized health information exchange can accept programmatic requests for copies of a patient record from an external EHR and return records in a standard format.16
  • EHR infrastructure capable of responding to queries 24 h/day, 7 days/week17

  • Record-locator service functionality available and in use

  • Standard method used to structure data (e.g., C-CDA)

  • Sending EHR’s data dictionary available to receiving EHR

  • “Internet robustness principle” respected (be liberal in what you accept and conservative in what you send)

An organization can move all its patient records to a new EHR.
  • Standard method in which to structure key clinical data (e.g., laboratory results, medications, problems, admission history) provided (e.g., Health Level Seven (HL7) v2.x or v3)

  • Data dictionary used to define clinical and administrative data

  • Existing metadata (e.g., timestamps, source, and authors) preserved in the new system

  • Transaction history of data items (e.g., renewals and dose changes for a medication) preserved

An organization can embed encapsulated functionality within their EHR using an Application Programming Interface (API). Goals: access specific data items, manipulate them, and then store a new value.
  • External applications have “read” and “write” access to clinical and administrative data, including metadata from the EHR (e.g., using the Substitutable Medical Applications, Reusable Technologies (SMART) app platform18 or HL7’s Fast Healthcare Interoperability Resources (FHIR) services19)

  • Programmatic method to embed external applications (either code or presentation; i.e., an embedded web application; e.g., Cerner’s mPages.20) with which the user can interact via the EHR’s user interface without re-compiling the existing EHR’s codebase

  • Appropriate support and maintenance to ensure that encapsulated functionality will continue to work and meet user needs following system configuration changes or upgrades

  • Health Insurance Portability and Accountability Act of 1996 (HIPAA)-compliant protection of newly created data item(s) (e.g., only accessible to authorized users and backed-up with all other patient data) like all other patient-related data

  • EHR, electronic health record.

In addition to the specific features and functions required to implement these use cases, we also note that many developers limit access to their systems by, for example, requiring: 1) special training and certification by the developer before users can extract data from the system or integrate an application; 2) users to sign a “non-disclosure agreement”; 3) users to pay an additional license fee to access data or integrate an application; 4) customized programming that only the developer can do; or 5) access to documentation that requires special permission or additional fees. While we understand that developers need to maintain a degree of control over access to their software for financial, security, intellectual property, and reliability reasons, we question whether a system subject to such constraints can be considered truly “open.”

We propose a working definition for open EHRs that includes 5 use cases, collectively referred to as the EXtract, TRansmit, Exchange, Move, Embed use cases (EXTREME). Each use case represents functionality important to 1) clinicians, so they can provide safe and effective health care to their patients regardless of where previous care was delivered; 2) researchers, so they can advance our understanding of disease and health care processes through use of advanced data mining techniques and experimentation with new application features and functions; 3) administrators, so they can better track health care costs and quality while reducing their reliance on a single-source EHR developer; 4) software developers, so they can develop innovative solutions to address limitations of current EHR user interfaces and new applications to improve the practice of medicine; and 5) patients, so they can access their personal health information no matter where or from whom they receive their health care.

The first of the EXTREME use cases (EXtract) enables any health care organization to create a new secondary-use database (e.g., for population health management or clinical research).21 The second (Transmit) enables a clinician to send a copy of a patient’s record to another physician as part of a referral or to a patient’s personal health record. The third (Exchange) enables a health care organization to participate in a community-wide health-information exchange regardless of which EHR they or anyone else in the community uses. The fourth (Move) enables a health care organization to switch EHR developers without incurring extraordinary data extraction and conversion costs. The fifth (Embed) enables an organization to develop new EHR features or functionality and incorporate this new software into clinicians’ workflow within their existing EHR.

In addition to these use cases, open EHRs should be subjected to stringent conformance testing to ensure that receiving systems are able to import and parse the structured data and store it in the appropriate storage location within the receiving EHR’s database, while maintaining the metadata and transaction history from the sending system that is required for financial, legal, and clinical decision-making.22


Widespread access to “open EHRs” that conform to at least the 5 EXTREME use cases we propose is necessary if we are to realize the enormous potential of an EHR-enabled health care system. Health care delivery organizations should require these capabilities in their EHRs. EHR developers should commit to providing them. Health care organizations should commit to implementing and using them. In addition to having all EHRs meet these technical requirements, we must also begin addressing the myriad socio-legal barriers to widespread health information exchange that is required to transform the modern EHR-enabled health care delivery system.


We thank Isaac Kohane, MD, PhD and Allison B. McCoy, PhD for their comments on early drafts of this manuscript. We thank Paul Guttry for assistance with medical editing.


View Abstract