Specialisation

Specialised archetypes in their authored form are represented in 'differential' form. The syntax is the same as for non-specialised archetypes, with two additions: specialisation paths (see Specialisation Paths) and ordering indicators (see Ordering of Sibling Nodes). For a specialised archetype therefore, the lineage of archetypes back to the ultimate parent must be taken into account in order to obtain its complete semantics.

Differential form means that the only attributes or objects mentioned are those that redefine corresponding elements in the parent and those that introduce new elements. The differential approach to representation of specialised archetypes give rise to the need for a flat form of a specialised archetype: the equivalent archetype defined by the sum of the (differential) child and its parent, as if the child archetype had been defined standalone. The flat form of archetypes is used for building templates, and subsequently at runtime. It is generated by 'compressing' the effects of inheritance of the parent to the specialised child into a single archetype, and applies recursively all the way up an archetype lineage to the ultimate parent, which must be a top-level (non-specialised) archetype. For a top-level archetype, the flat-form is the same as its differential form (i.e. in a top-level archetype, every node is considered to be an extension node).

In order to talk about archetypes at different levels of specialisation, a standard way of identifying the levels of specialisation is used, as follows:

For nodes carrying a node identifier, the specialisation level is always equal to the number of '.' characters found in the identifier.

Because ADL is a block-structured language, the redefinition of nodes deep in the parent structure normally requires descending into the structure. Since it is common to want to further constrain only nodes deep within a structure in specialised archetype, a more convenient way is provided in ADL to do this using a specialisation path, illustrated by the following example:

In this fragment, a path is used rather than an attribute name. A path can be used in this manner only if no further constraints are required 'on the way' into the deep structure, with the exception of id-code overrides (since these can be syntactically accommodated within the path).

The rules for specialisation paths are as follows.

Any node in an archetype can unambiguously be located by its archetype path. For example, the text value of the 'problem' node of the openEHR-EHR-EVALUATION.problem.v1 archetype shown at the top of the example in Redefinition for Specialisation is:

Similarly the path to the redefined version of the same node in the openEHR-EHR-EVALUATION.problem-diagnosis.v1 archetype at the bottom of the same figure is:

By inspection, it can be seen that this path is a variant of the corresponding path in the parent archetype, where a particular object node identifier has been specialised.

In general, the path of every redefined node in a specialised archetype will have a direct equivalent in the parent archetype, which can be determined by removing one level of specialisation from any node identifiers within the specialised path that are at the level of specialisation of the specialised archetype (i.e. node identifiers corresponding to higher specialisation levels are not changed). In this way, the nodes in a specialised archetype source can be connected to their counterparts in parent archetypes, for purposes of validation and flattening.

Conversely, any given path in an archetype that has children will have congruent paths in the children wherever nodes have been specialised.

A specialised archetype definition at any level consists of a set of changes with respect to its flat parent. The technically available changes are categorised as follows.

In the ADL syntax, objects can be specified in two places: under single-value attributes and under multiply-valued (container) attributes.

Each object under a single-valued attribute defines an alternative that may be used to constrain data at that attribute position. An example is the OBSERVATION.protocol attribute from the openEHR reference model: if multiple objects appear under this attribute, only one can be used at runtime to constrain data.

Within a container attribute, the meaning of multiple objects is that each child object defines constraints on one or more members of the container in the data. The occurrences constraint on each one determines how many objects in the data match a given object constraint in the attribute.

Object constraints can be specialised in both places by redefinition, refinement and exclusion. Addition can also be used under either kind of attribute: in both cases, it corresponds to an alternative. The actual semantics are described in terms of object node identification, type redefinition, and structural constraints (existence, cardinality and occurrences), and are the same for objects under single- and multiply-valued attributes. The following sections describe the details.

The example shown below is from an older version of the openEHR 'Problem' archetype and illustrates the use of redefinition and extension. The first text is the the definition section of the top-level 'Problem' archetype, and shows one ELEMENT node in expanded form, with the remaining nodes in an elided form.

The second text below is from the 'problem-diagnosis' archetype, i.e. a 'diagnosis' specialisation of the general notion of 'problem'. In this situation, the node [id2], with occurrences of 1, i.e. mandatory non-multiple, has its meaning narrowed to [id2.1] 'diagnosis' (diagnosed problems are seen as a subset of all problems in medicine), while new sibling nodes are added to the items attribute to define details particular to recording a diagnosis. The extension nodes are identified by the codes [at0.32] , [at0.35] and [at0.37], with the latter two shown in elided form.

