Slots, naming and merging

Overview

Slots, or archetype slots are statements within archetypes that other archetypes may (or must) be included at this point in the composition. They are constraint statements about what might be sensible to add at that particular point. Clearly the reference model itself is constrained - sections can only contain other sections or entries, tree structures can only contain clusters or elements and lists only elements. Slots go beyond these limits to say what archetypes are sensible to add at this point - but the archetypes must be of the appropriate sort (so a cluster element is only allowed to be added within an entry for example).

NOTE: most of the problems described below are now dealt with in detail here.

Multiple slots - how to represent them?

Slots have to express the reference model class that is allowed at that point - eg an OBSERVATION or an EVALUATION. Early in the development of templates it became clear that adjacent slots for OBSERVATION and EVALUATION (2 slots were required to express the mix of content allowed) meant that all the OBSERVATIONs had to be held in one slot and all the EVALUATIONs in another slot. The solution taken at that time was to merge adjacent slots into a single slot, while maintaining the constraints (ie only valid content could be added). This allowed ENTRYs to be added in any order - ie you could mix and match the OBSERVATIONs and EVALUATIONs. This achieved what was required.

Later, with CLUSTER slots within an ENTRY, a new problem arose. Two or more slots remain discreet in the Template Designer but have overlapping constraints. Archetypes added to one slot at design time, if they were legal content of another slot expressed in the archetype at the same level in the hierarchy (same ..\items path) but standing before the desired slot, would be added to the first slot. The insert_at_path did not discriminate between slots at the same level.

Naming slots

At the same time, the clinical modellers were requesting the ability to name slots - have labels that meant something to the clinicians and indicated what was going in there (rather than just a regular expression of the valid archetype ids). Naming slots is legal in ADL - but slots themselves do not appear in the data (they are just constraint statements of containers). This is now implemented in the Archetype Editor (Daily release) and it does offer a solution to the problem of multiple slots - now we have named slots so we can locate them.

If we have a slot with the name SLOT_1 and an ATCODE at0001 then, at the level of the archetype, we could see the path \itemsat0001 as the path to that slot. This is NOT a data path, but it is an archetype path. This does get over the problem, potentially of knowing which slot to add the item to when building the data at runtime (and also rebuilding the template at design time). It does not get over the problem of what to do when we want to mix and match archetypes from different classes (the norm in sections).

Generic classes

The final piece of this jigsaw is that the reference model needs to have abstract classes at every level that include all types of legal contained classes. So at the level of the CLUSTER for instance, the items attribute is a LIST<ITEM> where ITEM is the superclass of CLUSTER and ELEMENT. If we want to mix and match CLUSTERs and ELEMENTs, we have the opportunity to make the reference model class type ITEM rather than having two slots, one for CLUSTER and one for ELEMENT.

Summary

The combination of generic types for the Reference model type (eg CONTENT_ITEM, ENTRY, ITEM) of slots and naming of slots provides us with everything we need at the moment to provide the sort of functionality from slots that is required.