Three Things That Health Care IT Can Learn From Open Source

Why I care

I have been involved in the open source world for several years as a hobbyist. But in my paid work, I have spent the last year immersed in the development of a health care system that is trying to comply with standards and be interoperable. Along the way, I’ve noticed several things that I feel that health care IT is not doing as well as it could. Health care is an important, even central part of our lives, and it seems to me that making health care IT as good as it can be should be a priority.

Here are three open source principles that I think would make health care IT better.

1.    Don’t fork; push it upstream

Terms like “forking” and “upstream” are fairly common in the open source world. The origin of a project, the original developer or development team, is considered to be “upstream” of everyone who uses that project in their own projects. When someone wants to modify a project for their own uses, they are generally encouraged to try to “push the changes upstream,” that is, try to get the original developer to add the changes to the original project, so that everyone can have them. The other option, “forking,” is generally discouraged. If you fork a project, you are taking it, modifying it for your own use, and then keeping the changed version as a separate project. This means that any changes are kept away from the upstream project, and if changes are made upstream, they are not likely to be incorporated into the fork. Forking usually happens when there are problems between the upstream project and a downstream developer, or if the upstream project has become inactive.
In health care IT, forking seems to be the norm. There is a general feeling that the upstream projects are not responsive to input and are very slow to change or improve, and so developers tend to make local changes to the standards rather than improving the standards themselves. This isn’t limited to individual companies, either. There tends to be regional and national versions of the standards that are full of changes that should have been pushed upstream. These changes have little or no relation to region-specific situations; rather, they tend to be local workarounds to limitations discovered in the upstream standards. Others create competing standards that claim to fix problems with the current standards, and then lobby the standards bodies to adopt their standards instead.
Healthcare IT could greatly benefit from the open source model of pushing changes upstream instead of forking.

2.    Build a stack; use modules and plugins

Perhaps because it grew out of the Unix world, open source is all about building a solution from many small pieces that are stacked and plugged together, rather than trying to build a monolithic solution that encompasses every use case. This is analogous to using interchangeable, snap-together pieces to build a toy, rather than making a single, proprietary mold for each toy. The modular approach allows a great deal of flexibility and allows many different use cases to share a great deal of common code. Also, upstream changes are much easier to implement, as they tend to affect only the users of a particular module, rather than affecting all users of the project.
Health care IT tends to rely heavily on global, proprietary systems and standards. The system or standard is expected to encompass all use cases, and single vendors or standards are expected to manage the whole system. There is very little use of modularity in health care IT. This contributes to the first problem (forking), because any change affects the whole system, rather than a small piece of the system. So if a particular use-case is not included in the existing system or standard, a whole new version of the system or standard needs to be created to handle the new use case, rather than creating a new module to “plug in” to the existing system.

3.    Share your work

One of the fundamental principles of open source, perhaps the most important principle, is the belief that developers should share their code. From the licenses that require users of the code to keep it open, to the open repositories where the code is stored, open source developers passionately believe that code should be free, and open, shared code benefits everyone in the end.
Historically, health care IT has been very reluctant to open up their systems and their standards. Often using patient privacy as an excuse, vendors have charged high prices for “interfaces” that expose small pieces of their data to other systems. Standards bodies have put their standards behind paywalls and have made it clear that users of these standards need to pay to license the technology. Because health care systems and standards tend to be monolithic rather than modular, vendors can control the entire system, and demand high prices for any changes.

Going Forward

Large, profitable companies, like Samsung or IBM, that have begun participating in open source have discovered that following open source practices, like pushing upstream, building modularly, and sharing their work may not be the obvious way to be profitable, but it quickly becomes evident that open standards and systems benefit the entire industry, which in turn benefits the individual vendors. Open standards and systems encourage competition and innovation, which in turn improve the quality of all the systems and standards. This is the kind of upward spiral that health care desperately needs.
The ship of health care IT is big, bulky, and hard to turn, but I believe it desperately needs to change course. If the industry cannot change course, the alternative is frightening. There are many icebergs looming in the dark.