Page 19 of 36
Previous Page     Next Page        Smaller fonts | Larger fonts     Go back to the flash version

When the EHR application is hosted on a remote Web server, it’s one of dozens of practices being concurrently served by a single computer (or blade in a server array). All practices are running instances of the same EHR ap- plication. A high-speed Internet connection introduces a half-second to 1-second round-trip delay into screen updates, and EHR Web-server application delays add more time due to switching between concurrent us- ers. Worst-case SaaS Web-server response time can be 2 seconds or much slower than the offi ce-deployed counterpart, and it needs to be specifi ed in the licensing agreement (as does what happens if maximum response time is exceeded). That’s the speed trade off.

EHR work-fl ow customization trade off In pure SaaS Web-server-only approaches, individual practice customization must work through the Web browser, which generally provides fewer customization options than do offi ce-deployed EMR counterparts. This may make it more diffi cult to enhance ease of use and improve work-fl ow effi ciency.

PMS integration trade off Achieving Web-based EHR integration with an exist-

ing, offi ce-based practice-management system (PMS) can be challenging, but achieving it through a fi rewall and secure tunnel to an Internet-based SaaS EHR server is even more so. As a result, many SaaS Internet-based solutions include an integrated EHR/PMS as a single product, but there are a couple problems: First, it adds to cost. Second, it forces the use of a new PMS at the same time a practice is learning to use an EHR for the fi rst time.

Upgrading to new version trade off

Upgrading to a new version of the EHR software can be very disruptive. Anyone who upgraded from Microsoft Offi ce 2003 to 2007 (with its “improved” user interface) will understand. The Microsoft “improvements” were unfamiliar to most existing Offi ce users, and therefore the new system slowed them down and crippled work fl ow. Many offi ces skipped the upgrade and continued us- ing Offi ce 2003. They could do that because Offi ce is run on their offi ce computers, not delivered as an Internet service. Had Offi ce been a Web-based SaaS application, all users would have been forced to upgrade and suffer the work-fl ow disruptions it caused. In the Web-based EHR SaaS approach, the EHR developer controls when EHR application updates oc- cur, and they are generally mandatory. When forced to choose among Web-based SaaS approaches, try to fi nd an EHR developer that hosts two versions on two serv- ers, one with the latest version and a second with the last legacy version.

Increased deployment failure trade off Lack of customization to improve work fl ow and

diffi culty using EHRs are the two leading causes for the current 30 percent EHR system failure rate (cited by AMA News) within the fi rst two years of deployment. What’s the logic of pushing 100,000 primary care practices to adopt only EHR solutions that offer limited customization? Most new offi ce-deployed EHRs offer more customization options, and a few offer fully inte- grated, user-accessible work-fl ow management engines. Focusing strictly on the Web-based SaaS approach raises the specter of increased system-deployment failure rates. Apart from the $8.5 billion dollars of ARRA funding that action could waste, it could also mean that more practices won’t achieve meaningful use. The technology exists (on the MSP EHR Selector: to match each practice to an EHR that is right for its needs and practice readiness.

Congress may not have understood the damage HITECH would do by severely disadvantaging and pe- nalizing hundreds of otherwise viable offi ce-based EHR developers that don’t offer the politically correct SaaS approach. Coupled with delays in defi ning meaningful use, the package has cost some private sector jobs while creating mostly bureaucratic and not-for-profi t jobs, many that are costly and probably not sustainable over the next fi ve years. There seems to be a bias against ex- isting private companies providing essentially the same services as newly created, not-for-profi t services.

Provider liability for SaaS server breach If a SaaS EHR Web-server site is breached, is the physician practice a party to the breach and litigation that may ensue from it, or is it protected from such lawsuits? How well are individual physician practices – following REC advice and adopting Web-based ASP EHR solutions – protected? These are legal questions that need to be discussed with an experienced healthcare law fi rm. Don’t depend on REC-provided, boilerplate licensing agreements to determine if adequate protec- tion is provided.

The bottom line

There is no best deployment choice for all practices. Each alternative has its own trade offs and issues that must be understood and addressed. The authors believe that the government is doing physicians and EHR devel- opers – whose business depends on selling to physicians – a great disservice by allowing some RECs to emphasize one particular deployment approach to all PPCPs. Physi- cians in solo or two-provider practices particularly need to understand the choices and consider the trade offs, because the move to force EHR adoption nationwide puts their very practices at risk.


Previous arrowPrevious Page     Next PageNext arrow        Smaller fonts | Larger fonts     Go back to the flash version
1  |  2  |  3  |  4  |  5  |  6  |  7  |  8  |  9  |  10  |  11  |  12  |  13  |  14  |  15  |  16  |  17  |  18  |  19  |  20  |  21  |  22  |  23  |  24  |  25  |  26  |  27  |  28  |  29  |  30  |  31  |  32  |  33  |  34  |  35  |  36