VistA Custodial Agent Launches, and it doesn’t suck (much)

[Update 2011-10-19 Many of the issues here applied only to the initial launch of OSEHRA and began to be addressed almost immediately. Do not assume everything you read below still applies]

As typical, I was alerted to the fact that Tiag, the winner of the Open Source VistA custodial agent competition, has launched a website and new non-profit foundation called Open Source Electronic Health Record Agent (osehra.org)

The good news? The site, and the foundation both seem to be moving in the right directions. The site appears to be using a Drupal backend, which is a reasonable choice. The foundation has made pretty strong technology and licensing initial positions and those initial positions are not stupid. They have done -some- stupid things, but for the most part these appear to mostly be relatively minor errors that hopefully can be fixed.

Strongly pushing the Apache License

Something that OSEHRA is doing right is to strongly push the Apache 2.0 license, without insisting on it. The whole licensing document makes a compelling case for Apache, and for the right reasons. Apache has a reputation as strong non-copyleft Open Source license because it is GPLv3 compatible, it is more explicit, and handles patent issues well. It is a strong license and almost every informed person I know in the Health IT community prefers it when non-copyleft is required (which it obviously is in this case). But they consider their licensing document in draft, which I assume they leave some room for debate on the subject.

Strongly pushing git

Another smart thing they have done is to setup a git repository. VistA, in order to survive, must have a strongly distributed version control system. Git is by far the best option for this, given how much it has pulled ahead of the other Open Source distributed version control systems. Git has some fundemental advantages for projects that are as large and expansive as the Linux Kernel, and VistA is just such a project. OSEHRA has nothing in their VistA git repository so far, but they fact that they already have a repository is a very strong move.

I seriously doubt that many of the TIAG contractors actually understand how difficult running any kind of software version control system is for VistA. To actually pull it off, it is likely that someone is either going to have to build some KIDS-to-git software bridges and/or develop some very methodical development processes that allow an individual instance of VistA, in a KIDS environment, to function. It is hard to know if TIAG is being smart here or just really lucky. We may never know unless Joseph Conn’s FOIA requests efforts reveal more from their initial proposal. (BTW, given that the VA is stonewalling it would be smart for TIAG just to hand over their proposal to Conn, for the sake of transparency).

OSEHRA is putting all of its chips on long term VistA-git compability. Specifically, their testing and certification strategy centers on using Gerrit, (a git-based source-code review tool) to ensure that new contributions to VistA are safe and compliant. It is unclear to me how this system squares off against the KIDS-based Class I, Class II and Class III software evaluation and deployment system that the VA currently employs.

Perhaps Tiag is lucky to choose git, perhaps they are smart to chose git. Either way, I’ll take it. Git is one of very few systems that has the brawn to potentially solve the most vexing KIDS-vs-VCS problems. It is a smart choice. Pretty much the only choice that might have been stronger would have been to endorse Medsphere’s preexisting work on bazaar. Since the decision by Medsphere to back bazaar, git and mercurial have surged ahead as more popular distributed version control systems. Specifically the git community, centered around github, has become the standard for enabling Open Source development. Take a read on the short whitepaper covering the OSEHRA repository strategy. It is obvious that Tiag gets the potential of Git, but it is difficult to see if they fully understand the complexities in existing in the nexus of git+KIDS+GTM+Intersystems as technology stacks. Still, who gives a damn if they understand what they are getting themselves into if they are still taking the right strategy? There really is no other rational way forward in this technology issue. I am pretty happy about this.

Long-term the foundation board is community elected

According to my initial skim of the current OSEHRA by-laws, the DOD and the VA, along with Tiag, initially appointed three board members. However, when the term of these board members expire, they will be re-elected by the membership. I would love it if someone with either some legal expertise and/or more free time can read the by-laws carefully and see if my understanding on this is correct.

If it is, then there is a basic mechanism in place for OSEHRA to actually represent the community, something that has been missing in WorldVistA for years. This is pretty good news.

NDA in the Membership Agreement

The largest of these is the Membership agreement. At this time, no Open Source developer or company should consider joining the OSEHRA organization, or even register for the website. The current OSEHRA membership agreement contains a tremendously broad non-disclousure agreement. Here it is:

Confidentiality.  Member acknowledges and agrees that all information disclosed by such Member or received by such Member relating to the Corporation, including information discussed in any meetings of the Corporation, shall be presumed to be confidential (the “Confidential Information”) unless otherwise stated by the disclosing party.  Member hereby agrees to keep the Confidential Information confidential and not disclose the Confidential Information to any party other than its Representatives, whom it will cause to observe the terms of this Agreement, using the same degree of care that it exercises with respect to its own information of like importance but in no event less than reasonable care.  Confidential Information does not include information which:  (a) is rightfully obtained by a recipient Member without breach of any obligation to maintain its confidentiality; (b) is or becomes known to the public through no act or omission of the recipient Member; (c) the recipient Member develops independently without using Confidential Information of the Corporation or any other Member; (d) is disclosed in response to a valid court or governmental order, if the recipient Member has given the disclosing party prior written notice and provides reasonable assistance so as to afford it the opportunity to object; (e) information that is known to the receiving Member prior to disclosure by the disclosing party; (f) information that is approved for release in advance by written authorization of the disclosing party; or (g) information that is rightfully disclosed to the receiving Member by a third party not bound by a confidentiality restriction.  Member understands that the Corporation does not contemplate the exchange of competitively sensitive information.

No Open Source software developer I know would be willing to agree to this. It basically allows other ‘Members’ of the corporation to limit what can be coded by simply communicating ideas through OSEHRA. The agreement presumes that information from the OSEHRA is confidential -by default- which is so deeply contrary to the values of Open Source it is not funny. As an Open Source developer, whenever someone starts to tellme “This is confidential information…” I stop them immediately and tell them not to tell me any more. The only reason that I do not consider this a big deal is that it is obvious that OSEHRA simply did not think this through and allowed boiler-plate legalize to slip into its document process. They will fix this because, I, and countless other Open Source developers will not be able to participate under these terms. I know this because the other important document that they have created is their draft Software Licensing document. In that document they get the basic idea of openness right.

Non-disclouser agreements, like the one in the paragraph above, serve to create fodder for “trade secret” litigation.  Trade secrets are a mirky aspect of “intellectual property” law (I use the term ironically), because in order to have an action under trade secrets law, you need to basically show that you were keeping a secret, and someone else did something wrong in obtaining and taking advantage of that secret. (IANAL, but this is not just my understanding). Non-disclosure agreements are a big part of the process for ‘protecting’ trade secrets. Trade secrets have little use in the Open Source community, and elsewhere OSEHRA recognizes this. From its consideration of “intellectual property” law in the draft software licensing agreement:

The final bullet point, trade secrets, is mostly irrelevant and not applicable in the context of open source projects given that openness and transparency are some of the required characteristics of open source and are enforced by the best practices. We exclude trade secrets for the subsequent discussion in this document.

Obviously, the fact that the membership agreement at OSEHRA fundamentally endorses and protects trade secrets, which they know is not a part of the Open Source ethos must simply be an example of the left hand not knowing what the right hand is doing.

Still, no Open Source developer or company should consider joining OSEHRA while the click-through membership agreement contains these terms.

Commercial vs Proprietary

A pet peeve of those of us who make a living writing and supporting Open Source software is when people say “Commercial” when they mean “Proprietary”. The word “commercial” simple implies that someone is being paid for working on software and implies a certain amount of professionalism. There are plenty of commercial Open Source companies out there. Red Hat is a great example of a general commercial Open Source company, and Medsphere certainly considers itself a commercial Open Source Health IT company.

Sometimes, OSEHRA uses “commercial” correctly, referring to both proprietary and Open Source individuals and companies:

In the context of open source software development, it is very important to prevent patented methods from being implemented into the code, given that they restrict the use of the software and undermine the emergence of a commercial marketplace in the ecosystem. Patents undermine the environment of trust that is required for a collaborative ecosystem to be successful. Commercial companies will be unlikely to invest and build upon the common resources of the ecosystem if there is a suspicion that this will result later in costly patent litigation.

underlines are mine. This use of “commercial” is appropriate. But the following one is not.

The OSEHRA should not adopt GPL, a restrictive “free (libre) software” license that limits commercial interests.

This is a false statement. Red Hat lives and dies by the GPL in the Linux kernel. It is a commercial enterprise. What the GPL limits is “Proprietary business models”. It means that commercial companies have to share improvements. The GPL aligns corporate “interests” with community interests. It is not the “commercialness” of companies that is limited by the GPL, it is their “proprietary-ness”. This problem becomes more apparent with:

The OSEHRA will continuously encourage members of the ecosystem, both commercial and non-commercial, to contribute back to the code base any improvements and modifications that they made to the code.

There will be almost no “non-commercial” members of the eco-system. There will, however, be a continuing debate between proprietary vendors, hybrid proprietary/Open Source vendors, and fully Open Source vendors. Labeling this as a distinction between “those who which to make money and those who do not” is to be intellectually dishonest about the core debate.

Any frequent reader will know that I favor Open Source processes and copyleft licenses. But the argument against my positions is legitimate: proprietary software licenses can help ensure that developers are paid fairly for their work and contribute to long term sustainability of software development. I get that. I wish there was a way to ensure that developers could more safely invest in Open Source code development, and I have been financially taken advantage of by free-loaders in the Open Source community more than once. I have the intellectual honesty to admit that there is a real-debate here, with valid points on both sides. But the divide is Open Source vs. Proprietary and not Open Source vs. Commercial, or Non-Commercial vs. Commercial.

This is insulting terminology, that artificially endorses the positions taken by proprietary vendors and glosses over the consequences of their positions. (i.e. the word proprietary gives some hint about the tremendous amount of control that a proprietary vendor holds over a user, whereas ‘commercial’ gives no such hints).

Ambiguous Ethics Terms

I have a degree in Philosophy and a minor obsession with ethics. I call people out in the Health IT frequently and, some might say, harshly.

I am convinced that discrediting those who deserve to be discredited is an important part of what it means to be ethical in Health IT.

But the OSEHRA Code of Conduct says:

Working to instill public and consumer confidence relating to electronic medical records, its member companies, and its professionals, avoiding any action conducive to discrediting members of OSEHRA, Inc.

Being a member of OSEHRA will never exempt some from a need to be “discredited”. Hell I am not sure I could even define what “discredited” means here, but I am pretty sure if I feel that someone who happens to join OSEHRA deserves to be discredited, that OSEHRA should not have anything to say about that. For instance, would this famous post from ONC regarding the use of the term EHR over the term EMR serve to “discredit” EMR technology? This is the only place that I can find on the OSEHRA website where the term ‘electronic medical record’ is preferred over ‘electronic health record’. Would ONC qualify for OSEHRA membership?

I am also unsure of how scheduling an untimely party could be unethical:

Refraining from scheduling general attendance meetings, receptions or other events at times that conflict with substantive programming or social events at OSEHRA, Inc. meetings without the express prior written permission of OSEHRA, Inc.

This raises the strange possibility that I might use my deeply nuanced understanding of the basic motivation constructs of Open Source software developers (they like free beer) to create an alternative social event (free beer party) that would compete with “substantive programming” (a boring meeting) that would put me in violation of the “ethics” of OSEHRA. Seriously?

Again, I think this is an example of boiler plate language slipping through without careful examination.

Every Open Source project has unwritten policies regarding basic courtesy among software developers. Generally, it is frowned upon to criticize individuals directly, but ideas can and are frequently judges very harshly. When a person strongly associates with a bad idea they can expect some unkind words. But these unkind words always focus on the quality of the ideas.

Any Open Source community code of conduct is either a paper tiger or has some acknowledgement that heated technology discussions are the norm in the Open Source world.

No automated document forge

Putting aside the complexities of git+KIDS, software development is not the most important set of tasks facing OSEHRA.

OSEHRA is intended to be the middle man on a lot of really thorny policy and governance issues. The documents that they have created, including their white-papers, and corporate documents are far more important than any software issues they might attempt to address at this stage. But OSEHRA is not yet using an effective document forging process.

There is an art to Open Source document forging, and everyone is familiar with the wiki concept. But wikis are not  ideal for gathering commentary on formal documents. Community commenting was advanced most substantially by stet, which was used to enable thousands of comments on specific sections of the GPLv3. Stet is a dead project but the heir apparent is a project and service called c0-ment. Co-ment enables a community to build consensus around the contents of a document in the same way that a bug reporting engine allows the Open Source community to improve code. All of the documents that OSEHRA is developing, and even those that it considers “done” should be submitted to a community comment process enabled by co-ment or software like it.

Apparently, lots of people read this blog. I have the server logs to prove it. I even had Roger Baker comment on my last blog post on Tiag. I remain surprised by things like that, since I write primarily about things that amuse me in ways that amuses me. I always assume that my readership is limited to other geeky ideological information revolutionaries like myself. But apparently, important decision makers and thought leaders are reading this (Hi Allison).

Which is a problem, it means that my voice, as an abnormally high-profile hacker/blogger is automatically weighed higher than others in my community. In fact, my proclivity to spend hours typing up an analysis like this makes me a worse technologist, not a better one. It is critically important that OSEHRA develop processes that embrace the insights of my community who constantly prefer hacking over writing. They need to hear from the guy who is going to read this article and then spend the next 4 hours hacking to see if he can write a working KIDS-to-git translation script. Systems like co-ment dramatically lower the barrier for developers like that to participate in a document creation process. They do not have much time to contribute to commenting on governance issues, but if the OSEHRA governance process does not work for these hard-core developers, then it will cripple OSEHRA in the long term.

Overall

I am very pleased with the first pass that OSEHRA and Tiag have taken here. They are making some smart moves and most of the mistakes that I point out here are minor infractions that can either be quickly fixed (the NDA problem) or do not matter that much (the code of ethics issues).

OSEHRA