To state the obvious, open-source software (“OSS”), also called “free, open-source software” (“FOSS”) is everywhere. (I’ll use “OSS” in the rest of this article for consistency.)
OSS packages keep the Internet operating, and nearly every company and government agency uses OSS. Literally every computer user globally relies on OSS to function. This is hard to wrap one’s brain around, but this OSS ubiquity did not happen overnight.
OSS: A 50-year Overnight Success
IEEE has an excellent article reviewing the detailed history and evolution of the OSS movement. Notable highlights:
- Unix, the commercial operating system released in 1972 that is the inspiration for Linux, catalyzed the creation of an open-source Unix clone called “BSD Unix” by a consortium of universities in the late 1970s. (If I were to admit my vintage, I would reveal that I was an undergraduate user of BSD Unix in that era.)
- Linux, in its many flavors (called “distributions”), is the software backbone of the internet. Linux was first released in 1992.
- More recently, Linux was added to Microsoft Windows operating system releases (as Windows Subsystem for Linux – “WSL”).
- Apple’s MacOS and iOS (which are not open-source) can trace their lineage directly to Unix/Linux.
I’m not sure what is more shocking to me, that Unix is over 50 years old, that I am old enough to have used BSD Unix, or that the open-source software most of us are more familiar with in this internet era has already been around for decades.
OSS in Health IT
Given the close integration between healthcare and academic/research institutions, it is not surprising that OSS is prevalent in health IT. A quick search on GitHub for “healthcare” returns over 60,000 repositories. It’s a fair bet that there are thousands more health IT OSS projects that are either not on GitHub or don’t have the “healthcare” keyword in their descriptions. That is a lot of energy being spent on OSS for the healthcare space.
A couple of prominent projects focused on day-to-day clinical settings are OpenMRS and OpenEMR, which are both widely deployed outside of the US.
Nevertheless, few hospitals or outpatient practices in the US use open-source Electronic Health Records (EHR) systems such as OpenEMR or OpenMRS, so OSS is not ubiquitous for mission-critical/patient-facing clinical applications in the US.
Why is that?
To understand this, a comparison with the financial industry is helpful. Searching GitHub for “finance” returns almost 160,000 OSS projects. Granted, “finance” can mean personal budgeting apps, stock-picking algorithms, hedge fund systems, hobby projects and many other specialities, but let’s just arbitrarily say that half, or 80,000, of those OSS projects are applicable to the things financial institutions like banks and investment firms need to run their operations.
As mentioned above, most companies use OSS packages, and this is true for financial firms. However, very few (if any) of such firms use an open-source system to run their business, because they need more control over functionality and customization than and off-the-OSS-shelf system provides. Put another way, it requires more effort to adapt an OSS system than it does to either use a commercial system tailored to their specific needs or (for larger firms) to write and maintain their own systems.
That open-source EHR systems are not widely adopted by US providers is an example of OSS not being the best model for all software in healthcare.
Another input into these decisions is risk. The landscape is littered with abandoned OSS projects, so system stakeholders (those responsible for maintaining the systems, along with the business people paying for them) don’t want to get burned by a broken or unmaintained open-source project putting their operation in jeopardy. This brings us to the two sides of OSS.
The two edges of the OSS sword
The vast majority of OSS projects are volunteer efforts. On one hand, this is awesome: Talented developers are collaborating to create software that can be used by anyone. That’s an amazing expression of the better side of human nature. On the other hand, people’s lives and priorities change; that’s the reality of being human. The most vibrant OSS communities (the group of developers, called “maintainers,” who contribute code to the project) are able to add new maintainers as others move onto other things, but many OSS projects are the work of just a few people (and sometimes only one).
In 2016, the lone maintainer of leftpad, a package used by pretty much the entire internet, became burned out by all that effort and called it quits. But he didn’t just quit; he removed his package from NPM, a popular source of OSS packages, and that broke the internet for a few hours. That is an extreme example, but OSS packages get “deprecated” all the time.
In the early days of US healthcare interoperability, the Federal Health Architecture (FHA) group of US federal agencies paid for the development of CONNECT Open Source as a “gateway” application to enable Nationwide Health Information Network (NHIN) participants the ability exchange healthcare information using the NHIN interface specifications. (NHIN evolved to become the eHealth Exchange under Sequoia.) CONNECT was a great way to bootstrap interoperability efforts, so from an initial ROI perspective, one could argue that FHA made a sound investment.
On the other hand, sponsor-funded OSS projects eventually run out of that funding, and this happened with CONNECT. Just one day following ONC’s in September 2019 announcement of a “Transition to the Private Sector,” the CONNECT project on GitHub was archived. Firms (and federal agencies) certainly had the option to use their own fork of CONNECT, and some may be, but they are now funding those efforts as closed-source initiatives.
In our space of healthcare system interoperability validation, there are a handful of OSS projects out there, and nearly all are sponsored by taxpayer money. Until they aren’t.
In today’s frothy government funding environment, it is impossible to predict how long OSS project sponsorship will last.
When OSS Doesn’t Make Sense
The AEGIS team hears a lot of pushback about Touchstone, anchor of our FHIR conformance validation ecosystem, not being open-source. We do understand the proclivity to OSS in the Health IT community, but the OSS model does not always make sense. In the case of Touchstone, we think about this in two ways.
- Financial Sustainability – We are in this for the long haul, but we don’t have unlimited funds, so the zero-cost OSS financial model does not support this commitment.
- Scope – Touchstone is not just a code repo; it is a managed service built around that code and supported by a team of FHIR experts with deep experience since the earliest days of interoperability.
Touchstone is a managed service, not just software, so the OSS model does not make sense.
Again, we celebrate open-source, but OSS is not good fit for all software-based offerings.
When OSS Does Make Sense
One piece of our FHIR conformance validation ecosystem is WildFHIR, our FHIR server that acts as a reference implementation (RI) for numerous FHIR use cases and IGs.
We recently released WildFHIR Community Edition (WildFHIR CE) as OSS, and we are collaborating with implementers and the HL7 Foundry team to create a vibrant OSS community around WildFHIR CE.