openEHR Querying specifications
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/362e1406/attachment.html
openEHR Querying specifications
On Tue, Jun 03, 2008 at 11:26:08PM +0200, Mikael Nystr?m wrote: I therefore think that excluding the version information can result in a mess. It shouldn't, of course, be excluded by default but should be excludable on demand. By, say, allowing regex matching for path definitions. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
openEHR Querying specifications
Hi Tim, -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Tim Cook Sent: Wednesday, June 04, 2008 4:49 AM To: For openEHR technical discussions Subject: Re: openEHR Querying specifications Hi Tom, On Tue, 2008-06-03 at 16:39 +0100, Thomas Beale wrote: I have uploaded the Ocean Informatics developed 'Archetype Query Language' (AQL) as a candidate solution for querying archetype-based data. As explained in the query specification home page, AQL can be treated as a starting point for defining a normative openEHR querying language, or it may be considered to be one candidate amongst several, if there are others available. Ocean Informatics undertakes to continue the development of this language in the openEHR space, so that if the openEHR community wishes to use AQL, the most recent modifications will be available. This certainly 'looks' functional. I assume that Ocean Informatics has done a fair amount of testing it to get to this point. [Chunlan Ma] Yes, Ocean has implemented the parser an query engine to process AQL queries even though some features are not supported yet. It is in our plan. Currently, all Ocean products are using AQL to retrieve data from backend. From my (possibly too brief) read; are there any cases where the FROM clause wouldn't contain either EHR of DEMOGRAPHICS as its first parameter? [Chunlan Ma] Certainly, a FROM clause doesn't necessarily include EHR if it is not required. In the From clause, if you specify a particular ehr_id value as the criteria, then you are querying data within a single EHR. Otherwise, you are doing population queries, i.e. querying data across all EHRs. If you want to retrieve EHR associated information, then you need to specify the EHR variable in FROM clause, such as: SELECT e/ehr_id/value FROM EHR e CONTAINS... However, if you are not interested in the EHR associated information, then you can just leave it out. For example, SELECT c/composer/name FROM COMPOSITION c[openEHR-EHR-COMPOSITION.report.v1]... Also, does the FROM clause support wildcard matching such as: FROM EHR e[*] CONTAINS COMPOSITION c[openEHR-EHR-COMPOSITION.report.v1] Oooops! re-reading the very first step I see that the default is ALL EHRs. But, isn't explicit better than implicit in this case? Otherwise this query would read: FROM CONTAINS COMPOSITION c[openEHR-EHR-COMPOSITION.report.v1] Correct? [Chunlan Ma] We don't use wildcard in FROM clause because like what you said before, it is the same meaning as FROM EHR e CONTAINS If it is required, wildcard can be supported in WHERE clause or SELECT clause for the openEHR path, such as //*[at0002] Cheers, Chunlan Thanks, --Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* **
openEHR Querying specifications
Versions should be handled using the regular expression syntax of the archetype ID, as is done in ADL to represent slot constraints and action_arcehtype_id in ACTIVITY. E.g. [openEHR-EHR-COMPOSITION.encounter.v1*] BTW, using the OR operator you could have had ... CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] OR COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v2] ... Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Ian McNicoll Sent: Wednesday, 4 June 2008 6:06 AM To: For openEHR technical discussions Subject: Re: openEHR Querying specifications 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 Querying specifications
:// 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
openEHR Querying specifications
. 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
openEHR Querying specifications
On Wed, Jun 04, 2008 at 12:42:56AM +0200, Mikael Nystr?m wrote: It shouldn't, of course, be excluded by default but should be excludable on demand. By, say, allowing regex matching for path definitions. To be excludable on demand is probably a good solution, but I still think that there is a benefit if it is possible to see which version of the archetype the query was written for. If it's excluded on demand in a particular query then the query is written to work on any version - quite by design. Of course, the version can be included in the SELECT list so that one may learn which version actually matched the query. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
openEHR Querying specifications
On Wed, Jun 04, 2008 at 09:09:56AM +0930, Heath Frankel wrote: Versions should be handled using the regular expression syntax of the archetype ID, as is done in ADL to represent slot constraints and action_arcehtype_id in ACTIVITY. E.g. [openEHR-EHR-COMPOSITION.encounter.v1*] [openEHR-EHR-COMPOSITION.encounter.v\d+], hopefully ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
openEHR Querying specifications
Stef Verlinden wrote: 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? all, we need to be very clear about archetype 'versions'. There are two dimensions to the problem of 'archetype change' that need to be remembered. Firstly, archetype development lifecycle. Before an archetype is finally released after progressing through the quality assurance process, it will undergo many changes as part of normal authoring. During this period, no production data are created, and there is no issue about backward or forward compatibility of archetypes or queries with data. The second dimension is to do with the kinds of change that can be made. First of all, many variations in data can be accommodated with no change at all - archetypes are constraint models, not cookie-cutter templates. Most archetypes are designed to be very open. Many changes to archetypes, including all translations, and any semantic change that loosens the constraints can be accommodated by a 'revision'. Only incompatible changes result in a version change, i.e. a change in the '.v1', '.v2' etc part of the archetype identifier. Now, after an archetype is released, such changes should be minimal, if not non-existent. Remember: this is only incompatible changes, such as ones that change the structure of information, make optional items mandatory and other such things. When a new version is created, a data migration algorithm has to be published with it. The result of this is that new _versions_ of officially released archetypes should be very low in number and should always have a formal definition of how to migrate data created using an older version. The confusing factor that people are seeing now is that due to the current tooling, most archetype authors are creating new 'versions' when in fact the changes are only new revisions. We are also seeing many archetypes that have not been quality assured. These limitations are being addressed with new tooling that will soon be available, and a better defined version numbering system, using a 3 part identifier. One of the things the new ADL parser will be able to do is to determine whether a given change requires a new version or not. The algorhitms for doing this are not trivial and it has taken some time to get them worked out. In production systems different archetype versions may give rise to the following: - automatic data migration of data from an old version to a new version of an archetype - automatic on-the-fly translation of data from an old version to the form required by a new version If either or both facilities are in operation, then only one version of any given archetype will effectively be vsible in the database - the latest. For situations where data created by more than one is left intact, we consider this as if it were two archetypes. I.e. there is a general need if you are querying 'systolic blood pressure' to find all archetpes in which this could be recorded and to generate an appropriate query. If let's say 2 out of 3 found archetypes happen to be two versions of one logical archetype, this is essentially the same situatoin as if 3 distinct archetypes had been found that carried this data item. The key to managing this is the forthcoming online archetype repository classification ontology which allows you to do this search. This ontology already exists in a basic form, and is what supports the querying at the old prototype repository at http://archetypes.com.au. I hope this clarifies things - thomas
openEHR Querying specifications
Op 4-jun-2008, om 10:23 heeft Thomas Beale het volgende geschreven: I hope this clarifies things Absolutely, thanks. Stef -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080604/9103ac24/attachment.html
MIE-2008
One thing to note: in the MedInfo 2007 page, all the links point back to the openEHR.org website, whereas in future conference webpages, we will usually upload attachments. The problem we have to tackle is that conferences is only one way to view material; after a while you want a proper index of the papers etc, and you no longer care that much about what conference they came from. I addressed this on the openEHR website with a 'publications' set of pages (currently workflow, Health ICT and archetypes). The conference-independent view of things is obviously teh more long term one. Would anyone like to propose how we do this on the wiki? Clearly an agreed discipline is needed, e.g. we might say that you have to upload to a page for papers, and then put an entry in the conference page that just points to that. I'd say the 'long term' view should be in the publications section on the website, while the wiki could be used to assemble the conference information. What could be done is put a list of upcoming conferences in the wiki, but also in the 'news/events' section of the website, possibly linking to the respective conference page in the wiki. The wiki is then used by the participants in the conference to update the information and possibly upload the PDF of the paper and/or slides of the presentations. If necessary, extra wiki pages could be added to include discussions on specific papers/workshops, all accessible from the conference page. When the conference is over, papers could (possibly) be uploaded to the website and added to a special Daisy document type that has metadata on the paper (e.g. title, authors, conference, keywords, maybe abstracts and links to the respective wiki pages). The publication section in the website could be created dynamically sorting publications on topics, keywords, conference etc. Bye, Helma
Archetype official versions
On 6/4/08, openehr-technical-request at openehr.org openehr-technical-request at openehr.org wrote: The result of this is that new _versions_ of officially released archetypes should be very low in number and should always have a formal definition of how to migrate data created using an older version. - thomas In subversion there are a number of versions of archetypes - are any officially released or are all considered under development? dev\adl\openehr\ehr\entry\observation\openEHR-EHR-OBSERVATION.blood_pressure.v1.adl dev-uk-nhs\adl\openehr\ehr\entry\observation\openEHR-EHR-OBSERVATION.blood_pressure.v3.adl dev-uk-nhs\adl\openehr\ehr\entry\observation\openEHR-EHR-OBSERVATION.blood_pressure.v2.adl dev-uk-nhs\adl\openehr\ehr\entry\observation\openEHR-EHR-OBSERVATION.blood_pressure.v1.adl The NHS directory has many more templates which would be nice to use. thanks! Greg http://www.patientos.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080604/6b18254a/attachment.html
openEHR templates specification draft proposals available
An important part of the specfications work this year is the upgraded archetype specification and the new template specification. These specifications define specialised archeytpes and also openEHR templates. The latter will now have the equivalent of the Archetype Definition Language (ADL) and the Archetype Object Model (AOM) - known as the Template Definition Language (TDL) and the Template Object Model (TOM). There will also be an Operational Template Model (OTM). The XSD expression of the AOM will be upgraded and made more efficient (there will be a new version, the old one will remain available, and an XSLT conversion script will need ot be created); a new XSD for templates will be created from the TOM; this will largely re-use the AOM XSD. The basis of the template work has been tooling built by Ocean Informatics and used in various environments, but principally at the NHS since February 2007. This experience has provided the requirements and lessons needed to build what we believe is a solid open specification for templates that is compatible with the existing openEHR oeuvre. The acceptance of these proposals of course rests on validation via implementation, and the normal community and ARB review processes. The home page for this work can be found on the openEHR wiki at http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes . The community is encouraged to get involved in reviewing and contributing to the material. - thomas beale
openEHR Querying specifications
Dear all, The text below by Thomas warrants a conclusion: - openEHR needs a (place in a) document that defines the correct wording and meaning of: version and revision. To my mind these words are to much similar and can generate confusions. Alternatives: Package (new Archetype that breaks the previous package archetype) plus conversion script from the Old to the New Archetype) Version (new Archetype as the result of some editorial changes, only, not breaking the previous version) Gerard On Jun 4, 2008, at 10:23 AM, Thomas Beale wrote: The result of this is that new _versions_ of officially released archetypes should be very low in number and should always have a formal definition of how to migrate data created using an older version. The confusing factor that people are seeing now is that due to the current tooling, most archetype authors are creating new 'versions' when in fact the changes are only new revisions -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080604/4100af17/attachment.html
openEHR Querying specifications
]/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
openEHR Querying specifications
On Wed, 2008-06-04 at 21:56 +0200, Gerard Freriks wrote: Dear all, The text below by Thomas warrants a conclusion: - openEHR needs a (place in a) document that defines the correct wording and meaning of: version and revision. To my mind these words are to much similar and can generate confusions. Alternatives: Package (new Archetype that breaks the previous package archetype) plus conversion script from the Old to the New Archetype) Version (new Archetype as the result of some editorial changes, only, not breaking the previous version) Hmmm, seems to me that you are introducing a new term AND omitting a term that is in use. While not clarifying the previous terms which Tom did quite well. I believe that Tom very well defined a version change as a change that substantially modified a previous version in such a manner as to render it incompatible with previous versions. A Revision (which you omitted) is a change that may further constrain or otherwise modify an archetype but does not render the expressed information unusable. This is also the same information that can be found in the relevant documents. But I see no reference to 'Package' as far as archetypes are concerned. Package implies a grouping of some type. An archetype is (AFAIK) considered to be the expression of a single clinical concept. Regards, Tim -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080604/5051c0b7/attachment.asc
