I had forgotten this, but I think it will turn out to be a syntax equivalent to Seref's proposal. It is probably the kind of syntax man people would like to use, so we should certainly consider it; it maybe that both mechanisms should be put in, and respective users can then argue over who is using 'syntactic sugar' 
- thomas
And I meant to say: can you check if it has a PR, and if not, add one? In either case, you or Seref might add the text from his proposal as well.
- thomas
Karsten,
Out of interest, is there a diagram or other GNUmed documentation / explanation of all this. Itās pretty close to what I think openEHR is or should be doing; you have formalised more of this than we have so far, so itās good to have some reference points available.
Good idea from Sebastian, my three cents to this proposal: Because the other way around would be: A COMPOSITION is REFERRED BY a FOLDER I think āFOLDER REFERS TO a COMPOSITIONā would be better then āFOLDER CONTAINS a COMPOSITIONā For three reasons: The keyword REFERS TO indicates that it is a referral, the keyword REFERS is the opposite form of REFERRED BY, and the keyword CONTAINS falsely indicates that a COMPOSITION would be inside the folder. Bert
I agree with Seref,
So why not use conditions over the Folder.items instead of CONTAINS?
We might need a f.items INCLUDES c operator to resolve direct or indirect references (?)
With indirect I mean via an OBJECT_REF, and direct via an object oriented link in the IM.
That can be even used for CLUSTER.items or OBSERVATION.data.events, or any other collection.
CONTAINS should be just for traversing the tree using ancestor-descendant relationships, including direct references.
I agree with Serefās intention of keeping it clean and clear and most importantly of course consistent.
In this particular case, I think the REFERS idea is worth pursuingā¦to me this sounds pretty fundamental and should be supported without the need for defining an extension/function (in whatever way)
Regards,
Sebastian G.
Hi Seref,
I'm sorry, I interpreted the following quote
"anybody using this function could figure out that it was introduced by a particular vendor"
as a statement that the folder issue should be solved by particular vendors by introducing their own functions. I'm just saying that dealing with folders in AQL "somehow" should be part of the specification. However, I did not express any preferences regarding the solution.
As you seem to agree on this point: sorry for the misunderstanding!
Best,
Birger
Hi Thomas,
classes (and semantics) that need to be supported by the Contains keyword) led to a situation in which two vendors (Marand and DIPS) can claim that they have a valid implementation of openEHR but are not compatible. I can't even tell if Marand (not support Folders at all) or DIPS (using questionable overloading of the semantics) is more right or wrong with their approaches on this matter...
Birger
That is one of the issues with AQL, one thing is to support the syntax, another thing is to have compatible query engine implementations, even if the semantics are correctly interpreted for each operator, data results might differ. But we are also having different interpretations of the operators, and also different levels of support of the AQL syntax itself.
My interpretation of this situation is we are on a starting point of a wider use of the query specs, we will have inconsistencies between implementations and maybe in a couple of years we will have a clear spec for the full AQL syntax (with extensions), the internal query engine architecture, and the result sets.
That would be the case if only the AQL spec were used for conformance testing. But conformance also relies on the RM, ADL and other specs, as you can see here. If you go to 6.2.2 and down to āDirectory Operationsā, you can see conformance tests for Folders. The first step is to make sure all systems implement just the basic structure the same way.
The worst case right now would be that a query that mentioned some FOLDER structure was run in Marand, DIPS, Code24, EtherCIS, EhrServer etc, with different results. This is partly because we have not agreed on how to use Folders (e.g. mark them in a certain way to represent an episode etc), and partly because some systems donāt use them at all. Even systems that do have Folders may not use them in the same way (we know this is true). So Folder is a slight black hole in openEHR which we are actively working on in the SEC to tighten up, so that every implementation uses them in the same way.
The Querying conformance table also needs to be augmented to include Queries that reference Folders. A bit more work is needed to get all of this in place.
Ah I see. Well, in that case we agree 
This is clear to me. However, if we are talking about vendor-neutral platform ecosystems with lots of client applications sharing an openEHR backend, you just need to have (just a stupid guess) ~98% conformance (and AQL is in practice just as important to devs as the more fundamental specs), otherwise it is getting too painful and expensive to change the vendor. Even with small variances in the implementation, you might just create a more friendly looking version of vendor lock-in. I think this is obvious and it is likely I have missed your point. Jap, I agree that every AQL implementation that wants to meet the conformance criteria needs to support folders in a defined way. From my perspective, AQL queries on instances of EHR_ACCESS should also be considered for the conformance criteria, as consent information might also be relevant for querying in analytics scenarios (representation of consent information is something the community might also need to take a closer look at in the future). Birger
HI Ian,
Some definitions from Consys
These are taken from: https://contsys.org
problem: health condition considered by a healthcare actor to be a problem
health problemlist:health thread linking a set of health problems
health issue: representation of an issue related to the health of a subject of care as identified by one or more healthcare actors
episode of care: health related period during which healthcare activities are performed to address one health issue as identified by one healthcare professional[
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
Thomas,
sorry for the late reply.
Out of interest, is there a diagram or other GNUmed documentation /
explanation of all this. It's pretty close to what I think openEHR is or
should be doing; you have formalised more of this than we have so far, so
it's good to have some reference points available.
Some details are in my head, but the big picture on the Wiki,
say, in the User Guide:
http://wiki.gnumed.de/bin/view/Gnumed/GmManualBasicEmrConcept
The reason this aligns fairly well with the thinking
in OpenEHR is that I've been following this list for
far too long
Regards,
Karsten
Contsys will update some definitions. They are now the base of their thinking, but I am sure that will change soon.
Thanks, GĆ©rard, for giving me the opportunity to make my point again.
We donāt call war a peace problem. So why do we call illness a health problem?
Normally I would not mention such a small thing. But the positive naming could be standing in the way of a more holistic view. Healthcare is now about care-for illness. Medicine is not always about healing. It are medieval understandings in the way we still use them.
Healthcare must also be for healthy people
For example, food is important, not only for people with a disease, but also for healthy people so that they do not get a disease.
According businessplans of tech giants, like Google, Amazon, etc, a PHR will contain a holistic view of the consumer (not patient). The PHR will contain data from sport, leisure, diseases, yoga, food, everything related to health. Not only the negative aspects, but all aspects. This change in philosophy of healthcare is taking place quite some time now, but now reaching the upper levels of society.
Preventing diseases will become a major way of spending healthcare money. If insurance companies can keep their members healthy, they are saving money.
If companies do not start to change, they will lose their position on the billion dollar market.
There will be a new business-competition. The patient will become a consumer and will give new meaning to the word healthcare.
Change starts with using words in another way.
Now is the time to start with this. The world is changing fast, and we will change with it.
Verzonden vanaf mijn Xperiaā¢ van Sony-smartphone
---- GF schreef ----
HI Ian,
Some definitions from Consys
These are taken from: https://contsys.org
problem: health condition considered by a healthcare actor to be a problem
health problemlist:health thread linking a set of health problems
health issue: representation of an issue related to the health of a subject of care as identified by one or more healthcare actors
episode of care: health related period during which healthcare activities are performed to address one health issue as identified by one healthcare professional[
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
Thanks Karsten,
Very helpful. Iād suggest one other minor tweak to differentiate āepisodeā which is one or more encounters associated with a particular problem or issue, and āperiod of careā which is administrative idea that roughly equates to an admission or series of outpatient appointments. In hospital care the two are often conflated.
Ian
Agreed. Since GNUmed does not concern itself with documenting
in-patient care it never occurred to us that the time in
hospital most certainly does not necessarily equate to an
episode
Particularly since GNUmed affords documenting hospital stays
(with admission and discharge dates), each stay linked to
episodes of care.
Thanks for pointing that out.
Karsten