As you consider how to finance an EHR, you may wonder whether you should have your software and data hosted on a remote computer server. That approach requires a smaller upfront investment than an in-house client/server network does. However, physicians who have used these application service provider (ASP) EHRs are divided over whether they deliver patient data fast and reliably enough to support top-notch care in a high-volume practice environment.

One physician reported that, even with a fast DSL connection to the Internet, “the waiting times after every click” in his ASP-model EHR “felt like torture.” So he switched to an in-office client/server system, which gave him much better performance. Another doctor was using a CCHIT-certified EHR that accessed the server over the Web. He had a fast, business-grade cable connection; yet, he wrote on a bulletin board for EHR users, “The application is very slow and at times is not even workable. I am always late on my appointments because of the slow speed of the system.”

Other physicians are very happy with the performance of their ASP-model EHRs. S. Hughes Melton, a family physician in Lebanon, Va., says that his e-MDs EHR loads Web pages in less than two seconds, except during periods when the vendor does upgrades. His practice has a fiber-optic connection, but its download speed is no faster than the cable link of the doctor with the “unworkable” EHR. Family practitioner Peter Forman, a soloist in Delmar, N.Y., uses a Verizon FiOS link, and the pages in his remotely-hosted Allscripts MyWay application load in less than a second.

Internet connections are getting much quicker and will soon be a non-issue for ASP-model EHRs, except in some rural areas where broadband is not yet available. However, several factors besides download speed can affect performance. Chief among them is the nature of the application you’re using. As we’ll see later, it’s important to know whether or not your EHR software was designed for the Web.

The other thing to bear in mind is that EHRs are still a work in progress, whether they reside on your own server or a remote machine. “The density of documentation and information that a physician has to navigate is the real barrier, rather than response time,” notes internist William Bria, president of the Association of Medical Directors of Information Systems (AMDIS).

Optimize your bandwidth

That said, your Internet connection is still critically important to your ability to access patient information. While Bria believes that most physicians are willing to tolerate download times of two seconds per screen, other experts note that doctors expect pages to be available as soon as they click on them. Depending on your connection and software, an ASP-model EHR may load a page in anywhere from one to four seconds.

So what kind of connection should you have if you want to improve performance? Dialup is way too slow, and you should also ignore residential versions of DSL and cable. But business-class DSL and cable connections, which come in multiple bandwidths, can be fast enough for an ASP-model EHR, several experts say.

Several factors affect speed. If you have DSL, for example, performance varies inversely with your distance from the local phone company hub. A DSL connection is effective up to about 10 miles from the central office.

The performance of cable modems is not affected by distance. But the available bandwidth drops as more computers, medical devices, and scanners use the connection, either within your practice or in the neighborhood. The same is true of DSL. So the advertised speeds of cable and DSL may be considerably higher than the actual data transfer rate.

Think of the bandwidth of shared connections like highway traffic. If it’s a two-lane highway, a certain amount of traffic will clog it up, and data will move slowly. A four-lane highway can accommodate more traffic before it slows down. But in either case, the speed of your connection is not under your control.

That’s the No. 1 reason why many practices get a T-1 line, both to access the Web and to connect their satellite offices. “On a dedicated pipe, there’s no one in that last mile but you,” notes Sheri Rose, a telecommunications expert and a partner in the Louisville, Ky., consulting firm Commonwealth Leverage. “If you’ve got a T-1, you’re guaranteed 1.5 megabits per second.”

Have a backup

Practices should have a backup system in case the Internet connection goes down, experts say. Consultant Michael Uretz, executive director of the Seattle-based EHR Group, recommends that practices get both DSL and cable connections, in case one is interrupted. If you have multiple links, you can add on a service like Ecessa, which provides “load balancing” to ensure that if one connection is overburdened, the load is shared with the other line.

Rose of Commonwealth Leverage points out that T-1 vendors are much more likely than cable or DSL vendors to provide you with “service-level agreements.” These contracts provide penalties if your uptime is not close to 100 percent, and they also promise very rapid repairs if there is a problem.

