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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100820/b874d652/attachment.html>
