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

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.

• Secure login and role-based access controls.
• Structured data importable programmatically into another database (unstructured formats such as 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.

• Data selection methods that allow users to identify which data to include or exclude.
• Standard method to structure data (e.g., C-CDA) or portions thereof (e.g., DICOM, e-prescribing).
• 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 such as PDF would not meet these requirements.

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.

• EHR infrastructure capable of responding to queries 24 hr/day, 7 days/week.
• 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. HL7 v2.x or v3).
• Data dictionary used to define clinical and administrative data.
• Existing metadata (e.g., timestamps, source, and authors) exported to 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 SMART app platform or HL7’s Fast Healthcare Interoperability Resources (FHIR) services.
• Programmatic method to embed external applications (either code or presentation, i.e., an embedded web application, e.g., Cerner’s mPages) 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.
• 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.

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.