Try our Search!



Application Service Providers in Healthcare
By
Jeff Pasternack
4/4/00
Just as we've witnessed the next generations of bell-bottom jeans and the VW Beetle, so has the Internet given new life to the concept of mainframe computing. The way mainframe computing used to work is that there were dumb terminals connected to a computer that housed the software. All you had to buy was a server plus monitors and keyboards for your staff, all of which cost less than individual PCs. The new version of mainframe computing calls for you to access the software over the Internet from an Application Service Provider (ASP).

In the near future you can expect to access practice management software under the ASP model. Whereas today you have an office full of networked computers consisting of PCs, database and print servers along with costly service contracts, backup systems and headaches associated with upgrades and server failures, tomorrow all that will be required is Internet access and a web browser. Under the ASP model, your expenses are vastly reduced; merely the cost of a PC, Internet access and the subscription fee for using the software.

An issue that plagues the ASP model is the perception of a loss of control. The patient datum resides on computers outside your office and thus there is the appearance of a lack of control. While in the strictest sense this is true, one must ask oneself what the value of that control is. ASPs put language in their contracts stipulating that the client owns the data and can cancel the contract and move the data elsewhere. This is the same when you become dissatisfied with your software under the old model: you decide to change software and have to export it to another system. Whether the data is hosted on your own servers or on the Internet, the same headaches that accompany data conversions still exist.

What about security? Not too long ago the press was awash with news of break-ins and denial of service attacks. Are there any assurances that patient records won't be compromised? If you ask any ASP executive, the immediate response is an emphatic "YES!" followed by a litany of security jargon in which the only word one might reasonably recognize is "encryption." Encrypted datum requires a decoder and without it, the datum is useless.

While ASPs and their clients have a keen interest in ensuring privacy, the AMA and Intel are also taking an active role. Both are currently testing a "digital credential," which is a very lengthy combination to a lock. "1024-bit keys used for digital certificates are sufficiently long to be resistant to any kind of analytic attack, but this does not protect the systems themselves. Systems still need to be protected with firewalls and other security measures," says Dr. Aviel Rubin, an Internet security expert with AT&T.

So is information stored on an ASP's system any more secure than those stored in a hospital? Yes and no. Yes because few individuals, or even companies, have the computers and the technical expertise to devote into hacking records protected by 128-bit encryption, which is the current industry standard, much less than 512-bit encryption. No, because if someone is determined to access a patient's record, whether its in a hospital where all one needs is a lab coat, clip board and an easily faked badge, or by hacking a computer system, the truly determined person will obtain the record.

ASPs have a vested interest in making sure that your data is secure. While the security and privacy of patient information should be heavily weighted in your decision to go with an ASP, don't make it the sole factor. ASPs are constantly upgrading their technology so you don't have to. And that's the real value proposition offered by the ASP model: reduction and elimination of costs and headaches associated with running your own system.

Jeff Pasternack is the president of Dynamic Consulting Group, a franchise partner of 1-800-GOT-JUNK? and author of the TechnoPeasant Review.
If you have questions or comments about this column, please write to him at Jeff@TheDCG.com.