RE: Interoperability with HL7
Dear All,
I think that the discussion should be guided by the following
assumptions:
* Society demands standardization organizations to develop
interoperability standards rather than reusability standards.
* Society demands that these standards are applicable now.
* Society does not demand perfect standards, but standards
sufficiently to allow the representation of clinical knowledge to the
care
continuum.
* This should not be a story of winners and losers, it's the wrong
approach.
Today our hospitals lack semantic interoperability, companies are
afraid of
being wrong about which option to choose, and doctors do not have all
the
information to make the best decisions about the health of their
patients.
Without this perspective all the work loses its meaning
As the Spanish proverb, "ni quito ni pongo rey pero sirvo a mi
señor".
Carlos Parra.
________________________________
De: openehr-technical-bounces@chime.ucl.ac.uk
[mailto:openehr-technical-bounces@chime.ucl.ac.uk] En nombre de Thomas
Beale
Enviado el: domingo, 07 de febrero de 2010 14:12
Para: openehr-technical@openehr.org
Asunto: Re: Interoperability with HL7
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
_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical