At 04:50 PM 2/9/2003 -0800, Walt Biggs wrote:
HL7 was originally designed to permit message exchange between two systems
in the same organization. Originally, it involved a lot of negotiating
between the TWO partners. I attempted to convince people that a message
standard, especially one so vague in detail, could not be used to
standardize data. Once you are sending the data to someone else, it's way
too late to standardize it. You need to standardize the concepts before
you collect the data, much less represent the data, first perhaps in a
database, then in a message.
I basically agree with your observations.
Some of you met Ray Aller at the OSHCA meeting at UCLA. I don't know if
he left it in (I asked him to leave it out as it seemed incendiary), but
in a paper back in 1994 or so, he was saying something like "If you left
out all optional or user-definable data in an HL7 message, it would
transmit no information at all."
But on the practical side, with the vendor community's support for HL7,
and the fact that most people decided that they would just work with ONE
health informatics standard, it's been the only show in town for a lot of
participants. I have had an interest in CORBAmed, but it has seemed
expensive to participate in (for someone paying out of their own pocket),
and slow to gain broad acceptance. I still think it is the right
direction. There are a lot of needs for standardization of data in
health, but the concepts need to come from medical domain experts, not
hardware engineers for vendors.
The weakness in the OMG has been that it is mostly vendors. But that need
not be the case (we aren't vendors, for example). Federal participation,
in fact, is quite cheap. Costs are also low if you aren't submitting an
implementation of a spec, but simply voting on the specs. Also the specs
are free once complete, as opposed to HL7, where the actual spec costs
money and requires a particular commercial technology to obtain it. The
efforts in the OMG now are primarily in the higher level models, which are
important and even less dependent on a particular implementation.
To me, there is a great harmony between open source efforts and
standardization. I hope that the huge momentum that open source is
gaining in the world will also expand standardization efforts for data and
process description. Behind the idea that standards should have
limitations on their distribution is someone who is thinking of making
money, not of having the most useful and broadly-accepted standards. The
idea that we are required, for example, to use a proprietary system to
code clincal procedures for billing to Medicare seems ludicrous. If you
want to make a system work better, any impediment to access to information
used in the system will have a cost in accuracy, efficiency, safety, ease
of analysis, etc.
Unfortunately, there appear to be a lot of these obstacles in healthcare.
I'm also concerned with some other issues of proprietary rights, with such
things as genomic data. I hope the day comes soon when the entertainment
business realizes that free distribution of much music and video, for
example, gives it to people who never would have paid for it, but are some
of the best advertisers of the content, thus increasing sales to people
who can and do pay for it.
I look forward to meeting you, Dave, at the eGovOS meeting next month.
Same here,
Dave
Walt
David Forslund wrote:
I have some strong views on this. There is a lot of confusion going
around HL7 interfaces have nothing to do with programming
interfaces. One is speaking of two completely different concepts with
the same set of letters. HL7 is dealing with data, OMG deals with
functional behavior (and handles data, of course).
I would agree that HL7 has encouraged "balkanization" of health IT.
I've had to do several hospitals on a small scale and each has their own
interpretation. There is no ability to look up a term electronically to
find its definition. One has to get the HL7 manual from each institution
to see how they've interpreted the spec. This is unacceptable.
The goal of the OMG is to have a fully electronically negotiated
interaction, such that one doesn't have to read a localized manual to
determine how systems interoperate. More specifically there is a real
API that allows systems to communicate with one another. This does not
exist with HL7. One can create messages and responses, but there is no
rigorous API for doing so.
In any case, the use of the term "Interface" by HL7 is not what we are
talking about in a programming interface with well defined semantics.
Dave
At 09:19 AM 2/9/2003 -0500, John S Gage wrote:
Dave,
At the risk of beating a dead horse, could you just delineate the
differences between your interface approach and the interface approach
of HL7. One, I think, justifiably could argue that HL7 has actively
supported the balkanization of health IT (vendors basically run HL7),
whereas OMG can lead away from balkanization.
For example, it is relatively difficult to interface two systems
using HL7. Is it easier with OMG CORBA? Does it require more or less
effort on the part of the people doing the interfacing?
John
On Saturday, February 8, 2003, at 10:57 PM, David Forslund wrote:
This is exactly the reason for components which can enable the
construction of
a system rather than a monolithic system. This approach has been pursued
by the OMG's Healthcare Domain Taskforce, which has 4 international
specifications
with well defined interfaces that have been implemented by multiple
vendors and
open source developers. The failure of these to be widely recognized
is due to
two factors. One the lack of understanding of the value of this
interface approach
and the desire of vendors for this approach to fail since it could
radically lower
IT healtcare costs. The importance of this can be understood by
realizing
that there are potentially many implementations of the Internet's DNS
service, but
no one worries about the vendor because the programming interface is
well defined.
If it wasn't the Internet wouldn't function because it would consist of
a bunch of balkanized
states. This is the state of healthcare (in the US, at least) IT, and
won't improve
until people realize the importance of interoperable components that can
be used by everyone within the healthcare domain. These standards
exist (although
not complete), and have been ready for use for a long time. I've been
trying
to get the Open Source community behind them because of their importance
and the desire to produce low cost healthcare solutions available to all.
Dave
