Resources such as archetypes and templates can be classified in CKM. In addition, users can classify themselves in two of the schemes - registering their Health Domain expertise and Profession.

Both resources and users use the same structure in that case, which can be flexibly managed for each CKM instance.

To manage the classification, Technical Administrator or Clinical Knowledge Administrator rights are required. Alternatively, a subset of the functionality is enabled for user with the Classification Modifier or Scheme Modifier, or Scheme Translator roles.

To make changes, select Tools>'Manage Classification' from the menu.

This opens the Manage Classification Tab in CKM:

Managing a Selected Class

You can right-click on any of these items to manage each class:

Here is possible to:

• add a new class below the existing class (or to the top-level by right-clicking on the name of the scheme, e.g. Health Domain),
• rename the class,
• translate the class for a new language,
• move the class below another class, so that the class will become a child of the other),
• move the class up in the hierarchy (if not already a top-level class in the case above),
• completely delete the class.

Advanced Options

Any items with a grey background have special options configured at the moment (such as Internal Medicine or General Internal Medicine above).
To change or add such advanced configuration, select Options from the context menu.
This takes you to the following screen for some advanced settings for each class.

Sorting Classes

By default, the classes are sorted alphabetically by their name (or their translated name, as applicable).

If a different sort order is required for selected items, a Sort Key can be specified that takes precedence over the name or translated name.
This can be usefully for example to indicate a certain order as in the example of Age groups:

If a sort key is specified, this sort key is taking precedence over the actual name of the class in the respective CKM language for any sorting purposes.
For maximum flexibility, the sort key is used to sort the elements alphabetically (NOT numerically), enabling a mix of elements with and without sort key to co-exist on one hierarchy level.

While it is possible to use letters as sort key, it is usually considered best-practice to use digits only as sort keys.
In harmony with the alphabetical order, digits are sorted above letters if there is a mixture of elements with and without sort key.
As a consequence of sorting alphabetically, it is advisable to add a sufficient number of leading letters or digits for the respective use case.

In the Age Group Use case above, for example, it is possible to use the following Sort Keys:

• Adolescent - 001
• Paediatric - 002
  • Fetus - 001
  • Neonate up to 28 days - 002
  • Infant up to 1 year - 003
  • Child 1-10 - 004
• Adult - 003

In this case, the leading "0" digits are not strictly required, but are considered best practice when it is possible that the ontology is extended later to avoid surprises in the sort order.

For example, consider sort keys "9" and "10": In numerical order, 9 is lower than 10, but alphabetical sorting is the opposite.This is why it is advisable to use 009 and 010 instead for example in this case.

Sorting to the End

As a special case, CKM supports explicitly sorting a class to the very end (of its hierarchy level within the ontology).
A use case for this is the typical "Other" class often seen, which is usually displayed at the end in all CKM language and not inline in alphabetical order. 

If a class should be sorted to the very end, the Sort behind last normal element checkbox can be checked, moving this class to the very end in all languages.
In case, multiple classes are configured to be sorted behind the last normal element, that need to be displayed in a particular order as well, it is also possible to specify the sort key for both items.

The result is that both classes will be listed at the very end, the one with the lower sort key first.

For example, the end of the ontology could look like 

• ...
• Other (Sort behind last normal element = checked)
• Not Applicable (Sort behind last normal element = checked)

If for some reason, the order of these two classes is important to be preserved in all languages (rather than relying on the alphabetical order of the class names), a sort key as described above can be applied in addition. This ensure that the "correct" order is preserved in all languages.

• ...
• Other (Sort behind last normal element = checked, Sort key: 001)
• Not Applicable (Sort behind last normal element = checked, Sort key: 002)

or, alternatively

• ...

• Not Applicable (Sort behind last normal element = checked, Sort key: 001)

• Other (Sort behind last normal element = checked, Sort key: 002)

Hiding Classes

Most of the schemes are used to classify resources such as archetypes and templates only.
However, two of the schemes - the Health Domain and the Profession scheme - are used to both classify resources such as archetypes and templates on the one hand and CKM users on the other hand.

This is to maximise consistency between both and avoid unnecessary maintenance overhead. However in practice some individual classes may only be relevant for either Resources or Users, but not for both. 

One example for the scheme "Health Domains" is that it may be necessary to provide a class "Not Applicable" or similar for users that do not want to classify themselves.
On the other hand, we may not want this class to be available to editors classifying an archetype or template.

In this case, it is possible to use the Hide option for Resources on the "Not Applicable" class:

This will hide the "Not Applicable" class everywhere where the Health Domain scheme is displayed in some way for resources such as archetypes and templates. This includes the "Find Resources" tab, the Archetype and template Classification tabs for each archetype/template.

If a class is hidden for users instead, this class will not be displayed in the User Profile or anywhere where users can be searched based on the user profile, such as when editors search for reviewers to invite to a review round. The class will also be hidden in the Users per Health domain chart (or the Users per Profession chart, respectively) available from Reports/Statistics form the CKM main menu.

View /Search Only

Also, it is possible to configure a certain class to only available for viewing or searching (View / Search only). This means that the class cannot be selected for the classification for a Resource or User. The anticipated use case is where the class will be a generic header that is a useful to demonstrate the logical hierarchy of the classification but the CKAs don't want it to be selectable.  For example, in the following example from the current Health Domain scheme, users or resources cannot be classified into the Internal Medicine class, which is "View/search only" -  one of the subclasses would need to be selected. Also note that "Other Internal Medicine" is displayed at the end because Sort behind last normal element checkbox has been checked.

Creating New Schemes

Occasionally, it may be also be desirable to create additional schemes using one of the "Create New Scheme" buttons.
New schemes are displayed in a tab of their own: In the example below the "Endorsement" tab is a new scheme of its own.

Once the scheme is created, it can be managed in exactly the same way as the existing / preconfigured schemes.