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

Practical collaborative document writing for patient communities

Hi,

I have a lot of experience with collaborative document writing, and now, in my role with Cautious Patient Foundation, I have been providing technical help to several patient communities. I helped write the security standards for the NWHIN Direct project and I am currently working with the e-patient/QS community to create a document detailing Doctor friendly Quants and Quant friendly Doctors.

My advice is pretty simple:

  • Use a forum, either a facebook thread or a mailing list to determine who the primary authors should be, and what the general content of the document should be.
  • If you have several authors, use Google Docs or a Wiki for initial document creation. If you are writing alone, use whatever you want as your initial author tool.
  • Once you and your co-authors feel OK about the resulting document, copy it over to co-ment.com, and allow your entire community to comment on it. (For Geeks: Co-ment is the successor to the stet project which was used to coordinate comments on the GPLv3.) There is a free version of co-ment but the service is cheap and probably worth it. It allows a community to comment on specific parts of a document, and it will automatically generate a “heat-map” of the more controversial parts of the document.  These are the areas that you will need to spend time with, ensuring that you have blessing of your community.
  • When the comments stop coming in, the document is done.
  • Keep your document as short and concise as possible. All of us operating in the various patient communities are short on time, and by keeping what you are asking us to read short, you are respecting that.

The insight here is that while a wiki makes it easy to update and maintain documents, they are not always the right tool for building consensus in a community. What you want is to have your documents reflect the will of your community at large, rather than the will of the most obsessive wiki-editor in your community.

Hope this helps.

-FT

Using HTML5 as the basis for HL7 CDA v3

Keith Boone, well known and liked Health IT standards geek has written up a proposal that would make the next release of HL7 CDA based on HTML5 rather than XHTML.

I have just become more deeply familiar with this set of standards as the result of the extensive research I have done on my new book on meaningful use  of Health IT.

I can say, without a moment of hesitation, that this is a really good idea.

Everyone should support this proposal, b/c otherwise, CDA is a huge mess.

Which is not to say that an HTML5 version would not also be a huge mess. But I believe that it would be less of one.

-FT

Unethical Blue Button Contest

This contest is deeply problematic.

The blue button initiative was a good initiative because it allowed greater access. It made that possible by ensuring that access to patient data did not have to wait for the VA/DOD/Whatever to create a download that conformed to the still-forming XML standards that make true interoperability possible.

But now the VA is promoting the Blue Button format as something that should be integrated into other EHR systems. That is unacceptable.

Meaningful use requries that doctors allow patients access to their health record summaries using CCR or CCD. Both of those standards can easily be translated to printable reports that are very readable. Meaningful use -also- requires that patients be provided a summary in a printed form. The simplest way to do this is just to have onsite printing of the CCR or CCD reports.

Blue Button data format is not as readable as a summary printout, and is not as parseable as XML. It is the worst compromise between human and computer readability. No clinician should ever make a clinical decision based on the content of a Blue Button download. The data is simply not rich enough to transfer into another health record or PHR. Essentially that makes the blue-button data format standard an FYI-only use case.

The innovation of Blue Button is to not let standards compliance get in the way of access. For this reason the DOD and the VA use of the Blue Button format should be applauded! The Blue Button initiative was fully give-me-my-damn-data compliant! But promoting it as an alternative process to a process that supports fundamental data reuse and is -already- required by meaningful use is unethical.

I formally request that the VA withdraw this contest, or make it clear that a CCR/CCD/printable report download meets the requirements of the contest.

Either you are promoting the notion of patient access, which is wonderful, or you are promoting shitty health data standards, which is unethical.

Cross posted on the VA challenge forums here.

Here is the example of the file format in question.

-FT

QR code stencil upmanship

As far as I know, I was the first person to publish a generalizable method for creating a QR code stencil or to even clearly document why such a method was difficult.

However, since that time, I have realized that other approaches would ultimately be superior. The two I have been pursuing are automated embroidery of qr codes and improved stencils using laser cutting or 3d printing.

I will likely be abandoning the latter work, now that my early attempts have been eclipsed by Golan Levin at the Studio for Creative Inquiry at Carnegie Mellon. This work is being released from fffff.at, whose motto is: release early, often and with rap music.

Here is a link to his post on his new laser-cutter QR code stencil generation code. Along with his first application, a remake of hobo-coding.

Golan gave me a shout-out on the post he made. In some ways, it is hardly justified, since his method obviously surpasses my chicken-wire method in several ways. In fact, the only outstanding benefit to my method now is that it is much cheaper, and you do not need access to a laser cutter. The codes generated from his method are cleaner, and could probably be made smaller than my methods, and do not require an hour of working with caulk.

In a private email, he mentioned the possibility of a githib release soon…

In any case, take a look at the wonderful photos of the stencil in action.

WorldVista Meaningful Use Certified

Not sure why this was not formally annouced, but I was just doing some last minute fact-checking on my new health IT book, and I discovered that WorldVista EHR is a meaningful use certified product.

This is quite an accomplishment, and I am somewhat surprised that WorldVistA has not had an announcement about this. This is really important news and have broad implications. WorldVistA, unlike ClearHealth and Medsphere, is a non-profit organization.

Medsphere and ClearHealth provide only “pro” customers with the benifit of certification. How will WorldVistA handle this?

It is not clear to me if this could be the first completely available (sans proprietary ontologies of course) meaningful use certified Open Source EHR that you do not have to pay for support for. To make an analogy its like the difference between Fedora getting a certification vs RedHat Enterprise Linux getting a certification. Both are Open Source, but the latter is expensive

The other Open Source options as I understand them:

Tolven is partially certified as is OpenEMR.

ClearHealth was the first to be fully certified, and Medsphere also has a fully certified product.

Sharks, Bees and Privacy

Hi,

I am happy to announce that my new article on healthcare privacy and interoperability has been accepted in the Journal of Participatory Medicine.

I am not against privacy in healthcare, but I am against the notion that privacy concerns should trump issues relating to good healthcare.

You can read the full article here:

http://www.jopm.org/opinion/commentary/2011/07/05/sharks-bees-and-health-privacy-paranoia/

-FT

Google Health: influential, controversial and gone.

Google Health is no more.

Thats a shame, because I am writing a book on Health IT for O’Reilly and before this announcement, my rough draft featured Google Health extensively.

I guess this is better, though, than having Google Health shut down just -after- I finished writing my book.

Of course, I am going to have to change lots of content in the book, but Google Health will still be there.

For a project that no longer exists, it will end up being one of the most influential Health IT projects of our era. Google Health, and for that matter Google generally, has always been willing to make strong statements when they evaluate technology and technology protocols. In fact, Google has made two controversial technology picks and the opening and closing of Google Health.

At the opening Google decided that they would support CCR (Continuity of Care Record) from ASTM and AFFP rather than the much more complex CDA/CCD from HL7. The CCR vs CCD debate has been one of the most controversial and long-standing arguments in Health IT. HealthVault, the Microsoft product which survives Google Health has always elected to support both standards. But Google insisted that the CCD standard was too complex, and not only insisted on CCR, but a smaller subset of that standard.

Now, as the end support for Google Health, Google is choosing to allow export under the Direct Protocol. Again this is the simpler of the two protocols that is supported by ONC to be part of the NWHIN (the precursor to the Health Internet). The other protocol, IHE, is getting no love from Google Health.

Goodbye Google Health, whatever else I may have said about you, I must admit that you made some ballsy technical stands.

-FT