EMR Updates in SaaS EMR World

When I was writing my last post about updating your EMR software, I knew that I had to also write a post talking about the update process for an SaaS (often called hosted) EMR solution.

Basically, updating your SaaS EMR is a two edge sword. Hosted EMR vendors will often talk about how great a hosted solution is because you never have to go in and update your server’s software. The updates just happen and are all managed by the EMR vendor itself. Kind of like if you use any of the free email services like Gmail. It’s updated all the time and you don’t have to worry about it. Essentially updates to an SaaS EMR work similar. The updates are applied on the server that’s managed by the EMR vendor and you automatically get the latest updates.

It’s worth noting at this point that this really is a huge time saver. I hate dealing with updates of client server based EMR software. I even push out the updates to my over 100 computers using an automated solution, but I still hate doing it. There’s always some sort of issue with some computer not updating properly. In an SaaS EMR solution you just have to make sure that your web browser’s updating doesn’t screw things up. Otherwise, no need to worry about updating every computer in your clinic when your EMR decides to update.

However, the second edge of the sword is that you EMR software will just automatically update. When all goes well this is great. When there is a problem with the update then you didn’t have a chance to test it first. You don’t get to choose when the updates happen (usually) and that includes delaying an update while you wait for another enhancement to fix what the update breaks. I will say that most SaaS EMR software are much quicker to fix if something really bad does happen with an update. The point is that you’re much more at the mercy of your hosted EMR vendor when an update is done. It’s nice to have it hassle free, but sometimes the hassle is worth it.

Let’s hear your stories. I know you all have them. That includes challenges with updating both in the hosted (SaaS) or client server world. Share it with us in the comments.

About the author

John Lynn

John Lynn

John Lynn is the Founder of the 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.

12 Comments

  • Training for new/changed/lost EHR functions or work flows is an area within SaaS implementations that requires better communication, management and coordination between the vendor and the practices involved.

  • Hi,

    It’s important what you say, an upgrade from the SaaS-based EMR vendro may bring unexpected functionalities and bugs that may bring problems.

    However, what if vendor notifies his clients that an upgrade will be done and allows them to test the new system and provide feedback before upgrading? I think that a good collaborative environment will help outstanding the upgrade benefits and troubleshooting the main issues before the new EMR release.

    Thanks.

  • One should also consider the scope of the data being stored. If the data is used only by the doctor or clinic, then perhaps local is the way to go.

    But if I understand the current and future concept correctly, EMR data is inherently global in nature. The records should be accessible to any medical provider. And when Walmart, Kaiser, et al eventually work out the formatting details, medical users should not have to worry about the problems their providers encounter. So I’d favor the hosted approach and let my EMR provider sweat the conversion details.

    Just make sure your hosting service will shield you from this future messiness!

  • Michael,
    You are so right. I’m guessing that many of the SaaS EMR providers have little notification and review when adding new features. It would be interesting to review what SaaS EMR providers provide when updates are done to the software. Do they post it to a blog?

  • Esteban,
    You’re right that good communication can solve a lot of the problems. My guess is that many of them aren’t communicating. However, if you look at the link to my previous post you’ll see that I even knew about the update and still had a problem with it because of unanticipated consequences from the update. So, updates to an EMR are a challenge in general. However, it becomes even more of a problem when a SaaS EMR does an update for which you aren’t notified or have no choice about when it happens.

  • David Swink,
    Actually, I don’t personally see any difference in interoperability between a SaaS EMR and a in house EMR. Both can be made just as inter operable. The only exception is if there are multiple clinics on the same SaaS EMR that want to exchange data. Then, there’s an advantage. However, the reality is that we’re never all going to be on one SaaS EMR. So, I don’t think that’s really an issue when choosing which type of EMR.

  • For a small Dr office, isn’t a hosted solution much cheaper than in-house. But does a small Dr office have sufficient bandwidth to effectively use a hosted solution? If the link is down the EMR is unavailable.
    I am sure patients will be vary wary about security of the personal record in “the cloud”.
    See my blog, for two NPR stories on patient privacy concerns and WiFi for Drs:
    http://gershater.wordpress.com/2009/09/22/in-response-to-john-zelski-healthcare-information-technology-and-the-future-of-medicine/

  • Jonathan,
    I think you just described the 2 issues for a small doctors office very well. If you go with a hosted EMR solution, then you’re likely to have less in house IT costs. However, you’re going to have to pay more for a better/more reliable internet connection and you’re at the mercy of that internet connection.

    I think that either option is a viable option. Practices just need to decide which thing would be more painful for them to deal with. Both options have worked very well in small offices.

  • I agree that moving your EMR to the cloud will help bring down your IT costs but only if the SaaS is real and not a pseudo-SaaS where your actually interfacing with a client box at a hosted site that has access to the Server at the hosted site. Now you have to support the client access (Citrix, RDP, etc.) on all your machines, so what have you really saved other than not physically keeping the server on-site. You’ve opted for co-location/hosting. This is not SaaS.

    As second item of note for small offices; if you think your security is tight but keeping your EMR in the cloud presents a risk, then you should at least have a security audit done once a year to prove this out. I doubt small offices who likely do not have full time IT staff (and I’m not talking about “the computer guy” I mean a real IT professional that does not worry about desktop installations of Word but instead focuses their time on good SLA’s for your internet and telecom, keeps your licensing in check for all your apps, and is in the decision making process for your security and EMR/PM infrastructure) will be able to secure their infrastructure day in and day out any better than a SaaS provider. So Assuming that because it is in-house it is inherently more secure is pure fallacy. Many “Geek-Squad” techies can set up a decent small network with security but once they leave you become more vulnerable every week.

    Finally, on the software update issue; this risk should be mitigated at the contract level not on the fly as many people assume it must occur. Get it in writing up front about exactly when and how many times the vendor can do a system upgrade. Have a detailed SLA that shows what defines “in service”, what the backout plan needs to be, monetary compensation for not complying with the SLA, and what occurs in the event of full loss-of-service.

    This all goes back to poor contract management when getting into business with a service provider. These software companies are not Verizon or AT&T. They need your business enough that they will amend the SLA’s so that you can be better protected. Essentially, you should be helping mold this industry but instead it seems that the practitioners are opting to do all this as cheaply (as a whole) as possible and when the going gets really tough, they jump on the next flashy ship that passes by. This is a big reason you have over 200+ vendors in this space (sure the stimulus money doesn’t help but there were plenty of vendors around before that, let’s not kid ourselves)

  • # John commented on October 8th, 2009:
    “Iā€™d say more like 300+ EMR vendors:”

    I’m in contact with many of the major software development houses on a regular basis and I would venture more like 3000+ soon. šŸ™‚

  • John said, “Interesting comment on the lack of in house IT posing a higher security risk.”

    There have been a number of front page stories about security breaches in the financial industry largely related to credit card info and potential identity theft.

    The first breach of an ASP system where financial info AND sensitive medical info leaks (or even floods) into the cloud will rock not only HIT but the foundation of ARRA/HITECH. Of course, just my opinion.

    How the patient/consumer reacts before it happens and after is key. Appears to me that no one has really asked what s/he thinks.

Click here to post a comment
   

Categories