Page 1

From Legacy to Live:

Evolution – not revolution – in Healthcare IT

Summary Forces are colliding to generate both challenges and opportunities for the Healthcare industry. As a result, expectations have never been higher for the role of information technology (IT) in improving both patient care and internal efficiencies. Failure to effectively plan for the modernization of existing legacy systems could be devastating to a Healthcare organization’s viability. Legacy applications often contain decades of business process refinement and value. Modernization retains that value and can actually increase the ROI of these core applications by supporting business process improvements offered by new technologies on open system platforms. This paper reviews the applications modernization solutions available as well as 10 tips for legacy rejuvenation.

A Collision of Forces

Two forces are colliding to generate both challenges and opportunities for the Healthcare industry. Internally, escalating healthcare costs will continue to be problematic. The shifting of more healthcare costs by employers and payers to consumers will drive consumers to demand much better healthcare information for them to make more informed healthcare decisions. External forces are characterized by continued economic distress, government policy changes, increased demands for transparency, and the integration of non-traditional healthcare delivery systems and new players in the Healthcare sector. As a result, expectations have never been higher for the role of information technology (IT) in improving both patient care and internal efficiencies. Effective utilization of healthcare IT requires decision-makers with both healthcare knowledge and IT knowledge. While advances are being made on many fronts (promotion of electronic health records, increased electronic transactions, improvements in the sharing of healthcare information among all stakeholders, and advances in EMR/ EHR applications for orders, charting, clinical decision support, and bar coding to eliminate errors), some rather formidable challenges remain. Patient friendly billing and pricing transparency initiatives are providing an insight into a world in which many Healthcare organizations are not properly prepared to participate. Organizations must create strategic plans on how to share information with consumers and other stakeholders in a fair, objective, and unbiased manner.

Many Healthcare IT applications (e.g., patient billing, encoding, ADT/registration) are legacy applications based on monolithic architectures that will not easily accommodate the modifications necessary to meet these new challenges.

From Legacy to Live

Healthcare legacy IT platforms can be either a safe haven – or a beacon of inefficiency – in today’s environment. As a safe haven, legacy systems support important applications, services, and data. As a drain on organizational efficiency and profitability, they can consume more time, money, human resources, and physical space than their modern counterparts. With capital expenditures limited, many Healthcare organizations are asking how to retain the value and perhaps even improve the ROI of core applications. The Aberdeen Group summarizes it this way: “Today’s pressure on IT departments to use existing resources cost-effectively continues to increase… the answer is to leverage existing business-critical applications and information more effectively.” Areas under investigation include providing better access to data, re-using tried and tested business logic to deploy services within a Service Oriented Architecture (SOA), and/or moving these applications to more cost-effective hardware. The goal is to reduce legacy costs, mitigate the risk of system failure, and transform the legacy platform to become part of a modern infrastructure. The options can be categorized as: Replace, Re-develop, or Modernize. Replace. Replacing the legacy applications with a new “packaged solution” may initially seem the most attractive route. However, the experience of many Healthcare organizations has been that significant modifications have to be made to a so-called “packaged” solution, which frequently extends the time and cost of the project. Add to this the learning curves for technicians and users, and a Healthcare organization is presented with project that will impact its daily operations and its cost structure for a period of time. Re-develop. Re-development has the compelling promise to deliver a solution that will meet the new requirements and still leave the organization in control of its IT direction. However, re-development is without question the most risky, and probably the most expensive, option to take.

There are many horror stories of re-development projects lagging well behind the published schedule or costing significantly more than planned. With resources committed to the re-development, existing systems are left with little or no maintenance resource. This forces the IT team to either cut corners to speed up delivery, or escalate costs by throwing more resources at the project in the hopes of finishing it more quickly. Modernize. Application modernization is rapidly being seen as the most viable alternative to the slash-and-burn approach of replacing existing applications with packages, or through grandiose re-development projects. The principles behind modernization are based on the optimum retention of existing business logic and data combined with the marriage of new capabilities. These new capabilities might include:     

Enabling for e-Business Transforming the user interface, including Web enablement Changing the database technology Integrating with other enterprise systems Flexibility to meet changing business functions or models

Regardless of the option chosen, unless business processes have changed significantly, the minimum requirement of the new solution is that it does all the things the existing application does. Otherwise, the legacy application can never be turned off.

