Gunther Schadow wrote:
> Thomas,
>
> after reading your last message, I think GEHR and HL7v3 is very much on
> the same side. In fact, we already converged: GEHR came to include more
> specificity and HL7v3 has recently gone towards more generality. So,
> we now agree on the three level approach towards clinical information:
>
> (1) One concrete data structure
>
> information model, mostly graphically rendered in BON or UML.
>
> (Actually, if your BON-bubbles would show the attributes, and if
> the association lines were not so ugly double-fat, I would have
> no problem with using BON instead of UML. But not seeing the
> attributes is a real problem.)
We will (be forced) to go UML (more hype....) since everyone can read it.
The reason we used BON is because it is 1:1 seamless with Eiffel, and it has
a formal grammar, which no other graphical modelling standard is (AFAIK).
UML isn't that nice either, but I agree that one wants to see the main
attributes on the diagrams.
> (2) Thousands of what both GEHR and HL7 call "templates" defining
> clinical collections of information.
We call these archetypes to be more general, since some of them will act as
templates (you could just copy a BP template for example and fill in
systolic and diastolic) but others express rules (e.g. a simple set of rules
for Weed's SOAP structure of headings in a transaction might be:
first level heading = <any text; meaning problem>;
second level heading = <<"Subjective", mandatory>, <"Objective", mandatory>,
..., extras allowed>
and so on. This is not the GEHR formalism for this (I just made it up now to
illustrate the idea). But you can see that it is not quite a template.
> (3) A knowledge base (also called "master files," or "data
> dictionary") that define the observations, normal ranges,
> dosage instructuions, defaults, and those templates.
We think of this as the archetype database. It is likely to be influenced by
LOINC and the other termsets, as well as other research specifically for
GEHR.
What does HL7's knowledge base add to the templates? Is it mainly a way of
organising them, or does it add some data? It appears to add reference
information. Is this correct? If so, this is an area where GEHR needs more
work.
> Both GEHR and HL7 v3 have these three layers. I have not seen
> how GEHR maintains the knowledge layer and how GEHR maintains
> template definition. (I'm going to dis-regard the mentioning of
> XML DTD's in GEHR as a to-be revised mistake... this marketing
> hype makes all of us weak, I know. :-)
We will use XML-schema. The reason for doing this is that the archetypes
want to be editable with some fairly normal (XML-capable) editor (of the
future?). The could just as well be SGML, or some binary format that we made
up. But it seems reasonable to use XML-schema for this. Note: the internal
representation in GEHR will be objects, not XML text. XML just allows people
to edit independently of the EHR system.
What are your criticisms of XML in this context (apart from the fact that
no-one ever knows what the current definition is....)?
> In HL7 we have traditionally spoken of "master files" and still
> do so. But my vision has been to remove "master" tables from
> the model and merge them into the instance tables ... in your
> words, my belief is that a priori predicates and a posteriori
> predicates do have the same structure and that the semantic
> difference can be factored into a single code, which we call the
> mood code.
All our knowledge representation classes have the same structure (a header
object and a hierarchical substructure); the difference is the context
attributes which are stored with them, vis:
PROP_CONTENT:
- author: HCP (HCP = health care professional_
- date_time:DATE_TIME
PRED_CONTENT: (inherits from PROP_CONTENT)
- subject:PATIENT (or maybe just PERSON ...)
PHEN_CONTENT (inherits from PRED_CONTENT)
- location: HCF (HCF = health care facility)
- protocol: PROP_CONTENT (can be as complex as you like; archetype
driven)
SUBJ_CONTENT (inherits from PRED_CONTENT)
- provider: PERSON (i.e. the person giving the info)
- certainty: REAL (% certainty of correctness of info, in HCP's opinion)
INST_CONTENT (inherits from PRED_CONTENT)
- start_condition:CONDITION (a triplet of <datum, relational_op,
datum>
- execution_condition:CONDITION (<operator, <datum, rel_op, datum>>,
e.g. <"while", <"pain", =, "persists">>)
- status:INST_STATUS (e.g. pending, executing, overdue etc)
- maybe others in future
(Compress the inheritance to see what context attributes each one really
has.)
> Furthermore, I don't believe that subjective and objective
> a-posteriori predicates are structurally any different, in
> fact I even don't see the semantic difference, since there
> is nothing that reliably distinguished subjective from objective
> observations. Only circumstances (like who reported?, who
> witnessed?) that may make the distinction. Just try to label
Exactly. The difference in recorded context attributes is not great, but the
clinical semantics are quite different, I'm sure you'll agree - so for
example, an application might want to be able to easily see what was
recorded as subjective and objective, and display them/manipluate them in
different ways.
> these as subj. vs. obj.: "HEART MURMURS", "PALPITATION",
> "PULSUS CELER ET ALTUS", "SCHIZOPHRENIA", "HALLUCINATIONS".
> What are your criteria?
I'm not really the proper person to answer that (I am not a clinician; I
work closely with clinicians however); but I can say that GEHR's idea here
is that anything that is recorded in the context of making observations,
i.e. where there is a protocol followed, and there is no element of opinion
by the clinician, we would call that observation. E.g., taking a BP,
measuring height, locating a painful area.
Anything recorded as an opinion of either the patient, another person or of
the clinician, e.g. subjective findings during contact (patient), diagnosis,
differental diagnosis etc (clinician) is recorded as subjective.
Something like SCHIZOPHRENIA is likely to occur in a diagnosis or
differential diagnosis - it is a conclusion reached by the clinician based
on a protocol which has been followed to determine the mental state of the
patient; it is subjective. HALLUCINATIONS is likely to be something reported
by the patient; again subjective.
But: it is important to note that we are not assigning any kind of
subjectiveness or objectiveness to the terms; it is the terms which occur
within subjective or objective information structures. There is no a priori
reason why the term SCHIZOPHRENIA could not appear in an observation
structure (what we call phenomenological), it's just not very likely (as far
as I can see), since it is not a phenomenon which can be measured as such.
> So, in HL7 v3 we do not make these distinctions in the
> concrete information model. Instead we represent all this
> attribution information with the medical record item, which
> we call Service. We believe that the professional action
> (Service) is in the center of the medical record. We believe
Hm. I wonder if this is not equivalent (somewhat) to the types of GEHR's
transactions, e.g. "contact", "admin", "summary", "report" and so on....
> that observations are just a specialization of actions (and
> hence I renounce CORBAmed's COAS, if only for it's name.)
> We also believe that the notion of Service Action is more
> powerful to standardize meaning than the concept of "Record
> Item". Everything can be an "item" but not everything should
> be a distinguished Service in HL7 ... at least what this
This I need to read in more detail! Can you give me a current reference?
> Item/Service thing generally does should be clear without
> digging in a semantic network of 100000 entries.
What are examples of "service" in your model?
> My favorite example for a non-observation and more-than-an-
> item is our Medication class with it's attributes. These
> allow you to express/share medical prescription data have in
> a stricly defined way, rather than having to make up bogus
> codes (or "headings") we use static attributes where we can.
> Table-drivenness is not a benefit in itself, we use it only
> if we have to. We have to for many things, but when it comes
> to largely quantitative phenomena, we may be able to do better.
Hm. In our model, prescriptions are INST_CONTENT; that is to say they can
take the form of a hierarchy of information (exact shape driven by an
archetype, e.g. "uk-nhs-std-prescription"). All the content level classes
allow for an open hierarchy of information.
> Some questions: is the home of GEHR Australia now and are you
GEHR includes collaborators/contributors from at least 6 European countries
(UK, portugal, belgium to name some) as well as the Ocean group here in
Australia. In the UK, a project at UCL called SYNEX is GEHR-ish and CEN-ish,
and has an implementation. There are also other implementations of various
versions of GEHR, e.g. Health.one.
A GEHR foundation is being set up right now to enable people to collaborate.
When I speak as if the model we are using is GEHR, I am being slightly
presumptious: our model is in fact the purest modern version of the GEHR
model published in Deliverable 19 of the project in early 1995, but it is
not the only one. There are other models, but we think ours is more advanced
in terms of semantics. "GEHR" is united around requirements, and certain
modelling ideas (e.g. transactions), but is in a period of convergence
itself.
> the chief modeler? Who else is in the GEHR group? What are
> your relationships to Europe and CEN's EHCRA (honestly, no
we keep track of CEN's model, and liase with CEN WG members from the UK to
know what is going on. CEN's model is a bit of a mess, although it has some
reasonable ideas. But it is obsessed with the "item" idea, and does not look
particularly implementable either. But on the other hand, they have done a
lot of thinking, and there are good ideas to be pulled from the documents.
> fluff please)? Why has GEHR and EHCRA, who are so similar,
> been developed in two separate branches?
One is consensus decision-making, one has been focussed modelling. I leave
you to guess which is which!
> If you track HL7 v3 work, would you be interested in sharing
> and getting into further collaboration to converge? Can you
> come to HL7 meetings? HL7 Australia (contact Klaus Veil or
> Dawid Rowed) may assist you in this effort.
David Rowed is in Ocean, and yes we are interested in convergence. I have
not come to HL7 simply due to time/resources. But all of our stuff is
published on www.gehr.org these days, so please feel free to read and
review. Our work is now funded, so perhaps, time permitting I can get to
some HL7 meetings. But I need to review the matieral more thoroughly first.
> How married are you to Eiffel? It seems like a lot. I don't
well, I'm a professional software engineer, and it is concerns of
engineering quality systems that lead me to use Eiffel. I have used it in
real systems, and know the benefits. As a modelling and development language
and environment, it is far superior to the rest, so for the complex part of
a system or model, it is ideal. If you want to know more, see a talk I gave
at TOOLS EE99 at www.elj.com/eiffel/ebs.
> see Eiffel to become mainstream, even though it certainly is
What is mainstream? Eiffel has 4 vendors, a GNU compiler, and a huge
community of users. And in GEHR, we are interested in quality, not fashion
(as I am sure you can appreciate....)
> better than Java, it may be a path that leads into isolation.
As far as interoperability goes, an Eiffel component or server can be
wrapped as a COM or CORBA component (tools exist to do this). For those
interested, have a look at http://eiffel.com.
There is no problem with people writing applications in Java, VB or
assembler, for all I care. We will make the component available through COM
or CORBA, or a C/C++ or Java interface as required.
> How well is GEHR portable onto other things than Eiffel, ...
> I know, you can always map, but impedance mismatch may render
> a good model difficult in another environment.
Agreed; one of the reasons to use Eiffel when modelling is to be able to
state everything we want, without being caught by the limitations of the
formalism. The model is thus a faithful formal expression of the
requirements. With a weak formalism, we would always have to compromise.
Eiffel also has direct support for design by contract (pre, post
conditions, class invariants). Its latest version supports new concepts like
TUPLEs, ROUTINEs as objects (called agents), and multi-threading (been there
for a couple of years now), so it is much more advanced than Java.
> Finally for now: what happened to the Units of measure
> between GEHR 1.0 and GEHR 2.2? Is it gone? Why? Are you
> interested in a replacement?
The model does have units in it, but does not need a full domain model of
units, unit systems etc. But it is quite likely that we need more work in
this area, and since HL7 has eons of experience here, we want to review your
work before wasting a lot of our time.
For people wanting to keep track of GEHR, there are various groups at
eGroups including gehr-announce and gehr-discuss. You can subscribe at
egroups.com.
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
---------------------------------------------
