I think you might be arguing for data access rights, saying that any application where the data cannot be exported at any time and for no cost by the user is evil.

There is not any new threat here that hasn't been around since before EMR was a buzzword.

For starters, all-browser-based is not the full picture. An application does not have to be browser-based for the data to be inaccessible to the practitioner. I can come up with the following scenarios, all of which are "hosted" applications for the practitioner where obtaining the data might be controlled or carry a cost.

1) Hosted desktop applications accessed over Terminal Services or Citrix where the application and data reside on hardware that is in a separate location than the practitioner. The practitioner may or may not "own" or have control of that hardware. The full environment may be hosted for them by a vendor.

2) Hosted desktop applications that run on local workstations, but where the data is stored off-site on separate hardware. Again, control and ownership of the hardware where the data is stored would have some ramifications on whether the data could be exported freely or not. Whoever "owns" the hardware might actually want paid if exporting the data requires some effort, or they might provide tools to export data on your own.

3) Hosted on the Internet or a private network by a vendor, and accessible with a browser only. This is the scenario you mention, but data access ability is really no different than scenario 2. The only difference is that the application renders with HTML in a browser instead of drawing itself using desktop software techniques.

4) Hosted on a server in the practitioner's office and accessible with a browser only. That server might be fully serviced by the vendor, FOSS or not. The practitioner may have no more access to the data than they did in the above scenarios. Even if they have access (= freedom) they may know nothing about how to "export" that data and may even trigger clauses in their service agreement for touching it.

Your last sentence gives examples of FOSS products, OpenEMR, and ClearHealth/MirrorMed. However, the business model of those vendors is one based on service and support. Free source code or not, I bet they get "paid" if the practitioner wants time spent to copy all their data copied off the servers that are being cared for under contract.

And, let's not forget the advantages of having the data reside on servers that are outside of the control of the practitioner. The data is immune to viruses and "evil" staff or outside tech support personnel that could otherwise affect that data if it were in an office. That's a huge benefit with insurance companies wanting "HIPAA privacy" insurance now on top of all the other insurance that practitioners already have.

As long as a "hosted" offering provides tools to export the data and contractual verbage that the customer always "owns" the data, then the data is safe and secure and accessible. Whether it is freely accessible in terms of cost or not is another matter entirely, and most likely to be dependent on the effort required to copy that data.

• Re: Browser Based EMR's Threaten Software Freedom by Fred Trotter on Sunday January 14, 2007 @ 08:51 PM

  Your response is lucid, but misses the point. you said... "There is not any new threat here that hasn't been around since before EMR was a buzzword." Sure there is! A threat is not merely a particular technology, but the popularity of it. Browsers do not have to installed in computer, making the solution that Ignacio is detailing trivial to deploy and use. Trivial means cheap and cheap means pervasive, pervasive means a new threat. The other problem is with your assumptions. any application where the data cannot be exported at any time and for no cost by the user is evil. Ignacio is smarter than this. He is not at all arguing this. He knows that most proprietary programs do not have any export functionality or if they do they are in a non-standard format. (that's easy since for the most part, there are no solid standards for health data. Note to readers: do not bother to contradict me with examples of a "standard" that is clearly not "solid"...) What separates hosted solutions from local solutions is that with a local solution you have the right to reverse engineer the data storage format or even the data export format. Ignacio is talking about this "right to reverse engineer" and "access to the data" in the same breath because you have to. Trusting an "export function" does not really help you. (especially since that may be what you are reverse engineering). All of this is wrapped up in his phrase "privately extract data". You said "And, let's not forget the advantages of having the data reside on servers that are outside of the control of the practitioner." Totally irrelevant advantages. If the practitioner does offsite backups, there is no risk of data loss. Data thieves will simply steal in some other way, (i.e. print screen button). Viruses can impact anyone, including the datacenter that "hosts" your medical application for "protection". If even if you counted these as advantages, they are irrelevant if the practitioner has lost control of the data. You said "As long as a "hosted" offering provides tools to export the data and contractual verbage that the customer always "owns" the data, then the data is safe and secure and accessible." No. In order to truly own the data, the practitioner must have full access not only to the data, but to the source code under a FOSS license (preferably the GPL) for the application that is used to manipulate that data. Again, an "export" is useless unless I can continue to run the practice on the same system using that data, which is impossible without the sourcecode. A MirrorMed or ClearHealth (which are GPL) based ASP with full data export is moral, while a proprietary ASP is not. Also, data access "in the contract" does not always actually translate to data access. What happens when the company that you have the contract with files bankruptcy? Much better is "data exports backups in practice", where you and the vendor agree that you will download a backup every night to your server! Ignacio is making an argument and that argument is correct, the fact that he did not give a "full picture" is as irrelevant as it is impossible, I think he made his point. Trotter

  [ Reply to this ]

• Re: Browser Based EMR's Threaten Software Freedom by lksjt on Monday January 15, 2007 @ 05:44 PM

  1) You missed my point and jumped right into FOSS vs. proprietary evangelism. I said nothing of proprietary software. The scenarios I listed could all be operated using open source software. Whether an export feature exists or not is application-dependent, not simply FOSS vs. proprietary, and is arguably irrelevant anyway based on your points. 2) Your view of a data center offering no security over the alternatives is not supported by real world events and systems. You'll have to do better than just saying it is an irrelevant advantage. 3) Arguing the morality of these points is as irrelevant as it is impossible. But then, you already knew that.

  [ Reply to this ]

• Re: Entire conclusion is a non-sequitor by Ignacio H. Valdes, MD, MS on Friday January 12, 2007 @ 08:59 AM

  Could your argument be a red-herring :-)? You present no evidence to the contrary of my claim. I actually do present evidence that I have experienced personally with my example of getting data out of a proprietary, LAN-based EMR which is a real-world example. The necessity of having to call an EMR vendor for any reason is onerous to me. The necessity of calling a browser-based proprietary EMR for technical information is now obligatory since not even binaries are shipped. This will invariably result in: 1) More opportunities for the EMR vendor to charge more money whether legitimate or not with poor response time or no response at all. 2) An opportunity for the EMR vendor to ask 'what do you need that for?', 'why are you asking?' and 3) The dreaded 'we want to make sure this won't void the service contract'. All the above are real world examples that I have personally experienced. Proprietary, browser-based EMR's by their nature will only increase this. -- IV

  [ Reply to this ]

• Re: Browser Based EMR's Threaten Software Freedom by Fred Trotter on Monday January 15, 2007 @ 09:37 AM

  CCR is a great example of a standard like the one I mention above, good but not yet solid. Still I agree that is definitely the closest to being solid. Real Soon Now (tm) MirrorMed will be able to import and export to CCR too. But then, if we are going to all this trouble, and you are going to all this trouble why don't you simply use MirrorMed. From a practical standpoint, your company would be doing exactly the same thing it is doing now, but with 10 programmers instead of one... Its better practically... its better morally... something to think about. Trotter

  [ Reply to this ]

• Re: Browser Based EMR's Threaten Software Freedom by Redzzand on Wednesday June 20, 2007 @ 09:05 AM

  Browser based software requires much less bandwidth than LAN based applications. Additionally, browser-based software can be accessed remotely through the internet from any hanheld device such as PDAs, Blackberrys, Internet-enabled cellphones, laptops, tablet pc's, etc. All of this can be accomplished securely through the use of TLS/SSL 128-bit encryption.

  [ Reply to this ]

• Re: Browser Based EMR's Threaten Software Freedom by Ignacio H. Valdes, MD, MS on Wednesday June 20, 2007 @ 10:20 AM

  False. LAN based applications take no more and no less bandwidth than anything else. Moving a bit is moving a bit whether it is a browser or a RPC call. You can argue that Browsers have been optimized for certain things, but so can client-server applications. EMR applications such as VistA are client-server based and very optimized for low-bandwidth service. For now at least VistA's CPRS client can do things that browser-based applications cannot. -- IV

  [ Reply to this ]