Fred Trotter

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

Here is my submission for the Local Children’s Data Health 2.0 developer challenge. The challenge was to make data available through kidsdata.org come alive.

Generally, the red circles correspond to the percentage of child allergy suffers who had -seen- a doctor, but had no specific plan to address their condition. The red tags, are healthcare providers from the NPI database that are listed as experts in kids allergies… the top of the field for asthma treatment. We are using these “super experts” as a proxy for the availability of specialist care for allergies generally. Notice the under-served areas… The specialist are clustering in the high-population areas. Hopefully this map will inspire an expert to move to Eureka, or Santa Maria..

Here was my process for this for my hack:

• I would only use Open Source software or Open APIs. The idea here is to show just how powerful FOSS tools can be in health data analysis.
• I have just created the best API to the National Provider Identifier database at docnpi.com, so I have this rich datasource that previously has not been available as an API.
• I wanted to target something from kidsdata.org that was directly related to the availability of healthcare, something that you can measure geographically using the docnpi.com API.
• I chose Asthma, because this is something that clearly responds to treatment.
• I wanted to document my process to show how easy this kind of analysis is with the right tools.

Ok here’s what I did…

1. First, I browsed kidsdata.org for asthma information. That leads you straight to this analysis of asthma hospitalizations for young children over the last few years.
2. Then I started digging for source data. It looks like the California Health Interview Survey was a substantial source of the data.
3. They offer Public Use Files of the original survey data. I signed in, and the terms of use for the data were reasonable, and not contrary to my purposes or Open Source. So I signed up and went to download the data.
4. Sadly, the data was only available in three proprietary data formats, Strata, SPSS and SAS. This was obviously designed for academics that think using proprietary software is ethical and normal. Thankfully there are other options. The R project is where I usually turn first for stats help, but I actually found that there was an Open Source SPSS alternative called PSPP. Using PSPP I was able to open the SPSS data file. Victory for Open Source! It would be nice if organizations like CHIS would release in simple XML or CSV, which is much friendlier to hackers and people who believe in software freedom.
5. My feeling of elation was short lived. The data had no geo-coded information. Which makes sense, that would make re-identification much easier. There had to be another way to get geo-coded data.
6. And there was. AskCHIS is a powerful data reporting tool that allowed for xls data download. Again, I am amazed that CHIS would chose to run with a proprietary format without an open alternative. They used alot of advanced xls layout options that meant that an export to CSV would never work. An API would be even better, but at least CSV would allow me to actually parse a file instead of cutting and pasting which is what I ended up doing.
7. But I had access to lots of data. I could see several different measures of asthma that I could have used in my mashup. This included lots of stuff like missed school days, emergency room visits, diagnosis of asthma, symptoms in the last twelve months… etc etc. If CHIS had given this data up using an API, I would have been able to merge the various asthma measures into an overall asthma status score… but it would have take a week of cutting and pasting to do that manually.
8. So I had to choose one data point and run with it. I chose “Health professional ever provided asthma management plan“. This was asked to parents whose kids already had a doctor who was “treating” the asthma. I thought this was an interesting question because it seemed to correlate strongly with doctor-availability, something that I had good geo-coded data on.
9. Now what provider data should I compare it to? Using docnpi.com I can easily grab a list of all/most of the doctors in California who specialize in treating allergies in children I decided to use that as a proxy for “available allergy specialists”. Of course, I had a serious advantage here, because I had already done the work of changing the NPI database into something I could access using an API (that is the idea behind docnpi.com). This easily saved me 30 hours of work on this project alone.
10. So now I have the data I want… but what now? I had addresses for the doctors and clinics from the NPI database, but the asthma data was coded by county. No problem, I just needed to geocode the counties into longitude and latitude. If I had a rich data source from CHIS, it would have been worth writing a script to do this, but since I was using cut-and-paste data, with about 75 rows, it was much simpler to just manually geocode everything. Which is what I did. More cut-and-paste.
11. But now I have geo-coded data for both data sources.
12. I needed a method to graphically display geo-coded scoring. This is pretty easy to do using proprietary GIS tools, even costless tools like Google Earth. But I wanted to keep things simple and Open Source at the same time. Enter the EInsert extension to Google Maps API v2. This allowed me to overlay png circle graphics on a Google Map, and size them in accordance with their percentage (bigger is worse, it means more of the kids did not have asthma plans).
13. Then something tickled my brain. Using circles to represent scaled data is problematic. There is solid research indicating that humans have trouble estimating the area of circles in relation to each other… So I used the ratio suggested by James Flannery to counter this effect. Now the circles are sized in a way that indicates their relative meanings in a somewhat more appropriate way.
14. Now I had a Google Map that displayed data regarding the frequency of plans as meaningfully sized circles over the California state. This data shows some predictable effects. First, the worst areas are either very urban or very rural. Exactly the places that have trouble attracting medical talent. That means that on this map, Ureka and Los Angeles urban counties have similarly sized circles.
15. Now all I needed to do was overlay the doctor data on this map. This turned out to be pretty simple. I already have a link to provide a Google Map display of any small search on docnpi.com. For instance, here is the link for the map for the search on allergists in California. All I needed to do was copy the html and javascript for the doctor map and integrate the map with the Asthma data map I had already made.
16. So far, that maps looks pretty good. However, there is no easy way to tell which county, specifically, a given circle represents. I decided that the simplest way to address this was to dynamically rewrite the png using the gd library of php. I would pass the php script a label, and it would generate a circle with a label on it. This would allow me to label all of the circles on the map. As usual, stackoverflow provided a quick and dirty solution. (update 4-20) I realized that the label should show both the name of the county, and the percentage without a plan… now it does.

