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-bounces at 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/8eb66047/attachment.html>
