Many Eyeballs Actually Looking: Microsoft’s Shawn Hernan responds

One of the things that I love about blogging is that it often puts you directly touch with those people who are influencing your thinking. This is just what happened when Microsofts Shawn Hernan sent me an email response to my recent blog post about the security of Open Source Healthcare Software. As it turns out, he also spent some time at the Air Force Information Warfare Center in San Antonio, we probably passed each other in the hall at some point.

Shawns original article,  Microsoft’s Many Eyeballs and the Security Development Lifecycle had spurred me both to kibitz some of his points, and to consider their implications in Open Source healthcare software.

Shawn wrote the following to me and gave me permission to quote him here:

I saw your comments on my blog, and just wanted to write a quick note to thank you for the positive comments and the constructive and reasonable criticism.

It is of course unfair to lump all open source projects under one umbrella, and I regret leaving that impression. The various fights that people have over the different open licenses is all the evidence that anyone needs to see to realize that the only thing that many FOSS projects have in common is their “FOSSness.” And it’s clearly true that there is some highly competitive FOSS software.

I also like your characterization of “the game” for developers. I ran the security training program at Microsoft for a while, and while it was successful, I quickly learned that a corporate training program leaves a lot to be desired. We have a team called “Engineering Excellence” and they turned me on to the ideas of human-performance management, and I wrote about some of my experiences here: http://blogs.msdn.com/sdl/archive/2008/05/29/sdl-training.aspx. I think this is not too far from your idea of “the game” as I understand it.

I will quibble some with your ranking, though, and the implicit assumption that Microsoft is all a single culture. While the cultures differ from team to team (Windows v Office v SQL), all the big teams have a security-obsessed subculture and are all subject to at least the minimum SDL requirements, and I feel confident in saying that all our teams are at the very least competitive with the best open-source projects. I would invite you to look at the security track records of SQL Server, vs. MySQL for example.

But I do agree that the #6-style vendors may try to adopt my argument; I’m not trying to claim that proprietary software  is inherently more secure than open source, but merely trying to challenge the meme that openness, all by itself,  conveys  magic security properties.

I agree with Shawns point here. The meme that openess all by itself is a magic bullet for security improvement is dangerous precisley because it interferes with “games” that can make Open Source more secure.

When someone says “The Many Eyeball effect” the right counter should probably be, “The Many Eyeballs Actually Looking”. Secure Open Source does not happen because people merely can look, it happens when they use their rights under the license to actually take a look. Openess is a critical first step in the process, but only the first step. Often, as I look at how money is being spent in Open Source in healthcare, I see far too little being explicitly spent of efforts to make things more secure. I think part of the reason is that people just assume that it will happen. When it doesnt you end up with insecure code that people trust more, because it is open.

I hope it is clear why this is an especially bad problem for Open Source Health Information Software. People really need to be able to rely on Health Information being private. There are two reasons for this. First, it could actually hurt someone if their health information got out. Second, our culture reacts really poorly to violations of trust, and, even if a software developer is not directly at fault for private information getting out, the reputation consequences are very serious.

Our community has already been damaged by this effect. The VA’s reaction to security breaches was part of the motivation for centralizing VistA development, which has lead to a serious stagnation in VistA development within the VA. The current VA administration is slowly reversing many of those decisions and opening development back up, but “security drama” has already seriously damaged VistA development.

We should be listening carefully to Shawn here. His point is, very simply, that merely being Open Source does not ensure security. We need to find a way to create a “game” for Open Source healthcare developers that automatically improves security. Without some kind of built-in incentives, we run the risk of creating trust without justification. We need to take page from Microsofts book here, at least to a certain extent.

We need to work to convince those of us who are “feature-focused” to balance that with a “security-focus” if we are to be succesful long-term.

-FT

Security Reviews in Open Source Health Software

Recently, Shawn Hernan wrote a piece on Microsoft’s security blog that argues that the “many eyeballs’ effect does not ensure that open source software is secure.

His argument is excellent and while I disagree somewhat with his conclusions, his point is undeniable. his argument, if it can be boiled down to a quote is:

The key word in Raymond’s argument is can. I’ll concede that open source can be reviewed by more people than proprietary software, but I don’t think it is reviewed by more people than proprietary software.

The simple reality is that -most- Open Source software projects are -not- popular enough to create a sub-culture of project developers who devote themselves to fixing bugs and ensuring quality code. Note that just because Open Source software is popular with its users does not always ensure that the size and makeup of its developer community is large enough to encourage such a subculture.

This is where Shawns piece breaks down. He does not bother segmenting the various “Open Source” projects nor does he bother segmenting proprietary software companies. One of the most important lessons to learn about software development is that very very few proprietary software companies are capable of operating at the level that Microsoft does.

Lets imagine for a second what methods would produce the most bug-free and therefore secure software.

The most important issue for determining how buggy software will be is to determine what the “game” is for developers. “The game” is the basic motivational structure that each individual developer is subject to when writing the given software. This kind of assumes that there is some variance in the rate at which developers debug their own code, and the rate at which they review other developers code, based on some kind of reputation, financial, or pleasure incentive.

What happens if you make bug-fixing the primary focus of the game?

The primary culture of the development team would be to develop highly secure and bug-free code, then simple competition and social pressure, inside your core development team, would help ensure that you have secure code. If a new developer were to join the project/company and was seeking to establish credibility, he or she would know that finding a bug and fixing it would increase their own prominence, probably at the expense of the developer that wrote the bug. The original developer would know that and take every effort to slow down and write good code in order not lose credibility.

The problem with this “game” is that any Open Source project that took this approach would slow to a crawl. New features would be added very slowly, as developers spent lots of time reviewing, testing, and generally obsessing about bugs present in any portion of the code. In fact if secure code and bug-free software were truly the goal then this software project would intentionally continue to slow down as long as going any slower would produce better, more stable code.

Frankly, no reasonable business plan for a proprietary software company could ever tolerate such an intentionally metered pace. However, Open Source software presents the opportunity for any community culture to grow and flourish. The OpenBSD project is a project with a focus almost identical to what I described here. The OpenBSD operating system is objectively the most secure operating system in the world based on several measures. You might imagine that a project so obsessed with security and bug-fixing would have a web-page devoted to their thoughts and practices on the subject, and you would be right.

Shawn Hernan neglects to acknowledge that projects like OpenBSD are possible in Open Source but are impossible with proprietary software companies. But it is important that we not straw man Shawn’s argument. Proprietary Software companies have one substantial advantage over Open Source projects. They can pay developers to follow procedures that ensure high quality code and they can pay some developers to do nothing but professionally audit code. Microsoft is very good about this. But then they are in a pretty unique position regarding their software. You could restate Microsofts business plan as “protect the billions that we already make selling operating systems”. The profits from anything that the company is doing “to compete with Google” for instance, pales in comparison to the profits from selling operating systems. But Microsoft can recognize that if they do not compete with Google now, and at least sometimes on Google’s terms, Google will eventually begin to hit them where they live, by subverting the all important operating system profit.

Microsoft has developed strict code-review procedures, like the ones Shawn Hernan mentions, because every time a vulnerability comes out for Microsoft software, alternatives look better and better. At this stage in Microsoft’s history, they have decided that security is a financial priority, but this only after years of ignoring it in favor of other more profitable business priorities. Just like most Open Source projects are not focused on being fundamentally secure, most proprietary software companies do not have an financial incentive to invest in programmers and procedures that produce fewer bugs and more secure code. Especially in healthcare software, bug-free code is an afterthought. This is just the nature of for-profit endeavors. The focus is always on what makes the most money. Microsoft is now in a position where secure code will protect profits. Proprietary EHR companies are not in that position. They write code that helps them sell to doctors. Since doctors are typically irrational purchasers, the feature set and priorities of typical EHR companies are similarly irrational.

It should also be noted that just because Microsoft has an financial incentive to produce secure code in one product line does not means that this extends to all of its product lines.

There is another method by which Open Source projects can be more secure and bug-free than code developed by a proprietary software company with an financial incentive to produce solid code. Its pretty simple really, and Shawn has already acknowledged it:

But could “enough” code review, which might happen for popular projects like Linux and the Apache Web Server compensate for the more comprehensive approach of the SDL?….

Shawn is acknowledging here that there are differences between Open Source projects. Ironically both the Apache project and the Linux Kernel are often subjected to distributed attempts at systematic bug detection similar to the whole contents of SDL. A great example of this is the Security Enhanced Linux (selinux) project run by the NSA. The problem with software bugs is that they are often unimportant for the average user, but a cracker can still use them to break into the system. This point is made most eloquently in the classic paper by Anderson and Needham, Programming Satans Computer. Projects like selinux attempt to make other bugs less prone to becoming a security weakness, an important step. This is exactly the kind of comprehensive security improvement that, according to Shawn, auditing is not supposed to have that Microsoft’s SDL does have. But the many eyes principle is not limited to mere audits. The whole point is that anyone can could shoehorn bug-detecting methods onto Open Source projects. I will use the term “Audit” to embrace all of the bug-detection and fixing techniques that Shawn mentioned. Since simply human auditing is often the most onerous and unlikely task for all but the most motivated developers.

So we are now able to make a little ranking. Who has the most secure and bug free development practices and what kind of “game” are they using to achieve that security. I think it looks like this:

  1. Best: Security Obsessed Open Source: Open Source Projects that build-in bug-fixing at the expense of everything else, like OpenBSD.
  2. Really Good: Popular Open Source with audit teams: Open Source Projects that are so popular -with developers- that they can afford to create a security obsessed sub-culture within the development team. Projects like Apache, Linux, and MySQL (before… well you know…)
  3. Really Good: Proprietary Vendors who pay for audit: Proprietary software vendors who have a financial incentive (Microsoft) or cultural imperative (Fog Creek)  to create a development structure that reduces bugs.
  4. OK: Audited Open Source: Open Source projects that are sufficiently popular with developers to actually get some kind of formal code audit, preferably both automated and by a programmer trained in testing.
  5. Crappy: Unaudited Open Source: Open Source projects that are essentially one-man shows, whose code is rarely used and even more rarely looked at. (The vast majority of Open Source software projects in existence fall into this category)
  6. Worst: Unaudited Proprietary: Proprietary companies without a financial incentive to pay for expensive testing and bug-detection essentially have a financial incentive to -ignore- bugs. For most proprietary companies a software problem is only actually a bug, if it prevented a sale or lost a client.

Shawn’s post correctly points out that Microsoft, which is a typically in group #3 is much better than Open Source generally which is typically in group #5. of course his argument will be embraced and touted by companies who are in group #6.

Which brings me back to my subject of passion: Open Source medical software. I believe, tragically, that most Open Source Health software projects are in category #5 (Unaudited Open Source). I think this is changing with companies like Medsphere and ClearHealth becoming more mature companies, they can afford to sponsor auditors for their projects. Others like MOSS and Indivo are starting out with a security focus. I think #2 is the right target for us since it is not clear that OpenBSD is a -better project- just because it is -more secure-. Linux is still more secure that Microsoft Windows, and it is developed at much greater pace.

Still, I think the lesson here is that the best security happens when people focus on the boring and mundane. Starting with reading someone else’s code and then moving all the way up to using software to make software more secure. We simply do not have enough security focus in our corner of the Open Source world and I have to admit it is partly my fault. Before coming to the world of Open Source Health Software I was trained in Information Security at the Air Force Information Warfare Center in San Antonio. That payed off with later security contracting with Rackspace, Verisign and Nokia. I have never been 100% devoted to code auditing in any of my previous roles, but I know enough by rubbing shoulders to know when I should be nervous. As I look around the Open Source Health Software arena, there is a lot to be nervous about. There are also upsides. Our community has embraced at least two other serious security people. Alesha Adamson with MOSS was trained as a security geek at one of the few NSA National Centers of Academic Excellence and Ben Adida with Indivo X has a PhD from MIT, under the Cryptography and Information Security group

Both of these people are fully cognizant of security research and they are in leadership roles in their respective projects, and in the community as a whole But is it important that the whole community learn from their strong kung-fu. We need to develop a kind of security focused sub-group within the Open Source health information movement. We need people willing to do security audits on not one but several important Open Source codebases. Perhaps we should be trying to get members of the larger security community involved with Open Source healthcare software auditing. I will be thinking more about this, but I would love to hear my readers thoughts on the subject.

-FT

Basically a bad deal

Emma Schwartz is an serious investigative reporter who now works for the Huffington Post

She has taken an interest in covering Electronic Healh Record issues and has started to reveal just how problematic this industry is.

Her most recent article, Doctors Get Buyers Remorse, is her best yet. She has uncovered not one but several of the kinds of stories that industry insiders like me view as typical. This may not be as glamours as uncovering that big story about the congressman paying his mistress…. but this is exactly the kind of documentation that people like me need when we claim that basically the proprietary EHR industry is broken.

