On Tue, Jun 3, 2008 at 11:26 PM, Mikael Nystr?m <mikny at imt.liu.se> wrote:
> 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". > > Micke, what if you keep the original search criteria "not sitting" and "not standing" instead of searching "others", will you get expected result with both versions? I was thinking on the potential broken paths between changes when I made my guess. Since archetypes are expressed more as "maximum datasets" now, it seems the changes of removing parts of the archetype will be kept minimum. Most of changes will perhaps be additions to allow more relevant data entries. If this is the case, the original path should remain valid through versions. I was too "quick" about broken path failing silently. The RM PATHABLE.item_at_path function (underlying path based query support in RM) requires path to be valid. Would this mean during query execution phase any invalid path in the query should result in stop of execution or exclusion of the current data instance from the result set? I think we need to make this clear in the query specification. The idea of "hiding" version number can be achieved if the Query generator tool will be smart enough to tell for a given set of versions of archetypes, a query should be not only valid with paths, but also semantically consistent across all versions. We probably want to have similar validation on the queries once they hit query engines. Cheers, Rong > > > 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/3255e5dd/attachment.html>
