Mapping Archetypes to HL7 and vv [from Heath Frankel]

Implementers (archive)
1

[Something funny going on with the list server right now; this post is from Heath Frankel in response to Bert Verhees....]

Bert,
Sorry I have been meaning to respond for some time but have been considering
how to do so.

To be blunt, I would suggest that your approach should be reversed. When
working in the EHR messaging space I consider openEHR/CEN 13606 reference
models and archetypes as logical models rather than implementation models
and HL7 becomes the ITS. So what you are trying to do is take an
implementation model and derive from it the logical model. Even though
reverse-engineering is common practice I would suggest that the resulting
logical model will end up being tightly bound to the original technology.
An example of this would be if you attempted to include the Type and
TemplateId attributes of the REPC_MT000001NL.Performer2 CMET you provided as
example into an archetype. This would not be the way that this data would
be represented in openEHR. It would also be to the detriment of your work
and to openEHR if you generated a set of archetypes to be used in your
system or across the Netherlands that was not consistent with or draw from
the existing openEHR archetypes.

I do agree with Tom that we can re-engineer the good work from the
Netherlands Primary Care Model which is based on or at least been influenced
by the HL7 Care Provision domain, of which I have made a significant
contribution. But, I would suggest that the Primary Care Model is too
high-level to be used for extract archetypes. That is, the archetypes
produced from the model will not be specific enough to be useful. This is a
common mistake made when relating archetypes to HL7 models. Most HL7
influenced people want an archetype for high-level concepts such as a
Battery of which Blood Pressure is such an occurrence of a battery.
However, openEHR has archetype that represent these fine grained concepts of
blood pressure, HbA1c, Blood Glucose etc.

One exception to this think is in William Goossen's work where he defines
fine-grained "Care Structures" that are specified as constraints on the HL7
Clinical Statement pattern. It is these Care Structures that should be
represented as Archetypes not the Clinical Statement or some intermediate
constraint of the clinical statement such as a Battery.

Your original message did not indicate specifically which reference model
you are using to build these archetypes but from subsequent messages I
assume you are using openEHR. However, the HL7 CMET examples you gave below
are related to Parties and Entries. To represent these concepts you should
be using the openEHR Demographics model rather than the EHR model. Not much
work has been done as far as defining archetypes for Demographic parties but
it should be progressed with as much diligence and review as the Clinical
Archetypes.

In addition, these examples you give highlight the core of the issue why you
have so many classes you want to archetype. The concept of performer and
author is a concept of participation which is reflected specifically in the
openEHR EHR model and does not need to be archetyped although in some cases
such as performer you may choose to template this (e.g. requiring there to
be at least one participation representing the primary care provider).

The concept that does need to be archetyped is the Practitioner (the
AssignedEntity) that was the author or service performer. Again, the
openEHR EHR model represents these already but more as a reference to a
demographic object held outside the EHR, which you can archetype using the
openEHR Demographic model.

So in summary, you need to be very careful when you are trying to archetype
concepts represented in an implementation technology that does not follow
the same rules as openEHR and CEN 13606. I would suggest that you work more
in the logical space of developing archetypes, drawing from the requirements
that have been used to develop the implementation models of HL7. The
mapping tables that William has developed would be a good place to start.
You will more likely to have an archetype that will be usable to the more
general health informatics community without the implementation specific
influences of HL7. You can then specify mapping from the logical archetypes
to the HL7 implementations. This is the approach I have used when
performing this task in the HL7 V2 and other proprietary messaging formats.
This approach also allows you to map between different messaging formats by
converting to/from the common logical models using the known mapping rules
for each message format.

The alternative to this pure openEHR archetype approach is using Legacy
Archetype as an intermediate form. Legacy archetypes is a new concept in
openEHR release 1 and is intended to be used by openEHR to support CEN
13606. It could also be used for HL7 V2 and CDA/V3. The idea is to develop
archetypes that use the openEHR archetyping approach but the structures more
reflect the source content (i.e. a HL7 V3 RMIM/CMET such as Clinical
Statement or a Battery) to ensure that all the source data can be
represented in the archetype. This could then be stored in an openEHR
archetype aware repository as a close structured representation of the
source data. However, this archetyped data would not have the semantic
integrity as data represented using pure openEHR archetypes so an additional
transformation could be performed to represent the source data as pure
openEHR content. If all you want is to have a flexible storage mechanism
that supports changed schemas then the legacy archetype content is probably
sufficient. If you want to perform semantic data processing and be
interoperable with openEHR systems you will need to transform the legacy
archetype content to pure openEHR archetype content.

Hope this helps.

Regards
Heath
Heath Frankel
Senior Interoperability Consultant
Ocean Informatics
mobile: 0412 030 741 email: heath.frankel@oceaninformatics.biz

2

Hi all,

I have a kind of class diagram created on base of the XSD-files which describe the Primary Care DMIM, according to Nictiz, were I downloaded the XSD-files.

I started with one, the XSD for Primary Care, and filled up the complete Christmas Tree.

I did that because the documentation of Nictiz is very, very incomplete, there is no way to build an application when having nothing than the officially published information.
So I had the XSD's as officially published information, but as you may know, they are not readable, so I analyzed them using XML-tools, and created the diagram
it is nowhere mentioned this to be a beta version, or something like that, so I guess, untill stated otherwise, this must be regarded as the DMIM describing medical information-exchange in the Netherlands.

See for yourself, and do not hesitate to express your opinion.

But maybe I did something really stupid, please tell me, I can handle it.

I will respond to the previous email later.

Go to http://www.rosa.nl/HL7/

thanks
Bert Verhees

3

Thanks Heath, for you very extensive answer. I will respond in between. I must
say, I approach the case from a practical point of view. I need to build a
datastore in really a short time.

I have heard in the industry that there are massive problems with storing
messages based in Prica in a relational database.
Oracle's XML engine failed to create a table/database structure build on the
XML-definitions. The only thing that seems to be trusted for the industry is
to model those 1000 Prica classes (including HL7 datatypes) manually.

There are possibilities to work with XQuery, I have heard about, but there is
not much experience with that. How does it perform, how does it behave in a
multitasking service environment?

But anyway, we don't need to discuss HL7-implementation problems here, I just
mention them because it is part of my reasoning.

There are several reasons to choose for an architecture like I have a mind.
But basically they boil down to a few things, I mentioned before.

- I need to communicatie on HL7 Prica level
- I need to have an model and I am not a domain expert or modellist, so I take
the good work from Nictiz
- The archetypes based on CMETs from Prica can be extended for our own need.
We cannot communicatie those extensions, or very hard, but that is not really
an issue. For communications, the Nictiz Prica definitions are regarded as
sufficient
- We can, except from CMET-archetypes and extended CMET archetypes, also use
openEhr archetypes, and evend efine our own small purposes archetypes which
contain things like taste of music, or taste of wine. :wink:

But some things are in the future, I can be mistaken, but OpenEHR cannot be
more perfect for us.

Maybe I misunderstand things, do not hesitate to tell me.

To be blunt, I would suggest that your approach should be reversed. When
working in the EHR messaging space I consider openEHR/CEN 13606 reference
models and archetypes as logical models rather than implementation models
and HL7 becomes the ITS. So what you are trying to do is take an

This is because I need a good working and a compleet model, and HL7 Prica
seems to be able to contain the thins we store in Dutch Primary Care.

Maybe there are omissions, If someone knows, I like to hear about them.

and HL7 becomes the ITS. So what you are trying to do is take an
implementation model and derive from it the logical model. Even though
reverse-engineering is common practice I would suggest that the resulting
logical model will end up being tightly bound to the original technology.
An example of this would be if you attempted to include the Type and
TemplateId attributes of the REPC_MT000001NL.Performer2 CMET you provided
as example into an archetype. This would not be the way that this data
would be represented in openEHR. It would also be to the detriment of your
work and to openEHR if you generated a set of archetypes to be used in your
system or across the Netherlands that was not consistent with or draw from
the existing openEHR archetypes.

The fields TypeID and TemplateID are optional (most of the time), they are not
used in the example HL7 messages I have seen from Nictiz. Maye they will be
used in the future, then I must find documentation what they are about. If
you know a quick hint, I have access to HL7 website, I would be thankful.

