EMR Question and Answer: Local Server EMR vs Web Based (SaaS) EMR

Miguel sent me the following email about local server EHR and Web Based (SaaS) EHR:

A lot of vendors in Puerto Rico are selling their local server application over the web application. In fact, to my view, they have very weak arguments when selling Local Server vs Web based application.

Can you direct me where to get additional information regarding the comparison of the two? Do you have an estimate, from the 100% physicians that are using EMR in US, what is the proportion of physicians using local server? What would you recommend?

This is a tricky question and the question that really divides many EMR vendors into their various camps. The tricky part is that both camps are right in their assertions. So, there is no clear winner. From my perspective you can make the case for either solution.

However, in certain situations one type of EMR might win over another. For example, if you’re in a place where your internet connectivity is not reliable, then you probably should go with an in house EMR instead of a web based EMR. Many doctors who don’t have formal IT support avoid an in house server and go with a web based hosted EMR to avoid the lack of IT support of the in house server.

I’ve written quite a few times about SaaS EMR and so a scroll through my previous posts will provide insight on a number of other topics including this post discussing the SaaS vs Client Server EHR. I should take the info and add it to this EMR and EHR wiki page. Maybe someone else can help with that too.

I don’t think anyone has an idea of the percentage of user who use a local server vs a web based EMR. I did do this EMR poll back in June, 2009 that showed a split decision between SaaS EMR and the 2 different style of client server EMR.

Finally, here’s the section from my EMR selection e-Book (which everyone should buy) that talks about the SaaS (web based) EMR vs. the Client Server (local server) EMR:

SaaS (hosted/web based) EMR versus Client Server (in house) EMR

This is one of the most heated questions you can ask EMR vendors when considering an EMR.  For an EMR vendor, choosing one or the other becomes like a religion.  My personal belief is that either model is reasonable.  Certainly the SaaS EMR people are correct that web based systems are the major trend in technology and that EVERYTHING is going web based.  However, it is also true that there are some things you can do with a client server EMR that still aren’t as effective with a web based system (ie. complex document workflow).  Some EMR vendors are combining the two models by having an in house server that is web based.  Others are putting their client server EMR in a data center also so they get the advantages of a SaaS EMR while still having some of the client server benefits.  For those that do not know the differences in SaaS versus client server, here’s a high level summary of the advantages and challenges of each model.

SaaS (hosted/web based) EMR

A SaaS EMR is one that is hosted by the EMR company (or partner of the EMR company).  Access to the EMR is done through a standard web browser. (Note: Client Server EMR can be hosted by the company and accessed using terminal server software as well, but that isn’t usually considered a SaaS EMR for purposes of this description.)  The biggest advantage to a SaaS EMR is a clinic doesn’t have to pay for the server and associated IT help to support a server in the office (ie. server room, tech support, redundant network, UPS, backups, etc).  SaaS EMR vendors reasonably argue that most clinics in house IT support cannot provide reliable and redundant server support the way a SaaS EMR can provide.  Part of this is due to the lack of expertise of in house IT support (or lack of in house IT support altogether) and the other part is due to lack of funds to build a reliable and redundant server environment.  Another advantage of SaaS EMR is that since they are web based they are available anywhere you have an internet connection.  When a SaaS EMR updates its software, you will automatically get the latest and greatest features of the software.  This can be a good and a bad thing depending on whether the latest updates were well tested and if they included features that would help your office.  Since a SaaS EMR uses a standard internet web browser, you will not need to spend time installing special software on each computer in your office.  This is even more beneficial when your SaaS EMR does an upgrade to the software.

The major disadvantages of a SaaS EMR are: internet connection dependence, EMR data not stored on site, and reliance on your EMR vendor.  Access to a SaaS EMR is completely dependent on a clinic’s internet connection.  Since the SaaS EMR is stored offsite in the vendor’s data center, any loss of internet connectivity means the clinic is without an EMR.  The solution to this is to have redundant internet connections (where possible), but also often means an increased cost for your internet connection.  Cellular broadband cards have helped to lower the cost of clinics having a redundant internet connection in many places.  Many rural locations with poor internet connectivity should probably avoid using a SaaS EMR.  Many clinics are also leery of SaaS EMR because the patient data in their EMR is stored in the vendor’s data center instead of on site.  Some SaaS EMR vendors will provide a backup copy of your data which you can store locally, but this is not very common and cannot usually be done at regular intervals.  SaaS EMR vendors argue that there’s no need to store a copy of your data locally since the server where your data is stored uses enterprise level backup to avoid any loss of data.  Ensuring these backups are completed appropriately and your SaaS EMR server is always available means you as a clinic are relying on your EMR vendor’s expertise in setting up those processes and configurations.

