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....).
> 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.
> 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....
> content" as you suggest to be a good idea here. CORBAmed has
> specific semantic content (that sometimes, however, falls pretty short.)
>
> 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.
> 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.
> 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.
>
> 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.
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
---------------------------------------------
