- HIStalk - https://histalk2.com -

Readers Write: Defining Our Terms: Does Anyone Know What an "Open EHR" Really Is?

Defining Our Terms: Does Anyone Know What an "Open EHR" Really Is?
By Dean F. Sittig, PhD and Adam Wright, PhD

image image

Adapted from “What makes an EHR “open” or interoperable?” J Amer Med Inform Assoc 2015. Available at: http://jamia.oxfordjournals.org/content/early/2015/06/13/jamia.ocv060.

There’s been a lot of talk lately about “open” EHRs, ranging from Congressional hearings to industry buzz. Last summer, Mr. H challenged his readers with, “What core set of published standards or capabilities must a given EHR support to be considered open?” We thought this was a great question, so we decided to give it a try.

First, “open” does not mean “open source.” Although open source software is of great value, an EHR can certainly be open without being open source.

We’ve also noticed that some commentators equate open with the platform software is built on, and specifically, that systems which use relational databases and support SQL (structured query language) are inherently more open than those that use hierarchical databases (e.g., Cache). We think this is a distraction, too – you can make closed systems on SQL or open systems on Cache.

Regardless of the database technology (relational, hierarchical, 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 (the format), semantics (the meaning), and pragmatics (the way the data are used in context to create a meaningful clinical application). The internal representation of the data, in either the sending or receiving EHR, is largely immaterial.

We decided to organize our definition of open around five use cases, which we refer to as the EXTREME criteria (short for EXtract, TRansmit, Exchange, Move, Embed):

EXTREME Use Cases

An organization can securely extract patient records while maintaining granularity of structured data.

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.

An organization in a distributed/decentralized health information exchange (HIE) can accept programmatic requests for copies of a patient record from an external EHR and return records in a standard format.

An organization can move all its patient records to a new EHR.

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.

These use cases were designed to address the needs of patients, so they can access their personal health information no matter where they receive their healthcare; clinicians, so they can provide safe and effective healthcare; researchers, so they can advance our understanding of disease and healthcare processes; administrators, so they can reduce their reliance on a single-source EHR developer; and software developers, so they can develop innovative solutions to address limitations of current EHR user interfaces and create new applications to improve the practice of medicine.

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 requiring: special training and certification by the developer before users can extract data from the system or integrate an application; users to sign a non-disclosure agreement; users to pay an additional license fee to access data or integrate an application; customized programming that only the developer can do; or 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.

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 location within the receiving EHR, while maintaining the metadata and transaction history from the sending system.

Widespread access to open EHRs that implement at least the five EXTREME use cases we propose is necessary if we are to realize the enormous potential of an EHR-enabled healthcare system. Healthcare delivery organizations must require these capabilities in their EHRs. EHR developers must commit to providing them. Healthcare organizations must 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 (e.g., lack of a unique patient identifier, information blocking, high margin, fee-for-service clinical testing) to widespread health information exchange required to transform the modern EHR-enabled healthcare delivery system.

Dean Sittig, PhD is professor of biomedical informatics at the University of Texas Health Science Center at Houston. Adam Wright, PhD is senior scientist in the Division of General Medicine of Brigham and Women’s Hospital, a senior medical informatician with Partners HealthCare, and assistant professor of medicine at Harvard Medical School.