The latest salvo in the interoperability and information-blocking debate comes from two academic experts in the field of informatics, and was recently published in JAMIA. In the brief article, Sittig and Wright are endeavoring to describe the prerequisites for classifying an EHR as “open” or interoperable. I believe the term “open” is a much better fit here, and if the EHR software happens to come from a business dependent on revenues, as opposed to grant funding from the government, bankrupt may be a more accurate description. Since innovation in the EHR market seems to lack any disruptive effects, perhaps a bit of disruptive regulation would help push everything over the edge.
Although the article seems to be just another shot at Epic, the currently #1 EHR in the country, which is privately owned and run by a woman (a seemingly irritating anomaly in the EHR world), it does have some interesting points worth exploring. The authors propose five overlapping use cases to describe functionality that is important to five stakeholder groups: clinicians, researchers, administrators, software developers and lastly, patients. Let’s look at each one in more detail (pay attention, since we’ll have a quiz at the end), and keep in mind that these requirements are meant to be enforced on all EHRs, including the relatively cheap little one you have in your office.
Use case 1: Extract
The first use case states that a client facility should be able to extract patient records from an EHR, while maintaining granularity of structured data, with the goal of creating “a new secondary-use database” for internal purposes, or most likely for research. To enable the client to extract data and migrate it to a different database structure, the EHR vendor is required to provide the client with its “data dictionary”. A data dictionary is a detailed description of the EHR database schema, all its tables, views, data types, what the data means, how it connects to other tables, constraints, references, packages, procedures, and a whole lot more.
For the less technically inclined among us, the database structure, or the model, of a serious transactional software application is its heart and soul. The user interface, which is what you as a user see every day, is secondary and easily changed. Chances are that if you used the same EHR for a few years, you have witnessed such changes multiple times. You can certainly build a horrific user interface on top of an excellent model, but you can never build a great user experience on top of a lousy data model. The database structure is not written in stone either, but changes to the model entail excruciating effort and huge expenditures. The data dictionary, if done well, is both description and recipe for recreating the entire application, and as such it is the main portion of a vendor’s intellectual property.
Data dictionaries are usually provided to large clients that host their EHR onsite, and are mostly used to build interfaces with other systems. As health insurers continue to dump risk on health systems, database extractions are increasingly being used for other purposes as well. In the ambulatory market, data dictionaries are not usually shared with customers, since small practices have little to no ability to do independent software development. If your EHR is hosted in some cloud, in truly multi-tenant software as a service (i.e. data from multiple customers is stored in one database structure), you will not get any dictionary and you will never be allowed to access the vendor database, and rightfully so. The best you can hope for in this case is a data dump from your vendor.
Related: The Kabuki Dance of “Blocking Data” in Healthcare
Use case 2: Transmit
This use case is a slightly expanded version of the current meaningful use requirement to generate and transmit clinical information in standard format (e.g. C-CDA) to another clinical facility or to an external personal health record (PHR). The goal here is to facilitate referrals or other transitions of care, and to prop up third party PHRs that nobody is interested in using.
Use case 3: Exchange
Here EHRs are required to be available 24/7 to accept programmatic requests from other EHRs for patient records. I am not sure what the significance of 24/7 is in this context, but basically the EHR should be able to respond to ad-hoc queries from any other EHR, locate the requested records, if any, and return a standard based response to the requestor. This use case is supposed to facilitate EHR agnostic community-wide health-information exchange, presumably (and strangely) without using a health information exchange (HIE) entity as mediator. Another peculiarity is the completely superfluous demand that the responding EHR should make its data dictionary available to all querying EHRs, which boils down to publishing the whole thing online, or on demand, for all competing (and aspiring) EHR vendors to enjoy, and to further democratize the hacking industry.
