You might be a cyborg….

People often do not get why I am so convinced that only GPL Software should be used in Medicine. I can understand why. Without understanding the nature of Healthcare, people assume that I am being religious about the issue. This is the furthest thing from the truth.

It has been a while since I have blogged over at In fact you can see that I still have some site maintenance to do. But recently more attention has been given to the issue of Open Source and Software Freedom in medicine.

The Software Freedom Law Center has just released a paper called Killed by Code: Software Transparency in Implantable Medical Devices

Awesome title. Even more awesome paper.

The form of the argument is so simple:

  1. Hey you are putting hardware AND software in my body? yep.
  2. I cannot look at the software? nope.
  3. And the software is hackable? yep.
  4. Well that kinda sucks.

Feels kinda icky don’t it?

One thing I love about people with pacemakers or other implantable medical devices, is that they know they are cyborgs. Most people living in modern countries are cyborgs, but unlike people with pacemakers, they do not see it that way, because they carry their electronics, rather than implanting them. Makes no difference. In fact lets play a variant of “You might be a redneck“: I call it “You might be a cyborg..”;

  • If you leave your cell phone at home, and you -must- to leave work to go home and get it, you might be a cyborg.
  • If you will sleep through the morning unless a machine wakes you up, you might be a cyborg.
  • If your spouse is jealous of your cell phone, tablet, laptop, server or workstation, you might be a cyborg
  • If not wearing a watch makes you uneasy, you might be a cyborg
  • If you view any relationship you have with an online service as an addiction, you might be a cyborg
  • If you try to avoid walking more than 100ft in favor of a segway, bicycle, golf cart, or automobile, you might be a cyborg
  • If you try to avoid walking more than 100ft in favor of a lawn mower, you might be a cyborg and a redneck

Our relationship with technology is becoming more and more personal, and the operating system to your mobile phone, the software your medical devices uses and the EHR system that your doctor uses to track your health information make software freedom ethical issues into personal freedom ethical issues.

Today, its people with pacemakers, but tomorrow, there will things that people consider normal to do with their own bodies that will either use software that the user controls, or software that some random company controls.

Thanks to the Software Freedom Law Center, for helping to make this issue more personal.


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.


Enabling open core

What license should you consider for your new Health IT platform? As you consider that, you should think carefully about your user audience. You want people in the Open Source community to develop against your code. You want people to add value to your core. To achieve this you have to recognize that our community does not share universal motivations. The most important detail that you need to understand about our community is the ways in which we we relate to proprietary software.

There are two general ways of thinking about how to relate to proprietary software within the FOSS movement.

There are those that believe that the most important potential feature in software is the ability to change and share it without restriction, which is software freedom.

Others in the FOSS community feel that the important issue is that we have a good method for collaboratively developing good software and if people want to make money selling software that restricts freedom (the definition of proprietary software) thats fine.

I am solidly in the first camp. However, for the purposes of this article I will treat them as equally valid perspectives. This respect for an opposing opinion is crucial for the FOSS community because we want to be able to develop software together!

People in the first group we might call freedom sticklers and the second group we will call pragmatic openers.

Before we move on we should discuss the basics of licensing. I have written on licensing before, but you will find my freedom stickler bias in those writings. I will try to avoid that here.

The most important thing to understand about licensing (for this discussion) is to consider the perspective of the person who accepts a license with the intention of redistributing the sourcecode with other software.

Imaging that Ozzie the Originator released some valuable software called coreware. He decides to release the code as open source! He must consider several perspectives as he chooses a license.

Freedom loving Fredi 😉 wants to ensure that whenever possible software that he writes will not be used to allow someone to control another person. Fredi appreciates the value of coreware and writes a module for it called Fredis freely scanning module.

