Managing Legacy Health IT Systems

One of the realities of healthcare IT is the mass of legacy healthcare IT systems that an organization has to support. I remember one hospital CIO saying that they had over 100 different health IT systems in their organization that they were supporting. Now expand that over the years and you can imagine how many of those systems get replaced and the old legacy system has to be supported.

I’m sure many are asking why they don’t just sunset the system. In many cases there are regulations and laws around how long you have to retain the healthcare data that’s stored in these systems. Other times there isn’t a good way to get the data out of the legacy system and the organization still needs access to the data. Regardless of the reason, every hospital has a number of legacy systems.

A little while ago I was talking with a consulting company and they pointed out something really interesting. Many times hospitals find themselves in a situation where they have a legacy system they have to support, but all their expertise in that legacy system has moved on from the organization. It turns out that this presents a great opportunity for these consulting companies to leverage the legacy software experience of their consultants. Many of these consulting companies do amazingly well just consulting on legacy systems. It’s amazing.

In my G+ hangout today, we also touched on this topic. The question of how to host the legacy system is often an important consideration. In the video interview, Jason Mendenhall pointed out that for legacy system’s, you often don’t want to move it to some new high end cloud infrastructure. In fact, it’s very likely that it’s not even possible. However, it’s nice to have all your health IT hosted in a place that can support the full gamut of needs from legacy servers to high end cloud computing.

I’d love to hear more about people’s strategy when it comes to legacy applications. Also, can we learn from our current experience that will help avoid future legacy application misery?

About the author

John Lynn

John Lynn

John Lynn is the Founder of, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference,, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.


  • John,

    This article could have been about Financial IT. Only difference, the financial services industry has been dealing with these issues for years. Numerous core systems still run on mainframes in languages like COBOL. They still exist because they are critical, generally robust systems and because no one has come up with better. And yes, it’s a pain integrating modern and antique!

    BTW, yet another reason why HealthIT management should embrace displaced Financial IT workers – we’ve done so much of this already! HealthIT doesn’t need to redo everything from scratch – AKA reinvent the wheel. They just need to hire the people who already know how to get things done.

  • The challenge in healthcare is that we often have something better, but record retention laws often mean that we still have to keep the old stuff that is barely limping along.

  • John,

    It’s interesting that the first comment refers to the financial sector and COBOL. A widely used language and database in the healthcare IT sector is MUMPS particularly the InterSystems Cachè version. As an established software house serving the Financial sector for over 3 decades whose solutions were originally developed in MUMPS, we too faced issues of integration, migration, data extraction, etc. Mapping hierarchical schemaless MUMPS databases to relational databases is a challenge that we met successfully for our own customers. The word is now out and enquiries are starting to arrive from the healthcare IT sector about the “Relational from MUMPS” tools that we developed and the two key driving forces, at least with regard to the enquiries that we are receiving, are (a) regulatory and compliance requirements (record retention laws), and (b) data extraction from MUMPS/Cachè databases to data-vaults/warehouses based on relational databases. Having already completed a significant MUMPS-to-Oracle database migration for a well-known US medical institution as an essential step in their plans to decommission a legacy MUMPS platform, there is growing recognition that companies such as ours with no historical involvement in the healthcare sector may have better solutions than those immersed in that field.

  • That last line certainly resonates, but it doesn’t for many in healthcare. Some are pretty insular when it comes to technology from outside of healthcare.

    Alex, I wonder if your technology could facilitate what many are calling an EHR vendor neutral archive. The idea is basically a non-EHR vendor specific storage for their EHR data. In some cases they do it for record retention. In some cases they do it as a disaster recovery/business continuity play. In other cases they do it when they want to switch EHR vendors. In other cases they do it so they could switch EHR vendors later if (and often when) that relationship sours.

Click here to post a comment