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 at-code (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.

Within an archetype, multiple object constraint nodes may appear under a single-valued attribute. Each such node 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. When a single object node is refined by one or more alternatives in a child archetype, any redefined occurrences of the child must conform in the expected way to that of the parent node, i.e. be a narrowed interval.

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 under the attribute. Valid occurrences intervals for each specialised child in this case are determined collectively, that is to say, by considering the occurrences of all the specialised children of a given parent node. As a consequence, for any child node in such a set that specialises the occurrences of the parent node, the occurrences of each such node need only intersect the occurrences interval of the parent node. This is because it may be assumed (indeed, necessary) for the data to contain instances matching more than one of the set. To correctly determine the effective occurrences of any node in a specialised group, the cardinality of the owning attribute must also be taken into account. For this reason, a particular concrete consequence of collective occurrences is that any given child node occurrences may have an unbounded upper limit (i.e. *) even if the upper bound of the cardinality of the owning attribute is finite.

The rules for redefinition of occurrences on object nodes is formally defined in the VSONCO validity rule in the AOM2 specification.

Object constraints can be specialised under both types of attributes 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.