Hi Andrew,
this description of 'semantic' attributes is quite useful. People should
indeed realise that the named attributes in various health reference
models are often semantic concepts that just happen to be defined in the
information model, not a terminology. The same occurs at the class
level. The point of doing this is that such models commit to some level
of meaning-of-structure rather than being completely agnostic. In terms
of your explanation, a few points:
* all models (openEHR, ISO13606, CDA usage of RIM) provide a
structural container concept, which can be understood as a
'document' or 'recording'. Classes for this purpose include
COMPOSITION (= CDA Document) and SECTION, and also many classes
and attributes for defining audit & context attributes. openEHR &
13606 have a similar model for this.
* the openEHR reference model uses 'semantic classes', e.g.
OBSERVATION, EVALUATION, INSTRUCTION, 'semantic attributes' e.g.
'CARE_ENTRY.protocol', as well as generic compositional attributes
like CLUSTER.items. Some of these classes, like HISTORY and EVENT
are for extremely generic concepts in science/mathematics.
* the HL7 RIM uses 'semantic classes', e.g. Observation, 'semantic
attributes', e.g. 'activityTime', special attributes like
'contextControlCode', 'contextConductionInd', generic
compositional attributes like ActRelationship.source and target.
There are some data structure classes within the HL7v3 data types,
like HXIT (a generic history concept) as well as hardwired classes
like Person name, address etc.
* ISO 13606 uses no 'semantic' classes at the domain level -
everything is just an Entry, but it does include a couple of
'semantic attributes' in the wrong place (a specific attribute
should never be on a generic class) - ITEM.obs_time, ENTRY.act_status.
All three approaches use some special 'programmable attributes' which
are given values at archetype design time, or at runtime to provide the
actual meaning of the instance:
* openEHR: there is just one such attribute, LOCATABLE.
archetype_node_id, which marks any object with the concept code
from an archetype (thereby for example making an ELEMENT instance
into a systolic blood pressure measurement)
* HL7 attributes like Act.code, moodCode, classCode, levelCode etc
* ISO13606 has a few attributes for this purpose:
RECORD_COMPONENT.archetype_id, ITEM.item_category,
CLUSTER.structure_type.
Another key difference that contributes to the difficulty of mapping &
harmonisation: HL7v3 uses a pervasive 'restriction' approach in all its
modelling, which means that all RIM classes contain numerous attributes
(in theory sufficient to cover every possible situation in the universe
of healthcare), and these have to be constrained out to come up with
classes that mean something for any given concrete situation - the high
level classes like Act and ActRelationship don't have any meaning as
such. On the other hand, openEHR and 13606 take a standard object
approach to the information model, and have only very general attributes
defined on general classes; more specific descendants then add relevant
attributes. To give an analogy: in the HL7 approach, if you had a model
of 'animals', the top class Animal would contain every kind of defining
characteristic of particular animals, such as 'wing', 'claw', 'fin',
'spine', 'horn' etc, and the class Bird would be created by the removal
of 'fin', 'horn' etc.
These differences not just in modelling but in modelling paradigm are
what make harmonisation difficult.
My question is: why do we want harmonisation? What we need is a clean
clear information model for the health information domain, carrying
sufficient semantics to be useful, while being 'prgrammable' in some
way. Trying to 'harmonise' 3 different models & theories of modelling
won't achieve that, it will simply create a frankenstein.
Do we need convertability? If we have a world in which all 3 of these
models exist, then there is no avoiding it. The only question is whether
it can be achieved in a generalised manner - e.g. a converter than can
take any CDA and generate the equivalent 13606 Extrtact - or a custom ad
hoc manner - i.e. every CDA => 13606 conversion requires its own
converter, or, something in between.
We should also be interested in the qualities of the models themselves.
Many government programmes are paralysed trying to work out which one to
use. In a different world, the problem could have been solved by an
information model so generic as to be a 'node/arc' construct; this would
be like having to build a car from individual atoms of iron rather than
nuts, bolts and sheet metal. ISO 13606 has stayed more generic, based on
the idea that it is a lowest common demominator model of interchange,
that can't impose a view of semantics on originating systems. HL7 (both
message and CDA forms) is intended to be a model of message & document
interchange, and is quite generic in the sense that you have to make
everything you want out of Act/ActRelationship nodes (essentially a
node/arc idea). openEHR on the other hand models some of the basic
structures found in science and computing, to help the definition of
models.
Hence in openEHR there is quite a good model of time-based data, in the
HISTORY & EVENT classes. These classes allow the easy definition of
structures via archetypes for:
* any time series of instantaneous measurements, like vital signs
* inclusion of 'interval' events, representing e.g. 4h average, max, etc
Another inclusion in the model is OBSERVATION.state (also in EVENT),
where the state of the subject of recording can be recorded. This
enables a very clean representation of the history of events in an oral
glucose tolerance test, where not only is there timing involved, but
also the state of the patient at each point is key information (post
fast, 1 minute post 75g glucose challenge, 1hr post 75g glucose
challenge etc).
As mentioned above, there are various kinds of specific attribute in
HL7, including in Act descendant classes.
The key question here is: how easy is it to create
technology-independent models of content, based on these models? In
other words, can I create a model of the many medical concepts found in
clinical information in some framework based on an information model -
and can I reuse that one definition for a) messages, b) screen display
c) screen capture d) reporting, etc.
This is what archetypes offer: a method of single-source semantic
modelling. Now the choice of information model becomes critical. If the
information model is just node/arc, we get no help, and we have to
soft-model different ontological categories like Observation and
Instruction over and over again, and build every simple common structure
like 'history of events with state' from scratch every time. If it
provides some of this help, then the clinical models of content don't
have to re-invent such things, and life is easier. If it doesn't
modellers will model all of these things differently every time, and
greatly reduce the chances of the information being interoperable. One
of the other key values of archetypes is that they support a coherent
and portable query methodology, called Archetype Query Language - based
on archetype paths. This provides a lot of power over using and reusing
health data.
In summary, openEHR has opted to provide some ontological and structure
concepts in its information model that are common across healthcare,
rather than force its archetypes to have to re-invent everything each
time - in other words to standardise common structure concepts that
otherwise get reinvented in incompatible ways. This is the reason that
there are some hundreds of archetypes in the CKM right now, and the NHS
was able to fairly quickly build over 1000 archetypes in 2007. It has
proven much harder to do the equivalent thing with HL7 v3. There are
RMIMs, but these contain a lot of messaging attributes and it is hard to
see how to reuse them in non-message situations. One can create CDA
templates, but as they rely on HL7 RIM constructs at level 3, you still
get hit by the difficult RIM semantics, and lack of common structure
classes.
So, here is an existential question: what it the so-called Detailed
Clinical Models activity trying to do in fact? Use a node/arc model and
create its own domain models for everything (including having to
replicate History-of-events everytime)? It could do this easily enough:
just choose a model with some document/section container semantics, and
a simple Cluster/Element internal structure, and then use archetyping.
In the history of openEHR we were doing this in about 2002. What we
found was that being too simple came with a huge cost - limited clarity,
and unnecessary replication of typical structures. Over a period of some
years, we improved the openEHR RM to include things that domain
modellers should not have to keep re-inventing. The openEHR RM is the
only model I know of that has been actively re-engineered over time to
directly absorb requirements from domain modellers using it. I would
suggest that DCM thinks very carefully about what its goal is, and how
many years it wants to take to get there. openEHR already offers a very
solid basis for doing much of what DCM could be aiming for, and could
greatly reduce the time taken to make progress.
- thomas beale
On 07/02/2010 01:04, Andrew McIntyre wrote:
> Hello Charlie,
>
>
> The biggest issues with inter-operability relate to the use of
> Semantic attributes in both HL7 and openEHR.
>
> They are not really semantic in the SNOMED-CT sense in either format,
> and because they are different, inter-operability between openEHR and
> HL7 is difficult. OpenEHR has attributes such as "data", "state" etc
> and HL7 has Act Relationships that are supposed to be semantic rather
> than just compositional. OpenEHR also has a lot of specific CLUSTERS
> such as ITEM_TREE and subclasses of ENTRY such as "EVALUATION" which
> have semantics that are in the implicit in the model, rather than pure
> clinical knowledge.
>
> This makes a DCM (Detailed Clinical Models) format that both agree on
> a difficult proposition. There are other differences, such as the
> ability of HL7 Observations to have both a value and child acts via
> Act Relationships, where as openEHR does not have CLUSTERS with values.
>
> The best way to resolve these is to accept that openEHR and HL7 cannot
> use the same models without adding extra information to the format ie
> extending ADL or adding attributes to the RMIM.
>
> If the clinical knowledge was modelled in ISO-13606 there are only
> compositional attributes ie "items" and only one of them and the data
> structures defined require the terminology to impart the meaning and
> not semantic attributes. This could be translated into openEHR and HL7
> in a loss less way. There are obviously some issues with the 13606
> reference model, but the pure clinical content is then representable
> with a tree of Name=Value pairs, with the meaning in the terminology
> rather than the attribute names. It is also an international standard
> that gives a degree of certainty and stability to the format, even if
> its not a perfect fit for every system.
>
> I think in most cases the demographic content is able to be mapped, as
> people have a lot of practice at that. A bigger issue is things like
> Medication, which has specific classes in HL7 V2 and 3. However the
> ability to model clinical knowledge outside the contentious areas and
> represent the clinical knowledge in a standards based format that can
> be adapted to other formats would be a huge leap forward. It is even
> possible to represent this in a loss less way in HL7 v2. For things
> like Medication and Allergies an archetype that can be mapped to HL7
> V2 and V3 Segments/classes is needed for interoperability.
>
> The use of Semantic or "named" attributes specific to a format is the
> major barrier to a common DCM format. The HL7 V3 assessments and
> scales RMIM is and example of a HL7 V3 format that is adaptable to an
> archetype, although it does have a cluster with a value, which would
> have to be mapped to the "value" ELEMENT of an archetype.
>
>
> The formula for calculated values is also undefined, but GELLO, which
> is a standard could be used for this and this is what we use with
> ISO-13606 archetypes.
>
> I cannot see how openEHR archetypes can be used for a general DCM
> format, but ISO Archetypes could, as long as they were modelled in a
> fashion that is neutral to final implementation format.
>
> A common format would require both sides to either map the generic
> structures into their own specific classes or adopt a more generic
> model with the semantics in the terminology. The overlap between the
> information model and the terminology model is probably at the heart
> of the conflict.
>
> Andrew McIntyre
> *
> *
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100207/94d7745a/attachment.html>
