ADL - UML Gap Analysis

Owned by Thomas Beale
Last updated: 01-Mar-2012
9 min read

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.

ADL/AOM is an object-level formalism; UML is a class formalism

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>>.

Archetypes are defined in terms of per-instance constraints on an information model

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:

  • cardinality of attributes: the underlying UML model might have an attribute CLUSTER.items with cardinality 0..*; an archetype might limit this to 1..4. In UML there is no way to override an existing cardinality.
  • existence of attributes: the underlying UML model might have an attribute ELEMENT.value with cardinality 0..1; an archetype might limit this to 1..1 (i.e. mandatory). In UML there is no way to override an existing cardinality.
    • NB: UML actually doesn't correct distinguish between existence and cardinality. Existence means: is there an object? Cardinality means (for containers only): how many items can be in this container. There is no accepted way in UML to force the container to be there, but allow it to be empty. For this, you need to add an OCL statement.
  • number of occurrences of data items matching a given child in a container in an archetype. For example, you might make a container item called 'systolic pressure' in a container that also has 'distolic pressure' etc. You can set the occurrences of each such element individually. Usually these ones would be set to 1..1 or 0..1 (two systolics in one measurement doesn't normally make sense). BUt a data element marked 'differential diagnosis' could have occurrences set to 1..* for example, or 1..3 or whatever. 'Occurrences' is not a UML concept per se, because it is to do with numbers of instances in data matching a specific pattern, not numbers of possible instances of any kind in a container.
  • type; e.g. ELEMENT.value (see here ) could be restricted to say DV_QUANTITY, DV_COUNT and DV_TEXT.
  • value range: any primitive valued field (this includes coded items and dates and times in ADL) can be restricted to a specific range or set of possible values
  • any coded text (HL7-speak: CD, CV, CS) can be restricted to an internal code, an external code, or a value from a referenced ref-set

Integrated terminology

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.

Composition Semantics

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")).

  • NB: this assumes a terminology service is available (and inherited someway into the model) and that there is a service function for testing subsumption.... maybe doable in some very esoteric environment, but no UML tool today can do this.

Per-archetype Rules

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.

Native Internationalisation

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.