My two cents, A nodeID only has to be unique inside an archetype, because an archetype with a specific archetypeId is considered unique. The path to a data-item contains the nodeId and the archetypeID, and together they form a unique combinations. (most of the cases the paths contains more then one nodeIds and archetypeIds (in case of slots))
A data-item is not identified by the nodeId, but by the archetype-path to that data-item Bert On 08/29/2013 06:32 AM, William Goossen wrote: > There is plenty of health informatics science that tells that combining data > from various systems is only possible when each data element is uniquely > coded. > > That single use case alone - reusing data from multiple systems - justifies > the SHALL linkage between data element/node and terminology as Snomed CT. > > I agree with Sam that the meaning should be derived from the DCM and the > collection of data elements in it. > > Here is where the science of data Modelling and the science of clinical > terminologies meet and team up. > > Vriendelijke groet, > > Dr. William Goossen > > Directeur Results 4 Care BV > +31654614458 > > Op 28 aug. 2013 om 23:55 heeft openehr-technical-request at lists.openehr.org > het volgende geschreven: > >> Send openEHR-technical mailing list submissions to >> openehr-technical at lists.openehr.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> or, via email, send a message with subject or body 'help' to >> openehr-technical-request at lists.openehr.org >> >> You can reach the person managing the list at >> openehr-technical-owner at lists.openehr.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of openEHR-technical digest..." >> >> >> Today's Topics: >> >> 1. Re: openEHR-technical Digest, Vol 18, Issue 37 (William Goossen) >> 2. RE: openEHR-technical Digest, Vol 18, Issue 37 (Sam Heard) >> 3. Re: openEHR-technical Digest, Vol 18, Issue 37 (Hugh Leslie) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 28 Aug 2013 19:16:13 +0200 >> From: William Goossen <wgoossen at results4care.nl> >> To: "openehr-technical at lists.openehr.org" >> <openehr-technical at lists.openehr.org> >> Cc: "openehr-technical at lists.openehr.org" >> <openehr-technical at lists.openehr.org> >> Subject: Re: openEHR-technical Digest, Vol 18, Issue 37 >> Message-ID: <41D62117-1409-4EBB-B352-3CA1B71DDC5E at results4care.nl> >> Content-Type: text/plain; charset=us-ascii >> >> The General problem with the at codes is that each archetype has the same at >> codes. Hence it is not an ontology it refers to but is an internal >> micro-ontology only . >> >> In the DCM approach each node SHALL have a minimum of one external code, >> preferable Snomed CT, which links the data element in the archetype to an >> external ontology, which importantly allows external maintenance and >> governance and facilitates the use in other archetypes or templates as >> defined in OpenEHR. >> >> Vriendelijke groet, >> >> Dr. William Goossen >> >> Directeur Results 4 Care BV >> +31654614458 >> >> Op 28 aug. 2013 om 18:00 heeft openehr-technical-request at >> lists.openehr.org het volgende geschreven: >> >>> Send openEHR-technical mailing list submissions to >>> openehr-technical at lists.openehr.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >>> or, via email, send a message with subject or body 'help' to >>> openehr-technical-request at lists.openehr.org >>> >>> You can reach the person managing the list at >>> openehr-technical-owner at lists.openehr.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of openEHR-technical digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: Polishing node identifier (at-codes) use cases. >>> (Gerard Freriks) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Wed, 28 Aug 2013 13:26:14 +0200 >>> From: Gerard Freriks <gfrer at luna.nl> >>> To: For openEHR technical discussions >>> <openehr-technical at lists.openehr.org> >>> Subject: Re: Polishing node identifier (at-codes) use cases. >>> Message-ID: <C6BF076F-3040-442B-B9D7-69D04EEC599A at luna.nl> >>> Content-Type: text/plain; charset="windows-1252" >>> >>> David, >>> >>> Can I summarise it for my understanding as: >>> - ATxxxx codes are pointers to an 'ontology'. >>> - ATxxxx codes can be considered symbols that represent a particular concept >>> - The 'ontology' provides a name that will be used to display the name of a >>> node (concept) in an archetype. >>> - When a node is specialised the node name used will indicate a new concept >>> (its meaning has changed) >>> - When the archetype is specialised ideally the new concept in the >>> specialisation is a subordinate concept. >>> - When a Node is specialised the standard does not prescribe that the new >>> concept is a sub-set of the previous one. >>> - The question is: is each Node (and the concept it represents) unique or >>> not. >>> - The question is: is it obligatory that each node in the archetype carries >>> a unique code of the form ATxxxx . >>> >>> My answers to both questions are: >>> - Each archetype node is a unique concept that must have attached to it a >>> unique identifier. >>> - Archetype editors must support this. >>> >>> And I would like to add: >>> - When specialising each specialised concept must be a subset of its >>> previous one. >>> >>> >>> Gerard Freriks >>> +31 620347088 >>> gfrer at luna.nl >>> >>> On 28 aug. 2013, at 09:13, David Moner <damoca at gmail.com> wrote: >>> >>>> I'll try to summarize the origin of the different views we have regarding >>>> this topic and maybe this can be also useful to see why this is not just a >>>> configuration problem of the tools. >>>> >>>> We can find the explanation of node identifiers in two places (I use the >>>> latest drafts, I think): >>>> - In AOM 1.5 specifications, page 47: "Semantic identifier of this node, >>>> used to distinguish sibling nodes of the same type. [Previously called >>>> ?meaning?]. Each node_id must be defined in the archetype ontology as a >>>> term code." >>>> - In ADL 1.5 specifications, page 26: "In cADL, an entity in brackets of >>>> the form [atNNNN] following a type name is used to identify an object >>>> node, i.e. a node constraint delimiting a set of instances of the type as >>>> defined by the reference model." and "A Node identifier is required for >>>> any object node that is intended to be addressable elsewhere in the same >>>> archetype, in a specialised child archetype, or in the runtime data and >>>> which would otherwise be ambiguous due to sibling object nodes" >>>> >>>> The definition in AOM is the one followed by the openEHR editor, i.e. a >>>> node identifier or atNNNN code is just a pointer to the ontology section >>>> and a mechanism to distinguish sibling nodes. Thus, wherever it is not >>>> needed, the tool does not introduce that code in order not to dirty the >>>> ontology section. >>>> >>>> The first part of the definition in ADL is the one followed in LinkEHR >>>> and, in our opinion, more correct formally. When you introduce an >>>> archetype constraint for a C_OBJECT you are in fact creating a definition >>>> of a type (a sub-type of the more generic type defined by the reference >>>> model class) that will be used to create a subset of instances. We have to >>>> distinguish this sub-type from the RM type, and since the class name >>>> cannot be changed, the only solution is to use the atNNNN as type >>>> identifier. In other words, our interpretation is that atNNNN codes are >>>> unique identifiers of each type defined in the archetype, that may be also >>>> used to link to the ontology section, but that is the optional part. In >>>> fact, the only exception to this would be when you create constraints >>>> using a path, because then you are just navigating through the RM but do >>>> not change the meaning of the intermediate classes. >>>> >>>> The logic of the tools and the validation checks of archetypes are built >>>> based on those interpretations. I agree with Bert in one thing: tools >>>> shouldn't change things without notifications, but in this case we face a >>>> methodological difference, not just a configuration one, and that's why it >>>> is not easy to be solved. >>>> >>>> David >>>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/1595399d/attachment-0001.html> >>> >>> ------------------------------ >>> >>> Subject: Digest Footer >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >>> ------------------------------ >>> >>> End of openEHR-technical Digest, Vol 18, Issue 37 >>> ************************************************* >> >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 28 Aug 2013 19:58:10 +0100 >> From: Sam Heard <sam.heard at oceaninformatics.com> >> To: For openEHR technical discussions >> <openehr-technical at lists.openehr.org> >> Subject: RE: openEHR-technical Digest, Vol 18, Issue 37 >> Message-ID: <BLU404-EAS150A57B3DF007FCD8490EA2854B0 at phx.gbl> >> Content-Type: text/plain; charset="utf-8" >> >> Hi William >> >> That road is seductive but assumes that SNOmed or the like covers the >> concept unambiguously. The fact is that the world experts on SNOMED spent >> weeks discussing what codes applied to the BP archetype nodes.....and >> finally agreed with the ones I had proposed. >> >> The fact is that the archetypes are often far less ambiguous than the terms >> in an ontology. >> >> Modeling in openEHR will accelerate now we have a widening implementation >> base. The models won't be perfect or all encompassing but they will support >> high fidelity processes and sharing evolving data expressions. >> >> Ontological based approaches may be suitable in 20 years, but will need to >> be based on the clinical models, not the other way around. Clinicians need >> to define what they want to record. >> >> My 2p - Cheers Sam >> >> Dr Sam Heard >> FRACGP, MRCGP, DRCOG, FACHI >> Chairman, Ocean Informatics >> Chairman, openEHR Foundation >> Chairman, NTGPE >> +61417838808 >> ________________________________ >> From: William Goossen<mailto:wgoossen at results4care.nl> >> Sent: ?28/?08/?2013 6:16 PM >> To: openehr-technical at lists.openehr.org<mailto:openehr-technical at >> lists.openehr.org> >> Cc: openehr-technical at lists.openehr.org<mailto:openehr-technical at >> lists.openehr.org> >> Subject: Re: openEHR-technical Digest, Vol 18, Issue 37 >> >> The General problem with the at codes is that each archetype has the same at >> codes. Hence it is not an ontology it refers to but is an internal >> micro-ontology only . >> >> In the DCM approach each node SHALL have a minimum of one external code, >> preferable Snomed CT, which links the data element in the archetype to an >> external ontology, which importantly allows external maintenance and >> governance and facilitates the use in other archetypes or templates as >> defined in OpenEHR. >> >> Vriendelijke groet, >> >> Dr. William Goossen >> >> Directeur Results 4 Care BV >> +31654614458 >> >> Op 28 aug. 2013 om 18:00 heeft openehr-technical-request at >> lists.openehr.org het volgende geschreven: >> >>> Send openEHR-technical mailing list submissions to >>> openehr-technical at lists.openehr.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >>> or, via email, send a message with subject or body 'help' to >>> openehr-technical-request at lists.openehr.org >>> >>> You can reach the person managing the list at >>> openehr-technical-owner at lists.openehr.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of openEHR-technical digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: Polishing node identifier (at-codes) use cases. >>> (Gerard Freriks) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Wed, 28 Aug 2013 13:26:14 +0200 >>> From: Gerard Freriks <gfrer at luna.nl> >>> To: For openEHR technical discussions >>> <openehr-technical at lists.openehr.org> >>> Subject: Re: Polishing node identifier (at-codes) use cases. >>> Message-ID: <C6BF076F-3040-442B-B9D7-69D04EEC599A at luna.nl> >>> Content-Type: text/plain; charset="windows-1252" >>> >>> David, >>> >>> Can I summarise it for my understanding as: >>> - ATxxxx codes are pointers to an 'ontology'. >>> - ATxxxx codes can be considered symbols that represent a particular concept >>> - The 'ontology' provides a name that will be used to display the name of a >>> node (concept) in an archetype. >>> - When a node is specialised the node name used will indicate a new concept >>> (its meaning has changed) >>> - When the archetype is specialised ideally the new concept in the >>> specialisation is a subordinate concept. >>> - When a Node is specialised the standard does not prescribe that the new >>> concept is a sub-set of the previous one. >>> - The question is: is each Node (and the concept it represents) unique or >>> not. >>> - The question is: is it obligatory that each node in the archetype carries >>> a unique code of the form ATxxxx . >>> >>> My answers to both questions are: >>> - Each archetype node is a unique concept that must have attached to it a >>> unique identifier. >>> - Archetype editors must support this. >>> >>> And I would like to add: >>> - When specialising each specialised concept must be a subset of its >>> previous one. >>> >>> >>> Gerard Freriks >>> +31 620347088 >>> gfrer at luna.nl >>> >>> On 28 aug. 2013, at 09:13, David Moner <damoca at gmail.com> wrote: >>> >>>> I'll try to summarize the origin of the different views we have regarding >>>> this topic and maybe this can be also useful to see why this is not just a >>>> configuration problem of the tools. >>>> >>>> We can find the explanation of node identifiers in two places (I use the >>>> latest drafts, I think): >>>> - In AOM 1.5 specifications, page 47: "Semantic identifier of this node, >>>> used to distinguish sibling nodes of the same type. [Previously called >>>> ?meaning?]. Each node_id must be defined in the archetype ontology as a >>>> term code." >>>> - In ADL 1.5 specifications, page 26: "In cADL, an entity in brackets of >>>> the form [atNNNN] following a type name is used to identify an object >>>> node, i.e. a node constraint delimiting a set of instances of the type as >>>> defined by the reference model." and "A Node identifier is required for >>>> any object node that is intended to be addressable elsewhere in the same >>>> archetype, in a specialised child archetype, or in the runtime data and >>>> which would otherwise be ambiguous due to sibling object nodes" >>>> >>>> The definition in AOM is the one followed by the openEHR editor, i.e. a >>>> node identifier or atNNNN code is just a pointer to the ontology section >>>> and a mechanism to distinguish sibling nodes. Thus, wherever it is not >>>> needed, the tool does not introduce that code in order not to dirty the >>>> ontology section. >>>> >>>> The first part of the definition in ADL is the one followed in LinkEHR >>>> and, in our opinion, more correct formally. When you introduce an >>>> archetype constraint for a C_OBJECT you are in fact creating a definition >>>> of a type (a sub-type of the more generic type defined by the reference >>>> model class) that will be used to create a subset of instances. We have to >>>> distinguish this sub-type from the RM type, and since the class name >>>> cannot be changed, the only solution is to use the atNNNN as type >>>> identifier. In other words, our interpretation is that atNNNN codes are >>>> unique identifiers of each type defined in the archetype, that may be also >>>> used to link to the ontology section, but that is the optional part. In >>>> fact, the only exception to this would be when you create constraints >>>> using a path, because then you are just navigating through the RM but do >>>> not change the meaning of the intermediate classes. >>>> >>>> The logic of the tools and the validation checks of archetypes are built >>>> based on those interpretations. I agree with Bert in one thing: tools >>>> shouldn't change things without notifications, but in this case we face a >>>> methodological difference, not just a configuration one, and that's why it >>>> is not easy to be solved. >>>> >>>> David >>>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/1595399d/attachment-0001.html> >>> >>> ------------------------------ >>> >>> Subject: Digest Footer >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >>> ------------------------------ >>> >>> End of openEHR-technical Digest, Vol 18, Issue 37 >>> ************************************************* >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/34ab97de/attachment-0001.html> >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 28 Aug 2013 23:55:21 +0200 >> From: Hugh Leslie <hugh.leslie at oceaninformatics.com> >> To: For openEHR technical discussions >> <openehr-technical at lists.openehr.org>, William Goossen >> <wgoossen at results4care.nl> >> Subject: Re: openEHR-technical Digest, Vol 18, Issue 37 >> Message-ID: >> <140c6ec5f97.27fb.243087f8365f3372debbc7646d5c4c1f at >> oceaninformatics.com> >> >> Content-Type: text/plain; charset="us-ascii"; format=flowed >> >> Hi William >> >> The whole point of at codes is that they ARE an internal terminology and >> that an archetype only has to be consistent internally. Of course any node >> in an archetype can be bound or mapped to one or more terminologies as >> necessary. The openEHR work is well proven in many contexts, and your >> statements are only a matter of opinion rather than any science. >> >> Regards Hugh >> >> >> >> --- Original message --- >> From: William Goossen <wgoossen at results4care.nl> >> Date: 28 August 2013 7:16:13 PM >> Subject: Re: openEHR-technical Digest, Vol 18, Issue 37 >> To: "openehr-technical at lists.openehr.org" <openehr-technical at >> lists.openehr.org> >> CC: "openehr-technical at lists.openehr.org" <openehr-technical at >> lists.openehr.org> >> >>> The General problem with the at codes is that each archetype has the same >>> at codes. Hence it is not an ontology it refers to but is an internal >>> micro-ontology only . >>> >>> In the DCM approach each node SHALL have a minimum of one external code, >>> preferable Snomed CT, which links the data element in the archetype to an >>> external ontology, which importantly allows external maintenance and >>> governance and facilitates the use in other archetypes or templates as >>> defined in OpenEHR. >>> >>> Vriendelijke groet, >>> >>> Dr. William Goossen >>> >>> Directeur Results 4 Care BV >>> +31654614458 >>> >>> Op 28 aug. 2013 om 18:00 heeft openehr-technical-request at >>> lists.openehr.org >>> het volgende geschreven: >>> >>>> Send openEHR-technical mailing list submissions to >>>> openehr-technical at lists.openehr.org >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> or, via email, send a message with subject or body 'help' to >>>> openehr-technical-request at lists.openehr.org >>>> You can reach the person managing the list at >>>> openehr-technical-owner at lists.openehr.org >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of openEHR-technical digest..." >>>> >>>> Today's Topics: >>>> 1. Re: Polishing node identifier (at-codes) use cases. >>>> (Gerard Freriks) >>>> >>>> ---------------------------------------------------------------------- >>>> Message: 1 >>>> Date: Wed, 28 Aug 2013 13:26:14 +0200 >>>> From: Gerard Freriks <gfrer at luna.nl> >>>> To: For openEHR technical discussions >>>> <openehr-technical at lists.openehr.org> >>>> Subject: Re: Polishing node identifier (at-codes) use cases. >>>> Message-ID: <C6BF076F-3040-442B-B9D7-69D04EEC599A at luna.nl> >>>> Content-Type: text/plain; charset="windows-1252" >>>> David, >>>> Can I summarise it for my understanding as: >>>> - ATxxxx codes are pointers to an 'ontology'. >>>> - ATxxxx codes can be considered symbols that represent a particular >>>> concept >>>> - The 'ontology' provides a name that will be used to display the name of >>> a node (concept) in an archetype. >>>> - When a node is specialised the node name used will indicate a new >>> concept (its meaning has changed) >>>> - When the archetype is specialised ideally the new concept in the >>> specialisation is a subordinate concept. >>>> - When a Node is specialised the standard does not prescribe that the new >>> concept is a sub-set of the previous one. >>>> - The question is: is each Node (and the concept it represents) unique or >>> not. >>>> - The question is: is it obligatory that each node in the archetype >>> carries a unique code of the form ATxxxx . >>>> My answers to both questions are: >>>> - Each archetype node is a unique concept that must have attached to it >>> a unique identifier. >>>> - Archetype editors must support this. >>>> And I would like to add: >>>> - When specialising each specialised concept must be a subset of its >>> previous one. >>>> Gerard Freriks >>>> +31 620347088 >>>> gfrer at luna.nl >>>> On 28 aug. 2013, at 09:13, David Moner <damoca at gmail.com> wrote: >>>>>>>> I'll try to summarize the origin of the different views we have >>> regarding this topic and maybe this can be also useful to see why this is >>> not just a configuration problem of the tools. >>>>> We can find the explanation of node identifiers in two places (I use the >>> latest drafts, I think): >>>>> - In AOM 1.5 specifications, page 47: "Semantic identifier of this node, >>> used to distinguish sibling nodes of the same type. [Previously called >>> ?meaning?]. Each node_id must be defined in the archetype ontology as a >>> term code." >>>>> - In ADL 1.5 specifications, page 26: "In cADL, an entity in brackets of >>> the form [atNNNN] following a type name is used to identify an object node, >>> i.e. a node constraint delimiting a set of instances of the type as defined >>> by the reference model." and "A Node identifier is required for any object >>> node that is intended to be addressable elsewhere in the same archetype, in >>> a specialised child archetype, or in the runtime data and which would >>> otherwise be ambiguous due to sibling object nodes" >>>>> The definition in AOM is the one followed by the openEHR editor, i.e. a >>> node identifier or atNNNN code is just a pointer to the ontology section >>> and a mechanism to distinguish sibling nodes. Thus, wherever it is not >>> needed, the tool does not introduce that code in order not to dirty the >>> ontology section. >>>>> The first part of the definition in ADL is the one followed in LinkEHR >>> and, in our opinion, more correct formally. When you introduce an archetype >>> constraint for a C_OBJECT you are in fact creating a definition of a type >>> (a sub-type of the more generic type defined by the reference model class) >>> that will be used to create a subset of instances. We have to distinguish >>> this sub-type from the RM type, and since the class name cannot be changed, >>> the only solution is to use the atNNNN as type identifier. In other words, >>> our interpretation is that atNNNN codes are unique identifiers of each type >>> defined in the archetype, that may be also used to link to the ontology >>> section, but that is the optional part. In fact, the only exception to this >>> would be when you create constraints using a path, because then you are >>> just navigating through the RM but do not change the meaning of the >>> intermediate classes. >>>>> The logic of the tools and the validation checks of archetypes are built >>> based on those interpretations. I agree with Bert in one thing: tools >>> shouldn't change things without notifications, but in this case we face a >>> methodological difference, not just a configuration one, and that's why it >>> is not easy to be solved. >>>>> David >>>>>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: >>> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/1595399d/attachment-0001.html> >>>> ------------------------------ >>>> Subject: Digest Footer >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> openEHR-technical at lists.openehr.org >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> ------------------------------ >>>> End of openEHR-technical Digest, Vol 18, Issue 37 >>>> ************************************************* >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> ------------------------------ >> >> End of openEHR-technical Digest, Vol 18, Issue 38 >> ************************************************* > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
