At 04:04 PM 3/3/00 +0000, jeff b wrote:
>On Thu, 02 Mar 2000 Alvin B. Marcelo wrote:
> > It has been silent. But I know the projects have been surging on...
> >
> > Question:
> >
> > It was mentioned that most of the open source projects, being generated
> > from ground up, have the unique capability to integrate interoperability
> > right at the start.
> >
> > But has the alliance agreed on what level of interoperability this would
>be?
>
>No. I've tried to bring this up several times, unsuccessfully, and was
>basically either ignored or told what internal data format I should be
>using.
I thought this was discussed pretty thoroughly a while back. I know I
responded to it but
haven't recently because I was attacked for proposing a solution even
though it was
based totally on international open non-proprietary standards.
> > So far the interoperability solutions that have been presented were:
> >
> > CORBA
> > CORBAmed
> > HL7
> > CEN
> > GEHR
> >
> > Are all these players on the same field? meaning: can I proceed with my
>EMR
> > project, with my own database, with my own programming language, and with
> > my own operating system, and _still_ be interoperable with the other open
> > source projects?
>
>Well, in a word... no.
>
>Each standard is either an interchange format or an idea for how to keep
>data internally. CORBA is a protocol for storing information using an ORB
>(Object Request Broker) and CorbaMed is a subset of that. Of course, that's
>all fine and good unless you aren't using an ORB yourself, in which case
>someone would have to build a bridge for other systems, so it doesn't
>really fly as an interchange format. The GEHR is not an interchange format
I don't believe this statement about an ORB is quite accurate. One could
do everything described above an be compatible with CORBAmed if the
particular relevant interfaces are also implemented. You don't have to use
an ORB yourself, it could just be the gateway to other information. The
CORBAmed specification, itself,is rather silent on the data interchange
format but supports those provided by others (HL7, CEN, etc.). But it can
provide complete interoperability in the services if one implements the
interfaces.
>-- it's an idea for how to store medical data, and while it may be good for
>that, it has to rely on something else as an interchange format. (I'm going
>to skin CEN, as I am not familiar with it). Out of all of the items you
>listed, only HL7 has some viability as an interchange format, but it
>requires everyone to either write their own parser or use hl7lib (check out
>sourceforge for this one). I really don't know about all of HL7's
>capabilities or fields, but so long as no one goes the Microsoft
>"proprietary extensions" way on that protocol, it seems to be the way to
>go, otherwise we all get stuck with CorbaMed, which only works for the
>CORBA based projects.
CORBAmed specifications are being implemented in DCOM and could be in other
systems, too.
It is intended for interoperable services and relies on one being able to
"negotiate" through essentially a namespace as to the data representations.
> > Which of the above can give me that flexibility?
>
>HL7 is a good idea for an interchange format, but makes a lousy storage
>medium. Use whatever you think is the best for internal data storage, so
>long as you can map it to an interchange format like HL7. (That's why I
>think that in a way GEHR is a really good storage idea -- their mappings
>are excellent)
The GEHR model is fully compatible with the CORBAmed specification and
could be implemented within it quite nicely.
HL7 will be much more useful as an interchange format once it is fully in
XML. However, one needs
more than an interchange format for one to be able to link multiple
clinical systems together and access them simultaneously. I believe a
service-oriented architecture is the only thing which will support this
kind of functionality.
>
> > Shouldn't we settle this question right now or else go the way of the
> > current proprietary systems?
> >
> > Maybe we're not looking for the best (maybe it isn't there). But we need
> > something common to hold on.
>
>I've been saying this for a very long time as well, but no one ever seems
>to want to talk about it -- everyone would rather talk about why XXXX is
>the greatest thing since sliced bread, but not how we should be blowing off
>this proprietary model of "every man for himself" and forging ahead in the
>Open Source (tm) way ... by using our collective bargaining and brain power
>to bring a new standard.
I think we should forge ahead in the "open-source" way. This does not mean
we should ignore various international standards. We've tried to
demonstrate this by providing "open-source" implementations of CORBAmed
standards. I think others on this group are doing the same. I know of no
other way to provide true interoperability.
>We all have to compete with guys like WebMD, who frankly have much more
>money and man-power than any of the groups working on free projects. But I
>think we have a better way of doing things, and if we don't all kill each
>other or committee everything to death, we have a good chance of being able
>to change the world of electronic medicine.
Exactly. We make this point in a recent book chapter which has been
published. I'd be happy to provide a reference to it if anyone is interested.
Thanks,
Dave
>I'm coming down off the pulpit now.
>
>*************************
>jeff b
>system administrator
>university communications
>university of connecticut
>[EMAIL PROTECTED]
>
