Skip to Navigation | Skip to Content

openEHR-Technical mailing list archives

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

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

Hi Thomas,

In CKM, the run-time name constraint is displayed under 'Concept name'
.
The ADL is 

 PARTY_IDENTITY[at0000] matches {  -- Person name
name matches { -- A classification that enables differentiation between the usage of names for a person.
   DV_TEXT matches {*}
            DV_CODED_TEXT matches {   
                 defining_code matches {
                                        [local::
                                         at0023,
                                         at0024,
                                         at0025,
                                         at0026,
                                         at0027,
                                         at0028]
                 }
   }
...


Dr Ian McNicoll
office / fax  +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
ian@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 09:49, Thomas Beale <thomas.beale@oceaninformatics.com> wrote:
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 


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


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