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

Surescripts agrees to modify NDA to be compatible with Open Source licences

As many of you know,  I am often asked to represent the FOSS Health IT community in negotiations with various organizations. My first opportunity to do this was with CCHIT, that negotiation has turned out pretty well. Then I represented the FOSS community at the NCVHS hearings on Meaningful Use.

Most recently, I have had requests from the community regarding Surescripts (who appropriately use a .net domain name… because they are a network!!).

For those that do not know, Surecripts (after the merger with RxHub) is essentially the only way to communicate electronic prescription messages in the United States. However, many in the FOSS community felt that the Surescripts Non-Disclosure Agreement prevented FOSS implementations of the Surescripts interface.

I just got off the phone with Rick Ratliff and Paul Uhrig from Surescripts and they agreed to modify the NDA to explicitly allow the release of Surescripts implementations under Open Source and Freedom Respecting Software Licenses. In fact from their perscpective this was implicitly allowed under the current NDA.

To move forward I have asked representatives from Medsphere and ClearHealth (Open Source vendors who already have a working relationship with Surescripts) to work with Surescripts to produce a short modification to the Surescripts NDA which will explicitly allow for a FOSS release. Once they have finished that language, we will present the resulting changes to the community at large to make sure it works for everyone. After this, Surescripts has agreed to add the changes to the default NDA.

While this issue will not be resolved until we have FOSS-available implementations that can access the Surescripts network, this is a huge step forward. I would like to thank Paul and Rick for making time for me in what must be a tremendously busy schedule.

Regards,

-FT

Network Effect vs Open Source

Something I have been thinking alot about lately is the issue of Software as a Service and how that model works with the network effect and open source software.

My thinking is prompted by a service that I am thinking of launching. The code behind the service is very simple, and while I have predilection to release everything I do under FOSS licenses, I am thinking of not releasing the code for this. Notice that I am not talking about making a proprietary software product, that would be unethical, I am talking about offering a service over the Internet, using code that is kept private. Private code is ethical, proprietary code is not. It is a matter of control, proprietary software allows a user to run software that they have no control over. Private software running a network service is often called the ASP loophole of freedom respecting software licenses like the GPL (but not the AGPL), but basically it is ethical because the user is not actually running the software at all, they are just accepting a benefit from that software. The moral issue gets convoluted when you have a service that maintains user data on the foreign site, rather than just providing a take-it-or-leave it service. Google, for instance, is in a very different position of responsibility when it chooses to offer an email service rather than a search service. If Google stopped providing search, that would suck, but if gmail went down and took years of my corresponence with it… that would -really- suck.

For certain kinds of critical data, I think it is unethical even to use private code. This should seem especially obvious for health information.

Before we get to my issue, I wanted to point out another organization that is in essentially the same position: StackOverFlow.com

StakOverflow is a site that supports the ability to ask very specific technical questions and then rank the answers that result. You see if StackOverflow releases its code open source, then you could have hundreds of separate question-answering sites start, all of which would have have only trivial amounts of users on each site: Joel (as in Joel on Software) discusses this issue in a podcast (transcript):

Spolsky: Well, but they will suck away some the audience that might have come to us, thus reducing the network effect, and thus reducing the value to the entire community.

As long as Stackoverflow is in -one- place, then all of its users go to one place to ask and answer questions. There is a network effect of all of those users going to to same location, it means more questions and more answers. More questions and more answers means better answers and questions since the whole point of the stack overflow architecure is that “more” becomes “better” through user voting. Better answers means that more people will go there to search, which means more users, which means more answers/questions which means better answers which means better users and you have the loop. The critical upward spiral of community collaboration where the more users you have the more valuable the central resource is.

What does this sound like? It sounds like open source software development and the way Wikipedia works. In fact there is a whole book about this upward spiral-through-open-collaboration effect called wikinomics.

But the upward spiral of the -content- on StackOverflow is hindred by attempting to open source the code. The code would obviously improve if it where open sourced, but the content would degrade. (Aside: It might be possible to find a way to turn the StackOverflow model into a protocol too, so that you could have multiple instances that would create a large disstributed system of StackOverflow instances. So that when you searched for bird watching on StackOverflow.com you might get results from BirdOverflow.com or whatever. This is what Google is trying to do with Google Wave)

It should be noted that StackOverflow actually already open sources the content that it produces, using a creative commons license for the questions and answers posted there. They also provide a data dump of the content, so that you can get it for programmatic use without bothering to screen scrape. So they really are making an open source contribution.

Back to my idea. I have a service that I will be launching soon that will also greatly benifit from the network effect on the content, but would be damaged by having multiple instances. I am inclined to not release the source code for this reason, but I have not yet made up my mind…

Update:

This got several good comments very quickly. Thanks for that, I really have not made up my mind on this issue and your comments have been very helpful.

Probably the most important information that I got is that there are several Open Source Stack Overflow clones in various stages of development.

I had searched for Open Source implementation of Stack Overflow and had only found Stacked. Personally reimplementing something so that it will not be proprietary anymore and then using a proprietary language (no offense to mono) to do it in just seems pointless. Of course I really wish there was something in php, since that is my current crutch language of choice. Hopefully people looking for a GPL or BSD implementation of Stack Overflow might be able to find it now. Drop a comment if you have a good implementation in php!!

-FT

e-prescribing prior art

Hi,
Whenever I hear that someone was doing Health IT a long-long time ago, I always suggest that they find copies of their old code and post them online so that we can have a strong source of prior-art to fight software patents with.

Recently, Bob Paddock took me seriously and dug up some invaluable prior art on automated prescribing. Today he sent me the results, including scans of printouts of both the printed prescriptions and the source code that made them. All of it with a date so long ago that it would invalidate any still active patent covering those subjects.

Bravo,

-FT

Stick your neck out

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:


Can I ask the question: 9 months after having going out of my way to
make it available as Free Open Source to try to provide this community
with a state of the art tool for Ajax development, is *anyone*
actually using EWD with VistA yet?  I have to be honest and say that I
do wonder sometimes why I bothered.  All I seem to hear is reasons why
people haven’t used it or don’t use it.

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

The iphone, a poor HIT platform analogy

Recently, a NEJM perspective article titled No Small Change for the Health Information Economy advocates that a Health IT platform should be created in imitation of some of the successful technology platforms in other areas. Specifically the iphone was mentioned. The relevant paragraph:

The Apple iPhone, for example, uses a software platform with a published interface that allows software developers outside Apple to create applications; there are now nearly 10,000 applications that consumers can download and use with the common phone interface. The platform separates the system from the functionality provided by the applications. And the applications are substitutable: a consumer can download a calendar reminder system, reject it, and then download another one. The consumer is committed to the platform, but the applications compete on value and cost.

The whole article is worth a read, there are some pretty invaluable fundamental insights that are provided here that are right on. However, there are problems with the iphone app universe. Imitating that universe will require that those problems find new solutions. The NEJM article recognizes some of these implicit difficulties, and suggests that the solution is for the government to step in and evaluate individual applications.

Here is a quick list of things that are true about the iphone that really should not be true in a HIT platform:

  • Apple plays favorites. Alot. Google was given special access to forbidden APIs for a voice application. Nike is another great example of company that created an application that has special privileges. It gets to have device integration that no one else gets. From Apples perspective these kind of things are acceptable because they create a user experience that is excellent. But it is not fair to developers. Developers who do not have the clout of Google or Nike know that they might be blown out of the water by a special deal that Apple might make with a bigger partner. It creates risk to developers and alot of resentment. Playing favorites gives Apple a short term advantage but ultimimately prevents a true meritocracy from developing. A Health IT plaform has to be truly open, and not play favorites.
  • Apple protects its cash cows at the expense of innovation. Google Voice could have broken the back of the AT&T price for SMS messages, which can cost about $5000 per megabyte . It was rejected by Apple because it hit them in the cashflow. But Google Voice is probably one of the most fundamentally innovative technologies to appear in a long time. A Health IT platform will need to find a way for this kind of blatant incentive problem from occuring. Its harder then you might think.
  • Apples approval process is inscrutable. Sometimes applications are rejected for content, even though that content is already available through Apple elsewhere. The approval process is slow, painful and does not make sense most importantly people hate it. The problem is that you have to have an approval process, and the reason that Apple is so closed about the process, probably has to do with the unpleasantness of watching sausage get made. It is not trivial to have an approval process that is fair and open, while also ensuring that developers do not abuse users. It takes time, which means money and it is not clear where that money will come from in a Health IT platform.
  • Apple is a locked-in provider of software. This can easily be fixed by jail-breaking your iphone, so that you can easily download apps from other sources. Apple limits the source of downloads for a reason, you can download anything with an jail-broken iphone… even things that will make your iphone much less stable. How do you ensure that applications are trustworthy, without having an exclusive source? Tough one.
  • Apple forbids creating applications that replicate core functionality. Which is exactly the opposite of what you want to do with a Health IT application. But no one will use the system unless you provide high-quality initial applications.