Take a look at the final result.

Notice that the shapes scale automatically as you zoom in. Try zooming in to Los Angeles or San Francisco to compare the compacted counties more closely. Also note that you can actually get the name of particular doctor that specializes in the treatment of asthma directly from the map. If you click the link you can get all of the contact information from docnpi.com

Which brings us to the point of this exercise.  A better view of the data can prompt change.

If you are a parent of a child with Asthma in one of the “big circles” you need to know that the long term treatment of Asthma requires a plan. If you do not have a plan, the reason might be that there are not enough doctors around you to provide the help you need. This map can put you in touch with the nearest expert.

If you are a doctor, who specializes in childhood allergy treatment, this is an opportunity map for you. Eureka is much smaller than LA or San Francisco, but you would have a near monopoly on a population that needs help with asthma. These people do not have the same access to specialized care and that might be a business opportunity for you. Moreover, a doctor who chose to focus on the urban areas in the larger cities might also be able to gain patients and profit. The data here shows that while there are lots of experts -around- the densely urban areas they are not meeting the demand for care. If a doctor could find a way to make money on a Medicare/Medicaid population in these urban areas, this might also be an opportunity.

Seeing the health data in a new way can provoke change. I hope you think my application is cool and sexy, but frankly I do not give a damn about that. I want to make a difference, not toys.

People remember Florence Nightengale as the mother of modern nursing. But she once made a diagram that changed the way people thought about war. It was that diagram that gave her much of the political clout she needed to create the field of professional nursing that we know today.

I have made the NPI data more liquid with docnpi.com. Organizations like CHIS need to a much better job of making their data accessible. If I had been able to access the data from AskCHIS in a normalized and open format using an API, I would have been able to make mapping system that would allow the overlay of -any- type of doctor with -any- health data measure that they survey.

So that leaves me with a call to action for three groups: Patients -> find better care near you. Doctors -> go where the patients need you. Researchers -> expose your data in open formats using APIs and open file formats.

Of course, I publish my source code under an Open Source license. Enjoy.

-FT

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 GPLMedicine.org. 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.

-FT

I am utterly not surprised to hear that OpenMRS is shining in Haiti.

This reminds me of the tremendous reponse that the VA had to hurricane katrina using VistA. For fun you should ask those involved for the inside scoop of how VistA enabled an entire hospital to uproot and move over the course of a single week.

