The Integration Challenge
Monolithic Systems
The challenge of integration has evolved over the years as the scale and extent of computing has increased. While the examples here are healthcare-specific, integration requirements in various industries have evolved in much the same way. Initially, automation in healthcare was monolithic. The number of necessary applications was small—usually Admission/Discharge/Transfer (ADT) functions, basic orders (usually just charge entry), and a billing system—and one vendor typically provided the whole suite. The application goal was simple—capture all the charges associated with a patient visit so that a bill can be generated and someone can pay. All the applications would reside on one system.
Figure: Monolithic System
Vendors managed integration entirely as an attribute of common application requirements on the system. Use of shared files or even multiple instances of the same file solved the problem handily, especially since everything existed on one system. A little inelegance could be forgiven because the system was self-contained.
Scale and Demand—Problem of Logical Distance
As the business scale and demand increased, the single system model became less practical. Memory, disk storage, and processing power were extremely limited compared to current systems, and vendors were forced to split applications across machines to gain needed space and horsepower. (By way of context, some hospitals ran whole multi-user systems in 256KB or memory with several hundred megabytes of disk storage!) Multi-host systems presented a new application wrinkle—a problem of logical distance—where applications still need to access shared or common data, but the only way was to cross a communications gulf to another machine.
Figure: Single Vendor/Multi-host Scenario
Vendors solved his problem of logical distance with proprietary interfacing schemes that addressed most, sometimes all, the requirements of establishing and maintaining a communications link. The Open Systems Interconnection (OSI) model was not yet fully defined, and virtually no useful integration tools existed beyond whatever minimal facilities a hardware vendor included in operating system libraries. The problem of logical distance was solved simply by developing additional functions and raising the price of software.
Best of Breed
By the early 1980s, dozens of vendors had emerged and dominated the market for healthcare automation. Attempting to maintain their position in the market as well as a nearly exclusive hold on their customers, vendors continued to expand the range of software applications in their integrated suites. Since maintaining the necessary expertise in house to respond to every unique application need was impractical, few of the ancillary systems were adequate to their tasks.
Specialty vendors emerged offering superior application function and performance by confining themselves to what they did best—laboratory, pharmacy, radiology, etc. Hospitals now laboring under increasing cost pressure looked to run departments as efficiently as possible, and this required specialty systems. Systems were purchased and a painful process of interconnection began.
Figure: Best of Breed—Potential Point-to-Point Confusion
The problem of logical distance presented itself again in the challenge of integrating these various systems. Each vendor had a preferred, frequently incompatible method for interfacing. Negotiating an interface became an extremely expensive and time-consuming process of resolving every detailed question of communication and protocol. Vendors seldom agreed about any of the details, so every interface became a matter of custom programming for every vendor involved. Often, reprogramming would be necessary when any of the vendors provided a software update. The resulting operational environment was usually fragile, complicated, and resource intensive. Customers began seeking a remedy for the pain of integration.
The Open Systems Interconnection (OSI) model was, by this time, largely defined. A standards movement began to evolve and entrepreneurs emerged quickly to respond to the technical need for better integration. In a market shift initiated by the first HL7 proposal and Don Simborg's (Simborg Systems) StatLAN, an application that brought information from disparate systems to the desktop, a whole new product category surfaced—the interface engine.