I just started a few new engagements, working with institutions facing a number of issues with cardiology services. Primary among them is the question of how to react to the reality of vendor announcements of impending sunset of specific applications. Overlay on top of that the fate of applications and infrastructure still running on Microsoft’s XP platform, and facilities face huge challenges.
First and foremost – what to replace obsolete products with? Should they stay with the same manufacturer? Is it time for a change? What about migration of existing data? What else is impacted by a change in a specific application?
Most vendors that intend to sunset a product will have an alternative – upgrade to their latest and greatest. This can make sense when it represents the path of least resistance. Prior data is compatible. Vendor support is good. Transition time is minimal. The application is similar enough that there is a minimal learning curve.
But what if any of these factors aren’t true? Regardless if it is the same vendor, prior data must still be migrated. Vendor support has had issues. The transition will take considerable time and expense. All replacement alternatives will require a learning curve and expense.
Experience would suggest that there are a number of factors to consider, including:
• Is the department considering other changes that might impact selection of an alternative application?
• Do potential alternative applications fit current and planned information technology strategies and infrastructure?
• Even though there may be support issues with the existing vendor, have there been similar issues with alternative vendors?
• What is the consequence of not updating and losing vendor support?
For example, consider the issue of the demise of Windows XP. With Microsoft support ending in 181 days, does it mean that all applications running on and written for Windows XP will cease to work? Not necessarily. It does mean that there will be no support from Microsoft, and no additional security patches. Newer applications may not work on Windows XP (no backwards compatibility). Older applications might still work on newer operating systems though. Overall, this represents a huge issue for healthcare as changes to newer operating systems may mean multiple applications may no longer work, or at a minimum, must be fully tested with the newer operating system.
Systems not updated may have additional security issues from the lack of compatible security platforms, such as anti-virus applications, as it is doubtful that anti-virus vendors will keep virus definitions current for a discontinued operating system. I am reminded of a site that had such headaches with its PACS equipment running on older operating systems where the vendor did not supply any anti-virus software. Occasionally, a PACS PC would become infected, as it was connected to the facility’s network, forcing it to be re-imaged each time it happened.
Another risk is that newer applications don’t play nice with older platforms. Over the years, I have seen PACS viewer limitations impact which version of Microsoft Internet Explorer can be used, as the viewer might not be compatible with newer versions. This is a constant battle, as some newer applications might not work well with older versions of Internet Explorer, especially with new developments such as HTML5. This can limit the number of PC’s where specific viewer applications work, and disrupt plans to roll out applications to physician homes or other locations.
Sites would be wise to implement a few simple policies, including:
• Inventory existing applications and build a compatibility matrix for future reference, with known obsolescence noted
• Identify interdependencies of existing applications, noting where a change might have a ripple effect
• Consider new applications on the basis of their impact and compatibility with existing infrastructure
A little re-thought can help keep sunsets beautiful!