How would you differentiate between HL7 messaging and CorbaMed interfacing? Are they,
in reality, two different ways of doing the same thing, though one uses common objects and the other uses messages?
The healthcare industry has worked out using message oriented middleware (MOM) very, very well. Transaction based standards like HL7and X12N leverage the benefits of MOM. However, using MOM and transactions is not ideal for every business process in a healthcare enterprise. Thus my interest in CORBAmed began...living in the bowels of the Medical Center toiling endlessly on the Interface Engine, data translations, mapping of vocabularies, and heaven forbid security! Problem: the Interface Engine required multiple clients to accomplish data interchange. Many of these where proprietary, with much hidden logic behind the veil of a software application. The HL7 or X12 transaction syntax took care of getting the data from one system to another, but larger issues loomed large. After too much time running my head into the proprietary brick walls, I came to the realization that standardization of how the software needed to compute the data would be a very good thing.
This brings us to a discussion of the benefits of using Enterprise Components.
Without seamless standardized Enterprise Components as a mechanism for the deployment of information you are forced to rely on redundancy throughout your enterprise. This redundancy creates maintainability problems due to the latency in providing timely extensibility. Eventually this has a great impact on the productivity of the end-user.
So where do Enterprise Components come from? Well, in today's market you can pay a vendor to develop/deploy them for you. Personally, I would very much like to see some Open Source Enterprise Components developed for the healthcare industry based on the HL7 RIM definition, using standard interface definitions (CORBAmed services).
So why do we care about Enterprise Components? What are the benefits?
Messaging standards move the data, while CORBA based components 'leaves (and uses) the data where it lies'. Major implication of this is that if one uses only data interchange to interface between different systems, you end up with multiple copies of it and a synchronization nightmare. In fact, the synchronization is never really achieved, causing significant data quality issues.
Allowing a client to ask a remote system to perform procedures, allows the organization freedom to consolidate functionality into common services that all systems can use. For example, if you have a Clinic system, and a Radiology system, and a Nutrition system, they can all share the same appointment Scheduling Service (Enterprise Component). This not only avoids duplicate development efforts, but it prevents the integration problems that occur when each of these standalone applications implements appointment scheduling in slightly (or significantly) different ways. It also provides uniformity of the appointment scheduling business rules, and better data quality for studies such as clinical utilization rates.
This line of reasoning gives you the opening to get a bean in the jar about the power of encapsulation and to limit the impact (read 'cost') of change. If an organization�s business practices change, that requires a change in appointment scheduling, the change is required to one component, instead of four separate pieces of functionality.
Of course, this line of logic is all based on the HL7 message based version (2.x). Version 3.0 of HL7 promises to do many things. It has been a while since I attended an HL7 Technical Steering Committee meeting. Does anyone know when HL7 will be ready for ballot? The only implementation of HL7 version 3 I've seen is the recent demonstration at HIMSS. Are there any HL7 version 3.0 implementations on the market today? How long will it take for them to be made available? What impact will (could) Open Source Enterprise Components make on the healthcare software marketplace?
Feeling philosophical this AM,
Mary
At 04:13 PM 5/8/00 -0400, you wrote:
Thank you for a comprehensive reply! One quick question.
"standardization of correlation manager interfaces" and "information
required for Healthcare transactions" are not semantically that
different, particularly when one adds in the additional wording having
to do with "all operating systems", "all platforms", etc. How would you
differentiate between HL7 messaging and CorbaMed interfacing? Are they,
in reality, two different ways of doing the same thing, though one uses
common objects and the other uses messages?
John
Mary Kratz wrote:
>
> Clearly, HL7 is not in the business to standardization of
> correlation manager interfaces, but rather in the information required for
> Healthcare transactions.
