Resolving EHR_STATUS refs

Implementation Platform
1

It seems to me that EHRbase resolves OBJECT_REF refs in case of EHR_STATUS, replacing it with the actual object - see (UN)COMMON QUERIES | EHRbase Docs, but basically it is about an AQL like:

SELECT
   e/ehr_id/value,
   e/ehr_status/subject/external_ref/id/value
FROM  EHR e

So my questions are:

  1. Is this a (nice) EHRbase-feature, or an AQL requirement that I am not aware of?
  2. Is this also working on Better platform AQL
  3. Is this only implemented for EHR/EHR_STATUS refs, or is it also available to more other situations? (for example for refs somewhere inside COMPOSITION structures)
2

The Better CDR works exactly the same - I would guess this comes from original Ocean CDR behaviour.

Can you give an example of other Composition refs, other than LINKS and EHR_URIS that are not resolved?

1 Like
3

I don’t have an example, I was curious about what else besides EHR_STATUS is resolved in this fashion.
These cases could be for instance refs of the other EHR aspects (directory, ehr_status, contribution, etc) or from FOLDERs enclosing COMPOSITION. any other place where OBJECT_REF is used.

If this case of object ref is always resolved, then:

  1. should we have this specified in the AQL specs?
  2. what to do with an AQL that is considering the RM and is trying to get he OBJECT_REF? (e.g. SELECT e/ehr_status/id/type FROM EHR e)
  3. What else (besides EHR_STATUS) should the specs state that it should be always resolved?

In any case, the issue with accessing EHR_STATUS could have been solved in a different way, without having the engine replace the ref with the corresponding object, with using equivalent SELECT es FROM EHR contains EHR_STATUS es, right?