The example shown below illustrates redefinition in a specialised archetype. The first text is taken from the definition section of the 'laboratory result' OBSERVATION archetype (available at openEHR CKM), and contains an ELEMENT node whose identifier is [id79] , defined as 'panel item' in the archetype terminology (sibling nodes are not shown here). The intention is that the id79 node be specialised into particular 'panel items' or analytes according to particular types of test result. Accordingly, the id79 node has occurrences of 0..* and its value is not constrained with respect to the reference model, meaning that the type of the value attribute can be any descendant of DATA_VALUE .

The second text, below, is a specialised version of the laboratory result archetype, defining 'thyroid function test result'.

The redefinitions include:

Note that the original ELEMENT[id79] node with occurrences of 0..* remains a valid constraint node: the fact of specialisation does not remove it. If the intention is that the specialised nodes constitute an exhaustive redefinition of the original node, the latter can be effectively removed, as described in Exhaustive and Non-Exhaustive Redefinition.

This archetype is typical of a class of specialisations that use only redefinition, due to the fact that all objects in the redefined part of the specialised version are semantically specific kinds of a general object, in this case, 'panel item'.

All attributes mentioned in an archetype have an existence constraint, indicating whether a value is required or not. The constraint is either stated explicitly - typically done for single-valued attributes - or it is the value from the reference model - typical for multiply-valued attributes. In both cases, the existence of an attribute in a parent archetype can be redefined in a specialised archetype using the standard cADL syntax. In the following example, an implicit existence constraint picked up from the reference model of {0..1} is redefined in a child archetype to {1} , i.e. mandatory.

Parent archetype:

Child archetype:

Redefinition of existence to ` {0}` by this method denotes exclusion, i.e. removal of the entire attribute (including all sub-structure) from the resulting structure. In an archetype, it is likely to indicate poor design, given that the decision to remove optional attributes is much more likely to be local, and therefore more appropriate in templates rather than archetypes; within a template it would be perfectly normal. The following example shows the protocol attribute in the above ` OBSERVATION` archetype being excluded in this way:

Note that in the above, the '/' is used to denote '/protocol' as a differential path. Without the slash, the 'protocol' attribute would be considered to be trying to constrain a hitherto unconstrained attribute called 'protocol', rather than redefine a constraint already present in a parent archetype.

The following sub-sections describe specialisation semantics specific to container attributes.

In an archetype, node identifiers ('id-codes') are mandatory on all object constraint nodes. The identifiers of those object nodes defined as children of a multiply-valued attribute and multiple alternative children of single-valued attributes (see Node Identifiers) require definitions in the archetype terminology. Definitions are optional on other single child constraints of single-valued attributes. This rule applies in specialised as well as top-level archetypes.

A key question is: when does a node identifier need to be redefined? There are three possible situations:

Redefinition of an object node identifier for purely semantic purposes, unaccompanied by any other kind of constraint change is done as shown in the following example.

Parent archetype:

Child archetype:

Here the id5 ('Description') node is refined in meaning to id5.1 ('Summary'). Since there is no other constraint to be stated, no further matches block is required.

An example of the 3rd case above of redefinition is shown in the first archetype in Redefinition for Specialisation, where the node [id79] is redefined into a number of more specialised nodes [id79.2] - [id79.9], while in the second, the identifier [id2] is redefined to a single node [id2.1] .

The syntactic form of the identifier of a redefined node is a copy of the original followed by a dot ('.'), optionally intervening instances of the pattern '0.' and then a further non-zero number, i.e.:

This permits node identifiers from a given level to be redefined not just at the next level, but at multiple levels below.

The following are examples of redefined node identifiers:

The digits '1' and '2' here should not be confused with levels 1 and 2. The above identifiers based on an id6 node might easily be:

The occurrences constraint on an object node indicates how many instances within the data may conform to that constraint (see [Container Attributes]). Within container attributes, occurrences is usually redefined in order to make a given object mandatory rather than optional; it can also be used to exclude an object constraint. In the following example, the occurrences of the id4 node is redefined from {0..1} i.e. optional, to {1} , i.e. mandatory.

Parent (openEHR-EHR-EVALUATION.problem.v1.0.3):

Child (openEHR-EHR-EVALUATION.problem-diagnosis.v1):

In the above we can see that if the only change in the redefinition is to occurrences, the remainder of the block from the parent is not repeated in the child. Occurrences is normally only constrained on child objects of container attributes, but can be set on objects of any attribute to effect exclusion of part of the instance space. This can be useful in archetypes where a number of alternatives for a single-valued attribute have been stated, and the need is to remove some alternatives in a specialised child archetype. For example, an archetype might have the following constraint:

and the intention is to remove the DV_INTERVAL<*> alternatives. This is achieved by redefining the enclosing object to removed the relevant types:

Exclusion by setting occurrences to {0} is also common in templates, and is used to remove specific child objects of container attributes, as in the following example:

If the whole attribute is to be removed, this can be done by redefining existence to {0}, as described in Existence Redefinition: Mandation and Exclusion.

