Hi Ian, I was not thinking on names attribute of an archetype as holding more than names. Yet, the demographic_im.pdf is suggesting/stating to use them to associate a type meaning the the owner objects (i.e. things like PERSON/name/value = "PERSON" or ROLE/name/value = "General practitioner"), and for some objects the purpose() is designed that way as well.
As you previously said, there can be RM-types and Archetype-types and the later is introduced in demographic package through this construction of 'name' attribute. As long as the scope of that 'type' is within (or related) that owner archetype domain I don't see any problem, but if that that 'type' need used outside I don't really see it working, without a proper coding system or at least a binding. Maybe I was not very clear in previous emails about my reasoning, maybe I am just confused about specifications or about the modeled archetypes on CKM, but nevertheless one of my main technical question remains: /how can a function like ACTOR.has_legal_identity() be implemented regardless the archetypes being used? / If you or somebody else can give some suggestion on this, I think it will be much more easier to understand the concepts behind the demographic package. Sebastian On 8/23/2010 4:52 PM, Ian McNicoll wrote: > Hi Sebastian, > > I am not sure I understand the distinction you are trying to make for > the purpose/type attribute in the demographics archetypes which I > would regard as simply a 'shortcut to ConceptName/value, and not an > attempt ot make a semantic statement about all names - the name types > will be dependent on the concept being defined by the archetype - it > could equally well be Oragnisation_name, or Professional_name, which > would have very different 'name types'. > > It certainly makes sense to define the persistence type of the > composition within the openEHR terminology since this is wholly > associated with the openEHR Reference Model. > > There are some exceptions like the UCUM units, and subject of data > terms e.g self, brother, sister, mother etc, which I believe in time > will be expressed and governed outside openEHR, but until SNOMED or > some other reference terminology is used ubiquitously, these terms > must be defined within openEHR, as we cannot assume that all openEHR > users have access to the equivalent SNOMED terms. > > So I think there is a fundamental difference between a 'type' > expressed within the Reference model, which will often/always need > direct openEHR terminology support, and a 'type' expressed at > archetype level, where using any sort of reference terminology is much > more difficult and the correct list is wholly dependent on the concept > being expressed in the archetype. > > As Thomas suggests, the whole assumption within openEHR is that the > semantics are based almost wholly in the archetype. If two > organisations use different archetypes to express Patient_name, there > is very little that can be done to enforce semantic interoperability. > The purpose() function is not designed to aid interoperability, but > even if it was agreed to use an external reference terminology to > supply values for purpose(), via the Concept name archetype root node, > if we are using 2 different archetypes to define PatientName, we > cannot further process the data i.e. the remainder of the archetypes > are semantically incompatible. I cannot really see the value of being > able to query for 'legal name', unless the remainder of the 2 > different archetypes are to some degree aligned e.g. have a common > specialisation parent. > > So, if we want to harmonise different Patient_Name models, we will > need to do much more than identify the name type, and we should start > from the basis of a common archetype, even if this is extended to > encompass differing requirements, or specialised for different > countries/vendors. Of course, having a universal set of terms for > 'name type' would be helpful but it really only makers sense to do > within the context of a common 'base' Patient Name archetype. > > Ian > > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100826/d85b59df/attachment.html>
