Open Source Solution Facilitates Communication between Legacy Systems and New Technologies

Nicole Hawkins, Matt Reid, Mark Simaga, Jahanzeb Syed, Isolina VargasNorthwestern University MED_INF 403

INTRODUCTION

Hospitals rely on their computer systems for day-to-day operations from patient registration to billing the insurance companies. Some of these computer systems have been used for years or decades. As health care practice changes and information technology advances, these existing computer systems become obsolete. These computer systems are called legacy systems.

Legacy systems are old computer systems that may still be in use because the data cannot be changed to new formats or its application programs cannot be upgraded (Legacy System). Because these systems contain historical data and are the foundation for many organizations, they are not easily replaced. Instead, an organization must figure out how to integrate these legacy systems with newer technologies to maintain the data. Throughout this paper we will describe the problems associated with legacy systems and propose a viable solution to overcome these problems.

PROBLEM

A number of healthcare organizations still use legacy systems to access financial, medical, billing operations and other data. In an effort to improve healthcare quality while reducing costs, the healthcare industry has been moving towards an infrastructure model where information is shared beyond local systems. These legacy systems were developed prior to the need for interoperability. Over time, these legacy systems grew into substantially large data repositories. A significant problem for healthcare organizations is how to integrate, extract, convert, and migrate data from these systems so that information can be received and translated by current information systems. A framework is needed that provides interoperability between legacy systems and new information systems.

Problems such as brittleness, inflexibility, isolation, non-extensibility, and lack of openness plague many legacy healthcare systems and the organizations that continue to operate them (Wu et al., 1997). These issues are well known and have become a major concern for system administrators and IT departments causing a roadblock to progress. However, issues concerning data integration are massively complex and costly, consuming resources both in time and personnel. A 2001 study by Forrest Research reported that 98% of companies polled viewed data integration between heterogeneous computer systems as either “extremely important” or “very important” to their organization’s long-term IT strategy (Park, 2004). Some of the challenges in legacy system integration involve:

2

● a lack of understanding of internal system functions due to misplaced documentation (Wu et al., 1997);

● the absence of clean functional interfaces (Wu et al., 1997);● information stored in multiple, conflicting formats without a clear conversion

process;● very large (e.g., 10^7 lines of code), geriatric (e.g., more than 10 years old),

applications written in COBOL using a legacy database service (e.g., IBM’s IMS or no DBMS at all) (Brodie, 1992).

Gateways are major components addressing interfaces between legacy architecture and current information systems. Gateways are often constructed to mediate and direct requests between disparate information systems (Brodie, 1992). By encapsulating legacy components, gateways remove the need to directly interface between legacy and current systems, reducing legacy code manipulation and helping maintain functional integrity. For instance, newly built software deployments tend to be very malleable allowing for their implementers to make changes without damaging the system. As software ages, component interdependency becomes more rigid from years of software patches and updates. At that point, entering unusual data or altering code in minor ways can cause unforeseen system failure.

Furthermore, gateways are complex, expensive to develop, and generally ad hoc (i.e., built solely for the two systems being interfaced) (Brodie, 1992). Current gateway development tends to focus on short-term solutions to long-term problems and do not allow for third party systems to easily access legacy data. Other gateway limitations include:

● no support for transaction management and no way to ensure data consistency between the legacy and target systems (Bisbal, Lawless, Wu & Grimson, 1999);

● no method to homogenize the structural and representational differences between two database schemas (Bisbal et al., 1999); and

● considerable complexity in their attempt to maintain consistency between the legacy and target system (Wu et al., 1997).

In addition to the constraints developing gateway interfaces, legacy system maintenance requires skilled personnel experienced with supporting verbose programming languages and outdated hardware. The predominance of COBOL code in early business and healthcare information systems presents obstacles for current data-mining efforts. The required skills to perform advanced business analytics on legacy data are being lost as experts in these fields are retiring while educational institutions no longer offer courses to young programmers.

Legacy systems often run on unsupported hardware platforms installed years before current IT technicians were hired. These platforms, generally mainframe in nature, incorporate obsolete technology, low processing power, high power consumption, and were designed before the advent of information exchange:

3