However Proprietary Pat also has scanning application that has far more functionality than Fredis module. She likes the idea of open source but, for whatever reason, is not in a position to release her own software under a FOSS license. It is important to note that if Pat did not have a functionally better scanning module than Fredi, there would be no reason for Ozzie to consider her interests. Ozzie knows that when an open option is available, functional and stable end users will always prefer it. This can be called the Open Source Sets the Floor effect.

Pat has software patents and proprietary software that she feels must be protected from the full GPL (a license popular with Fredi and his ilk). Certain provisions of the GPL can have the effect of devaluing software patents, or at least that is how patent owners often feel about it.

Then there is Indifferent Ingride who writes a printing application. She has no specific position on proprietary vs. FOSS. She just wants her printing software to be as useful to as many people as possible.

Ingrid, Fredi and Pat would all be willing to help Ozzie improve coreware assuming they are happy with the license. Ozzie knows that if everyone is not happy, someone will start a competing project with a license more to their liking. This would dilute the talent pool available to work on coreware!

Ozzie the Originator is a bind. He knows that he can chose a proprietary-friendly license like the Mozilla Public License or the Eclipse Public License that will make Pat happy. But Fredi will never agree to a license that would be incompatible with the licenses that ensure that he can keep his own software freedom respecting. For people like Fredi there is no substitute for two very popular keep-it-free licenses the GPLv3 and the AGPL. The Free Software Foundation keeps a list of licenses that are and are not compatible with the GPL.

What is Ozzie to do? How to keep both Fredi and Pat happy? The first place to look is the LGPL which stands for the Lesser General Public License. This license does two important things, first both Pat and Fredi can use coreware as the basis for the coreware + someothermodules under their preferred license. You can think of coreware + somemodules as a “rollup”.

From a licensing perspective some open source rollups are loosely coupled (like GNU/Linux distros) while other rollups are more tightly coupled (like the Linux kernel itself). Tightly coupled rollups must have identical or fully compatible licenses. Most thinking says that if one software package locally calls the functions exposed in another software package, then they are tightly coupled. (Any VA VistA -server- rollup is likely to be considered a tightly coupled rollup while the relationship between VistA clients and VistA servers would probably considered loosely coupled). It should be noted that these ideas are generally accepted as flowing from a consensus understanding by the Open Source community lawyers of the copyright rules of derivative works, not all of them look at this way.

Ingrid can release her printing component under the LGPL too; essentially adding it to the core… Both Pat and Fredi will then benefit from Ingrids code. Of course end users will have to chose between Pats code and Fredis code because their chosen licenses are incompatible. Each of them is creating a new rollup of coreware with a different family of licenses. While coreware can be included in each rollup, the two rollups are license incompatible.

Both Fredi and Pat can collaborate on coreware with a LGPL codebase because they know that in the end the license of their own module will determine how the LGPL acts for the their users. For Fredis users the LGPL upgrades to the GPL and the AGPL, but for Pat, the LGPL does not interfere with her proprietary license.

Everyone is happy. (or close)

Is the LGPL the only license that is intended to work in this way? No, but it is the license that is specifically designed to solve this problem. Another license that attempts to be compatible with GPL/AGPL projects is recent iterations of the Apache license. Apache is generally considered more proprietary friendly than the LGPL. If Ozzie uses the Apache license, Proprietary Pat could make changes to the internals of coreware, that she does not need re-distribute. Both Apache and the LGPL give here the right to “hoard” or “protect”, depending on your perspective on the matter 😉 her module. But Apache also allows her to horde/protect her changes to coreware itself.

The reality of licensing is that at least two parties must be satisfied with the license. The end user and the most significant contributor. The GPLv2 made Torvalds happy, and his end users tolerate it. Everyone else in the Linux universe tolerates the GPL for Linux because the value of Torvalds original contribution and those contributions he was able to amass around that original contribution. Together these are too valuable to try and replicate. Companies that hate the GPL and everything it stands for, like Microsoft, contribute GPL code to the Linux kernel because Linux is too important for them to ignore. (P.S. If you hear someone talking about these issues in terms of viral or non-viral, you can bet that freedom is not a priority for them)

For VA VistA we have a conundrum, the originator of the code, the US government, has left the code basically licenseless. I believe this means that the choice if preferred license should be up to the most substantial third-party developers. I believe that the most substantial way to make VistA better is to make contributions that make further development easier. MUMPS is a great language but it makes VA VistA inaccessible to most programmers. Given that I believe the most significant third-party contributions to VA VistA are (in no particular order):

  • Medsphere’s OVID – because it lets you code for VistA in Java. (AGPLv3)
  • EWD from M/Gateway – because if you already code in MUMPS you should still be able to write web interfaces. (AGPLv3)
  • Astronaut VistA – because you want to be able to install… With all of the above development environments, in seconds…. Not months… (AGPLv3)
  • TMG-CPRS – because adding patients and correcting demographics should be easy. (GPL v2 or later as per the core WorldVistA EHR license)
  • OpenVistA CIS – because we want to be able to run VistA without Windows. (AGPLv3)
  • Timsons Fileman – VistA Fileman is an important core VistA component that has had many improvements since George Timson left the VA. (LGPL)

-all- of these applications do not just make VistA better, the are Platform Improvements. These improvements are designed to spur new innovation by making hard things easy or previously impossible things tractable.

-all- of these innovations (as far as I can tell) are available under either the GPL or AGPL.

I hope that it is now obvious why most of the VistA community believes that if there is to be collaboration between the Fredis and Pats of the VistA community it must be around a LGPL VistA core.

Soon DSS will be releasing a version of vxVistA under the Eclipse Public License. That license is not compatible with the GPL. If vxVistA is released under the EPL none of the above platform improvements would be available to vxVistA. However all of them are available to users of OpenVistA, WorldVistA and Astronaut VistA, all of which use GPL variants.

I have lauded the release of vxVistA but I fear that as a FOSS project, it will be stillborn because of the EPL. Users will be forced to choose between vxVistA and the considerable menu of proprietary partners whose patent and proprietary interests are satisfied by the EPL, and a projects where VA VistA is being improved -as a platform-

If we were talking about one or two minor improvements that might be available under the GPL variants the I would not take this position but practically, the most important member of any opencore community is not Fredi or Pat but Indifferent Ingrid. Ingrid wants to work with the best platform and contributes in such a way that it makes the platform itself better. Whoever wins the attention of Ingrid, wins.

These lessons are applied in the specific context of VistA, but I hope that is clear that these issues are generalizable to any Health Information Technology (HIT) platform.

(Update 10-13-09 Medsphere has released its server project under the LGPL)

(Update 10-16-09 Ben from Medsphere has responded to my post)

(Update 10-18-09 Thanks for Theodore Ruegsegger, who pointed out several serious errors… fixed)


Microsoft may allow FOSS implementations of HealthVault API

Sean Nolan has announced that Microsoft has placed the HealthVault API specification, under the Microsoft Community Promise (CP) at the time of the writing, this page has not been updated to list the HealthVault API, but the text is provided in the specification download. This may allow for FOSS implementations of HealthVault.

The Microsoft CP is not the same as Microsofts Open Specification Promise (OSP). That is problematic because the Open Specification Promise is already doubted by the larger FOSS community,  and the CP seems even more limiting.

Most notably the CP is different from the OS (from the CP FAQ):

The CP requires that implementations conform to all of required parts of the mandatory portions of the specification. Also, in specified cases (such as where the specifications have uses that exceed those needed to achieve the interoperability needs for which the release under the CP is being made), the CP may have special terms concerning what kinds of implementations are covered.


The CP applies only if the implementation conforms fully to required portions of the specification. Partial implementations are not covered.

The CP for Healthvault does have special terms (from the specification download)

Community Promise Restrictions on the Field of Use for the HealthVault Service Specification

