A truly open VistA | Opensource.com

A truly open VistA

Image by : 

opensource.com

The VA has released a draft RFP to create a new open source project around their electronic health record system, VistA. This is a landmark event for both the VA and the open source community. The need for cheap and robust EHR systems is clear, and the VA has one of the leading platforms.

VistA’s a challenge, though. The community is notoriously fragmented as a result of

regular FOIA requests for the VistA source code. The project is based on MUMPS, which a relatively unpopular platform, so developers for VistA are in short supply. Since there’s no clear mainstream for the project, the VA VistA project competes against this fragmented community for a shallow pool of developer talent. There’s the for-profit Medsphere, which has built its own offering called OpenVistA. There’s also the WorldVistA community and http://www.hardhats.org/. FOIA requests for VistA source code are so common that VistA appears on VA’s FOIA FAQ page, but few (if any) of the contributions from any private-sector VistA communities feed back into the VA VistA project.

"VA believes that VistA’s rate of innovation and improvement has slowed substantially, and the codebase is unnecessarily isolated from private sector components, technology, and outcome-improving impact. To address this issue, VA is establishing a mechanism that will open the aperture to broader-based public and private sector contributions."

This RFP changes the VA’s game profoundly. They’ll create an independent body, the “Custodial Authority”, to hold the VA’s VistA code. The CA will then act as a kind of coordinator and authority for the project, allowing anyone to submit improvements which are “certified” by the CA and fed to downstream projects, like VA’s VistA and (presumably) projects like OpenVistA and WorldVistA.

This is a worst-case scenario for government-sponsored open source projects. The technology is obscure, the internal community of developers is likely anxious about opening their code to outsiders, and the external communities will go out of their way to protect the businesses they’ve fought so hard to create. This makes VistA a fascinating case study for creating open source projects from inside government.

Convincing these communities to come together will take a lot of courage. It’s as much about political will and persuasion as it is technical hurdles. This CA model is a clear attempt by the VA to balance control and predictability with agility and innovation.

It's obvious from the goals and incredibly aggressive timeline for the project that the VA is in a hurry to build from scratch the kind of community that usually grows organically over time. The open source approach here is similar to the pattern of letting pathways across a common greenspace form by the humans living there rather than the hands of an architect. It's easy to see what works in existing open source communities, but applying this brand-new way of working on to an existing community of developers, vendors, and system integrators will be a different story.

This is most obvious in the RFP’s notion of “certification” for new ideas, which makes it more difficult for developers to participate. The CA clearly wants to attract developers, but at the same time will have to provide assurances to its internal customers that this newly open code is stable and thoroughly reviewed. That's not uncommon in open source projects, but if building community around this code is a goal, a rigorous certification will make this much harder. A successful certification regime relies on the Authority having a natural... well, authority. This comes from unambiguous and transparent rules that have the community's consent. Given the diversity of this particular community, consensus will be difficult. There's also the matter of procedural friction: certification could be a huge bottleneck, since a finite QA staff must review a potentially unlimited amount of community input. Of course, the certification could just mean plain-old open source patch review. However this shakes out, it will be an interesting study in the tension between control and collaboration that will always exist in government-sponsored open source projects.

A diagram of the VistA Certification Workflow

Strangely, the VA seems to be planning for certified code that doesn't go into the upstream repository. The use case for this isn't clear, if the goal is to pull the disparate VistA communities into the fold. If the CA is busy certifying code that won't end up in the upstream, that's a lot of overhead with no clear benefit. We suspect that we just misunderstand the intent here.

We're also unsure of the stated goal of creating "a custodial agent based on well-understood open source business models." Is it telling that they are focusing on establishing a business model instead of creating an open source community that can be the wellspring for many business models? It's difficult to discern community goals for participants who are outside of the recognized pool of system integrators, vendors, and academia. Is there room in the vision for the users, such as health care providers, to participate in improving the upstream? Is the barrier low enough for them to succeed?

We don’t want to leave the impression that this RFP is flawed. We think it’s an excellent model for future agency open source projects, and it's clear significant and smart thinking went in to this. The VA has avoided a number of common mistakes in community-building. They’ve gone out of their way to socialize this change with the internal and external communities. You can see evidence of this on the Medsphere Community site, which has an excellent tick-tock account of the initiative. They also recognize that it needs a neutral third party, in this case the CA, to act as the catalyst for all these competing interests. Even though the implementation doesn't seem quite right, they're clearly making an effort to invite amateur participation, rather than restricting control to a handful of incumbent developers. In this plan, you can see aspects of the Eclipse, Apache, and Fedora models for governance, with a government twist.

This may be the largest single code-drop in the history of the US government. That makes it significant to open source in general, not just the VA. It’s in our best interest to make sure this effort succeeds. So what else have we missed? Is this plan workable, or is it profoundly flawed?

[This article was co-authored by Gunnar Hellekson and Karsten Wade.]

Topics

About the author

Gunnar Hellekson - I'm the Chief Strategist for Red Hat's US Public Sector group, where I work with systems integrators and government agencies to encourage the use of open source software in government.