David,
I can't seem to get into the various standards from your web page on
Telemed. When I click on COAS, for example, I get an access denied. Is
this temporary?
John
David Forslund wrote:
>
> 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]
> >
