But.
-1-
The HL7 RIM is a reference model for any sentence.
The EHRcom reference model defines any document.
The former will be more difficult to implement generally by writing generic
software, because sentences can express very many nuances of trillions of things.
The latter is more easy to implement. The model for any generic document is only
a limited amount of classes and structural codes.
Perhaps the answer is that the reference models are not equivalent. The openEHR
reference model is equivalent to the HL7 DIMs. The fact that the HL7 DIM's are
based on a metamodel with a structural code pattern is both a strength and a
weakness when compared with the OpenEHR reference model, which is not based on
a seemantic metamodel, only on a technical metamodel (MOF). So we
should not compare reference models, we should compare the openEHR reference
model with the HL7 Domain Models
-2-
The HL7v3 method, using the RIM as template for further developments, produces
R-MIMs in a not-computable way.
they are computable, but not compatible with each other in a computible fashion.
Each R-MIM generates an unique xml-schema needing unique software.
well, I will keep saying this until everyone listens:
* R-MIM's need not be treated this way
* Archetypes can be treated this way.
Each approach has advantages. HL7 chose one, OpenEHR chose the other.
Full analysis suggests that HL7 should change on this issue, we are
considering this.
-3-
Using the Message paradigm, a community of healthcare providers, together with
the vendors, produce a series of XML-schema's for a clinical domain.
In the Archetype (or Two Level Model) paradigm only healthcare providers meet to
produce the archetypes/templates. All vendors have to implement one relatively
simple and stable XML-scheme based on the EHRcom reference model.
Implementing a reference model is more costly than implementing a few messages
with specific models. Implementing a lot of messages with specific models is
more costly than implementing a reference model. The structural code pattern
allows HL7 users to choose either approach, but this has not proved very
successful, partly because the nominated reference model is actually the
metamodel.
-4-
HL7v3 is based on the philosophy that only the common information model is used
in the exchange structure. It is system agnostic. It is not impacting the
proprietary components of the communicating systems.
EHRcom impacts one or more components is EHR-systems in order to be able to reap
the benefits of this standard. The full deployment of EHRcom needs a new layer
in EHR-systems. One layer that conditions the archetypes and accompanying data
such that it provides a uniform interface with the other EHR-SYSTEM components
like the persistence layer, the presentation layer and the business logic layer.
(This is why the CEN/tc251 HISA standard is important next to EN13606 EHRcom)
so this is why they have different scope. But the scopes very clearly have a
large overlap
-5-
EHRcom is an European standard (and will become an ISO standard as well)
European standards play a reserved role in the European Market.
Only European standards (or equivalent standards) can be used in legislation in
Europe and its Member States.
Several European Directives regulate this in the European Economic system.
In view of the first four topics mentioned above, I don't think HL7v3 messages
and EHRcom can be considered equivalent.
they are not the same. But the focus clearly overlaps.
In our game of 'EHR-chess' you will not be surprised to learn that my next move is:
*/CEN/tc251 EN13606 EHRcom (openEHR) deserves to be considered for worldwide
patient safe communication between EHR's and EHR-systems./*
It is a new exciting paradigm.
I could respond with: HL7 V3 is the primary contender for world wide
communication between all health systems, including EHR's.
But that's not what I'm here for, we cannot afford to compete and confront.
Instead, my move is about stepping in the direction towards this statement:
The HL7/CEN healthcare standard provides a solid base for everyone who
wishes to communicate and manage information in healthcare.
ok. my move:
If we work together (i.e. our different focuses overlap with common engineering
and semantics support, and we can use each others content models), this will be
a net benefit to everyone. For instance, I note that OpenEHR does not include
general business process / orchestration models, and you really need to
consider this before systems can usefully communicate. This is a core interest
of HL7. But OpenEHR/13606 have a focus of managing persisted information - everyone
has to do this, and HL7 is not good here. So, it's good to work together
for everyone's benefit. We can do this if we share:
* reference models
* constraint pattern expressions
* wire formats
So, we can move ahead in each of these areas:
* I have a data types ITS for HL7 V3 which is well cross-mapped to the OpenEHR
data types. The differences are mainly due to requirements differences, and
we can use this as a base to move to a single model that everyone shares.
I am starting to work on the reference model. (There is a joint working party
already working the reference model who have made significant progress, some
of the contributers to this are on this list)
* I can interconvert between R-MIM's and ADL diagrams. I have code for this.
To complete the work, some small changes are needed in ADL and HL7 constraint
methodology. I have been proposing changes here at Boca Raton for the HL7
methodology, and I have been discussing the changes required in ADL with Tom.
I believe that they make sense in their own right, not just justified by
harmonization.
And in Eclipse, we will be working on having a single editor for both
archetypes and HL7 models
* The HL7 wire format is being reexamined. For technical reasons, a wire format
that closely resembles the OpenEHR wire format is emerging as a front runner.
(i.e. a single schema at the domain level). This is not an established decision,
it's something that is still being worked on
So, in each of the 3 areas, fundamental progress is being made, and, while not
complete, progress is accelerating, and being taken seriously by everyone. I
look forward to advancing this even further in Geneva in a few weeks time.
Last point: the most important thing to understand is that both OpenEHR and
HL7 are *very closely* aligned in goals and methods. There is some engineering
differences. I wish that important clever people who should know better would
stop claiming these differences are significant, and start talking about how
these things are nearly the same after all. Then we can accept that both are
flawed, and have useful discussions about how to move forward together. (and
pigs will fly, I guess, in some cases)
Grahame