Reference Model Adaptation

These adaptations can be formalised in a configuration object that is an instance of the class AOM_PROFILE, illustrated below. This is only one way such information can be represented, and alternatives could be used.

One adjustment that can be made is to indicate equivalences between RM entities and AOM built-in types. This can be illustrated by a common situation in health, where multiple RMs have concretely different models of the 'coded term' notion. Semantically, these are all the same, and the correspond to the AOM built-in type TERMINOLOGY_CODE. However, there is nothing that can be stated in an ADL archetype that can indicate this relationship, with the result that ADL tools can’t infer that a certain type, e.g. openEHR’s CODE_PHRASE or ISO 13606’s CODED_TEXT are equivalents of the TERMINOLOGY_CODE type in the AOM.

The mapping is achieved by using the aom_rm_type_mappings property of the AOM_PROFILE type, which enables equivalences between complex classes and properties to be described.

The following example shows parts of two AOM profile files, illustrating two different mappings of RM types for 'coded text' to the AOM TERMINOLOGY_CODE class. The following extract is from the openEHR AOM profile file for the ADL Workbench.

The following extract is from the {cimi_home}[CIMI] AOM profile file for the ADL Workbench. This defines a mapping from the CIMI RM class CODED_TEXT to the AOM class TERMINOLOGY_CODE.

The value of creating these mappings is that they inform tooling that constraints on the types CODE_PHRASE in openEHR archetypes, and CODED_TEXT in CIMI archetypes are to be understood as equivalent to contraints on the primitive AOM type TERMINOLOGY_CODE. This can be detected by the tool, and computed with, for example, with specific visualisation. Without this configuration, the archetype constraints are still correct, but the ADL tooling doesn’t treat them as different from any other RM complex type.

Using class and property mappings can enable more sophisticated archetype comparison and potentially even harmonisation, as well as more intelligent data comparison.

The primitive constrainer types of the AOM, i.e. descendants of C_PRIMITIVE_OBJECT correspond to a small abstract set of primitive types, as shown in the table [Primitive Types]. The implied list of RM abstract primitive types is Boolean, Integer, Real, Date, Date_time, Time, Duration, String, and Terminology_code. However, real reference models may be based on typical programming languages, and therefore include types like Double, Integer64, and even numerous variants on String, Integer etc, such as String_8, String32 and so on.

In order to prevent a similar explosion of AOM primitive types, the AOM profile enables equivalences between these latter types (which typically differ for each RM) and the abstract set to be stated, using the rm_primitive_type_equivalences property of AOM_PROFILE. An example is shown below.

The following CADL fragment provides an example.

Occasionally there are type mismatches between the RM type and the AOM type we would like to use, or has been used in an archetype. For example, the RM may have a String attribute in some class that represents an ISO 8601 date. It is possible to use the AOM constrainer type C_DATE instead of C_STRING, to obtain more a meaningful constraint.

Another use is where the archetype has been written with an integer constrant (i.e. a C_INTEGER) but the RM has a Real or Double type in the corresponding place. This can also be accommodated.

These differences can be corrected by using the aom_type_substitutions configuration table defined in the AOM_PROFILE class. The following is an example of using this facility to enable primitive type matching for openEHR archetypes.

The effect of these mappings is that literal values in an archetype that parse as the left hand side type (ISO8601_DATE etc) etc will be silently mapped to the right hand RM type (String etc). The following example shows a native ISO Duration field that is mapped to an RM String value.

Another kind of useful mapping adjustment that can help to make tools process archetypes in a more homogeneous way is to do with the AOM life-cycle states, which are standardised in the openEHR Archetype Identification specification. These states denote the state of a whole archetype in its authoring life cycle. Historically however there were no standard names, with the consequence that various archetype tools implement their own local lifecycle state names. To adjust for this the aom_lifecycle_mappings property in the AOM_PROFILE class can be used. These mappings have the effect of replacing the current value of the lifecycle_state property of the RESOURCE_DESCRIPTION instance of a parsed archetype with an openEHR standard state name. A typical example of the description section of an archetype with a local lifecycle state name is below.

The following example shows typical mappings of customs lifecycle state names to the openEHR standard state names.

Normally this kind of change should be written into the archetype, so that it is upgraded to the standard form. Tools should offer this possibility, including in batch/bulk mode.

Various meta-attributes may be added to an AOM profile in order to affect the behaviour of archetyping tools and processing. These are not required for correct functioning of tools, but are typically needed to make models comprehensible. Without them, there will no difference between primitive types such as Any, Integer etc, business types (e.g. things like Person, etc), and business-level data types (e.g. CodedText, Quantity etc).