The path feature computes the path to the current node from the root of the archetype, while the has_path function indicates whether a given path can be found in an archetype.

All node types include two functions that formalise the notion of conformance of a specialised archetype to a parent archetype. Both functions take an argument which must be a corresponding node in a parent archetype, not necessarily the immediate parent. A 'corresponding' node is one found at the same or a congruent path. A congruent path is one in which one or more at-codes have been redefined in the specialised archetype.

The c_conforms_to function returns True if the node on which it is called is a valid specialisation of the 'other' node. The c_congruent_to function returns True if the node on which it is called is the same as the other node, with the possible exception of a redefined at-code. The latter may happen due to the need to restrict the domain meaning of node to a meaning narrower than that of the same node in the parent. The formal semantics of both functions are given in the class definitions, [_class_definitions_].

The any_allowed function defined on some node types indicates that any value permitted by the reference model for the attribute or type in question is allowed by the archetype; its use permits the logical idea of a completely "open" constraint to be simply expressed, avoiding the need for any further substructure.

Every object node has an rm_type_name attribute that states the RM type to be matched by that node in the archetype. The value of rm_type_name is understood as a constraint on the dynamic type of data instances of the stated Reference Model type. It is either a class name from the RM, or a generic type constructed from RM class names, as described in the Reference model type matching section of the ADL2 specification.

The RM type stated in an archetype object node is understood to be a static type constraint. Accordingly, it will match an instance of any RM subtype of the stated type, as long as the inheritance relationship is stated in the RM definition. This holds both for sub-classes, and subtypes of generic types, in a covariant fashion. The following matching will thus succeed:

There are some special rules that apply to primitive type matching that enable 'logical' primitive type names in archetypes to match multiple 'concrete' variants that occur in some reference models and programming type systems. These are described in detail below.

The node_id attribute in the class C_OBJECT, inherited by all subtypes, is of key importance in the archetype constraint model. It has two functions:

The existence of node_ids in an archetype allows archetype paths to be created, which refer to each node. Every node in the archetype needs a node_id , but only node_ids for nodes under container attributes must have a terminology definition. For nodes under single-valued attributes, the terminology definition is optional (and typically not supplied), since the meaning is given by the reference model attribute definition.

Note that instances of C_PRIMITIVE_OBJECT have a constant node_id (see below) and thus do not require node identifiers to be supplied in syntax or serial forms that are converted to AOM structural form.

Within a specialised archetype, redefined or added object nodes may be defined under a container attribute. Since specialised archetypes are in differential form, i.e. only redefined or added nodes are expressed, not nodes inherited unchanged, the relative ordering of siblings can’t be stated simply by the ordering of such items within the relevant list within the differential form of the archetype. An explicit ordering indicator is required if indeed order is specific. The C_OBJECT.sibling_order attribute provides this capability. It can only be set on a C_OBJECT descendant within a multiply-valued attribute, i.e. an instance of C_ATTRIBUTE for which the cardinality is ordered.

It is possible to mark an instance of any defined node type as deprecated, meaning that by preference it should not be used, and that there is an alternative solution for recording the same information. Rules or recommendations for how deprecation should be handled are outside the scope of the archetype proper, and should be provided by the governance framework under which the archetype is managed.

The valid_value function tests a reference model object for conformance to the archetype. It is designed for recursive implementation in which a call to the function at the top of the archetype definition would cause a cascade of calls down the tree. This function is the key function of an 'archetype-enabled kernel' component that can perform runtime data validation based on an archetype definition.

This function is used to generate a reasonable default value of the reference object being constrained by a given node. This allows archetype-based software to build a 'prototype' object from an archetype which can serve as the initial version of the object being constrained, assuming it is being created new by user activity (e.g. via a GUI application). Implementation of this function will usually involve use of reflection libraries or similar.

This attribute allows a user-specified default value to be defined within an archetype. The default_value object must be of the same type as defined by the prototype_value function, pass the valid_value test. Where defined, the prototype_value function would return this value instead of a synthesised value.

The assumed_value attribute is useful for archetypes containing any optional constraint. and provides an ability to define a value that can be assumed for a data item for which no data is found at execution time. If populated, it can contain a single at-code that must be in the local value set referred to by the ac-code in the constraint attribute.

For example, an archetype for the concept 'blood pressure measurement' might contain an optional protocol section containing a data point for patient position, with choices 'lying', 'sitting' and 'standing'. Since the section is optional, data could be created according to the archetype which does not contain the protocol section. However, a blood pressure cannot be taken without the patient in some position, so clearly there is an implied value for patient position. Amongst clinicians, basic assumptions are nearly always made for such things: in general practice, the position could always safely be assumed to be 'sitting' if not otherwise stated; in the hospital setting, 'lying' would be the normal assumption. The assumed_value feature of archetypes allows such assumptions to be explicitly stated so that all users/systems know what value to assume when optional items are not included in the data.

Note that the notion of assumed values is distinct from that of 'default values'. The latter notion is that of a default 'pre-filled' value that is provided (normally in a local context by a template) for a data item that is to be filled in by the user, but which is typically the same in many cases. Default values are thus simply an efficiency mechanism for users. As a result, default values do appear in data, while assumed values don’t.

The C_TERMINOLOGY_CODE type entails some complexity and merits further explanation. This is the only constrainer type whose constraint semantics are not self-contained, but located in the archetype terminology and/or in external terminologies.

A C_TERMINOLOGY_CODE instance in an archetype is structurally simple: it can only be one of the following constraints:

Uniquely in the AOM, a Terminology code constraint may not be required, and may instead be considered informal. This is achieved via the attribute constraint_status which indicates either that the constraint is required (0) (i.e. the data item must formally conform to the constraint), or three levels of informal constraint, namely extensible (1) | preferred (2) | example (3). This particular model of constraint 'strength' follows the HL7 FHIR 'binding strengths' model. The convenience function constraint_required() can be used to determine if the constraint is formal, i.e. if constraint_status has the value required (0) or else is not set.

The informal constraint feature in C_TERMINOLOGY_CODE is provided to address the common real-world mismatch between local terminology use and more centrally defined archetypes. The enumeration values of 0 - 3 are designed such that the required constraint status (value = 0) is considered the default. Additionally, the constraint_status attribute is optional, and will not be present in archetypes authored with tools not including this feature. Accordingly, the constraint_required() function returns True if constraint_status is Void. This means that in all archetypes containing C_TERMINOLOGY_CODE nodes with no constraint_status, such nodes are considered to express a formally required constraint.

For the non-required settings of constraint_status, a data instance value may be a non-matching terminology code, including from another terminology. It might also be a plain text (i.e. not coded), in which case it will not be matched by a C_TERMINOLOGY_CODE archetype node, but an archetype node corresponding to the relevant RM type. In openEHR, this would usually be DV_TEXT. To allow for coded text or text matching therefore, at least 2 sibling archetype nodes are required, with one containing the appropriately configured C_TERMINOLOGY_CODE, and another representing a text-only constraint.

With respect to redefinition in specialised archetypes, the constraint strength may be redefined to be stronger, i.e. the enumeration value must be lower. Thus, a term constraint with strength of preferred (2) can be redefined to a strength of required (0).

When an archetype is deployed in the form of an operational template, the internally defined value sets, and any bindings are processed in stages in order to obtain the final terminology codes from which the user should choose. The C_TERMINOLOGY_CODE class provides a number of functions to formalise this as follows.

These functions would normally be implemented as 'lambdas' or 'agents', in order to obtain access to the target terminologies.