Client/Server vs. ASP/Web-Based in Healthcare IT

I get tons of email for healthcare IT advice (which I love, so keep the questions coming) and every once in a while a question comes along that I decide to answer here since I think it will be interesting to many readers. Here’s a great one from yesterday:

I am a frequent reader of your blog. I find your writing very pertinent to my own business. I run a development shop that creates EMR software and our company is currently in a debate about the future of our application architecture. We are a client/server based application. We sell to small clinics, multi-specialty and large hospital settings. We usually play along side the GE Centricity, NextGen, Meditech and AllScripts EMRs – interfacing primarily via HL7. We encounter the same issues as any other client/server based application. There are high deployment costs. Implementations and upgrades are very costly.

Recently I have been pushing the strategy (internally in my company) of moving to an ASP model. I have been evangelizing on the merits of this architecture as a way to cut costs and support a more dynamic delivery model. There are obviously many gains to be had.

What I was wondering is in your experience how much of the healthcare application space is already using or is moving towards an ASP model? Is the healthcare world comfortable with this paradigm? We have always written off this model as risky due to HIPAA concerns. Why aren’t the major EMRs going this way? Will they? Won’t they have to? I just see it as the inevitable evolution.

First, let me thank the reader for the question. I bet he feels alone like the fellow in the picture above :-).

Now, let’s talk about the state of the applications architecture world in healthcare IT. Lots of healthcare applications are still (yes!) running on mainframes and mid-range computer systems connected to “dumb terminals” running text only user interfaces (using in many cases very old but still quite functional MUMPs software). This is the “big iron”.

Most healthcare applications today run on the client/server paradigm with “fat client” applications running either UNIX or Windows on the server and Windows user interfaces on client PCs. This means that the database server is usually on its own computing hardware and the user interfaces (data entry, reports, etc) run on the user’s PCs. Very traditional, tried & true, and things work (but have plenty of deployment issues).

There are only a few pure web-based applications out there in the EMR/EHR world. Of course, the PHR world has tons of web based software (almost exclusively). There are many hybrid solutions out there where legacy EMR vendors have put “web portals” in front of their legacy client/server solutions. These portals are often useful but not as useful as complete web-based systems.

There are many companies that have client/server software but also run in an ASP (application service provider) model by using either Terminal Services or Citrix to provide remote and multi-user access from a single deployment architecture.

To answer the reader’s specific questions:

In your experience how much of the healthcare application space is already using or is moving towards an ASP model?

Yes, many healthcare IT providers are using the ASP model. It’s generally safe and if architected properly it works well. Of course the ASP model using client/server architectures is much harder than the web model but it’s certainly achievable using Microsoft and Citrix desktop sharing technologies.

Is the healthcare world comfortable with this paradigm? We have always written off this model as risky due to HIPAA concerns.

Hospitals and large organizations are not necessarily comfortable with external ASP but the small to mid-size market (physicians, small healthcare groups, etc) are comfortable with the model (in fact, they prefer it over on-premise models). However, even the large hospitals and organizations that are uncomfortable using external ASPs would love to use ASP models in their own data centers (in fact, many are requiring it these days).

HIPAA concerns are almost all mitigated these days by using VPNs, leased lines, or other encryption mechanims so it’s really no worry.

Why aren’t the major EMRs going this way? Will they?

Many are already going this way and those that aren’t will whither away quietly.

Won’t they have to?

Yes, they will. If EMRs can’t be hosted on premises, in an externally managed ASP, in an internally managed ASP, and “in the cloud” simultaneously they won’t have a long shelf life. All successful EMR vendors will allow multiple deployment models if they really want to grow big. If you want to stay small you can choose one model; if you want to grow big, you will choose a flexible model.

Last words of advice for all software vendors: don’t think that “the cloud” or “ASP” or any specific deployment model will fit all needs. Create a flexible approach using modern web techniques that lets your users tell you how they want things deployed. No single model will work for very long or for a large number of customers.

Newsletter Sign Up


8 thoughts on “Client/Server vs. ASP/Web-Based in Healthcare IT

  1. So here is my question/issue with the ASP model. Friend of mine use to call it “Guy on a Backhoe” problem. As most smaller practices don’t have multiple telcom providers or redundant channels available, what happens when their telecom capability gets disrupted (ex guy backhoes though the cable). Now they don’t have access to their patient records. How does that impact their operations? Do they close their doors till things are restored? A similar issue came up with the VA as they looked at various forms of ASP models for Vista. But in the end they still needed to have some local EHR capabilities in order to ensure patient care if they are ever forced off the grid.

  2. Great question, Kevin. The real way to think about it is like this: if you’re going to use a utility (like electricity) you’re going to pay much less money than if you didn’t use a utility (like you have your own power generator). For this price reduction you are going to rely on other people and the reliance comes at more risk but the reason you’re choosing to go with more risk is that the price is lower.

    So, if you want ASP you want it because it lowers your cost for management, purchase, etc. But, it also means that you risk being down every once in a while. Usually that means keeping paper backups for that day’s patients or a day or two in advance if you can’t live without any downtime whatsoever. Now keeping paper is also a cost — which, again, you’re bearing to reduce to risk.

    Basically, it boils down to a customer choice: if they are willing to live with zero risk and full control of data and servers in their own office they should use the “on premise” model.

    If they are willing to live with a little risk then they should choose the ASP model.

    This is why I mentioned in the my article that vendors shouldn’t think that “the cloud” or “ASP” or any specific deployment model will fit all needs for all customers. Create a flexible approach using modern web techniques that lets your users tell you how they want things deployed.

    No single model will work for very long or for a large number of customers. Some customers will want on-premise because they accept zero risk and want full control; others will accept a little risk and go with ASP or cloud computing.

  3. The PACS Designer

    Reply

    The ASP Model is definitely the way to go if you are going to add flexibility to your client/server system and attract new customers. Additionally, there are other enhancements that can be added to work offline when the phone service is interrupted. Of course you will need to input data that is created while working offline but it should not be a huge task if service interruptions are brief.

  4. There is another alternative!

    Java Web Start gives you the simplicity of the web with all the advantages of a thick client. Web Start is a Java deployment mechanism that delivers Java desktop applications using the web. Go to a web page, click a link and your program launches. It can also be launched via an icon on your desktop.

    With recent releases of Java 6 update 10 and Java FX you now also have this available in the browser. Embed your application in a web page. http://javafx.com/

    The server can then be either dedicated or ASP (SaaS). It does not even need to be Java.

  5. Pingback: HealthBlawg

  6. Great and insightful post! I have happened to see an increased move to a hosted solution for clinical and financial processing over the last several years. I would be interested in hearing why the perception is that there is increased downtime for ASP solutions. In my experience, I have found this not to be the case.

    The “on premise” model also has risks, and can experience downtime. In the field, these unplanned outages occur due to a variety of reasons, supporting old equipment, not having a fully redundant power design for the local datacenter, not monitoring the application, not performing basic monitoring on the database, and variety of other reasons. Often these risks are responsibilities are transferred to the ASP.

    Looking forward to hearing your response,
    Elyse

  7. Hi here I am a medical doctor..cum IT manager for my hospital in malaysia.We have been using EMR and THIS for the past 10 years.Until today we are still using our client server based application..the vendor offered us an upgrade to web based however we are very,very sceptical about it.My view is that i believe client server application is still the best solution to THIS or hospital based application rather than web based application..it is faster,upgrades can be controled,there is no bottle neck in the web servers and u can have multiple screen openeing up at the same time without compromising accessability speed to the database..opening up multiple screen is necessary becoz u need multiple input before any decisions can be made to treat patient ie u need blood test,radiological,ulrasound,biopsy results etc.. at the same time in order to decide your next step of management..worse still if the emr allows data to be stored in image,video and audio form..accessing the EMR during clinic days would be very painstakingly slow..but much appreciate if you could give your views..

  8. Hi here I am a medical doctor..cum IT manager for my hospital in malaysia.We have been using EMR and THIS for the past 10 years.Until today we are still using our client server based application..the vendor offered us an upgrade to web based however we are very,very sceptical about it.My view is that i believe client server application is still the best solution to THIS or hospital based application rather than web based application..it is faster,upgrades can be controled,there is no bottle neck in the web servers and u can have multiple screen openeing up at the same time without compromising accessability speed to the database..opening up multiple screen is necessary becoz u need multiple input before any decisions can be made to treat patient ie u need blood test,radiological,ulrasound,biopsy results etc.. at the same time in order to decide your next step of management..worse still if the emr allows data to be stored in image,video and audio form..accessing the EMR during clinic days would be very painstakingly slow..but much appreciate if you could give your views..

Add Comment