I have been having an email conversation with Sebastian Iancu of Code24 about some issues concerning the design of the Demographics PARTY_IDENTITY.person_name.v1
http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.477 There were 2 key areas discussed: 1. In 'Person identifier' the concept name of the archetype has a 'run-time constraint' allowing the archetype concept to be re-defined at Template/tun-time. e.g the original name of the archetype is 'person identifier' which may be re-defined i.e. *Concept name* Person name Runtime name constraint: *Choice of:* - Coded Text - Reporting name [The subject?s name as it is to be used for reporting, when used with a specific identifier.] - Newborn name [A type reserved for the identification of unnamed newborn babies.] - Professional or business name [The name used by the subject for business or professional purposes.] - Maiden name [The name used by the subject of care prior to marriage.] - Legal name [Registered name (Legal name).] - Other name [Any other name by which the subject is known, or has been known by in the past.] - Free or coded text The constraint is deliberately left open (via the 'Free or coded text' choice) as we felt that we could not be certain that the Code Text options (derived from ISO) were universally applicable and that other national name categories are likely to be required in the forseeable future. The concept name constraint approach for compatibility with the purpose() function in the RM class: purpose() : DV_TEXT<http://_9_0_76d0249_1109068213265_877931_4246report.html/> Purpose of identity, e.g. ?legal?, ?stagename?, ?nickname?, ?tribal name?, ?trading name?. Taken from value of inherited name attribute. 2. A related but broader issue is how/where we should define the terms for such a constraint - in the openEHR terminology, in the archetype as local atcodes, or in an external terminology such as Snomed. I am reasonably confident that we have adopted the correct approach to these design issues and will post my own thoughts and replies, but I felt that the topic merited wider discussion, particularly as Sebastian has explained his concerns so clearly and is happy to move the discussion to the lists. Sebastian's latest reply to me needs to be in a separate post as the combined message is too large for the email server. I hope a lively debate will ensue :-) Regards, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100816/c6983baf/attachment.html>