Sometimes people do not really understand why we need software freedom in healthcare. These are two perfect examples.

Can you imagine the headache that per-seat or per-doc or per-patient EHR licenses would have caused in -any- haiti clinic? Of course they could always -ask- the vendor for temporary seat licenses, and because the vendors are decent human beings they would probably give them to them. Of course that only works when the phones work or the Internet is up.

Emergencies highlight the fact that health software users may have -very- different needs than the software vendor’s vision or even their own understanding. I know that the OpenMRS project will change substancially in response to the earthquake in Haiti. More importantly those changes will spread to other areas of the world… but those other users of OpenMRS will get the haiti lessons -before- the mudslide/tsunami/earthquake/bombing happens in their area.

In fact I can just imagine and administrator setting up OpenMRS for the first time and wondering “Hmm why would you ever need that???” and ten years later, when those features make OpenMRS better able to handle a disaster in that area, the same administrator will say “Ohhh… that’s why….”

Everytime I hear about something like this from the OpenMRS project I feel again guilty that I am not more involved….

-FT

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.

-FT

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

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

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

Recently, someone contributed a library to help with the webification (<- clearly this is a real word) of VA VistA. In a recent HardHats thread, he expressed his discouragement. I responded and I thought it might help other discouraged developers out there to read me reply. Sometimes the Open Source community just does not respond to good contributions. Here is some of what he wrote:

Jim,

Working with the FOSS health community can be very trying. I fully understand how you feel. I felt that way in the early days of FreeB, which has still not been adopted by the VistA community.

Here are some basic insights about how to get things done in the FOSS Health IT community.

1. You have to be prepared to fully ignore the peanut gallery. There will always be people who have no idea what it means to develop making comments as though they were developers. This is actually a negative side-effect of something positive: this community basically treats clinical users and software administrators as equals. That is a wonderful thing but it means that contributors like you have to learn to ignore people who are not really in your target audience.
2. Your audience is developers, a small subset of this community. Developers are typically very circumspect group and are often lurkers on Hardhats and elsewhere (I am a notable exception to that rule).
3. Developers never have any spare time, we always have something worthwhile that we are working on. That means for your software to get attention, it must win out over other interesting projects for any given developer.

Without presuming to speak for the rest of the development community here, I personally cannot afford to spend time on time-sink projects. Frankly, until Astronaut arrived -as a shared development environment- VistA as whole fell into this category for me. Once you get EWD working in Astronaut then it will be a different ball-game. Then a developer like me, who has very little time, can still afford to evaluate your library for potential projects. If you want an even wider audience, you should try to get EWD included, fully working, out-of-the-box in OpenVistA. Not every developer feels this way, some of them are entranced with the hard way, preferring to compile everything they can themselves from scratch just to be able to say they did.

For VA VistA there are two phases of adoption, first the VistA platforms, and then the developers who rely on those platforms. You are still at the first stage, and you should expect that only the VistA Demigods will even look at your stuff before the platforms adopt it. There are very very few VistA Demigods, which explains the reaction that you are seeing. Once the platforms have adopted your code, mere mortals like myself will consider using it for various projects. There are lots of mere mortals in the FOSS Health community. Do not get discouraged about how things are going now. You should only be discouraged after about a year of inactivity -after- the VistA platforms include your code. At that point I would assume that some other webify-VistA strategy had won out.

This is -not- a criticism or meant to imply that you have failed at anything. You have done some great work, and that is true if your code becomes popular or not. Sadly, the best code does not always make the most popular projects or vice-versa. FreeB eventually became popular, but it was certainly not because it was good code. Success in Open Source is very often an accident of history. Your code might not take off the way other code has. But no one has control over that. Even people with successful projects did not -know- that they would be successful. Everyone has to do just what you did, put your code out there and see what happens.

For my part, I have as much respect for you as I do for the pioneers of our movement. People like Torvalds, Larry Wall, Stallman, and that ilk. It is worth keeping in mind that they got famous because their technical approaches -happened- to win out. But when they started they had to stick there necks out there just like you are. I will not lie and tell you that the reputation gains that you will get will ever approach the benefits that those people enjoy. Even if you are a success in the FOSS Health community the best you can hope for reputation wise in the FOSS Health movement is a LinuxMedNews award, and even that will probably not happen unless your project succeeds. For every project that “wins” in Open Source there are ten or perhaps even more that die on the vine (take a look at the stats on sourceforge) do not be offended if that happens to you, it means nothing.

Community members who have a clue about this will still give you plenty of credit for your work, and you will be surprised how loyal even a small group of users can be. You may have people seeking you out for years to get consulting on your project, even if it never really gets off the ground! In any case, those of us who have gone through what you are going through will always be quick to recognize a fellow contributer and give you the respect and appreciation that your work deserves. We do this because we recognize that your actions take courage, and unless lots of people continuously find the courage to risk what you have, our community will begin to rot.

To sum up: Do not let the turkeys get you down, be patient, and if your project ultimately fails remember to make like Obi-Wan Kenobi.

-FT

When I get a good question from a conference or email, I like to answer it in a blog post so that I can just link it in when others ask me the same thing in the future.

One of the good questions I got was:

Why are there so many “Open Source Health Care” non-profits, yet few seem to have much activity?  I see OpenVista, OpenHealthTools, WorldVista, and yours (Liberty Health) just to name a few.  Just to ask the awkward question, are the differences between them worth it?  What Apache and Mozilla prove is that there is power in scale even in non-profits – to be able to talk as one really helped people figure out who to pay attention to. We wouldn’t have really been able to negotiate with Sun over the open sourcing of Java, for example, if we were speaking as a bunch of separate orgs.  Thoughts?

So here is the downlow on the organizations issue.

There is no OpenVistA non-profit (that I know of) but if there is one, it would be exclusively focused on the Medsphere version of VistA called OpenVistA. In fact there are several projects that have non-profits focused exclusively on that particular project. FreeMED and OpenEMR (oemr.org) both have their own foundations. WorldVistA also has a project, called WorldVistA EHR, but its mission is more generally supportive of different versions of VistA. WorldVistA balances between being both a single project and focused on supporting VistA generally as a meta-project organization. With that said, WorldVistA is exclusively focused on VistA, it certainly cares about certain other projects, like Mirth, but only because Mirth can be used to make VistA better. Probably the most successful accomplishment of WorldVistA is that they were the first FOSS licensed project to achieve CCHIT certification and they have regular, well-attended meetings that have good attendance from almost all of the VistA community. In terms of numbers of bodies in the real-world, WorldVistA has the largest and most active community.

There is also an group representing the VistA vendors called the VistA Software Alliance. The are not formally associated with WorldVistA and also support VistA vendors who choose to make VistA into a proprietary product (DSS, for instance, still does this in some cases). So there are organization who support VistA without explicitly endorsing Open Source or Freedom.

Open Health Tools is another story altogether, it historically, has been focused on interoperability tools: from its FAQ

….to create a common health interoperability framework, exemplary tools and reference applications to support health information interoperability.

Given this it came as a surprise that Open Health Tools worked with DSS on the release of portions of vxVistA under the EPL. While that release was significant, bringing the number of major rollups of VistA at the time to 3 (now there are 4), Open Health Tools counseled DSS into using the EPL, which is relatively unpopular with the VistA community, which have generally settled on the FSF licenses (all three of the other rollups use a GPL variant). If Open Health Tools had used the LGPL, or even Apache which strives for GPL compatibility, it might have been possible to have cross pollination between all of the major development instances of VistA. So there is a small licensing debate that is going on between the traditional VistA crowd and the Open Health Tools (there some are indications that this might be resolved soon)

