THERE’S A TECHNO-MYTH full of sweet promises making the rounds. It goes like this: Standards such as Health Level Seven (HL7) will become less important as people implement components and objects for communication and sharing services. And it drives Jim Klein nuts.
The research director for Stamford, Conn.-based GartnerGroup says that argument is "180 degrees wrong." "Integration through components and objects need more, deeper and tighter standards," he says. When applications interact by presenting themselves as components and objects to other applications, you will need to know more than the syntax and encoding. You will need some common data models and shared semantics at a deep level.
Fortunately, none of the standards organizations have slowed their development pace. Quite the opposite. But even as standards development organizations and vendor consortiums advance implementations of standards, true interoperability remains elusive--even for products built on like architectures. But there is hope, and it is more expansive than a single architecture.
Cross-checking
In the emerging component and object technology camps, major developers, namely Microsoft and the Object Management Group (OMG), have put in motion certification processes to further plug-and-play. Both organizations have delegated management of the testing and certification processes to third-party organizations (New York City-based KMPG Peat Marwick LLP for Microsoft products and The Open Group of Cambridge, Mass., for CORBA-based products). When users purchase seal of approval products, they have some assurance that the product will interoperate with other approved products.
And they haven’t forgotten the home-grown varieties. Near-future plans to make the test suites available by online downloads will add standardization depth for local developers. By checking non-commercial products against a reference model, the IS department can raise the bar on interoperability for its own applications against exisiting and future IT investments.
Such recent initiatives for Microsoft’s ActiveX and the OMG’s CORBA products get full marks for benchmarking and demonstrating interoperabilty among like products. Nevertheless, standards proponents have shown us little to resolve the dilemma of communications between the two technologies themselves.
Crossing over
Until recently, users have been resigned to using static bridges between the two platforms, but the end of that era is close at hand. Cross-licensing and collaborative efforts between vendor organizations are resulting in real products that can communicate between the two major architectures, COM and CORBA.
A licensing agreement between Microsoft Corp., Redmond, Wash., with its COM technology, and Iona Technologies, Cambridge, Mass., now brings to market the first bi-directional integration product between COM and CORBA applications. In addition, collaborative efforts first announced earlier this year between ActiveX for Healthcare (AHC) and the Andover Working Group (AWG) support compliance and interoperability for future products.
Vendors together
Vendor cooperation toward the delivery of standards-based products is the key to success, says AHC committee member Bill Bysinger, chief technology officer of Health Systems Technologies Inc., Seattle. "The two initiatives will be complementary," he says, "not at odds." And contrary to widely-held perceptions of animosity between the two major technology backers, he reports good working relationships between their respective working groups.
OMG Medical Domain Task Force member Harold Solbrig, senior product development specialist at 3M Health Care, Murray, Utah, seconds that. He stresses that although specifications are bound to the Object Management Architecture, the work is not inextricably tied to CORBA: "If we do our jobs right, the results will be equally valid and useful in CORBA, DCOM, XML and hopefully other environments as they arise in the future."
United under HL7
Not only are the AHC and AWG initiatives complementary, Bysinger believes that HL7’s structured data formats and messaging standard is the common denominator in their initiatives. As the base level component that both ActiveX and CORBA can use in the clinical environment, HL7 is the unifying element between the two main component architectures. It has no real contenders for the throne and is likely to be the dominant standard for inter-process communications within healthcare.
HL7 standards are already widely used for linking clinical applications in healthcare. Although not without some "wobble" in the current version 2.3, some of the best minds in medical informatics are focused on developing more, deeper and tighter standards for the upcoming HL7 version 3.0--just the ticket for components and object-type middleware. As part of the standard, HL7 3.0 will have abstract messages that will direct mapping to a CORBA object, an ActiveX object, a traditional ASCII-text message or an XML document. "What HL7 is doing with 3.0 holds out hope that the ability to interface disparate applications is going to get better," says GartnerGroup’s Klein. (HL7 3.0 is scheduled for balloting 4Q99 with publishing, 1Q2000.)
Chasm closed
Wait, there’s more. Some of the best news Bysinger brings is the cooperative venture between the AWG and AHC to publish a set of corresponding standards. When completed, compliant products will enable users to move HL7 messages and data formats smoothly across the COM-CORBA chasm. It’s too soon to look for 100 percent compliant products--they don’t exist. But when next-generation products start shipping at the end of this year, vendors may start offering compliancy building blocks. The transition into the new environment won’t happen overnight, but take heart, it’s beginning.
Charlene Marietti is senior technology writer at Healthcare Informatics.
