An ADL version identifier is mandatory in all archetypes, and is expressed as a string of the form adl_version=N.M , or N.M.P, where N.M[.P] is the ADL release identifier.

An RM (Reference Model) Release identifier is mandatory in all archetypes, and is expressed as a string of the form rm_release=N.M, or N.M.P, where the version number indicates the release of the reference model on which the archetype is based.

A unique identifier for the archetype in the form of a GUID can be specified using the syntax below:

This identifier is set at initial creation or at any time later, and never subsequently changes. It acts as an identifier for the physical artefact, regardless of what semantics are changed, including changes to the constituent parts of the multi-axial identifier.

A build_uid identifier can also be specified, with a GUID value, identifying the current artefact. This identifier changes whenever any change is made to the text of the archetype, and can thus be used to disambiguate subsequent versions.

A namespaced archetype has an identification section like the following examples:

Namespaces are used to distinguish locally created artefacts representing a given concept (such as 'haematology result') from an artefact created elsewhere intended to represent the same concept.

Once a namespace is attached to an archetype, it is considered a part of the identifier, and never changed, even if the archetype moves to a new publishing organisation. This ensures the constant relationship between archetypes and the data created using them.

The archetype identifier may include a namespace, in the form of a reverse domain name, which denotes the original authoring organisation. The lack of a namespace in the identifier indicates an ad hoc, uncontrolled artefact, not formally associated with any organisation, typical for experimental archetypes, and pre-ADL 1.5 archetypes not yet upgraded to have a namespace. The main part of the identifier is multi-axial concept identifier.

A typical identification section for an ad hoc archetype is as follows:

The multi-axial archetype identifier identifies archetypes in a global concept space within a given namespace. It is also known as an 'ontological' identifier, since the concept space can be understood as an ontology of informational concepts on which the archetypes are based. The syntax of the identifier is described in the openEHR Identification Specification. The structure of the concept space is essentially two-level, with the first level being a reference model class (e.g. openEHR OBSERVATION class) and the second being a domain concept (e.g. 'haematology result').

Because namespaces are usually treated hierarchically, higher level namespaces (e.g. '.org' domains) are assumed to be includable by more local namespaces, with the result that the concept definition space is inherited as well.

The archetype identifier of any specialised archetype, including all templates, follows the same rules as for non-specialised archetypes.

ADL 2 Archetypes contain 3-part version identifiers, with optional qualifiers, following the openEHR Artefact Knowledge Identification specification. Examples below:

The version identifier variants are summarised as follows:

The following syntax validity rule applies in the identification section:

A flag indicating whether the archetype was generated or authored can be included after the version, as follows:

This marker is used to support the migration to differential archetype representation introduced in ADL 1.5, to enable proper representation of specialised archetypes. The 'generated' marker can be used on specialised archetypes - i.e. ADL 1.5 style .adls files - generated from flat archetypes - ADL 1.4 .adl files - and also in flat archetypes generated from differential files, by an inheritance-flattening process.

A flag indicating whether the archetype is change-controlled or not can be included after the version, as follows:

This flag may have the two values controlled and uncontrolled only, and is an aid to authoring tools, but has no semantic significance. Tools may treat archetypes with an uncontrolled flag as not needing version control, whereas archetypes containing the controlled flag should be versioned on every change. This enables archetypes to be repeatedly edited in early development without generating large version histories of little or no value.