AQL on specific list of compositions

Technical (archive)
21

Hello Gerard,

ISO System of Concepts for Continuity of Care (ContSys) defines all kinds of concepts related to care and its documentation.

I (GNUmed, that is) agree with the definitions you refer to.

I was answering to Ian's input:

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

which seemed to me to equate Encounter with Episode of Care.

But I may have misunderstood Dileep's example.

Karsten

22

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.

It's a thought experiment, not a serious proposition about a real system. But it partially answers the question: what is in an EHR? If Folders contain some extra information that can't be reconstructed by running specific queries, then probably the Folders are a first order part of the EHR rather than just an optimising data structure.

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.

There can be a Folder structure (= hierarchy of Folders), even though (as you say) Folders only hold refs to Compositions, and more than one Folder can point to the same Composition.

- thomas

23

This is how I understand it as well, just in the interests of avoiding confusion, so a Folder solution as described above is for episodes of care, within an institution, or something that functions like an institution, and where there is internal continuity of care, e.g. an integrated area or city health service.

  • thomas
24

Some of these Contsys definitions are problematic:

that would certainly be a subversion of the usual meaning of ‘encounter’ (literally ‘to meet’) in English and all the latin languages at least… (in Portuguese and Brazil health system, the word is ‘atendimento’, i.e. attendance… - probably the same in Italian and Spanish). It would be better ontologically to call such an event something else - in openEHR it is a commit of a Contribution. There are also other health system actions with the patient absent, e.g. doing lab work on tissue samples - also real ‘work’, but not an encounter. I would suggest that most people think an episode of care is not limited to one HCP, and is not always limited to one health issue, even if there is usually one main ‘problem’ on admission. An episode of care is usually thought of as care to resolve an issue for a patient by a team of HCPs working in an integrated environment, e.g. a hospital. If the resolution of the issue requires care that crosses institutions (usually the case), then a different term is probably needed for that. - thomas

25

Thanks Thomas,

What are your thoughts on the AQL example I foolishly guessed at :frowning: and that Seref quite correctly rejected!!

How would/should we do…

Select all compositions referenced by Folder x.

How else might we meet Dileep’s use-case with AQL?

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnicoll@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

26

@Gerard - I have always assumed that Contsys ‘Health Issue’ equates to problem.

https://github.com/openehr-clinical/shn-contsys

Ian

27

Well if you have access to a Folder, you don't need to do an AQL query, you can just retrieve the Folder structure and recurse through it, picking up direct refs to VERSIONED_COMPOSITIONs.

Creating Folders from the data on the other hand requires writing some queries that look for admissions and discharges, matching them up, and generating a Folder for each pair, named after the institution and/or dates of the stay. A bit messy, but not hard to do, if one wants to post hoc add Folders to 'old' EHRs that never had them.

- thomas

28

Yup but AQL is so cool for this kind of thing :slight_smile:

I still want to do

Select c FROM EHR Contains folder x contains composition c

since logically folder x contains compositions.

Ian

29

You’re (unintentionally) circling back to discussions re AQL in the last SEC meeting in Slovenia (I was sitting in remotely)

What you’re asking for can be accomplished in a number of ways at the AQL level, all of which would require changes to AQL specs and implementations. I’m always happy to discuss these but I suspect it deserves its own thread :slight_smile: Hint for subject: How to resolve object references with AQL?

All the best
Seref

30

Some of these Contsys definitions are problematic:

> ENCOUNTER
>
> But there is an encounter when the HcP interacts with the EHR without a
> Patient (Virtually) present.

that would certainly be a subversion of the usual meaning of 'encounter'
(literally 'to meet') in English and all the latin languages at least... (in
Portuguese and Brazil health system, the word is 'atendimento', i.e.
attendance... - probably the same in Italian and Spanish).

It would be better ontologically to call such an event something else - in
openEHR it is a commit of a Contribution.

I agree. In GNUmed we tend to think of this as a "session",
in quite a technical sense, between the technical system and
_a_ ("one"-party, where one is by purpose, not by number) actor.

So, a tumor board meeting is a session, as long as the
patient (or a non-staff guarantor) is not present.

Perhaps it's the difference between ABOUT the patient as
opposed to WITH the patient.

A session is the frame within which the commit of a
Contribution occurs.

An encounter does need a session (implicit or explicit) in
order to technically manifest itself. But a session does not
need an encounter.

Waters get muddy when patient and system are involved only,
due to information asymmetry: What if the patient interacts
with the system and the system is programmed to reinforce
adherence. Patient types into a "Question: ___________" GUI
field: "Should I continue this medication ?" And the system
answers:

  Generally, you should continue as previously decided.
  However, if you see fit to rethink that decision would you
  like to:

  - leave as is
  - revisit the previously documented decision details
  - decide something else now
  - contact a HcP now
  - book an appointment

I would suggest that most people think an episode of care is not limited to
one HCP, and is not always limited to one health issue, even if there is
usually one main 'problem' on admission. An episode of care is usually
thought of as care to resolve an issue for a patient by a team of HCPs
working in an integrated environment, e.g. a hospital. If the resolution of
the issue requires care that crosses institutions (usually the case), then a
different term is probably needed for that.

In GP land it feels more helpful to think of Episodes of Care
to relate to one "issue", "problem" each. Several episodes -
about currently-thought-to-be-different issues can overlap.

In GNUmed we over-arch episodes of care with "health issues".
Each health issue can have several (non-overlapping) episodes
over time. Each issue can be thought of to have several
episodes (technically) going on at different institutions
concurrently.

Each problem manifests as a thread, an episode of care for
that problem, running through one or several encounters. Each
encounter can interweave several threads. Each problem may
become identified to belong to a particular health issue, an
underlying "cause".

IOW, episodes and encounters are orthogonal in nature.
Problems are the labels of episodes. Health issues are the
containers for potentially several episodes.

At least in GNUmed.

Karsten

31

that would be possible if we modify the meaning of the CONTAINS operator to mean contains-by-value (like ENTRYs inside a COMPOSITION) or contains-by-reference, which is the FOLDERs case - as you have long argued :wink:

Not hard technically as far as I can see - but it does mean a modification to all existing AQL implementations, and of course AQL itself.

  • thomas
32

@ian – we have implemented the query you wrote:

“select c from EHR e contains FOLDER f contains COMPOSITION c where c…..”

You might even write:

“select c from EHR e contains FOLDER f contains FOLDER child_folder contains COMPOSITION c where c…..”

We made a restriction such that the COMPOSITION c MUST be referenced in FOLDER f and not any sub-folder. This was needed to avoid circular references and explosion in the result set.

Vennlig hilsen
Bjørn Næss
Product owner
DIPS ASA

Mobil +47 93 43 29 10

33

Hi,

There is ample reason to reconsider the use and need for folders.

There is a need for holding/collecting structures.
The RM has several places where data can be collected:

  • Folder
  • Composition
  • Section
  • Entry
  • Cluster

For what purposes?
What contributes to the meaning, the semantics?
What is for aiding the author / reader managing the data?

Gerard Freriks
+31 620347088
gfrer@luna.nl

Kattensingel 20
2801 CA Gouda
the Netherlands

34

Thanks Bjorn

That feels logical and the restriction to one layer of folders make sense. I appreciate that under the hood ‘CONTAINS’ is implemented differently but it feels natural to think in terms of logical containment.

Ian

35

@Bjorn and @Ian both: I don’t think this is a good idea. This example overloads the semantics of CONTAINS operator of AQL for a very specific scenario: when the object reference is a reference to a composition and the reference sits under folder F, which btw should not be a folder contained in another folder. Based on the second Example from Bjorn, It looks like CONTAINS also (silently?) resolves the reference of its parent’s parent (f) which is another overload of its very core definition.

This is not standard AQL, even though AQL is probably the most variable spec in openEHR in terms of its implementation across vendors. I know different vendors come across different requirements at different times and our individual solutions to those slowly make it into the standard so there is always a window during which a feature is available from a vendor but still not in the spec but this can be problematic at times.

As I said in the past in numerous occasions: I think the robust way to deal with these type of edge cases is to leave the core semantics of AQL alone as much as possible and use extensions such as functions. Something like

SELECT resolve_folder_comps(f/items) as compositions_under_folder FROM EHR e[$ehrId] CONTAINS FOLDER f[..]

would encapsulate the specific case into resolve_folder_comp function’s definition and semantics. Anybody using this function could figure out that it was introduced by a particular vendor, see its documentation, read its limitations such as the root folder requirement for f etc etc.

Pretty soon, we’ll have a REST spec which the vendors will have implemented, with API calls to run AQL queries. If those queries do not work across REST deployments of Ocean, DIPS, Marand, Code24 etc how on earth we can claim we have a unified way of retrieving data that works consistently across systems?

My suggestion above my be faulty and I’d be delighted to hear objections and suggestions for alternatives but let’s please try to not to lose the big picture when working on AQL: it is going to be a huge value added of openEHR in near future and its portability matters a lot. I tried to make this point in a more subtle way in my previous messages but I seem to have failed, hence: this rather blunt response I’m sending with good intentions only.

All the best
Seref

36

Hi Seref,

while I understand your argument regarding overloading of definitions (and I agree with your reasoning), I see a clear need to not treat folders as second class citizens in openEHR. Not including Folders in the official AQL spec and leaving this to vendor-dependent functions will not be helpful to allow portability. Especially, as the use of folders (especially when it can contain data in an ITEM_STRUCTURE) is becoming a common pattern to represent episodes of care.

Cheers,

37

Hi Birger,

Note that no openEHR RM types (COMPOSITION etc) are part of the AQL spec - they are just used in examples. AQL doesn't actually know anytthing about particular types. Seref's intention is that it stays this way, and his proposed function, or some other equivalent resolver mechanism would be a generic addition to AQL that would, for openEHR structures be used for FOLDERs containing refs to COMPOSITIONs (actually VERSIONED_COMPOSITIONs), and also any other similar situation (e.g. in the demographic model).

- thomas

38

You’re missing my point. To express it in your terms: this is not about excluding Folders from AQL spec, I said nothing of that sort or implied it anyway. AQL does not include or exclude individual RM types, it addresses all of RM and it is either consistent or not consistent across all of RM, period.

Contains statement works over folders but folders do not contain compositions, they contain references to compositions (and to other things if necessary) by design. Contains not returning compositions ‘referenced’ under folders is not excluding folders from aql: on the contrary, it is AQL working as intended on an RM type.

What is suggested here would make it inconsistent due to special cases. I’m suggesting a way to preserve consistency and providing the functionality that is requested. That is a win-win. There may be better ways of doing it, but overloading the contains operator is not one of them due to reasons I explained.

All the best
Seref

39

Hi Seref, Thomas,

On the last SEC meeting, another proposed idea (besides the one from Seref) was to use REFERS or REFERRED BY instead of CONTAINS - but it we did not explored further on. Could this still be considered in these discussions?

Sebastian I.

40

Hi Sebastian,

Sure, that is another way of dealing with the requirement of resolving object references. Every time we discuss new features like these for AQL, we’re basically looking at a choice between small language with libraries vs large language with richer native semantics. (e.g.: Java is former and C# is latter)

My inclination is usually towards small language option or at least keeping functionality in libraries and later promoting them to language syntax if they become features used frequently. The REFERS option presents no semantic ambiguity so it is not subject to my previous criticism.