It is an interesting situation. Free software will rely on support revenue, whereas other competitors -- other than traditional proprietary software -- could rely on a third party for ads.

I should note that Jonathan has also been discussing this issue over at emrupdate.com. So far he has been very responsive to my questions, which I appreciate. The main discussion on this seems to be happening there, so if you actually want to participate and watch other participants then go there.

I did miss the other article that Jonathan is mentioning. (There are two links because it was published twice). This article means that at least one reporter got the story right. So why did the other journalist get it so wrong? The question is to what degree, if any Practice Fusion misrepresented itself to these journalists. If this reply is any indicator, then it will be difficult to tell. If it turns out that this problem was the fault of an over-eager journalist, then I will post a full or partial retraction (depending on circumstances)

Practice Fusion does not have a standard Adsense relationship with Google where code is simply inserted in our site, as you pointed out in your commentary. We worked closely with Google Adsense team to develop a custom API to send keywords to Adsense and return relative content.

Actually what Jonathan means is that Practice Fusion is using the Adsense API rather than the standard html+javascript code. Of course anyone can do this, so by itself this is not unique. Practice Fusion has an "API to the API" which might help them internally, but can only exercise the capabilities already in the adsense API. Since they used flash instead of html I think they had to do it this way (i could be wrong).

Of course the second part of this statement is even more troubling. It could imply that Google actually assisted them in development, or it could mean that Google was providing standard forum based API support. When Practice Fusion says things like "worked closely with Google" they are implying a relationship with Google that simply is not there. This kind of thing is why I probably will not be doing a full retraction. Even I have to carefully think about what these statements mean in order to separate truth from marketing buzz... which is a bloody good definition of snake oil to me.

Lets continue...

How we are different: 1) We are free,

Lots of EHRs are costless, he definately does not mean free the way this website uses it...

2) We utilize an SOA,

Lots of EHRs use SOA

3) We are on-demand using a (flash-based RIA) rich internet application

Lots of EHRs are rich internet applications, and while I cant think of any other flash application I can think of no real benifits to this approach over an HTML interface besides animation improvements. Animations are not exactly core EHR technology.

4) We are interoperable (with absolutely no setup and integration

This is a totally bogus claim. You are interoperable with X, not just "interoperable". For instance you might say Open Office is interoperable with Word Documents. But you don't just say, "Open Office is interoperable". It is virtually guaranteed that there is some obscure file format that Open office cannot handle. I assume what Jonathan probably means is that they can import and export using standard formats, which is a good thing but hardly scratches the surface of the problem of "interoperability" as a whole.

5) We offer one-view into our entire community for IPAs, MCOs, RHIOs and other community administrators.

One view, many views... neither one is particularly unique for software in that category.

As you will see this is not thrown together open-source solution with some ads tossed in.

Yea... that never works. Here is a link to a company that that strategy is definitely not working for

This is a highly available (Practice Fusion's application is hosted at a world class data center featuring data redundancy in multiple locations, power backups, biometric security, armed guards, alarms and more), highly secure (our facility is protected by biometric security, closed caption video, armed guards, uninterruptable power supplies and fire extinguishing systems.

Please take a look a the facilities of the hosting service that I recommended. The really cool stuff that Jonathan mentions is what people in the hosting industry like to call "standard". I note that Jonathan did not mention that the "world class data center" was actually owned by Practice Fusion which means that they are likely to be using a competitor of ServerBeach.

In addition, all data transfers between physicians and Practice Fusion's system are encrypted and protected from malicious parties

This can be very difficult to do. Unless you decide to use https, and then it is trivial.

solution built upon a service-oriented architecture with a rich Internet application user interface.

The system provides value to the customer by leveraging existing infrastructure to change the paradigm for doctors offices. As evidenced by the previous sentence the system is also fully buzzword compliant.

Everything Jonathan is touting as unique is standard and software available under the GPL can do all of this and much much more. What Practice Fusion is doing is interesting because they are trying to fund it with ads. That's what the journalist who got it right said, and that's all there is to it. While the funding model is interesting Practice Fusion continues to imply some kind of special Google relationship which is not there.

I imagine that Practice Fusion will continue to list why they are a solid company with great technology. After all, would the CEO of a company that just invested large sums of money in development that was duplicating freely available code want to admit that you can do the same thing without that investment? Of course that is not really the issue for me. I do not care if they are a good EHR or a bad EHR, I just care that the whole blogosphere thinks Google has an EHR when they do not.

Assuming that Jonathan continues to fully respond to questions on emrupdate, this will probably end with me saying I was too harsh, but that Practice Fusion was and is still wrong to tout any special relationship with Google. Then I will turn my attention to the hundreds of blog posts that assume that Practice Fusion IS Google, which may actually be the real culprits here. There is no defense for bad blogging. So far, in Practice Fusions defense, Jonathan has been quite willing to actually respond to blog posts, which I think is a good sign. Perhaps soon he will relax the tone, and begin replying in the same light-hearted fashion that I favor.

Trotter

I normally am a spectator in these forums and have never commented but thought this thread was of particular interest and given the turn it has taken I feel I have to comment. I actually just got through getting a quote for a new PM/EMR system that was opensource and 'free'.

Fred - What I think is interesting is your hostility in both of your postings. Its interesting to see you trash-talk their model, particularly when you have an inherent conflict of interest. The reality is that you are a vendor. In fact according to you recent interview found here "$30,000 in Customizations Minimum"
You clarify that you charge to implement, customize and support your open source software – to quote you “I do a lot of software customization for MirrorMed, and when I sell it, I usually charge around $30,000 as a minimum.”

It's obvious you feel threatened by their model and you should. Your actions honestly show a true lack of professionalism. The fact that you would under the guise of being a consumer advocate, publicly bash a competitors solution not once, but continually, even after your base issues were addressed, in my opinion shows a dangerous lack of either good judgment or personal integrity both of which I consider essential in a potential vendor.

Please don't bother saying that FOSS or any of your other opensource software is free - because its not. Anyone using opensource is forced to pay endless consulting fees and on-going maintenance to get a product that is actually usable in a clinical group environment. The truth is you are the only snake-oil salesman here. You bait your prospects with free and then switch them with never ending customizations and support fees.

Also, I have looked at your site and if this is best you can show you should do less posting and more coding. Here is a link Mirrormed

I personally think Jonathan has represented his company well (I also noticed that you didn't have anything to say after his last comments). Will it work? Only time will tell, but I think they may be on to something. You, on the other hand, should be a man and retract your comments. They make you look bad and that will only hurt your business. If you want to bash me feel free but keep in mind you started this negative thread.
Dr. Kon Bökamp

Fred,

I have had some limited dealings with Practice Fusion, and the experience has been troubling, to put it kindly.

First, the program is not "free." Once you get past the marketing hype and actually try to sign up for the program, you are informed that there is a mandatory $50 per month per provider "support" fee. This is a little disingenuous as all of their marketing hype expounds on how easy the program is to use and how it is virtually maintenance free.

Second, I've been following these guys since the first of the year when they hit the edges of the EMR radar. Initially when I contacted them they told me that they were concentrating on large groups and RHIO's, and that they would notify me when they would start moving the program down to smaller practices. However, when I talked to them a few days ago, the story was just the opposite - they told me that they weren't ready for large groups and that they were concentrating on practices of fewer than 20 providers. I have the emails going back to the first of the year to substantiate this. In fact, I know of no group that has bought into their program, and they have not been able to provide me with any reference sites to contact.

Third, their program is an ASP version of an older program called Medical Chart Wizard - not exactly a program that set the EMR market on fire prior to being "acquired" by Practice Fusion - and despite hyping their service for the better part of a year, they didn't even acquire Medical Chart Wizard until July of this year. They have been hyping their "Free EMR" since March (maybe even before that). This was basically "vaporware" that they hyped most of this year. Actually they have given me several differing versions of what they are doing. At one time they told me it was not a true ASP program, but a “hybrid” program with a version that the physician could purchase that did not collect data or present ads.

I tried to get a number of question answered on behalf of a group of physicians I consult with, including:

1: Training – How do you intend to facilitate new-user training? Most PM/EMR’s require new enrollees to take 3-5 days of training (usually on-site with one of their trainers, but some are via webinars).

2: How will training be scheduled, and how will it be charged. Is it included with the support subscription, or priced separately?

3. What type of internet connection does the client need? Should the client provision T1? Can they use broadband? Will your program support a dual wan configuration, where the client has 2 ISPs for failover? For instance, cable and a failover DSL line (a common configuration for ASP installations is Roadrunner business-class cable on a dual WAN firewall/router with either Verizon or ATT DSL for failover). I can tell you that the hospital is going to require affiliated physicians on ASP or hybrid programs to either have T1 or broadband with failover.

4. Client setup and installation – Can clients add or remove workstations from the program on their own or through their IT provider? How is the client software installed on the client’s workstations? What are the minimum and recommended workstation hardware requirements?

5. If the program doesn’t work out, or your company goes under (that happens, unfortunately. I know several practices that had purchased AcerMed and are now out substantial investments), what is the procedure for exporting the data from your program and what formats can the data be exported to? Can the clients export their own data, or have their IT service export the data for them? I know that after the AcerMed fiasco a few months back that this is going to be a very important question.

6. What are the procedures for importing data? Can the client or the client’s IT service import data for themselves? If not, is there a standard format that the client can submit data for import (like CSV or comma separated values). Most of the 1,100 physicians that I work with through the hospital already have demographic data in the current PM. A few have emr data as well. Most of the programs that are currently being used are SQL based. It is relatively straightforward to run a SQL script to export the existing data into a CSV file in the field order
corresponding to the new program – for demographic data anyway. Appointment data and emr data is sometimes more difficult, depending on the program.

7. Can you give me more information on implementing your program within an RHIO? Can the RHIO train their existing IT staff to handle Tier-1 and possibly Tier-2 support requests from RHIO members? Can you give me a little more specific information on the Physician Relationship Management Service Dashboard and the Point-of-Integration Service?

8. Have you received CCHIT Certification for your program?

They would not respond to the questions. Nor would they allow me an opportunity to use the program hands-on to judge the efficiency of their hosting, and whether dictation and document scanning were feasible (even some of the best ASP solutions have difficulties providing enough bandwidth where practices scan a lot of documents or do a lot of dictation with Dragon).

Originally they represented to me back in March that the ads were controlled by them and were subscribed to by pharma, medical suppliers and providers. Now the model is Google AdSense. No way am I going to recommend something like that to a physician. I don't see how that they can make this model compliant with the HIPAA Security Rules (45CFR 164) for the Physician without fully disclosing and documenting for the physician exactly how PHI is segregated and protected, and exactly what information is being aggregated and sold.

They also told me that they had something like a thousand doctors already on board. But they could not provide me any reference sites, and I suspect that this user base is actually the old Medical Chart Wizard users.

Mostly, these guys are full of it – and full of themselves.

I was initially very receptive of their idea, but after some due diligence I unfortunately have to recommend avoiding Practice Fusion like a plague.

I've helped clients use Adsense to help defray the costs of their web presence. So in adition to my other concerns, I don't see the numbers really adding up if Practice fusion expects to profit by using Adsense imbedded in their SaaS EMR. This model relies on the users clicking on those ads and visiting the websites. But really, what doctor has the time for that distraction? And what medical office is going to put up with staff spending time cruising around the web? Patient visits and productivity are what make and break a practice. Most doctors I work with (and this can be verified by visting the user boards for most EMR's) want to input data in the least amount of time with the fewest distractions. There are whole threads on the internet by doctors devoted to reducing clicks per visit in their EMR's. Given that, how many practitioners are realy going to spend time clicking on those adds to generate revenue for PF? And btw, it is a violation of the Adsense usage agreement to actively encourage vistors (or users) to click on ads. Those advertisors have to pay for those clicks. Encouraging clicks soley to generate revenue for another party is fraud. Google's policy is to suspend an Adsense subscriber that actively encourages clicks, or that click on their own or other ads excessively. Its going to take a lot of clicks for each provider to generate enough revenue for PF to offset the bandwidth and hosting requirements from even a moderately busy provider. It doesn't add up.

General security and work rules in a medical practice also work against this model. Most facilities and practices I work with have strict restrictions on users accessing the web, and many require me to block access to all but the websites that are approved by group policies (GPO's). Any competant IT consultant strongly encourages restrictive GPO's - because most viruses and spyware come into the systems via the internet and browsers. In fact, most spyware is transmitted via web browsing. That is why to really be HIPAA Security compliant Web browsing should be locked down to known safe sites and strictly monitored. Once you have a spyware infection, all of your patient data can be potentially compromised. This is how the recent TD Amertrade "secure" data was stolen - by spyware introduced into their system.

Productivity also works against this model. Most providers already complain about the time lost having to log into computers in compliance with the HIPAA security rules. Thirty seconds to a busy provider is agonizingly long. In most facilites and practices, there are documented sanctions for employees caught "surfing" the web. Productivity makes a practice profitable. What practice is going to encourage, or even allow, staff to spend time clicking on ads and actually exploring the ads website? Most employees get two 10-minute breaks (besides lunch) during a workday. Just reviewing one or two ads can easily eat up that much time. Web surfing is the single biggest productivity drag in organizations that don't strictly control it. That has been documented in several studies.

Practice Fusion's business model relying on Google Adsense to generate the bulk of its revenues just does not ad up. It runs counter to Best Practices, both in terms of productivity and security, in a medical practice.