Hardware Hack: Hacking the ICE Medical ID USB wallet card

I am happy to say that I have a totally new type of post for my readers.

I am going to detail how to modify to the “ICE Medical ID” product to be relevant for those of use who do not want to be stuck crappy proprietary software. This only barely qualifies as hardware hacking, I am just going to detail how to remove the default software that comes with the card. But once this is done, it will form the foundation for some much cooler work. I bought my card for $20 at a local CVS, but you can get them all over the place. The only difference between this and some other credit card sized usb drive is that it is clearly labeled that it contains your In Case of Emergency (ICE) information. Most importantly, the card is Open Source and remix friendly. You can put whatever you want on the card and your EMT or ER personnel might find it.

First, you need to turn on viewing hidden files and potentially hidden system files in your Windows folder configuration. (Unless you are using GNU/Linux, which makes this step unneeded) This will allow you to see the hidden system files that the Ice.exe relies on.  Once you have done this you should be able to see the following files on the USB drive:

Ice.exe

unicows.dll

Ice (a directory)

Autorun.inf

The hack could not be simpler… delete all of these.

The Ice.exe file is a simple PHR application that makes all of the first-generation software errors. It stores its data in xml (under the ice sub-directory) but not in CCR or CCD, making the data you enter there trapped. It has bullet choice defaults, even when a user has not chosen data. The end result is that the application makes assumptions (like that a user is married) for unselected options. This is exactly the reason why Health Information software should be open source. The company that released this card has no business creating health software and they hired professional developers, but amateur health informaticists to do this work. Lots of rookie mistakes here.

I replaced the above with a simple text file with the following information:

Hi,
If you are reading this then I must be hurt very badly.
Please make sure my wife, Laura Trotter (email) and (phone number)
and my brother Rick Trotter (email) and (phone number)
are fully informed regarding my condition.

My blood type is O+
I had minor knee surgery on my right knee several years ago. A small part of my patellar tendon was removed.
I am not allergic to anything that I know of. I have never had a reaction to any anesthesia.
You should be able to find an health insurance card in my wallet, where you found this card.

Thank you for taking care of me.

Regards,
Frederick (Fred) Clayton Trotter

Email might seem funny, but it might be possible that my wife is in a different country when I am injured, and email always works…

I thought about replacing the Autorun.inf with something to popup the text file automatically when the USB was inserted into a computer, but Windows 7 no longer supports non-optical drives running Autorun.inf and Apple OS X or GNU/Linux computers do not support that either. It is just as well since most of the time I insert the card into a computer I will be using it to transfer files.

I also could and probably will upgrade the text file to an html file at some point. But I think that kind of work is best left to when I can integrate the record with Google Health or better yet with Indivo. Html would have the added benifit of allowing me to integrate a picture, which would make it pretty simple to include information on one card for several people, a mom-pleasing feature indeed. (You can do this with the proprietary software only after you purchase the privilege)

Enjoy hacking your healthcare information.

-FT

On project governance

Recently, some of the i2b2 team asked me for my thoughts on project governance. I find that my lengthy email answers to these kinds of questions are worth blogging about. I mean really, its a bother to write a good blog post and a bother to write a long email… why duplicate??

The original question was very broad:

Can you share any pointers to governance procedures, policy
and organization for an OS process?

The first question to ask is who, practically speaking, currently has the right to modify the published version of i2b2? Lets call those the “developers”.
The second question to ask is who owns the trademark to the term “i2b2″? That person or organization is by implication the current shepherd. Most of your concern should go into legitimizing your current development team and ensuring that your shepherd organization is doing right by them.

Next, is there a for-profit company that is predominantly the employer of more than half of the developers? If that is the case than you can consider a for-profit shepherd organization (like RedHat or Canonical). Usually for an organic project like i2b2 this will not work.

Next you can setup a new non-profit as the shepherd organization. This is the most common model. The purpose of this organization is primarily to have someone to sue other than developers directly. 501c3s are a bother to setup, if you want you can create an “arm” of an existing non-profit. There are at least two options for this, you can work with Open Health Tools which is really designed to support this. Often that does not work for licensing or other governance  reasons, and if you need more autonomy but still want a non-profit shield, you are welcome to setup sub-organization with Liberty Health Software Foundation.  There are other Open Source Health IT non-profits out there…

