Specialisations on SLOTs

Noting from the specs "An archetype is a specialisation of another archetype if it mentions that archetype as its parent, and only makes changes to its definition such that its constraints are ‘narrower’ than those of the flat parent. "

Are the nominated included archetypes part of the ‘definition’ of the SLOT?

The use case example is a parent archetype that contains 3 nominated archetypes as suggested or preferred SLOT-fillers. Think of a modelling situation like the large family of specialisations that will gradually evolve for the CLUSTER.exam family of physical examination archetypes - we could end up having a hundred specialised archetypes. However, imagine a situation in which the included SLOT-fillers work for most, there is a single specialised concept for which one of the 3 nominated SLOT-fillers are either inappropriate or even clinically unsafe (a one out of 100 is effectively an outlier).

At present, to add an additional (proposed, potentially useful, but not definitional) SLOT-filler in current tooling requires specialisation of the SLOT. Is this correct?

And, even more importantly for our modelling use case, is it possible to remove the proposed, potentially dangerous SLOT-filler from the single child outlier?

Given that the SLOT-fillers are not definitional, but essentially only suggestions for good modelling practice, or even considered as design advice, it seems to me that the normal specialisation rules should not apply to the include contents of the SLOT, but are rather providing supporting information much like the Purpose, Use etc.

[Note that I’m also mindful of the opposite that opening a SLOT closed in a parent should comply with the specialisation rules.]

If the SLOT-fillers are considered definitional, then my modelling nightmare is to remove the suggestions added to the parent SLOT in the use case above from all and add the relevant includes manually to each one of the relevant 99 children in the example above, and omitting the relevant include on the one where it is unsafe.

Thoughts?

Regards

Heather

1 Like

They are in a technical sense, but the current semantics is that any mentioned archetype is just a ‘suggestion’, unless all other archetypes are excluded, in which case the mentioned archetypes are treated as a strict part of the definition.

So the semantics are as follows:

  • slot fillers are a suggestion => computationally, any archetype (of correct RM type) can go here => specialised archetype can do what it wants, since anything goes anyway. We potentially should only allow narrower suggestions (a subset)
  • slot fillers are strict (exclude is being used) => only those archetypes or their specialisation children can fill the slot => specialisation of this archetype can only narrow its slot, i.e. reduce the mentioned archetypes to a subset.

The reason for the ‘narrowing’ rule is that data created according to child archetypes have to be valid with respect to parent archetypes as well - e.g. imagine you created a specialisation of archetype X specific to your clinic where you are doing some research, call it X.1. You create some data using X.1 (via an app your IT devs made), and then you send that data (for typical reasons, e.g. referral) to another place. Let’s assume every place has X archetype, but of course they don’t have the X.1. So it is essential that X.1 created data must be valid against archetype X. This can only happen if X.1 constraints fit inside the constraints of X. (You know all this of course - this explanation is mainly for new readers).

The first question is how we really want to specify slot fillers. Doing it with regexes on ids is not scalable, as we have recognised for years. The correct way to do it would be the same as constraining a terminology subset. So for example, we could:

  • define the slot to be ‘any child archetype of CLUSTER.exam’

That means as you keep adding new CLUSTER.exam children, they all become automatically usable in that exam slot.

Now imagine in some archetype X, you want a slot with pretty much all the CLUSTER.exam children except the ears/nose/throat (randomly choosing) ones. This would need a slot definition of the form:

  • define the slot to be ‘any child archetype of CLUSTER.exam except E, N, T, …’ i.e, a constraint that includes exceptions, including whole subtrees.

This is no different from defining a terminology subset = all blood types except Rh blood types or similar.

There are more possibilities, like allowing disjoint subtrees (e.g. any CLUSTER.exam OR any CLUSTER.symptom) - you probably remember from the Ocean Terminology Server.

We can’t quite do this kind of slot constraining with the current slot definition - it would need a ‘semantic slot’ constraint type. This has been on the drawing board for a long time.

Theoretically, we could use the current means of defining slot constraints to mention in the includes some id pattern that would match any CLUSTER.exam(-*) i.e. any CLUSTER.exam child, and in the excludes, put the pattern to match the archetypes that are not allowed.

According to the current ADL2 rules (which I think are now being applied by tools to ADL1.4 archetypes) this is not allowed - you can only put a pattern match in include and then set exclude to match everything (i.e. .*), or the other way around.

If your exclude scenario isn’t a burner for right now, you can probably just get by with the current recommendation semantics of slots. That would give us time to introduce a proper semantic kind of slot that would support the above semantics.

we definitely want to avoid such things! Allowing child archetypes to narrow slots incrementally down the specialisation hierarchy is something we can support with a smarter kind of slot constraint.

NB: I am not 100% sure of the current slot handling semantics in the tools today, but that ADL2 definition linked above is what was agreed last time I discussed the topic with the clinical modelling group some years ago.

OK. I think I hear from this answer that I can do whatever I want with the SLOT includes, so the current constraints in the tooling are the problem, not the specs.

I will go wild and hack the ADL accordingly.

While supporting the ability to make smart semantic statements about the possible includes in SLOTS is a nice idea, it is unusual for us to want to use this as a general pattern. Mostly I want to demonstrate a design pattern that you can sensibly nest ‘Exam of a pupil’ inside ‘Exam of an eye’ and that in turn is nested within ‘Exam of both eyes’ and leave the rest of the SLOT unconstrained for any CLUSTER archetype that the clinician thinks relevant, whether a specialisation of the same family or not.

A current use case is the evolving specialisation family of Imaging examination CLUSTERS - see the evolving Imaging project. Following the Physical exam pattern, specialisations of CLUSTER.imaging_exam (for each body structure or region or abnormality) can be nested inside the OBS.imaging_exam_result. But it is not always about nesting specialisations within the CLUSTER.imaging_exam family. For example, CLUSTER.fetal_biometry is intended to be nested within CLUSTER.imaging_exam-fetus - I can’t imagine it being used anywhere else, but we won’t stop it if it is clinically useful. Or the universal ‘get out of jail free’ CLUSTER.imaging_finding to record details about a significant clinical finding identified by radiological imaging techniques, not otherwise modelled in specific imaging examination archetypes per body site.

2 Likes

One thing to keep in mind is that sometimes you are nesting (in ADL2, = a direct reference to the sub-part archetype, no slot needed) archetypes just because the sub-part already exists, or someone decided to cut the archetypes up that way. THere may be no slot need, and had you been modelling in a vacuum, you would have just made one big OBS or EVAL archetype with some particular CLUSTERs inside.

If the slot-filling / nesting really is like this, I would actually make it strict, to indicate the intention properly, rather than always hedging your bets. It’s nearly impossible to get this 100% right of course, and IT people struggle with exactly the same thing in software.