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.
Related: Can Public APIs Unlock True Health IT Interoperaiblity?
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.
Related: Like Scorpions, Closed EHR Systems Cause Paralysis
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.
Margalit Gur-Arie is the founder of BizMed, a company devoted to supporting practicing physicians through software and services that simplify the business of medicine. She writes regularly about the intersection of healthcare & technology on her site: On Health Care Technology. Follow her on Twitter at @margalitgurarie
Opinions expressed by HIT Consultant Contributors are their own.
