Vendor Aql workgroup meeting: 30/09/2021

Attendants: @Seref Arikan (Ocean) @Sebastian Iancu (Code 24) @Teun van Hemert (Nedap) @Matija Polajnar (Better)

Agenda Items

  • Current vendor priorities re Aql

  • Initial scope for future Aql versions

  • Other Aql related issues

Re scope:

S.I. (Sebastian Iancu): we would like to see Demographic model queries supported in Aql. Code 24 introduced the concept of System into the logical representation of their openEHR implementation, so that demographic and EHR data are grouped under distinct root concepts (EHR and Demographic) but they’re still under the same conceptual root.

S.A. (Seref Arikan) Potentially cyclic nature of Demographic data (two parties having bidirectional relationships) may or may not be a problem, but the CONTAINS keyword has a semantic that does not necessarily apply to ‘connected’ or ‘related’ semantics expressed by the demographic data. S.I in response suggests that use of functions can help extend the semantics available to query authors and there is some thinking that’s gone into this direction. TODO: discuss how functions can be used as suggested by S.I. and ask S.I. to share his approach.

S.A. and M.P. (Matija Polajnar) both say that they’re not considering extending Aql to Demographic, but happy to contribute to discussion about how it may be implemented.

S.A. : It would be good to work on how access control should work with Aql, especially when it is used for population level queries. This has been an issue for Ocean from an audit and access control perspective. M.P. : we’re using logging of queries run by the user. Given that the system is immutable, it means we can provide the information that was available to the query at the time. For access control, Better is using their ABAC server. This server is open source now and can be found here. S.I. : we should also make sure that access rules applied by Aql align with those expressed by EHR_ACCESS TODO: Discuss with SEC what may be a good way to harmonise ABAC and openEHR’s access control semantics, or is this even a good idea?

M.P. : We would like to see some specifics clarified in the documentation, which will also be required for conformance tests. Which types are allowed in the containment relationships? Which types from the RM are allowed in an Aql query and what’s their behaviour/semantics? Feedback and discussion from other attendees concluded with: there is no vendor interest in a generalised/non-openEHR scope for AQL specs or implementations.

Re priorities:

All attendees agree that having consistent behaviour for what is commonly described as the permutation problem is high priority. Different implementations should all return the same results, provided the same data and same query. Furthermore, if a user wants to understand why a particular result is returned, it should be possible to explain this by pointing at the documentation (S.A.) Some help for users may be needed, as is the case for SQL, but the fundamentals of the query semantics should be clearly stated in the specifications.

M.P.: We do not have customers requests to make Aql more understandable, so conformance is the real reason for us to want to see this happen.

S.A.: Are vendors able to explain how their implementation behaves? M.P. : assigned this task to a developer, i.e. to document the query execution semantics, but no updates yet. Also M.P.: does not see much of a point documenting the current behaviour, given it’ll be made obsolete based on future work. S.A. : Ocean’s implementation (and original thinking of the Aql authors, as confirmed by Heath Frankel) is influenced by relational algebra. T.V.H. (Teun Van Hemert) : our implementation is close to relational model.

S.A. : How should we proceed (I don’t want to suggest any formalism like I’ve done in the past) ?. M.P. : let’s get in touch with Bjørn Næss : his responses in the Aql teasers discussions made sense. Let’s also use the github repo he built for the discussions. TODO: ask Bjorn if he’s able to describe DIPS’s view of Aql query execution semantics.

Consensus on discussing behaviour: let’s go back to Aql teasers posted under SEC category and discuss these core cases one by one. Add new ones if a fundamental case is missing. Then let’s discuss what the semantics of composing these atomic operations should be, and use that as the basis of specifications and implementations going forward. TODO: revisit Aql teasers, (re)initiate a dedicated discussion among vendors. TODO: provide this summary page to vendors who could not attend this meeting. TODO: organise next meeting asap.