If you think solving Y2K problems will put an end to technology upheaval at your facility, you may be in for an unpleasant surprise. New modular software programs based on object-oriented programming principles are about to shake up the healthcare industry. Variously known as object technologies or componentization, depending on how strict you are about definitions (see "Component Speak," page 68), this trend is forcing a Who’s Who list of healthcare software vendors to work feverishly behind the scenes to develop new standards and architectures. When the smoke clears, the healthcare industry could see the end of large, monolithic applications that you update with unwieldy revisions every few years.
Replacing tradition will be software chunks that you plug in like building blocks to an umbrella architecture whenever you need to revise a program or add a new capability. If you haven’t gotten a heads up from a software rep yet, you’ll soon be hearing promises like, "Get over one more installation hump, and revising software will become as easy as popping in a new videotape in your VCR."
When will software Nirvana arrive? Starting now and hitting full force in the next 12 to 24 months--if you believe marketing brochures. Support for componentized applications comes from heavy hitters like HBOC, HealthVISION, IDX and SMS, plus component software pioneers like CareFlowNet. But before the promise becomes a reality, software vendors and standards organizations have to solve knotty interoperability problems that have long kept competing applications from working together. In part, the solutions revolve around burying some proprietary technologies, which, it’s important to remember, have helped today’s big companies get big.
However, technological prudence demands an object-oriented approach by software vendors for the future. "No [vendor] in its right mind wouldn’t be working on an object-oriented architecture today," says Tom Hurley, vice president of First Consulting Group, Phoenix.
But how should healthcare organizations respond to the components craze? For now, components are mainly for pioneering hospitals that are trying to solve unique problems. For others, today’s challenge is to understand the new way of building software, what it can and cannot do, and how to prepare for the brave modular world.
Tuning in to components
Not unlike other technology areas, such as Y2K deployment, the healthcare industry lags finance, manufacturing and other industries in its adoption of component technologies. Since the early part of the decade, corporations in these sectors have been buying and building early componentized software to help them adjust information systems to fast-changing business needs and to build applications with best-of-breed software from a variety of vendors, rather than relying on a single software supplier.
Despite progress in developing standards, healthcare software vendors so far have been hard pressed to deliver componentized applications. "Everyone is talking about components, but there’s a very short list of people who have actually delivered," says Jim Klein, a research director for GartnerGroup IT Healthcare, Great Falls, Va.
Part of the reason for delays is that many hospitals aren’t demanding components yet. "Healthcare professionals make decisions on patient care features. Unless [componentization] criteria are brought to the front end of the buying process, it won’t happen," says LaDonna Shedor, chief information officer for Centra Health, Lynchburg, Va.
But that doesn’t mean the healthcare industry doesn’t understand the potential of components. "Healthcare is anxious to get better plug and play of packaged applications" and components are the latest best hope for achieving this, says Klein. The average 350-bed community hospital doesn’t develop its own applications, so being able to pop in a software module purchased from a third-party component vendor is almost like unleashing a programming staff to write a custom application, he adds.
Changing channels
To make components interoperable among applications from different vendors, the industry needs backbone standards like Object Management Group’s CORBA and Microsoft’s COM specifications, which define ways for components to travel and interact across organizations.
In a sense, CORBA and COM take up where HL7, a universal format for describing and exchanging medical data, leaves off. Instead of replicating data for each application, as HL7 does, CORBA and COM maintain a single copy of the data and provide interfaces that let applications tap into the database. Because only one data copy exists, doctors, nurses and administrators don’t have to wonder if they’re dealing with the latest information.
Although OMG and Microsoft talk about creating bridges to the other’s platform, software vendors face a more complicated reality influenced by competitive pressures and scarce development resources. The result is a kind of religious war between CORBA and COM. CORBA proponents value the consortium approach to creating the technology and its associated set of medical-specific specifications known as CORBAmed. A cross section of software vendors and end users participate in a give-and-take that creates the specifications. "As a member of the OMG, we can contribute to the standard," says Eric Butler, senior systems architect, with Baptist Health Systems of South Florida, with locations in and around Miami. "We go to meetings to make sure our needs are met."
By contrast, COM standards receive input from a cross section of the medical industry, but the definitions and technologies that ultimately become commercialized are up to Microsoft. As always, the benevolent dictator approach has one major advantage over the committee method: Things get done faster. COM enjoys another asset, namely the marketing muscle of Microsoft, which can promote the technology directly through developer meetings and indirectly with each increasing share of the operating system market Windows NT gobbles up. The downside is that COM is written first to serve the Windows platform, while CORBA is built to natively support a variety of computing platforms including Windows, Unix and Java.
"Realistically, 95 percent of ISVs [Independent Software Developers] and systems integrators are using Microsoft’s technology," says John Quinn, principal in charge of the Center for Healthcare and Emerging Technologies for Ernst & Young. "This is partly because Microsoft actually has a marketing plan, plus it is dominant on the desktop. Also, Microsoft makes COM very convenient to use. You can go out on the Web and find widgets, for example, that you can put a radiology image into."
For the time being, hospitals must watch both standards and assume that neither will gain dominance immediately.
Another difficulty lies in developing a kind of Esperanto for components, a way for the software modules to talk to each other so that components can work across different platforms. For example, a component from a lab system application needs to understand a CPR system component when it asks for a piece of data or when it stalls because some error has occurred in the interaction, says Klein. "We need to get a lot more formal about clearly defining these types of interactions," he says.
In the end, healthcare organizations should embrace componentization, once they’re satisfied that their vendors of choice are selling ready-for-prime time products. "There’s no question that a hospital’s strategic direction should be in componentization of business logic," says Hurley, of First Consulting. "The reason: You can’t predict your information needs very far out into the future. Components allow you to quickly adapt your computer systems to your needs. If you can’t adapt your application you’re at a disadvantage."
Getting Better Reception
GIVEN THE STILL EMERGING NATURE OF components, how can healthcare organizations make strategic technology decisions? Even if you’re not ready to become an early adopter, there are things you should be doing now to get your organization ready for the modular future.
DO YOUR HOMEWORK
Above all, educate yourself about component technology. "It’s easy to get misdirected by vendors," says Jim Klein, a research director for GartnerGroup IT Healthcare, Great Falls, Va. "Vendors say, ’We can distribute our applications across the enterprise.’ But when you box them into the corner, you may find out the technology is still in the lab." He advises IT departments to "know what the terms mean, what the technologies can do."
INTERROGATE VENDORS
Whenever you talk to current and prospective software vendors, find out their standards allegiances, especially as they relate to CORBA and COM. Then get vendors to pin down how they’ll build bridges to the other platform. This is true even if you see yourself as a single-platform shop. Even if you’re an NT convert, you may need CORBA in the future to reach out to a Unix system that comes under your control after a merger, or to integrate a CORBA-compliant component that a third-party component vendor may market in the future.
"Find out how the vendor models data within its application, " adds Bill Bysinger, chief technology officer and cofounder of Healthcare Systems Technologies, Seattle.
"Asking how the application connects to the data goes to the heart of the problem of turning raw numbers into information," he says. In addition, find out how the application connects to a data warehouse. The program should be compliant to some form of data standard, like HL7 or X12. "Ask the vendor to show you how an application would solve a hypothetical problem using the data model. For example, when a patient comes in, what are his benefits? You should be able to create a report ad hoc. Also find out how the application will interact with data you already have. Is it through a native capability or through a third-party product?"
ELICIT THE HELP OF CLINICIANS
The IT department at Centura Health, Lynchburg, Va., tries to educate clinicians on what new technologies and capabilities are coming to market so care givers and IT people can work together to buy the best products. Having clinicians ask questions about interoperability demonstrates how important the hospital considers this area. "Vendors respond to clinicians," notes LaDonna Shedor, the CIO.
GET VENDORS TALKING FACE TO FACE
To avoid interoperability problems and finger pointing, Shedor tries to get vendors around a table to agree on how they’ll get protocols working together in each other’s applications. "If they can’t determine how the applications will interoperate, the vendors don’t get the sale," she explains. "I don’t think hospitals typically put their medical buying on that level."
JOIN STANDARDS ORGANIZATIONS
Eric Butler, senior systems architect with Baptist Health Systems of South Florida, believes participation in the CORBA or COM development process is the only way that healthcare organizations can be sure their needs will be addressed. "You have to ask for things like CORBA interfaces or you won’t get them. I’d like to see more hospitals within the OMG. The more end users we have, the more robust the specifications," he says.
Component Resources
Medical Center Information Systems
Duke University
http://www.mcis.duke.edu
Microsoft Healthcare Users Group
http:///www.mshug.com
Object Management Group
http://www.omg.org
Component Speak
ActiveX:A component-to-component communications specification developed by Microsoft and based on the company’s Component Object Model (COM).
ActiveX for Healthcare: Initiatives by Microsoft’s Healthcare Users Group (MSHUG) to promote the Microsoft specification in the healthcare industry. Initial work focused on creating HL7 messaging objects.
Business object: An application-level component that can interact with other objects to perform a desired task.
Clinical Context Object Working Group (CCOW): A client (versus server) oriented specification for application-to-application interfaces to help distribute data across applications in an enterprise. Initial release addresses patient data and supports Microsoft’s COM/ActiveX environment. CORBA support may come in the future, depending on demand.
Component Object Model (COM): Microsoft’s standard for defining and building business objects.
COM+: Currently under development, next generation COM probably with the Microsoft Transaction Service.
CORBA: The Object Management Group’s standard for defining and building business objects.
CORBAmed: An OMB task force working to build interfaces for patient identification services and other healthcare applications.
Enterprise JavaBeans: An architecture for deploying multi-platform components in Java applications.
HL7: Health Level Seven is a specification for data messaging in medical applications. Version 3.0 is under development and due out in 2000.
Java: Sun Microsystems’ object-oriented programming language and computing environment.
Alan Joch, formerly a senior editor atBYTE magazine, is a contributing editor to Healthcare Informatics.
