Just a few years ago, a typical healthcare market was largely a hodgepodge of insular providers that failed to coordinate care or communicate information about patients.
Under market pressure to remedy those shortcomings, hospitals and other providers have been forming diverse healthcare networks that advertise a continuum of complementary, coordinated services.
Healthcare today is saturated with affiliations, strategic friendships and other deals where executives of various institutions join to sign on the dotted line. But when the backslapping stops and the flashbulbs stop popping, the typical healthcare network is likely to be much the same hodgepodge of insular providers. The difference is, they're now supposed to communicate but still can't.
That's because the conglomeration of information systems in use throughout the networks dates back to the insular era in which each department or facility was an island. The main concern was how well the computer system served the provider unit, not how well it interacted with computer systems at other units.
But now, computer interaction is suddenly Job One. To do the job, budding networks face a succession of integration challenges, according to healthcare consultants and information executives.
First, they have to retrofit their information systems with an integration mechanism just to be able to coordinate and share the data within their existing base of computerization.
Next, they have to round out their roster of information systems to capture and report data that are now committed to ink and paper. Patient data that once could be filed in a department or facility must now be able to travel throughout the system and contribute to a comprehensive picture.
Finally, the integrated system must be able to accept incremental computer innovation and new network partners, all without upsetting existing operations or squandering previous investment.
Understanding the technology.
Luckily,technology has been racing to meet healthcare networks at this critical juncture in system development, said Andrew Lederer, a senior associate with the Kennedy Group, a Redwood City, Calif.-based healthcare consulting firm.
A few years ago, the integration implementation would have looked like the software equivalent of spaghetti-wiring among all the disparate information systems inherited by the network. But advances in technology are providing "the capability to successfully integrate systems in an easier way than was possible in the past," Lederer said.
To reap innovation for the good of the network, though, top managers in healthcare will have to become much better versed in the strategic value of information systems and stay on top of advances, said Stanley Nelson, president of the Center for Clinical Integration.
Nelson co-founded the Minneapolis-based center in spring of 1993 to give extra support to top management on emerging integration issues such as computerization.
"My generation of CEOs is very uncomfortable in terms of their level of understanding of information technology and how it's going to be applied to these integrated networks," said Nelson, 68, who headed Henry Ford Health System in Detroit for more than 15 years before retiring in 1988.
Despite the discomfort among health network executives, "there's a broad understanding that the information system is going to be the central nervous system of that entity, the glue that holds it together."
But before networks can come together, they need to acquire and apply the glue that can hold their information systems together.
The connection task.
The basics of integration call for all systems to be able to communicate and contribute to a systemwide pooling of information, said Lederer.
But systems can't trade or pool information unless they convert their messages into something that can be understood among incompatible systems. A translation mechanism converts data sent in one system's format to data in a compatible format for the receiving system.
These translation mechanisms, called interfaces, traditionally were done point to point-from system A to system B and back the other way. But it's one thing to link two systems and quite another to interconnect dozens, as the current health network requires.
Conventional meshing of dissimilar systems is a time-eating, labor-heavy custom job that involves bridging software and hardware disparities bit by bit. All commands and particular ways of organizing messages have to be translated from one system to another.
That usually requires competing vendors to cooperate in decoding each other's organizational blueprints and also recoding their nuts-and-bolts instructions for differing hardware and operating systems.
The scale of the problem increases exponentially when each of the systems has to be connected to many or all others, said J. Steve Rushing, an Atlanta-based partner with Andersen Consulting. The information systems department just can't keep up with network-induced demands to hook up systems in short order, he said.
"When you run the arithmetic on it, you either have to tell someone you can't get to them until year five or six, or you have to get an incredible increase in your work force to get the jobs done," Rushing said.
Practically speaking, network integration can't be done point to point, said David Weiss, vice president for information services at St. Louis-based BJC Health System. "It would take you forever to get there."
BJC is in the process of integrating six of its 15 hospitals after merging three predecessor systems two years ago, each with its own base of computerization. Getting those first six hospitals interconnected involves interfacing 37 major information systems, including eight for clinical nursing, eight for patient accounting, six for laboratory and six for radiology, Weiss said.
The integration hub.
A squadron of software specialists is moving to troubleshoot the integration problem (See related story, p. 58). Instead of treating each interface as a separate custom job, a product called an interface engine or integration hub is doing the translating and switching all in one place.
From an organizational standpoint, the integration system works much like the hub-and-spoke system adopted by airlines to simplify their route system and facilitate connecting flights among hundreds of destinations.
Instead of setting up individual flights from a mid-sized city to a dozen other points, one flight goes to a hub airport in a major city. There, the coordination is already worked out for connecting flights to many final destinations.
With an integration hub, the transport of data between and among information systems works much the same way in a healthcare network (See chart, p. 58).
"Instead of building all those point-to-point transactions, you send it to the hub and it translates that to the systems," said John Vitalis, vice president of consulting services with the Kennedy Group. The hub is programmed with the connecting schedule that defines where the transaction needs to go, and it's routed to those destinations, said Vitalis.
That takes care of only half the challenge, though. A streamlined hub-and-spoke design only works if the data are effectively translated and exchanged among disparate systems.
Until recently, the technology was inefficient and slow, said Rushing. But it didn't matter much because there hadn't been a great need for interface engines.
During the past six months, however, the rules of the healthcare game have changed so much that integration hubs have moved from marginal player to central focus, he said. "The good news is the technology has also improved a great deal over that same time."
Some integration hubs are designed to make the construction and operation of multiple interfaces speedier and less elaborate. To do this, emerging industry standards for message formats are being used in the exchange phase.
To further speed up implementation, interface engine efforts draw on "libraries" of already-executed translations between vendor systems, modifying the library copies as needed instead of always starting from scratch.
Another technical approach is to convert data coming into the hub to a common vocabulary that all the "spoke" systems understand.
Technical descriptions aside, "it's a solid piece of technology in the middle," said Gary Bartlett, project leader in charge of integration technology for the network being formed by Emory University Hospital in Atlanta. "I see it as a fundamental architecture. Once you establish the connections, it's there and it works."
Over time, the architecture can bring down the cost of interface work to a tenth of its current expense (See related story, p. 54). And it gives health networks some latitude in preserving, adding to and planning for a data-exchange backbone in a climate of constantly improving technology and applications.
Preserving what's installed."The days of throwing out what you've got and buying something new are over," said Deborah Davis, vice president in the Clearwater, Fla., office of Superior Consultant Co.
But until recently, such a scorched-earth approach to retooling for integration was considered a plausible alternative to the complex, point-to-point interface marathons that loomed as the price of staying with the existing investment, said Rushing.
Increasingly, though, starting over is a workable approach only up to a point. Demands on health networks for more service coverage, both geographically and across a healthcare continuum, have created the need to accept or prepare for a greater number of entities than first envisioned, Rushing said.
At BJC in St. Louis, "mass replacement of all information systems was not the way to go," said Weiss. Besides being costly and time-consuming, starting over had "no great track record of success," he said.
Even if replacement were affordable, there's no guarantee that other entities would not join BJC in the future. And the replacement assumption also did not take into account such components as home healthcare systems that likely wouldn't be part of a major vendor's product line, he added.
The five-hospital Evangelical Health System in the Chicago area had been integrating its information systems since 1989, and it recently finished the job, said Charles Colander, who directed it. "But now we're eight hospitals," he said, referring to the addition of Lutheran General HealthSystem in January as well as affiliations with two other hospitals "that could turn into mergers."
Colander now finds himself the director of information services for Advocate Health Care, the merged system comprising EHS and Lutheran General that's consolidating and reorganizing into three regions.
Information systems will have to be organized around hospital service areas and their ancillary and physician-practice sites, he said. In addition, the data systems will have to be able to follow patients across regions for specialized care and other instances where patients need to be seen outside their usual boundaries of care delivery, he added.
Interface engines will be a key component of that new round of retooling. Though financial and payroll systems are slated to be a single-vendor solution, clinical system replacement is out of the question. "That's not a wise strategy, period," Colander said.
Meanwhile, the interfacing nightmare has faded. Speeds of interface engines have increased, and vendors are moving toward a programming approach that reduces a once-complex task to computer-mouse drags and clicks on a computer screen, Rushing said. That's another cost-effectiveness argument for preserving existing systems, he said.
"Healthcare is changing so much. What that really means is you have to plan a way to make change happen," said Jerry Scott, president of Healthcare Communications, a Dallas-based vendor of interface engines.
The integration hub, once set up, does more than run the current data-exchange formula. It also provides a means of introducing new and innovative software while replacing and retiring older systems. "The key here, I believe, is that you can accommodate proprietary architecture and disparate systems for years and years to come," Scott said.
Since the process involves two largely discrete steps-transmitting data to and dispatching it from the hub-a replacement system already would have half the integration job done for it, consultants said.
And the integration technology also makes it unnecessary for health networks to decide on all the components of an information system at once, said Davis. "It empowers hospitals to make the decisions when it's appropriate for them, instead of being forced by some market," she said.
New capabilities, such as data repositories, can be phased in according to what a network can afford, allowing decisionmakers to concentrate on computerizing paper transactions first, she added.
When it's time for a data repository-either the data-capture systems are all in place or the price of the repository falls to within a network's price range-it can be added as one more spoke connected to the central trove of transactions.
This troubleshooting of existing integration problems is taking place a aginst a backdrop of emerging software standards and compatibility formulas.
In contrast to much of the existing computer systems in healthcare, advanced systems promoted by vendors are adopting industry standards for message organization and computer operating systems. In theory, that would make integration hubs obsolete once the older generation of information systems is retired.
But integration hub vendors say healthcare networks can't count on the computerization industry to become homogeneous. "Who knows that someone isn't going to come up with another operating system a few years from now that makes the other systems disparate again?" said Scott.
Initiatives such as the Health Level Seven effort to standardize clinical messages are making progress, but the vocabulary of healthcare doubles every two to three years, said Mark Shary, chief executive officer of HubLink, a Columbus, Ohio-based vendor of integration hubs. Just keeping up with new demand for standardized terms will be difficult if not impossible, he said.
It's taken many years for vendors to develop their own computer vocabulary for the complicated field of healthcare. Shary said he doubts vendors will scrap that kind of detail for the more general standards.
Just the enabler.Integration hubs
themselves aren't the answer, either. They're just the beginning of the task, said Davis. "Interface engines are not the end-all to every problem. They've been getting trade press like crazy, but they're not going to solve all the integration problems."
The first problem to solve, she said, is a basic strategic one: How does a network recognize patients coming into any entry point in the network? And what does the network need to know about them?
"The systems have to start there," Davis said. "That's not even at the level of how do we tie things together."
Healthcare organizations could start solving that problem by implementing some basic computer-indexing programs now coming on the market, with the capacity to identify patients the same way across different information systems. Other more high-powered software is under development, but these elementary products can get the job done for now, she said.
The BJC integration effort, called Project Spectrum (June 27, 1994, p. 65), includes much more than interfacing and interconnecting facilities, said Weiss. The piloting of a master patient index, working through a data repository, is a high priority of the fledgling effort, he said. Also planned is a connection between that repository and another that's being built to handle diagnostic images.
And Project Spectrum is but one of 24 BJC information system projects going on at the same time, all attempting to add computer capability and foster greater integration of the health system, said Weiss.
"Then as healthcare networks evolve, whoever has this technology is going to be in a leadership position," Weiss said.