Cloud + VistA = Astronaut Shuttle

I am not sure how many people out there have tried Astronaut Shuttle yet.

First, let me get the caveats out of the way. Ignacio Valdes, the CEO of Astronaut (the company) hired me to do most of the cloud related work on shuttle. So I am financially biased on this. I chose to take the work, because I believe that the future of VistA is in the cloud. (If you do not know what VA VistA is, this might be a little muddy to you, and you might take a second and find out what VA VistA is…)

I hope that my readers can glean just how important the idea that is being put forward here is. Many people have criticized VistA for being long in the tooth and not “hip” to modern innovations such as the Cloud, web 2.0 and health 2.0 concepts. On the other side, no one has been able to provide any results in the same league as the clinical improvements that VA has seen over the last several decades using VistA. In the universe of Health Informatics people touting beautiful new technologies have failed to outdo people using the tried-and-true but boring. What follows is a template for taking the best parts of the new platforms, and using them to improve the classic VistA technology.

The History

The idea for shuttle came to Ignacio and I over the course of many of our back and forth conversations about the cloud and about his Astronaut VistA installer package.

For those who do not know already, VA VistA used to be a real bear to get installed and basically configured. Getting to “hello world” with this amazing MUMPS-based Open Source EHR system was really really difficult. Dr. Ignacio Valdes, of LinuxMedNews fame, set out to change that. His goal was simple, he wanted to make VA VistA usable, as close to instantly as humanly possible. He wanted to remove any cumbersome installation or configuration decision that had no meaning to the administrator making the decision. What was a process that took months for first-timers now takes mere minutes, simply download the astronaut rpm or deb installer to your Linux machine and away you go.

Once Ignacio had taken the project all the way to consistently working DEB and RPMs, I noticed that he spent lots of development time spinning up Rackspace Cloud GNU/Linux instances, installing an Astronaut DEB or RPM, and then giving root access to a collaborator to debug something or another.  I began wondering if this process could be automated. With a little study I discovered that we could use paid AMI instances to give people access to GNU/Linux images pre-configured to run Astronaut VistA.

The rest is history, I created Shuttle to work with Astronaut, and Ignacio developed critical features into Astronaut so that it would work cleanly in a cloud environment. When it came time to name the system, it was pretty obvious: what do you use to “launch” astronauts? Shuttle is a lot like RightScale , in that you use it to launch Amazon ec2 images, but specifically tuned to handle things required by an EHR, specifically VistA, in the cloud. One of its most important functions is as a key-server, so that you can have a fully encrypted VistA instance, without ever having the password live on the instance itself. That might sound like a lot of mumbo-jumbo to you if you are not technical, but what it basically means is that Amazon, even though they are hosting your VistA EHR for you, cannot access the health information stored on the database… only the EHR users can do that.

The service is still in beta, we would like to have more feedback and several critical service offerings (like auto-magic cloud-based backup) in place before releasing the system as 1.0. But as this point we are pretty confident that we will be able to carry customer EHR data who want to use the beta system in live environments forward. (that is what makes it beta, rather than alpha…) I would love to hear comments from my readers about what features they would like to see next in a service like this, as well as what you think those features should cost. Medsphere just charged a 100-bed hospital $2 million dollars for 5 years of VistA support, so getting full-access to VistA experts is an expensive proposition. I want to be clear, the kind of hand-holding and face-to-face help that Medsphere is selling is not what you get with Shuttle. We are essentially taking a metered approach to EHR deployment… the first offering is just automated installation in the cloud… what services do you want next?

It does not really matter if you want to host your instance of VistA in the cloud or not, the whole point of using an Open Source EHR system is that you are not married to your software vendor. If you feel like you no longer want to have your VistA EHR hosted in the cloud, all you need to do is copy your EHR to your own server, and then turn off your cloud server and stop paying. That means if you just want to spend a day or two playing with VistA to see if it is right for you, you can do that, and then turn off your cloud server and decide if you want to go to the trouble to install it locally.

I am in a pretty decent position where I can afford to work only on projects that I feel are truly revolutionary. Think about it, other vendors are charging several hundreds of dollars per month -per doctor- to get access to an EHR system. Using Astronaut and Shuttle, we can charge about $100 per month for an entire EHR. That’s a minimal markup (once by Amazon and once by Astronaut) on the base cost for the hardware itself. An EHR that can run an entire clinic or hospital. While some people will not be able to live with the limitations of the cloud (you have to have your data off-site for instance) for those who can tolerate the cloud, can get access to extremely high quality software at near-hardware costs.

Besides Amazon ec2, Shuttle would not have been possible without the excellent Ubuntu images from alestic and the php Amazon AWS library CloudFusion. Obviously none of this would have been possible without the Astronaut server and client installers, projects which are in turn indebted to OpenVistA and WorldVistA. Standing on the shoulders of giants.

The Idea

Before Shuttle, installing VistA required considerable systems administration know-how. With Shuttle you can start a VistA server, in the Amazon Cloud in a few minutes. You do not need to see a command line once. Anyone can now use a simple web-interface and have access to VistA, which is arguably the best Electronic Health Record System in the world

VistA is in two parts, a server and a bundle of clients that installs on Windows XP (the most famous of which is CPRS). Setting up the VistA server requires access to GNU/Linux or  proprietary software under Windows. The Open Source Astronaut VistA installers make it easy to install the VistA server on GNU/Linux. But setting up a separate server to test an application is a bother for those who no how and impossible for those who do not know how. Either way, using Shuttle, you can just start an instance of OpenVistA or WorldVistA with a click of  a button.

The VistA instances do not just have the VistA server installed, they also have a version of the Astronaut VistA client installer available for download from each instance. Each instances compiles the installer to be pre-linked with the server that it is downloaded from. The end result is that you download and install the client from an Shuttle VistA instance, it will auto-magically talk directly to that instance. All traffic to the server is encrypted and all data on the server is encrypted, as per HIPAA/ARRA regulations.

What does that mean? It means for the cost of renting a small server at Amazon (about $100-$150 per month), you can instantly have access to an entire VistA server. That VistA server, encrypted, in the cloud,  will allow you to download a client pack to every computer in your clinic or hospital. This is as close as you can get to instant VA VistA. But rather than let me continue blabbing about this idea, let me show you how it works…

Happy Launching!

-FT

gvim over ssh

I use vi for development.

I keenly remember one of Dr. Eggen‘s early lectures to us.

“There are other editors out there, but if you learn to use vi, you will have a powerful editor on every unix server you ever use…” (or something like)

It took me the about halfway through the compsci intro class to get used to command mode vs. input mode, but since then I have never looked back. Using keyboard commands to perform editing has become second nature to me, and I find myself constantly typing ESC then yy on windows text editors… Then I promptly install vim for Windows. Making Dr. Eggen’s point even more valuable.

However, I have gotten used to gvim. Its really the best of both worlds. You can use mouse based cut and past, but all of the command mode goodness still works. I must admit that I have never memorized the search and replace syntax and the fact that it is a dropdown menu on gvim really helps.

More and more I have been programming in the cloud. Which means I am frequently (for hours each day) using vim over ssh. But I miss gvim and the helpful menu items. I have been looking for a way to easily use gvim on a remote host for some time. Sharing an X session over the internet has always felt a like overkill to me. No cloud server should have X installed in any case.

The answer sshfs. Here is a link to a tutorial to using sshfs.

Basically the idea is that you have scp mirror a whole directory content, in real time, to a local directory. Because it is a local directory, gvim works fine. Of course, it takes an extra second for files to load… but now I can use gvim to my hearts content. It also means that I can edit ten different files at once, a pretty important feature if you are doing serious development work. This lets me code for the cloud in the cloud, which is lovely.

[Update Dec 19 2010] Happily this works with Mac OSX to… but you need to be sure to download the right version of gvim from here: http://code.google.com/p/macvim/ the one that comes up first when you search… sucks…

-FT

To Senator Grassely on EHR problems

Senator Chuck Grassely has sent out some letters to several proprietary EHR vendors asking some pretty direct questions. Here is the relevant excerpts.

Over the past year, I have received complaints from patients, medical
practitioners and technologies engineers regarding difficulties they have encountered
with the HIT and CPOE devices in their medical facilities. These complaints include, for
example, faulty software that miscalculated intracranial pressures and interchanged
kilograms and pounds, resulting in incorrect medication dosages.
In addition, it has been reported that HIT/CPOE manufacturers rely on a legal
doctrine known as “learned intermediaries,” to shift responsibility for errors in the HIT
systems to physicians, nurses, pharmacists, and other health care providers. The
manufacturers allegedly argue that the health care provider should be able to identify and
correct errors caused by the software. It has also been reported that HIT/CPOE contracts
with medical facilities may include “hold harmless” provisions that absolve
manufacturers of these products of any liability for errors that are allegedly HIT/CPOE
system or software failures. These contracts may also include “gag orders,” which
prohibit health care providers from disclosing system flaws and software defects.

Furthermore, it was also reported to me that there is no system in place to track,
monitor and report the performance of these systems/devices, which could impact a
health care provider’s ability to make informed decisions regarding the implementation
of an HIT/CPOE system.

To start lets bullet these complaints:

  • faulty software with dangerous results
  • avoidance of liability using legalize
  • gag clauses
  • no open data on bugs and problems

I submit that these are problems arise from the quasi-monopoly that these companies aquire with their software licenses. A definition of monopoly is:

a market in which there are many buyers but only one seller

The government does a pretty good job of breaking up simple monopolies, monopolies where there is simply one provider of a service and that is all there is to it. The government does a pretty bad job of preventing what you might call “staged monopolies”, which is more commonly referred to as “vendor lock in”.

