Archetype Slots Include - Exclude interpertation

Technical (archive)
1

Hello everyone

How do the "includes / excludes" fields of an Archetype Slot get interperted to conclude with one set of rules about which archetypes are allowed to be attached to a slot?

Browsing through various archetypes i am noticing that some slots will only have one or more "includes" while others have one or more "includes" and ".*" at the "excludes" field.

Are these two fields to be cascaded? (i.e. Include everything that satisfies the include condition and then FROM THE INCLUDED LIST exclude everything that satisfies the exclude condition)

Or would they operate in parallel? (i.e. Get everything that satisfies the include condition, Get everything that satisfies the exclude condition, merge the two sets. The merged set governs what is allowed to be included to a particular slot).

And, are the following equivalent?

"include
  archetype_id/value matches {/openEHR-EHR-CLUSTER\.address\.v1/}
exclude
  archetype_id/value matches {/.*/}"

This means "Include ONLY an address" (?)
In this case it makes sense to evaluate the include/exclude fields in parallel.

"include
  archetype_id/value matches {/openEHR-EHR-CLUSTER\.telecom_details\.v1/}"

(In this case there was no exclude)
This must mean "Include ONLY telecom_details" (?)

A secondary question, is there any case where it might be required to "Include" or "Exclude" an archetype with a condition other than its name / class? I am asking this because the "includes" / "excludes" are Assertions but all archetypes i have seen so far "match" the archetype_id/value only.

Looking forward to hearing from you
Athanasios Anastasiou

2

Hi Athanasios,

see the ADL 1.5 spec section 5.3.9.3 for the rules.

  • thomas
(attachments)

OceanInformaticsl.JPG

3

Hello Thomas

Thank you very much for your response. I missed that one, it's exactly what i am after.

All the best
Athanasios Anastasiou

4

Hello everyone

Coming back to the "archetype slots" issue, the adl 1.5 document specifies three types of slots but i can only see how to define two of them, based solely on the data that become available by the archetypes definition.

I can define the "formal" and "recommendation" ones, but not the "substantive" because (i think) that it is identical to a "recommendation". (Should i be looking at the way the regexp is written as well?)

At the moment:

if (includes is present) xor (excludes is present)
  //This is a recommendation, any "allow archetype TYPE" can match but it is recommended to use the includes / excludes matches.
else
  //At this point the xor has failed but effectively we know that both includes and excludes are present in an assertion
  if (includes == "/.*/) xor (excludes == "/.*/")
    //This is a formal binding

Is the above snippet along the right track?

All the best
Athanasios Anastasiou

5

This code may help - see the function build_slot_id_index from here. It’s eiffel, so easy to read :wink:

  • thomas
(attachments)

OceanInformaticsl.JPG

6

It's eiffel, so easy to read :wink:

I am not familiar with Eiffel so let's just say i am glad you have included that comment in the beginning of the function :smiley:

That last (pseudocode) ELSE is to complement the outer if...right? (or is it the elif?)

Still there's only two cases "formal binding" (i.e. ONLY the indicated archetype) and recommendation (i.e. Anything of indicated TYPE but better if it's one of the indicated archetypes).

If that's the case, maybe rule 3 should be absorbed by rule 1 in adl1.5.pdf p 62 ?

Many thanks
Athanasios Anastasiou

7

It’s eiffel, so easy to read :wink:
I am not familiar with Eiffel so let’s just say i am glad you have included that comment in the beginning of the function :smiley:

back to Pascal / Algol class then :wink:

That last (pseudocode) ELSE is to complement the outer if…right? (or is it the elif?)

hm… some dumb rendering problem to do with tabs i guess. here is the original:

– build slot_id_index in ARCH_REP_ARCHETYPE.
– Current slot logic of include/exclude lists:
– IF includes not empty and /= ‘any’ THEN
– IF not excludes empty THEN – excludes must = any; means not a recommendation
– create match list = includes constraint
– ELSE – it is just a recommendation;formally it means match all
– create match list = all archetypes of compatible RM type
– END
– ELSEIF excludes not empty and /= ‘any’ THEN
– IF not includes empty THEN – includes must = any; means not a recommendation
– create match list = all achetypes - excludes constraint matchlist
– ELSE – just a recommendation; formally it means match all
– create match list = all archetypes of compatible RM type
– END
– ELSE
– create match list = all archetypes of compatible RM type
– END

