Evaluating SNOMED CT concept modifications

Concept history

Snow Owl supports importing the full release of SNOMED CT, including historical data on every component change since 2002. The History view provides information about the changes made to a given concept over time. By default it is linked to the active editor or the selection in the currently active SNOMED CT Concepts view or Parents view.

• The table in the upper part of the view shows the revisions that the concept went through. It displays version number, date, number of changes, name of the author and comments (e.g. if it was a full or a delta import).
• Clicking on an item reveals further information in the bottom section. You can see which components were modified and the kind of changes that were made.

History view

Historical concept information from the SNOMED CT RF2 Association Type reference set can also be imported and displayed. This includes details about why a concept was inactivated and suggestions for alternate concepts that replaced an inactive concept. To navigate to the related concept, click the hyperlink in the editor.

Inactive concept

Validating concepts

Validation during the editing process

To prevent the creation of invalid concepts, Snow Owl automatically validates your concept during the editing process. Conflicts are indicated by error or warning decorators. A link in the top of the editor allows to navigate to the affected item.

Error decorators inform about a fundamental problem within SNOMED CT, e.g. if your Fully specified name is not unique. It is not possible to save your new concept until the error is fixed.

Warning decorators indicate a conflict with the rules specified in the concept model. It's still possible to save the new concept despite of this conflict. To review or modify the rules pre-defined in the concept model editor, click on the MRCM editor button in the main toolbar to open the editor. For further information please refer to the section about concept model editing.

Error and warning decorators

Validating existing concepts

Existing concepts can also be validated. This is useful when want to ensure that concepts that you imported comply with the SNOMED CT guidelines. Erroneous concepts that were imported are indicated by an error decorator in the SNOMED CT view. Error found during the validation are listed in the Problems view.

The validation uses the same rules that are applied when authoring directly in Snow Owl. You can validate a single concept, a concept and its descendants, or the entire ontology.

Right-click the concept in the SNOMED CT view and select Validate concept or Validate concept and descendants to start the validation. If you want to validate the the entire ontology, click on the validate button in the toolbar. This process can take several minutes.

Validate concept or concept and subtypes

A dialog informs you of the result of the validation.

Summary of the validation

Go to the problems view to see a description of the error and the affected concepts.

Problems view displaying validation errors

Classifying

Maintaining consistency via reasoning

While the validation rules check the syntactic correctness of the concepts, you also have a way to verify if the newly created components are semantically valid and if they maintain the consistency and coherence of the ontology. The reasoner also classifies the ontology by computing the hierarchical relationships between the concepts which are based on their semantic definitions.

Snow Owl includes the following reasoners:

• ELK remains the world's fastest SNOMED CT classifier and is Snow Owl's default. ELK supports numerical datatypes.
• FaCT++ is the most expressive reasoner and supports all of Snow Owl's description logic features, including numerical datatypes, negation, disjunction, disjoint classes, and universal restrictions. Unfortunately, it's also slower than the other choices.
• MORe is a modular reasoner that makes use of ELK and HermiT. ELK is used to quickly classify the majority of the ontology, with more complex axioms being handled by HermiT. This is a good "pay-as-you-go" reasoner useful for experimenting with advanced description logic features.
• Snorocket is an OWL 2 EL reasoner that supports numerical datatypes.
• HermiT is an OWL 2 DL reasoner.
• CEL is an OWL 2 EL reasoner.

You should select the appropriate reasoner to match the description logic features that you utilized during the ontology authoring.

The reasoner set to default in the application preferences will be used for classification. In addition to the reasoners that are included with Snow Owl, it's also possible to install a different Protégé compatible reasoner. You can add a reasoner by copying the reasoner's Protégé jar to the dropins folder. For further details, please refer to the section about installing a new reasoner.

Classifying the ontology and applying the changes

To start the classification, press the Classify SNOMED CT ontology button in the main toolbar. The reasoner now evaluates the defining relationships between the concepts to infer new connections and identify unnecessary or redundant ones. Afterwards an ontology-comparison process calculates the changes that the reasoner found between the old and the new ontology. You can see the status of this process in the Remote jobs view in the bottom section; dependant on the size of the ontology the process can take several minutes.

Status of classification process

When the process is completed, a dialog pops up that gives you a detailed overview of the new relationships.

• Click on Save to apply the changes throughout the ontology. This means that newly inferred relationships will be added, and redundant relationships set to inactive with an updated effective time.
• If you want to decline the changes recommended by the reasoner click on Cancel. In this case you can continue editing and repeat the classification at a later time.

Classification Results

Classification in collaborative mode: If you are working in an active task, the classification results are added to this task. If you do not have an active task, the classification results will be placed on the MAIN repository branch.

Classification failed. Why?

The classification cannot be completed if there are equivalent or unsatisfiable concepts present in the ontology. In this case the classifier returns with an error dialog listing the erroneously equivalent or unsatisfiable concepts.

In the case of equivalent concepts you need to fix the concept definition, either by changing the definition status or adding the necessary defining relationships and then classifying the ontology again.

Equivalent concept result

In the case of unsatisfiable concepts you may change the subclass enumeration on the supertype concepts to loose.

Unsatisfiable concept result

If the classification process reveals concept equivalence or unsatisfiable concepts, these are also added to the Problems view and remain there until the error is corrected and another classification is run to verify this.

Problems view