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 Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com ian at mcmi.co.uk Clinical Analyst Ocean Informatics Honorary Senior Research Associate, CHIME, University College London openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland On 20 August 2010 13:09, Sebastian Iancu <sebastian at code24.nl> wrote: > Hi Thomas, > > > On 8/20/2010 11:07 AM, Thomas Beale wrote: > > > well, queries will be archetype-dependent, that is the idea. > > > I think generally they are archetype-dependent, as most of the times > queries are looking for data within the concept-namespace created by the > archetype. But my issues presented earlier were related to the case when > queries are looking for type/purpose information, which I think is a bit out > of that archetype space. Let me give you another example: > > Suppose you're looking for persistent type composition. Luckily, as there > is an openEHR terminology, you can query (in a xpath like manner) for > COMPOSITION[category/defining_code/code_string = '341'] regardless those > compositions' archetype_id. > > But if you're looking for legal names of a person, I guess you'll have to > look for those PARTY_IDENTITIY objects (contained by PERSON) with a relevant > purpose - which I guess will be matched by a path like: > PERSON[openEHR-DEMOGRAPHIC-PERSON.person.v1]/identities[openEHR-DEMOGRAPHIC-PARTY_IDENTITY.person_name.v1, > name/value="Legal Name", name/defining_code/code_string="at0027"] if your > dealing with CKM archetypes. > > Looking only into current demographic specifications, if someone else (from > another organisation) develops other archetypes, the path can perhaps look > like: > PERSON[openEHR-DEMOGRAPHIC-PERSON.b_person.v1]/identities[openEHR-DEMOGRAPHIC-PARTY_IDENTITY.b_person_name.v1, > name/value="legal"] (as demographic_im.pdf is suggesting "legal" there - > page 13). > > Even if both organisations share both archetype sets, a demographic query > is only possible by considering both paths. Perhaps an external mapping is > neccesary so solve this, and of course it is the application's job to handle > it (without any addition/change to archetypes content). But it would be even > more helpful to support a generic query like: > PERSON/identities[name/defining_code/code_string="xxxxx"] or something else > with a similar outcome. > > The openEHR terminology is used for attribute codes in the model where it > is thought that the possible set of codes is universally applicable and > unlikely to change, or only very slowly. Any coded attribute that has a > value set that could be contextually dependent is going to require a more > dynamic and sophisticated approach to terminology. At the moment this is > done in archetypes, because there is nowhere else to do it. However, the > future approach may be that it could be done in SNOMED national extensions, > or lower level extensions of SNOMED. > > - thomas > > > Again, the concerns I have are only related to certain terms, certain > attributes, as used across demographic package to assign meaning to some > structures/objects - it is not about data contained by an archetype (data > contextualy depended on the namespace of that archetype). Maybe the future, > with the SNOMED collaboration you mentioned, will bring solutions to these > issues - I'm looking forward to this. > > Regards, > Sebastian > > _______________________________________________ > openEHR-technical mailing list > 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/20100823/f485f56e/attachment.html>
