The difference I mentioned is an addition of a value to a value set and not a renaming. It is just another variant of the classical ?not elsewhere classified?-problem in classifications like ICD. We probably have to be even more aware of the problem with varying value sets when data is reused when we use queries to retrieve value sets from external terminologies instead of include the value sets in the archetype. Greetings, Mikael
_____ From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Stef Verlinden Sent: den 4 juni 2008 08:58 To: For openEHR technical discussions Subject: Re: openEHR Querying specifications I'm not a technical person but to me it seems very cumbersome if such 'differences' could exist between 2 versions of the same archetypes. This would mean that for every query one has to go into detail of every version of that AT which could mean al lot of work. To my understanding versions of AT's should be 'backward compatible'. One can only add (and maybe remove) items, but never rename an existing item. Only then a lot of unnecessary work for 'query-makers' can be avoided. Is this assumption indeed correct? Cheers, Stef Op 3-jun-2008, om 23:26 heeft Mikael Nystr?m het volgende geschreven: I disagree with Rong. If for example the change between the first and second version is a change in a position value set from ?sitting?, ?standing? and ?other? to ?sitting?, ?standing?, ?lying? and ?other?. If then a query is written for the first version of the archetype searching for all cases where the position is ?not sitting? and ?not standing? the query will search for the position ?other? and return a correct answer. If we implement Rong?s suggestion the query will work also with the second version of the archetype, but it will return another answer than the intended, namely the cases where the position is ?not sitting? and ?not standing? and ?not lying? instead of the intended ?not sitting? and ?not standing?. I therefore think that excluding the version information can result in a mess. /Micke _____ From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen Sent: den 3 juni 2008 22:54 To: For openEHR technical discussions Subject: Re: openEHR Querying specifications I suspect changes between version could potentially break the paths in WHERE clause. So maybe the version information isn't significant here since either the path works and the criteria are checked or the path doesn't work and fails silently. /Rong On Tue, Jun 3, 2008 at 10:36 PM, Ian McNicoll <Ian.McNicoll at oceaninformatics.com> wrote: Fair point. Perhaps AQL should support ranges of version numbers to simplify the query as in many cases the query will not be affected by a structrural change to the archetype e.g. > FROM EHR [ehr_id/value=$ehrUid] > CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v[BETWEEN 1.5 AND 2] > CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v[>=1] > WHERE ( > obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value >= > 140 Versions and revisions would need to be handled. Ian 2008/6/3 Greg Caulton <caultonpos at gmail.com>: > > ------------------------------ > > Message: 2 > Date: Tue, 03 Jun 2008 16:39:37 +0100 > From: Thomas Beale <thomas.beale at oceaninformatics.com> > Subject: openEHR Querying specifications > To: Openehr-Technical <openehr-technical at openehr.org> > Message-ID: <484565B9.6030805 at oceaninformatics.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > The current material is therefore intended as a resource for discussion > and definition of a query language for openEHR. A team can be defined > after sufficient time for the community to react to this material and > determine if it makes sense to use AQL as the basis or to seek other > solutions or candidates. > > - thomas beale > > > > Perhaps this has been answered but as the archetypes change version is it > expected that the AQL will need to keep up with that - I assume our historic > data would be specific to the archetype version - not 'upgraded' ? > > i.e. after v1: > > FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION > [openEHR-EHR-COMPOSITION.encounter.v1] > CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1] > WHERE obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value >>= 140 > > after v2: > > FROM EHR [ehr_id/value=$ehrUid] > CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] > CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v2] > CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1] > CONTAINS OBSERVATION obs2 [openEHR-EHR-OBSERVATION.blood_pressure.v2] > WHERE ( > obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value >= > 140 OR > obs2/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value >>= 140 ) > > not sure if that is exactly right. > > thanks! > > Greg > > > http://www.patientos.org > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- Dr Ian McNicoll office +44(0)141 560 4657 fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com Consultant - IRIS GP Accounts Member of BCS Primary Health Care Specialist Group ? http://www.phcsg.org _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical _______________________________________________ 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/20080604/270109a7/attachment.html>