Skip to main content

A Proposal for Disruptive Regulation of EHRs

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.   

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.

Use case 4: Move

This use case is intended to reduce costs of switching EHR vendors, while ensuring that all data in the old EHR, including metadata and transactional histories are transferred to the new system. To better understand this noble requirement, let’s look at how easily a health system can switch banks. If an organization uses say, US Bank for ten years, and then wishes to transition their accounts, to say, Bank of America, US Bank will first provide its complete data dictionary to the switching organization to be shared with Bank of America developers. Then US Bank will provide an extract of all financial data, including historical transactions and all metadata (e.g., timestamps, source, and authors) so everything is migrated and preserved in the Bank of America system. Other than the logos, the organization would not see any difference really, and this will all be done for little to no cost to the switching health system. If this has not been your experience, then you should call the banks and complain.

Use case 5: Embed

The fifth and last use case is about application programming interfaces (APIs) on steroids, and it enables health systems to develop new EHR features or functionality and seamlessly incorporate those into the EHR. This implies full access to read, edit and delete database content, as well as ability to augment database structures, while the original EHR is expected to incorporate these changes automatically into its basic services such as security and privacy. Essentially, an EHR should become a development platform with functionality exceeding that of the best operating systems out there. For example, if an EHR lacks the ability to collect and process PHQ-9 data, an institution could develop such functionality independently, while the EHR will be expected to incorporate the functionality in its own workflows, screens, decision support, and HIPAA protections, practically out of the box.

Putting all five use cases together and using a tortured way to come up with an acronym, the authors dubbed their framework for defining an open and interoperable EHR, EXTREME, and extreme it is. The framework is written from the point of view of a large health system dealing with a large EHR vendor, and understandably so, since this seems to be the authors’ natural habitat. Applying this framework to the hundreds of EHRs and EHR modules that have been certified by the government to date will ensure that this big business habitat is the only model left standing. There is a cost to transitioning a software package from being a product or a service, to being a development platform. That cost is beyond the reach of most existing EHR companies. For the remaining few, the cost will eventually be passed down to current customers, as was the case with all government mandates imposed on EHRs. Small practices and small hospitals, already struggling to stay afloat, will be dealt the final coup de grâce.

The authors state that this upheaval is necessary “if we are to realize the enormous potential of an EHR- enabled health care system”. Six years and billions of dollars since we embarked on this journey and all we can come up with is some elusive “potential” that will certainly materialize if only we could spend a little more money, and if only we could drive a few more people out of this business, and only if we take the necessary next step, which we are told is to dismantle “the myriad socio-legal barriers to widespread health information exchange”, which is newspeak for removing any and all remaining privacy and informed consent protections for individuals, whether they like it or not. The truth is that we have no research, no proof and no reason to believe that the mythical “potential” even exists, let alone that the bigger-is-better, top-down model of health surveillance is best suited to unlock this “potential”.

I have to confess here that I have no idea what an open and interoperable EHR is. I also don’t know what a high usability EHR looks like. I do however know what a good EHR is, not a perfect one, but a good enough EHR. Just like any other piece of software, from Microsoft Office to Oracle Financials, a good EHR is one that people choose to purchase. If other people think there are better ways, then by all means, they should build amazing new software and fairly compete in the EHR market, instead of engaging in armchair quarterbacking of rules and regulations to advance theoretical concepts that captured neither market interest nor customer dollars on their own merit.

Quiz Question: Of the 5 stakeholders listed at the top, which one is absent, from all EXTREME use cases? Answer: The patient. Even in the tangential use case where data may be transmitted to a PHR, the patient is a passive entity, while the “organization” decides when, if and what to transmit. At some point, the few patient advocates who have not yet been thoroughly corrupted by the deluge of cash and fame, will have to come to terms with the grim realization that everything done and said nowadays is not intended to benefit the people, and health care is no longer an exception.

Comments

Post a Comment

Popular posts from this blog

Transforming Health Care: Values and Cultural Preferences

On his campaign trails, Harry Truman used to call on citizens to go out and vote for themselves, in their own selfish interests. It may sound shallow and divisive, but Harry Truman believed that the individual interests of the people should trump the special interests of the powerful few, and that’s how Democracy should work. Those were simpler times, but the logic still applies today, although it’s becoming increasingly difficult for people to figure out where their selfish interests lie, not because interests have changed, but because the art of spinning messages and the sheer amounts of cash thrown at it have grown beyond what Harry Truman could have imagined. Take for example the controversy around the Patient Protection and Affordable Care Act of 2010, a.k.a. Obamacare, which was spun into one little question: do we want the government to give more poor people health insurance, while forcing everybody else to pay for it? If yes, vote Democrat. If no, vote Republican. But Obamacare...
Post a Comment
Read more

De Novo EMR Design Part II: The Quest for Information

The Edwin Smith papyrus ca. 1500 BCE In Part I of this series, we engaged in a design exercise for an imaginary software product that has no stated (or hidden) purpose other than to improve patient care. Following our initial definition of patient care, we formulated three general requirements and several constraints, none of which were specific enough to start building software tools from. The next step in our journey will break down each requirement into more specific tasks. What follows below will seem like an unnecessary and laborious statement of the obvious to some. However, I would submit that the careless bypassing of fundamental analysis is precisely what led us to where we are today, and even if we are forced to cut corners eventually, it is imperative that we define all corners prior to cutting them, instead of feigning shock and surprise after the fact. So without further ado, let’s start where we left off. System shall assist with gathering information from various sourc...
Post a Comment
Read more

In Memoriam FFS

On April 16, 2015, President Obama signed into law H.R. 2, the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA), effectively sentencing Fee for Service (FFS) to death. The best explanation for how FFS is destroying the nation comes from Charles Munger , vice-chairman of Berkshire Hathaway and ad-hoc health luminary, who is equating what American doctors do, to raising rattlesnakes so they can collect the bounty for dead rattlers offered by the government in an effort to combat a growing snake problem. Based on this, and other equally compelling insights, FFS was found responsible for willful destruction of our great nation. A few months before Congress delivered its coup de grâce to the FFS system, the Secretary of Health and Human Services, explained to the elite group of NEJM paying customers, how “30% of Medicare payments should be tied to quality or value through alternative payment models by 2016 (50% by 2018)”. Other than transforming traditional Medicare into a vi...
Post a Comment
Read more