“The total cost of ownership of current systems becomes prohibitive, due to the diversity of the systems and the cost of software maintenance. On top of that, due to a growing business volume and the data processing model used, performance becomes increasingly an issue, raising the question whether to invest either in more powerful, but expensive hardware or to migrate to a new environment with a larger evolutionary capacity (Tromp & Hoffman, 2003).”

While a straightforward method to eliminating legacy systems centers on “remove and replace”, it is often not that easy. 24/7 healthcare organizations require constant system accessibility. Data migration at this level would undoubtedly take more time and planning than a scheduled downtime would allow. In addition, clinical personnel who have grown accustomed to a particular interface may be resistant to abrupt changes in their department’s clinical information system. For the sake of change management and business continuity, interfacing legacy systems with current technology, such as EHRs, can provide a stopgap measure between a complete overhaul and normal day-to-day functionality. However, as previously discussed, interfacing legacy systems with current clinical information systems is a complex issue requiring an innovative approach.

SOLUTION

“We connect the engine of a Ferrari, the brakes of a Porsche, the suspension of a BMW, the body of a Volvo. What we get, of course, is nothing close to a great car; we get a pile of very expensive junk.” Donald Berwick.

Today’s Heath Care Organizations (HCO) struggle with a similar challenge. Even after buying state of the art software, similar to the example above, meaningful use is not completely achieved due to the lack of interoperability between systems. . We believe that the answer to this problem is the developmental control through open source adoption. By using an open source application system, we can solve the complex interoperability issues that characterize transformation of legacy system data

The application component of our proposed solution is developed on an open source framework; the following are definitions of proprietary software and open source software.

Proprietary software vs. Open source softwareIn comparison to open source software, proprietary software contains intellectual property rights and is not free. To maintain a competitive edge, vendors do not publish the application source code. In some cases, the vendor issues a SDK (software development kit) for limited developmental use. The SDK prevents developers from making desired modifications. The software often comes with a licensing model. The manufacturers make money by selling the product and its associated services like subscription, and operations and maintenance support. Today’s healthcare information technology is a complex mesh of different proprietary products. One of the biggest

4

issues is interoperability among different systems. Most of these products come straight out of the box and limit customization. However, open source software is designed and developed on standardized modules. The source code is available for desired modifications. By following the predefined standards, any developer can either develop new applications or modify existing applications. It is totally free. The Veterans Health Administration is using an open source health record system nationwide. It is a low cost option for non-Veterans Affairs hospitals. Other examples of open source software are Android GOOGLE Android, Redhat, Apache, FreeMed, OpenEMR, and GNUmed.

Technical VisionTo solve the problem of interoperability between legacy systems and new technologies from an operational perspective while also considering financial restraints, we identified a two-phase approach:

Phase 1: Develop an open source application interface that understands legacy data formats and converts them into a readable format for current information systems.Phase 2: Design a central relational database infrastructure with sophisticated interfaces, and extract, convert and migrate data from legacy systems to a central repository.

In an effort to adopt new technologies, many healthcare organization infrastructures are transformed into a hybrid between new and legacy systems. Interoperability has always been a challenge. The figure below represents a state of the art IT infrastructure coexisting with a legacy system on the same network. The data is shared between internal departments through intranet clouds. The infrastructure uses standard formats such as HL7, CCR, CCD, DICOM etc. For external entities such as RxHUB, HIEs, CMS, laboratories, insurance companies and outpatient facilities, there is a HIPPA compliant DMZ (demilitarized zone) in place with strict firewall rules. This setup will establish a secure communication between the intranet and Internet. In addition to lacking high performance capabilities, the legacy system is limited in data sharing capabilities.

The infrastructure is set in a way that it can accommodate legacy systems for ongoing operations. The legacy systems will stay intact until the data is migrated to the central database. In accommodating data extraction, conversion and migration, the legacy systems are placed on the new network.

The new central database architecture is designed to cater to high performance input/output (I/O) needs and is used as a backbone for data sources. The database normalization in the relational database is used to enhance performance.

In addition, the OS cluster technology is deployed for data availability. A backup schema is designed to capture hourly transaction logs, daily/weekly/monthly SQL and system backups. An ongoing paper-to-electronic conversion setup is also part of the solution as shown in the figure below:

5

Data classificationIn order to design workflows for data extraction, conversion, transformation and storage, it is important to classify data types. Once these data types are identified within the legacy system database, the data will be converted and remodeled. The following is a list of data types that are commonly used in most health care organizations. These data types can be presented as a separate database or in the form of tables within databases that are linked to each other via a relational model.

CLINICAL Laboratory Pharmacy CPOE Admission/Discharge/Transfer Registration Master Patient Index Results Reporting Radiology Scheduling

ADMINISTRATION Billing/coding Scheduling Patient accounting Account payable Payroll/personnel General ledger Budgeting Cost accounting Education & Training

Open source application infrastructure – Legacy system data extraction

6

We envision an application server that will host our open source application. This server will be connected to the legacy database, legacy systems, staging database and central database on the organization network as shown below:

This setup will accommodate the ongoing departmental operations that use legacy systems. In parallel to daily operations, the infrastructure will establish a foundation for data extraction, conversion and remodeling as shown above. Most of the legacy systems are compatible with HL7v2 messages. The open source application will use the same standards to extract the data from these legacy systems. For those legacy systems that are not compatible with any standards, the open source application provisions API (application programming interface) in addition to free open source code to vendors.

Data TransformationThe transformation of legacy data into an interoperable format requires identification of objects, relationships between the objects, object attributes and files for each individual legacy system. Multiple data extract models will be developed with the required protocols. Once the data is extracted, it will be converted and stored into a staging database for data mining and data remodeling. In the end, the data is stored into a central data repository. The following are some key features of data extraction from legacy systems:

the application will use standards such as HL7, CCR, CCD, EDIFACT, or EN13606 to establish communication, the application will provision of Application Programming Interfaces (APIs) for more complex proprietary legacy systems, and the application will establish open source code functions for vendors.

The application data extraction module has four components:

OBJECTS are defined as an entity which can be manipulated byprogramming language and can be a value, variable, function, or data structure. In reference to healthcare data types, objects can be a person, service, facility, code, or department.

OBJECT ATTRIBUTES classify the objects with its characteristics. From theabove examples, the attribute of a person can be defined as a patient, doctor, or nurse. If the object is a service, the attribute can be defined as a billing service, lab service or financial service.

OBJECT RELATIONSHIPS define the relationships between objects. For

7

example, when a physician diagnoses a patient and writes up a drug order, there is a relationship created in the relational database which connects all four objects: patient doctor diagnosis drug.

FILES can be images, ADT (admission – discharge – transfer) records,patient charts etc.

As shown in the diagram below, a data modeling approach is used to transform the data. Once the data is translated into simple data formats and placed in the staging database, the data will be remodeled and stored in a central database model for better performance.

Application workflowMost of the legacy systems use HL7v2 type message headers. By using standards such as EN13606, EDIFACT, CCD/CCR/HL7, the data will be extracted. For complex legacy systems, the application SDK, API and open source will help vendors develop interoperability modules within legacy systems. Application WORKFLOW:STEP1. Objects, their attributes, their relationships and files will be extracted from the legacy system database.STEP2. These objects then will be converted in to simple form and stored in a staging database. STEP3. The application server will use data mining techniques to transform and remodel the data.STEP4. The data is then loaded to the central database.

Data ConversionOpen source applications must be able to format and restructure legacy data in order for legacy data to be interoperable with new clinical information system databases. This process is commonly known as legacy data conversion. Legacy data is unstructured data from multiple sources or departments within a health care system. An effective

8

conversion consists of the following: establishing data conversion rules, cleaning legacy data, and extracting the data from the legacy system.

The most important element of the legacy data conversion is determining the rules for converting the legacy data into a readable format. This requires meeting with staff and other stakeholders who have used the legacy data and conducting a comprehensive review of the legacy data. Some issues to be addressed during this review include: the retention period of legacy data in the new system, the fields to be used for reporting, and the definition of a transaction or event (Wilson, 2004). Also, during this review, systems developers may also determine how to: identify referential constraints enforced by the target application or database, identify fields that may require default values, identify fields that require data manipulation (such as concatenation or multiplication) and identify fields to be derived from lookups or sequences (Seagull Software, 2008).

