Introduction
In ADL 1.4 and lower, the idea of a 'slot' is a joining point from one archetype to another, similar to the idea of an 'association' or 'aggregation' relationship in UML. It is usually defined by a constraint on archetype identifers, although other kinds of constraint can be used. In the openEHR 'template' concept, slots are normally 'filled', in order to create large aggregate structures, such as whole COMPOSITIONs.
...
This page discusses the requirements as we understand them today, and an improved semantics for slots that should satisfy these needs.
Modelling Background
In ADL, constraints are stated for an attribute in terms of:
...
A 'slot' is one kind of object constraint, and has the meaning 'archetypes that match this constraint may go here'. A typical use of slots is shown below:
| Code Block |
|---|
SECTION[at0000] matches { -- SOAP
items cardinality matches {0..*; unordered} matches {
SECTION[at0001] occurrences matches {0..1} matches { -- S
items cardinality matches {0..*; unordered} matches {
allow_archetype OBSERVATION[at0006] occurrences matches {0..1} matches { -- Subjective observations
include
archetype_id/value matches {/.*/}
}
allow_archetype SECTION[at0007] occurrences matches {0..1} matches { -- Subjective sections
include
archetype_id/value matches {/.*/}
}
}
}
....
}
|
...
- a container attribute may have more than one slot definition, each standing for a different set of possible included archetypes;
- a single-valued attribute could also have multiple slot definitions, each standing for alternatives;
- slot definitions can be mixed with non-slot object constraints;
- the concept of 'filling a slot' is somewhat of a misnomer. In fact it is not the slot being 'filled', it is the containing attribute, which might contain more than one slot definition.
- A slot filler object does not necessarily correspond to a single object - in general it acts like any other constraint due to occurrences being e.g. 0..*.
Requirements
Slot-related requirements known for archetypes include the following.
...
- T1: basic filling: templates specify one or more 'fillers' for a slot (but see notes above).
- T2: complex ordering and occurrences: see bottom of this page herefor an example.
- T3: open/closed: ability to fully specify or leave open an attribute. This means that even if filler archetypes are specified, the author might want to allow those archetypes not to be used at runtime, instead allowing different archetypes that still fit one or more of the available slots in the attribute to be chosen at runtime. In this case, the filler archetypes can be understood as 'recommendations'. On the contrary, if the attribute is defined such that no further fillers could be used, the combined object constraints can be understood as 'required' archetypes.
- T4: ordering: ordering of slot 'fillers' should be independently constrainable from the definition of the slots.
- T5: a template can include another template in a slot rather than an archetype.
Solutions
There are various new elements that help provide a complete solution:
- Use of structured archetype slot specifications rather than archetype identifier regular expressions.
- Archetype references: the ability to directly refer to another archetype from with an archetype, without using a slot definition;
- Use of specialisation semantics: a slot definition can be specialised into both or either of a narrower slot definition, or one or more archetype references that fit the slot. This allows archetype references can be used as slot-fillers;
- Use of select construct: Use of 'select' construct to support more complex ordering and occurrences requirements (see this page here)
Structured Slot Definition
One of the key things we need to fix is how slots are actually defined. Currently, slots are defined as regular expressions on lexical identifiers. There at least three difficulties with the use of regular expressions in this way:
...
In fact, what we need is a way of separately matching the various parts of an archetype id, and especially for the concept part, some ontological operators. One reason this is needed is that in the future, if the recent governance and identification proposalsare taken up, the concept part of an archetype id will be weakened so that it no longer has to reflect the specialisation relationships of an archetype. The following example shows how such a constraint could look in ADL:
| Code Block |
|---|
allow_archetype CLUSTER[at0004.1] occurrences matches {0..1} matches {
include matches {...} -- C_BOOLEAN
archetype_id matches {
ARCHETYPE_ID matches {
namespace matches {...} -- a C_STRING
qualified_rm_entity matches {...} -- a C_STRING
domain_concept matches {...} -- a C_CONCEPT
version_id matches {...} -- a C_STRING
}
}
}
|
...
These kinds of operators are typical within the ontology / terminology world, but do not currently exist in openEHR ADL. One idea here would be to use the SNOMED constraint operators as syntax, as follows:
Symbol | Meaning |
|---|---|
= | This concept only (note, SNOMED uses no operator here, but it may be easier if we do in ADL, since it will alert the parser to a 'concept' match expression rather than some other kind of expression). |
<< | This concept or any subtype permitted |
< | Any subtype of this concept (but not the concept itself) |
Note that in another proposal, the concept part of an archetype id will be weakened so that it no longer has to reflect the specialisation relationships of an archetype. The following example shows how such a constraint could look in ADL:
| Code Block |
|---|
allow_archetype CLUSTER[at0004.1] occurrences matches {0..1} matches {
include matches {True}
archetype_id matches {
ARCHETYPE_ID matches {
...
domain_concept matches {<< investigation_methodology}
...
}
}
}
|
In the above, 'investigation_methodology' is a concept identifier within the archetype definitional space, and the << operator indicates that this concept or any subtype (i.e. specialised form) is to be allowed. Using this approach, it does not matter what the concept names of archetypes are, only how the specialisation relationships are constructed.
Semantics of 'include' and 'exclude'
In ADL 1.4, the semantics of the include and exclude parts of an archetype slot are not well-defined. A given slot can (and often does) use both 'include' and 'exclude'. Where a slot uses only 'include', it does not actually constrain the slot, but behaves more like a suggestion or recommendation to use archetypes that match the 'include' patterns. If the intention is actually to constrain the slot to use only those matches, then currently the slot must also specify an 'exclude' pattern (typically /.*/).
...
The above structured slot definition implements this by treating include/exclude as a Boolean flag on a slot.
Changes in the AOM and ADL
A new kind of Slot type would be required in the AOM to support the above kind of structured definition. In the interests of maintaining compatibility with existing archetypes, it is proposed to add a new class ARCHETYPE_SLOT_2, which would co-exist with the current ARCHETYPE_SLOT class. No changes would be required in ADL, since a parser can easily distinguish the two types of slot definition and generate an instance of the correct AOM class.
Archetype Reference
A new ADL/AOM construct is proposed, called an Archetype Reference. This is similar in concept to an 'internal reference', but rather than pointing to another part of the same archetype, it points to a different archetype. The archetype reference would allow requirement A2 to be met.
Archetype references could be used in two ways. First, they can be used directly in an attribute, just as any other object constraint; the only difference being that they refer to another archetype containing the required definition, rather than providing the definition inline. Example:
| Code Block |
|---|
items cardinality matches {0..*; unordered} matches {
ELEMENT[at0002] occurrences matches {1} matches {...} -- Investigation type
ELEMENT[at0003] occurrences matches {0..1} matches {...} -- Investigation reason
use_archetype CLUSTER[at0004] occurrences matches {0..1} openEHR-EHR-CLUSTER.investigation_methodology.v1 -- Investigation methodology
}
|
...
We can see it has both occurrences and the node_id attributes of other C_OBJECT types. In addition it defines an archetype identifier. We can understand the meaning of the occurrences as for any other C_OBJECT, i.e. it defines the number of objects in data that match the object in the referenced archetype. This could be 0..1, 1..1, 0..*, or something specific like 2..5. The node_id tells us what the meaning of the node in the originating archetype is, even if the included archetype is a far more general one.
Archetype References for filling Slots
In the interests of including all 'template' semantics in the same formalism, it is useful to see how to relate an archetype reference to a slot definition. Clearly an archetype reference logically could be a 'slot-filler'.
Doing it by specialisation
One approach would be to consider an archetype reference(s) as a specialisation of a slot definition. Remembering that the definition of the slot must remain intact, since it may be used at runtime to determine what further archetypes can go into a slot. This would lead to the rules:
...
We can visualise this in ADL with the following archetypes. Firstly the parent:
| Code Block |
|---|
items cardinality matches {0..*; unordered} matches {
ELEMENT[at0002] occurrences matches {1} matches {...} -- Investigation type
ELEMENT[at0003] occurrences matches {0..1} matches {...} -- Investigation reason
allow_archetype CLUSTER[at0004] occurrences matches {0..1} matches {
ARCHETYPE_ID matches {
namespace matches {"org.openehr.clinical"}
qualified_rm_entity matches {"openEHR-EHR-CLUSTER"}
domain_concept matches {<< methodology}
version_id matches {".v1"}
}
}
}
|
Now the specialisation:
| Code Block |
|---|
..../items matches {
use_archetype CLUSTER[at0004.1] occurrences matches {0..1} openEHR-EHR-CLUSTER.investigation_methodology.v1 -- investigation methodology
}
|
...
We can visualise this in ADL with the following archetypes. Firstly the parent:
| Code Block |
|---|
items cardinality matches {0..*; unordered} matches {
allow_archetype CLUSTER[at0004] occurrences matches {0..1} matches {
ARCHETYPE_ID matches {
namespace matches {"org.openehr.clinical"}
qualified_rm_entity matches {"openEHR-EHR-CLUSTER"} domain_concept matches {<< methodology}
version_id matches {".v1"}
}
}
}
|
Now the specialisation:
| Code Block |
|---|
..../items matches {
items cardinality matches {0..*; unordered} matches {
allow_archetype CLUSTER[at0004.1] occurrences matches {0..1} matches {
ARCHETYPE_ID matches {
domain_concept matches {<< investigation_methodology}
}
}
}
|
We could also do both. Assume the parent as above....now the specialisation:
| Code Block |
|---|
..../items matches {
allow_archetype CLUSTER[at0004.1] occurrences matches {0..1} matches {
ARCHETYPE_ID matches {
domain_concept matches {<< investigation_methodology}
}
}
use_archetype CLUSTER[at0004.2] occurrences matches {0..1} openEHR-EHR-CLUSTER.microbiology_methodology.v1 -- microbiol investigation methodology
}
|
Here we have two specialised nodes, one a narrowed slot, the other an archetype reference; with node_ids of at0004.1 and at0004.2 respectively. The meaning of this is that a 'microbiology investigation methodology' CLUSTER object (which conforms to the original parent archetype slot) could be used; as well, any archetype corresponding to the narrowed slot definition, i.e. any 'investigation_methodology' archetype.
A better specialisation approach?
The above idea treats an archetype reference as a direct kind of specialisation of an archetype slot definition. This would be practically convenient, but is semantically unsatisfying, and is likely to get in the way with more complex examples.
An improved approach might be to explicitly include the idea of a 'binding' within the definition of the new-style structured slot. This would entail a definition of a slot in ADL as follows:
| No Format |
|---|
allow_archetype CLUSTER[at0004.1] occurrences matches {0..1} matches {
include matches {...} -- C_BOOLEAN
archetype_id matches { -- as above }
bindings matches {
}
}
|
xxxx
Ordering of Slots and Fillers
One problem that has come up in archteypes and templates to date is the need to specify the ordering of slot fillers. There appear to be two ways to deal with this. The first is to treat the position and related constraints of slots themselves (remembering that there can be more than one within the same attribute) as significant. See the discussion on the lower part of this page for this solution. With the help of the 'select' construct, this approach looks reasonable.
Q: Is there a need for complex ordering, occurrences etc of fillers within a given slot?
A Complex Example
An example of a template expressed as a set of specialised archetypes, based on the above principles is here (HTML files zipped; download and unzip in a local directory; then double click on the COMPOSITION template file). This shows the following features commonly found in templates, but expressed using the ADL 1.5 syntax, including above suggestions:
...