# Mapping Archetypes to HL7 and vv \[from Heath Frankel\]

**URL:** <https://discourse.openehr.org/t/mapping-archetypes-to-hl7-and-vv-from-heath-frankel/14555>\
**Category:** Implementers (archive)\
**Created:** [28 July 2006 12:33 UTC](https://discourse.openehr.org/t/mapping-archetypes-to-hl7-and-vv-from-heath-frankel/14555 "2006-07-28T12:33:07Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [28 July 2006 12:33 UTC](https://discourse.openehr.org/t/mapping-archetypes-to-hl7-and-vv-from-heath-frankel/14555/1 "2006-07-28T12:33:07Z")

</div>

[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

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [28 July 2006 14:07 UTC](https://discourse.openehr.org/t/mapping-archetypes-to-hl7-and-vv-from-heath-frankel/14555/2 "2006-07-28T14:07:26Z")

</div>

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/](http://www.rosa.nl/HL7/)

thanks  
Bert Verhees

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [4 August 2006 13:32 UTC](https://discourse.openehr.org/t/mapping-archetypes-to-hl7-and-vv-from-heath-frankel/14555/3 "2006-08-04T13:32:50Z")

</div>

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. 😉

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

---

<div class="post-metadata">

**Author:** ![Nitin\_Uchil](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/n/8edcca/32.png) [@Nitin\_Uchil](https://discourse.openehr.org/u/Nitin_Uchil)\
**Post date:** [4 August 2006 14:11 UTC](https://discourse.openehr.org/t/mapping-archetypes-to-hl7-and-vv-from-heath-frankel/14555/4 "2006-08-04T14:11:28Z")

</div>

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](http://www.ipedo.com). There are open source varations like BEA’s Beehive [http://beehive.apache.org/](http://beehive.apache.org/) etc.

Regards.

Nitin Uchil

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [4 August 2006 15:30 UTC](https://discourse.openehr.org/t/mapping-archetypes-to-hl7-and-vv-from-heath-frankel/14555/5 "2006-08-04T15:30:53Z")

</div>

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](http://www.ipedo.com). There are open source varations like BEA's Beehive [http://beehive.apache.org/](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