Need to obtain XSD for result set.
Correct statements about AQL 'being for EHR' to be broader (i.e. will work for demographics)
Example population queries for demographics
Also - need to query across EHR and Demographics together; is this embedded queries?
HF: what does conformance def look like for AQL? Be careful of extensions.
- separate conformance for AQL lan extensions
- distinguish patient v population querying
- GDL - relationship with AQL - e.g. apply GDL over AQL results.
Problems
Cartesian problem / permutation explosion - need semantics defined (refer to Seref Arikan analysis)
Related: Ian - want to be able to say things like '40 kg' rather than 2 paths.
Link / Reference-following
BN:
- in the DIPS, they use FOLDER CONTAINS COMPOSITION; FOLDER CONTAINS FOLDER etc.
- need to define Care Plan semantics
HF: in fact we do EHR CONTAINS COMPOSITION (probably take out 'EHR CONTAINs'? to get consistency); but: EHR => compositions etc is logical containment
could we have an 'IN' operator to cover all logical 'containment'?
Ian:
- want to make e.g. Problems linked from problem list via LINK? or DV_EHR_URI Composition should be selected same as if inline inside COMPOSITION.
- Care Plan linking
Link depth issue.
TB: need marked up Ref Model to indicate what links to follow.
- SParql
- GraphQL
Pablo: if we want to state conditions (e.g. Contains / Where) on LINK targets - it's a nested sub-query
Analytics requirements
Birger:
- ?alignment to SQL
- HF: we don't do 'JOINs' (yet) - LINK following might be a JOIN concept
- need aggregate functions like SUM(); GROUP-BY() e.g. list of patient counts keyed by ICD code
- set functions: Union; Intersect;
- e.g. SELECT x FROM y WHERE z UNION SELECT x FROM y etc - (need same nr or columns in each result & col names - check ?types)
- UNION-ALL (already in Marand)
- MINUS - diff
- example: exclusion criteria for clinical studies - e.g. remove certain patients from result - e.g. remove pregnant patients from analytic query
- (performance not necessarily so important)
Bostjan: - keep AQL parser and processor simpler - potentially implement via params in service interface
Birger - counter-argument - lose semantic integrity of queries if broken up via API params
Ian: harder to sell AQL if aggregate operators like SUM, UNION, are in AQL
Erik: maybe consider meta-land to wrap AQL statements
Birger: ?analytics specific flavour of AQL
Iago: no good way to do patient subsetting for GDL; need AQL subsetting to be efficient
Bjorn: best way to define set in pop queries, esp for use in GDL
TB: model of optimisation / efficiency of AQL
Birger: could imagine EHR persistence impls that are optimised for analytics.
UPDATE / DELETE / INSERT
Question of UPDATE and DELETE i.e. modifying AQL statements as per SQL
Birger: in terms of mindshare - potential users of AQL see AQL as deficient
HF: keep it simple
Dynamic Result Set Structures
Sebastian Iancu: want to generate an on-the-fly return structure e.g.
SELECT FROM ... e/data[at0003]/items[at0004]/items[at0005] as Hashmap( /name/value as Key, /value as Object( /magnitude as Magn, /units as Units ) ) FROM COMPOSITION c
Birger: better to do post-processing to achieve this result.
Sebastian: could apply to UPDATE as well.
Possible ways to do this: GraphQL?
MS etc has e.g . JSON export of SQL results.
Bjorn: 'APL' - AQL Processing Language: need a processing pipeline concept
Erik: would be easy to add a post-processing script to run after a Query execute in REST API; can use more 'types', i.e. 'aql', 'aql-in-xquery' or whatever
Work group
- Birger
- Bjorn
- Heath
- Seref
- Sebastian
- + others