Grahame Grieve wrote:
Hi Tom
The main difference architecturally is that there in openEHR there is a
reference model from which software and systems can be built.
This is not a difference; it's true of HL7 as well
I think people would have a hard time finding it - where is the
reference model from which you can build software? It's not the RIM as
we are told time and time again (I can pull a dozen quotes from all the
core RIM designers to say that the RIM is not a basis for software, only
generating other schemas - this has been practically religion for 10
years)... you could call the sum total of all the HMDs a "reference
model" I guess, since they are what software is based on, but that's
stretching the meaning of the term...anyway, it's a pretty clear
difference for all practical purposes.
In HL7, the data are instances of schemas that are
progressively refined from the RIM.
well, it doesn't have to be; and also, you could do this with archetypes
and/or templates, and it would have some use too.
I'm just saying how things work now, so that new people have some hope
of understanding. I doubt if it would have any use with archetypes /
templates though - the subtractive logic based on relational projections
just isn't a part of normal object modelling or openEHR.
In recent discussions with the
designers, they claim that the theory of DIMs, RMIMs etc is based on
"relational projections" on the RIM (i.e. that's the basis of attribute
"removal").
well, I can't speak for "the designers" (I'm spending some time with him
today on this subject ;-), but archetypes and HL7 models are the same thing.
I can interconvert between them. The only issues are syntactical differences
in things that are allowed in each language, and they are minor. Obvious
conclusion: they are the same thing.
That's a somewhat misleading statement. An archetype isn't a new model;
it's a statement about putting together pieces from an existing model.
An RMIM is a new model with respect to the model from which it was
derived - different classes, different attributes. That's the whole
point of the HL7 refinement method - to iteratively derive new schemas
from the RIM...you can't pick up an RMIM and say what configuration of
classes from another model you have, because you don't have classes from
another model, you have _modified_ classes from another model. I know
that some RIM people will then say that the classes aren't really
modified, the missing attributes are "projected out", which means the
new classes are indeed new classes - each one specifying a new
projection on a class in the preceding model. Which brings us to the
question of the quality of the original model (the RIM), as well as the
details of the refinement method as a way of specifying content models.
Some archetypes and RMIMs are trying to say the same thing however. Is
reliable machine conversion possible? The key point is that while
conversion between the formalisms of some part of an archetype and an
RMIM and vice versa may be possible, conversion between actual real
archetypes and real RMIMs is not the same thing, due to the reference
models involved. Conversions that might be considered:
a) existing openEHR or CEN archetypes -> RMIM "language" - based on the RIM?
b) existing RMIMs -> archetypes based on the RIM
c) existing RMIMs -> archetypes based on openEHR
a) might be possible, but seems hard, because the RIM lacks numerous
primitives present in the openEHR reference model; if it was achieved,
it would allow openEHR content to be communicated in an HL7v3 message
(although why incur all the pain of transformation at both ends, when
the information can just be sent in the normal way is beyond me -
sending it as an opaque payload would be easier and safer); b) may well
be doable, and I suspect is the transformation you have most likely
achieved already - this would allow archetyping tools to be used in
HL7, but still wouldn't provide a way for openEHR archetypes to be used
in HL7, due to the difference reference models; c) I cannot see being
possible because of the differences in reference models and also another
problem: it is hard to tell with RMIMs what was intended and what "had
to be done that way" due to the limited language available in the RIM.
Actually reverse-engineering the true intention of the modellers from an
RMIM in general will be hard, due to this effect, and it should not be
under-estimated. So c) is only likely to be doable my manual means, but
it certainly should be considered, because there is a goldmine of domain
thinking locked up in the RMIMs which needs to be shared by systems and
technologies outside of HL7v3 messages.
One of the things newcomers to this field have to do is have a very hard
look at the reference models involved, how they enable semantically rich
systems and how they provide business value; then they need to
understand the methodologies involved in actually building software, and
what the costs and benefits are.
- thomas beale
, but archetypes and HL7 models are the
