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 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 09:49, Thomas Beale <thomas.beale at
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
>
> 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<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.
>
>
> 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 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/20100820/6337b53d/attachment.html>
