What SaaS EHR Users Can Learn from the Megaupload Takedown

It’s time to talk about a subject near and dear to my readers hearts: SaaS EHR. In this article, we’re going to take a serious look at some of the risks associated with the pure SaaS EHR model. I’m sure this will leave many concerned about SaaS EHR software. Before I get into that, I want to be clear that I can (and probably will) make a future post about client server EHR software that will likely leave you just as concerned.

The point isn’t that SaaS EHR or client server EHR is better than the other. I take a much more “switzerland” approach to the topic. I think both approaches to EHR have their risks, challenges, benefits and advantages. To me it’s much more important that users are educated on the risks of each so that they can address them properly.

With that in mind, I was recently reading one of my favorite venture capital bloggers, Brad Feld, who posted a guest post by Dave Jilk about what SaaS software vendors can learn from the Megaupload and its impact on the future of Multi Tenant Services. For those not familiar with the Megaupload situation, the Feds basically took down Megaupload and seized everything they had in response to copyright infringement violations. Wired has an interesting article about the case.

What then can we learn from the Megaupload case that applies to SaaS EHR companies. I think Dave Jilk describes the SaaS risks better than I could:

What this particular case illustrates is that a company that provides your online service is a single point of failure. In other words, simply offering multiple data centers, or replicating data in multiple locations, does not mitigate all the risks, because there are risks that affect entire companies. I have never believed that “availability zones” or other such intra-provider approaches completely mitigate risk, and the infamous Amazon Web Services outage of Spring 2011 demonstrated that quite clearly (i.e., cascading effects crossed their availability zones). The Megaupload situation is an example of a non-technical company-wide effect. Other non-technical company-wide effects might be illiquidity, acquisition by one of your competitors, or changes in strategy that do not include the service you use.

So again, while this is a striking and unfortunate illustration, the risk it poses is not fundamentally new. You need to have an offsite backup of your data and a way to use that backup. The situation where the failure to do this is most prevalent is in multi-tenant, shared-everything SaaS, such as Salesforce.com and NetSuite. While these are honorable companies unlikely to be involved in federal data confiscations, they are still subject to all the other risks, including company-wide risks. With these services, off-site backups are awkward at best, and more importantly, there is no software available to which you could restore the backup and run it. In essence, you would have to engage in a data conversion project to move to a new provider, and this could take weeks or more. Can you afford to be without your CRM or ERP system for weeks? By the way, I think there are steps these companies could take to mitigate this risk for you, but they will only do it if they get enough pressure from customers. Alternatively, you could build (or an entrepreneurial company could provide) conversion routines that bring your data up and running in another provider or software system fairly quickly. This would have to be tested in advance.

As many of you know, I’ve been quite interested in this topic and risk for quite a while. I’m sympathetic to those doctors that want at least a copy of their data stored somewhere that they control. Yes, most SaaS EHR vendors have a good set of backup, disaster recovery and business continuity plans. However, as the above quote points out so well, that doesn’t deal with the “non-tecnical company-wide effects.”

I’ve long considered the idea of creating a set of standards that SaaS EHR vendors could adopt. Things like making a practice’s entire EHR data available in an easily downloadable XML format. That could be the starting point. I think it would also create a real competitive advantage to those EHR vendors that adopted these type of common sense, good customer service practices.

I’d even be happy to lead the EHR agnostic team that it would take to make this happen. Client Server EHR software vendors could be involved as well. Not to mention I’d be happy to provide a voice to the movement on my network of EMR websites. I think the key to success would be getting a couple EHR vendors to get on board with the idea and fully invested in seeing this happen. The challenge is that too many EHR vendors are blinded by the meaningful use lights.

Let’s just imagine for a minute that doctors that select an EHR didn’t have to worry about their data being safe. They knew that they could have their data available to them when they needed it where they needed it regardless of what happened to the vendor. I have that with my blog data. Although, instead of that making me wanting to change blogging platforms, it’s endeared me to WordPress even more.

I wonder if Todd Park could add this idea to his concept of EHR Data Liberacion.