This series examines the importance of community and what steps are being taken by open source projects in health IT to create communities around their projects. My previous posting covered VistA and its custodial organization, OSEHRA. The last article in this series covers some important projects in open source with very different approaches to building community.
In addition to VistA, the electronic health record with the most success in building community is OpenMRS, using a unique approach. The project has an unusual genesis. They didn’t come out of a technology center such as Silicon Valley, or a center of health research such as my own Boston. Instead, they were inspired by the Regenstrief Institute at Indiana University.
Getting only a small amount of attention in the United States, OpenMRS proved quite valuable in the developing regions of Africa, especially Rwanda. The U.S. developers realized right away that, for their software to be useful in cultures so far from Indiana, it would have to be understood and fully embraced by local experts.
Indeed, a number of accomplished software developers can be found in Rwanda and surrounding countries. The challenge to OpenMRS was to attract them to the goal of improving health care and to make work on OpenMRS easy.
OpenMRS not only trained developers in African countries to understand and adapt their software to local conditions, but mentored them into becoming trainers for other developers. The initial project to train Rwandan developers thus evolved, the local developers becoming competent to train others in neighboring countries.
In this way, the OpenMRS developers back in the U.S. opened up the project in a unique way to people on other continents. To be sure, the developers had a practical end: they knew they could not provide support to every site that wanted to install OpenMRS, or adapt it to local needs. But they ultimately created a new, intensely committed, international community around OpenMRS. Regular conferences bring together OpenMRS developers from far-flung regions.
The SMART platform is not an EHR itself, but an application programming interface (API) that its developers are asking EHR vendors to adopt. The pay-off for adoption will be that all compliant EHRs can interoperate, and a software developer can write a single app that runs on all of them. SMART was developed at Harvard Medical School with support from ONC. It now runs on top of FHIR, an HL7 project to provide a modern API giving access to all EHR data.
EHRs are not by any means the only community-building efforts in open source health IT. Another significant player is Open Health Tools, which came into being in recognition of the creative work being done by research firms, university professors, and others in various health IT areas.
OHT brings together a wide range of developers to build software for research, clinical work, and other health-related projects. It’s remarkably diverse, providing a meeting place for all projects interested in making health care technology work better. Although they have had problems finding financial support, they now solicit dues from interested projects and seem poised to grow.
For a while, OHT had grand visions of recruiting their members to contribute to a unified “framework” on which other software developers could build applications. This proved to be a bit too big a bite to chew, given the wide range of activities that go on in health IT. But OHT still encourages members to find common ground and make use of each other’s advances.
Aaron Seib, CEO of Open Health Tools, listed the main goals OHT has for its member developers: making communities discoverable, making their licensing intelligible, and addressing the intellectual property barriers that can constrain a project’s adoption. OHT also helps establish trust and connect the dots among the community members to multiply effects across member communities. Roger Maduro of Open Health News writes that OHT has played a critical role in building the open health ecosystem, including the VistA community.
Many other institutions also sense a need for community. A few years ago I spoke with John Speakman, who was working for the National Cancer Institute at the time. They had developed some software that was very popular among developers, but no one made any contributions back to the common software base, and the NCI wanted the users of the software to start taking responsibility for the tools on which they depended. He took on the task of building community, but left when he realized it was not going to take hold.
Among the problems was the well-known dependence of government agencies such as the NCI on contractors. Speakman points to an organizational and cultural gap between “the big Beltway Bandit companies (who will never use the code themselves to do biomedical science) over academic groups engaged in biomedicine.” He also thinks the NCI intervened too much in community activities, instead of letting community members work out disagreements on their own. “If the government is going to invest in the seeding of open source communities,” he says, “it has to (a) focus on releasing the data and see what folks do with it, and (b) use as light a hold as possible on how the communities run themselves.”
Athenahealth stands out among EHR vendors with its More Disruption Please program. There it is building an ecoystem of third-party tools that its customers can use as part of its cloud-based service. This goal is similar to that of the open source SMART platform, which is trying to get EHR vendors and other data stores to adopt a common API and thus make themselves more open to software developers.
Openness and community go together. Although the health IT field is slow to adopt both practices, some projects could be entering into a virtuous cycle where open source developers learn to appreciate the value of their communities, which in turn reward the most open projects with greater success.