I love simplified examples. When you are on the outside of a movie theater, there is a competition for your movie dollar. You can drive to another theater, you can go home and watch a rented DVD, or a movie downloaded from the Internet. But the moment you pay for the ticket, the competition portion of the movie experience is over. If you looked at the items available from the concession stand -inside- a movie theater you will see a clear pattern:

  • The items available are all high-profit items. Healthy sandwiches require lots of labor relative to popcorn, but would not sell for much more…
  • The items available are all enticing, but what is enticing might not be very good for you.
  • Everything is overpriced.
  • The service is typically non-existent.

Once you have purchased your movie ticket, the movie theater has won the competition and also earned the ability to overcharge you for everything else. Also, the movie theater is very strict about forbidding outside food.. it has to be in order to protect its cash cow. Its not a particular theater that is at fault here, it is the basic structure of the deal itself. All of the theaters have the same deal, and all of the theaters offer the same high-priced, artery-clogging fare. They have to in order to stay competitive with each other.

The movie goer knows that the basic deal they are making is a bad one. If they wanted to have a healthy movie, they would rent a DVD and stop by Subway on the way home.

The problem with doctors purchasing proprietary EHR systems is that the problems that you are seeing are the direct and necessary consequences of the monopoly that a proprietary software license provides to the EHR software vendor. Proprietary software vendors are competing carefully -before- the EHR is purchased, but once the doctor has bought the system he is trapped.

Why the gag orders? Because the EHR vendors compete only -before- the EHR purchase, they have a huge incentive to provide the doctors with slanted data during that stage. How do they do they do that? They chose one customer who is really happy with their product and they have tours of that facility and they write white papers about that facility and they provide that facility as a reference. They might have 95 facilities who are furious with them and 5 who love them, but if they have a gag order in the contract then they can use the 5 to provide a skewed view to new clients.

You have already pointed out that there is no open system for reporting the flaws in EHR systems. All of the companies that you survey will give you lots of information about their sophisticated systems for tracking software errors. But these systems are closed, and as a result, there is no way for a particular doctor to know if the software problem he is having is common or unusual. There is no way for the doctor to recognize that he or she is the victim of systematic neglect or is the only person on the planet with a given problem.

Gag orders and closed reporting systems are two tactics in a much larger struggle between proprietary EHR vendors and EHR consumers. The struggle is to control the information available to EHR purchasers. This is not the only way proprietary EHR companies skew the data. They use organizations like HIMSS and the EHRVA to provide an air of legitimacy and professionalism. There are organizations that provide EHR “reports” that are supposedly objective, however, these types of evaluating organizations typically also serve as “consultants” to EHR companies. In short the EHR companies pay off the “researchers”. There is no equivalent to “Consumer Reports” in the EHR market (although there are some organizations that are trying). If a doctor is reading a report comparing EHR vendors, that report was very probably made by someone who was paid by those vendors.

There is a tremendous financial incentive to control information that impacts EHR sales, and lack of objective information is one of the big problems that your constituents are facing.

Now lets talk about the software bugs. We can talk about to classes of software bugs, bugs that are so huge that they blow up a salesman’s presentation of an EHR, and all of the other bugs that are not that big. I can assure you that the average proprietary EHR system does not have many sales-destroying bugs.

Bug-fixing isan expense, and a big one. Lets imagine that this year, software company X will discover 100 bugs in their software. Now, how will the “bottom line” be impacted if they fix 90 bugs vs 10 bugs. The answer? very little. There is simply no financial incentive to provide a greater reponse to EHR bugs. Their customers are trapped. When a doctor uses an EHR even for a short time, that doctor makes three important investments, time, money and patient data. Once they have chosen a vendor, it is almost always a worse deal to leave the vendor then it is to continue to accept poor service from that vendor. If they leave, they have to buy a new system, learn a new system and migrate patient data. It just costs too much.

Its just like the movie patron. Every time I pay six dollars for fifty cents worth of coca-cola, I resent the movie theater. I -could- leave and go somewhere else, but then I would loose the price of the tickets, and not get to see that movie tonight; too expensive. So I suck it up and pay six dollars for a small coke.

Again, it is not the proprietary EHR vendor itself that is at fault, it is the basic unfairness of the bargain.

Your last concern was regarding the legal loopholes that EHR vendors use to avoid the liability that occurs when their software causes medical errors that hurt people.

The simple reality on this issue is that no EHR company, proprietary or otherwise can afford to share medical liability with a doctor. A single death or serious injury that could be tied to the EHR vendor instead of the doctor could put the vendor out of business. If they could not avoid the liability contractually, they would have to insure against it, and the cost of that insurance would be roughly on par with cost of the medical malpractice that the doctor is forced to pay. If any EHR company is exposed to these levels of potential liability, then the stimulus money from ARRA will not make a dent in the new costs of EHR systems.

