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

[Ian McNicoll <Ian.McNicoll@oceaninformatics.com>]

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@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 13:09, Sebastian Iancu <sebastian@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@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