Most EHR products, or technologies, in both the hospital and ambulatory market are currently deployed through a local client/server paradigm. The client software is installed on users' PCs and the server software, including the data storage, resides on site in the hospital data center or the clinic office.
However, with Web 2.0 and Cloud Computing upon us, web based EHRs, Practice Management and Billing systems are sprouting all around. Is this the future, or is this customary cyclical IT hype?
A little bit of both and, as usual, the real answer depends on accurate definition of terms.
The first term we need to define is Software as a Service (SaaS).
In the classic (legacy) paradigm, software was built using a Client/Server model. The Server software is proprietary and runs on a big server machine. The Client software, also proprietary, usually runs on each user desktop and connects to the Server software via a local network, or a virtual private network if the server machine is located outside the local network (in a remote data center instead of under the lunch counter in the office).
SaaS, strangely enough, also uses a Client/Server model. The Server software is also proprietary and runs on a big server machine. The Client software runs on each user desktop, but it is not necessarily proprietary. In most cases the Client software is nothing more than a browser. Whether the client is a browser, or a proprietary client, SaaS software is accessible on demand over the Internet, and this is the main difference in paradigm. The SaaS Server may reside on site, but usually it resides in a remote data center, far away.... in the Clouds.
So what is a Cloud? A Cloud is a little drawing used in network diagrams to symbolize the Internet. Thus Cloud Computing really means computing over the Internet. It doesn't really matter where your servers are and it doesn't really matter if your client is a browser or a proprietary program. As long as the Client and Server communicate on the Internet, you are engaging in Cloud Computing.
Simple? It should be, but the current hype in the industry creates the illusion that Cloud Computing is a novel idea and somehow has something to do with the Amazon Cloud, or some Google service application.
Not so. Just like in the good old sky, the computer world has many types of Clouds.
First there is the Private Cloud which refers to having your Server on site, in your own data center, or even in a commercial data center where you rent some rack space.
If you don't want to invest in servers and routers and load balancers and lots of techie employees, you can rent all the computing power you need from such folks like AT&T, Amazon and a myriad of other players. For a little extra cash, they will manage your Server software, including updates, patches and everything your, now unemployed, IT guys used to do. These are the famous Clouds, and as you can see there are various degrees of Cloudiness.
When we talk about EHR, the most common type of Cloud is a "Vendor Cloud" - web based EHRs where the vendor manages the Servers in their own data centers, or in rented data centers. This is the athenahealth model and more recently Practice Fusion, Ingenix CareTracker, Quest360 and an ever increasing number of new entrants and old timers transitioning to web delivery systems.
How about the industry veterans who recently began to offer their Client/Server software as SaaS? Are these new products, or questionable advertising? Neither. You should know by now that all software is really Client/Server. All it takes to jettison an application to the Clouds is to remove the Server from the user's office and make it available to the Client on the Internet. And “on the Internet” does not necessarily mean in a browser. That's exactly what folks like eClinicalWorks and Allscripts MyWay and many others are doing now. Just like the purists' SaaS and Clouds, these non-browser based systems are basically renting out computational and IT resources, by hosting the server machines in their very own Clouds, and some, like Synapse EMR, even in the famous Amazon Cloud.
There are differences, of course. Systems built for the web from the get go are able to share resources better and need much less infrastructure. For example a natively browser based systems will store hundreds or even thousands of different customers in one data base and can get by with one instance of the Server running with multiple redundancy and load balancing. The original Client/Server products still require one server per customer, albeit a virtual one these days, and maintenance is no small feat.
So now that we understand the reality of Clouds, which one is better? The simple answer is that how an EHR got to the Clouds does not matter much. In both cases your capital expenses and IT needs are drastically reduced. In both cases you can access your software from outside the office. It may be a bit tricky for the Client/Server Cloud, but it's still doable from most places you would want to use your EHR, and with the advent of mobile access on iPhones and Blackberry, you really shouldn't have to bring out the old laptop on the golf course.
Maybe, the web based EHRs are better suited to the new interoperability requirements? After all they already reside on the web and there's nothing more common than a browser, right? This is only partially correct. Automated exchange of data on the Internet does not occur through browsers. The biggest interoperability advantage web based EHRs have is due to the inherent aggregation of all customer data. Instead of hundreds of data bases, they only have one. Instead of hundreds of "communications" pipes, they only need one. While a web based Cloud needs only one pipe to other Clouds, the Client/Server Cloud needs as many pipes as they have customers. The onus is on the Vendor, not the customer.
Well, how about modularity and choices for the customer? Unfortunately, this is another misunderstanding. Modularity and availability of plug-and-play EHR modules is made possible only if the EHR vendor decides to allow it, be it web based or not. The fact that you can access the EHR through a browser does not mean that you can plug in another piece of software that you can also access through a browser. True, if the EHR vendor decides to open the platform to others, it is easier to create new modules for a browser client than a proprietary client, but only slightly so.
The take away for anyone searching for the perfect EHR is to beware buzz words, Clouds and Vapors in general.
The 800 lb. Gorilla in the Clouds is of course Security and Privacy and peace of mind. We will look at those in a future post.......
Posts
What Did New Data Show About Drinking Wine?
13 hours ago
There is actually a distinct difference between SaaS, or web based computing and "Cloud".
ReplyDeleteCloud Computing implies that computing resources are provisioned on the fly - often without any human interaction on the side of the service provider - and are often billed in small incements - per minute, per hour, per GByte transferred etc.
Services that are Cloud enabled (private cloud, public cloud, or a SaaS cloud) dramatically lower the cost for the service provider and thus for the customer.
EHRs delivered via SaaS are nothing new - going to Cloud would require quite a bit of standardization in business processes on the side of the customer as the EHR would necessarily need to be a commodity.
Florian,
ReplyDeleteI of course completely agree with your comment. The problem is that multiple EHR vendors, I assume in a marketing effort, have been using the term Cloud for anything that does not reside on a customer site.
As Larry Ellison has said a while back, "The interesting thing about cloud computing is that we've redefined cloud computing to include everything that we already do,...."
There will be a very long time before any EHR can be offered as a true Cloud based application, if ever, for the exact same reasons you pointed out - commoditization of EHRs is as far away as commoditization of health care delivery itself.
Margalit, I’ve recently discovered your blog and new HIT forum. Hats off to you for offering a simplified explanation of some of the emerging Internet health information technologies, and thus addressing the conflicting information that abounds in the industry! I wanted to hopefully shed some light on a few points that we have found to be most confusing to physicians (particularly those in smaller practices).
ReplyDeleteSoftware as a Service (as the name implies) is really a business model – rather than a technology. With SaaS models, software is deployed over the Internet to a large number of users. Formerly known as Application Service Providers, SaaS providers encompasses everything from Terminal Services (which, as you’ve noted, is an example of where the server might reside on site, and users are given visual access to the application) to Web 2.0 applications that are delivered through a browser, to the most advanced applications that route data to users via a virtually private Internet connection. I would like to stress the following very important points. Modern Internet-based systems are designed for the public network and offer efficiencies not only for connectivity but user performance and cost. The legacy Client/Server products were designed for LAN environments and even if they are now repackaged and delivered over the Internet (or ‘cloud’), lack all of those benefits. This is the legacy vendors’ ‘quick and dirty’ jump into the SaaS business model. Not all SaaS models have the same underlying technology and they don’t all reduce IT needs and capital expenses.
Aside from their poor connectivity traits, these solutions also aren’t terribly efficient at scaling. For instance, any software system that runs via Terminal Services or Citrix requires that server capacity be adjusted as users and loads are added. Further, the number of concurrent users may be limited, and speed is dependent upon the load of the particular server that is being accessed by a user at any given time. A true ‘cloud’ model supports a load balancing architecture in a very efficient manner. Healthcare applications that are designed for the Internet ‘cloud’ model are especially good at those tasks because they can take the application flow model into consideration when implementing load balancing and fault tolerance. There are also some security considerations, which it sounds like you’ll be addressing in an upcoming post. Solutions like these are thus really not suited to a mission critical application like an EHR.
Systems that truly function in the cloud such as Nuesoft’s NueMD (and those that you described as existing in the Vendor Cloud in your post), are by contrast, a superior alternative, or in better words, ‘the real McCoy’. Due to their modern architecture, they not only offer users more flexibility and speed, but are also more conducive to interoperability and scalability in a highly cost effective manner. We strongly believe they will better support the vision that the government has for widespread HIT adoption under HITECH.
For a more thorough analysis of the differences, here is a fact sheet that describes the evolution of technology: http://www.nuesoft.com/pdf/technology-evolution-factsheet.pdf. Thanks for the opportunity to comment and I’ll look forward to your future musings about security issues among the varying types of systems.
Great points Jennifer. There is of course a huge difference between putting a server in a remote data center and a true multi-tennant SaaS application.
ReplyDeleteAs Florian also wrote above, I don't think EHRs even web based ones, have reached the level of SaaS as provided by the likes of Google or Amazon, even though I know of at least one EHR vendor that hosts the EHR at Amazon.
All that said, I am often amazed at the low subscription prices of former client/server applications, once they become "SaaS", or more accurately, hosted. I would be very curious to see how long this particular business model can be sustained.
SaaS is an acronym for Software as a Service. ... ^ cloud computing lies in the way it changes the economics of computing, that is that it creates a marketplace with service providers and consumers, learn saas application
ReplyDeleteGreat thoughts you got there, believe I may possibly try just some of it throughout my daily life.
ReplyDeleteSocial Learning