If you plan to have a wireless system in your office, make sure it’s business class. If your wireless connection is poor, says Bria, “you’ll have a nice fat pipe coming into your office, and you’ll never realize the benefit of it.” A top-of-the-line wireless setup, including the latest wireless cards for your laptops, a couple of transmitters, and a first-class router, will cost a small practice under $2,000.

Finally, the most efficient way to connect with an ASP server from multiple offices is to go through a router in one of the offices, says Uretz. If the network is set up properly, performance should not be affected.

While some physicians have reported problems using commercial cable links between offices, most practices don’t need T-1 lines to join their offices unless they’re connecting to a picture archiving and communication system or receiving radiology images. Mark Anderson, a consultant in Montgomery, Texas, and president of the AC Group, notes you don’t need a T-1 to scan old charts into an ASP-model EHR if you store the data on an office PC and upload it in batches overnight.

 

 

Where the rubber hits the road

Until the late ‘90s, EHRs were designed for client/server networks, in which an onsite server stored data and sent it to user PCs that contained copies of the EHR program. As EHRs moved to the Web, most vendors simply combined their client/server EHRs with special software (provided by Citrix or Microsoft) that enabled them to emulate Web applications.

Even today, says Anderson, few ASP-model EHRs are “Web-native” — that is, written specifically for delivery over the Internet. Such EHRs have significantly better performance than client/server applications do when they’re hosted online.

One defining characteristic of Web-native EHRs is that fairly little of the program resides on local computers. However, most EHRs place some program components on practice computers to speed up processing of data requests, says Jeff Amrein, one of Rose’s co-partners at Commonwealth Leverage. “To get something to run over the Web efficiently, you need to design it in such a way that you do as much local processing as you can,” he says, noting that it takes much less time to run a report locally than over the Web.

What takes the most time, however, is downloading data. Vendors of advanced ASP-model EHRs accelerate this process by using two approaches. First, they’ve reduced the number of screens that physicians have to call up to document a patient visit. That can make a big difference if your system now takes two seconds to call up each of 40 screens during a typical visit, notes Anderson. And second, some ASPs download much of the data that physicians will need before they need it. Both of these methods are aspects of what IT mavens call Web 2.0, which is widely used by leading Web companies such as Amazon and Yahoo.

Ed Park, chief technology officer for Athenahealth, which offers an ASP-model EHR and practice management software, explains that the performance of Web-based services “has less to do with the connectivity than with the way the Web application is architected. With Web 2.0 technology, you can create a very snappy user interface that can handle the most demanding applications.”

Basically, the Web 2.0 ASP does this by downloading “a lot of the content and logic necessary to run your application,” he says. “Then you have a core library of logic that allows you to run your application in real time. The only time you go back to the server is when you need more information.”

What this means is that the user doesn’t have to keep downloading the same elements to “paint” new pages. And, while the provider is documenting the encounter, the program is preparing for the next step. So, for example, when a drug is prescribed electronically, all of the possible interactions automatically pop up on the screen without the doctor having to click on anything or navigate away from the page that contains the other data he needs. Obviously, this improves performance.

The next step for EHRs

Download speed is becoming less of an issue for ASP-model EHRs, and performance is continuing to improve as developers of Web-native EHRs use techniques to reduce the number of screens physicians must move between. According to Anderson and Uretz, EHRs that use only a handful of pages per visit are just over the horizon.

But veteran EHR users say that these programs still have a long way to go. “The intelligent display of contextual information is the goal — but we’re not there yet,” says Bria.

In the meantime, physicians can adopt Web-based EHRs with some degree of confidence. Just make sure, advises Bria, that your EHR vendor and your IT service company demonstrate that the system works as advertised before you plunk down your money.

Ken Terry is a New Jersey-based freelance writer and the author of the book “Rx for Health Care Reform.” He can be reached via physicianspractice@cmpmedica.com.