Client Server (in house) EMR

As would be expected, the advantages and disadvantages of an in house EMR mirror those of a SaaS EMR.  In house EMR software is traditionally done through a client install on a computer which accesses a server stored in the clinic.  Since the server is stored on site, you are no longer dependent on your outside internet connection.  Access to the EMR is done through your more reliable local network.  This also means that all the data from your EMR is stored in your office.  Many people would argue that client server EMR software is faster and can do more than web based software.  Web based software is making major strides in this regard, but there are still some features of an EMR that are better implemented by a client server EMR.

The biggest challenge associated with an in house client server EMR is that it requires a certain amount of local IT expertise to support your local server.  Many EMR vendors will assist your local IT support, but they still usually require some local IT support.  The quality of your local IT support matters regardless of which EMR you choose, but is more important with a client server EMR.

Another challenge with an in house EMR is that you are the one required to make the backups.  Some people consider this a pro since then you can be sure that the backups are done regularly and properly.  However, most people would argue that this is a problem with an in house server.  The reason for this is that too often making sure the backups are done and done correctly is forgotten or not done at all.  This is very common since backups aren’t appreciated until some major disaster happens and it’s too late.  Some local IT companies will partner with you in this effort and this can help solve this problem.

One of the most irritating parts of a client server EMR is the need to install the client software on each computer.  Certainly this is less of an issue the smaller your clinic, but it still can be a pain to manage.  Remember that this is not just a onetime event.  When your EMR software gets upgraded (usually 2-3 times a year), you will need to make the rounds to upgrade the software.  Certainly many EMR vendors have automated the upgrade process to some degree.  You can also often automate this process using active directory.  However, this upgrade process does create just one more area for something to go wrong with your EMR or require special IT support.  The good part is that this means that you can do the upgrades on your own timetable.

Hybrid Model

Some EMR vendors do a mix of the two options above.  They might have a server stored on site, but still have an EMR that uses web based technologies.  This still means you need the in house IT server support, but means that you don’t have to rely on your external internet connection to access the server.  It does however, usually mean that you can access your EMR from anywhere with an internet connection.  It also means that you can use a standard web browser to access your EMR instead of having to install a client on each computer to access your EMR.

This is not meant to be a comprehensive list comparing SaaS EMR with client server EMR.  Instead it’s meant as an overview of the major differences between the two types of EMR setup, but should give you enough information to choose which option will work best for your office.

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.