In the examples shown above there are two types of redefinition occurring. The first shows a single node in the parent archetype redefined by a single node, both identified by id4. The second shows a single node in the parent redefined by multiple children. In the first example, the result of flattening is in-place overlaying, while in the second, it is cloning with overlaying. The consequence of the second type of redefinition is that the original parent node survives in its original form in the child archetype, whereas in the first, it is replaced. The reasoning behind this is that redefinition to multiple children is taken to mean that later redefinition to multiple children may occur in deeper child archetypes, and for this to occur, the original parent needs to be left intact. Conversely, the single-parent / single-child redefinition is taken to mean a logical refinement of an existing node, which should therefore be logically replaced.

The formal rule for whether cloning occurs or not is as follows:

The first case corresponds to the situation where the 'effective occurrences' of any child of an attribute can be inferred to be maximum 1, i.e. either the attribute is single-valued, or it is a container with a cardinality constraint with maximum 1. The second is where the object in the child archetype has an explicit occurrences constraint of max 1. In the above, the effective_occurrences function is defined in the AOM2 specification.

In any multiple specialisation situation, there is a question of whether the original node being specialised (e.g. id79 and id2 in the examples above) remains available for further redefinition in subsequent child archetypes, or do the redefinition children exhaustively define the instance space for the given parent node?

Should these children be considered exhaustive? One point of view says so, since all subsequently discovered varieties of hepatitis (C, D, E, etc) would now become children of 'hepatitis non-A non-B'. However this is likely to be sub-optimal, since now the category 'hepatitis non-A non-B' probably exists solely because of the order in which the various hepatitis virus tests were perfected. Therefore an alternative argument would say that the categories 'hepatitis C', 'hepatitis D' etc should be defined directly below 'hepatitis', as if 'hepatitis non-A non-B' had never existed. Under this argument, the children would not be declared, even when they are theoretically exhaustive.

This kind of argument comes up time and again, and the need for catch-all categories (archetype nodes) and the possibility of future discoveries cannot be predicted. Even in situations such as a lab result (e.g. cholesterol), where the list of analytes seem to be known and fixed, experience of clinical modellers has shown that there is nevertheless no guarantee of not needing another data point, perhaps for something other than an analyte.

The default situation is that child redefinition nodes do not exhaustively replace the parent unless explicitly stated otherwise. This may be done by excluding the parent node in the normal way, i.e. using occurrences matches {0}. If an exclusion node is included, it must come last in the set of siblings that specialise the parent node, otherwise a deletion will occur, leaving no node to specialise. The first example would then become:

Parent archetype:

Child archetype:

Without the above specification, a deeper child archetype could then redefine both the original id79 node (e.g. into id79.0.1 , id79.0.2), and any of the id79.x nodes (e.g. id79.1.1 , id79.1.2); with it, only the latter is possible. The id79 node can thus be considered to be logically 'frozen', in a similar way to frozen class methods in some programming languages.

The type of an object may be redefined to one of its subtypes as defined by the reference model. A typical example of where this occurs in archetypes based on the openEHR reference model is when ELEMENT.value is constrained to * in a parent archetype, meaning 'no further constraint on its RM type of DATA_VALUE, but is then constrained in a specialised archetype to subtypes of DATA_VALUE, e.g. DV_QUANTITY or DV_PROPORTION (see openEHR Data Types). The following figure containts a simplified extract of the data values part of the openEHR reference model, and is the basis for the examples below.

The most basic form of type refinement is shown in the following example:

Parent archetype:

Specialised archetype:

The meaning of the above is that instance data constrained by the specialised archetype at the value node must match the DV_QUANTITY constraint only - no other subtype of DATA_VALUE is allowed.

When a type in an archetype is redefined into one of its subtypes, any existing constraints on the original type in the parent archetype are respected. In the following example, a DV_AMOUNT constraint that required accuracy to be present and in the range +/-5% is refined into a DV_QUANTITY in which two attributes of the subtype are constrained. The original accuracy attribute is inherited without change.

Parent archetype:

Specialised archetype:

In the same manner, an object node can be specialised into more than one subtype, where each such constraint selects a mutually exclusive subset of the instance space. The following example shows a specialisation of the DV_AMOUNT constraint above into two subtyped constraints.

Here, instance data may only be of type DV_QUANTITY or DV_PROPORTION, and must satisfy the respective constraints for those types.

A final variant of subtyping is when the intention is to constraint the data to a supertype with exceptions for particular subtypes. In this case, constraints based on subtypes are matched first, with the constraint based on the parent type being used to constrain all other subtypes. The following example constrains data at the value node to be:

A typical use of this kind of refinement in openEHR would be to add an alternative for a DV_CODED_TEXT constraint for a specific terminology to an existing DV_TEXT constraint in a name attribute, as follows:

All of the above specialisation based on reference model subtypes can be applied in the same way to identified object constraints.

An archetype proxy object, or use_node constraint is used to refer to an object constraint from a point elsewhere in the archetype. These references can be redefined in two ways, as follows.

Note that if the intention is to redefine a structure referred to by use_node constraints, but to leave the constraints at the reference source points in form to which the reference points in the parent level, each use_node reference needs to be manually redefined as a copy of the target structure originally pointed to.

The second type of redefinition above is the most common, and is shown in the following example.

Parent archetype:

Child archetype:

Remembering that the parent archetype is essentially just definition two sibling object structures with the identifiers id1 and id2 (defined by the use_node reference), the child is redefining the id2 node (it could also have redefined the id1 node as well). The result of this in the flattened output is as follows:

There is one subtlety to do with redefinition of occurrences of a use_node target: if it is redefined to have occurrences matches {0} (normally only in a template), then the effect of this is the same on any use_node reference definitions, unless they define occurrences locally at the reference point. The chance of this actually occurring appears vaninshingly small, since by the time 'exclusion' occurrence redefinition is being done in templates, use_node object definitions are most likely to have been locally overridden anyway.

Lastly, one further type of redefinition appears technically possible, but seems of no utility, and is therefore not part of ADL:

External reference nodes can be redefined by another external reference node, in the following ways:

Slots and slot-filling is a special kind of 'redefinition' in ADL, normally only used in templates. Logically, an archetype slot constraint is understood to consist of a) its definition (what archetypes are allowed to fill it) and b) current filler list. At the point of definition, the current fillers is invariably empty. More specialised descendants can progressively add or replace fillers for a slot. Thus, the appearance of an object node whose identifier is the specialisation of a slot node in the flat parent is always understood as a partial specialisation for it.

In other words, a slot within an archetype can be specialised by any combination of the following:

Both types of redefinition are generally used by templates rather than published archetypes, since the business of filling slots is mostly related to local use-case specific uses of archetypes rather than part of the initial design.

The following example shows a slot from a SECTION archetype for the 'history_medical_surgical' archetype.

This slot specification allows EVALUATION archetypes for the concepts 'clinical synopsis', various kinds of 'exclusions' and 'problems', and 'injury' to be used, and no others. The following fragment of ADL shows how the slot is filled in a template, using the keyword use_archetype. In this syntax, the node identification is a variation on the normal archetype id-codes. Within the template, the identifier of the used archetype is also the identifier of that node. However, the original at-code (if defined) must also be mentioned, so as to indicate which slot the used archetype is filling. Templates may also be used to fill slots in the same way. Thus, in the following example, two archetypes and a template are designated to fill the id2 slot defined in the above fragment of ADL. The slot definition is not mentioned, so it remains unchanged, i.e. 'open'.

Slots can be recursively filled in the above fashion, according to the possibilities offered by the chosen archetypes or templates. The following ADL fragment shows two levels of slot-filling:

Note that in the above the archetype fillers are specified as published archetypes, but in reality, it is far more likely that template-specific specialisations of these archetypes would be used. The identification and organisation of such archetypes is described in the openEHR Templates document.

In addition to or instead of specifying slot fillers, it is possible in a slot specialisation to narrow the slot definition, or to close it. If fillers are specified, closing the slot as well is typical. The latter is done by including an overridden version of the archetype slot object itself, with the 'closed' constraint set, as in the following example:

Narrowing the slot is done with a replacement ` allow_archetype` statement containing a narrowed set of match criteria.

The use_archetype keyword can be used to specify child object constraints under any attribute in the reference model that is so far unconstrained by the flat parent of an archetype or template. Technically this could occur in any kind of archetype but would normally be in a specialised archetype or template. This is no more than the standard use of an 'external reference' (see [_external_references]).

Any reference specified will have no slot, and is instead validity-checked against the appropriate part of the underlying reference model.

The following example from the openEHR reference model is typical.

The above cADL block partially specifies a COMPOSITION object, via constraints (often including slot definitions) on the category and context attributes defined on that class in the reference model. However, the attribute of most interest in a COMPOSITION object is usually the content attribute, which is not constrained at all here. The reference model defines it to be of type List<CONTENT_ITEM> .

Using an external reference in an unarchetyped part of the RM structure is almost always done in specialised archetypes or templates, but is valid in a top-level archetype.

The following example shows the use of use_archetype within a specialised archetype.

For terminal objects (i.e. elements of the type C_PRIMITIVE_OBJECT) redefinition consists of:

Tuple constraints can be redefined by narrowing, as for other primitive constraints. A typical example is as follows.

Parent archetype:

Child archetype: