# Which queries should EHR\_STATUS.is\_queryable actually affect?

**URL:** <https://discourse.openehr.org/t/which-queries-should-ehr-status-is-queryable-actually-affect/2482>\
**Category:** Platform\
**Tags:** aql\
**Created:** [30 March 2022 09:34 UTC](https://discourse.openehr.org/t/which-queries-should-ehr-status-is-queryable-actually-affect/2482 "2022-03-30T09:34:31Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![vmueller-vg](https://discourse.openehr.org/user_avatar/discourse.openehr.org/vmueller-vg/32/1824_2.png) [@vmueller-vg](https://discourse.openehr.org/u/vmueller-vg)\
**Post date:** [30 March 2022 09:34 UTC](https://discourse.openehr.org/t/which-queries-should-ehr-status-is-queryable-actually-affect/2482/1 "2022-03-30T09:34:31Z")

</div>

Hey,

we want to implement the is\_queryable restrictions. So before this is started i wanted to clarify some questions I came across while reading the specs.

[EHR Information Model](https://specifications.openehr.org/releases/RM/latest/ehr.html#_ehr_status_class) states that is\_queryable will only affect population queries, meaning single EHR queries should still work.  
Where i am am a bit unsure is what actually counts as a population query:

[Archetype Query Language (AQL)](https://specifications.openehr.org/releases/QUERY/Release-1.0.0/AQL.html#_step_1_the_from_clause) states that the FROM clause of the query determines if it is a single or population query, where `FROM EHR [ehr_id/value='1234']` would make it a single EHR query.

[Query API](https://specifications.openehr.org/releases/ITS-REST/latest/query.html#header-query-types) states that a single EHR query can be achieved by supplying the `openEHR-EHR-id` header or `ehr_id` query parameter.

Question 1: Would these be applied to enforce the restriction to a single EHR regardless of whether the supplied query actually makes use of an `ehr_id` parameter or are they only applied if the query actually contains the parameter?

Question 2: Both definitions do not mention the WHERE clause in which one could also restrict the query to a single EHR like `WHERE e/ehr\_id/value=‘1234’. So am I correct to assume that an AQL query in which the limitation to a single EHR is done in the WHERE clause would still count as a population query?

Question 3: Is every query that is not a single EHR query a population query?

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [30 March 2022 11:10 UTC](https://discourse.openehr.org/t/which-queries-should-ehr-status-is-queryable-actually-affect/2482/2 "2022-03-30T11:10:36Z")

</div>

> [@vmueller-vg](#):
>
> Question 3: Is every query that is not a single EHR query a population query?

A population query is one that does not specify an EhrId, and for which the Query service will determine the matching cohort of EHRs.

---

<div class="post-metadata">

**Author:** ![vmueller-vg](https://discourse.openehr.org/user_avatar/discourse.openehr.org/vmueller-vg/32/1824_2.png) [@vmueller-vg](https://discourse.openehr.org/u/vmueller-vg)\
**Post date:** [30 March 2022 15:45 UTC](https://discourse.openehr.org/t/which-queries-should-ehr-status-is-queryable-actually-affect/2482/3 "2022-03-30T15:45:22Z")

</div>

Thanks. I am still a bit confused about what “specifies an EhrId” means concretely. Here are some small examples to illustrate my current understanding and what is unclear to me.

This would be a population query :

```auto
SELECT e/ehr_id/value, c/uid/value
FROM EHR e
CONTAINS COMPOSITION c

```

But then if i sent the `openEHR-EHR-id` header or `ehr_id` query parameter it would become a single EHR query because now it is supposed to only be run on the specified EHR right?

For these two I would think they are population queries since the WHERE conditions are evaluated for the entire population, but i am not sure if that is correct, since the WHERE clauses also specify one or multiple EHR-IDs:

```auto
SELECT e/ehr_id/value, c/uid/value
FROM EHR e
CONTAINS COMPOSITION c
WHERE e/ehr_id/value='1234'

```

```auto
SELECT e/ehr_id/value, c/uid/value
FROM EHR e
CONTAINS COMPOSITION c
WHERE e/ehr_id/value='1234' OR e/ehr_id/value='5678'

```

While this one would never be a population query independent of the header/query-parameter, because it is always limited to one EHR:

```auto
SELECT e/ehr_id/value, c/uid/value
FROM EHR e[ehr_id/value=$ehrId]
CONTAINS COMPOSITION c

```

---

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [31 March 2022 15:04 UTC](https://discourse.openehr.org/t/which-queries-should-ehr-status-is-queryable-actually-affect/2482/4 "2022-03-31T15:04:09Z")

</div>

> [@vmueller-vg](#):
>
> [Archetype Query Language (AQL)](https://specifications.openehr.org/releases/QUERY/Release-1.0.0/AQL.html#_step_1_the_from_clause) states that the FROM clause of the query determines if it is a single or population query, where `FROM EHR [ehr_id/value='1234']` would make it a single EHR query.

This could also be specified in the WHERE clause, because filters in the FROM clause are kind of a shortcut for/equivalent to, conditions in the WHERE. Something like: `SELECT * FROM EHR e WHERE e/ehr_id/value='1234'` is totally valid IMO.

That is related to your second question.

> [@vmueller-vg](#):
>
> Query API states that a single EHR query can be achieved by supplying the `openEHR-EHR-id` header or `ehr_id` query parameter.

This is correct, though wording in that section is not 100% correct, since having a query with `FROM EHR [ehr_id/value='1234']`is actually not having any “parameters”, a parameter would be “ehr\_id/value=$ehr\_id\_parameter”, IMO this needs rewording @thomas.beale @sebastian.iancu

That kind of answers your first question: is not about the parameter but providing a value for the ehr\_id, as parameter or inline in the query itself.

The challenge is: actually checking for a single EHR query, needs to parse the AQL into an AST and analyzing that for conditions over the ehr\_id, in the FROM or in the WHERE.

> [@vmueller-vg](#):
>
> Question 3: Is every query that is not a single EHR query a population query?

There could be a population query with a single EHR result. What makes a query to be a population one is that there is no filter for a single EHR in the query FROM / WHERE.

Hope that helps.

---

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [31 March 2022 15:08 UTC](https://discourse.openehr.org/t/which-queries-should-ehr-status-is-queryable-actually-affect/2482/5 "2022-03-31T15:08:55Z")

</div>

> [@vmueller-vg](#):
>
> But then if i sent the `openEHR-EHR-id` header or `ehr_id` query parameter it would become a single EHR query because now it is supposed to only be run on the specified EHR right?

If a query that doesn’t mention an EHR is submitted with that header, then the server needs o modify the query on the fly to add the condition for the EHR filter. Is that how this should work @thomas.beale @sebastian.iancu ?

If that is the way this was designed to work, IMO it is a weird design. I would expect the server to process the query as submitted, not changing it internally just because an extra parameter is there.

But I really don’t know how this works.

---

<div class="post-metadata">

**Author:** ![vmueller-vg](https://discourse.openehr.org/user_avatar/discourse.openehr.org/vmueller-vg/32/1824_2.png) [@vmueller-vg](https://discourse.openehr.org/u/vmueller-vg)\
**Post date:** [1 April 2022 02:50 UTC](https://discourse.openehr.org/t/which-queries-should-ehr-status-is-queryable-actually-affect/2482/6 "2022-04-01T02:50:36Z")

</div>

> [@pablo](#):
>
> Hope that helps.

Yes very much so. Thanks 🙂

> [@pablo](#):
>
> What makes a query to be a population one is that there is no filter for a single EHR in the query FROM / WHERE.

So just to be sure: If i have for example a disjunction of multiple EHR-IDs in the WHERE clause (like `WHERE e/ehr_id/value='1' OR e/ehr_id/value='2' `, this would then be a population query since it does not target a single EHR.  
(Sorry if i ask/state things multiple times. I’m a “rather ask/say it one time too much than not enough” person 😃 )  
And yes i agree, analyzing the WHERE-clause in particular may prove to be a challenge.

> [@pablo](#):
>
> If a query that doesn’t mention an EHR is submitted with that header, then the server needs o modify the query on the fly to add the condition for the EHR filter. Is that how this should work @thomas.beale @sebastian.iancu ?
> 
> If that is the way this was designed to work, IMO it is a weird design. I would expect the server to process the query as submitted, not changing it internally just because an extra parameter is there.

That is at least what the “Single EHR queries” section in [Query API openEHR specs](https://specifications.openehr.org/releases/ITS-REST/latest/query.html#header-query-types) implies IMO.  
EDIT: Also the REST spec is not clear on whether the header and the `ehr_id` “query parameter” are mutually exclusive. And if they are not it would be good to know which one takes precedence for modifying the query.

From a developer perspective I would agree that this feels like a weird design and will probably lead to confusion for developers

---

<div class="post-metadata">

**Author:** ![birger.haarbrandt](https://discourse.openehr.org/user_avatar/discourse.openehr.org/birger.haarbrandt/32/24_2.png) [@birger.haarbrandt](https://discourse.openehr.org/u/birger.haarbrandt)\
**Post date:** [1 April 2022 06:09 UTC](https://discourse.openehr.org/t/which-queries-should-ehr-status-is-queryable-actually-affect/2482/7 "2022-04-01T06:09:32Z")

</div>

> [@vmueller-vg](#):
>
> So just to be sure: If i have for example a disjunction of multiple EHR-IDs in the WHERE clause (like `WHERE e/ehr_id/value='1' OR e/ehr_id/value='2' `, this would then be a population query since it does not target a single EHR.

IMO this is **not** a population query. I think the distinction is that we only want to “see” active EHRs as part of population queries. For example, we might want a list of EHRs that have an open order entry for a medication or image study. In this case, we are really only interested in active records.

Sure, if in theory we use an “IN” operator (or “matches”) and put in all EHR IDs from our system, then we could argue that it is a population query. But I don’t think this is a helpful way to think about it this way.

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [1 April 2022 09:02 UTC](https://discourse.openehr.org/t/which-queries-should-ehr-status-is-queryable-actually-affect/2482/8 "2022-04-01T09:02:50Z")

</div>

> [@vmueller-vg](#):
>
> So just to be sure: If i have for example a disjunction of multiple EHR-IDs in the WHERE clause (like `WHERE e/ehr_id/value='1' OR e/ehr_id/value='2' `, this would then be a population query since it does not target a single EHR.

There is not really a formal definition that I know of for ‘population query’. But in my view a query of this form is just N individual queries being defined in a slightly more efficient fashion.

I see a population query as one that is trying to find out which individuals in a population match some criteria, or what some aggregate characteristic is over the population (e.g. average number of visits per year to the doctor). In a population query (according to this definition) you don’t know initially which EHRs are of interest - indeed, EHR ids are likely to be in the result, not the query.

> [@birger.haarbrandt](#):
>
> Sure, if in theory we use an “IN” operator (or “matches”) and put in all EHR IDs from our system, then we could argue that it is a population query. But I don’t think this is a helpful way to think about it this way.

That is my view as well.

---

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [1 April 2022 14:11 UTC](https://discourse.openehr.org/t/which-queries-should-ehr-status-is-queryable-actually-affect/2482/9 "2022-04-01T14:11:07Z")

</div>

> [@vmueller-vg](#):
>
> So just to be sure: If i have for example a disjunction of multiple EHR-IDs in the WHERE clause (like `WHERE e/ehr_id/value='1' OR e/ehr_id/value='2' `, this would then be a population query since it does not target a single EHR.

I agree with that, though there is a gray area right now in the specs. My rationale is:

1. query classes divide in: single EHR queries / population queries
2. when the ehr\_id filter (note I said `filter` nor `parameter` which I think should be the correct name), the result will be for a population
3. the specs doesn’t say if a multi-value filter is used for ehr\_id then the query is a population one (like ehr\_id IN (a,b,c)

Maybe we are missing (in the specs) another classification.

@thomas.beale mentioned `cohort`, IMO a `cohort query` (I propose that name) is when you want to target specific EHRs and multiple EHRs.

When doing population studies you initially want to target ANY EHR (population) and get the EHRs that comply with some condition.

Then you might want to further query, but just those EHRs that resulted from the population query, I would call these `cohort` queries.

Then you might want to target individual EHRs to check some conditions or, for a population study, not even query individual EHRs.

> [@vmueller-vg](#):
>
> From a developer perspective I would agree that this feels like a weird design and will probably lead to confusion for developers

Yep, that is exactly what I thought when I read that part of the spec. I don’t like the system changing my queries because some parameter/header appears in the request.