Legacy data files have a different structure and content and may be stored in a variety of formats, requiring extensive cleaning to prepare it for later migration into the new system. The most effective and efficient methods to clean legacy data should be established during the initial review of the data and should focus on missing, duplicate or incorrect data. Data cleaning should be performed on each set of legacy data, sometimes more than once, in order to produce a satisfactory data set for migration.

After all legacy data has been cleaned, the data must then be extracted to a file that is used later for migration. There are two key considerations: the data form to be used for extraction and the type of file to be extracted. Legacy data should always be extracted in its original, raw form; it will be easier to identify problems later during an audit of the new system. Data should be extracted to a delimited flat file format because new applications can easily import this format, even if the destination data structure is not known. Once the new system's data structure has been chosen, it can easily be loaded from the data files and does not involve writing code against the legacy system to extract data (Wilson, 2004).

Data MigrationOpen source applications must also be able to transfer data from the legacy system to the new system. This process is called data migration. Legacy data migration has five phases: design, build, test, revision, and migration. In the design phase, IT staff review the list of data fields from each legacy data source and decide if the field is a candidate for migration. This field selection may also occur at the same time the legacy data is undergoing the comprehensive review, as each data field identified as a candidate for migration results in a change to the data model (Hudicka, 1998). In the build phase, data fields are created in the new system that are identical to the legacy data fields and then legacy fields are mapped to the new system fields. During the testing phase, developers check data formats for accuracy, verify the correct number of records and ensure data are loaded into the correct fields (Hudicka, 1998). In the final phase before the actual migration, the revision phase, data mapping is validated and the data documentation is updated. Prior to the actual migration, a pilot migration is performed on a copy of the new data, then the actual migration is performed, followed by post

9

migration testing. The post migration testing is essential for verifying the integrity of the data in the new system and should compare:

migrated fields to fields generated in the new system to ensure that migrated fields are complete and, migrated fields to source fields to verify that fields’ values are migrated per the migration specification (Katzoff, 2008).

Conversion and extraction of legacy system data are complex processes that have a significant impact on the ability of an open source application to transform and share legacy data with current health care information systems. Open source application developers must remember to thoroughly document all processes and consult with end users and other stakeholders to garner support for the project from the initial data selection to the final live migration.

CONCLUSION

In the rapidly advancing field of biomedical informatics, open source software offers academic and commercial interests the opportunity to focus on the troubling aspects of data conversion from legacy systems. Because there are so many older systems requiring conversion, no single commercial or academic entity is likely to commit the energies or finances to solve the complexities of data conversion in healthcare organizations. However, a community effort could form the system kernel which would then be modified and enhanced to address the various legacy data types, software, and hardware found throughout the healthcare system.

The concept of the “open source”, the sharing of practical or technological information, has advanced society and science for millennia. The modern day example of the application of this concept of mutual collaboration is the Internet, which became possible when the United States Department of Defense published open standards to develop telecommunication protocols through the Advanced Research Projects Agency Network (ARPANET). Other examples include the Linux operating system (which controls operations of nuclear submarines) and the open source development of Netscape and Mozilla. The Internet mainstreams programming via connecting programmers together, regardless of distance or location (Cooper, 2006). Google, Amazon, and Facebook use computer software developed with open source computer code (Zemlin, 2011). Apache is an open source success with a market share of 59.4% in 2010, and a product that has been the preferred web server for millions of webmasters since its inception (Pingdom, 2011).

Open source software (OSS) is defined as computer software for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that meets the Open Source Definition or that is in the public domain. This permits users to use, change, and improve the software, and to redistribute it in modified or unmodified forms. It is very often developed in a public, collaborative manner. Open source software is the most prominent example of open source

10

development and is compared to user-generated content. A report by the Standish Group states that adoption of open source software models has resulted in savings of about $60 billion per year to consumers. A paper in Marketing Science by Columbia Business School finds that commercial open source software (COSS) results in high-quality products, and that despite the free riding that is inherent in the industry due to information-sharing, the market creates spillover benefits for both consumers and producers. Prof. Brett Gordon explains the relevance of the study:

"Open source is becoming applicable to more industries – for example, open source has recently made the leap to mobile computing platforms with the release of the Google Android operating system. Overall, we expect the open source market to continue to attract attention, given its impact on product design, pricing, and firm strategy." (Gordon, 2011)

Today it is difficult to find a Fortune 500 company with an IT infrastructure that does not depend, in some fundamental way, on open source software. Major corporations within the computer industry, companies like IBM and Oracle, turned their attention to open source as a business opportunity in the 1990’s. They are looking for innovation, but the rampant creativity that leads to innovation in both science and software comes at a cost (Behlendorf, 1999). Maintaining control of an active open source project can be difficult. This fear of losing control prevents some individuals and many companies from active participation. Even with these limitations, open source software is dramatically more successful today because of the rapid dissemination of information made possible by the Internet. This will improve the possibility of continuing support, but does not guarantee it (Hanganu, 2011).

Clinical information systems must be reliable as health care providers depend on accurate, reliable data when making life or death decisions for their patients. The technology that connects the provider to this information now must navigate multiple boundaries and organizations. Clinical and administrative tasks must be completed on an increasingly rapid timetable to improve care and control costs. Open source solutions have proven their ability to provide reliability, accuracy, and speed, as recommended and detailed in a report by the Department of Defense (Herz, 2011). Vulnerabilities or “bugs” are usually corrected within hours in open source systems. Proprietary vendors often do not release their patches for weeks or months, and vulnerabilities can be exploited until these patches are implemented. Minimizing downtime and guaranteeing message delivery are essential in the delivery of modern healthcare. Quickly repairing any system defects is an advantage of the open source solution.

Security issues remain, with the possibility of Trojan horse programs, back-door access, or intentionally malicious programs diverting data being major concerns. The concept of “many eyes” has been suggested as an adequate guard against these possibilities, but this has not been effectively demonstrated (Hansen, 2002). Proprietary software forces the user to accept the level of security that the software vendor is willing to deliver and to accept the rate that patches and updates are released (Cowan, 2003). The end-user

11

of open source code has the ability to change and modify source to implement any extra features of security they may wish for a specific use, which can extend to the kernel level if they so wish. A drawback of open source software is the fact that anyone can access the source code, giving attackers the opportunity to disrupt system operations (Caloyannides, 2001). Also, simply making source code available does not guarantee that the code will be reviewed for integrity and quality.

Public, private and academic interests could develop a robust system-using framework outlined in this paper for the creation of an open source solution that integrates legacy data with modern data processing systems. Many obstacles exist; however, successfully developing and implementing an open source solution would produce significant cost savings and improve the quality of care in a variety of healthcare institutions and organizations.

12

References:

Beale, T. (2005). The openEHR Integration Information Model. Retrieved August, 2011 from OpenEHR website:http://www.openehr.org/releases/1.0/architecture/rm/integration_im.pdf

Behlendorf, B., Bradner, S., Hamerly, J., McKusick, K.,, O’Reilly, T., Paquin, T., Perens, B., Raymond, E., Stallman, R., Tiemann, M., Torvalds, L., Vixie, P., Wall, L., Young, B. Open Sources: Voices from the Open Source Revolution . O Reilly Media, Inc., 1999. p.33

Bisbal, J., Grimson, J., Lawless, D., Wu, B.(1999). Legacy Information Systems: Issues and Directions. Retrieved August 2011 from website: http://stono.cs.cofc.edu/~bowring/docs/00795108.pdf

Bisbal, J., Grimson, J., Lawless, D., O’Sullivan, D., Richardson, R., Wade, V., Wu, B. (1997). The Butterfly Methodology: A Gateway-free Approach for Migration Legacy Information Systems. Retrieved August 2011 from IEEE Xplore website:http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?reload=true&arnumber=622311

Brodie, M. L. (1992). The promise of distributed computing and the challenges of legacy information systems. Retrieved August 2011 from website: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.55.987&rep=rep1&type=pdf

Caloyannides, M., Landwehr, C., Witten, B. (2001). Does Open Source Improve System Security? Retrieved August, 2011 from IEEE Xplore website:http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=951496

Cooper, D., DiBona, C., Stone, M. Open Sources 2.0: The Continuing Evolution. O Reilly Media, Inc, 2006. pp.37-39

