Hi everyone,
we are having a question regarding AQL, and it would be great to have some input from the community. When querying our data, we need to be able to filter out non-signed entries (without ATTESTATION) . We are looking at different solutions, but all seem quite cumbersome. It becomes even harder when you have different signers for different parts of the composition. It seems like a common use case, but we were not able to find any info about it. Has anyone thought on how to solve this problem before? Is there is a simple way to do this (complying with the specs)?
Thanks!
(great work with the new forum btw ! )
Hi Seref,
we were considering something of this sort:
SELECT a
FROM EHR e[ehr_id/value=“XXX”]
CONTAINS ORIGINAL_VERSION
CONTAINS ATTESTATIONS a[is_pending = false]
CONTAINS (OBSERVATION b[openEHR-EHR-OBSERVATION.blood_pressure.v1])
even if this is correct (lot’s of gaps here, I’m not even sure if ORIGINAL_VERSION and ATTESTATIONS are addressable in AQL specs), this would only be a solution that would cover a single sign per composition scenario (attestations/items is not being evaluated to see if the OBSERVATION entry is covered). This AQL might not seen cumbersome, but the implementation is far from trivial.
I don’t think this is possible with the current specs. The quicker solution would be to query for the needed data and post process the result sets. Then if more data is needed, the REST API could be used to get specific full COMPOSITIONS.
SELECT e/ehr_id/value, c/uid/value
FROM EHR e CONTAINS VERSION v[LATEST_VERSION] CONTAINS COMPOSITION c
WHERE EXISTS v/attestations[is_pending=true]
AND NOT EXISTS v/attestations[is_pending=false]
Sam pointed out that this misses an important case. A version that was already signed can get a new pending attestation later, for example when the first clinician didn’t realise more action was needed. In his view only the latest pending attestation puts a direct responsibility on a clinician. So what you really want to ask is whether the most recent attestation on the current version is pending.
As far as I can tell, AQL can’t express that today. There’s no way to address the last element of attestations, and ORDER BY / LIMIT only work on result rows. So I’d agree with what @pablo said here in 2019.
For now we’ve added a function of our own for it, and labelled it as a FerroEHR extension:
WHERE LAST(v/attestations/is_pending) = true
I’d much rather have this standardised than keep our own version, so I’m curious what others think:
Do you agree with Sam that “pending” should mean the latest attestation is pending?
Is the order of attestations meaningful, or should “latest” be decided by time_committed?
Would it make sense for AQL to get a standard way to pick the last (or n-th) element of a list, like a [last()] predicate or LAST() / FIRST() functions?
How do other CDRs handle this now?
This also ties in with the questions in Attestation ‘Request’ about who is supposed to sign, and how committer should be read when is_pending is true.
If there’s interest I’m happy to draft something up?
Attestations are really a form of commitment. Is_Pending is a way of someone attesting that there is outstanding responsibility. The timing of this attestation should be determined by FerroEHR, as the time has to be beyond dispute as well. So I think we could say from a conformance point of view, either the attestation itself proves the date, or openEHR CDRs show that they always set the date of an attestation when it is being saved.
There is a vulnerability with importing existing EHR compositions from another source, but the Contribution will tell you when that took place and it would be possible to determine if the attestations were present in the previous CDR.
Timing of these statements is absolutely critical from a legal point of view.
I think this might be a useful function to have anyways, regardless of the usecase around attestation. Perhaps we would need to investigate and contemplate more, ask AQL users for use cases with impact. In any case, such functions are supported in SQL land, similar to MIN() and MAX().
Though you can extend your AQL implementation to support that, and when you have that tested, you can contribute your findings to the SEC (issues, caveats, pros/cons) and the SEC can evaluate to extend the formal AQL to support this.
IMO it’s always better to have a sample implementation to play with before going with the abstract requirement only and update the specs hoping that could be implementable.