No matter if you setup your own non-profit, partner with an existing one, or choose a for-profit vehicle, your governance model is basically the same core set of issues. The questions you must answer definitively with your organization governance is:

  • Who gets to update the code?
  • Who gets to name a particular codebase as the “current” and “official” version of i2b2?
  • If you have a modular architecture (and who doesn’t?) how do you decide which modules get to advertise on the main community “site”
  • How do new developers earn the right to update the core code?
  • Who will you recommend for paid support? How can an organization get on that list? This is an important question, you must do everything to ensure that when i2b2 is installed somewhere by some third party that if that third party was using the i2b2 name to market themselves that they did a good job.
  • What are the rules for the use of the i2b2 trademark?
  • Where do you go on the web to participate in the i2b2 user and developer community?
  • Who owns the copyright to i2b2? What is the license? If you decide to change the license how will that happen? Are you requiring copyright assigments for coded contributions and if so, to whom are the copyrights assigned?
  • What is your policy towards patented software? (Universities can be sensitive about this)
  • Will the organization be employing developers? Will you seek money for development?
  • How will you unsure that future difficult decisions on your project will be made well?

I know that i2b2 has very strong academic associations, as many FOSS projects do. That relationship may mean that “at the university’s discretion” is often the answer to many of the above questions. That is fine, but you need to make it perfectly clear which of the above questions you are abdicating (and why) and which you are not.

I hope that I have adequately opened a can of worms for you. I have many opinions on how these questions should be answered and for each of them there are many different legit paths taken by other FOSS organizations. I can intelligently discuss how the top reference organizations function as applied to you (like Apache, Mozilla, Eclipse and Linux) to see where there might be areas for you to imitate. Let me know which of these topics interest you and I can discuss them further here. The most important thing to realize is that your governance -cannot- be as complex as the Apache governance processes without also having the kinds of resources that the Apache projects have. You either need to work with an organization like Open Health Tools which has alot of these things figured out, (but may have made decisions that you cannot live with) or you need to create a light-weight set of processes and governances that are something that your organization can actually follow.

I am sure that you already have concerns and ideas that I have not even listed, either because I am unaware, or I think there are not important. So I as you go through this process I would advise you to ask two questions:

“What bargain am I making with my users? Besides understanding what my software does, my users want to understand what license obligations they are undertaking to use my software. They want to understand how to connect into a community of users, and how to get paid support if they need it. Are the ‘terms’ for becoming a user of the my software clear and fair? “

and

“What bargain am I making with my developers? Developers are by implication both interested and not satisfied with my current software. They want to improve it with me, but they must calculate whether it is worth their time to make the investment to develop with me. Are the ‘terms’ that I set forward to them clear enough that they can determine whether to make that investment?

Sometimes an shepherd organization is going to have to make unpopular decisions. (Like Red Hat did in retiring Red Hat Linux and creating Fedora) How will your organization be able to make good decisions that potentially infuriate your users? More importantly, how will your organization recognize when your community of users has moved beyond you? (Like the firefox project did inside Mozilla) how will your organization maintain the humility to recognize that a community version is better than your official version?

If you get either of these questions wrong, your shepherd organization will end up holding your project back in the long term.

Probably the most controversial question that you have to answer is to what degree you will allow your community to rule you. When WorldVista (the current non-profit for VistA) was originally formed, they were concerned that corporate interests would “buy-out” the WorldVistA board. As a result there are no elections to the WorldVistA board positions. There is no way for the community to remove board members. Over time, this has resulted in a steady loss of “doers” on the WorldVistA board. Enforcing “doing” over “dithering” is impossible if you cannot rid yourself of someone who really wants to “dither” (for goodness sake look at Congress). As a result, the board tends to attract and keep “ditheres” while alienating “doers” in the community. The few “doers” on the current WorldVistA board are long-suffering and patient individuals… martyrs really. The end result is that WorldVistA consistently refused to make the difficult decisions. When they do act, it is usually only after a particular strategy has become obvious (<- read this as “too late”)

WorldVistA did not start out that way, it is a factor of organization rot based on bad decisions made early in the formation process. But remember, their concern was very real. There are plenty of organizations that get taken over by corporate interests. The purpose of a shepherding organization is to protect the project for its developers and users, that means partnering with companies, but not being ruled by them.

For a worst-case scenario of how an organization can get embroiled in project issue, consider when Tridgell developed a FOSS Bitkeeper client while employed by OSDL (the precursor to the Linux Foundation). At the time OSDL also employed Linus Torvalds, who was in favor of using the proprietary Bitkeeper. From OSDLs perspective, you had a big mess. Two of its sponsored developers where at odds putting in a potential position of liability from Bitmover, the company behind the proprietary Bitkeeper tool.

You have to consider the far future of a project as you consider your governance structure. To do this, you have to honestly, and potentially painfully, asses the potential conflicts within your particular community. Remember that it will not be you sitting in your chair when the critical decisions are made, you have to be able to assume that your replacements will be competent, but you would be foolish to assume that they have your motivations. Its a difficult balance and I wish any project luck with that.

For the best examples of well-run shepherding in our community I would recommend Medsphere.org (the community arm of Medsphere corp) and the OpenMRS project.

HTH,
-FT

Lack of Transparency in Houston, T.X.

I am quite happy to say that your insane business practices will soon be coming to an end.

http://www.hhs.gov/valuedriven/

Do you honestly think that any other business could get away with not providing up-front pricing? You actually expect me to visit in-person to determine whether you have a fair price for services? Try calling Walmart or IHOP or any other business that sells standardized products, you will find that they will be happy to publish those prices. Most of those businesses publish their prices on the Internet.

Prepare to be blogged about as a fine example of what cannot continue.
Do let me know if you decide to change your policy so that I can
update my blog piost.

http://www.fredtrotter.com

-FT

On Mon, Nov 2, 2009 at 3:31 PM, Midtown Dentistry
<censored@midtowndentistry.com> wrote:
> Good afternoon Mr. Trotter,  Thank you for contacting Midtown Dentistry.  We
> don’t give quotes over the phone or emails.  I will be happy to give you an
> appointment for and exam and consultation.  At this appointment you will
> have a full exam, consultation & x-rays.  Dr. Penchas will go over all of
> your needs and you will be given a treatment plan will all costs involved.
> Please call me at the phone number below so that I may assist you with an
> appointment.  Thank you again,
>
>
> Glenda Cornell
> Midtown Dentistry
> 315 Westheimer
> Houston, Texas 77006
> censored
>
> —–Original Message—–
> From: Fred Trotter [mailto:censored]

> Sent: Monday, November 02, 2009 11:13 AM
> To: censored
> Subject: Contact us message
>
> Contact Us Message
>
> Name : Fred Trotter
>
> Email : censored
>
> Phone :  censored
>
> Message:
>
> Hi, I need to have a extensive cleaning done (according to my previous
> dentist) and I would prefer to have it done under general anesthesia. I will
> be paying cash, so I would like to know the cost of an “extensive” or “deep”
> cleaning under general anesthesia factoring in any cash discounts you may
> offer
>
> Regards,
> -FT
>

Who owns the data

Who owns the health information?

  • the patient to whom it refers?
  • the health provider who created it?
  • the IT specialist who has the greatest control over it?
  • the researcher who aggregates it?
  • the health 2.0 company that harvested it?

the notion of ownership is inadequate for health information. No one has an absolute right to destroy health information. But we all understand what it means to own an automobile: You can drive the car you own into a tree or into the ocean if you want to. No one has the right to do things like that a “master copy” of health information.

All of the groups above have a complex series of rights and responsibilities relating to health information that should never be trivialized into ownership.

But asking the question at all is a hash argument.

What is a hash argument?

Come to think of it, there’s a certain class of rhetoric I’m going to call the “one way hash” argument. Most modern cryptographic systems in wide use are based on a certain mathematical asymmetry: You can multiply a couple of large prime numbers much (much, much, much, much) more quickly than you can factor the product back into primes. A one-way hash is a kind of “fingerprint” for messages based on the same mathematical idea: It’s really easy to run the algorithm in one direction, but much harder and more time consuming to undo.  Certain bad arguments work the same way—skim online debates between biologists and earnest ID (Intelligent Design) aficionados armed with talking points if you want a few examples: The talking point on one side is just complex enough that it’s both intelligible—even somewhat intuitive—to the layman and sounds as though it might qualify as some kind of insight… The rebuttal, by contrast, may require explaining a whole series of preliminary concepts before it’s really possible to explain why the talking point is wrong.

At some point I will modify this article to actually do the rebuttal. At this point it is enough to say that -even asking the question- who owns the data is creating a hash argument. The question presumes that the notion of ownership is valid and jettisons those foolish enough to try and answer the question into needless circular debate. Once you mistakenly assume that the question is answerable you cannot help but back an unintelligible position.

People asking this question at conferences is a pet peeve for me.

(update 2012: fleshing out this post, for reposting to radar)

So the reason that “ownership” does not apply to well to health data is that “ownership” means a little too much to apply well for anyone. Here is a quick chart that shows what is possible depending on a given role.

