Coming back to this, I agree that we can end with differing
implementations, but probably the challenge is to define the syntax of AQL
in a way that no different interpretations appear. Maybe I can propose a
simple example (not sure if 100% correct, but you get the idea)


ns snomedquery="";


    obs/$diagnosis, $ehrUid
    EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION
        CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.problem-diagnosis.v1]

This could be used for validation (and could be created automatically from
Even if we end up needing to know the range in the moment the measure was
taken we could use something similar

ns bioportal="";





I understand your concerns, but I think it falls into the same use case of
templates: Archetypes should have general use, but templates for your
organization probably haven't. Another example I can think of is mappings
to SNOMED-CT on archetypes: If you aren't in an IHTSDO member country you
can potentially end with constraints that you are unable to use/verify.

By the way, I don't know if I'm mistaken, but if we define the ranges on
the archetype I believe that currently AQL cannot access values in the
archetype definition, and probably the alternative of sending the ranges
with the data maybe is a little overkill.

2018-03-01 15:57 GMT+01:00 Seref Arikan <>:

> Hi Tom,
> On Thu, Mar 1, 2018 at 2:33 PM, Thomas Beale <>
> wrote:
>> On 01/03/2018 11:05, Seref Arikan wrote:
>>> Hi Diego,
>>> I'd like to hear how you'd address the requirement via a call to an
>>> external service.
>> I don't think it should be that complicated - after all, a call out to a
>> terminology service is already a call out to a service; terminology is just
>> one kind of reference knowledge that a query language / engine needs to get
>> at; we can assume that a units service (as Bert and others were discussing
>> earlier), lab results reference ranges, drug DB and so on may all be needed
>> by the query service.
> In case I gave the wrong impression: my question above was not meant to
> sound like I thought this would be a difficult thing. Reading it again, I
> can see that it may be interpreted as 'I'd like to see you try', which was
> not the intention. I genuinely wanted to  know how Diego would like to use
> AQL to address this specific requirement.
>> So I think it mainly comes down to the syntax and programming model of
>> talking out to such interfaces. We might potentially assume that they are
>> all based on a common ontology meta-model of some kind (e.g. based on BFO,
>> RO, IAO etc) in which case a common underlying style could be established.
> The way I see it, your suggestion may pave the way to the can of worms I
> mentioned earlier, so I'll give up on my efforts to not to hijack this
> thread :)
> Re extending AQL for calls to external services: I'd be inclined to keep
> the syntax in the scope of the AQL specification and leave the programming
> model out of scope.
> I think AQL needs to support procedural extensions as an umbrella concept,
> which, then, can be used for a number of things, some of which may be calls
> to external knowledge services.
> There is a lot more than calling out to external terminology services that
> can be accomplished with procedural extensions: they could turn AQL into
> the ultimate clinical data query language, which is the upside.
> But there is a downside as well: things may get complicated from a
> standardisation point of view.  Once calls to external services become part
> of syntax, AQL's vendor/implementation independent nature will be harder to
> preserve, as vendors start doing useful and no doubt clever things with
> calls to external services. Aql's behaviour is already slightly different
> across vendors, so if vendor X implements a smart feature using an external
> service and that service is available only in my vendor X's implementation,
> behaviour interoperability provided by AQL would be damaged.
> I think the upsides are worth adding this support but downsides will need
> careful management, probably based on profiles/levels etc.
>> - thomas
>> _______________________________________________
>> openEHR-technical mailing list
> _______________________________________________
> openEHR-technical mailing list


[image: VeraTech for Health SL] <>

[image: Twitter]  <> [image: LinkedIn]
<> [image: Maps]

Diego Boscá Tomás / Senior developer

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a
openEHR-technical mailing list

Reply via email to