ASP vs. Client-Server EMR. Which is best?

This a fascinating debate and one that will continue into the forseeable future. Is the ASP (Application Service Provider) EMR superior to the traditional client-server EMR systems? An ASP EMR runs over a network (often the Internet) to access information and save information in a remote server. The system is accessed using a browser. Client-server refers to a network structure in which the server is local in the medical clinic or hospital and the data is accessed using a client (another computer connected directly to the server through a local network) and can be either browser-based or can have the full application running on each local client.

The benefits of ASP seem obvious - the ability to access the information from any remote location, ease of maintenance and updating from the vendor perspective (the vendor only has to update the server to benefit all users). In larger settings, hundreds of physicians and other providers, an efficient ASP system would allow multiple users to easily share information through a single central database. Cost is usually lower for the ASP model of delivery. However, security and privacy of information and always available connectivity are critical issues that need to be addressed. The client-server model has the benefit of rapid responsiveness, greater security (although this point could be argued) and the ability to store the data locally. In other words, the risk of not being able to access the network due to problems with the Internet or other wide are networks are less likely.

The majority of current EMR installations are Client-Server, however ASP is becoming more prevalent. An excellent discussion on this issue can be found on the EMRupdate bulletin board. See Electronic Medical Records - Is ASP the future of EMR's?

From this discussion, I have copied the following quote by one of the participants - "The major challenge of any EMR regardless of where its housed and however it is accessed, is the presentation of complex data with stat access consisting of timely quality and quantity of medical information. "

If you have implemented an ASP EMR or have strong feelings about which will be the dominant system in the future and why, please share your thoughts by clicking on the 'Comments' link below.

Comments

[Scot Mountain]

Having used an ASP emr, billing, and scheduling system for the last 10 months, in spite of the headaches we have had with implementation, I feel confident that ASP is the way of the future, and that Client-Server type models will one day be a thing of the past.

To a large degree, this is because ASP will resolve many of the issues that Alan has raised on this website. For example, practicing in electronic islands; client-server is just an electronic form of the information islands that traditional offices have with their paper charts. Or how about Alan's recent post regarding the development of a single, sharable infrastructure for the Richmond area physicians. With ASP, the infrastructure is already in place - information sharing can begin as soon as someone adopts the software. This information sharing capability has already been recognized in the adoption of Alberta's EMR and B.C.'s Pharmanet - both internet based.

In addition, ASP reduces cost, office infrastructure, the need for office-based IT expertise, and the headaches of backups and updates to software.

All this is not to say that ASP doesn't have its headaches. To begin with, speed has been a significant issue for us in our clinic; we finally seem to have solved it by buying an industrial speed internet connection many times faster than a standard broadband connection. However, we are still dependant on our ISP for uptime (we still maintain a cable connection as a backup). This upgraded internet speed is not cheap, and has been difficult to get up and running. Hopefully, with the rollout of faster, more stable internet connections, this kind of problem will be a thing of the past - I think it is safe to say that, if nothing else, the internet and computers will continue to get faster.

The other big knock against ASP is security. However, I think that if you are going to compare security of one system to another, you have to identify the real threats to your data. To me, these include direct theft, physical destruction (fire, flood) and malicious hacking. With respect to the first two, ASP stored data is infinitely safer than either paper records or office based client-server models. If there is a fire in my office tonight, or someone breaks in and steals all my computers, all my patient records will still be accessible tomorrow, and the thief would have no access to anything from any of our computers.

With respect to hacking, there is an acknowledged risk that a hacker with the time and expertise could potentially breach the system. However, our data is secured at the same level as major financial institutions use to secure their internet transactions, with an extra level on top of that in the form of secure access via certificat only. To me, that is at least as secure as the data sitting around my office in paper charts.

Whether it is the current ASP systems that end up dominating the market, or some new upstart yet to come, my belief is that eventually, we will all be using ASP for most of our software, not just our EMR.

I am fully aware that ASP is a controversial choice, and that a lot of people are not yet ready to even consider making the leap. I'd be interested to hear other comments.

[Jel Coward]

Speed is the thing that counts it out for me. I have an adsl connection at home and cable in the office. I can access our EMR over these connections and it is very usable - but not full-on office speed usable, it would drive me nuts . I do some outreach work to distant reserves and I hope to use the internet to connect to the office charts then.

Other big issue for me is data housing. Personally, I like it in house - patients trust _me_ with their charts be they paper or electronic - I an not sure that I can sub-contract that trust.

[Allan Horii]

As much as I wish that cost would not be the main determining factor in choosing an EMR system, I have to say that it is a major factor in choosing between an ASP and a client-server EMR. I am currently looking at implementing EMR in my solo practice and the hardware costs for the client-server system seem to be prohibitive. In a multi-doctor clinic, where the costs of the server/network/backup system can be shared, client-server EMR seems to be reasonably affordable. However, $20,000 (a recent quote I received) for a lone physician is too bitter to swallow. My only choice seems to be an ASP-based EMR system.

[Alan Brookstone for John L. Males]

The following comments were sent to me by John L. Males - a software Quality Assurance expert in Ontario. He provides some very insightful thoughts about EMR and the strategic position that should be taken in developing EMR systems.

I have just learned about CanadianEMR via a Linux site.

I have read the postings, mostly by you it seems on the various issues and considerations with respect to EMR. They are all very good points and elements to be considered.

I am not a doctor, not a medical person. I am a very very experienced IT person who's speciality is Software QA, both at application level and embedded (BIOS, hardware/firmware software). A large part of what I also do as a QA Professional is scope from users the requirements, review and validate requirements are consistant for user, validate requirements will result in what the user is "really" expecting,
infrastructure (almost always between very different systems that have to communicate/exchange) , different software "parts" oftentimes from very different systems or Operating Systems communicate/exchange, and a full User and Technical evaluation that involves a number of processes.

It seems to me what needs to be done initially is to research what is the target of data to be transformed to EMR. You need to do this first and then establish the data structure/flow and functional elements of the EMR data. The data is the primary base and needs to be conceived like a human, whose anatomy does not change drastically over several thousands years. EMR should avoid a "vendor lock in" of data.

IT likes to keep changing things too frequently. There are many examples of this that most none IT people have had a few experiences with to date. This is driven out of two basic root motivations. The first, is to force a change for the sake of change in order to generate revenue. The second and just as disruptive, is frequent data/flow/functional changes to the non-standard EMR or not thought out EMR that the data/flow/functional elements are in a state of too much flux. Once a well conducted analysis is done, then a data/flow/functionality that can evolve and adapt without major redesign of the standard and the vendor's that have writter code to support the EMR standard. This standard really needs a global audience, and steering. You need to avoid patents that require licencing on the data/flow/functionality or else this will quickly distill into a vendor run model that may not serve the needs of the Medical Professionals EMR needs to be used by.

I would highly recommend that the EMR data, flow, interfaces, functionality, security, etc be well established and made a draft standard. Once that is accomplished then the excellent issues you have raised, e.g. sending paper based copies of MR to Medical Professional that does not use EMR and receive their information back into EMR, can be addressed with solutions that can greatly ease the obvious issue. This issue would also hold true even for an EMR Professional who is in field and cannot access the EMR due to
location, et al.

This is all very necessary work that takes much time to do up front. I know as been in such stuations all too many times over the years in IT. The payback is a standard that provides long term use and stability of the data, migates greatly data conversion issues short term and long term. The short term data conversion issues would be mostly vendor centric. The long term data conversion issues frequency and extent would be due to poor or no formal standards, and would be very costly and provide upward compatiability issues of the data that could be most problematic down road.

I am a Linux user, and have been for a few years now. My one and only home experience with Windows was with Windows NT, and suffice to say in two years it was a complete disaster. I had used OS/2 since the
late 1980's, but IBM started to mess that gem up, not technically, but from a strategy perspective. I tried Linux in mid 1990's but it was not ready for the hardware, standard, for me to use yet. By the late 1990's Linux was useable and I used it alot instead of Windows NT. I switched over to an existing Linux I had when yet again NT self dustructed it's file system.

I am saying this not just to bash Windows or Microsoft, but I have found things have a much longer live cycle, be it hardware or software, when it is an open standard rather than a closed one vendor owns model. I think EMR should be a public and open standard. As many vendors can write software to the EMR "standard" for data/flow/functionality and still have lots of room to add vaule while still having an Open standard. That would also allow Open source developers to also develop software solutions about the EMR tandard. In fact I believe there is already one EMR like Open Source Project that has existed for over a year. Perhaps it can be part of the EMR research/analysis data/flow/functionality phase.

Regards,

John L. Males
Willowdale, Ontario, Canada
28 July 2004 00:45
mailto:johnlmales@yahoo.com

Contact me by:

Replacing before the "@" as follows:

* reduce my first name to the first letter
(which proceeds my middle initial and surname).

Replacing after the "@" as follows:

* Domain name = The first four letters of the word "software", followed by the first four letters of the word "homeless".

* The character for DOT.

* TLD = The last three letters of the word "internet".

My appologies in advance for the jumbled eMail address but SPAM has become a very serious problem. The eMail address in my header information is not a valid eMail address for me. I needed to use a valid domain due to ISP SMTP screen rules.