Re: Run-time name constraints and appropriate use of terminologies

[Thomas Beale <thomas.beale@oceaninformatics.com>]

On 16/08/2010 10:26, Ian McNicoll wrote:

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.

Hi Ian, I could not see the following in the archetype mentioned above.

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

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.

presumably in the same place as where we define things like 'family relationship'. Currently this is done in openEHR, because of the lack of a reliable alternative, but we should take this up at IHTSDO to see if these kind of vocabularies cannot all be done in Snomed.

- thomas beale

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical