This time, coming soon, the VA minions will team up with rival bureaucrats at the Defense Department, who have plugged along for decades trying in vain to develop an EHR to match the VA's. The latest failure for the Defense minions is a program called AHLTA, which they now want to scrap, but which nearly sparked a mutiny in the Military Health System.
This proposed VA/Department of Defense joint production is to be called iEHR. A plot outline for iEHR was released last month to the "angels"—members of Congress who’ll be asked to fund the new "project."
"I think it's the Son of AHLTA," Munnecke said in an interview about iEHR. "It's just repeating everything that was done wrong in the past."
And Munnecke knows the past. He has worked on both the VA's and the DoD's EHR systems.
"The DoD hasn't changed their development method for 30 years now," Munnecke said. "It's called the waterfall model. You have a committee that designs the right requirements and everything after that is executing those requirements." That model might work when building an aircraft carrier, he said, but it's a different story when dealing with healthcare software.
"There's no feedback from the bottom," Munnecke said. "You can't know in advance what's going to work until you see it. It’s a discovery process."
Moreover, he said, "you can’t know from the top what it's like on the bottom." He added: "Information technology is an integral part of the professional experience. So, this feedback loop needs to be closed, and I think that was the trademark of the early VistA development."
End users were quick to spot shortcomings in the early VistA modules they were using and helping to develop, he said. Because development was decentralized, they could communicate their needs to local programmers, who made the improvement and handed the system back to the clinician users in a cycle of iterative development.
"We never wrote big requirements," Munnecke said. The watchword was to release software that was "good enough," which meant "you put simple things out in the field and people tried it and knew they could improve it."
How did they the programmers know their releases wouldn't harm patients?
"That's the definition of good enough," Munnecke said. "You want to make it good enough to not cause problems. We relied on our users' abilities to make judgments. I think this evolutionary, spiral development model and this continuous flow of change and improvements—I think that lesson is still valuable today."
Follow Joseph Conn on Twitter: @MHJConn.