In six weeks, a team of three college students with no industry experience and only academic software-specific knowledge, developed and designed a health care provider search system using only open source software. To tell you how they got there, let's start with a little history of open source software in the US federal government workspace.
The open source software (OSS) movement has grown and matured over the past four decades. What first began as a strategy by Bell Laboratories to recruit pre-trained college students who had hard to find UNIX skill sets, has blossomed into an alternative to the "cathedral" approach to software development. This movement gained momentum, particularly after development of Linux in the early 1990s, and use of the open source approach for production of high quality, innovative software has grown exponentially. Despite this impressive track record, and some notable exceptions, OSS has been generally avoided as a viable software alternative within the US federal government sector. The objections to OSS are based primarily upon two pivotal concerns: security and lack of support.
While anxieties over security issues continue to persist, they seem to have lost a good deal of credibility. In 2001, the National Institute of Standards and Technology (NIST) adopted the Federal Information Processing Standard (FIPS) 197. FIPS 197 used the Rijndael algorithm for both its encryption and decryption. The algorithm was publicly published by NIST, and for three years prior to its adoption cryptanalysts from around the world were invited to try to defeat it. Their efforts were not successful.
In 2007, Actuate (co-founders of the BIRT Open Source Project) reported that a continuing impediment to Federal adoption of open source software (OSS) was the widespread perception that it still lacked the capacity to provide long-term support. There is considerable foundation for this latter assertion. Its earliest practitioners were generally more interested in the programming problem-solving challenges associated with OSS than the mundane and tedious task of documentation and training. When training and documentation did come, it was more often in the form of informal exchanges via email, rather than in the form of formal, well-written documentation. It almost always assumed the user had a base level of technical understanding. Moreover, regardless of the availability of training and documentation, while OSS was "free" in a monetary sense, it was not free in the broader sense of individual time and effort. Organizing and implementing a cogent training curricula was hard to imagine.
From a governmental perspective—making the difficult transition from a manual paper-based bureaucracy to a technology-based bureaucracy—this made the adoption of OSS problematic. And despite the current use of sophisticated OSS programs in the public sector (i.e., Apache Tomcat, Apache Hadoop, Linux, PostgreSQL, Drupal, and Google Earth), the assumption continues that OSS support is not readily available. Oddly enough, countering these perceptions through the well-distributed documentation of OSS project outcomes has not been a high priority within the OSS community. The experiment that this business case analysis reports is intended as a small step forward towards rectifying what we consider a flawed point-of-view.
The experiment
In response to the HHS final rule on the Administration Simplification provisions under HIPPA, the National Provider Identifier (NPI) was initiated in May 2007. Its purpose was to provide a standardized approach for electronic HIPPA transactions, unique and intelligence free health provider identifiers, and the efficient coordination of health benefit transactions.
Legacy provider identifiers such as a Unique Provider Identification Number (UPIN), Online Survey Certification & Reporting (OSCAR), and National Supplier Clearinghouse (NSC) were replaced by a single, common identifier for all HIPAA standard transactions. Billions of state and federal dollars have already been spent on making this mandated transition. It appears that much of the software development for this effort will be accomplished with Commercial-off-the-Shelf (COTS) software and applications. Could a small team of college students with no industry experience and no professional software-specific knowledge, develop and design a useful health care provider search system using only OSS?
A remote team of six college students were recruited, as interns from the University of Central Oklahoma and from North Carolina A&T State University, to determine whether such a goal was feasible. Using current professors from each of the respective universities, a syllabus was circulated to students for a guest lecturer credit course: Web Site Application Development Through PHP Programming.The course focused on taking publicly available health care data from the Federal government and making a web application of that data available to the public. The team was given the functionality requirements by the project manager. The team took the requirements and built the application using OSS: LAMP (Linux, Apache, MariaDB, Python).
Project management with this remote team was handled through weekly team meetings via WebEx interactions and teleconferencing and email exchanges with individual team members during the project lifecycle. The project kicked-off on December 6, 2013 and ended five weeks later. A core of three team members completed the assigned project tasks.
Results
On January 10, 2014, the health care provider search web site, an internet site that allowed users to freely search for both individual and business healthcare providers, was implemented at http://xenvcounts10.srihosting.com/www/. Its MariaDB backend contained in excess of 4 million records, taken from public sources.
Open source software was never intended to be free, nor was it intended as a panacea. Rather, it was intended... "to deny anybody the right to exclusively exploit a work. Typically, in order to permit their works to reach a broad audience, and, incidentally, to make some sort of living from making works, creators are required to surrender all, or substantially all, of the rights granted by copyright to those entities that are capable of distributing and thereby exploiting that work." (from St. Laurent, A. M. (2004). Understanding Open Source and Free Software Licensing. Page 4. Sebastopol, CA: O'Reilly Media.ac)
The health care provider search website project demonstrates that many of the objections to using OSS may no longer hold water. A single instance of a fairly small and uncomplicated software development project has certainly not thrown the continuing reluctance to use OSS in the Federal sector on its head. We hope, however, that it has, at the very least, put a significant crack in its foundation.
Note: This article was adapted from the whitepaper on this research project. The team is available to speak with anyone or give presentations to groups who are interested in learning more about the project or the issues presented here.
2 Comments