Person/Privilege Delete their copy of data Arbitrarily (without logs) edit their copy of data Correct the providers copy of the data Append to the providers copy of the data Acquire copies of HIPPA covered data
Sourcing Provider No. HIPPA mandates that the provider who creates HIPAA covered data must ensure that a copy of the record is available. Mere deletion is not a privilege that a provider has with their copies patient records. No. While the provider can change the contents of the EHR, they are not allowed to change the contents without a log of those changes being maintained. Many EHRs contain the concept of “signing” EHR data, which translates to “the patient data entering the state where it cannot be changed without logging anymore”. Yes. The provider can correct their copy of the EHR data, providing the maintain a copy of the incorrect version of the data. Yes. The providing merely add to data, without changing the “correctness” of previous instances of the data. Sometimes. Depending on the providers ongoing “treatment” status of the patient, they typically have the right to acquire copies of treatment data from other treating providers. If they are “fired” then they can lose this right.
Patient rights Yes they can delete their own copies of their patient records, but requests to providers that their charts be deleted will be denied. No. Patients cannot change the “canonical” version of a patient record No. While a patient has the right to comment on and amend the file, they can merely suggest that the “cannonical” version of the patient record be updated. Yes. The patient has the right to append to EHR records under HIPPA. HIPPA does not require that this amendment impact the “canonical” version of the patient record, but these additions must be present somewhere, and there is likely to be a substantial civil liability for providers who fail to act in a clinically responsible manner on the amended data. The relationship between “patient amendments” and the “canonical version” is a complex procedural and technical issue that will see lots of attention in the years to come. Usually. A patient typically has the right to access the contents of an EHR system assuming they pay a copying cost. EHRs frequently make this copying cost unreasonable and the results are so dense that they are not useful. There are also exceptions this “right to read” which includes psychiatric notes, and legal investigations.
True Copyright Ownership (i.e. the relationship you have with paper you have written or a photo you have taken). Yes. You can destroy things you own. Yes. You can change things you own without recording what changes you made. No. If you hold copyright to material and someone has purchased a right to a copy of that material, you cannot make them change it, even if you make “corrections”. Sometimes, people use licensing rather than mere “copy sales” to enforce this right (i.e. Microsoft might have the right to change your copy of Windows, etc…) No. Again you have no rights to change another persons copy of something you own the copyright to. Again, some people use licensing as a means to gain this power rather than just “sale of a copy”. No. You do not have automatic right to copies of other peoples copyrighted works, even if they depict you somehow. (this is why your family photographer can gouge you on reprints.

Ergo: neither a patient, nor a doctor has an “ownership” relationship with patient data. So asking “who owns the data” is a meaningless time-wasting and shallow conceptualization of the issue which is at hand.

The real issue is: “What rights to patients have regarding healthcare data that refers to them?” This is a deep question because patient rights to data vary depending on how the data was aquired. For instance a PHR record is primarily governed by the EULA between you and the PHR provider (which usually gives you wildly varying rights depending), while right to your doctors EHR data is dictated by both HIPPA and Meaningful Use standards.

Usually, what people really mean when they say “The Patient owns the data” is “The patients needs and desires regarding data should be respected”. That is a great instinct, but unless we are going to talk about very specific privileges enabled by regulation or law, it really means “Whatever the provider holding the data thinks it means”.

For instance, while current Meaningful Use does require providers to give patients digital access to summary documents, there is no requirement for “complete” and “instant” access. While HIPPA mandates “complete” access, the EHR serves to make printed copies of previously digitized patient data completely useless. The devil is in the details here and when people start going on about “the patient owning the data” what they are really doing is encouraging a mental shortcut that cannot readily be undone.

HTH,
-FT

The Health Internet

For whatever reason, people still do not get the basics of the Health Internet. Part of the problem is the fact that the marketing term has been, until recently the National Health Information Network or NHIN. The Feds recently decided to start calling the project the Health Internet, because that gives a much better idea of what they are trying to achieve.

Please do not be the guy/gal who writes in my comments but the Internet is not secure, that means my privacy will be violated. That is pure FUD and is not how the Health Internet will work. It is a relatively simple process to make the Health Internet into a zone that is more secure and private than the current health information infrastructure. Notice that did not say “secure” I said “more secure”. Your bank is not “secure”, your doctors paper records are not “secure”, the CIA is not “secure”. As an adjective, secure is more like the human attribute of “tall”. I am typically considered a tall person, but in college I was an student athletic trainer for my schools basketball team. In that crowd, I was short. While there is one and only one person who can be considered universally “tall”, it is well understood that this is a relative term. Similarly, the Health Internet is relatively more secure than current systems. I personally am far more comfortable having my private data in the Health Internet than I am with having my paper records locked in my Doctors office. You should be too.

So you should not be thinking about security or privacy in the Health Internet…. Really… It is as close to a solved problem as it gets. There are always obviously ways to make things more secure… but taller is not always better.

So what does the Health Internet buy you as an individual living in the US? To put it simply you and your Doctors should eventually be able to get to all of your health information as easily as you now get access to your financial information. Its a big promise, but the design of the Health Internet should eventually make that kind of convenience and access a reality.

Given that, it becomes obvious why a rebranding to the Health Internet is a good idea. For several basic reasons:

  • the original Internet started life as a government network (ARPANET)… And that has turned out pretty well.
  • the reason that the original Internet was such a hit was that people built neat stuff on top of it. Similarly, the Feds are hoping that people will use the Health Internet as the platform for further innovation.

So the Health Internet is a good thing and everyone should embrace it.

So how do you jump start a Health Internet? You do it by providing Open Source Software that enables people to participate in the new network.

Most people do not really understand the relationship between Open Source networking projects and the success of the original Internet. Here is how this breaks down:

Most of the Internet servers that provide X do it using Open Source project Y. With that as a template, look at the following chart:

Email:sendmail
DNS:bind
Web server:Apache

Of course, you -can- use proprietary software for these components, but the Internet as we know it would not exist without these very low cost tools that provide a substancially large portion of our Internet infrastructure. So whats the plan for the Health Internet? Simple.

Health Internet:CONNECT

The CONNECT project is an Open Source project that -will- run the core Health Internet. The core will connect major government health data sources including the VA and the DoD the initial Health Internet core. Most importantly the CONNECT software is available for local exchanges to connect into the core Health Internet.

Overall the strategy of creating an Open Source project that can be used to fractally to create other, connected, networks is a proven strategy. Its a smart move and it is going to change Health Informatics in fashion that is very similar to the way the Internet has already changed computing generally.

Open Source Health Software Conference

So I have two small news items.

First, I am renaming the yearly Houston Open Source Conference from fosshealth to OSHealthCon, which just stands for Open Source Health Software Conference. Why the name change? Well, it is caused by the need for me to distance myself from the term “free”. I know what “free” means when you are talking about software, but again and again, the term is abused by people with a proprietary agenda.

People would talk about the differences between “free software” vs “commercial software” implicitly insulting any professional who wants to use freedom-respecting licenses.So I am throwing in the towel. I am not going to fight this battle any more. At some point, I have to decide if I am going to advocate for freedom, or for one particular way of talking about freedom.

The other important news item is that I have started posting the 09 Videos up to www.OSHealthCon.com.

This is our first stab at videoing our own conference, and the results are just as amateurish as you might expect. Still, if you can tolerate the sound, there is a tremendous amount of insight available there.

I will be posting new videos there as I sort out how to make blip.tv transcoding work on GNU/Linux.

-FT

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)

-FT

The wrong conversation, missing CONNECT

Today I heard a session today at the National IT Forum at Harvard entitled “Business-Government Interactions to Support a Platform”.

I felt like I was Alice in Wonderland. Behind me sat two of the top leaders of the Open Source CONNECT project. Which is, frankly, the single largest contribution to Health IT interoperability to come from the Federal Government… ever. Even now, that project will ensure that there will be a National Health Information Network that will create local exchanges that will allow the transfer of health information about individuals from coast to coast.  Or at least this is so likely to happen, that other outcomes would be so random that they cannot be planned for in any case. Yet,  the CONNECT project was hardly mentioned one time during the session about “What we want from the Government”.

The session waxed long on what to expect from the Government, what the Government should do and should not do. Lots of talking about laws and rules and Google.  How should we do health information exchange? Some of it was pretty interesting, but basically it was the wrong conversation.

The right conversation starts with this: we can assume that CONNECT -will- unify the health information transfer in the US. It will serve as the basis for the core NHIN and regional networks will have the option of implementing it. That means that CONNECT sets the bar for health exchange.  Software must be as good as CONNECT to be considered for a local Health Information Exchange, otherwise, why not use CONNECT?

So -given- that the US government will (sooner or later)  solve the problem of health information exchange using CONNECT, the question is how we as platform developers will -leverage- CONNECT to make new and improved patient and clinician-facing tools.

While the first talk was better, and the contacts I have already made here are invaluable, so far there is too much fluff and not enough on the dirty details required to make a platform. I really wish Ben Adida could have made it, because as it stands I feel somewhat ungrounded. The conversation should really have been “what does CONNECT mean for us?” and instead it was just circular nonsense. I really want to ask after almost everyone finishes talking “so… you will therefore code what… exactly?”

For this post I want to make it clear. CONNECT is not perfect, they have warts both as a codebase and as a project. But they are rapidly fixing themselves, and they will change everything. This seems so obvious to me… and yet apparently not everyone gets this.

-FT

Away from iphone and towards a better platform analogy

As many of you know, the CHIP/Indivo/Harvard guys (who I guess I should call the ITdotHealth guys) wrote an article in the NEJM saying that we needed something like the Iphone app store in Healthcare IT.

I wrote a rebuttal saying that, among other platforms, the Google android platform was a better fit. Frankly, I thought that would be the end of it. Most of the time I write a blog post, I get some hits, and maybe a comment if I am lucky. But mentioning the iphone is great for getting attention. Apparently, just saying the word iphone brought the readers out of the wood work. iphone iphone iphone <- (just to be sure…).

More than just getting some good comments I have just realized that Ben Adida (check out my blog roll) wrote a Knol that touched on my criticisms and argues convincingly that there needs to be some balance between openness and safety.

Though it is clear that Apple’s regulation of the iPhone apps market has gone far beyond malware prevention, the goalof malware prevention is certainly reasonable.

I think he is right on, and I look forward to talking about it with him in person tomorrow. I think now, the night before the conference, it might be a good time to drop my thoughts about what platform analogy would really be the best to reference as we move forward. I also take a moment towards the end of the post to concede some of the things that Apple really got right, since I do try to be fair.

If I had to pick one thing that best embodies the 10 principles that are being targeted here, I would pick yum. Yum is the update manager for Red Hat based operating systems. Here’s why:

  1. Like the iphone app store, it is “substitutable (first of the ten points). You can download like 10 different web browsers on the current Fedora.
  2.  It built its own protocol. RPM was a lower-level standard, and yum was born as a meta-tool on that standard.
  3. Yum allows for multiple platforms. It forms the basis for the software packaging for just about every Red Hat/Fedora based operating systems, of which there are several.
  4. The API for yum is open, which is what lets things like yumex happen.
  5. The programs installed by yum never have direct control over yum (unless that is the point of the program, and that is what the user wants to do).
  6. Application install is as pointy-clicky and as user friendly as it gets BUT you do not lose the power of command line script-ability. Talk about walking the fine line!!
  7. Separation between the copyright/patent/trademark of applications and the platform is totally there! You can point your yum to a proprietary repository, for instance to download Adobe flash… no problem.
  8. Unfortunately it does not make any sense to say that you can remove everything from yum and still have a platform. So I guess it strikes out on that one. Of course, I am not sure why the platform itself should -not- be considered a package on the platform… Ill have to ask about that tomorrow…
  9. Yum is really really efficient. You can update applications very quickly, and you can even install a special yum module that will find the fastest download servers, ensuring the best experience for downloads.
  10. The certification is as minimal as can be. The packages -can- (not required to be) signed by the people who set up a repository, and you simply do or do no trust that signature.

Someone will point out, someday, in comments that apt-get is just as good and does all the same things. To that future commenter I fully admit that you are 100% correct. I am a long time Red Hat guy and I am letting my colors show, for the record I am trying Ubuntu on my desktop for now….

Now let me point out a couple of cool things about yum that are not on the “big ten” but that I think are worth emulating:

  1. Yum is actually an upgrade to a previous platform, Yup. Yup was good, but users forked it and made it much better… then the original yup developers adopted yum. That’s the virtuous cycle of Open Source in action if I have ever seen it.
  2. Yum handles “trust” in the system, by getting out of the way. A “default” repository is trusted to get the system off the ground. But you can “trust” other repositories to get upgrade versions of the software you are currently using, to get substitutionsfor the programs you were currently using, or to get new software that is found nowhere else. It automatically find the balance betwen openness and security. Users make the decision about how to trust, and the system does not auto-branch beyond those decisions.
  3. Although yum violates principle 8,  you get the benefits of being able to use the platform to upgrade the platform. You can upgrade a late-generation yum operating system while it is running.
  4. The yum platform was central making a larger community effort. Remember when Red Hat stopped doing Red Hat Linux, instead creating the Fedora project and RHEL? Fedora existed before that, as a high-quality repository of Red Hat packages! yum was an important new feature of Fedora Core 1. The yum platform helped move the whole community forward.

So I think the yum project and the way that Red Hat made into a software distribution network is a pretty good model to follow.

Even I, however, get why they original authors chose to use the iphone as an analogy. Not assuming that these points are original, I want to point out some things that Apple did right, that other systems have failed at.

  1. Apple enforced simplicity. They refused to allow programs to run in the background. They refused to allow many other things that a developer for Windows CE might have expected. They made the core interface as simple as possible. They even excluded cut and paste initially to make the system simpler. Apple put these restraints in place because by making the applications simpler, they made the user experience vastly more intuitive.  I have used countless “modular” or “substitutable” platforms that miss this.  It is the platforms responsibility to protect the overall user experience, -not- the application developers. That means knowing when to say no. Ignore this one at your peril.
  2. Apple built a meritocracy at the level of the end user. When you see an application on the iphone that has been used by 5000 users, and they have all rated it 5 stars, you can be pretty sure it is good. That rating stands front and center in the platform, and more importantly, the platform itself constantly promotes and rewards its star performers. On other modular systems, I usually spend a lot of time trying to sort out what modules are reliable. The Firefox module system has also done a good job of this.
  3. Despite its habit of blessing particular development groups with special privileges, Apple also made it easy for the individual developer to become a super star on the platform. It did that by giving people pretty substantial development tools and a robust development environment.  If you want to get rock star developers you have to give them their version of the red carpet. That means awesome documentation, video tutorials and lots and lots of working examples.

I figured I would jot down these thoughts before the conference, so that I can have the most fun while there. Apparently, some of these people are actually reading this… so its a very efficient way of making points as opposed to taking the whole conference to dinner with a Fred-monologue.

-FT