Still there’s only two cases “formal binding” (i.e. ONLY the indicated archetype) and recommendation (i.e. Anything of indicated TYPE but better if it’s one of the indicated archetypes).

If that’s the case, maybe rule 3 should be absorbed by rule 1 in adl1.5.pdf p 62 ?

I think the text needed some work. How about this:

The semantics of the include and exclude lists are somewhat subtle, and may initially be confusing. The semantics are as follows:

  • The meaning of the ‘set of all archetypes’ in any given environment is evaluatable (and evaluated) to a finite set consisting of all archetypes actually available within that environment, known as the current archetype set, not some notional virtual / global set of archetypes, or theoretically possible set.

  • An include or exclude constraint may be ‘substantive’, i.e. defining a particular set of archetypes that would be matched within a given slot, or ‘open’, i.e. matching all possible archetype.

  • A slot constraint may consist of a single include or exclude constraint, or of an include / exclude pair.

  • If an include or exclude constraint is present on its own, it is understood as a recommendation, i.e. it does not constitute a formal constraint for matching or exclusion, but tools and applications may use the recommended match set in an intelligent way. The result set for such an include or exclude is the whole current archetype set.

  • If a substantive include or exclude constraint is present with a corresponding open exclude or include, respectively, the substantive constraint is considered formally binding.
    BTW, these lexical rules are historical, and will be obsoleted one day - I more or less had to construct them after 100s of archetypes that actually assume these rules had been built! You will see further down in the ADL 1.5 text an indication of the future, but for today, we are stuck with the above…

  • thomas

8

Hi Athanasios,

From a clinical modelling perspective, we have found that it is extraordinarily difficult to set tight constraints on archetype slots

The general approach is to include a number of suitable candidate archetypes as recommendation but to leave the exclusion constraint open. Where we have set a specific inclusion + exclude all others, I would largely expect this to be replaced by actual slot-filling in ADL1.5.

Ian

9

> It's eiffel, so easy to read :wink:
I am not familiar with Eiffel so let's just say i am glad you have
included that comment in the beginning of the function :smiley:

back to Pascal / Algol class then :wink:

That's definitely not similar to Pascal! If i was to be sent back to a class for this, better make it Eiffel directly :slight_smile:

That last (pseudocode) ELSE is to complement the outer if...right? (or
is it the elif?)

hm.... some dumb rendering problem to do with tabs i guess. here is the
original:

-- build slot_id_index in ARCH_REP_ARCHETYPE.
-- Current slot logic of include/exclude lists:
-- IF includes not empty and /= 'any' THEN
-- IF not excludes empty THEN -- excludes must = any; means not a
recommendation
-- create match list = includes constraint
-- ELSE -- it is just a recommendation;formally it means match all
-- create match list = all archetypes of compatible RM type
-- END
-- ELSEIF excludes not empty and /= 'any' THEN
-- IF not includes empty THEN -- includes must = any; means not a
recommendation
-- create match list = all achetypes - excludes constraint matchlist
-- ELSE -- just a recommendation; formally it means match all
-- create match list = all archetypes of compatible RM type
-- END
-- ELSE
-- create match list = all archetypes of compatible RM type
-- END

Thank you

Still there's only two cases "formal binding" (i.e. ONLY the indicated
archetype) and recommendation (i.e. Anything of indicated TYPE but
better if it's one of the indicated archetypes).

If that's the case, maybe rule 3 should be absorbed by rule 1 in
adl1.5.pdf p 62 ?
*

I think the text needed some work. How about this:

The semantics of the include and exclude lists are somewhat subtle, and
may initially be confusing. The semantics are as follows:

  * The meaning of the ‘set of all archetypes’ in any given environment
    is evaluatable (and evaluated) to a finite set consisting of all
    archetypes actually available within that environment, known as the
    /current archetype set/, not some notional virtual / global set of
    archetypes, or theoretically possible set.
  * An include or exclude constraint may be ‘substantive’, i.e. defining
    a particular set of archetypes that would be matched within a given
    slot, or ‘open’, i.e. matching all possible archetype.
  * A slot constraint may consist of a single include or exclude
    constraint, or of an include / exclude pair.
  * If an include or exclude constraint is present on its own, it is
    understood as a recommendation, i.e. it does not constitute a formal
    constraint for matching or exclusion, but tools and applications may
    use the recommended match set in an intelligent way. The result set
    for such an include or exclude is the whole current archetype set.
  * If a substantive include or exclude constraint is present with a
    corresponding open exclude or include, respectively, the substantive
    constraint is considered formally binding.

I think it's clearer.

BTW, these lexical rules are historical, and will be obsoleted one day -
I more or less had to construct them after 100s of archetypes that
actually assume these rules had been built! You will see further down in
the ADL 1.5 text an indication of the future, but for today, we are
stuck with the above...

Oh joy. (Yes, i did notice that part in the text, it will make the constraint more strict but inserts yet more parsing).

Is there a single BNF description of ADL 1.5 available from somewhere?

All the best
Athanasios

10

Greetings,

Is there a single BNF description of ADL 1.5 available from somewhere?

I think the Eiffel project has a grammar in some form, but it was kinda scattered around
I remember talking to Tom about something like this.

A BNF description would actually be a good exercise for Antlr work :slight_smile:

Kind regards
Seref

11

yep, they are here - fairly standard .y and .l files.

  • thomas
12

Thank you very much Thomas. That's not really what i had in mind, but still, usable :slight_smile:

Wow, i have not tried this but as it seems "YoU cOuLd ReAlLy Do ThIs"...Since arcethypes are human readable, maybe it's better to have ADL be case sensitive (?)

All the best
Athanasios Anastasiou

13

Dear all

I am coming back to this issue of interpreting and following Archetype Slots with a simple (i hope) question.

How are we supposed to handle cyclic references created by Archetype Slots?

There are quite a few places where cycles might come up, first of all, getting the RM from the AM, building the GUI and finally even up to the complex issue of creating and executing queries.

As we clarified earlier there are mainly two flavours of slot binding: a) Formal,
b) Recommendation

My understanding of the "Formal" slot binding is that the slot would have to be filled explicitly by one of the archetypes that are determined by the include / exclude criteria.

In most of the cases of the archetypes that are available through the CKM*, the formal binding does not lead to any cycle formation.

However, it is much easier to create cycles with a "Recommendation" type.

For example, i can specify something like this:
A->B->A

That is, [...an archetype (of some kind A) including a slot that accepts a generic archetype (of some kind B) including a slot that can accept...]*

And that's the shortest cycle that would create a problem...It is of course possible that longer cycles could emerge unknowingly to authors as the archetype creation process proceeds by various teams independently.

Therefore, what i would like to ask is the following:

1) Is there a recommendation for avoiding cycles? (For example, one could say that "you can't attach an archetype of the same or higher level (of datatype) to a slot". In this way, a CLUSTER would only be allowed to reference ELEMENTs. This is guaranteed to lead to a tree but reduces the flexibility of the model)

2) Is this kind of reference something to be expected when modelling clinical data? (In other words, it's actually a use case and you can't prohibit it, so you have to watch for it)

3) While creating the RM / GUI / other artifact, am i expected to follow all links exhaustively in order to create a Tree through which i would first detect cycles, resolve them and THEN create the final version of the RM?

(Please note, "fudging" this, by resolving slots lazily is not an option :-). For example, i could create a GUI with all available information and a "Fill This Slot" button at the slot. Once you click the button another form is created which collects the data for the attached archetype. In this case, the algorithm did not hit a "loop" but the user eventually will because "new buttons" for filling in data will keep coming up in new forms.)

Looking forward to hearing from you
Athanasios Anastasiou

*: My XML parser (built out of the openEHR XSDs) kept complaining about the structure of a few XML files downloaded from the CKM, therefore, it was not possible to include all of them to this "cycles" investigation.

14

Dear All

I hate this when this happens, but still, i forgot to attach this SVG file to my previous message that might be helpful. This is showing the interactions between all archetypes that i have examined so far (that is, any that fall within the category "Formal" where no "cycles" exist)

