Jose Alberto Maldonado wrote: > Hello, > > We have just read the message bellow and honestly we do not understand > anything now. We supposed that EN13606-1 reference model could be used as > reference model for developing archetypes. > You can read in prEN13606-2 (last version February 2005), section > 1.3. Communicating archetypes: "It is > the intention of both CEN and HL7 that HL7 Templates and EN13606 > archetypes be interoperable".
well, this has been stated for a long time, but there is little evidence of it happening. A recent post from the HL7 templates list indicates the current state of play...in short they using something called MIF to do "templates", which are approximately the same as archetypes. But it is complicated in HL7 because there are two ways to create any model of a clinical concept: using a template (presuming they finish defining what they think a template is) and using an RMIM - a message model. CEN doesn't need archetypes based on its own model, although not everyone in the working realises this yet. However, I had a recent discussion with Dr Gunnar Klein (chair of TC/251) and he now understands the reason why basing archetypes literally on EN13606 does not make a lot of sense. The documents you mention are indeed somewhat confusing as currenly worded and have to be changed; I will be recommending changes at the next CEN meeting. > One question arises are these EN13606 > archetypes different from OPENEHR archetypes?. > Could you show some examples of clinical concepts that can not be > expressed as archetypes derived from EN13606-1 reference model?. Sure....practically every archetype we have built. Have a look at the archetypes either using the adl-workbench or jsut on the web - see http://www.openehr.org/repositories/archetype-dev/latest/index.html. Consider the apgar archetype at http://www.openehr.org/repositories/archetype-dev/latest/adl/archetypes/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.apgar.v1.html - you will see it references classes OBSERVATION, HISTORY, EVENT, and LIST, and particular attributes, e.g. OBSERVATION has data, state and protocol (see e.g. blood pressure for example use of these). You can't write any of this using the CEN model because it just doesn't have any of the classes I just mentioned. Instead, you can only write ENTRY, CLUSTER and ELEMENT, which is too limited. CEN is designed to carry data that has already been archetyped, not to be a model on which archetypes are based. > > thanks in advance ------------------------------- HL7 templates list post ----------------- Lloyd McKenzie wrote: Hi John, The internal format of all HL7 v3 content is MIF. It is used for persistence, exhange, as well as for definition of what's possible. The MIF also acts as a UML profile expressing what pieces of UML HL7 permits and what stereotypes we require. The MIF requires that all 'custom' constraints be expressed as OCL, though alternate formal (e.g. Schematron) or free text representations are also supported. (Obviously we're coming up short on OCL representations at present.) Thus, to a certain extent, the statement of UML + OCL is accurate. We just need to make clear that the UML being referred to is the MIF LIM stereotype. Also, the format for registration should be MIF XML to allow for easy validation and checking against other models (e.g. RIM, datatypesn etc.) -----Original Message----- From: john.si...@philips.com Date: Thu, 3 Mar 2005 11:01:17 To:Mkfrad at aol.com Cc:lloyd at lmckenzie.com, owner-templates at lists.hl7.org, templates at lists.hl7.org Subject: Re: Comments on draft document As an 'outside' observer to all of these discussions there seems to be a core issue of disagreement and one which I share. That is, WHAT is the ITS and what is the 'official' HL7V3 representation of a model - I don't care if it a RIM, D-MIM or Any-MIM, template, CMET. Some contends it's the MIF and others contend it's UML (maybe with OCL) and the MIF is an interchange for the model (it's name suggests it is a interchange format NOT the model itself)! The other problem that seems to crop up is the resistance to use any previously defined mechanism to describe the logic or mathematical constraints on the model itself. When OCL is mentioned it's 'tossed' as an ITS rather than being viewed as an existing 'language' to define constraints. Same thing with OWL or ADL. I can't see why we can't separate the notion of using these 'existing languages or formalisms' to help define our constraints? (*) Just because we choose to use one of these languages for definitions doesn't IMPLY that the specific artifact has to be rendered or, for that matter, even stored in that format; it is used as a means to convey the concept in a more precise language. We could choose to use formal logic languages, assuming that these wouldn't be viewed as 'ITS'es , e.g. relational algebra or regular expressions, etc. if it could precisely define the constraints and remove the issue of these being 'ITS'-ish. However, at some point there has to be a formalism for defining the constraints on model elements (templates or any other V3 element) and that can either be a human language or a mathematical/logic language, or an existing constraints language. To me this all goes back to the discussion of HL7 V3's model as a 'pure' UML metamodel -- something we seem to have lost along the way -- because the MIF appears to [try to] be the V3 'metamodel'. [To me this is analogous to saying the XMI is the model and UML is not.] - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
