Are Client Server EHR Holding Back Healthcare?

The number one topic of debate on this blog has definitely been Client Server EHR versus SaaS EHR. There are staunch parties on both sides of this aisle. No doubt both sides have a case to make and we’ll see both in healthcare for a long time to come. Although, I think that long term the SaaS EHR will win out.

As I was thinking about this recently, I realized that while client server EHR can do everything a SaaS EHR can do, it definitely makes a lot of things much harder to accomplish.

It’s much harder to create an API that connects to 2000 client server EHR installs.

It’s much harder to make 2000 client server EHR installs interoperable.

It’s much harder to evaluate data across 2000 client server EHR installs.

I’m sure I could keep going with this list, but you get the point. Even though something is possible, it doesn’t mean that they’re actually going to do it. In fact, if it’s hard to do, then it takes extreme pressure for them to do it.

All of this has me begging the question of whether client server installs are holding back the EHR industry. Up until now, many of the things I mention above haven’t been that important. Going forward I think that all three of the things I mention above are going to be very important.

The good thing is that I see many client server EHR moving to some kind of hosted EHR solution. That solves some of the problems mentioned above. At least if it’s a hosted EHR solution, they can control the environment and more easily implement things like API access and interoperability. That’s much harder in the client server world where if you have 2000 EHR installs, you have 2000 unique setups.

Of course, as soon as a large SaaS EHR has a massive breach, healthcare will go running after the client server EHR. The battle lines are drawn and each side knows each other very well. Although, I think the SaaS EHR have the high ground right now. We’ll see how that continues over time. Client server EHR have done an amazing job battling.

About the author

John Lynn

