Hi,
Can you write an AQL to query only on a list of specific compositions? Is there any sample for reference?
I am trying to create the concept of clinical encounters and maintain a collection of compositions per encounter. I am using AQL to retrieve data per encounter and need to pass the corresponding set of compositions.
Thanks in advance
regards
Hi Dileep,
I do this by querying on the name attribute of the root composition archetype - see the examples in
You can of course query on multiple names.
where a/name/value matches {'Clinical Notes', 'Other Clinical Notes'}
Going forward I would expect the list of allowable composition names to come from a controlled vocabulary or even a local terminology.
Ian
Thanks Ian,
However my requirement is different. I seem to have confused you with the way my question was framed.
What I meant by composition ID was in fact Composition UID. I want to query the same template (/name/value), but limited to specific commits (compositionUIDs).
I hope that helps
regards
Modifying Ian’s example for a/uid/value and using uid values instead of names should do the trick
Beat me to it 
Ian
thanks Ian, Seref
regards
There is a bigger question of how best to model ‘encounter’ and ‘admission’, which some implementers are doing with Folders, particularly DIPS in Norway. I suspect that some version of using Folders (or else some kind of tagging, which is semantically equivalent) will be the long term approach to doing this.
We are working on the same lines. As Ethecis does not have folder concept currently, we are doing this minimally outside as a different service.
thanks for the pointer
Regards
I’m used to thinking compositions as semantcally self contained units of information, at the very least using references to other means of expressing semantics (as in terminologies)
What you’re describing seems to take some clincal semantics out of the composion and if we have multiple ways of doing that, it may hurt reusability of queries and data.
Do you think we can find a way of expressing this semantcs without losing its trace within the cmposition?
(Sorry for the typos, on the phone..)
Hi Seref,
I’m not sure I understand your concerns here. I think the use case is where there is a need to group compositions by some other higher level construct which usually reflect something like an admission, episode of outpatient care or perhaps a community plan of care.
As Dileep has indicated he probably would use folders if Ethercis supported them. Another alternative is to create an Encounter ID for each new encounter (which in Dileep’s example, I think I would call an episode of care, and simply tag each composition with that Encounter ID e.g create a cluster archetype to hold this in every Composition/ other_context. I have done that on other projects. So it is a case of looking of all composition with EncounterId = x
Now I would probably go down the Folder route, if I could.
Ian
Hi Ian,
When the fact that the Composition is associated to an encounter or episode of care is recorded by including a reference to that composition in a folder, some clinical context/information related to that composition is now stored outside the composition, by means of a refence in a folder
Unless I’m missing an Aql feature that can help, you can no longer select those compositions via Aql (since Aql does not support/specify how to resolve refs)
If you follow the encounter id approach you mentioned, then you could use Aql.
In fact, if Ethercis had support for Folder, Dileep would still not be able to get those compositions with a singl query: he’d need to fetchs uids from a folder with one query, then perform a second query to get compositions in the way I suggested.
I’m probably being unnecessarily picky here, just pointing at the difference between approaches and trying to put my finger on any downstream issues. I’m not doing a great job of it though 
Hi Seref,
My understanding is that AQL can support FOLDER (assuming it is implemented) with something like
Select c
FROM EHR e CONTAINS FOLDER f CONTAINS COMPOSITION c
Where folder f.name = “My lovely encounters”
but I may be wrong (both in principle and practice)
Ian
But folder does not contain COMPOSITIONS, it contains object refs https://www.openehr.org/releases/RM/latest/docs/common/common.html#_folder_class
You need some aql semantics to resolve those refs to whatever they’re pointing at, which does not exist as far as I know (q: what if object refs are pointing at different types ? )
Contains is only applicable to parent/child/../descendant relationship of object.property paths
The easiest way to think about this question is: if someone trashed the Folder structure, could we (some admin app) rebuild it? The answer is interesting. It should normally be possible to rebuild the Folder / Composition association structure (it’s not containment, just referencing), but of course, if you stored other information in the Folders, for example in the recently SEC-approved other_details structure, then you would lose that.
So the Folder approach does two things:
represents a pre-built query result (the Folder/Composition associations) - giving instant access, and avoiding having to construct the query, which is usually somewhat messy.
allows other information to be stored directly about the thing the Folder represents, e.g. admission / stay in a facility.
thomas
Very interesting discussion that has helped us get some of our thoughts clarified. We have started building a virtual folder as a service outside Ethercis to cover our requirements and are hoping to migrate the structure into the EHR server at a later date.
The plan is to cover both the things mentioned in Thomas’s response. We intend to get a list of compositions associated with a folder from this service and pass it to the AQL to get what we want.
However, I am not sure how to rebuild the folder structure if it is lost. We do not have any folder related information inside Compositions and so the query can only go from folder to the composition and not the other way. Keeping folder details in Composition may not be a good idea as folder is meant to be virtual grouping and can have some dynamism around it. Also same composition can, in theory, be part of multiple folders. There is also the concept of a folder hierarchy that exists only within the folder service.
regards
I cannot imagine how a folder structure can get lost except by data corruption. In that case anything is lost anyway and a rollback from a backup is needed.
In fact there should not be a folderstructure in the database. There are folder objects which contain a list of references (data) to compositions. Not the compositions itself are in those lists. That would not be possible because a composition can be referenced in more then one folder.
But maybe I am missing something
Bert
My point was more about querying aspects. Tom emphasized data integrity aspects.
I think we’ve survived just fine so far without any mechanisms similar to foreign keys in relational dbs that would stop a folder from being deleted, so I’d say go with folders as you intend to.
My concerns can (probably) be handled by smarter Aql down the line.
As far as I understand, and I also implemented it like that, there should never be functionality to delete data. Accidental deletion can only occur when you pass the software and hack on the database directly. That should never occur and if it does, the database should be restored to a safe point in the backup routine.
A folder is a versioned immutable object, that can never be changed or deleted, according the specs, or did I miss a change?
Sorry in that case for my speaking while not being up to date. I don’t read the specs every day.
Bert
Verzonden vanaf mijn Xperia™ van Sony-smartphone
---- Seref Arikan schreef ----
My point was more about querying aspects. Tom emphasized data integrity aspects.
I think we’ve survived just fine so far without any mechanisms similar to foreign keys in relational dbs that would stop a folder from being deleted, so I’d say go with folders as you intend to.
My concerns can (probably) be handled by smarter Aql down the line.
An Encounter (in community medicine) is very much different
from an Episode of Care.
An Encounter happens when patient and healthcare system
"meet" in some way, it is one-off. It can encompass a
multitude of Reasons for Encounter, about different care
targets.
An Episode of Care is a time range during which one
particular care target is handled. It manifests itself during
1..many Encounters, each of which is about 1..many care
targets (problems).
Karsten
Hi Karsten,
ISO System of Concepts for Continuity of Care (ContSys) defines all kinds of concepts related to care and its documentation.
It would be. a good thing to harmonise terms we use.
More info via: https://contsys.org
ContSys is NOT a Data model but a way to define concepts and there relations using UML.
It can/must inform the production of shared archetypes.
ENCOUNTER
Most certainly this is the case when a Healthcare Provider meets the patient and documents the care given.
Meeting can be real and virtual via telephone, e-mail, a third party
But there is an encounter when the HcP interacts with the EHR without a Patient (Virtually) present.
So ENCOUNTER, in my terms, is any interaction of an Author (HcP, Patient, third Party/Proxy) with the Patient Record.
The ISO standard System of Concepts for Continuity of Care uses the term and definition:
contact period- healthcare activity period during which a contact occurs
EPISODE
ContSys defines this as:
episode of care- health related period during which healthcare activities are performed to address one health issue as identified by one healthcareprofessional[
PROBLEM
In addition the term PROBLEM is used in the context of EHR’s.
ContSys has NOT defines this term.
The closest concept in ContSys is:
reason for demand of Care- subject of care or a subject of care proxy’s perception of health needs motivating a demand for care
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands