Comments inline below.
Thomas Beale writes:
> Gunther Schadow wrote:
>
> > Thomas Beale wrote:
> > > GEHR on its own is not an interchange format. The "modern" way to do
> > > interchange is using generic mechanisms like CORBA, rather than
> > > application level protocols like HL7. CORBA (for example) just
> > > serialises whatever structures it finds in memory into a bytestream,
> > > according to the rules for the language and the IDL definition for
> > > the classes involved. So there is no need to say anything about
> > > clinical concepts in the protocol - it's all in the object model
> > > (i.e. the class model, i.e. the software - it's all the same thing
> > > in OO). HL7 v 2.x has to define clinical concepts in the protocol,
> > > because it makes no other assumptions about systems. All one has to
> > > do is to build an HL7 interface and stick to the HL7 rules.
> >
> > Wait, wait, just a moment. You are suggesting that it would be
> > favorable to not have clinical concepts represented in the interface
>
> I was not talking about the interface but about the protocol here. And the
> CORBA protocol comes from the IDL which comes from the information model,
> so it is entirely derivative. There is no need to specify any clinical
> thing in terms of protocol. Well, unless you are starting with IDL as your
> main modelling formalism, but for many people it is jsut too weak for that
> (broken type system, no true generic classes, no assertions or
> contracts....).
IDL comes from more than the information model. There is in addition a
computational model. I don't know of anyone that starts with IDL as
your modeling formalism. Most use UML or some form of UML to do the
modeling. IDL then is derived from that. The model would be put into
the MOF (MetaObjectFacility) which can generate the UML and IDL i
fdesired.
>
> > to a system (a protocol is simply an interface). This goes straight
>
> Well, a protocol definition can be derived from an IDL, so that's a fair
> statement.
>
> > against my idea of good system design. Object oriented technology
> > allows us to construct system interfaces of ever higher abstractions,
> > ever more application (business) oriented and ever less computing-
> > technology oriented.
>
> I think we are probably jsut at cross-purposes here. GEHR just doesn't use
> IDL for anything except as a derivation of the information model And the
> information model we use has more semantics in it than just those relating
> to messaging.
>
>
> > data base schemas, etc. Now you are saying we should stop right
> > here and deal only with a somewhat intermediary logical schema
> > and not deal with clinical concepts? No. You are not really
> > suggesting it, since GEHR too talks about clinical observations, etc.
>
> It does, but there are two levels of clinical concepts in GEHR:
>
> a) general ones, such as "transaction" (unit of committing to an EHR);
> "headings" (navigational organisers); knowledge representation classes
> capable of representing observations (phenemona), subjective information,
> and prescriptive information; and low level data types (text, terms,
> quantities, multimedia etc). These concepts are in the GEHR concrete model.
> It is possible to express anything in these structures.
>
> b) specific clinical concepts, from clinical medicine practice, e.g. "blood
> pressure", "audiology results", "family history" and so on. There are 100s
> of thousands of these, and they are represented in GEHR via meta-models (we
> call them "archetypes"), expressed in XML. When converted to object form,
> they act as meta-models and templates for defininf valid concrete
> structures ((a) above).
>
> Separating the two means that a concrete model can be developed relatively
> quickly and standardised, while clinical archetypes can be develped over
> time, and will continue to drive software developed using the concrete
> model.
>
> > In the end, systems want to do clinical business, and communication
> > wants to exchange clinically relevant information. I don't say it's
> > easy, but wishing application level business logic away from
> > inter-system interfaces is not right.
>
> I'm not sure if you are saying that the meta-model approach is invalid, but
> I can say that it is used commonly in OO systems, including ones I have
> built, and it saves significant expenditure, since the systems are more
> configurable than "normal" systems.
>
> > Your points on HL7 version 2 are well taken, but I plead with you
> > to keep HL7 v2 out of the discussion. When we compare GEHR with
> > HL7 we ought to look at HL7 version 3 only. Whatever you may know
> > about HL7 v2 does not apply to HL7 v3. So, please do not even
> > mention HL7 v2 any more in this discussion (except if explicitly
> > labeled and explained why HL7 v2 is relevant.)
>
> Actually I didn't want to - I have known about HL7v3 for a long time, and
> have no problem with what you are doing (in fact I am quite impressed). But
> I am fairly sure that others on this group do not know the difference....I
> agree, only HL7v3 should be talked about here (apart from some discussion
> about legacy converters for v2 systems, perhaps).
>
> > > - because the protocol is defined in terms of its semantic content,
> > > there is always the problem of older software not understanding
> > > newer messages. This should not in principle happen with CORBA.
> >
> > This is stated too simply, misleading, and therefore wrong. First
> > of all CORBA is not equal to CORBA. (At some point we should start
>
> Do you mean to say CORBA =/= CORBAmed?
>
> > using terms and references to models and systems more distinctly.)
> > There is CORBA and CORBAmed. CORBA talks about interaction of
> > distributed objects. CORBAmed defines application models and
> > interfaces using the CORBA infrastructure. CORBA is good stuff.
> > CORBAmed defines information models that are designed mostly from
> > an information systems perspective rather than from a medical
> > information perspective. <SOAPBOX>That's the reason why CORBAmed
> > goes pretty fast, but I predict at some point they will get into
> > problems tying these many pieces together.</SOAPBOX>
>
> I agree. That's exactly why we use a much more powerful formalism (Eiffel)
> to express our model, and also use the two-level approach. We will just
> develop our IDLs from that.
>
And that is the procedure within CORBAmed (not Eiffel, but other object
formalisms such as UML).
> > So, if you talk about CORBA here, which do you mean, CORBA plain
> > or CORBAmed? It is not true that CORBAmed is free from "semantic
>
> I meant just CORBA actually. I have not even looked at the latest CORBAmed
> IDLs....
>
You can't get interoperability without getting more specific and
agreeing on some form of the IDL. That alone doesn't guarantee
interoperability but it is pretty hard to get interoperability without
it.
> > content" as you suggest to be a good idea here. CORBAmed has
> > specific semantic content (that sometimes, however, falls pretty short.)
> >
Most of the semantic content in CORBAmed specs comes from HL7/CEN and
other modeling efforts. CORBAmed isn't trying to be comprehensive but
rather an enabling technology to facilitate the use of models coming
from other domain standards bodies.
> > If you talk about CORBA plain, I agree that it is a great
> > architecture in which to make medical information systems
> > interoperate, but it requires one to add well-defined medical
> > semantics to CORBA or otherwise you just communicate "stuff"
> > that your systems do not really understand. Thus, the information
> > model that encompasses the whole of clinical information is
> > of paramount importance. That's what HL7 version 3 is doing.
>
> So is GEHR. It's just that GEHR treats CORBA as a means to an end, not as a
> primary formalism for expressing the complex semantics of an EHR. For
> example, our initial kernel component will be in Eiffel, with APIs wrapped
> appropriately to make it a CORBA (and also COM) component.
>
If GEHR is to interoperate with other systems, attention will have to be
paid to the IDL, otherwise it will have to create some other mechanism
to communicate. This, of course, could be done (and is done) with XML,
but it is difficult to express functional methods with XML. If the
objects have methods, one should be able to call them directly rather
than create a whole new set.
> > hyped technologies (like ASN.1, remember it?) all come along with
>
> GEHR used ASN.1 a long time ago, and that was very problematic....
>
> > great (bold) promises that are never fulfilled -- the technology
> > evangelists are like a locust plague: they fall over an application
> > domain field that is just about giving crops and eat everything to
> > the ground, suggesting to do it all over again, (from the ground
> > up so to speak :-) using their new technology. This costs
>
> I have had the same impression from a few CORBA evangelists. So, although
> the "mainstreamers" may take issue with us using Eiffel and treating CORBA
> just as distribution service, we see our focus as building a model of a
> quality EHR, including semantics for medico-legal requirements, education,
> as well as patient/carer interaction - not just transmitting objects.
>
Building the right model, and that is what is being attempted. We think
it is important to follow the RM-ODP model from ISO in doing so. It
clearly separates the Information Model from the Computational Model.
CORBAmed and work groups in the OMG believe it is a good idea to follow
this well worn path in software design.
> > so much effort, and leads nowhere. That's why I stick with HL7
> > v3 and that's why I refuse to shortcut our application layer
> > work to any currently hyped technology.
"and leads nowhere"????? I don't understand why the specification of
high level objects leads nowhere. I know of know other way to link
systems together. If you express functionality in a streaming format,
you are doing the same thing. CORBA is heavily used in industry in cases
where organizations want to have control of the interfaces. Having
common interfaces for interoperability doesn't reduce functionality but
rather reduces the building of redundant code, and allows disparate
systems to communicate.
> >
> > I consider GEHR to be on a fairly high application layer too,
> > defining clinically relevant EMR concepts. My only criticism
> > about GEHR is that they build everything on the concept of
> > Observation ... often used metaphorically, and sometimes called
> > MedicalItem or something. In one part of HL7 version 2 we made
> > this same mistake believeing that everything could just be
> > represented by an Observation structure (the infamous OBX
>
> This is a fair criticism, but GEHR has moved on from there. Now there is an
> epistemological basis for knowledge representation as mentioned above, i.e.
> there are "species of knowledge". So we have:
>
> - (pure) propositions (a priori knowledge in philo. terms); clinically: you
> mght want to state a target dosage for something, a target weight etc.
>
> - predicate propositions - knowledge about a subject (the patient, or
> sometimes a relative of the patient)
>
> then the following species of predicates:
>
> - observations, or phenomena (objective a posteriori knowledge in philo.
> terms); clinically: information from instruments or investigational
> procedures, e.g. taking BP
>
> - subjective information (subjective a posteriori; opinion; implicit
> error); clinically - information from patient (e.g. their family history -
> as they remember it; how they feel) or doctor (diagnoses)
>
> - instructions (prescriptive in philo.); clinically: prescriptions, orders,
> etc
>
> Combined with the ability to build different logical structures (single
> values, lists, time-series, tables, matrices, hierarchies), these KR
> classes eable us to represent anything we can think of in the clinical
> domain. But remember - they are effectively "programmed" by the archetypes.
>
This is very close to the capability of the new COAS (Clinical
Observation Access Service). The GEHR model was looked at very closely
in the design of COAS so that it could support it rather easily (as well
as other models). The idea is to let these various models flourish and
facilitate mechanisms for them to interoperate.
One can ignore the work of CORBAmed, but you will have to reproduce the
functionality some other way (such as putting the semantics of method
calls in a stream oriented protocol).
I hope this also clears things up.
Dave
> hope this clears a few things up....
>
> regards,
>
> - thomas beale
>
>
> ---------------------------------------------
> Deep Thought Informatics Pty Ltd
> Information and Knowledge Systems Engineering
>
> mailto:[EMAIL PROTECTED]
> http://www.gehr.org
> phone: +61 7 5439 9405
> ---------------------------------------------
>
>
>
--
David Forslund Voice:(505) 665-1907
Advanced Computing Laboratory FAX: (505) 665-4939
MS B287 EMAIL: [EMAIL PROTECTED]
Los Alamos National Laboratory WWW: http://www.acl.lanl.gov/~dwf
Los Alamos, NM 87545
