It is sometimes asked why archetypes are not a) authored or b) displayed in UML. Here, 'UML' usually means the static class diagrams of the OMG UML standard. The following is an initial gap analysis.
UML is essentially a class-modelling formalism. At the UML concrete instance level, ADL/AOM is an object-level formalism.
Using UML directly to express an archetype implies converting all the object nodes in the archetype - which already have both a class from the underlying model (e.g. CLUSTER, ELEMENT, or in HL7v3, it cold be Act, Act-rel etc) and a local code that gives it its particular meaning (e.g. 'white cells', 'platelets', 'systolic pressure' etc) - to UML classes. This is potentially possible: if the underlying class is used as a stereotype, then you would have a class like WhiteCellCount <<ELEMENT>>.
In an archetype, a given node might express a constraint on e.g. the ELEMENT class, thus defining a particular set of instance variants (one in the limit) of ELEMENT that are designated to represent e.g. 'White cell count'. Elsewhere in the same archetype, or in another archetype, a different set of constraints could be applied to another occurrence of ELEMENT, designating it as e.g. 'body weight' or 'diagnosis'. This can't be achieved by normal OCL constraints on the ELEMENT class, unless a new OCL context is declared for every single constraint on ELEMENT. Note that in the CKM archetypes right now, the ELEMENT type is constrained around 1300 times.
The possible constraints on a Reference Model type can be made on:
Archetypes have their own inbuilt terms which are used to code the meaning of each object in a structure, e.g. with meanings like 'heart rate' (Apgar), 'systolic pressure' (BP meas), 'reaction category' (adverse reaction) and so on. These terms are mappable to external terminologies in the bindings part of the archetype, individually, and to ref-sets. For individual mappings, matches exist 30-50% of the time in our experience; for ref-sets, most of the work remains to be done to create appropriate ref-sets, particularly because usable ref-sets are almost always localised.
Archetypes are composed via 'slots', which are constraint statements on which archetypes could plug in at a certain point. E.g. at a CLUSTER node, you might put a statement that says that any lab biochemistry panel CLUSTER archetype can come here. The kind of statement to do this is currently a regex on the archetype id (bad) but in ADL 1.5 is a SNOMED CT-like semantic constraint using <, << etc subsumption, conjunction etc operators. There is no way in UML to connect two classes based on a semantic relationship like this;
Simulating this would require some kind of OCL statement in the source archetype that makes some statement to do with a value field in the target classes, e.g. self.items->forAll (i:ITEM | TerminologyService.valid (i.some_coded_attr.code + "<<" + "|0394856|biochemistry panel code")).
Archetypes have a rule section allowing declarations similar to OCL, but based on paths. Some expressions are not available in OCL, e.g. access to outside variables.
Archetypes natively support internationalisation. All linguistic elements (including all meta-data) in an archetype can be expressed in any language. Translations can be added as required.