Which Is Best: Client-Server EMR or Web-Based EMR?

Three things initially attract people to web-based EMRs over client-server EMRs: they are easier to deploy and upgrade, demand less IT support, and require less hardware. While it is true that web-based deployment and upgrades are easier, client-server technology actually delivers far superior benefits and long-term cost savings on the second two criteria.

For a start, the IT support argument ignores the significant trade-off between physicians’ time and IT staff time. Physician productivity is a crucial part of any practice’s bottom line, which amplifies the limitations imposed by EMRs whose architecture relies on the Internet. Anyone who’s compared the speed and performance of PC-installed Outlook with Outlook’s Web mail accessed through Internet Explorer knows that client-server software affords a richer, crisper user interface that outperforms browser- or web-based software in terms of the number of clicks and the ease of use. Gaining just 30 seconds of productivity per exam with a fast and robust client-server solution can generate an additional $50,000 per year or more for high-volume specialists.

Internet lag/latency can also be very costly, particularly during the “Internet Rush Hour” when millions of teenagers come home from school to play online games, view YouTube videos, and communicate with each other on Facebook. This may result, over the course of a typical patient exam, in repeated several-second delays between the physician’s web-based EMR and the server where the patient’s data exists, increasing the time it takes to pull up patient information, make a prescription, retrieve a document, or display an image. These protracted, productivity-sapping delays can have a significant impact on revenue.

When it comes to hardware, web-based vendors tout their cost savings by claiming that all you need is a computer with an Internet connection to be up and running. This is not quite true—like all client-server offerings, a web-based EMR requires exam-room PCs, tablets, and laptops, as well as computers at the nursing stations, a wireless networking infrastructure, and a Windows server to manage logins and network security. In fact, the only difference in hardware between the two solutions is that the client-server solution needs an in-house, plain-vanilla Microsoft Windows server, which costs just a few hundred dollars per year per physician when amortized over the life of the server. In contrast, practices using web-based EMRs must absorb the frequently exorbitant fees that are built into the subscription model to cover the cost of the web-based company’s sophisticated data center. Over the long term, a client-server offering often costs far less than a web-based subscription offering, and a well-designed client-server EMR always delivers productivity-enhancing benefits that save physicians both time and money—something they sorely need in an era of lower reimbursements and higher patient volumes.

17 thoughts on “Which Is Best: Client-Server EMR or Web-Based EMR?

  1. Have you checked the cost of a fault tolerant infrastructure recently? If not, have you checked the cost of your client/server environment going down? How much is it costing you per hour while you wait for what ever happened to your server/network to be fixed? I agree, that if you are large enough, it would make sense to keep everything in-house currently, but for a small to mid sized clinic to have the kind of uptime guaranteed by a commercial internet provider, and a cloud based EPM/EMR, is very cost prohibitive. You are talking distributed, clustered servers and storage, off-site backups, and D.R. plans, and a staff to maintain it all. You could easily spend $200k to make you that additional $50k per year.

    Of course, you could always go the cheap route. White box server, built and installed by the receptionists boyfriend (who if really good at W.O.W.). Depend on remote support from your vendor, hope the backups are working (you can just set those to back up to the boot drive, right?), then just count on 3 or 4 random days a year that it goes down.

    [Evan Steele says]

    I agree that the cost of having your EMR down for even a short period of time is unacceptable. The easy solution is to deploy another, lightweight, read-only server that you can automatically switch to in the case of an emergency. The cost of that solution is minimal. An alternative is to reuse an existing server, which has no additional cost.

  2. While what is said make some sense, it misses the whole goal of digitized health care. The ultimate goal is to digitize paper, it is the ability to share that information to reduce errors and cost. Client Server based EMRs are siloed requiring HIE to be implemented before true value of electronic health to be realized. For a physician to make a purchase decision, a client based system locks him in. The better model is the cloudbased emr which is on a monthly subscription or free. The client server model may work better for the larger group which can afford IT expertise but with the known upgrade requirements to meet 2011, 2013 and 2015 meaningful usage, it will be more costly and frustrating for the one MD practice to get the attention of the vendor to service. For example, if you have a client server and you want to get lab integration to meet the CPOE (computerized order entry) this will be costly as some national labs won’t integrate w you unless you are ordering enough volume.

    As for the speed and bandwidth, this will eventually resolve over time since the trend is going toward cloud and massive amount of investment is being made by the feds and private company to address this.

    In the end, for most doctor the choice for emr is a long term decision since most do not ever want to switch again because of training, cost etc. To invest in server based solution may not be an investment in the future because it limits the choice of the doctor. There are rapidly new solutions that will deliver virtualized office. We are starting w it.A that is to say all front and back office functionalites built around a cloud based based platform to give the small offices the advantage of a larger practice at a fraction of the cost. In summary, the choice is no longer about web-based or server based, it is more about what services can be virtualized to help physician office the competitive edge they need to be more efficient and dekiver better care.

  3. Could not disagree more on the cost issue. Having some experience with both systems in a small office, the hassle and IT costs are significant when they are on your end as opposed to a remote server. The service and reliability of a professionally managed server farm is light years above what you can do on the provider end unless you’re institutional in size with your own full time IT staff. Hardware maintenance and upgrades alone will kill small operations.

    In addition, the idea that “30 seconds” on an encounter can actually translate into $50K of lost productivity is silly if you’ve ever seen the flow of an office. These 30 second increments are not bankable in a way that you could simply sum them up at the end of the year and suggest you’ve lost that many hours of productivity. That’s a academic rather then a pragmatic view of such small increment of time.

    [Evan Steele says]
    I believe that a 30 second productivity increase per encounter translates directly into bankable revenues for physicians. By example, let’s look at a busy specialist seeing 40 patients per day. 1/2 minute more per exam frees up a total of 20 extra minutes per day – at 10 minutes per exam, that’s 2 more exams per day… a 5% increase! On $1 million in annual revenue, the 5% productivity increase results in an extra $50,000 of income by year’s end and $250,000 over 5 years. For a small, 3 physician practice, the revenue difference over 5 years is $750,000 which dwarfs the cost of having a server in-house.

  4. Cloud computing rules for smaller offices! See google, youtube and facebook. Do you offer that option? Our pm is web based. Would never go back to client server.
    Productivity calculations are sexy but theoretical. Very few physicians work at 100% capacity. Cancellations are the rule.

  5. I think both systems have advantages and disadvantages… just like everything else. For those that are on board with the online model, you can’t deny there are concerns with this model. What if your Internet goes down?

    Likewise, having a client server poses some unique challenges (IT staff, maintenance, cost, back-ups) as well. Can’t deny that.

    In terms of cost, I think practices that go with the web-based EMR system underestimate the cost issue. While it is true that the up-front cost is less than buying a server and software, when you figure out the long term month-to-month fee over a 5 to 8 year period, the cost is similar to the client-server system. In fact, in the long run, web-based EMR could even be more expensive in some cases.

    Just like most everything we do in our practices, we have to evaluate the pro’s and con’s as it relates to our unique needs and make a decision as such.

    Oh, and refrain from criticizing others that consider other system better than yours. Because for that practice, that decision was the best for them.


  6. Pingback: Browser-Based vs. Client-Server EMRs: Productivity is King - Straight Talk by Evan Steele CEO SRSSoft - emrupdate.com

  7. Oh, I just love this debate. If you think carefully, it is a debate whether a browser client is better than a proprietary client (or thick client). And the question is of course, better for what? For occasional use and simple things like paying bills on line, browser is best. For heads down 8 hours days of work, thick client has better potential to make one’s life easier.
    The best model in my opinion, is Outlook. Have both and use them as appropriate.

    Every software has a server. Whether it is in your office, managed by you, or as a black box managed by the vendor remotely, or whether it’s in some database half way across the country, is a different question altogether.
    I would submit that it’s largely a matter of personal preference and circumstance, since as others have noted, each solution has pros and cons.
    The most important aspect in selecting an EMR is not really where the server resides, but how well it works for your office, how much it increases your efficiency and how much it improves patient care. Other than that everything else is a wash.

  8. As is often the case, oversimplification of the issues abounds. The local server deployment can provide some cost savings if executed and maintained by a competent, cost conscious tech team. But keep in mind that in addition to absorbing the very real cost of assured downtime and mental anguish, the doctor(s) are then also responsible for maintaining a HIPAA compliant datacenter at their site.

    There are good reasons why the hosted EHR vendors pay for all that “extra” stuff like Completely Fault Tolerant infrastructure, Daily Offsite Backups, Enterprise versions of Database and OS, Network monitoring and Intrusion Detection, Detailed performance monitoring and reporting, Disaster Recovery components, and of course having top notch tech experts with “butts in seats”, 24×7.

    It is not accurate to compare that setup to what a doctor and their trusted techs might cobble together with a spare “box” in his office. 9 times or better out of ten, I found that small practices get a much better value out of a remotely hosted solution.

  9. With respect to the Client/Server VS Browser presentation, I agree that it is far more likely that a user will get a richer, more productive EHR interface from the client server arrangement.

    However, I must point out that this is primarily a result of many more years of experience in that way than due to an inherent limitation. I moderated a 2 hour debate by 2 halves of a 30 person EHR development team on this very topic in 2005. The conclusion reached was that it would require extensive browser based functionality and intricate database record staging to be successful both in useability and in raw performance.

    This is heady stuff if you are a developer. Only the very best of web developers today are capable of producing such an application whether using Microsoft, Adobe, or open source Web 2.0 type development tools.

  10. I find this conversation very interesting, as I am coming as a 30 year vet in Healthcare IT. I have worked with many vendors, physicians, clinics, private practice and Hospitals, and it is indeed a personal preference, and ultimately ends up being bottom line COST. There are areas in both that support the decision of Web verses Client Server. I assure you that vendors (yes even those Web based) will promise you the moon in their dog & pony show, however, having us IT folks around to ask the correct questions could end up saving you not only money, but legal aspects. Having seen this industry change over the years, I promise you that there is no perfect solution in this decision process. and Web is no better in keeping up with the ever changing rule and regulations than an IT staff is. Change is a constant in IT Heatlhcare, and that is about the only gurantee that you can count on.

  11. As a consultant, I’ve worked with hardcopy, scanned, and digital records for over 30 years. My personal experience researching client/server versus web based records solutions in several industries, including health care, is that “productivity”, like “ease of use”, is in the eye of the beholder. Which is to say two things – 1.) your personal experience, however anectodal, is all that matters to you regardless of statistics across a broader population and 2.) if you’ve experienced a “crash” on a locally hosted solution or a world wide web traffic jam at any time, this will seriously affect your personal opinion about which is better. If you’ve been lucky enough to avoid either of these, then your preference comes down to the interface – in most cases, Windows versus browser. My experience servicing physicians indicates that at this level, all other things being equal (such as overall EMR design in either environment) Windows is more responsive, flexible and integrated than browser technology, at least at this stage. Referring back to the point that the physician is THE high end revenue producer in the clinic, it makes the most sense to make this resource most effective.

    And lastly, while collecting 30 second increments into buckets of 20 minute visits and multiplying them until they magically make you $50K per year, it’s also stupid to say its okay to waste 20 minutes every day just because you can’t track and utilize time in exact increments. I haven’t met a doctor yet who says I can have 20 minutes of his/her time every day for “free”.

    Patrick J. Casey, MBA
    Consultant for AvivaEMR by Records 1-2-3, Inc.

  12. I am looking into a web based integrated billing and EMR. I am a solo ENT. An issue that may impede an web based subscription model is audiology. A few years ago Medicare began to require audiograms to be billed with the audiologist NPI as well as the corporate NPI. I have several part time audiologist. All together they add up to less than 1/3 of a PTA. If I were to have to pay a subscription for each one I would pay the vender more than we receive for the audiograms! I would imagine this would also be a problem for any practice that hires any part time or locum. The cloud vendors are going to have to resolve this problem.

    [Evan Steele Says:]
    Most vendors will adjust pricing to reflect part-time extenders.

  13. It also matters whether a physician works from multiple offices. If so, then a client based server would only be at one location and the other offices would need to communicate with that server via a T1 line or similar connection anyway, and thus a wholly web based system may make more sense.

  14. Three things initially attract people to web-based EMRs over client-server EMRs: they are easier to deploy and upgrade, demand less IT support, and require less hardware.

  15. Since it has been two years + since my last reply, it is appropriate to provide an update.

    As originally mentioned, it has in the past been easier to get a rich client experience (UX -user experience) with a Client Server implementation. This was due to the fact that there were many years of experience in developing UX’s in VB and other client oriented technologies and this was only more recently begun for Web based products.

    I am happy to say that over the last year or so, I have seen some pretty impressive web products with respect to User Interface. It is still a work in process for most EHR vendors but we are seeing web solutions which address many of the web windows limitations.

Comments are closed.