7 Comments

  • Ankhos uses the hybrid approach and it works quite well. It uses a web browser to access the application within our office. Our original plan was to do use the SaaS platform with an internet-hosted site but we decided that the security risks of going on the open internet were just too great.

    Ankhos is very fast and responsive and is in a class of web apps called Rich Internet Applications , which are coming very close to the usability of native desktop applications.

    Note that most native desktop apps are simply client-server interfaces… just like the browser and a web server. Microsoft outlook (a classic native client app) is only as fast as it’s servers can be.

    Like John said, the internal server setup is more complicated than SaaS, but it allows more control and security. Just make sure you get someone who knows what they are doing and be prepared to be more involved in the process.

  • If this were a hardware store, a client-server solution would be fine, because there is no need to share information. But the whole point of EMR is to make medical records easier to use, which means sharing information among other doctors and clinics. Updates to patient information should be done in-place at a single location, and that implies a web domain name to make it accessible in multiple locations.

    Think email. POP3 was OK in its day, but a webmail account is much more flexible and thus more useful — one can read one’s email from anywhere in the world. Whether I choose gmail, yahoo, or hotmail is irrelevant — my messages are globally accessible because they don’t reside on my computer.

    Of course, security issues must be worked out. But if one is making the tremendous effort to embrace EMR, why settle for merely more efficient storage of your paper?

  • David,
    That’s a bit of a generalization. Some in house EMR software has as much or more information sharing capabilities as the SaaS EMR software out there. In fact, I’d say that most SaaS EMR software and in house EMR software still has a long way to go in information sharing. Is one easier than the other to share? Only if 2 people are on the same SaaS EMR is it easier to share.

  • These are my technical remarks:

    > if you’re in a place where your internet connectivity is not reliable

    Do not make this condition the decision factor to consider SaaS. Even if your internet connectivity is reliable there are other factors why you may not want to implement SaaS with respect to internet connectivity. However reliable your internet connetivity is it still can fail. For most small-sized clinical facilities it will be cost un-affordable to subscribe to a highly resilient internet connection. I’ve seen internet (even frame relay) subscriptions go down for a long time (hours) even if they have an SLA (Service Level Agreement). So what would a clinic do if their internet connection fails ? Close shop for the hour and hope that everything goes back normal ?

    >…accessed using terminal server software as well, but that isn’t usually considered a SaaS EMR for purposes of this description.

    You’ll be amazed that most SaaS solutions is not web-based but RDP (Remote Desktop Client / Terminal Services). New Terminal Services technology can show you just the application (making the back-end transparent) making it look as if they were accessing the software program in-house. Don’t count this out, because if browser-based does not work, there is always a Terminal Server waiting for you to peruse.

    > Since a SaaS EMR uses a standard internet web browser, you will not need to spend time installing special software on each computer in your office. This is even more beneficial when your SaaS EMR does an upgrade to the software.

    When it comes to Java (most likely this will be the back-end technology used for browser-based SaaS applications) it is not true that there is no need for a client installation. The correct version of the Java client software is needed on the clinical desktop computers. Most versions of Java client are compatible to a specific Java back-end for the SaaS. The problem lies when the clinic’s IT department updates the client Java version (for some tehnical reason) without consorting with the SaaS provider (or vice-versa). The same issue lies with Terminal Server, Internet Explorer, Firefox and Flash players. What I am saying is it is not that easy to say that all that is needed is a browser which is already built-in with the desktop computer. Most software sales people will sell it this way, unknowingly there are client-based issues to fix during implementation.

    >Some SaaS EMR vendors will provide a backup copy of your data which you can store locally, but this is not very common and cannot usually be done at regular intervals.

    There is no use for a backup copy of the data as this is too raw. If there is no “SaaS” system located in-house the backup copy can not be used at all.

    > SaaS EMR vendors argue that there’s no need to store a copy of your data locally since the server where your data is stored uses enterprise level backup to avoid any loss of data.

    Data recovery and Business continuity are two different things. Data Recovery is for restoring data when lost. Business continuity is for (exactly) continued business functions regardless of where the data is.

    >Hybrid model

    My idea of a hybrid model is a SaaS that resides in both the SaaS provider’s location and in-house. Data is generated from the clinic and processed in-house. This will fix the latency (slowness) and connectivity issues with regards to the internet connection. When the processed data has reached a particular time (say 1 -2 minutes) the in-house data will be uploaded to the SaaS provider location as replicated data. This architecture allows business continuity when a computer disaster strikes in-house, but note that you still need an internet connection to access the SaaS. There are many variations of this type of business continuity and it will depend on how the software is modeled. It is important to say that the selection of EMR should encompass as to how the business continuity is designed either or both by the software developer and the IT implementation team.

    Cheers for my 2 cents.

    Jojo P
    ITBusinessAnalyst@lagunarty.com

  • Email is one of the least secure protocols on the Internet, although most vendors are now using https to encrypt the traffic.. — The bottom line is that if it’s encrypted, it CAN be hacked (and sold/leaked). There needs to be a balance between risk and accessability, and we just don’t see the need to be on the public Internet yet if we can do everything for ourselves in-house.

    Also, Our EMR is not just about storing papers electronically. We are using our EMR to streamline the clinic oncology workflow. Workflow first, papers second.

    Good point about the “Meta” hybrid, where you have an in house and out -of-house server working together. I don’t agree with your Java remark though. Java should not be confused with Javascript; they are very different. Most web apps run in javascript which comes with all browsers, while as you say, Java does not.

  • Jojo,
    I could say much more, but a few comments.

    I’m definitely not counting out the various RDP/terminal service solutions. They have come a long way and are definitely options to consider. Just for definition I left them out of the SaaS versus in house discussion.

    People still code with Java? Ok, I know there are some that still do, but it’s becoming less and less so. Sure, some browser compatibility issues still come up, but not if the EMR is built right. Plus, it’s still easier to deal with than client installs.

    There’s certainly a use for a local copy of the data at your office. A nice XML export of all the data in your EMR would be incredibly valuable to have if you are using a SaaS EMR system. Sadly, only a few vendors offer this type of capability.

  • Miguel,
    I have been in the Puerto Rico IT industry for 30 years, specifically in the Network and Server arena. As you well know many of the Local ISPs (at some point or another and quite often) have connectivity issues. First evaluate that as your first point failure. Next and most importantly, Due diligence, Many EMR/EHR Vendors are misrepresenting Certification status and how the incentive program works in Puerto Rico.
    For starters we have Identified 4 companies claiming to be Certified. 2 are CCHIT certified (one preliminary), but until ONC completes the selection process, they are not HHS acceptable. The other two Claim to be CCHIT certified but are not.
    To add further, the majority of Puerto Rico’s Medicare population is under several Medicare Advantage programs. So as a provider if you do not qualify under the MA 80/20 rule you may not qualify for the incentives at all.

    Buyer beware.

Click here to post a comment
   

Categories