Cowan, C. (2003). Software Security for Open-Source Systems. Retrieved August, 2011 from IEEE Xplore website:http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1176994&userType=inst.

Fehrs, S., Hage, M., Hales, J., Hammond, W., Lobach, D., Prather, J. (1995). Converting a Legacy System Database into Relational Format to Enhance Query Efficiency. Retrieved August, 2011 from website:

13

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2579117/pdf/procascamc00009-0401.pdf

Gordon, B., Kumar, V., Srinivasan, K. (2011). Research identifies benefits of the open source software market. Marketing Science. Articles in Advance. August, 2011. Retrieved August 2011 from website:http://mktsci.journal.informs.org/

Hanganu, G. (2011). The community source development model. Retrieved August, 2011 from OSS Watch website: http://www.oss-watch.ac.uk/resources/communitysource.xml

Hansen, M., Köhntopp, K., & Pfitzmann, A. (2002). The Open Source approach – opportunities and limitations with respect to security and privacy. Retrieved August, 2011 from website:http://dud.inf.tu-dresden.de/literatur/HaKP_02OpenSource_0214.pdf

Herz, J., Lucas, M., Scott, J., Wheeler, D. (2011). Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software. Retrieved August 2011 from Open Source Software Institute website:http://www.oss-institute.org/OTD2011/OTD-lessons-learned-military-FinalV1.pdf

Hoffman, G., Tromp, H. (2003). Evolution of legacy systems: strategic and technological issues, based on a case study. Retrieved August 2011 from website: http://soft.vub.ac.be/FFSE/Workshops/ELISA-submissions/11-TrompHoffman-position.pdf

Hudicka, J. (1998). An overview of data migration methodology. Retrieved August 15, 2011 from Dulcian, Inc. website:http://www.dulcian.com/Articles/Overview_Data_Migration_Methodology.htm

Katzoff, D. (2008). How to implement an effective data migration strategy. Retrieved August 15, 2011 from Data Migration Pro website: http://www.datamigrationpro.com/data-migration-articles/2009/11/30/how-to-implement-an-effective-data-migration-testing-strateg.html

Legacy System (n.d.) Retrieved August, 2011 from website:http://www.businessdictionary.com/definition/legacy-system.html

Park, J., Ram, S. (2004). Information Systems Interoperability: What Lies Beneath? ACM Trans. Inf. Syst., Vol. 22, No. 4. Retrieved August 2011 from website: http://comminfo.rutgers.edu/~muresan/IR/Docs/Articles/toisPark2004.pdf

14

Pingdom. (2011). Apache Web Server Hit a Home Run in 2010. Retrieved August 2011 from website: http://royal.pingdom.com/2011/01/04/apache-web-server-hit-a-home-run-in-2010/

Seagull Software. (2008). The business case for automated data migration. Retrieved August 15, 2011 from Rocket Software website: http://www.rocketsoftware.com/seagull/products/data-migration/resources/technical-resources/smartdb-business-case.pdf

Szolovits, P. (n.d.). Medical Informatics: Computer Applications in Health Care. Retrieved August, 2011 from website:http://groups.csail.mit.edu/medg/courses/6872/96/notes/Tsien/sld016.htm

Thomas, C. (2002). Conceptual, Semantic, Syntactic, and Lexical Model. Retrieved August, 2011 from website:http://www.cs.umd.edu/class/fall2002/cmsc838s/tichi/CSSL.html

Wilson, D. (2004). A plan for successful legacy data conversion. Retrieved August 15, 2011 from Information Management website: http://www.information-management.com/infodirect/20040917/1010466-1.html

VA's VistA EHR System Could Be Low-Cost Option for Hospitals (2009). Retrieved August, 2011 from iHealthBeat website:http://www.ihealthbeat.org/Articles/2009/4/30/VAs-VistA-EHR-System-Could-Be-Low-Cost-Option-for-Hospitals.aspx

Zemlin, J. (2011). Imagining a World Without Linux: Jim Zemlin Opens LinuxCon North America. Retrieved August 2011 from website:http://www.linux.com/news/enterprise/biz-enterprise/484962-imagining-a-world-without-linux-jim-zemlin-opens-linuxcon-north-america