So is the iphone system, as an ideal, is fine to emulate. But you can see where your problems might be with such a platform by looking carefully at the problems that Apple is dealing with.

This is not really a criticism of the authors of the NEJM article… who, for instance, already see that the platform needs to be open source, addressing many of the problems that Apple is having by default… this is just to point out that all is not well in Apple land… analogies have their limits.

(update 9-01-09 I should talk about the iphone more often, this article has generated more comments, faster than anything I have written in years. One comment particularly stands out. Piyush Daiya over at androidmedapps.com has provided a very careful analysis that shows that Andriod is a better embodiment of the ten principles, that the NEJM authors endorsed. He is 100% right-on about that, and I wish I had thought to point that out myself. Thanks for reminding me, Piyush…)

-FT

Multiple Merged Monitors the nightmare

I use GNU/Linux on the desktop. This is for both ideological and practical reasons. I develop FOSS Health Software, and my preferred languages work best on GNU/Linux.

I also believe in Software Freedom.

Sometimes I will use proprietary software, if it is obvious that I need to do that in order to 1) further the overall FOSS in Healthcare movement or 2) put food on the table.

It was with some reservation that I have used the nvidia proprietary drivers in order to get three monitors working. I have used Red Hat for years and I usually like to use the latest version of Fedora for my desktop. However, I do not like upgrading as often as Fedora releases. I often get two or three versions behind. I had three monitors working as a single merged desktop on Fedora 9. Almost immediately after Fedora 9 went unsupported, (1 month after two higher versions existed with Fedora 11) an yum update of the livna rpms crashed my desktop.

Since then I have been scrambling to get a working multiple monitor, with merged desktop working.

This has been a painful, brutal process. I have tried two generations of 4 different major distros. I have bought and entirely new computer. In the end I ordered two huge Dell monitors because I could only get two monitors to work at one time.

I will spare you the minuta of what did and did not work. Here is what I discovered during my three month ordeal:

  • Multiple Monitor, merged desktop, and Multi-head support is one of GNU/Linux’s greatest weaknesses.
  • Multiple Monitor almost never works out of the box.
  • Debugging Multiple Merged Monitors is a nightmare.
  • Searching for solutions is painful. Almost infinite software and hardware version differences makes what you find almost always useless.
  • While x.org is advancing, it is a very poorly managed project.
  • Nvidia is making development so painful with proprietary licenses that they should be boycotted.
  • By using nvidia’s drivers, rather than participating in efforts to replace them I have been making the problem worse.

I should know better. If I can help it, I will never use a proprietary GNU/Linux module again.

-FT

DocOliver

I have convinced my good friend and partner in healthcare reform, Dr. Cari Oliver, to start a blog.

She will now be talking about her ideas regarding patient engagement/empowerment/involvement/safety at docoliver.com

Whenever someone asks me “how do you do it” for blogging, I always tell that the secret is to have something to say about something specific.

For instance, here on FredTrotter.com you will get a steady stream of information about Open Source Software in Healthcare, and all things related to it. Thats a pretty broad brush that lets me talk about politics, healthcare, and healthcare IT along with Open Source in Healthcare. My readers know that if they visit or subscribe to my feed, they will generally get information about what is going on in the FOSS Healthcare world, with a generous dose of helpful bias.

At DocOliver.com you can expect to hear about how a patient -should- engage in their own healthcare, and -how- they can use Health Information tools to do it. If I had written the tagline of Doctor Olivers site, it would be “Making PHRs actually do something useful for you”, but she tends be a little more disciplined and careful with her prose than I am.

-FT