Important topics seldom discussed at EHR conferences

It's what we don't hear at EHR and HIE conference presentations that gets our attention. We hear the assertion that Web-based EHRs are superior to other alternatives for smaller practices, but we don't hear much about their bad points. One provider's solution is another provider's problem — particularly when 100,000 primary care physicians (known as priority primary care physicians, or PPCPs, when they sign up with regional extension centers) are involved. The “single-deployment approach is best for everyone” assertion being propagated is a dangerous and potentially expensive myth. In our opinion, there are three major deployment approaches each practice should consider.

1. Deploy EHR on an office server;

2. Deploy EHR as Internet service and access it from a Web browser in the physician's office (software-as-a-service, or SaaS, approach); and

3. Deploy EHR as a service, but from either an office-based Web server or a remote Internet-based Web server (“blended deployment” approach).

Judging from regional extension center (REC) request for qualification (RFQ) documents we reviewed, some government-financed RECs clearly favor the second, Web-based SaaS approach. While a good choice for many smaller physician group practices (because it eliminates in-office server management and back-up issues), this approach also has important limitations that must be addressed to avoid adverse impact on office operations when Internet access is lost, when the EHR application is updated, if an application service provider (ASP) Web-site breach occurs or if the application needs to be customized to meet office
work flow.

Loss of Internet connection
Internet interruption risk varies geographically. Cable Internet interruptions can sometimes take days for cable companies to repair. Without secondary broadband Internet access, patients are left stranded in the waiting room, and next-day schedules may have to be cancelled and rescheduled. Physicians should make contingency plans to access secondary Internet pathways in order to be able to keep operating. Don't count on modern technology or settle for only one Internet connection because reliability is a problem in both metropolitan areas and most of rural America.

In the SaaS Internet approach, the demise of the EHR application developer and possible disputes with the third-party ASP provider are contingencies to plan for. Special contracting language is required to mitigate the situation when the ASP and EHR developer are two different organizations. If the ASP provider and EHR developer are one, issues still remain. All practices need to get a second opinion from outside law firms with healthcare practices.

Blended SaaS eliminates interruption risk
The blended SaaS deployment approach can circumvent Internet loss. It operates by accessing an Internet Web server (generally through port 80), supplemented by an office-deployed EHR SaaS Web server (generally through local host, on port 8080). If/when Internet access is lost, the office-deployed Web server stands in for the remote Web server that can't be reached. Some SaaS EHRs run the office-based Web server as the primary EHR Web server, using the Internet one primarily for backup. Blended SaaS deployment eliminates Internet interruption risk. The trade off is increased cost (of deploying an office-based SaaS EHR Web server) and loss of simplicity (since managing an office-deployed EHR Web server is now required).

EHR responsiveness trade off
Web-based SaaS approaches are generally less responsive than their office-deployed EHR counterparts. 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 application. 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 users. Worst-case SaaS Web-server response time can be 2 seconds or much slower than the office-deployed counterpart, and it needs to be specified in the licensing agreement (as does what happens if maximum response time is exceeded). That's the speed trade off.

EHR work-flow 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 office-deployed EMR counterparts. This may make it more difficult to enhance ease of use and improve work-flow efficiency.

PMS integration trade off
Achieving Web-based EHR integration with an existing, office-based practice-management system (PMS) can be challenging, but achieving it through a firewall 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 first 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 Office 2003 to 2007 (with its “improved” user interface) will understand. The Microsoft “improvements” were unfamiliar to most existing Office users, and therefore the new system slowed them down and crippled work flow. Many offices skipped the upgrade and continued using Office 2003. They could do that because Office is run on their office computers, not delivered as an Internet service. Had Office been a Web-based SaaS application, all users would have been forced to upgrade and suffer the work-flow disruptions it caused.

In the Web-based EHR SaaS approach, the EHR developer controls when EHR application updates occur, and they are generally mandatory. When forced to choose among Web-based SaaS approaches, try to find an EHR developer that hosts two versions on two servers, one with the latest version and a second with the last legacy version.

Increased deployment failure trade off
Lack of customization to improve work flow and difficulty using EHRs are the two leading causes for the current 30 percent EHR system failure rate (cited by AMA News) within the first 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 office-deployed EHRs offer more customization options, and a few offer fully integrated, user-accessible work-flow 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: www.medsp.com) 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 penalizing hundreds of otherwise viable office-based EHR developers that don't offer the politically correct SaaS approach. Coupled with delays in defining meaningful use, the package has cost some private sector jobs while creating mostly bureaucratic and not-for-profit jobs, many that are costly and probably not sustainable over the next five years. There seems to be a bias against existing private companies providing essentially the same services as newly created, not-for-profit 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 firm. Don't depend on REC-provided, boilerplate licensing agreements to determine if adequate protection 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 developers — whose business depends on selling to physicians — a great disservice by allowing some RECs to emphasize one particular deployment approach to all PPCPs. Physicians 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.

For more information on MSP: www.rsleads.com/009ht-207