We face with the need to store AQL’s to be able to provide them when necessary to different initiatives projects or actors. We are not sure where to store them.
Has anyone else encountered this need? We would be very grateful if anyone could share their experience. Thank you so much.
4 Likes
DIPS has created a separate concept for storing queries that they call “VAQM”. More about them from @bna here: AQL through GraphQL - #12 by bna
Hey David,
From a tech-savvy perspective, you could leverage the ability store AQL queries via REST API: Definition API openEHR specs
And execute them when needed: Query API openEHR specs
Is that what you are looking for or did I understand your question wrong?
Yes, the REST API allows to have stored queries, so any CDR that implemented those endpoints will be able to store AQLs.
Though the challenge, and I guess that’s from where this question comes, we don’t have a standard way of managing AQLs. That is: defining their purpose, authoring metadata, versioning, etc. like we do with other authored resources in openEHR.
In our implementations (EHRServer/Atomik) we do manage stored queries in that way, though are not AQL.
Yes, I think that’s the question of @david.alonso
In Catalonia we will need to build a specific system for AQL publication and governance, much beyond of what stored queries can offer. I will include not only the purpose and authoring metadata but also the description of the query parameters, the description of the return values, or information about the execution rights or roles authorized to run those AQL.
2 Likes
We actually got a similar request from our UX and requirement engineers at vitagroup. Hence, I think there is some general appetite to enhance the spec of stored queries.
1 Like
We need something similar for authorising specific queries across CDR vendors. So we need basic things like naming and hashing a query and probably (semantic?) versioning.
2 Likes
I know that both @sebastian.garde and @rong.chen have been looking at what other metadata might be needed to store shared stored AQL queries for federation purposes.
At Cambio, we have the concept of reusable AQL queries that are used in forms and CDS apps. These query defintions are versioned and kept in light weight CKM with some basic metadata and authorship information.
I think we have a ticket on sharable AQLs in the SEC board, need to progress if there is enough interest & input on it.
2 Likes
Has anyone thought of using ADL with a query-RM ( not existing in spec) to fulfill this need? If that would work and if it would also make sense, then the governance including versioning. reviewing could be the same as for EHR archetypes ( e.g. CKM). That would be cool 
1 Like
I like your thinking. I definitely think a lot can be reused/inherited from archetypes, like identification, namespaceing, versioning, meta data like author, maybe multi language. But the definition section will be very different I assume?
I’m also interested in defining a result set for a query (maybe as part of the same artefact. Ithink anotations could be very important for the result. But it might be a risk to duplicate parts of the archetypes.
1 Like
Indeed, definition section has to be a bit different as it is not constraining the usual RM types we know. I did not thought too much on this, but a wild guess example:
archetype (adl_version=1.4; uid=5aaada4a-28be-46e9-b33d-f8739a71fcee)
openEHR-QUERY-QUERY.test.v0
concept
[at0000]
language
original_language = <[ISO_639-1::en]>
description
original_author = <
["name"] = <"...">
["organisation"] = <"...">
["email"] = <"...">
["date"] = <"...">
>
details = < >
definition
QUERY[at0000] matches {
q matches {
"SELECT
c/name/value AS Name, c/context/start_time AS date_time, c/composer/name AS Composer
FROM
EHR e[ehr_id/value=$ehrUid]
CONTAINS COMPOSITION c
ORDER BY c/context/start_time"
}
name matches {"test query"}
query_parameters matches {
STRING[at0003] matches {"ehrUid"}
}
}
ontology
term_definitions = <
["en"] = <
items = < ... >
>
>
>
If you would like templating such query-archetype (equivalent of a sort of ‘sub-select’ ?), then perhaps it would make more sense to further define and constrain that q as AQL subparts SELECT, FROM, WHERE, etc.
In any case, this is just a thought, not a proposal, and I was asking if any ADL experts here ( 
) had tried something like this.
1 Like
This idea goes in the right direction for any openEHR artifact, which should all be subtype of AUTHORED_RESOURCE, have some kind of RM associated and the capability of being defined by ADL.
Though I think this is half-way between the syntax and the model. IMHO we did put much effort on the syntax part of AQL and no much attention on processing or the model behind the query. It would be desirable to have a full Query RM, independent from any syntax, though that could be represented by a syntax (AQL or even ADL following the Query RM).
If we could reach a model that fully expresses a Query RM, we will be able to do things like type checking or validating query instances against the ADL.
The example provided by @sebastian.iancu has a top level class then the whole query is inside in am embedded syntax way, so with the ADL we can’t do much, just treat the whole query as a string.
Maybe it’s worth a try to define more of the query model and try to rely less on the AQL syntax at the ADL level. Though I don’t know if anyone in the SEC will like that idea 
2 Likes
This is a really interesting proposal! @joostholslag mentioned multi-language, and my first ever thought was that this would need to support multilingual paths, including the and name/value=parts. How could this work?
I guess alternatively the default way of differentiating paths would have to change to use coding instead of natural language names?
That is one of the issues that ADL2 will solve (and we are finally getting there!). When a name is cloned, the underlying atCode is specialised.
If you look at a a Better native json example you will see this is already handled but it cannot be exported to .opt - that needs to wait for .opt2
1 Like
The idea of using ADL as the container is nice but I think we should really hesitate at trying to do anything clever in the definition section beyond handling parameters.
That feels like a whole new specification area which must be a very low priority against all the other pressures on time and resource.
@joostholslag - the resultset is already defined by the AQL. Can you give an example of than ‘annotation’ - not sure what you men is this context?
I assume the result set is only defined in a generic way in AQL? I mean definition/annotations for a result set for a specific query. E.g. “this systolic blood pressure value query result is always between 0-200mmHG”, “it excludes blood pressures taken during hospital admission”. It’s just a wild idea, but I think it may be very useful for people using a query without knowing all the semantics of the archetypes the AQL and openEHR in general’.
does that make sense?
Which is why we separated out the Resource Model to BASE.
Well that’s an ADL concept. An artefact can be a kind of AUTHORED_RESOURCE without being an archetype.
If you want to go that way, we could solve the ‘definition’ part of the query with something that looks more like ‘query ADL’ (not yet formally defined, but very similar to GraphQL), which is ADL with only some id-codes (where you want matches), and a few other extras. WHERE clause is achieved by matches just like on normal ADL, but probably with narrower values.
I think the archetype would be the definition of a specific query by using the underlying query model, which is kind of a new syntax for sharing and managing queries instead of using AQL. In this context, AQL would be like a domain specific serialization format of a query. So these archetypes are not really generic building blocks for creating queries in templates, the archetype is the final query.
This would allow to reuse all the infrastructure we have for archetypes for managing queries, and if we want to think further, just for the sake of discussion, a similar idea would work for CDS rules, form definitions, etc. (I know we have GDL but we don’t have “GDLs” managed in the same way archetypes are managed yet).
I just find these ideas interesting, not proposing anything in particular, just thinking out loud. This would take a lot of time researching and testing, maybe it could be a good masters or PhD thesis project.
1 Like
If we could have a Query RM that could be constrained by ADL, we might take advantage of the ontology section of the archetype. Maybe having something like and name/value=at0xxx in the definition, and having one definition for each language for the at0xxx code in the query ADL.
Note if a template defines a constraint defining the texts, it generates a dependency on the query archetype, since the query should use only texts that are available. I guess that dependency could be detected automatically and the corresponding components could be added also automatically to the query archetype.
Then when the query is evaluated/executed from the archetype, the processing of the query can take the environment language as parameter and replace the code for the right term.
That would be if the query is executed directly from the ADL. Another way would be to have the query ADLs as sources, then compiled into the AQL syntax, and that compilation will replace the codes for the texts.
There could be other ways too.
Though, this is all theory.
1 Like