I was invited to join in on a discussion that Ben over at tempdev started with the CEO of Practice Fusion, Dr. Robert Rowley. The guest post by Dr. Rowley essentially began to highlight some advantages of the Practice Fusion SAAS model versus the client server model which NextGen (and most other EHR companies) employs.
Much of Dr. Rowley’s guest post and the comments on it were about whether a hosted one database for multiple practice system facilitates sharing of patient information better than a bunch of disparate client server installs. I’ll leave most of that discussion for the comments on the post, but I will mention that the biggest challenges with sharing information between multiple EHR systems isn’t the technology. The 2 biggest problems I see with sharing patient information between doctors are:
- Doctors who aren’t using an EHR and won’t give up their paper charts
- Defining the rules for sharing
Think about what it takes to share information. You have to ensure that the patient has given you permission to share that information, manage how long and which parts of the information can be shared and then go to work to make that happen without sharing more than you should share. Much more could be said about sharing patient records, but my point is that the technology of sharing information isn’t the problem with client server installs. The technology is there, but the policies aren’t.
One final note about sharing using the Practice Fusion model of SAAS EMR is that it still strongly depends on everyone using Practice Fusion. The problem is that there are at least over 400 EHR vendors selling product. This means that ever EHR system will have to learn to talk with each other and can’t just learn to share with itself. At that point, I’d argue that it’s not that much easier for a one database hosted solution to share data with a different EHR software than it is for a client server based EHR to do the same.
Wait, I told you’d I wasn’t going to talk about sharing….so back to some of Dr. Rowley’s other points.
It is true that a client server based system does require a larger up front cost in server and IT support than a hosted solution like Practice Fusion. However, it’s really quite amazing how quickly those costs have dropped. Just today I got a quote for a server for a local doctor’s office that cost under $3k. Prices on servers have become so affordable that it’s not nearly the expense that it was 5-10 years ago.
What wasn’t pointed out by Dr. Rowley is the need to invest in a more reliable and faster internet pipe when using a SAAS EHR. A client server EHR works on your local network which will always be much faster than anything an ISP can provide. Not to mention significantly more reliable. Choosing to go with a hosted EHR can work, but you’ll just have to plan well for when your internet connection goes down.
Hosted EHR companies also love to tout how the software automatically updates as new releases are made. This really can save time compared to in house EHR systems that require you to update an application on each computer (we won’t talk about the in house EHR software that is web based). What they don’t tell you is that you may not want or be ready for the new features. In the client server world, you can test the update and prepare for the changes being made on your schedule. A one database hosted option doesn’t give you that flexibility. If the update breaks something you enjoy, then you’ll have to deal with it until the company can fix it (assuming they think fixing it is a priority).
It’s getting late or I’d keep going about the pros and cons of both the SAAS versus client server models. Don’t get me wrong, I think hosted EHR are certainly a viable option for those implementing an EHR. However, even hosted EHR come with their own list of challenges. Selecting an EHR is more about choosing which challenges you are willing to work around than it is choosing the perfect EHR that does everything exactly the way YOU want it.
I also wanted to talk about Dr. Rowley’s suggestion that “NextGen is an example of one approach, and PracticeFusion is an example of a fundamentally different approach. Rather than seeing them as “a spectrum” of approaches, it might be more appropriate to consider them as different generations of product: EMR 1.0 vs. EMR 2.0”
I think it’s unfair to call NextGen or any other similar EMR as EMR 1.0. Some of the features offered by the client server model blow away PracticeFusion and other web based EHR. The web has come along way (and is continuing to improve), but still can’t compare with some of the UIs client server can offer.
I do agree that they are fundamentally different approaches to solve the same problem. They each have their own benefits and challenges. Pick your poison.
Finally, I was a little surprised that Dr. Rowley didn’t mention the most unique part of his model until the end of his guest post. PracticeFusion’s “free EMR” model that is funded by advertising is what sets it apart from even the various hosted EMR options. This description of PracticeFusion’s business model is its most defining characteristic:
Practice Fusion’s free EMR is an emerging product built on this vision, and has a business model where in-product targeted ads pay for the service. The ads can be traditional vendor ads (pharmaceuticals, devices, billing and transcription services, etc), or can be “counter-detailing” ads, where insurers or local medical groups or IPAs can display their preferred treatment methods for the condition-at-hand.
You can read some of my past thoughts on free EMR by PracticeFusion. I’m still very curious to see how PracticeFusion fairs in the marketplace. One thing is certain, they’ve got a pitch and their selling it to everyone who will listen.
I am glad to see that my blog post resulted in stimulating discussion on the strengths and weaknesses of different EMR data strategies, and in particular about the issue of clinical data sharing. I believe that without good data sharing between clinical practitioners taking care of individual patients, or groups of patients, that the quality of health care will not improve appreciably, and the true potential of EMR/EHRs will fall short.
While it is true that the cost of server hardware is dropping, a local install has overt as well as hidden costs – besides the server, the local network, and the EMR software, there are also other costs such as data backup, anti-virus protection, platform upgrades, access to the records when outside the LAN, etc, which tend to add up. Nevertheless, whether you are an enthusiast of free, hosted, web-based EMRs, or an enthusiast of local client/server installations (or a wait-and-see skeptic), the question of data sharing is one that is important to us all.
Maybe the discussion can be best moved forward by considering a real-life scenario and examining how data sharing can occur in different situations. Let’s say that I am the Family Practitioner taking care of Mr. Chest-Hurts, who just was released from the hospital after a heart attack, and you are the cardiologist who saw him there. Mr. Chest-Hurts is in my office for post-hospital follow up, wants a referral to see you as an outpatient, had numerous tests done (which I don’t have in my records when I see him), states that you changed several of his medications on discharge and is confused as to which ones to take (and did not bring them with him for his visit). I just did some lab test and found his cholesterol to be not-quite-at-target. Let us assume that the referral is a simple administrative matter that happens anyway. What is important for patient care here is for us to share our records with each other – we need to reconcile his meds lists, you need the labs I just got, I need the cath report from the hospitalization, etc. Now let’s explore how we share data, given different scenarios:
1. Neither of us have EMRs; we both use paper charts. In this case (the traditional one in medicine), we copy and fax information to each other from our charts. We take each other’s faxes and make them permanent parts of our own separate charts.
2. I have a client/server EMR and you use paper charts. I generate a fax to you from my EMR, which you place in your paper record. You fax records to me, which I scan and import into my EMR.
3. I have Practice Fusion, and you use paper charts. Several options exist here: (a) I can generate a fax to you, like scenario #2 above; or (b) you sign in to Practice Fusion (after all, it’s free, and with “Live in Five” provisioning, you will be able to have access almost immediately). You can then print out what you might need, for inclusion into your own paper chart.
4. We each have client/server EMRs (maybe the same one, or maybe different). Like with paper, we each have separate chart records, and there is no unified patient identifier. A few options exist here: (a) we each have our systems fax out the desired records to each other, and import the data as scanned documents into our separate charts; (b) we each output a Continuity of Care Record (CCR), and somehow push it to each other. There are some efforts (like Relay Health, for example) who are trying to build an infrastructure to be an intermediary for CCRs – I push out a CCR and post it to Relay Health, and you look there and import the CCR directly into your EMR. This need to build a connection between local installs is a challenge (weakness, in my view) of local client/server systems, and will take effort and money to build. There is a lot of activity here.
5. I have Practice Fusion and you have a local client/server EMR. Several options can take place: (a) we each fax our information to each other; (b) we exchange CCRs (like #4 above); (c) I give you access to Mr. Chest-Hurts’ chart (like #3 above), so that you can see the record, and copy-and-paste between the systems if desired.
6. We each have Practice Fusion. We can share the same record on the same patient, and with the right permissions, can see each other’s notes, shared lab values, meds lists, etc. No uploading or downloading of CCRs required. No faxing needed. This is the most compelling scenario.
Pardon my long-windedness here, but my belief is that the discussion of data sharing is very important, and vital to unlocking the true potential of e-tools in improving health care in this country.
I think the technology and policies exist to control sharing. It is a matter of exposing it in the right manner for both patients and doctors. Have proper control and audit mechanisms.
Can PracticeFusion open an interface to accept CCR? EMRs that can communicate with RelayHealth can then communicate with PracticeFusion directly.
There could be a few more choices, when at least one doctor has SaaS EMR.
Have the EMR export the records in doc/pdf format. Share this with another doctor via a secure portal. The doctor should be able to access this doc without requiring to sign up with the service.
For hosted v/s SaaS. I agree with Dr. Rowley. The hidden costs are huge. In a small practice, who is responsible for maintenance of EMR server? You need someone for it’s TLC. It needs to patched and kept up to date. Almost need a system administrator to do this, which means additional cost.
Regarding forced updates.
Sure, SaaS upgrade might break certain features, but so can in-house server upgrade.
Say, a physician updates his server with a new patch. The patch adds new much-needed functionality, but breaks something else. In most cases, the patch cannot be easily rolled back to original state. So the doctor has to wait for the company to fix the bug. Get the CD and then apply the patch and hope it works.
In SaaS model, when something is broken due to an upgrade, fixing it is relatively easy. Vendor applies the fix and makes sure it works. Doctor does not have to worry about rolling back or applying patches.
Also, there are ways to continue using previous version of SaaS application. Think Hotmail and Yahoo Mail. After a major upgrade, they allowed users to use the old interface.
abhi
Abhi,
I’ll leave the PracticeFusion CCR compatibility question to Dr. Rowley. Hopefully he stops by and answers your question.
I agree that a doctors portal where you can download information is another option. Of course, it has its own challenges in making sure that the doctor has access and then of course, does that mean you have to know the portal of every other doctor you work with?
I’m not necessarily arguing that client server is better or worse than SaaS. I think they both have their pros and cons. I’m fine with either depending on the needs of the practice.
I don’t personally think the hidden costs of updating a one server install of an EMR are that much. Updating a server is as simple as updating a workstation. It does have some costs, but most doctors/practice managers can easily learn these skills and do it without problems.
The difference with in-house upgrades is that you can review the updates before doing them. In a small practice, this might not be reasonable. A large practice though has the resources to be able to test the update before doing it. Plus, they can wait for other guinea pig clinics to do the update and ensure that everything’s working right. This option isn’t usually available with SaaS.
A roll back feature like Hotmail and Yahoo would be cool, but I’ve never seen it in an EMR. Plus, it’s mostly just the user interface and not the other more important problems that can and do occur with updates.
Your point about upgrading and experiencing a problem with your update is a good one. My current EMR vendor does a minor bug fix update in situations like this and is able to roll out the fix as quick as the SaaS model. I’m not sure all EMR vendors would do the same though.
The thing I like most about the SaaS model is that you don’t have to manage client installs. Web browsers are rather ubiquitous and that’s easy to manage.
[…] aren’t without their challenges. They faced head on some of the challenges I described in my previous post. For example, an update to the EHR software affected every clinic using the EHR whether they liked […]
[…] previous posts will provide insight on a number of other topics including this post discussing the SaaS vs Client Server EHR. I should take the info and add it to this EMR and EHR wiki page. Maybe someone else can help with […]