John Lynn

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


  • Hi John,
    Nice article – there is a financial issues in going from client server to the SaaS model. What should be a consideration for many is the ability to minimize risk and support a ‘hybrid’ model. Slowly the industry will move to SaaS until then we should be planning an in between model for EHR. As for the data evaluation there are new tools like Tableau that helps the users gather requisite data from multiple sources for evaluation and analysis. (Refer to the BI and Analytics tools Magic Quadrant). In summary you want to give users the ability to analyze and transport their work to foster collaboration. Today’s client server tools requires IT to provide these reports and analysis. I like your article and will leverage this in a future blog post. Thanks, Jim

  • As I see it we are moving all our clients to full Cloud or Hybrid, depending on their wishes. From the Vendor standpoint it is much easier for upgrades and to maintain the full cloud, but we have received push back from some larger end users. Nearly all small practices, 1-3 providers like it more.

    The real issue is cost to the provider, most Client Server installs are on a purchased once, and pay maintenance solution. The maintenance is a lot less then a subscription to the EHR they already own. This is a tough selling point, and probably the only time in my history in EHR where we simply are not offering a choice on price, we are end of life the purchased product. This does not seem fair, but you have to consider most of those purchase took place over three to five years ago, and the practices have got a return on the investment in our case, 10 fold usually.

    So we like many vendors will be forcing this on all new users, and moving existing user to this technology, often begrudgingly.

    My 2 cents worth.

  • Jim,
    There are tools that can do some of the work, but it’s still much harder when you have 2000 installs you have to connect.

    Thanks for your insight. The financials you mention are the major barrier for many to move from client server to some sort of cloud offering. I’m seeing many EHR vendors do something similar to what you’re doing.

  • John, certainly, you make some good points. I think there is value in both. We usually use client-side instead of client server, so I will refer to it that way in my comments.

    With a client-side install, complete control is available. That’s great for security. But it’s only going to be as good as the people supporting it and the infrastructure behind it. Then there’s the question of interoperability. Usually, interoperability is an afterthought with most everything hosted internally. Hence the problem with traditional EHRs that were not designed to be interoperable.

    SaaS applications have to make interoperability a #1 priority. After all, who is going to use any SaaS if they can’t communicate with it. It’s also easy (easier, anyway) to have a SaaS already connected to other common services and have that interoperability ready on a dime.

    SaaS is also [generally] built to scale. There should be no question that any SaaS is highly available and fault tolerant. That’s a far cry from what we see with many of our clients who choose to run their Production applications in environments lest robust than our laptops. The concern with SaaS has generally been really over security, and to a lesser extent latency. How does SaaS guarantee transmission security and how does it guarantee the security of data that’s already been transmitted? What’s the recovery strategy?

    As these problems with SaaS become less and less of an issue, I see it becoming more of an attractive option even for healthcare which in the past was very skeptical about having their data stored off-site. I think the draw of having a service that “just works”, is “natively” more interoperable, they don’t have to support or staff for, and that’s already “connected” is just too hard to resist for many organizations despite the higher cost. Remember total labor costs can quickly even out the total cost of SaaS.

  • Good point Monika. Thanks for adding to the discussion.

    I’d like to see some standards for SaaS providers when it comes to availability of data to a practice. I think it would help the fears of many in healthcare and also be good for the practices as well. When I say standards I mean like “your data is your data.” “We’ll provide you your data in an export as needed (ie. backups, switching etc).” It will take some forward thinking SaaS vendors to make this happen though.

  • The only constant is change. Look at the history of computing: Mainframes to client/server to thin clients to client server to “the cloud” to…wait for it…wait for it….

  • John,
    I am just going to say it bluntly. Your data in a EHR is never your data, and is never exportable easily. That is by intent, after all, if you want to switch your EHR one protection of the Vertical is to provide a cost for conversion.

    Weather client server or SAAS this remains the case. In SAAS a little worse.

    That said, Latency not as much a issue, especially with a Hybrid cloud solution, especially in Urban Areas. Further, the current (Next Generation) is much better, Apps that store the primary data in the Session Local and post the data to Data Center, and if one DataCenter/Host is down transaction occurs elsewhere.

  • Don’t know how to post corrections on this blog, so for correction purposes, you own the data on your client server but everyone knows that in reality you cannot usually do much with it, some are more open then others, but usually a conversion requires both vendors or a third party understanding both vendors systems.

  • BrendonHolt,
    There’s no way for you to edit an old comment without a login, but no worries we understood.

    I agree that EHR vendors have used export of the EHR data as a way to try and lock in customers. However, I could see an EHR vendor using that fact as a way to market their product. Basically, the message would be “We’re so confident that you’re going to love our EHR, that if you want to leave you’ll have all the data and you can easily switch to a new EHR!”

    It would take some courage to do it, but it would definitely change the discussion about it.

  • As others have pointed out, the differences between Client Server EHR and SaaS EHR are subtle.

    The variables include vendor cost to build/deploy/maintain, customer cost of acquisition/ maintenance, customer ease of access/use, fault tolerance, security, interoperability.

    As a vendor that offers both CS and SaaS solutions, aside from customer cost, it has been my experience that there is not much difference except in the area of fault tolerance.

    I can’t comment on whether CS is more/less expensive to a customer.

    Any ROI prepared needs to start with the real cost of self-hosting and few customers are able to do the before/after calculations.

    An outsourced solution with a large hosting company lets you adjust capacity easily and in most cases gives increased fault tolerance.

    On the issue of vendor upgrades/support, if a vendor has 1,000 separate sites to service instead of one, they automate.

    On ownership of data, this is purely a contractual issue so it’s not accurate to say that hosted data is not/never your data and it’s not accurate to say that the data is not easily exportable.

    Lack of interoperability is the result of customers failing to insist on it. End of. Vendors build what customers say they want/need.

    John Brewer makes an interesting comment (mainframes, client/server, thin clients, cloud) and if we recall that there are two ways to connect users (i.e. hard –wired, timesharing), a different way to look at the history is timesharing, timesharing, timesharing, timesharing.

    It has not been my experience that

    – It’s harder to create an API that connects to 2000 client server EHR installs.
    – It’s harder to evaluate data across 2000 client server EHR installs.

    Our group designed, for an MCO, an e-hub application to consolidate patient session data across 100 member clinics, plus patient data from several hospitals and labs.

    We allowed uploads from clinics using ANY format for the simple reason that the clinics had different EMRs and were lucky to be able to export their data, period, let alone export and then map the data to a common data transport format.

    Clearly, each time a new clinic came on board with a new EHR, a new formatter/parser had to be written to get the data to the e-hub and back out again, but we got tired of this and wrote a “sniffer” that could read a new format and write a parser/re-formatter for that format.

    We never got beyond the pilot stage because our customer was acquired by a large healthcare entity.

    To this day, we have no clue what happened to the e-hub application.

    The system did manage during the pilot stage to process 100,000,000 transactions over 12 months without fanfare.

  • Karl,
    I love how you say you haven’t seen it be harder to work with 2000 client installs and then you talk about all the complexity you had to deal with when there were so many installs, no common format, etc.

    Like I said, it’s not impossible and from an end user perspective you can make it seem the same, but it definitely takes a lot more work.

  • John.

    LOL. the apparent inconsistency can be explained by pointing out that the “sniffer” removes most of the complexity.

    All you need is a representative sample of a new format, you then run the program and get a new format.

    For sure, you have to tweak your program now and then.

    A crosswalk matrix of publishers/subscribers simultaneously handles the issue of what subset of a publisher’s data any one subscriber wants/needs and the on-file format each subscriber needs to read the data.

    As and when the formats change (and they do), your mapping fails and you then reverse engineer again.

    I suppose the rule sets that are in the sniffer could be described as complex.

    In general, once we have automated something complex, does this mean it remains complex or can we now say it no longer is complex?

  • Karl,
    I agree that you can remove the complexity from the end user, but it’s hard for the vendor to do it. That’s why they haven’t gotten to it yet (at least most). Although, I’d argue that updating your “cross walk” is hard work too since they love to change things and there is very little that’s standard across medical practices’ IT.

    Of course, I’ve always loved the concept the best business is something that takes something extremely difficult and makes it easy. That would be my philosophy for investing.

  • Let’s not confuse ourselves here.

    Using your test case of 2000 clients.

    I don’t care if you are using cloud EHR or not, 2000 clients takes a good deal of effort to manage.

    So, in this size install, I’m raising the BS flag on the cloud being cheaper and easier to manage. There will be too much on those clients that has to be managed to say that 1 additional software is breaking your back.

    IF you were to say 2000 thin clients…well, now at least there is an argument.

    Add to this, many cloud EHRs still require client software to be installed…yes, you heard that right folks, some of the most used (notice I didn’t use the term “popular”) EHRs cloud version require software to be installed.

    And…of course…the upgrade process is still as arcane as their client/server version which means, you must manually update each client.

    I’m still a firm believer that if the EHR vendors wanted to make their client/server version easy to manage…they would.

    That being said, I also believe that in smaller offices, let’s say 10 computers or less, the cloud version generally makes the most sense.

    Yet, this still goes back to the fact that the EHR vendors are not trying to make things easy for the client/server user.

    Does this surprise anyone? We all know the EHR vendor will make more selling their cloud version vs the client/server version.

  • John Brewer,
    That’s a different discussion. This isn’t about managing 2000 clients on either system. It’s about creating things like APIs or exchanging data or doing queries across 2000 systems. All of these are much easier if they are in one controlled environment versus being spread across 2000 different environments.

  • Ah, third time is a charm.

    Sure, having it all in house is easier.

    But, written & managed correctly, those 2000 separate servers being tapped into are not a big issue.

    Sure not as clean and neat as being all in-house, but who is the customer here?

    Who really is the customer of the EHR?

    This isn’t about making it easier for the EHR vendor….

    Besides, there are plenty of folks out there who plop their own server in a private practice to mine through their data (de-identified of course), that is then sent to their own “home” server.
    These folks are happy to 1) supply a server for this 2) pay the practice for this.

Click here to post a comment