All the best
Athanasios Anastasiou

(Attachment openEHR_formal_G.svg is missing)

15

Hi Athanasios,
I have a feeling that you’re facing a problem due to your particular implementation approach. I can’t fully understand your problem, but it sounds like you’re doing everything based on archetypes.
Remember that you also have templates. Almost everybody instinctively writes code that walks archetypes and creates GUI during runtime, when they first start working with openEHR. It almost sounds like you’re doing something like this.

If you can explain the specifics of your problem with a little bit more detail, it would be easier to help.

Kind regards
Seref

16

Hi Athanasios,

I would agree with Seref. Remember that we largely use templates to resolve when and how slots are actually filled in real use. Even when slots are left open and filled at run-time this is going to be for specific uses, rather than some sort of algorithimic slot-filling.

There are rules about what slots are allowed, defined by the RM.

Compositions
→ Sections
→ Entries

Sections
→ Sections
→ Entries

Entries
→ Clusters
→ Elements

Clusters
→ Clusters
→ Elements

17

Hi Athanasios,

I have to admit, my initial reaction is that this a theoretical CS problem that never occurs in practice, because the choosing methods for slot fillers are normally clinically aware (assuming they are not already prevented by RM type violations). This makes me think that you are doing some highly automated potential slot-filling algorithm that tries to guess all possible data paths allowed by the slot definitions. When you get down to CLUSTERs, things could in theory become recursive, leading to graph cycles.

If this is the case, I think it is dangerous with the current slot semantics. The slot semantics that are being defined for ADL/AOM 1.5 are much safer, being based on concept subsumptions rather than on lexical matching. Therefore, for now, I would avoid any overly mechanistic approach to trying to generate out possible data constructions because the needed information is not in the current slot definitions.

  • thomas
(attachments)

OceanInformaticsl.JPG

18

Hello Seref

Based on my own experience with Opereffa, I can tell you that I had a
heavy emphasis on Archetypes too.
It is correct that you need to work with AM to do anything with
archetypes, but are you sure that what you're trying to do has something
to do with archetypes? :slight_smile: This is the tricky bit.

>

Validation, source code generation, GUI generation uses AM, but even
this usage would mostly happen at the template level.

Alright, i think i see what you mean, so let's get this straight:

1) You define Archetypes as re-usable elementary data types. For example, i can define an Archetype that describes all the necessary pieces of data that a clinician would collect / require to describe an observation. Archetypes (to an extent) can be seen as "elements of forms". (and of course, elements of other archetypes)

2) You define Templates as re-usable compositions of Archetypes that roughly correspond to forms. Because of this, they have some extra elements, such as SECTIONs.

In any case, i have to go from the AM to the RM and from the AM to the GUI (and back). Therefore, whether it is an Archetype or a Template, i HAVE to parse and make sense of it.

If the above are "true" then "Yes, what i am trying to do has something to do with Archetypes".

I acknowledge having very little experience with actually building the Archetypes themselves (working on it though :slight_smile: ) and no experience at all with building (and handling) Templates.

What I've learned
after hitting my head against my own creation many times, is application
development is very much about templates. I think there are more than
one cases where one may face cyclic references and related issues. Some
issues reveal themselves when using a particular method of
implementation, such as the recursive-reflective tree walking approach,
and the others may be in the model where nodes refer each other in a way
that'd cause issues no matter what the implementation approach is. I was
probably wrong about your case, you were referring to what Thomas has
mentioned.

I do not see how different implementations would deal differently with the model branch of "ARCHETYPE_CONSTRAINT". Whether you do it recursively or non-recursively, if you have to follow an ARCHETYPE_SLOT, you could run into cycles (so, it's good to have all these extra constraints, lowering this probability). I am sorry if i don't "get it". (Happy to discuss it off the list if you like)

All I'm going to say is, for application development purposes, do not
focus too much an Archetypes. AM and templates is where you'd like to be
for that. Take a look at template designer, which is available to
everyone, and try to think in template terms for your development. That
is where you're going to end up anyway.

Yes, point taken, will do :smiley:

All the best
Athanasios Anastasiou