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

In some cases, primitive types as parsed in an archetype do not quite match those in the reference model. Typical examples of benign mismatches that can be silently corrected by defining mappings in the AOM profile are:

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 CADL fragment provide an example.

The following example shows a native ISO Duration field that is mapped to a 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.