HealthVault Service Specification is intended to support personalized healthcare. This technology is designed to be used by individuals to manage their health information, and is not intended to be provider-centric or health enterprise-centric.

That is a problem for projects like Tolven, which is a combined PHR/EHR system. If the PHR component of Tolven were to implement the HealthVault API,would the CP still be ineffect? In Tolvens architecture, the PHR and EHR are based on the same database. While Tolvens PHR is patient centric, the EHR is user centric.

Further it is not defined, as far as I can tell, what a ‘full’ vs. ‘partial’  implementation means. I could create an implementation of the web service calls for HealthVault over a long weekend, by stubbing everything. Now, my system would be a complete implementation from the protocol perspective, every call made to HealthVault would also work on my system, but nothing my system did would have any meaning. It would be much harder to implement things so that they conformed to the specification and actually worked (as opposed to merely appearing to). We might call an implementation that had no stubs and instead contained attempts at real working parts a ‘robust implementation’. But even a robust implementation would have bugs. It would typically work just like HealthVault, but sometimes it would behave differently, mysteriously.

Those ‘differences’ are what programmers like me might call a  ‘bug’. But would an implementation with bugs fall under the Microsoft CP?

More importantly, who decides if an implementation is buggy? HealthVault is still labelled as ‘beta’ and it is entirely possible that if HealthVault and a FOSS implementation of the HealthVault API worked differently, it would be because HealthVault had moved past its own specification.

At this point, I cannot recommend that anyone implement this API. There are too many unanswered questions here.

Having said that, Microsoft is  obviously trying to open up with HealthVault. I hope to convice them that the OSP is a better vehicle, but this is a step in the right direction. So far Google has released no information on the rules for re-implementing the Google Health API. At this point, Microsoft is (surprisingly) more open than Google.


A Little Law Lecture

I have been asked to give a lecture at the University of Houston Law school about PHRs and HIPAA.

I originally hooked up with the law program there because they publish interesting things on the collision of Open Source and Healthcare IT law, an issue that I care about.  Now I am being invited to talk about PHRs, HIPAA and other interesting things at a Law class. When I was a student I loved it when a speaker brought notes, so that I could focus not on the information content of what he was saying but the validty of his arguments. Apparently (ironically really) I am qualified to talk about things that I blog about, so I wanted to point out some of the medico-legal topics I have covered in my various posts, in some kind of formal way. I hope this benifits others.

But first, I must invoke that wonderful acronym of amateurism IANAL.I am not a legal expert at all, no matter how smart I sound. This is OK because I am much less concerned with how the law does work, than with how the law should work. I think of the law as “applied moral philosophy”, which means that I can ignore lots of the legal issues especially when it is stooopid. When you think the law in a given area is stoopid, like our copyright law, (at least Colbert knows) then you respond with licenses that make some kind of sense, like the GPL or Creative Commons. I am not really an expert in these licenses either, but I am shocked at how often legal experts totally trash the concepts that our community was trying to protect when we wrote these licenses. For instance I have heard file-sharing compared to Creative Commons and Open Source as similarly respectful of copyright.

I care about Free and Open Source licenses in Healthcare IT. I also care about user agreements and PHR privacy statements. So lets dive right in.

First when everyone else was in an uproar about Google Health and Healthvault not being covered by HIPAA, I came to their defence. PHR systems should not be covered by HIPAA and that is a good thing. 

I wrote an article on the difficulty of designing software around healthcare privacy laws.

I have written a pretty snarky little post on the definitions of the terms PHR/EHR/EMR, do not have much to say about that except that these terms are still abused by people who sell stuff. Its much more important to consider a feature set in when defining a term like EHR.

As I prepare for this lecture I wish I had written more on the “Robots attack” problem, where average people have unreasonable fears about technology, but I have talked some about how we focus on the wrong class of problems, with regards to security threats.

I have not yet talked much about the evils of health IT patents. But I should.

So hopefully, talking a look at all of this I should be able to come up with a good talk.