Software bugs are a simple reality. EHR software bugs, have and will continue to kill people. This is a difficult thing for politicians to face, but that -is- an acceptable cost of moving to EHR systems. If I told you that by causing 100 deaths a year I could prevent all of the traffic accidents in the United States in the same year you would jump at that offer! The math is really that simple: how may people will EHR bugs kill? vs how many will be saved through pervasive availability of EHR technology?

The problem is that right now, no one know what the true cost of these EHR bugs except proprietary EHR companies who stand to profit greatly by keeping the information secret and keeping the number of people killed by bugs as high as possible. Fixing bugs is a tremendous expense and the EHR companies have a financial incentive to only fix as many bugs as it takes to keep their clients from leaving. Because the cost of leaving is so high to EHR clients, the number of bugs fixed is low indeed. The current system incentivize proprietary EHR vendors to keep the information about deadly bugs a secret and to fix as few of them as possible.

The solution? The doctors must discern that the deal is bad, and seek a better one.

People are watching less and less movies at theaters. People have learned that there is a much better deal available. Buy a nice TV, rent the same movies for a fraction of the cost, cook whatever you want to eat and watch the movie from your comfortable sofa. The market is pushing people away from the crappy monopoly deal and towards the better deal without any monopolistic component. Movie theaters are responding..  now many movie theaters have removed rows of seating to make room for tables and are offering full restaurant style meals at reasonable prices… along with seeing a movie. A much better deal.

For EHR vendors, the better deal is this: An open source EHR.

Here is why an Open Source license prevents the problems you are mentioning:

First, the competition never stops, the open source license give the EHR buyer the right to fire the EHR vendor, and hire another one, without migrating software. That means that the end of the sales process does not mean the end of the competition. If an EHR vendor tried to have a client sign a gag order, that client could find another vendor to implement the first vendors software offering. If the open source EHR vendor failed to fix a critical software bug, the client could find another vendor to do it, or even do it themselves. All open source software vendors of note publish bugs publicly, in fact they will even accept bugs discovered by people using the software who are not paying the software vendor. Open Source software naturally produces open bug reporting, competition for the fixing of bugs, and no gag orders (or other silly contract stunts). What about liability? By making the basic relationship fair, and focusing vendor competition on reducing bugs the software is made safer through the natural action of commerce, rather than the artificial safety provided by lawsuits. Critical bugs, like the ones mentioned in your letter, will be fixed overnight, or somebody will get fired. That’s a much better deal than ensuring that when someone is killed after 4 months of living with a known bug, there are more people to sue.

But do not take my word for it.

I would encourage you to send your letter and questions to Mike Doyle, the CEO of Medsphere (an important Open Source EHR vendor) and compare his answers to those provided by the vendors you have already sent letters to. Do not worry about time, it will only take Mike a day or two to answer the questions. Most of the information is already online, he could just send you a bunch of hyperlinks. Medsphere is not the only good Open Source EHR vendor, but their responses will be typical of the industry. I can provide you with 10 other Open Source EHR companies if you would like.

What do I want you to do about all this? Nothing. Open Source EHR systems wins in the end anyways…

Do think of me the next time you watch a movie at home…

-Fred Trotter

Hardware Hack: Hacking the ICE Medical ID USB wallet card

I am happy to say that I have a totally new type of post for my readers.

I am going to detail how to modify to the “ICE Medical ID” product to be relevant for those of use who do not want to be stuck crappy proprietary software. This only barely qualifies as hardware hacking, I am just going to detail how to remove the default software that comes with the card. But once this is done, it will form the foundation for some much cooler work. I bought my card for $20 at a local CVS, but you can get them all over the place. The only difference between this and some other credit card sized usb drive is that it is clearly labeled that it contains your In Case of Emergency (ICE) information. Most importantly, the card is Open Source and remix friendly. You can put whatever you want on the card and your EMT or ER personnel might find it.

First, you need to turn on viewing hidden files and potentially hidden system files in your Windows folder configuration. (Unless you are using GNU/Linux, which makes this step unneeded) This will allow you to see the hidden system files that the Ice.exe relies on.  Once you have done this you should be able to see the following files on the USB drive:

Ice.exe

unicows.dll

Ice (a directory)

Autorun.inf

The hack could not be simpler… delete all of these.

The Ice.exe file is a simple PHR application that makes all of the first-generation software errors. It stores its data in xml (under the ice sub-directory) but not in CCR or CCD, making the data you enter there trapped. It has bullet choice defaults, even when a user has not chosen data. The end result is that the application makes assumptions (like that a user is married) for unselected options. This is exactly the reason why Health Information software should be open source. The company that released this card has no business creating health software and they hired professional developers, but amateur health informaticists to do this work. Lots of rookie mistakes here.

I replaced the above with a simple text file with the following information:

Hi,
If you are reading this then I must be hurt very badly.
Please make sure my wife, Laura Trotter (email) and (phone number)
and my brother Rick Trotter (email) and (phone number)
are fully informed regarding my condition.

My blood type is O+
I had minor knee surgery on my right knee several years ago. A small part of my patellar tendon was removed.
I am not allergic to anything that I know of. I have never had a reaction to any anesthesia.
You should be able to find an health insurance card in my wallet, where you found this card.

Thank you for taking care of me.

Regards,
Frederick (Fred) Clayton Trotter

Email might seem funny, but it might be possible that my wife is in a different country when I am injured, and email always works…

I thought about replacing the Autorun.inf with something to popup the text file automatically when the USB was inserted into a computer, but Windows 7 no longer supports non-optical drives running Autorun.inf and Apple OS X or GNU/Linux computers do not support that either. It is just as well since most of the time I insert the card into a computer I will be using it to transfer files.

I also could and probably will upgrade the text file to an html file at some point. But I think that kind of work is best left to when I can integrate the record with Google Health or better yet with Indivo. Html would have the added benifit of allowing me to integrate a picture, which would make it pretty simple to include information on one card for several people, a mom-pleasing feature indeed. (You can do this with the proprietary software only after you purchase the privilege)

Enjoy hacking your healthcare information.

-FT

On project governance

Recently, some of the i2b2 team asked me for my thoughts on project governance. I find that my lengthy email answers to these kinds of questions are worth blogging about. I mean really, its a bother to write a good blog post and a bother to write a long email… why duplicate??

The original question was very broad:

Can you share any pointers to governance procedures, policy
and organization for an OS process?

The first question to ask is who, practically speaking, currently has the right to modify the published version of i2b2? Lets call those the “developers”.
The second question to ask is who owns the trademark to the term “i2b2”? That person or organization is by implication the current shepherd. Most of your concern should go into legitimizing your current development team and ensuring that your shepherd organization is doing right by them.

Next, is there a for-profit company that is predominantly the employer of more than half of the developers? If that is the case than you can consider a for-profit shepherd organization (like RedHat or Canonical). Usually for an organic project like i2b2 this will not work.

Next you can setup a new non-profit as the shepherd organization. This is the most common model. The purpose of this organization is primarily to have someone to sue other than developers directly. 501c3s are a bother to setup, if you want you can create an “arm” of an existing non-profit. There are at least two options for this, you can work with Open Health Tools which is really designed to support this. Often that does not work for licensing or other governance  reasons, and if you need more autonomy but still want a non-profit shield, you are welcome to setup sub-organization with Liberty Health Software Foundation.  There are other Open Source Health IT non-profits out there…

No matter if you setup your own non-profit, partner with an existing one, or choose a for-profit vehicle, your governance model is basically the same core set of issues. The questions you must answer definitively with your organization governance is:

  • Who gets to update the code?
  • Who gets to name a particular codebase as the “current” and “official” version of i2b2?
  • If you have a modular architecture (and who doesn’t?) how do you decide which modules get to advertise on the main community “site”
  • How do new developers earn the right to update the core code?
  • Who will you recommend for paid support? How can an organization get on that list? This is an important question, you must do everything to ensure that when i2b2 is installed somewhere by some third party that if that third party was using the i2b2 name to market themselves that they did a good job.
  • What are the rules for the use of the i2b2 trademark?
  • Where do you go on the web to participate in the i2b2 user and developer community?
  • Who owns the copyright to i2b2? What is the license? If you decide to change the license how will that happen? Are you requiring copyright assigments for coded contributions and if so, to whom are the copyrights assigned?
  • What is your policy towards patented software? (Universities can be sensitive about this)
  • Will the organization be employing developers? Will you seek money for development?
  • How will you unsure that future difficult decisions on your project will be made well?

I know that i2b2 has very strong academic associations, as many FOSS projects do. That relationship may mean that “at the university’s discretion” is often the answer to many of the above questions. That is fine, but you need to make it perfectly clear which of the above questions you are abdicating (and why) and which you are not.

I hope that I have adequately opened a can of worms for you. I have many opinions on how these questions should be answered and for each of them there are many different legit paths taken by other FOSS organizations. I can intelligently discuss how the top reference organizations function as applied to you (like Apache, Mozilla, Eclipse and Linux) to see where there might be areas for you to imitate. Let me know which of these topics interest you and I can discuss them further here. The most important thing to realize is that your governance -cannot- be as complex as the Apache governance processes without also having the kinds of resources that the Apache projects have. You either need to work with an organization like Open Health Tools which has alot of these things figured out, (but may have made decisions that you cannot live with) or you need to create a light-weight set of processes and governances that are something that your organization can actually follow.

I am sure that you already have concerns and ideas that I have not even listed, either because I am unaware, or I think there are not important. So I as you go through this process I would advise you to ask two questions:

