On behalf of the National Institutes of Health/National Institute of Allergy & Infectious Diseases (NIH/NIAID), the Duke Human Vaccine Institute (DHVI), an Institute within the Duke University School of Medicine, administratively supports the External Quality Assurance Program Oversight Laboratory (EQAPOL) program. Through EQAPOL, the NIH/NIAID is advancing HIV research by helping research laboratories improve data quality, data integrity, and laboratory practices. In 2010, the EQAPOL PI engaged SciMed Solutions to develop a web-based software application for EQAPOL to coordinate quality assurance protocols at more than 50 leading research laboratories worldwide.
EQAPOL Program Managers gave SciMed Solutions a diverse set of success criteria for the EQAPOL application project:
After a nine-month effort, SciMed successfully deployed the EQAPOL management system in 2012—on spec, on time, and on budget. Now, after two years of use, the EQAPOL team reports that:
The EQAPOL software project, funded by NIH/NIAID, was a first-of-its-kind application capable of supporting research laboratory improvement of data quality, data integrity, and laboratory practices on a global basis. Both DHVI and SciMed Solutions share the credit for its successful completion. Because DHVI and SciMed were working in a new arena together, they began the project with an exceptional emphasis on thorough, clear communication.
At the beginning of the project, DHVI’s Director of Information Technology, Paul Debien, emphasized that the EQAPOL system’s User Experience requirements were as fundamentally important as the data.
The project team decided at the start that the EQAPOL system had to be “an effort multiplier” for the users -- it couldn’t be seen as a system more cumbersome or time consuming to use than other laboratory management or quality assurance applications with which they were familiar. SciMed built this philosophy into all modules of the application even though we were working across a broad scope of laboratory programs ,QA, and reporting processes that defined EQAPOL needs. Our team had to solicit from many different users, but this effort also got us a lot of user buy-in, which is very important.
User buy-in was not a “hoped for” outcome for the EQAPOL project. Instead, it was a priority that was addressed from the beginning by incorporating input from many users into the software’s design. According to Debien, this collaborative approach was, in fact, a common theme throughout the project.
With each phase of the project, we sat around the table to discuss EQAPOL's requirements and the possible ways we could design the software to do what we needed. Both DHVI and SciMed took responsibility for asking questions, creating ideas, and debating the merits of different approaches. The DHVI/SciMed and User team members felt comfortable asking questions, and letting go of ideas that didn’t hold up and that freed up our developmental energy. Collegial, collaborative, cooperative -- those are theme words for our work on EQAPOL.
As the project moved from requirements definitions to software design, the collaboration process evolved to meet the new tasks. EQAPOL’s Project Manager, Ana Sanchez, PhD, describes it:
After the EQAPOL and SciMed teams had defined the major requirements, and described our process flows in detail, SciMed created mock screenshots to help us visualize what we’d discussed. Working with the screenshots, the EQAPOL team was able to “see” in more detail what we’d be asking our users to do, where our plan made sense, and where we needed to make a change. Then we’d get back together to figure out “OK, how’s this really going to work?”
This process—design, mock-ups, review, and re-design—was done for nearly every part of the EQAPOL application. By doing this before coding, the team avoided wasting many hours of development that would have been quickly discarded.
Next, SciMed began coding the various modules of the EQAPOL application. Debien describes how SciMed and the EQAPOL team would refine their plans along the way:
As SciMed finished each module, the EQAPOL project team got a stronger sense of the coding challenges and opportunities. In discussion, we might discover that a feature previously deemed “nice but not necessary” was actually very useful to the application managers and uses, and relatively easy to build, because SciMed could tackle it while coding a similar piece of the software.” We made these judgments all the time – for single features or for packages of related parts. We would ask SciMed “what are the degrees of difficulty? …what are the downstream effects?” That’s how we’d come up with good development decisions.
EQAPOL’s early success was clearly driven by the collaboration between experts on the EQAPOL team and SciMed. In the words of Sanchez:
Collaborating with SciMed was easy and productive because they understand the science. This was used to our advantage in not having to explain the intended scientific content of the module which resulted in better utilization of our development resources and hours. That understanding allowed the combined project team to not only understand the requirements, but also what we were trying to accomplish. Not only did we use our time better, but we also got a better product.