I love it.

-FT

Hello World with Indivo X

Ben Adida the project manager for the Indivo X project has announced the first public code drop of Indivo X on the Indivo developers mailing list, two days ago. Since then I have been spinning up a Rackspace Cloud instance to see if I could get it up and running.

I do not yet have write access to the wiki to make notes, but I documented all of the issues I had using Sidewiki so if you want to use an identical setup, I might save you an hour or so. Frankly, most of the hiccups I have are due to fact that I am most comfortable using PHP/MySQL/RedHat rather than the Ubuntu/Python/PostgreSQL setup used by Indivo X. After clearing some mental cobwebs, I had my own Indivo X PHR Platform installed and running..

Here is the obligatory screenshot, sanitized for spammers…

Screenshot of the alpha release of Indivo X
Screenshot of the alpha release of Indivo X

Of course, there are no applications to install yet, so “get more apps” does nothing. But the basic Indivo X platform is available, and will be going through the standard alpha/beta/1.0 process over the next few weeks/months.

Why this matters

Eventually there will be a dominant health platform upon which most personal health applications will be built. These are the applications that patients will use directly as health consumers.

This is the core enabler for the e-patient, it is at the heart of “Health 2.0”

It is the PHR or Personal Health Record. This health records of the future will be massively connected, like the Internet today, and the same way each of us has a primary email address, where our email records all end up, in the future we will all have Personal Health Records. Just like there is a competition between email providers, there will be a competition between PHR platforms. For many years, you can count on it being pretty difficult to move between these platforms however, alot more like getting a Mac to talk to a PC and vice-versa, than moving your email provider.

The dominant platform might be Google Health, HealthVault, or some kind of layer on the Health Internet (perhaps a spin-off from the Mirth or CONNECT projects)

However, my money is on Indivo X.

Indivo X is the newest PHR Platform engine developed jointly by Harvard Medical School Children’s Hospital Informatics Program and Intelligent Health Lab. Indivo X is a complete reimagining of the original Indivo PHR, which was already one of the most successful Open Source PHR applications available. It was the codebase behind Dossia, which is one of the three “big” PHR deployments (the others are Google Health and HealthVault). Indivo X comes from impeccable stock.

Indivo X is dramatically different the original Indivo project in several important ways. First it is entirely rebuilt using the Python Django + PostgreSQL stack. Second it has been redesigned to be a PHR-platform, PHR functionality in Indivo X will be provided by modular applications, applications that could even be hosted on other computers. Indivo X is designed to create a market for PHR sub-applications using unifying PHR data abstractions provided by Indivo X. The notion for Indivo X is almost entirely based on the notions first outlined in now-famous NEJM article. I had criticized the article because it does not fully consider the implications of the proprietary trap for health software. However, this release renders most of my comments moot. These guys are trying to strike a balance between a stable platform and respecting software freedom and doing a more than decent job of it.

They have invited me to code on their development server, which has been up for a while, but I have very limited time due to my own skunkworks project (love a secret….) , and I can only afford to contribute when I can see both ends of the code. Still my skunksworks application will be consumer facing health application (Open Source eventually… of course) that is suitable to interface with HealthVault, Google Health and of course Indivo X. Given my feelings on software freedom, you can bet which one I plan on integrating with first….

An alpha code drop is a big day for any project and I know that the Indivo team has been working hard on this for months now. Congratulations are in order.

-FT

OpenMRS shines in Haiti

I am utterly not surprised to hear that OpenMRS is shining in Haiti.

This reminds me of the tremendous reponse that the VA had to hurricane katrina using VistA. For fun you should ask those involved for the inside scoop of how VistA enabled an entire hospital to uproot and move over the course of a single week.

Sometimes people do not really understand why we need software freedom in healthcare. These are two perfect examples.

Can you imagine the headache that per-seat or per-doc or per-patient EHR licenses would have caused in -any- haiti clinic? Of course they could always -ask- the vendor for temporary seat licenses, and because the vendors are decent human beings they would probably give them to them. Of course that only works when the phones work or the Internet is up.

Emergencies highlight the fact that health software users may have -very- different needs than the software vendor’s vision or even their own understanding. I know that the OpenMRS project will change substancially in response to the earthquake in Haiti. More importantly those changes will spread to other areas of the world… but those other users of OpenMRS will get the haiti lessons -before- the mudslide/tsunami/earthquake/bombing happens in their area.

