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.

About the author

John Lynn

John Lynn is the Founder of HealthcareScene.com, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference, EXPO.health, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.

8 Comments

  • @John: Working backwards here, to your last paragraph on data security – that utopia just can’t exist. Yes, your blog data is nicely stored in “the cloud”, but to believe it is available regardless of what happened to the vendor is slightly misleading.

    You have multiple vendors that keep your blog alive. WordPress, your website host, Google and others.
    Your real vendor of failure is your web host: if they screwed up your site has the potential to disappear. Yes many things need to happen for that disaster, but I’ve been there.

    And as you alluded to at the beginning, there is no perfect answer, but for some situations one solution is better than the other.

    SaaS vs. Client/Server is almost like Apple vs. PC.

    SaaS is sold as the Utopian answer. It is not utopia, but is can be a great answer for smaller practices.

    Still, how do you really know your SaaS provider is backing up your data…and how do you get your data when you want it (to go to another EHR)?

    Why XML isn’t the standard used for EHRs is beyond me…other than once you get the gov involved, things go haywire.

    That said, client/server requires more effort to setup, maintain and backup, but once setup it should be able to hum along with little effort.
    Plus you have complete control over your data.

    Many like that idea of complete control over their data.

    p.s. I still believe an open source EHR (aVista?) was the answer. Imagine that open source EHR, all data stored the same way. Wow.

  • I do have multiple vendors to keep my blog alive. However, I can port the data for the blog anywhere I want and even on a local install if I want. That’s what makes it so powerful. I can move it around any way that I want and store it in multiple locations. Sure, there are still risks. Plus, I still have to make sure that it does get saved to all of those locations and test that the data is saved properly, but at least I can do that with my blog. Try doing the same thing with an EHR. I know of at least one that EHR that gets pretty close.

  • We are both on the same page here.

    I guess I’m doing a little devil’s advocate.

    Another thought as I was reading your post. I used to be a Drupal guy, and still have some Drupal sites.

    Converting a Drupal site to WordPress isn’t basic.

    Point being, even in the open source CMS world, there are incompatibilities…everyone has a better way of slicing bread.

  • If I understand what you’re saying, it is that if you go the cloud / saas / ASP model you bear the risk that the vendor will go under or otherwise suddenly shut down or somehow leave you without an EHR system and without your data. Reasonable fear. And one of the criteria for accepting a system (keeping Federal law in mind) is that your data is safe – in this case safely backed up, presumably daily, to another site besides yours and besides your vendor’s regular site. Not so clear is that you need to actually be able to get hold of that data and do something ‘meaningful’ with it (useful) presumably with another vendor, and on very short notice.

    Funny, but when I was comparing features of 2 (free) cloud based systems, I saw nothing about backup, DR, etc. I wonder if you go the FREE route if you have to pay extra for that. Regardless, let’s assume backup is done – and accessible to you in some way. Then the bigger problem shows up – no one else can suck in that data and even with messed up processes put you back in business.

    I remember reading how there were 2 ‘industry standard’ export protocols. Then reading that they weren’t all that available, and even if they were, not many systems can read them back in. I can’t even begin to comprehend how we could get so far along in this process without there being some resolution here. Nor can I believe that this is what the Feds had in mind when they committed so much money to EHR.

  • @R Troy
    I guarantee the Feds never had in mind a free EHR for which they would reimburse the end user tens of thousands of dollars.

    I always tell folks that use a SaaS to get the backup process detailed in writing. When an auditor shows up, your answer to your backup process can’t simply be a shrug of the shoulders and, “well, my vendor handles that”.

    Additionally, if this is how one chooses to run their business, not understanding “where” their data is, then disaster is just around the corner.

  • R Troy,
    You understood the points I made well. Although, if you have the data in almost any accessible format, then at least you have options. The problem is that in many cases no practice has their data in a place they can get the data other than through the standard EHR interface. That’s a huge risk that many are taking and I’d love for SaaS EHR vendors in particular to at least solve that part of the problem. If they did, a whole group of companies could be put together to support the import to a new place.

  • It doesn’t help that none of us individually have the leverage we need to get the vendors to include a good export tool. And as to import, I’m sure that for a large enough fee for a desperate practice they’d be happy to come in quickly, upload what you have (if you have), and get something going! 🙂

    This should be part of the Fed requirements. It’s clear that a lot of vendors will do away and leave a lot of practices stranded, so having a daily export off site download (to where the practice can retrieve it) should be mandatory.

  • BTW, even if you have an in house system, you still have the backup question. And so many businesses have no clue; doctors even less so. It is one of my huge concerns about a practice having a system in house, and why I’m so strongly against it in many cases. But all SAAS/ASP/Cloud does is move the problem; it doesn’t eliminate it.

Click here to post a comment
   

Categories