In any case, Open Health Tools is designed to be a Forge site, attracting developers and providing collaboration facilities for several major projects at once. It has major industry backing and is an important force in our community. If you want to see where Open Health Tools shine, you should attend a connectathon, where many vendors, including proprietary ones, use OHT toolkits to achieve phenomenal scores. If connectathon was a competition, OHT would be winning, by a large margin. Although DSS has gotten lots of attention as an OHT contributor, the most significant contributor is actually Misys Open Source Solutions (MOSS). MOSS uses the OHT forge for development and is releasing their considerable tool set through OHT. Laika (the CCHIT interoperability compliance tool) uses OHT hosted MOSS components in its tool chain. Even if CCHIT is not chosen as the certifying body for ARRA, Laika will likely form the basis of interoperability testing in the US for the foreseeable future.

Probably one of the oldest organizations in the FOSS healthcare space is OSCHA (as of the writing, the website looks down) . OSCHA was active about a decade ago and then went dormant. It was rehabilitated by an international group and has now started having conferences again. This group has largely been tainted by the relelation that the project pushed by the founding president of OSCHA was not actually available to anyone under a FOSS license. The current OSCHA organization might be rehabilitated and the international focus of the new group is admirable, but for now the organizations future is in question. (OSCHA section added July 10 2009 in reponse to a comment)

Finally, Liberty Health Software Foundation, which I helped start and which I am currently serving as the director of, is devoted to the general advancement of FOSS in healthcare. Personally I view the organization as a kind of cleanup organization, taking those roles that require a non-profit, but that have and cannot be addressed by other non-profits. Here are several points of our strategy that set us apart.

• We are project neutral, VistA is important but there are many other solid EHR projects out there that deserve support.
• We are license neutral. We will support any FOSS license, and generally want to avoid getting into the ‘Free’ vs. ‘Open Source’ licensing debate.
• We are not concerned with the ‘category’ of software, but rather its relevance. If something does not fit neatly into the current terminology of EHR, PHR, Integration and other, we will still happily work to advance the project if it might make an impact.
• We will try to focus our development on: the boring (like documentation) that for-profit companies view as a last-priority, and development that could spawn new development. We will not be a Forge project, instead relying on other projects (like Open Health Tools) to provide a collaboration platforms.
• We will be supporting smaller projects by providing them space at conferences.
• We will be promoting FOSS conferences, like SCALE, and creating our own, like FOSShealth.
• We will do -very- limited lobbying in support of FOSS.
• We will provide an industry trade group made up of FOSS vendors, hybrid vendors, and proprietary-but-FOSS-friendly vendors.
• Where possible to promote obviously legitimate projects as alternatives to proprietary systems, to whoever will listen.

Obviously Liberty has lots of overlap with the other meta-project groups like WorldVista and Open Health Tools especially, but we are the first organization designed intentionally to embrace everyone in the Healthcare FOSS community. I hope that by creating a central organization, that seeks support not from companies like Oracle and Microsoft, but by companies like Mirth, ClearHealth, Misys, Medsphere, DSS and Akaza Research (not a comprehensive list by any means). Companies that obviously have a significant financial interest in our movement as a whole succeeding. Also we want support from the project or multi-project specific non-profits like Open Health Tools, WorldVistA and the OpenEMR Foundation.

It is worth noting that our community is simply never going to organize itself exactly the same as the wider FOSS movement. Liberty will typically be taking roles that normally, OSI, EFF or FSF might fill in the broader space. Open Health Tools will typically be operating more like the Apache, Eclipse or Mozilla foundations with a specific development focus. However, I hope and expect that we will get frequent role reversals and overlap. Why? Because we are still a very very small community in terms of devoted developers. I would expect that there are less than 1000 people who are devoted to developing FOSS licensed healthcare applications full time. There is way more activating, advocating and forging to get done than any organization could accomplish. Unless Liberty, WorldVistA and Open Health Tools each continue to fulfill their ‘part’, we are in trouble! It would take years for another non-profit to step in the gap left by any of these three meta-project organizations.

So, for today, that is how the non-profit space in FOSS healthcare breaks down.

HTH

-FT