Public health requires effective informatics tools to support improving the health of a community. Appropriate epidemiological response to noncommunicable and communicable disease, including sexually transmitted infections, depends on disease identification with subsequent individual case investigation and contact tracing. Public health informatics tools must mirror these complex workflows, be able to access and evaluate real-time data, and be both interoperable and highly flexible to meet diverse disease reporting requirements and responses. Domestically, there are limited informatics tools built specifically for public health. Here we explore how open-source technologies can support public health initiatives in the United States by highlighting the benefits and challenges of open-source approaches and outlining how public health authorities can approach open-source software.
DEFINING OPEN SOURCE
Open-source software exists in many fields to help different organizations come together to meet their needs and to share knowledge and resources. Although most people associate open source with the software products created, open source is also a philosophy and approach to working together. Open-source software is any software that uses an open-source license.1 An alternative to open source is “proprietary” software, where one company owns and controls the code entirely.
We argue that there are 3 key pillars to a well-functioning open-source project: it allows anyone to freely use or contribute rather than being controlled and maintained exclusively by 1 company or a closed group. The source code should be easily accessible by anyone. To protect the software from manipulation, there should be a transparent decision-making process for accepting contributions that involves both developers and software end-users. Strong open-source ecosystems have well-defined and transparent governance frameworks, or processes for self-management, that enable anyone to create peer-reviewed contributions to the shared software, rather than changes being controlled by a single entity or a closed group.
BENEFITS OF OPEN SOURCE
Government agencies at all levels can benefit from using open-source software. By working with an open-source project, a public health authority can take advantage of work done by others to solve common problems and contribute back to those same projects. This can save time, money, and human resources, and generate additional benefits including flexibility to meet new needs, transparency, shared best practices, and community support for problem solving. Because the software can be viewed and enhanced by anyone, there are opportunities to distribute the work of improving the code and collaborate on identifying bugs and vulnerabilities.2
Open-source software procurement benefits from a lack of being obligated to a vendor. The standard model for government agencies working with open source is to select an open-source project and separately select an implementation vendor or service integrator to deploy and maintain the software. Sometimes the implementation vendor is internal to the government, such as a digital service agency. Because the software and code is openly available for anyone to use, if a relationship with an implementer does not meet the agency's standards, they can terminate the vendor contract and switch without having to also install new software and conduct a data migration. In contrast, proprietary software usually requires losing access to the software when switching vendors.3
Open-source software also provides additional advantages. The code is easy to access, which means that it can be shared with implementation vendors during procurement. When additional capabilities are required, the enhancement process is well documented, and it may be quicker to get new features added.4 US public health authorities have mentioned to us that their experience when using open-source software leads to fewer surprises and additional expenses overall than when working with proprietary providers.5
In addition to the open-source software communities and projects, there are some cross-project organizations that provide support for open-source projects to ensure that best practices are being followed.6 That support can include community management and coaching, fiscal and operational support, open-source education and understanding for use in public and clinical health, and more. There is usually a higher standard that the projects within these organizations adhere to, giving public health authorities greater levels of confidence that they can move forward with this software. Some high-quality hosts of open-source projects include Linux Foundation Public Health, the World Health Organization, and the United Nations Development Program. In global health, there is a collection of software labeled as “global public goods” that also adhere to open-source standards.7,8
CASE STUDY: OPENMRS
There are many case studies of good open-source informatics tools used in public health with a wide range of project maturity across various public health applications.2,9–12 One of the strongest functioning and long-standing open-source health software projects is OpenMRS, an electronic medical record system that was initially developed for HIV monitoring and management and has expanded to become a key tool for public health authority decision making in resource-constrained settings.12,13 OpenMRS is currently implemented in public health programs with more than 6700 health facilities across 40 countries.14
OpenMRS offers a strong example of the agility and sophistication that good, open-source software can provide an agency. OpenMRS was developed in 2004 to ensure that data were available for clinical care decision making and local and national public health reporting and tracking. It meets the public health needs of case investigation, electronic case reporting, and longitudinal monitoring of disease. With ongoing engagement from the public health domain, OpenMRS has become a scalable and user-driven platform. Its open-source design has been leveraged and configured to meet clinical and public health needs in a variety of environments. The software can also be quickly customized in response to changes in disease patterns as seen in a recent case study from Kenya, where, in only 1 week, a small team launched a COVID-19 module that included disease tracking and epidemiological investigation without reliance on vendors or external resources.15
COMMON CHALLENGES OF OPEN SOURCE
Although there are many advantages to open source, it is not always the ideal choice.16 Open source should not be chosen when there is not a well-functioning project available to join, unless the public health authority has the capability to invest in growing and improving a project, including bringing in other jurisdictions to use the software. Open source should be selected when the agency is able to use the code without much customization and can work on the timelines of group decision making or has their own resources for customization. Finally, open-source code should get the same level of scrutiny and security review as any proprietary software.
Open-source implementations can easily go awry with overcustomization of the software by a public health authority. When this happens, the health authority becomes responsible for maintaining their custom version, increasing maintenance costs.17 They also may lose easy access to the improvements from others in the community. Strong open-source software embeds settings in the original code to allow for specific configurations, which keeps organizations from needing to customize on their own.
Another risk is when the open-source software is operated by a single vendor who does not accept code changes from other sources. Although this software may be high quality, development and innovation speed is limited to the capacity of what that single vendor can contribute. A second version of this issue is when the code is viewable only to a prevetted, small community, which more resemble co-ops than open-source communities.18 In either case, the software lacks the power of many people working on a mission together, limiting the amount that can be accomplished.
Finally, open-source adoption is limited by the false perception that open-source systems are error-prone and less secure.19,20 Open-source software transparency means that bugs and vulnerabilities are visible, as opposed to proprietary systems where issues can be hidden.16,19 Healthy, open-source software projects should require that contributors and maintainers actively look for software problems or hire an outside organization to do security testing, the same as with any proprietary system. In addition, although the code is available for all to see, the implementation by any particular agency would still be protected, meaning that the databases used would be subject to the same level of security and confidentiality as other systems. No personal health data are exposed owing to the codebase being open source.
GETTING STARTED USING OPEN SOURCE
There are many aspects to consider when selecting an open-source software. Many of them are similar to concerns with a proprietary procurement process; hereinafter, we highlight some specific considerations (Table 1).
TABLE 1.
A Quick-Start Guide of How to Get Started With Open-Source Software
| Step | Considerations for Evaluation |
|---|---|
| Define software objectives and use cases | • Objectives of the software align with agency objectives • Software able to meet most of the selection criteria • Agency has limited unique needs |
| Define technical requirements | • Requirements consistent with what agency can support • Includes commitment to modern software architecture • Integration of common data and messaging standards |
| Conduct vendor selection process | • Familiarity with agency operations • Familiarity with preferred open-source software • Commitment to agile software delivery process • Willingness for long-term relationship to support the solution |
| Review open-source software license | • License allows program objectives to be achieved • License allows for variation in case the agency needs to diverge from the core software |
| Check for software maturity | • Within public health environment: number of deployments; number of users; are current deployments aligned to agency objectives • Maintainers and contributors come from a variety of companies and organizations • 100% of source code publicly viewable |
| Evaluate governance | • Well-documented governance process • Ability for agency to engage in governance if desired • Actual governance operations align with published process |
| Community | • Well-documented paths for community participation from both technical and nontechnical people • Viable community with shared vision • Stated public health commitment |
To ensure appropriate selection of an open-source solution, it is critical to define and understand the problem to be addressed. Establish use cases and objectives of the tool to guide the required features for selecting a solution.3 There should be additional criteria from the technical and community support perspectives.
After outlining specific requirements, the next step is to compare the requirements with what exists in current open-source solutions. To find software worth considering, searches on Google and GitHub can be useful, but networking is often most effective. Talking with peers at other agencies and connecting with the technology teams at supporting organizations such as Association of State and Territorial Health Officials, Council of State and Territorial Epidemiologists, and Linux Foundation Public Health are pathways to learning more. In addition, the Centers for Disease Control and Prevention runs an open-source resource at open.cdc.gov.
Selecting software requires understanding the governance model, as this defines how additional capabilities get added. When evaluating a particular software, make sure to understand the change management process and how requests are handled. These should be clearly documented in a public place and include review from public health experts within the community, not just a technical team.
In terms of cost, open-source software does not mean that it is free.21 Organizations may still need to outsource software implementation and hosting, and these costs could be similar to proprietary software. Any cost savings are realized with the elimination of ongoing licensing fees and possibly some support and maintenance costs, depending on the capacity of the organization.16 Note, however, a recent, compelling study by the European Union estimated a high cost-benefit ratio for open-source software finding that with increased investment “the public sector could reduce the total cost of ownership, avoid vendor lock-in and thus increase its digital autonomy.”22
A vendor who can support the implementation and maintenance of the software will be a key partner on any open-source journey. It is best to select a vendor who has prior experience with the codebase or a vendor who is already familiar with the inner workings of the agency. The vendor, in collaboration with agency staff, can also assist in helping choose a quality open-source solution to work with.23
TAKE THE FIRST STEP
One great benefit of open source is that the software and communities of practice supporting them are public, intent on sharing software, knowledge, and experiences. Open-source solutions have the potential to give public health authorities around the United States greater access to quality software while increasing transparency, cross-agency collaboration, and lower total cost of ownership. This can only be achieved by agencies implementing open-source software, sharing their experiences, and therefore, helping to improve the quality of the open-source communities available for public health use.
The best ways to learn more about open source are by reviewing the Web sites, joining a discussion forum or attending a community meeting, talking to implementation vendors involved in solutions, and connecting with other public health workers about their experiences. Consider learning by working to contribute directly on an open-source project. Public health authority staff experience as a subject matter expert is an essential and sufficient contribution, and software expertise is not required. Direct involvement will rapidly facilitate understanding of how open source may support an agency's public health program.
Footnotes
Conflict of Interest and Sources of Funding: None declared.
Contributor Information
Jenny Wanger, Email: jwanger@linuxfoundation.org.
Theresa Cullen, Email: Theresa.Cullen@pima.gov.
Elizabeth L. Dunbar, Email: edun@uw.edu.
REFERENCES
- 1.Open Source Initiative. The Open Source Definition. Available at: https://opensource.org/osd. Accessed February 28, 2022.
- 2.Oza S Jazayeri D Teich JM, et al. Development and deployment of the OpenMRS-Ebola electronic health record system for an Ebola treatment center in Sierra Leone. J Med Internet Res 2017; 19:e294. [DOI] [PMC free article] [PubMed] [Google Scholar]
- 3.Carnahan R, Hart R, Jaquith W. State Software Budgeting Handbook. 18F, Technology Transformation Service, General Services Administration; 2019. Available at: https://derisking-guide.18f.gov/state-field-guide/basic-principles/#modular-contracting. Accessed February 27, 2022.
- 4.Advani A Turuvekere AM Liu C, et al. Design and assessment of a common, multi-national public health informatics infrastructure to enable H1N1 influenza surveillance. Stud Health Technol Inform 2010; 160(Pt 1):452–456. [PubMed] [Google Scholar]
- 5.Jenny Wagner at Linux Foundation Public Health—Public Health Advisory Council Meeting. August 25, 2021.
- 6.Izquierdo JLC, Cabot J. A Survey of Software Foundations in Open Source. arXiv [csSE] 2020. Available at: http://arxiv.org/abs/2005.10063. Accessed February 27, 2022. [Google Scholar]
- 7.Digital Square . What Are Global Goods. Available at: https://wiki.digitalsquare.io/index.php/What_are_Global_Goods. Accessed February 28, 2022.
- 8.Digital Square . Global Goods Guidebook Version 2.0. 2021. Available at: https://static1.squarespace.com/static/59bc3457ccc5c5890fe7cacd/t/6061f423e9c30f0939b94873/1617032231588/Global+Goods+Guidebook+V2_update+29+Mar+2021.pdf. Accessed February 27, 2022.
- 9.Case Based Reporting Module . OpenMRS Wiki. Available at: https://wiki.openmrs.org/display/docs/Case+Based+Reporting+Module. Published 2019. Accessed February 27, 2022.
- 10.Bhattacharya AA Umar N Audu A, et al. Quality of routine facility data for monitoring priority maternal and newborn indicators in DHIS2: A case study from Gombe State, Nigeria. PLoS One 2019; 14:e0211265. [DOI] [PMC free article] [PubMed] [Google Scholar]
- 11.Muinga N Magare S Monda J, et al. Implementing an open source electronic health record system in Kenyan health care facilities: Case study. JMIR Med Inform 2018; 6:e22. [DOI] [PMC free article] [PubMed] [Google Scholar]
- 12.Mamlin B, Cullen T. Public health decisions using point of care data from open source systems in Africa. Onlne J Public Health Inform 2018; 10. [Google Scholar]
- 13.Verma N Mamlin B Flowers J, et al. OpenMRS as a global good: Impact, opportunities, challenges, and lessons learned from fifteen years of implementation. Int J Med Inform 2021; 149:104405. [DOI] [PubMed] [Google Scholar]
- 14.OpenMRS Website. Available at: https://openmrs.org/. Accessed March 7, 2022.
- 15.Mamlin BW Shivers JE Glober NK, et al. OpenMRS as an emergency EMR—How we used a global good to create an emergency EMR in a week. Int J Med Inform 2021; 149:104433. [DOI] [PMC free article] [PubMed] [Google Scholar]
- 16.Reynolds CJ, Wyatt JC. Open source, open standards, and health care information systems. J Med Internet Res 2011; 13:e24. [DOI] [PMC free article] [PubMed] [Google Scholar]
- 17.Charles SH, Weinstock CB. Open Source Software: The Other Commercial Software. In: 1st Workshop on Open Source Software at ICSE. 2001. Available at: https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.16.8802. Accessed March 8, 2022. [Google Scholar]
- 18.Jaquith W, Carnahan R. Sharing Government Software: How Agencies Are Cooperatively Building Mission-Critical Software. Washington, DC: Beeck Center for Social Impact and Innovation, 2021. Available at: https://beeckcenter.georgetown.edu/wp-content/uploads/2021/04/Sharing-Government-Software_Final.pdf. Accessed February 27, 2022. [Google Scholar]
- 19.Hoepman JH, Jacobs B. Increased security through open source. Commun ACM 2007; 50:79–83. [Google Scholar]
- 20.Schryen G. Is open source security a myth? Commun ACM 2011; 54:130–140. [Google Scholar]
- 21.Nagy D, Yassin AM, Bhattacherjee A. Organizational adoption of open source software: Barriers and remedies. Commun ACM 2010; 53:148–151. [Google Scholar]
- 22.Blind K Böhm M Grzegorzewska P, et al. The Impact of Open Source Software and Hardware on Technological Independence, Competitiveness and Innovation in the EU Economy: Final Study Report. Brussels, Belgium: Directorate-General for Communications Networks, Content and Technology, 2021. Available at: https://op.europa.eu/en/publication-detail/-/publication/29effe73-2c2c-11ec-bd8e-01aa75ed71a1/language-en. Accessed March 10, 2022. [Google Scholar]
- 23.Jaquith W, Hart R, Hopson M, McFadden V. An Agile Software Development Solicitation Guide. Available at: https://18f.gsa.gov/2019/08/20/an-agile-software-development-solicitation-guide/. Published August 20, 2019. Accessed February 27, 2022.