Emergency programming: The mindset that makes it happen

The team from the Department of Information Systems that created decision-support software to help distribute crucial H1N1 vaccine knew that for this project, speed trumped all other protocols. They found that when faced with such severe time pressures, other design guidelines emerge, and textbook tactics go by the wayside.

It isn't often that software can save or end life. Yet, those were the outcomes faced last fall when scholars from the Department of Information Systems were called for help by the Department of Public Health in Arizona's Maricopa County.

Public-health officials were being inundated with H1N1 vaccine that had to be distributed on a daily basis. With more than 1,000 healthcare providers clamoring for the vaccine, getting each day's distribution to the right doctors at the right time was more than public-health workers could do within the few hours they were given to make decisions.

The information systems team was faced with the task of creating decision-support software to help distribute crucial vaccine to those most in need. For this project, speed trumped all other protocols. The W. P. Carey team found that other design guidelines emerge, and textbook tactics go by the wayside when faced with severe time pressures.

In one door, out the other

Asked if there's a process for creating software in an emergency, Raghu Santanam, professor of Information Systems for the W. P. Carey School, says there is certainly a first step: "Be in 'listen' mode. Don't jump to conclusions. Try to get as much information up front as possible."

That's what Santanam, his colleagues Benjamin Shao and Ajay Vinze, as well as two doctoral students did when called in to the county health department around 10 days after the U.S. Centers for Disease Control started daily shipments of vaccine to combat the much-feared H1N1 flu.

Maricopa County's public-health experts knew they could have distributed vaccine through some random but quick approach, such as sending vaccines out according to an alphabetized list of physicians. But they wanted a more deliberate method, because they knew that when vaccines are distributed in a targeted way, there's a greater chance of limiting contagion and saving lives.

To meet the county's goal of strategic but equitable vaccine distribution, the W. P. Carey school team first tried to determine the county's "pain points," Santanam says. These, he notes, largely boiled down to how information was being distributed among vaccine-supply agents. "There were a lot of opportunities to lose information," he explains. The physician orders for vaccine were going to the Arizona Department of Health Services. Then, that agency would communicate the orders to the county via email.

"There were a dozen or more spreadsheets floating around," he continues. "That's a big no-no for a process. The first thing you try to do with a process is reduce any need for reconciliation," which is what has to happen if there are multiple places in which you capture information. At some point, you have to compile and verify all the data.

Other problems the county faced were order fulfillment and tracking, Santanam adds. The county was only deciding where to ship the vaccines. Other agencies sent doses to the healthcare providers specified, so the county had no way of actually knowing whether physicians had received their orders or used the vaccines.

Speedy delivery or functionality? Pick one

Meanwhile, by the time those tardy H1N1 flu vaccines were available, county health officials had only a couple of months ahead of them to distribute the doses. "They needed a decision-making tool yesterday," says Trent Spaulding, a doctoral candidate at the W. P. Carey School who was called in to help with programming on this project. "If the county got the software three months after asking for it, it would have been useless."

With speed as the top design goal, the programmers realized they had a surprising step to take to meet the emergency at hand. "We had to throw away some of the academic ways of doing things as perfectly as possible," admits Aaron Baird, another W. P. Carey school doctoral candidate and co-creator of the software.

"As part of systems design, you often redesign a process," he continues. "In this project, we couldn't take time for that. The pandemic would be over. We had to work with the processes we had." Likewise, a more formal development effort would accommodate programming rules of "generalizing" the system, or making the software comprehensive enough to serve in many situations or, at least, many vaccine-distribution schemes.

"The system is not designed to be used for any other flu pandemic or any other types of vaccines," Baird explains. "We built it in Access and built it very quickly. It was designed for this county, this vaccine distribution, this flu and those few months in which it was needed." According to Spaulding, the system might be adapted for another pandemic, but that could take a few weeks of programming.

Making it generalized and robust enough to work in multiple situations could take as long as six months' development time. "Normalizing" the system is another formal development approach the team abandoned, as this system had to be something people who are not necessarily database experts could audit later. While most vaccine programs are paid for by county health agencies, H1N1 was such a dreaded threat, the CDC took the reins of vaccine supply and expenses.

Consequently, county officials wanted to make sure their distribution decision-making tool could be reviewed by federal workers later should the feds want to see how allocation choices had been made. "We had people who were not database administrators who would need to use and maybe audit the system later," notes Spaulding. "That meant they needed to be able to open the database and read tables in it."

He explains the challenge this way: Had the system been a simple spreadsheet, there might have been a column called "category of practice," and in that column, you might see practice types written out, such as family practice, pediatrics or obstetrics. "To normalize a database, you leave a marker in that column to represent the category of practice. Then, in another database, you identify the marker some way — number one equals family practice, number two, pediatrics and so on," he says.

Given the audit concerns, the programmers chose to forego database normalizing and leave the system looking more like an Excel spreadsheet. It was part of their user-friendly approach. Speaking of user-friendly programming, the automation did improve the rickety process that was in place for tracking H1N1 vaccine. As Santanam explains, the software allowed county health workers to import various spreadsheets and reconcile orders against shipments.

"The software clarified who had placed orders and how many doses were requested. As those orders were fulfilled, county officials could track how many had shipped," he notes. Although the project didn't necessarily draw on the IS experts' knowledge of best practices, it did provide some lessons on meeting emergencies efficiently. Among them, the researchers offer up these bits of advice:

Streamline paperwork: This project started with a four-hour meeting, but it didn't include a back-and-forth round of specifications and contract negotiation. "They gave us an end goal, and we met it without a lot of inefficient upfront paperwork," Baird says. On the other hand, the team wanted to make sure processes were documented should an audit occur. So, they documented processes, decisions and strategy as work progressed.

Plan for self-service: According to Spaulding, one design consideration was self-maintenance. "The county had to be able to manage the system themselves," he says. "We sat right next to health workers while they used the program. If they said something didn't work, we'd fix it right then and hand over a new copy." After a week of fine-tuning, the system worked exactly as needed.

Get the right team players: To deliver software quickly, the W. P. Carey School's professors hand-picked doctoral candidates to do the code work, plus they helped guide strategy along the way. They also had the county offer up a dedicated resource. "They assigned a full-time staff member who would help us get the data so we didn't need to go hunting through seven or eight people," Vinze says. "That one person is the only one we dealt with."

Have faith in your co-workers: "This was a situation where when push comes to shove, trust matters," Vinze adds. "We've been working with the public-health people for eight years and always on some decision-making problem. It was that trust that allowed them to give this to us in such short order. They turned to us and said, 'Make it happen.' We saw this as a social responsibility, and we made it happen."

Bottom Line:

• When time is crucial, speed trumps protocol in systems development.
• There may be no time to rework processes. Instead, they must be accommodated.
• Programmers should listen to problems with care, find the pain points and focus on solving the big problem at hand.
• Trust, teamwork and handshake agreements may meet the emergency more efficiently than specifications documentation or scope-of-work plotting.