Partners Healthcare writes the book on legacy data archival

What do you do with legacy data-storage applications containing near-antique patient information—so old it hasn’t been accessed in up to 20 years—that may yet be needed for legal, financial, clinical or population-management purposes?

Simple. If it costs more to keep the data live than to retire it to an archive, be it interactive, static or cold storage, retire it.

In truth, the decision may be that simple to make. But the particulars can be dauntingly complex to carry through.

The why’s, whens and how-to’s of getting it right were the subject of a HIMSS15 on-demand session presented by two IT pacesetters who recently completed a massive legacy archiving project for Partners Healthcare in Boston—and lived to create a “playbook” from their learnings.

Lesson one: Legacy archiving needs to be considered as part of EHR planning and total cost of ownership in any core system implementation, said Cara Babachicos, Partners’ CIO and corporate director of information systems for community hospitals and non-acute sites. Babachicos is responsible for IT in 10 facilities housing more than 1,500 patient beds and taking in $15 million in annual revenues.

Lesson two: You’re going to need a bigger steering committee. Co-presenter Janice Wurz, a senior advisor with Naperville, Ill.-based Impact Advisors, and co-chair with Babachicos of their archiving steering committee, said they brought in representatives from site CIOs as well as Partners’ CTO, chief privacy officer, IT finance director and others.

“As we had requests to retire these applications, and as issues arose, we had a means of prioritizing,” Wurz said. “We would have executive oversight and insight as to what would be the best way to move forward.”

“We really did create what we are calling a playbook for data archiving,” Babachicos added. “The purpose of the playbook is to say who gets to play and what they need to have in order to play. And then the overarching theme is the rules—how to get engaged and how to do your archiving.”

Planning for retirement

Most Partner sites are compliant with meaningful use (MU) stage 2 and beyond, and the team wanted to come up with a solution that would allow ongoing MU reporting if necessary while also maintaining readiness for recovery audit contractor (RAC) audits, should lawyers or government regulators come asking questions many years after the patient visits that created the data.

They also wanted to make sure they had integration with their vast enterprise master patient index (EMPI) and that end-users had single sign-on so they didn’t have to log in separately to various systems when accessing the data.

“As we looked at vendor solutions, we considered certain things such as whether the solution would be hosted on the premises or by software as a service (SaaS) through a cloud-based solution,” Babachicos recalled. “We wanted to have an application viewer that we could pull through and allow for contextual linking within the clinical record.”

As legacy applications transitioned into Partners’ new EHR platform, they wanted to consider them for retirement.

One of the biggest surprises came when they stepped into the data-extraction phase for their first application retirement. Traditionally at Partners, data extracts had been budgeted as six-week projects. This time it took nearly four months, as the retirement process bogged down working with the biggest and most complex projects at satellite care sites.

“We found there were some things that could be facilitated by internal [human] resources,” Wurz said. “In some cases we relied on our archive vendor to help us find those resources to do the extract. In our most complex case, where we were working with the legacy vendor people themselves, they provided us that extract of the information. Depending on whether or not that database is proprietary or if it’s a standard SQL database, those considerations also come into play.”

Simply static

Massachusetts requires healthcare providers to retain medical data for 20 years. Partners’ office of general counsel recommended that the team use that as a starting point but prepare a solution that would remain robust enough to renew for another 20 should a need arise at year 19: Better safe than sorry.

Meanwhile the team decided to go with a static solution over an interactive for one very simple reason: It’s easier. Static data is data stored in memory with fixed capacity. As such it’s less flexible than interactive (sometimes called “dynamic”) data, so it requires less care and feeding by people.  

“Keeping this project simple was one of our guiding principles,” explained Babachicos, adding that the steering committee was fully on board with it as such. “We couldn’t see the purpose of creating a new working system and rebuilding all those interfaces, which can vary from one application to another.”

The static state, they knew, would also allow them to stay consistent with how they’d be retiring their data-storage applications going forward. It would additionally allow end-users working at revenue-cycle tasks to avoid having to learn a new tool just to emulate what they’d been doing all along.

One month at a time

The Partners archival team now has a timeframe component in its playbook based on these experiences. The first six months focus on planning and funding. “That’s our biggest step in the planning phase,” said Babachicos, “making sure we have things in the right budget cycle and that people have budgeted for retirement of their applications.”

Around month seven, the timeframe calls for kickoff with extract and integration. This is followed by design, build and test in months nine through 11, final extract validation around month 12, training and “Go Live” in month 13, transition to support in month 14 and, finally, deactivate and decommission in months 15 and 16.

Upon transitioning to the vendor-support phase—in essence, the end zone—the team looked at what they needed to do to fulfill contractual obligations to legacy vendors, certify the destruction of data from the legacy systems and decommission or re-provision hardware, if needed.

The EHR element 

The Partners presenters wrapped up by summarizing why archiving absolutely needs to be part of a cost model in an EHR environment.

From the perspective of total cost of ownership, a lot of cost models incorrectly assume that expenses tied to legacy applications go away as soon as providers replace legacy apps with a shiny new EHR, said Babachicos.

“What we have found is that the regulatory requirements don’t allow us to do that. We need to maintain that access,” she added. “And we’ve found that we really need to make sure that we accommodate this requirement, and include it, in our overall cost for the transition to our new EHR program.”

“Looking at what data archiving really facilitates, and why we think it’s such an important topic to share with everybody: It provides us with a single place for all of our data to access,” she concluded. “We now have one application to support instead of dozens. It is a lower-cost alternative to maintaining legacy systems and keeping up all those other applications. It really helps us provide ongoing access to that data for legal purposes and also lets us boost the value of the clinical data that we had access to before.”