# Mapping Archetypes to HL7 and vv [from Heath Frankel] **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2006-07-28 12:33 UTC **Views:** 4 **Replies:** 4 **URL:** https://discourse.openehr.org/t/mapping-archetypes-to-hl7-and-vv-from-heath-frankel/14555 --- ## Post #1 by @thomas.beale \[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 --- ## Post #2 by @system 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 --- ## Post #3 by @system 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 --- ## Post #4 by @Nitin_Uchil 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 --- ## Post #5 by @system 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 --- **Canonical:** https://discourse.openehr.org/t/mapping-archetypes-to-hl7-and-vv-from-heath-frankel/14555 **Original content:** https://discourse.openehr.org/t/mapping-archetypes-to-hl7-and-vv-from-heath-frankel/14555