Process-oriented planning, tool-based implementation The decisions involved in modernization not only include the obvious (which applications, which platform, budget, timeline, etc.), but also need to consider all the other facets -- not simply the code conversion. These decisions are best supported by using a process-oriented approach for the planning. Some of the most experienced modernization vendors have developed and refined the process steps and offer specialist services to assist the Healthcare organization. In general, the steps include:

1. Determine business fit and cost of ownership It is important to understand the value of existing application assets to the business, the need for strategic investment, and the current total cost of ownership of each system before a clear modernization strategy can be determined. Many legacy applications, although rich in functionality, are difficult to modify, are less integrated with other systems and cost disproportionately more to operate. Additionally, if the application operates on a proprietary hardware platform this may be considered as an operational risk.

There are a number of ways applications can be modernized to become more agile while continuing to maximize the ROI of the legacy application: 

Incrementally exposing core business functionality from the legacy applications as Services within a Service Oriented Architecture (SOA). These SOA Services can be integrated into new clientfacing applications such as .NET and Java/J2EE.

Consolidating legacy data sources into relational databases to enable easier data access, better reporting, and simpler integration.

Moving legacy applications from older proprietary platforms to more cost-effective and better performing platforms.

Moving to a modern development environment. Many development shops still use development tools based on “green screen” sessions (e.g. COBOL or RPG development). Modern development tools provide support for COBOL and other older languages.

2. Assess the current platform The long-term issues regarding the current platform should be addressed upfront. This entails looking at the current hardware and anticipating its future. Is it proprietary? If it is time to upgrade, might this be the time to move to an open systems environment? How many years of life remain in the hardware, operating system, and database? Does the organization have sufficient skills and resources to continue to support the hardware?

3. Detail the existing application The next step is application assessment. This usually starts with the completion of an assessment document that articulates the key details: current platform, numbers of programs, database used, integration points, third-party products used, etc. The assessment should also detail the business changes required and the preferred target technology landscape. The best modernization vendors have developed and refined these assessment documents and offer specialist services to help evaluate the best alternatives -- leading to a Modernization Roadmap to guide the project development.

4. Define the target environment If the recommendation is to move a legacy application off its current platform to a modern environment, more than hardware is involved. An assessment of operating system, languages, user interface, database required, third party products required, and how the application interfaces with other systems must be made. Taking a proprietary language to another environment is not all that difficult. There are tools on the market to do this (e.g. proprietary COBOL to .NET COBOL on Windows). However, if the wish is to convert the existing application code to another language (e.g. converting COBOL to Java or C#), the work becomes significantly more complex. There are many issues to be defined: What will the architectural framework be? How readable and maintainable will the resultant converted code be? Does the organization possess the required skills? etc. Code conversion, particularly from a procedural language to an object-oriented language, is unlikely to be a fully automated process.

5. Scope the project and prioritize actions There is often the temptation to attempt to do everything at once during a modernization: change platforms, change user interfaces, change databases, improve integration with other applications, etc. The most successful projects are those that prioritize these activities and break them up into sub-projects in a way that each sub-projects can be delivered separately. The project scope must be documented in detail beforehand. This ensures that the strategy, tactics, and resources have been agreed upon and “scope creep� is eliminated, or at least minimized. The activation of a formal change request procedure, where implications are signed off by all project owners, reinforces this discipline.

6. Investigate modernization products and services With a Roadmap and detailed project scope in hand, the next step is to investigate the technologies and services available to best implement the project. Has a project similar to the one in your scope been done before, or is this project unique? What experience do vendors have in this area? Are there automated tools to assist? Modernization projects typically start off with very simple ideals, such as replacing a flat file system with a relational database. However, the choice of tools to achieve this can vary from replacing all of the existing I/O statements with embedded SQL (which is a time-consuming, labor-

intensive approach) to a middleware solution that is virtually risk-free, faster, and less expensive. Middleware tools differ in their architecture and it is vital to investigate them fully to ensure that the chosen solution will provide the performance and scalability required. For example, Legacy Liberator, a wellestablished and proven technology, automates the process of converting not only application code, but also the database, user interface, Job Control Language (JCL), and the data to a platform of choice. Component Adapters make the existing business rules and data in a critical legacy application available via a seamless, scalable, and nonintrusive interface layer (the Component Broker). This layer lies between the existing application and new application modules, and the services can be exposed as J2EE compliant JavaBeans/JCA, COM/C# objects for use with Visual Basic/Windows .NET or XML-based Web services, for integration with new or other enterprise applications. An e-Toolbox framework provides a Web server and platform-independent template application. It uses the Component Adapters and Component Broker middleware to ensure that existing core business application services are integrated into a Web application with real-time, straightthrough processing.

7. Allocate resources People, money, time. Those are the resources required. Most projects will require a mixture of internal and external vendor resources. Internally, the key position is that of Project Manager (PM), who has overall responsibility for project success. Success is measured in terms of meeting all the project targets for effectiveness, budget, and schedule. In addition to coordinating and communicating with the equivalent PMs from the vendor side, it is the responsibility of the PM to ensure that the relevant application assets, the test plans, testers, and other resources are available when required.

8. Create a project plan The project plan is typically a team effort: drawn up in close cooperating with the vendor(s) and key internal personnel. Most project plans consist of at least four parts:  

Desired outcome (end-state objectives) Budget requirements

Timeline showing project tasks and required resources to complete the task. Ensure that sufficient time is allocated to both vendor and user testing and at the end of each major milestone build in a small contingency. Detailed commentary on the tasks and responsibilities for the organization and the vendor(s). It should include the scope of the project, the success criteria, detailed steps of each project phase; the number of test cases the vendor is to carry out for each work package; the extent of final acceptance testing, and the acceptance criteria. In addition, the commentary should articulate how the project will be monitored and the project change procedures should the scope need to change during the project. Lastly, it is important to document what is not included in the project scope.

9. Execute the project Project execution not only requires technical skills, but also interpersonal skills to coordinate, communicate, and motivate the project team. It is essential that project managers keep on top of the tasks, particularly at the beginning. Quite often, internal staff continue to give priority to their “day jobs,” rather than focusing on project tasks. “Schedule creep” at the beginning too often leads to missing the deployment date at the end, unless considerable contingencies are built-in. Throughout the project, project managers should have formal progress meetings, bringing in technical team members as appropriate. It should be expected that each vendor PM will provide regular status reports for each meeting. Within the team, someone should be appointed to take meeting minutes, documenting decisions made, actions required, problems and the plan to solve them, etc. After each deliverable, it is all important to monitor any issues that arise from acceptance testing and ensure they are resolved in a timely manner.

10. Evaluate, learn, adjust Since the project scope and plan contains a definition of the success criteria, the performance against these criteria should be carefully evaluated. Typically, this is done in a “post mortem” where “what went well” and “what did not go well” are discussed and documented in order to learn from the experience. While the primary outcome of a successful project is usually economic (demonstrated by a tangible return on the investment), success if not always defined in financial terms. Other targets may be equally important: improved performance, ease of use (e.g. through a new graphical interface), improved data access, streamlined business processes, reduced errors, better support for sales or customer service, etc.

Modernization of legacy applications can positively impact revenues and costs – allowing the Healthcare organization to extract additional economic return from existing investments while meeting the new requirements being placed on Healthcare IT.

Project Phase

General Tasks


Requirements Definition: Roadmap; High Level Architecture; Scope, Budget


Establish Project Team & Set-Up; Evaluation of third-party tools and services


Architecture; Database; Prototypes; Test Plans

Technical Set-Up

Product Installation & Configuration; Tool Set-Up; Construction Procedures


Language Conversion; System Services; Database Build; DCL; Interfaces


Unit; System Testing; User Acceptance


Documentation & Implementation

About Transoft Transoft, a leading provider of innovative and pioneering modernization solutions, helps clients maximize the potential of existing applications by safely moving these core applications to modern, open platforms while improving their functionality in the process. Transoft is part of IRIS, which has an exceptional reputation for delivering award winning, market leading solutions to more than 60,000 organizations worldwide. The technology and services from Transoft deliver rapid return on investment, reduced costs, improved productivity, and the ability to manage operational risk. Major organizations such as The Gap, L’Oreal, Boeing, Balfour Beatty and Christie’s, and thousands of other customers enjoy the business benefits of a Transoft application modernization strategy. We work with a large network of VARs, System Integrators, ISVs and technical partners.

Transoft Contact Information Here

White Paper: Evolution, not revolution in Healthcare IT  

Client: Transoft Location: UK

Read more
Read more
Similar to
Popular now
Just for you