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.

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

• 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 ]