Terminology Package

Overview

All local terminology as well as terminological and terminology binding elements of an archetype are represented in the terminology section of an archetype, whose semantics are defined by the aom2.terminology package, shown below.

AM aom2.terminology
Figure 1. am.aom2.terminology Package

An archetype terminology consists of the following elements.

  • term_definitions: a mandatory structure consisting of lists of term definitions defined local to the archetype, one list for each language of translation, as well as the original language of definition. The entries in this table include:

    • Some or all id-codes. One of these is a code of the form 'id1', 'id1.1', 'id1.1.1' etc, denoting the concept of the archetype as a whole. This particular code is recorded in the concept_code attribute and is used as the id-code on the root node in the archetype definition. Not all id-codes are required to be in the term_definitions structure - for nodes that are children of single-valued attribute, a term definition is optional (and not typically defined).

    • at-codes used to define value terms and inline value sets/ All at-codes will appear within a C_TERMINOLOGY_CODE constraint object within the archetype. All at-codes must have a definition in the term_definitions.

    • ac-codes used to define external value set references. All ac-codes must have a definition in the term_definitions.

  • term_bindings: an optional structure consisting of list of terms and bindings, one list for each external terminology (i.e. the terminology or ontology being 'bound to'). Each 'binding' is a URI to a target. For a binding of an id-code or an at-code, the target will be a single term, and for an ac-code, it will designate a ref-set or value set.

  • value_sets: optional structure defining value-set relationships for locally defined value sets. Each value set is identified by an ac-code and has as members one or more at-codes.

  • terminology_extracts: an optional structure containing extracts from external terminologies such as SNOMED CT, ICDx, or any local terminology. These extracts include the codes and preferred term rubrics, enabling the terms to be used for both display purposes. This structure is normally only used for templates, enabling small value sets for which no external reference set or subset is defined to be captured locally in the template.

Depending on whether the archetype is in differential or flat form, an instance of the ARCHETYPE_TERMINOLOGY class contains terms, constraints, bindings and terminology extracts that were respectively either introduced in the owning archetype, or all codes and bindings obtained by compressing an archetype lineage through inheritance. A typical instance structure of ARCHETYPE_TERMINOLOGY is illustrated in Terminology Instance Structure.

terminology instance structure
Figure 2. Terminology Instance Structure

Semantics

Specialisation Depth

Any given archetype occurs at some point in a lineage of archetypes related by specialisation, where the depth is reflected by the specialisation_depth function. An archetype which is not a specialisation of another has a specialisation_depth of 0. Term and constraint codes introduced in the terminology of specialised archetypes (i.e. which did not exist in the terminology of the parent archetype) are defined in a strict way, using '.' (period) markers. For example, an archetype of specialisation depth 2 will use term definition codes like the following:

  • id0.0.1 - a new term introduced in this archetype, which is not a specialisation of any previous term in any of the parent archetypes;

  • id4.0.1 - a term which specialises the id4 term from the top parent. An intervening .0 is required to show that the new term is at depth 2, not depth 1;

  • id25.1.1 - a term which specialises the term id25.1 from the immediate parent, which itself specialises the term id25 from the top parent.

This systematic definition of codes enables software to use the structure of the codes to more quickly and accurately make inferences about term definitions up and down specialisation hierarchies. Constraint codes on the other hand do not follow these rules, and exist in a flat code space instead.

Class Descriptions

Unresolved include directive in modules/AOM2/pages/terminology_package.adoc - include::../UML/classes/archetype_terminology.adoc[] Unresolved include directive in modules/AOM2/pages/terminology_package.adoc - include::../UML/classes/terminology_relation.adoc[] Unresolved include directive in modules/AOM2/pages/terminology_package.adoc - include::../UML/classes/value_set.adoc[] Unresolved include directive in modules/AOM2/pages/terminology_package.adoc - include::../UML/classes/archetype_term.adoc[]

Validity Rules

The following validity rules apply to instances of this class in an archetype:

VTVSID: value-set id defined. The identifying code of a value set must be defined in the term definitions of the terminology of the current archetype.

VTVSMD: value-set members defined. The member codes of a value set must be defined in the term definitions of the terminology of the flattened form of the current archetype.

VTVSUQ: value-set members unique. The member codes of a value set must be unique within the value set.

VTSD specialisation level of codes. Term or constraint code defined in archetype terminology must be of the same specialisation level as the archetype (differential archetypes), or the same or a less specialised level (flat archetypes).

VTLC: language consistency. Languages consistent: all term codes and constraint codes exist in all languages.

VTTBK: terminology term binding key valid. Every term binding must be to either a defined archetype term ('at-code') or to a path that is valid in the flat archetype.

VTCBK: terminology constraint binding key valid. Every constraint binding must be to a defined archetype constraint code ('ac-code').