As you may know (I don't know if you can read Dutch, the Nictiz documentation
is far from complete, but the XSD's are)

I do agree with Tom that we can re-engineer the good work from the
Netherlands Primary Care Model which is based on or at least been
influenced by the HL7 Care Provision domain, of which I have made a
significant contribution. But, I would suggest that the Primary Care Model
is too high-level to be used for extract archetypes. That is, the
archetypes produced from the model will not be specific enough to be
useful. This is a common mistake made when relating archetypes to HL7
models. Most HL7 influenced people want an archetype for high-level
concepts such as a Battery of which Blood Pressure is such an occurrence of
a battery. However, openEHR has archetype that represent these fine grained
concepts of blood pressure, HbA1c, Blood Glucose etc.

That is why I suggest to create new archetypes, especially for this
functionality, and even it might be possible to generate archetypes from
HL7-XSD's, or do that partially.
We can extend these archetypes, as long as they keep the HL7 base in tact,
which might be an inconvenience, but possible to overcome

One exception to this think is in William Goossen's work where he defines
fine-grained "Care Structures" that are specified as constraints on the HL7
Clinical Statement pattern. It is these Care Structures that should be
represented as Archetypes not the Clinical Statement or some intermediate
constraint of the clinical statement such as a Battery.

Your original message did not indicate specifically which reference model
you are using to build these archetypes but from subsequent messages I
assume you are using openEHR. However, the HL7 CMET examples you gave
below are related to Parties and Entries. To represent these concepts you
should be using the openEHR Demographics model rather than the EHR model.
Not much work has been done as far as defining archetypes for Demographic
parties but it should be progressed with as much diligence and review as
the Clinical Archetypes.

I think, it must be clear by now, that I need to find a way to create
archetypes.

In addition, these examples you give highlight the core of the issue why
you have so many classes you want to archetype. The concept of performer
and author is a concept of participation which is reflected specifically in
the openEHR EHR model and does not need to be archetyped although in some
cases such as performer you may choose to template this (e.g. requiring
there to be at least one participation representing the primary care
provider).

I learned to live by the idea to have to generate that many archetypes. That
is why I am looking at possibilities of generating them. It is because we
need a working prototype by begin October. But I work best when under
time-pressure. Maybe I do not hae all the funny details ready. There are some
of them in Prica of which I don't understand how they get there

f.e.

The CMET Subject is used a lot, in it is patient, and that is a person, and
that person has a contactparty.....

In COCT_MT030200NL.Person is a property scopedContactparty of type
COCT_MT030200NL.Contactparty which has a property of type
COCT_MT_030200.Person
In COCT_MT_030200.Person is a property citizen of type COCT_MT030200.Citizin
which has as property politicalOrganization of type
COCT_MT150000.Organization

As I said, we don't need to discuss HL7, but I do not need to store everything
that has arrived implicitly in the Prica-model.

The concept that does need to be archetyped is the Practitioner (the
AssignedEntity) that was the author or service performer. Again, the
openEHR EHR model represents these already but more as a reference to a
demographic object held outside the EHR, which you can archetype using the
openEHR Demographic model.

It is also a possible to look at the stucture of Prica, it breaks down in to
parts, one part has demographic properties, these is the biggest part of the
Prica. If you take a look at the diagram I put on the Internet,
www.rosa.nl/HL7. Excuse me if it is a bit of a mess.

But, the inner-objects, white of colour, are demographic objects. As you close
your eyes a bit, you'll see that most of the objects are pointing to these
Demograpich objects, one could make the Prica model more efficient, because,
(e.g.) it makes practically for a data-modeller no difference if someone is
author or performer, because both are AssignedEntity. The difference is only
for the domain-modeller, which occurs to be a completely different
proffession.

But when choosing this path to go, there can be no autogenerating of
archetypes.

So in summary, you need to be very careful when you are trying to archetype
concepts represented in an implementation technology that does not follow
the same rules as openEHR and CEN 13606. I would suggest that you work
more in the logical space of developing archetypes, drawing from the
requirements that have been used to develop the implementation models of
HL7. The mapping tables that William has developed would be a good place
to start. You will more likely to have an archetype that will be usable to

I don;t know what you mean by this. I found mapping tables from MEDEUR to
Prica. Medeur is a Dutch edifact message. I worked a lot with that, and it
helped me to understand the Prica model.
I found them on a website of the Uniersity of Maastricht, which was also
involved with working for Nictiz.

But maybe you are talking about other mapping-tables. Please tell me where to
find them.

the more general health informatics community without the implementation
specific influences of HL7. You can then specify mapping from the logical
archetypes to the HL7 implementations. This is the approach I have used
when performing this task in the HL7 V2 and other proprietary messaging
formats. This approach also allows you to map between different messaging
formats by converting to/from the common logical models using the known
mapping rules for each message format.

The alternative to this pure openEHR archetype approach is using Legacy
Archetype as an intermediate form. Legacy archetypes is a new concept in
openEHR release 1 and is intended to be used by openEHR to support CEN
13606. It could also be used for HL7 V2 and CDA/V3. The idea is to
develop archetypes that use the openEHR archetyping approach but the
structures more reflect the source content (i.e. a HL7 V3 RMIM/CMET such as
Clinical Statement or a Battery) to ensure that all the source data can be
represented in the archetype. This could then be stored in an openEHR
archetype aware repository as a close structured representation of th

Can you please point me to some more information about this

source data. However, this archetyped data would not have the semantic
integrity as data represented using pure openEHR archetypes so an
additional transformation could be performed to represent the source data
as pure openEHR content. If all you want is to have a flexible storage
mechanism that supports changed schemas then the legacy archetype content
is probably sufficient. If you want to perform semantic data processing
and be interoperable with openEHR systems you will need to transform the
legacy archetype content to pure openEHR archetype content.

Hope this helps.

I hope so, too, it helps me thinking

Thanks again
Bert Verhees

4

As an ousider who has been following this groups discussions perhaps your should look at solutions provided by vendors like IPEDO…
http://www.ipedo.com. There are open source varations like BEA’s Beehive http://beehive.apache.org/ etc.

Regards.

Nitin Uchil

5

Nitin Uchil schreef:

As an ousider who has been following this groups discussions perhaps your should look at solutions provided by vendors like IPEDO....
http://www.ipedo.com. There are open source varations like BEA's Beehive http://beehive.apache.org/ etc.

Thanks, but my purpose is not to create a HL7 datastore, this is only a part of my purpose.

regards
Bert Verhees