It all started when I had to go up to my attic to get something for my wife. Once I was up there it was like a trip down memory lane. There was stuff up there that I had not seen in years and some things that I didn’t even realize that we had. So after I came back down we started having a discussion about our attic inventory. I have course wanted to purge most of the things up there, but the requirement always came back to the value it had either tangible or sentimental. Other issues came up and soon the attic discussion was low on the priority list.
A few weeks ago I was talking to a CIO about their EPIC migration and what they were going to do about all the remaining legacy systems. He mentioned the challenges with defining what to keep, and figuring out what all the stakeholders wanted to do with their niche’ systems. It was a moment of Déjà vu’ as I realized that this was similar to my attic discussion. His data center had become his server attic.
Software often becomes a product that users get attached to. Some users navigate through software screens while drinking coffee and talking to coworkers…it becomes second nature. They become personally invested with the product. So when organizations migrate to a new product, Information Technology departments are often left with racks of servers in the back of the data center. Some applications continue to be used because some functionality does not work the same in the new system, or there is still some data in the old legacy system.
Deciding what to get rid of and what to archive from your old systems can be a daunting task. You first have to figure out what systems actually contain data and which ones can be retired. This due diligence sets the foundation for any Legacy Data Retirement project.
- Determine what applications have been or will be replaced by your new system.
- What interfaces are currently active that will be repurposed or deactivated as part of the new system.
- What are the use cases for the applications that contain data? What information will users need to access and how will it be used; Reports, static view, exporting as a csv file?
- Take the time to talk to the users and understand the value of the data to them from a clinical and workflow perspective.
- What applications are tied to the accounts receivables rundown? What utilities will remain active to expedite billing?
Finally, what are the dollar savings around the license and support fees of the retired applications? This should be enough to make the case for archiving the data and engaging a legacy archive software vendor. There are many vendors that will work through the process of extracting, transferring the data and, loading it to a relational database. They provide an application layer that sets on top of the database which allows users to perform most if not all the required access to the data.
One piece that should be understood is that Digital Imaging and Communications in Medicine (DICOM) files. These are your PACS type files. They normally are handled differently than standard data extracts since you have to have a link to the images which enables users to view the necessary patient images. Some legacy archiving software companies contract separately to provide this service, or organizations can contract with a preferred vendor to store and archive images. Either way, it has to be considered as part of the legacy archiving project.
Like the discussion I had about the content in my attic, be prepared to get some push back from some users about retiring their applications. Healthcare data has value in some way, shape or form. Often there is research value and sometimes it allows for patient trending. There are also regulatory policies around retention that you should review and discuss with your legal department. Again, this can be a difficult task especially if you are preparing to go-live on a new system. But going through the process will yield substantial savings, improve access to valuable data and make you feel better next time you visit your server attic.
