FHIR Chat · 'return' semantics · cql

Stream: cql

Topic: 'return' semantics


view this post on Zulip Georg Fette (Oct 18 2018 at 08:03):

Hello,
I have some questions related to the 'return' operand in CQL:
- Is another structure other than 'Tuple' allowed to form results ? If arbitrary structures are allowed to be constructed in the return part how does the syntax of the 'constructors' of those structures look like ? On page 46 of the CQL documentation there is an example of a 'Concept' literal. But it is not clear to me how the values in the winged brackets are assigned to the members of the concept in the example. How would it look like if the returned results would be e.g. ad hoc constructed patient resources that are created by values retrieved by the query statment ?
- If 'Tuple' is used as return type, how does it look like when elements with different cardinality are used as the elements of the tuple ? Like in
[Encounter] E return Tuple { id: E.identifier, diagnosis: E.diagnosis }
Does in this case each tuple contain a list as its second element ?
- If 'Tuple' is used as return type, is it allowed to create the tuple of elements of differnt types mentioned in the query statement ? Something like:
[Encounter] E with [Condition] C return Tuple { id: E.identifier, c: C.identifier }
Does the list of returned tuple represent the cartesian product of all encounters and conditions that are found ? I have thought of the cartesian product because every valid encounter would have to be combined with every valid condition. It would look a bit like an unconstrained join in SQL which would as well return a cartesian product.
Greetings
Georg

view this post on Zulip Bryn Rhodes (Oct 23 2018 at 00:07):

Hi @Georg Fette, the short answer is yes to all of the above. CQL supports a tuple selector { id: 1, name: 'Joe' } (the Tuple keyword is optional), but CQL also supports instance selectors using the same syntax, but with the name of the type as a prefix. So something like Encounter { id: 1, period: ... }.

view this post on Zulip Bryn Rhodes (Oct 23 2018 at 00:07):

And yes, the unfiltered result of a multi-source query is the Cartesian product of all the input sources.

view this post on Zulip Bryn Rhodes (Oct 23 2018 at 00:07):

Exactly like an unconstrained join in SQL.


Last updated: Apr 12 2022 at 19:14 UTC