Share on LinkedInTweet about this on TwitterPin on PinterestShare on FacebookShare on Google+
image

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.