New software deployments present hospitals with both great opportunity and great risk. A few bad decisions early on can be costly in terms of both time and money, especially in the healthcare software market, where long development cycles and post-sales support issues are common.
When a software installation goes awry, the aftermath is seldom pretty for the customer or the vendor. Occasionally, though, a software company will emerge from these near-disasters with both a happy customer and a better product.
Such was the case with San Francisco-based McKesson Corp.'s Paragon Community Hospital Information System. While Paragon has been named Best in KLAS two years in a row and is quickly gobbling up market share in the community hospital space, there was a time when the product was near collapse. The software didn't work, customers had been left hanging, and McKesson executives were weighing whether to mothball the product or start over from scratch.
Paragon's rise from the ashes required both a commitment from McKesson and a leap of faith from its customers, and provides some important lessons in product development, software selection and collaboration for hospitals and software vendors alike.
Monumental problems
McKesson first acquired the software through its merger with Atlanta-based HBO and Co. (HBOC) in 1999. HBOC had introduced Paragon in 1996 as the next generation of its existing SAINT product line, promising that it would be a Windows-based, client/server system for smaller community hospitals, a few dozen of which eagerly signed up to migrate. Unfortunately, it didn't work.
“HBOC tried to tie the new Microsoft technology into the old technology, and then replace the modules as they became available,” says Jim Pesce, senior vice president and general manager of McKesson's Paragon group. “That led to monumental problems.”
The original Paragon team had oversold the capabilities of the product (a common practice among software vendors at the time), and started signing contracts before the software was near completion.
“They started these PowerPoint presentations at the trade shows, and sold it way before its time,” says Vince Ciotti, principal at H.I.S. Professionals, a consulting firm based in Santa Fe, N.M., and an HCI guest blogger (http://www.healthcare-informatics.com/vince_ciotti). “There were lots of bugs, and not a lot of applications.”
McKesson had three options: discontinue the Paragon line; move forward with the existing customers and hope to make the software work later; or pull it from the market and start over.
“I instantly saw the problems, but more importantly I fell in love conceptually with what HBOC had been trying to build,” he says. “I thought that if McKesson could build a fully integrated clinical and financial product on the Microsoft platform, it would be light-years ahead of anything else in the industry.”
Pesce came on board to head up the rebuilding process. “Stabilizing the product provided the opportunity to demonstrate our commitment to our customers and the industry, and to build market share, and had the potential of producing something that would become a valuable asset to our company,” Pesce says.
McKesson suspended new sales and implementations of Paragon while the product was stabilized. About half of the existing customers received a refund, but the remaining hospitals agreed to stay onboard while the software was retooled.
Rebirth
The “new” Paragon system emerged in 2001 as a fully integrated clinical and financial HIS offering, built on Microsoft technology. And in 2004, McKesson's executive committee gave the go-ahead to start building a sales team and formally roll out the product to new customers.
“Paragon's reputation had suffered,” says Pesce. “But I was adamant that we not change the name. My belief was that if we turned this into a great product, it would be a better story and get more recognition than if we tried to introduce it as a new offering. But the hardest part was getting in the door.”
One of the first new customers to take a chance on Paragon was David Witton, director of information systems at St. John's Medical Center, a non-profit community hospital in Jackson Hole, Wyo.
Witton, himself a programmer, started looking at Paragon in 2002 and was aware of its history. “They were converting from a flat-file, siloed application to an object-oriented, relational database,” he says. “It looked like a trainwreck waiting to happen. But once they made that conversion, there was no reason it wouldn't be viable.”
Paragon was still missing some core modules at the time, but after speaking to some original customers who had already made the switch, Witton says he learned that McKesson was rapidly delivering new applications — a key factor in Witten's final decision. “The product did not have a materials management module in November 2002,” he says. “By the time we got to the final face off in May of 2003, they had built that product.”Witton, in fact, chose the software over the initial objections of Ciotti's firm, which was helping him with his search.
George Sullivan, director of information technology services at Mary Lanning Memorial Hospital in Hastings, Neb., was also skeptical of Paragon when the product was mentioned as a possible successor to the hospital's existing HIS. Sullivan, a former consultant, had actually evaluated the software for a client in the 1990s. “We looked closely at Paragon back then, and that's when I started hearing all the stories about it,” Sullivan says. “It truly did not work.”
“We had warned all our people not to go near the damn thing with a stick,” says Ciotti, whose firm was assisting Sullivan with his search. “But (St. John's) had fallen in love with Paragon and forced us to look at it. And low and behold, they had done a pretty good job with it.”
Sullivan put Paragon and several other vendors through their paces, asking for multiple product demos, visiting customer sites and even having his staff call up the vendors' help desks to see how they responded to problems.
Sullivan (who likens Paragon to the Saturn division at General Motors) says that Paragon eventually won the contract in large part because it held up so well during the lengthy and rigorous selection process. “You have to really kick the tires,” Sullivan says. “You have to get proof that the system works.”
Like Sullivan, Pam Ridley, IS director at Henry County Medical Center in Paris, Tenn., relied on a thorough selection process to select Paragon out of a field of eight vendors. The hospital's IT steering committee evaluated the vendors based on price, the responses to a request for proposal (RFP), product demos, and customer site visits.
“We knew all about the product's history, and that did weigh into our decision,” Ridley says. “They were up-front about it. Ultimately we knew the system would move us toward our goal of an electronic patient record, and we liked what they had to offer in terms of functionality.”
There's still some work left to do on Paragon — the pharmacy module is due in October, and the computerized physician order entry (CPOE) module will be ready next year. Pesce is confident that Paragon will continue to move forward on schedule, and is proud that the company was able to successfully turn the product around.
“It cost us, but it was the right thing to do,” Pesce says. “This is a market with a history of not delivering products on time. For community hospitals to buy from us, they have to believe that we are going to deliver high-quality products on time, with the functionality to meet all of their future needs.”
Sidebar
Vetting Software
A thorough software selection process is one of the best ways to avoid post-installation problems. Many hospitals use third-party consultants to help narrow their choices, but there are some basic steps to follow even when the process is being internally managed.
Develop a thorough RFP, but don't rely solely on vendor responses. Examine the responses closely and use the RFP to identify differences and gaps in functionality between vendors.
Don't settle for the standard software demo. Provide a demo script that reflects the hospital's operations, and watch to see how the vendor responds to ad hoc questions during the presentation. “We brought (the vendors) in for a ‘day-in-the-life’ of the patient, and had them take us through how their system would work in our hospital from scheduling and registration, all the way through billing,” says Pam Ridley, IS director at Henry County Medical Center in Paris, Tenn.
Talk to other customers. References are important, whether you talk to them by phone or in person. The vendor will likely be on hand for site visits, but make sure your selection team is able to speak to actual users at the hospital without the vendor in the room.
Find out who will install the system. Make sure you have an experienced project manager leading the implementation, and that they will see the project through to completion. — B.A.
Sidebar
When Things Go Wrong
Getting a software bug fixed can be a frustrating process, particularly for smaller hospitals with modest IT staffs and limited clout with their vendors. A few simple strategies can help move the process forward:
Outline your support expectations up front, and get the vendor to commit to them in writing.
Carefully document any problems. Hospitals must be able to clearly explain the issue, and provide documentation explaining how the problem is impacting operations.
Know what you want to accomplish. Don't just suggest a change to the application; let the vendor know what the goal of the change will be — there could be a more effective fix you haven't thought of.
Participate in user groups.
Be patient, but persistent. Any major fixes might have to wait until the next software upgrade, but follow-up with the vendor regularly to check on the progress of short-term support issues.
Sidebar
CONTINUE THE CONVERSATION
Wiki-fy this story at http://www.healthcare-informatics.com by posting comments, listing relevant resources and linking to associated events.