“What bargain am I making with my users? Besides understanding what my software does, my users want to understand what license obligations they are undertaking to use my software. They want to understand how to connect into a community of users, and how to get paid support if they need it. Are the ‘terms’ for becoming a user of the my software clear and fair? “

and

“What bargain am I making with my developers? Developers are by implication both interested and not satisfied with my current software. They want to improve it with me, but they must calculate whether it is worth their time to make the investment to develop with me. Are the ‘terms’ that I set forward to them clear enough that they can determine whether to make that investment?

Sometimes an shepherd organization is going to have to make unpopular decisions. (Like Red Hat did in retiring Red Hat Linux and creating Fedora) How will your organization be able to make good decisions that potentially infuriate your users? More importantly, how will your organization recognize when your community of users has moved beyond you? (Like the firefox project did inside Mozilla) how will your organization maintain the humility to recognize that a community version is better than your official version?

If you get either of these questions wrong, your shepherd organization will end up holding your project back in the long term.

Probably the most controversial question that you have to answer is to what degree you will allow your community to rule you. When WorldVista (the current non-profit for VistA) was originally formed, they were concerned that corporate interests would “buy-out” the WorldVistA board. As a result there are no elections to the WorldVistA board positions. There is no way for the community to remove board members. Over time, this has resulted in a steady loss of “doers” on the WorldVistA board. Enforcing “doing” over “dithering” is impossible if you cannot rid yourself of someone who really wants to “dither” (for goodness sake look at Congress). As a result, the board tends to attract and keep “ditheres” while alienating “doers” in the community. The few “doers” on the current WorldVistA board are long-suffering and patient individuals… martyrs really. The end result is that WorldVistA consistently refused to make the difficult decisions. When they do act, it is usually only after a particular strategy has become obvious (<- read this as “too late”)

WorldVistA did not start out that way, it is a factor of organization rot based on bad decisions made early in the formation process. But remember, their concern was very real. There are plenty of organizations that get taken over by corporate interests. The purpose of a shepherding organization is to protect the project for its developers and users, that means partnering with companies, but not being ruled by them.

For a worst-case scenario of how an organization can get embroiled in project issue, consider when Tridgell developed a FOSS Bitkeeper client while employed by OSDL (the precursor to the Linux Foundation). At the time OSDL also employed Linus Torvalds, who was in favor of using the proprietary Bitkeeper. From OSDLs perspective, you had a big mess. Two of its sponsored developers where at odds putting in a potential position of liability from Bitmover, the company behind the proprietary Bitkeeper tool.

You have to consider the far future of a project as you consider your governance structure. To do this, you have to honestly, and potentially painfully, asses the potential conflicts within your particular community. Remember that it will not be you sitting in your chair when the critical decisions are made, you have to be able to assume that your replacements will be competent, but you would be foolish to assume that they have your motivations. Its a difficult balance and I wish any project luck with that.

For the best examples of well-run shepherding in our community I would recommend Medsphere.org (the community arm of Medsphere corp) and the OpenMRS project.

HTH,
-FT

Lack of Transparency in Houston, T.X.

I am quite happy to say that your insane business practices will soon be coming to an end.

http://www.hhs.gov/valuedriven/

Do you honestly think that any other business could get away with not providing up-front pricing? You actually expect me to visit in-person to determine whether you have a fair price for services? Try calling Walmart or IHOP or any other business that sells standardized products, you will find that they will be happy to publish those prices. Most of those businesses publish their prices on the Internet.

Prepare to be blogged about as a fine example of what cannot continue.
Do let me know if you decide to change your policy so that I can
update my blog piost.

http://www.fredtrotter.com

-FT

On Mon, Nov 2, 2009 at 3:31 PM, Midtown Dentistry
<censored@midtowndentistry.com> wrote:
> Good afternoon Mr. Trotter,  Thank you for contacting Midtown Dentistry.  We
> don’t give quotes over the phone or emails.  I will be happy to give you an
> appointment for and exam and consultation.  At this appointment you will
> have a full exam, consultation & x-rays.  Dr. Penchas will go over all of
> your needs and you will be given a treatment plan will all costs involved.
> Please call me at the phone number below so that I may assist you with an
> appointment.  Thank you again,
>
>
> Glenda Cornell
> Midtown Dentistry
> 315 Westheimer
> Houston, Texas 77006
> censored
>
> —–Original Message—–
> From: Fred Trotter [mailto:censored]

> Sent: Monday, November 02, 2009 11:13 AM
> To: censored
> Subject: Contact us message
>
> Contact Us Message
>
> Name : Fred Trotter
>
> Email : censored
>
> Phone :  censored
>
> Message:
>
> Hi, I need to have a extensive cleaning done (according to my previous
> dentist) and I would prefer to have it done under general anesthesia. I will
> be paying cash, so I would like to know the cost of an “extensive” or “deep”
> cleaning under general anesthesia factoring in any cash discounts you may
> offer
>
> Regards,
> -FT
>

