AQL to retrieving data for an element with cardinality 0..*

Thats great! As I said before, that cl[at0005] is a valid predicate according to the AQL specifications, so it should be acceptable not only in the WHERE clause, but also in the FROM clause.

Following the discussion between @siljelb and @ian.mcnicoll, my opinion is that if we use a path in the WHERE clause, it should be evaluated as a whole, matching with every instance it finds, and without trying to break it by its middle multi-valued objects to group them. That should be explicitly expressed in the FROM clause.


@bna please note that this has to return rows where the match is found for the two where clause in the same instance of the cluster [at0022]


Absolutely. That was the point :+1:

This is where I suggested that the syntax and consequently the spec is ambiguous.

your implementation may be enforcing the criteria/logic for grouping data instances based on their archetype node ids, but I don’t think the syntax is actually expressing that here.

1 Like

Hmmm … one step forward and one step back!! At least in terms of helping fix the issue.

I have picked up 2 competing themes/suggestions.

  1. The ‘correct’ way to do this is enforce the grouping on a cluster by supporting CONTAINS on non-root archetype nodes. DIPS appear to do this.

  2. Better and DIPS simply assume that the correct behaviour is to group data instances (as Seref just said) in the absence of such a CONTAINS clause

It would be good to hear from other CDR implementers. This is quite a critical issue as a number of archetypes now use this pattern.

1 Like

Please consider not using this term :slight_smile: It really is vague.

1 Like

it is? Doesn’t it just mean nodes that are root points of the archetypes that created them, and are marked with the archetype id rather than an internal archetype node code. Interested to understand the ambiguity, relating to querying.

To me, that’s referring to a bunch of RM types which may be different according to interpretation. There’s been a historical difference between what can be archetyped and what the tools support (maybe that’s gone now), and what the clinicians prefer to archetype, as part of modelling. Agreeing upon a clear set of RM types as allowed types in the FROM clause is clearer to me. Highly personal view of course, but that’s where my confusion comes from.

ps: completely off topic but I’m being told that in recent years my perception has kinda “narrowed”. I seem to be getting stuck at ambiguities which do not exist to the other side of the conversation. No idea why but if this is another case, then sorry about it.

1 Like

As of the latest ehrbase Release, it will show the same behavior as Better and DIPS.


Thank you.

Hi All,
Unfortunately the latest EHRBase release has still not addressed this issue completely. I have raised an issue in EHRBase git issue.


1 Like