In fact I can just imagine and administrator setting up OpenMRS for the first time and wondering “Hmm why would you ever need that???” and ten years later, when those features make OpenMRS better able to handle a disaster in that area, the same administrator will say “Ohhh… that’s why….”

Everytime I hear about something like this from the OpenMRS project I feel again guilty that I am not more involved….

-FT

VistA License debate: its about proprietarization

It looks like WorldVistA is, for now, holding fast to the GPL and AGPL for VistA licensing. I have been a vocal advocate for compromising with DSS and Open Health Tools around the LGPL. The LGPL would allow for some innovations to be licensed under the GPL, and others, in the core of VistA to be compatible to bundle with proprietary software.

Recently, Skip McGaughey was quoted in modernhealthcare as saying:

“I believe it’s all about community-building,” McGaughey said. “I believe people have focused too much on technology and licenses and they need to focus on the care of individuals. If we can switch the focus from licensing and technology—the VistA community has a tremendous opportunity to fundamentally alter care throughout the world.”

“They’re starting from a base that has a tremendous knowledge base, built by care providers, tested and modified over a long period of time,” McGaughey said. “So, the opportunity is tremendous. So what we have to do is change the focus and quit worrying about the individual ‘me’ and talk about the ‘we’ together,” he said.

“If we enable an environment for people to collaborate in building infrastructure that everybody can use, to share the expense, what we can do is build the integration and interoperability and build a collaborative spirit,” McGaughey said. “Then people can climb the value stack to provide added value that can make money.”

It should be noted that I was not at the talk and did not hear exactly what Skip said. I know Skip and I know that he is a good guy, I think he intended to bring a message of reconciliation regarding licensing which is very good.  I may actually agree with Skip’s position, but I cannot agree with this quote. While I am in favor of compromising with Open Health Tools, the position of WorldVistA on insisting on the full GPL is not unreasonable and it is certainly not anti-people.

Lets be clear, when you talk about proprietary friendly licenses in medicine, you are not talking about a way for people to “make money” or “earn a living”, you are talking about a mechanism that traps software consumers into a monopoly relationship with a software provider.  Proprietary software in healthcare is so famous for abusing this monopoly position to the detriment of its clients that the issue is being investigated by congress and is even the subject of in-depth lampooning.

To trivialize licensing and indicate that is about “people” is typical and insincere. The software license defines the basic power structure of a relationship between software developer and software consumer. Full copyleft ensures that the developer and the consumer are always equals. Proprietary licenses ensure that the software vendor is in control. Open Source licenses that allow for proprietarization are a grey area. If software consumers are careful only to use Open Source components, they can maintain a balance of power, but if they ever allow a proprietary module into their ecosystem, then the license for that module puts some vendor back in the drivers seat.

If there was an “open” movement in the prisons around the world so that all prisoners were limited to just one shackle, they would still remain prisoners. Similarly as long as one software vendor can dictate terms to a clinic or hospital, they have a problem. Proprietary vendors who do not abuse their clients are like kind wardens. Just because they are nice a prisoner, does not change the fundamental power dynamic in the relationship.

The LGPL is a compromise precisely because it allows people who value freedom to work with people who are willing to compromise with proprietary vendors.

When you start hearing people saying things like “value stack” and “let people make money”, you are hearing the argument that being trapped is sometimes OK, if what you get for it is worth it.

This kind of power dynamic is precisely what prevents communities from trusting each other and cooperating. If you want to create community, you better not ignore licensing concerns.

-FT

MOSS crosses the threshold

MOSS has successfully tested the IHE profiles, all available under Open Source licenses.

I know for a fact that the MOSS team has been working on this for years. Completing these tests, and making sure they actually work at a Connectathon takes months of preparation and several frantic days of performance. In this respect, the Connecathon is something like a professional sporting event, one where you win by cooperating instead of competing.

This is an extremely impressive achievement and the MOSS team deserves applause. Because they are releasing most of these components as FOSS, the whole world is richer for their achievement!

-FT

Updated 2-21-09

Some have pointed out that not all of the Misys HIE tools are open source. This is quite true and I have updated the post to reflect that. MOSS makes no bones about being a hybrid proprietary/open source company.  I am sorry that I gave an impression to the contrary.

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