Who owns the data

Who owns the health information?

  • the patient to whom it refers?
  • the health provider who created it?
  • the IT specialist who has the greatest control over it?
  • the researcher who aggregates it?
  • the health 2.0 company that harvested it?

the notion of ownership is inadequate for health information. No one has an absolute right to destroy health information. But we all understand what it means to own an automobile: You can drive the car you own into a tree or into the ocean if you want to. No one has the right to do things like that a “master copy” of health information.

All of the groups above have a complex series of rights and responsibilities relating to health information that should never be trivialized into ownership.

But asking the question at all is a hash argument.

What is a hash argument?

Come to think of it, there’s a certain class of rhetoric I’m going to call the “one way hash” argument. Most modern cryptographic systems in wide use are based on a certain mathematical asymmetry: You can multiply a couple of large prime numbers much (much, much, much, much) more quickly than you can factor the product back into primes. A one-way hash is a kind of “fingerprint” for messages based on the same mathematical idea: It’s really easy to run the algorithm in one direction, but much harder and more time consuming to undo.  Certain bad arguments work the same way—skim online debates between biologists and earnest ID (Intelligent Design) aficionados armed with talking points if you want a few examples: The talking point on one side is just complex enough that it’s both intelligible—even somewhat intuitive—to the layman and sounds as though it might qualify as some kind of insight… The rebuttal, by contrast, may require explaining a whole series of preliminary concepts before it’s really possible to explain why the talking point is wrong.

At some point I will modify this article to actually do the rebuttal. At this point it is enough to say that -even asking the question- who owns the data is creating a hash argument. The question presumes that the notion of ownership is valid and jettisons those foolish enough to try and answer the question into needless circular debate. Once you mistakenly assume that the question is answerable you cannot help but back an unintelligible position.

People asking this question at conferences is a pet peeve for me.

(update 2012: fleshing out this post, for reposting to radar)

So the reason that “ownership” does not apply to well to health data is that “ownership” means a little too much to apply well for anyone. Here is a quick chart that shows what is possible depending on a given role.

Person/Privilege Delete their copy of data Arbitrarily (without logs) edit their copy of data Correct the providers copy of the data Append to the providers copy of the data Acquire copies of HIPPA covered data
Sourcing Provider No. HIPPA mandates that the provider who creates HIPAA covered data must ensure that a copy of the record is available. Mere deletion is not a privilege that a provider has with their copies patient records. No. While the provider can change the contents of the EHR, they are not allowed to change the contents without a log of those changes being maintained. Many EHRs contain the concept of “signing” EHR data, which translates to “the patient data entering the state where it cannot be changed without logging anymore”. Yes. The provider can correct their copy of the EHR data, providing the maintain a copy of the incorrect version of the data. Yes. The providing merely add to data, without changing the “correctness” of previous instances of the data. Sometimes. Depending on the providers ongoing “treatment” status of the patient, they typically have the right to acquire copies of treatment data from other treating providers. If they are “fired” then they can lose this right.
Patient rights Yes they can delete their own copies of their patient records, but requests to providers that their charts be deleted will be denied. No. Patients cannot change the “canonical” version of a patient record No. While a patient has the right to comment on and amend the file, they can merely suggest that the “cannonical” version of the patient record be updated. Yes. The patient has the right to append to EHR records under HIPPA. HIPPA does not require that this amendment impact the “canonical” version of the patient record, but these additions must be present somewhere, and there is likely to be a substantial civil liability for providers who fail to act in a clinically responsible manner on the amended data. The relationship between “patient amendments” and the “canonical version” is a complex procedural and technical issue that will see lots of attention in the years to come. Usually. A patient typically has the right to access the contents of an EHR system assuming they pay a copying cost. EHRs frequently make this copying cost unreasonable and the results are so dense that they are not useful. There are also exceptions this “right to read” which includes psychiatric notes, and legal investigations.
True Copyright Ownership (i.e. the relationship you have with paper you have written or a photo you have taken). Yes. You can destroy things you own. Yes. You can change things you own without recording what changes you made. No. If you hold copyright to material and someone has purchased a right to a copy of that material, you cannot make them change it, even if you make “corrections”. Sometimes, people use licensing rather than mere “copy sales” to enforce this right (i.e. Microsoft might have the right to change your copy of Windows, etc…) No. Again you have no rights to change another persons copy of something you own the copyright to. Again, some people use licensing as a means to gain this power rather than just “sale of a copy”. No. You do not have automatic right to copies of other peoples copyrighted works, even if they depict you somehow. (this is why your family photographer can gouge you on reprints.

Ergo: neither a patient, nor a doctor has an “ownership” relationship with patient data. So asking “who owns the data” is a meaningless time-wasting and shallow conceptualization of the issue which is at hand.

The real issue is: “What rights to patients have regarding healthcare data that refers to them?” This is a deep question because patient rights to data vary depending on how the data was aquired. For instance a PHR record is primarily governed by the EULA between you and the PHR provider (which usually gives you wildly varying rights depending), while right to your doctors EHR data is dictated by both HIPPA and Meaningful Use standards.

Usually, what people really mean when they say “The Patient owns the data” is “The patients needs and desires regarding data should be respected”. That is a great instinct, but unless we are going to talk about very specific privileges enabled by regulation or law, it really means “Whatever the provider holding the data thinks it means”.

For instance, while current Meaningful Use does require providers to give patients digital access to summary documents, there is no requirement for “complete” and “instant” access. While HIPPA mandates “complete” access, the EHR serves to make printed copies of previously digitized patient data completely useless. The devil is in the details here and when people start going on about “the patient owning the data” what they are really doing is encouraging a mental shortcut that cannot readily be undone.

HTH,
-FT

The Health Internet

For whatever reason, people still do not get the basics of the Health Internet. Part of the problem is the fact that the marketing term has been, until recently the National Health Information Network or NHIN. The Feds recently decided to start calling the project the Health Internet, because that gives a much better idea of what they are trying to achieve.

Please do not be the guy/gal who writes in my comments but the Internet is not secure, that means my privacy will be violated. That is pure FUD and is not how the Health Internet will work. It is a relatively simple process to make the Health Internet into a zone that is more secure and private than the current health information infrastructure. Notice that did not say “secure” I said “more secure”. Your bank is not “secure”, your doctors paper records are not “secure”, the CIA is not “secure”. As an adjective, secure is more like the human attribute of “tall”. I am typically considered a tall person, but in college I was an student athletic trainer for my schools basketball team. In that crowd, I was short. While there is one and only one person who can be considered universally “tall”, it is well understood that this is a relative term. Similarly, the Health Internet is relatively more secure than current systems. I personally am far more comfortable having my private data in the Health Internet than I am with having my paper records locked in my Doctors office. You should be too.

So you should not be thinking about security or privacy in the Health Internet…. Really… It is as close to a solved problem as it gets. There are always obviously ways to make things more secure… but taller is not always better.

So what does the Health Internet buy you as an individual living in the US? To put it simply you and your Doctors should eventually be able to get to all of your health information as easily as you now get access to your financial information. Its a big promise, but the design of the Health Internet should eventually make that kind of convenience and access a reality.

Given that, it becomes obvious why a rebranding to the Health Internet is a good idea. For several basic reasons:

  • the original Internet started life as a government network (ARPANET)… And that has turned out pretty well.
  • the reason that the original Internet was such a hit was that people built neat stuff on top of it. Similarly, the Feds are hoping that people will use the Health Internet as the platform for further innovation.

So the Health Internet is a good thing and everyone should embrace it.

So how do you jump start a Health Internet? You do it by providing Open Source Software that enables people to participate in the new network.

Most people do not really understand the relationship between Open Source networking projects and the success of the original Internet. Here is how this breaks down:

Most of the Internet servers that provide X do it using Open Source project Y. With that as a template, look at the following chart:

Email:sendmail
DNS:bind
Web server:Apache

Of course, you -can- use proprietary software for these components, but the Internet as we know it would not exist without these very low cost tools that provide a substancially large portion of our Internet infrastructure. So whats the plan for the Health Internet? Simple.

Health Internet:CONNECT

The CONNECT project is an Open Source project that -will- run the core Health Internet. The core will connect major government health data sources including the VA and the DoD the initial Health Internet core. Most importantly the CONNECT software is available for local exchanges to connect into the core Health Internet.

Overall the strategy of creating an Open Source project that can be used to fractally to create other, connected, networks is a proven strategy. Its a smart move and it is going to change Health Informatics in fashion that is very similar to the way the Internet has already changed computing generally.

Open Source Health Software Conference

So I have two small news items.

First, I am renaming the yearly Houston Open Source Conference from fosshealth to OSHealthCon, which just stands for Open Source Health Software Conference. Why the name change? Well, it is caused by the need for me to distance myself from the term “free”. I know what “free” means when you are talking about software, but again and again, the term is abused by people with a proprietary agenda.

People would talk about the differences between “free software” vs “commercial software” implicitly insulting any professional who wants to use freedom-respecting licenses.So I am throwing in the towel. I am not going to fight this battle any more. At some point, I have to decide if I am going to advocate for freedom, or for one particular way of talking about freedom.

The other important news item is that I have started posting the 09 Videos up to www.OSHealthCon.com.

This is our first stab at videoing our own conference, and the results are just as amateurish as you might expect. Still, if you can tolerate the sound, there is a tremendous amount of insight available there.

I will be posting new videos there as I sort out how to make blip.tv transcoding work on GNU/Linux.

-FT