As an industry, healthcare has been behind most other business sectors in adopting Information Technology as a competitive tool. Generally speaking, until the advent of managed care in the late 1980s, the need to distinguish one provider from another was not necessary. Typically, each city or county had a "general hospital" that provided services for the local population. Very rarely did these local providers seek to gain market share from their competition in surrounding communities. Partly as a result of this non-competitive environment, as well as, prevailing economic trends, increases in health care costs began outpacing inflation rates. Employers, who foot the bill for the majority of health care costs through insurance premiums, began to take notice. Pressure on insurance carriers to keep premiums low gave rise to Health Maintenance Organizations (HMOs), which ostensibly focused on illness prevention or "wellness."
HMOs promised lower costs by negotiating fixed reimbursement rates with health care providers. In other words, unlike in the "fee for service" days under standard insurance plans, hospitals could no longer charge a patient covered by an HMO more for a procedure than was negotiated through the HMO contract.
Compounding the cost squeeze for providers was the aging "Baby Boomer" population, which was beginning to turn to Medicare in ever-increasing numbers. As with HMOs, Medicare dictates a fixed rate of reimbursement based on the procedure and the geographic region in which the provider is located.
These factors, in turn, forced providers to find new ways to generate revenue. Taking their cue from the business world, hospitals and other providers began actively seeking new "customers" for their services. Uncommon before, many medical centers engaged in advertising campaigns. Facilities began expanding high-demand services such as heart care and occupational therapy. Providers also turned to IT to provide an intelligence edge on their competition.
Prior to the 1990s, most computer systems designed for health care were mission-specific. There were systems to manage laboratory testing, patient billing systems and admissions tracking systems, but few, if any, companies were developing systems that could encompass the full spectrum of activities conducted in the average medical center. For a time, some larger teaching hospitals developed their own Health Information Systems (HIS), which could act as an integrated environment to support a multitude of service areas. Gradually, vendors took notice and, by the mid-1990s, several long-time players in the healthcare systems market had developed (or bought their way into) first generation HIS.
A properly deployed HIS offers several potential benefits to a provider, depending on the applications bundled into it. Centralized registration, which enables a patient to register once, then proceed to any service area such as laboratory or radiology without the need for a second or third registration is one example. Greater convenience for the patient can translate to a greater likelihood that the patient will choose the facility in the future. HIS may provide access to patient information to physicians from remote locations, thereby forming the basis for a Community Healthcare Information Network (CHIN). This benefits the medical center, as well, since physicians who have access to such tools are more likely to admit their patients into facilities that have them.
HIS platforms may also provide more business-oriented functions such as decision support. For example, a medical center may want to model managed care contracts to see which contracts optimize revenue for the institution. Armed with this information, the provider will be in a better position to negotiate when the contract is due for renewal. Other Business Information (BI) tools contained in some HIS environments provide the ability to analyze patient demographics and enable their users to target services more effectively.
Despite the fact that HIS platforms provide many critical functions "under one roof," most of the current implementations were actually created by pulling together various point solutions and adding an interface layer to allow the systems to act as one "seamless" whole. The degree to seamlessness varies greatly and only in the past few years have developers begun to turn out products that have a truly integrated look and feel. Enterprise Application Integration (EAI) techniques provide this interface layer that is crucial to the modern HIS. To understand HIS, it is essential that we gain an understanding of the fundamentals of this burgeoning integration technology.
Enterprise Application Integration (EAI) can be considered the response to years of isolated systems development. In many organizations, applications have been created and/or implemented in a vacuum, with little or no consideration of other currently deployed or planned applications.
EAI is not a single technique, but rather, a plethora of alternatives to tie isolated systems; also known as "stovepipe" applications, together. When choosing an EAI approach, one must consider not only the target applications themselves, but also the hardware platforms and operating systems that host these applications. These alternatives fall into three broad categories that will be summarized in the following sections.
The most obvious "point of entry" through which to extract data is usually an interface written directly into the target application. The use of such interfaces, also known as Applications Programming Interfaces (APIs), constitutes Application-level EAI (Linthicum, 1999). This approach assumes that the developers have taken future integration needs into account and have provided suitable linkages for external systems. In some cases, these APIs may be developed after the primary application development is complete, but this usually results in limitations in interface functionality.
When dealing with legacy mainframe systems, there may be no APIs provided with the original product. These interfaces can be written into the application after the fact, but this assumes that sufficient metadata exists to make such changes feasible. Additionally, one must consider the costs associated with program modifications, both in terms of dollars and potential downtime. If these changes are deemed too disruptive, the EAI project team might consider the database accessed by the application to be the next best choice as a source for integrateable data. This integration technique is known as Data-level EAI.
While data-level EAI might seem like a panacea for organizations that have built stovepipe applications atop industry standards DBMSs, this EAI method usually requires that some of the processing logic of the target applications be recreated in order to provide data that is calculated, but not stored. Again, the metadata issue looms. It is possible that documentation is not available which details this processing, rendering the data-level approach ineffective in providing all critical data. If neither of the two aforementioned techniques can provide the data required, then the third and perhaps the most limited form of EAI, User Interface-level EAI, should be considered.
User-level EAI accesses data, as its name implies, from the point at which the user interacts with the system. This might be a Graphical User Interface (GUI) as found in most current PC applications or a text-based screen as is common with mainframe and midrange systems. The interface is established by capturing data displayed on the screen with an intermediary program and passing it to the target external application. The primary limitation to this approach is that only information presented to a screen or printer is available for use.
Despite the fact that interfaces are a major component of an EAI strategy, it must be remembered that the terms "interfaced applications" and "integrated applications" are not synonymous. A truly integrated system will not only provide for data transfers between component systems, but will also provide a common look and feel to the user. In this manner, the user of a composite system will feel that he is working with a single application. This is the ultimate goal of EAI efforts, but one that is none too frequently achieved and may not be required.
Now that we have gained a basic understanding of EAI and related implementation approaches, we will now see how these techniques were brought to bear during the complete overhaul of the clinical information systems environment at RRMC.