AQL fetch issue when Two different templates has same archetype in version 23

Specifications AQL
, , ,
1

Hi Team,

We have created two templates with same archetype sign/symptom created using same composition encounter v1,

While inserting data we have inserted two data points one is observation, and other is for cluster for template1
Where as, for the second template we have inserted for only cluster.

SO, when we try to fetch the data inserted for both templates, we are getting only one row for template1 where we had inserted for both data points(observation and cluster), but expected was 2 rows for both templates. This expected result was working in version 20, but the same is not working on 23.

Below is AQL used :

{
“q” : “SELECT e/ehr_id/value as ehrId, c/uid/value as composition_id, c1/items[at0001]/value/value as name, o1/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value/value as story,c/archetype_details/template_id/value as template FROM ehr e[ehr_id/value=‘{{ehrId}}’] CONTAINS COMPOSITION c[openEHR-EHR-COMPOSITION.encounter.v1] contains (observation o1[openEHR-EHR-OBSERVATION.story.v1] or cluster c1[openEHR-EHR-CLUSTER.symptom_sign.v1]) where (c1/items[at0001]/value/value=‘encounter-test-one’ and c/archetype_details/template_id/value =‘encounter-signsymptom-1.en.v0’ and o1/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value/value=‘Test’) or (c1/items[at0001]/value/value=‘test-encounter-two’ and c/archetype_details/template_id/value =‘encounter-signsyptom-2.en.v0’)”
}

Can you please help us identify the issue in new version, since it was working in version 20.

Thanks in Advance.

2

Which CDR implementation are you using?

3

It is tagged as EHRBase.
They also mentioned EHRBase in other posts.
I guess they are using EHRBase :blush:

4

We are using ehrbase version 0.23.0

5

Hi @Mancini,

would you be so kind to open an issue at the GitHub? Issues ¡ ehrbase/ehrbase ¡ GitHub?

6

Hi @Mancini,
I guess you’re question is related to Behaviour of logical operators(OR, AND, NOT) in FROM Clause - #32 by pablo.
Both are product-related questions, and best is to place them (or similar future questions) under Platform - openEHR section.
This section is a placeholder for question on AQL specifications, and therefore should be more generic or conceptual, not necessarily focused on a specific product.
Also, it would be nice if you could format next time the SQL and extract it from the JSON - so that it gets more readable.
However, if you now follow @birger.haarbrandt recommendation and I’m sure you’ll get an answer to your issue.

1 Like
7

This confuses me, where is the CLUSTER located in the COMPOSITION? A COMPO can’t have a CLUSTER directly in it, it should have some entry, the entry would have some structure and the structure the cluster.

Can you provide sample templates and compositions?

8

It will be in context/other_details.

Example

image
image469×598 51.4 KB

9

@birger.haarbrandt , raised an issue on GitHub. Thanks

10

Template -1
encounter-signsymptom-3.en.v0.opt (25.0 KB)
encounter-signsymptom-3.en.v0-FLAT.json (1.4 KB)
encounter-signsymptom-3.en.v0.t.json (10.8 KB)

1 Like
11

Template-2
aql.json (757 Bytes)
encounter-signsymptom-5.en.v0.json (1.5 KB)
encounter-signsymptom-5.en.v0.t.json (14.1 KB)
encounter-signsymptom-5.en.v0.opt (118.7 KB)

1 Like
12

I see the -5 file to have data in the observation, but the -3 doesn’t have data in the observation, it seems this is the only data point “encounter-signsymptom-5.en.v0/story_history/any_event:0/symptom_sign/symptom_sign_name” in the -5 file.

And this “encounter-signsymptom-3.en.v0/story_history/any_event:0/story:0” might be only a name, not data in a data structure. So not sure where is the cluster you mention. Maybe I don’t see it (I’m not used to custom formats, personally prefer canonical JSON).

Also there is a strange underscore in the _end_time and _health_care_facility, those are normal attributes like the rest, I think the underscore prefix might not be right. If those work, then maybe the CDR isn’t consistent in attribute naming.