Wouldn’t It Be Great if EHRs (medical records) Supported Plug-Ins and Were More Like Firefox?

I am currently migrating from one electronic health record (EHR) to another in my practice and feeling very sorry for myself.

There ought to be a way to do this easily, I keep thinking to myself.  Despite all the talk of interoperability and health information exchanges (HIEs) that is all the buzz right now in health IT circles, it seems that some basic functionality that could help make doctors’ lives easier is still missing from EHRs.

While being able to exchange standardized XML formatted documents between hospitals when transferring patients is critical to safe and effective transfer of care, what about the doctor who wants to archive some patient records for later retrieval? Or for the practice that wants to switch from one EHR to another without paying an over-priced consultant to change column-names in an exported spreadsheet or to write a scripts to rename exported attachments.

Here is a list that my friend Jim O’Connell, a physician who is starting a company to address even more fundamental issues of aggregating EHR data for research and other purposes, came up with:

• more configured systems so there isn’t a lot of loading of content when the software/hardware arrives
• improved connectivity between systems so that the patient’s chart (i.e. labs, x-rays, and progress notes etc) could be easily exported from any EHR and then imported by any EHR, regardless of brand
• improved usability in EHR existing data so that you only use 3 screens instead of 6 or 7 to do a complete patient note
• improved  “structured documentation” where enhancements like touch interfaces, natural language processing, and voice navigation would supplant the dense 10 pt font screens often seen in current implementations

At this point, I can almost hear the EHR vendors saying “do you want a pony with that too?”.  Well, no. But the bigger point here is that there are many targeted features that I can imagine would work great for my specialty and my specific work flow. Thus far, the vendors seem to be in a sort of arms race to provide the broadest range of features, so they could satisfy the largest pool of customers.

Instead, what if they published the broadest possible range of APIs (application programming interfaces)? This would allow other software developers to write smaller “plugin” programs that would work inside the EHR and provide highly targeted features that appeal to smaller audiences. I can imagine specialty-specifc “plugins” designed to allow for structured data-entry and validation, potentially allowing for speedier entry and cleaner data, which could then be better aggregated. For example, an orthopedic surgeon could be prompted always to enter data according to validated hip and knee scoring systems. Tumor data can be partially pre-filled using intelligent prediction and validation, instead of asking the user to click through innumerable pull-down menus (or, more likely, skipping them entirely).

The ability to extend the application with plugins has been one of the primary reasons why Mozilla Firefox is such a beloved web browser that is rapidly gaining market share at the expense of Internet Explorer. It is also fundamental approach to the amazing success of Twitter. By publishing and supporting a rich set of APIs, Twitter has spawned a huge ecosystem of developers who profit by selling specialized tools to access the rich treasure-trove of information of users and their tweets.

The hard work the CCHIT and, more recently, the ONC to develop national standards for connectivity and meaningful use will revolutionize the role of IT in health care. While these infrastructure advances will help patients and health systems, it is not so obvious they will address the day-to-day problems of physicians. Here, one should note that one EHR vendor has realized that its future success could lie in encouraging others to develop on their platform.  At the recent HIMSS convention, Eclipsys announced its Helios application development platform precisely to open up patient data within their EHR so that other applications can access it securely. While the method of access granted may have some restrictions, it certainly seems like a step in the right direction.

As every physician knows, the house of medicine is not monolithic. Every specialty is like its own small nation, with its own language and customs. In order for health technology to really make physicians’ lives simpler and easier, the pathways of innovation must diverge and meander in order to accommodate the innumerable variety of physician practices. Opening up APIs and allowing for development of “plugin” applications to enhance EHRs could be the way to let the most flowers bloom.