Case Study: Streamline Verify

Streamline Verify is an HR Management organization that focuses on exclusion screening for medical professionals using the Office of Inspector General (OIG) exclusion list in the United States.

Streamline’s web application allows clients to perform OIG exclusion list checks on employees, import and manage a healthcare organization’s current computer system, edit and manage employee lists, access compliance-proving reports, and receive automatic emails with verification results and newly-flagged matches.

The part of the web application that Vehikl would be working on was exclusion matching. This part of the application checks employees against the OIG list of certain qualifications that would disallow them from working in the healthcare field.

The Problem

Streamline introduced Vehikl to their application with a significant challenge. The Streamline web app needed new features developed, but the app itself was considered legacy while also being actively used by several hundred organizations. In other words; the risk of new features breaking the application were high, and so updates to the application were necessary.

Proposed Solution

In order for Streamline’s developers to ensure stability with new features for their application, they would need to refactor not only considerable parts of the app but a database restructure would also be required.

Execution

Database Restructure
Streamline’s main concern with the database was that if more users were added to it, the application would collapse.

A typical upload to the system could be upwards of 75,000 records at once. If that upload included updates to an existing file, there could be hundreds of thousands of database calls. To ensure that we would continue being able to make updates to the database, we put it under version control, began testing performance with New Relic, and began automating management of the schema with Liquibase.

Once this setup was complete, we were able to restructure the database to accommodate for scalability of the Streamline application and continued improvements.

Refactor the app

The goal of any refactor project is to maintain the outward behaviour of the application while changing the underlying implementation so that it is more understandable and easier to maintain. In order to consider the project a success (or a failure) we needed a way to measure the progress we were making towards these two goals.

To verify that the changes we were making to the application source were not changing its behaviour we developed a comprehensive acceptance test suite which focused on the area of the application we were changing. There are many types of tests for software products, each type focuses on the application at a specific level, from units of code to the interactions between modules to the application’s behaviour as a whole. We chose to write acceptance tests as they treat the application as if it were a ‘black box’. In this format, internal implementation is irrelevant; only the output is considered when differentiating a passing test from a failing test.

To measure the impact of our changes to the application source we used a tool called Scrutinizer.

Scrutinizer passes each change to the source through a set of PHP specific static analysis tools and reduces the results of those tools down to a single score between 0 and 10 (with 2 points of precision). A high score, objectively tells you that your code is clean and maintainable. At the end of the refactor project we elevated the Scrutinizer score into the 9s.