Healthcare IT EHR Platforms

Following a comment by Vince Kuraitis regarding EHR modules below, I thought it would be helpful if we expanded a bit on the notion of "Platform" in the context of EHR software technology.

Roughly speaking there are three kinds of "platforms":
(1) Hardware Platforms like the computer you are reading this on or an iPhone
(2) Operating System (OS) Platforms like Windows 7 or Linux or iPhone OS
(3) Software Platforms like salesforce.com or IBM Websphere Portal

We should keep in mind that some OS platforms, particularly everything made by Apple, are tied to a hardware platform. For example, you cannot install the iPhone OS on a Motorola mobile phone. You can however install Windows 7 or Linux on a Dell machine or a Sony laptop.

So which "platform" are we referring to when we discuss EHR modules that are plug-and-play?

Until very recently, best of breed EHR modules, particularly in Hospital settings, could be assembled by users on various hardware platforms and even various OS platforms. The integration of such modules was achieved by interfacing the modules, that is, creating a platform independent connection between the modules and streaming data across. There are well established IT standards for this sort of communication (TCP/IP, FTP) and every OS platform is capable of supporting them. The integration of such modules occurs purely on a data-exchange level. Each module, more likely full blown application, is completely self-contained when it comes to functionality and data storage.
For example let's look at the most common integration in HIT: an EMR interfaced to a Practice Management (PM) system. Both the EMR and the PM are maintaining separate databases of patients demographics. Both contain different code to implement such functionalities as searching for patients, registering and updating demographics, creating users and privacy and security measures. When a user changes data in one application, the information is updated in the other application through interfaces (data-exchange).

This process is complex, expensive, requires IT professionals to set up and maintain and is prone to failure. If the modules are developed by different vendors, the coordination of software releases and versions is a very delicate process. From a software development perspective, this arrangement is also very slow and wasteful, since each vendor has to reinvent the wheel and program all features and functionality from scratch. This dilemma is not unique to Healthcare IT.

The software world's response to the problem was twofold, but the underlining idea was the same. Create reusable small general functionality and make it available to other programs as a service. Thus the term Web Services was coined, along with Service Oriented Architecture (SOA). Web Services, for a while the holy grail of modularity, proposed complete vendor, language and OS neutrality. Application would look for, discover and employ, services deployed all over the web. So you could locate and use a service providing weather forecasts in your region, or drug-to-drug interactions, or recommendations for immunization schedules for a healthy six year old. This is very much like asking the web a simple question, subject to simple parameters, and receiving a simple response. Theoretically, one could assemble a large application built on this paradigm, but, at least for Healthcare, the complexity of the domain coupled with the lack of financial drivers, limited the use of Web Services for anything more than replacement for old fashioned (TCP/IP) interfaces.

SOA on the other hand is widely practiced by developers building applications on an internal basis. It breaks down large modules of software into small, reusable service chunks that different teams can use without the need to rewrite code. For example, there are many places in an EHR where you need to search for patients, or display medication lists. An SOA architected application would make these functions available as a service to those writing lab modules and those writing billing modules and so on. It saves development time and makes the software much easier to maintain.
Within an SOA architected software platform (here's that word again), disparate development teams can create functional software modules guaranteed to work together, since they are all using the same services building blocks. My favorite analogy is a big bucket of Lego blocks. Each Lego represent a service. Developers pick Legos from the bucket according to specifications documents and assemble large software constructs. As you get better at this, you create more sophisticated and specific Lego blocks for your developers (like adding the Lego Star Wars kits to your old bucket).

Now let's take a leap of faith and imagine that a vendor who built such SOA architected product, decides to publish a list of all the services available along with a manual on how to use them, and to top it off it makes a test environment available to the public, so they can try building their own bundles of functionality and test their creations. salesforce.com did that for the CRM market and a flurry of little modules to enhance or replace the original salesforce.com product parts quickly emerged. These independent developers could sell their new software to other salesforce.com customers, or make it freely available to all. There is only one thing they couldn't do. They couldn't use their modules without subscribing to salesforce.com and they couldn't run their software on another vendor's platform. For salesforce.com, opening its software platform to outside developers made good financial sense.
                                           - - - - - - - - - - - - - - - -
So when we talk about EHR modules and platforms, what exactly are we talking about?

If we are talking about modules interacting through Web Services, then yes, we could subscribe to a variety of vendor independent modules and create an entire EHR that way. However, there are no Web Services out there, right now, that would allow such integration out of the box. The most common module that is available in this fashion is electronic prescribing, but you cannot buy an e-Prescribing service and expect your other EHR modules to just work with it. Usually the EHR vendor performs the necessary tasks for such integration, including testing, and e-Prescribing services are not interchangeable. There is very little financial incentive for software vendors to create general services in this fashion and even less incentive for large vendors to allow consumption of such third party services. If the financial ROI is not there, like it was for salesforce.com, in most likelihood it will not happen.

How about the salesforce.com model then? The Software Platform. Will it work for Healthcare IT? The answer is a resounding yes. Last week Eclipsys Corporation announced that it is opening its Microsoft powered Helios enterprise platform to software developers everywhere, much like salesforce.com did a few years ago. What does this mean?
It means that small vendors can use the Helios services (Lego bucket) to develop plugins for the Eclipsys Sunrise product. It means that medium size vendors can develop modules to replace some Sunrise modules, and it means that large vendors can wrap their own applications in code that will allow seamless integration with Eclipsys Sunrise. And Eclipsys is taking the responsibility to test, validate and guarantee that all these modules from different companies will indeed work together. Securely.
The caveat is of course that you must become an Eclipsys customer to enjoy all these choices of EHR modules, because Eclipsys is the platform owner.
I believe we will see more large vendors taking this approach in the near future.

We can also take the software platform notion one step further. What if a generic Healthcare platform was built that offered no EHR and only very few basic services, like security, communications and other OS related functionality, such as printing and scanning? What if software vendors could be convinced to build modular EHR services and also make them available to other users of this platform? What if such platform were free to develop on and free to the consumer? Not necessarily open source, just free. Would that work? Would that achieve vendor independent, plug and play EHR modularity that would lower costs and improve quality?
There is only one possible answer to this: Not really.

First, software platforms, as their name indicates are made of software. Software needs to be maintained, updated and fixed. This costs money.
Second, in order to ensure true integration, someone has to test all these modules and their interaction, and validate data integrity and proper functionality. This too costs money.
In other words, any software platform requires governance. Without governance, a platform is only useful as an open source tool for professional developers. And governance costs money.

IBM Websphere Portal is one such software platform. By EHR pricing standards, Wesphere is very expensive. The only way, I can see, to create and maintain a Healthcare IT open software platform is for the Government to offer one to vendors and providers for a nominal price, which means that the public is paying for the necessary governance.

EHRs are very complex transactional pieces of software. They are the ultimate challenge in enterprise software. It is not a trivial task to build an EHR and it is not a trivial task to assemble one from prebuilt modules either. There is very little fault tolerance. EHRs can improve efficiency and quality of care, if done right, but they can also harm patients if done wrong.
While I can see patients, or consumers, assembling on the fly iGoogle pages with various widgets to help maintain wellness and mange health, I cannot envision the same ability for a hospital responsible for millions of patient records, hundreds of integrated electronic devices, thousands of staff members and several hundreds of human lives, at any given moment. For them the EHR is Mission Critical Software, and that requires a much different standard than iGoogle.