Prior to releasing a SNOMED CT extension or edition, a series of validation checks should be performed to ensure that the package is ready for release.
The table below summarizes the different types of validation tasks and provides some examples of checks that can be performed prior to a release.
Table: Pre-release validation tasks
Structural Conformance
To validate that the SNOMED CT distribution files conform structurally to the specification of the associated file type, and that the rows and columns contain values of an appropriate data type.
Concept file conforms to the structure specified in the
Description file conforms to the structure specified in the
Relationship file conforms to the structure specified in the
Reference set files conform to the structure of the specific reference set type in
Release Type
To test assertions about the content of SNOMED CT data files, with respect to their release type (i.e. Full, Snapshot or Delta). This involves comparing data files for the prospective release with those of the most recently published previous release.
New full file consists of the previously released full file and the new delta file
New delta file consists of all rows from the new full release which has an effectiveTime equal to the new release date
New snapshot file contains only one row for each component or reference set member
File
To test file constraints and interfile dependencies (i.e. assertions about the integrity of data within and between SNOMED CT data files). This involves testing primary and foreign keys, and the cardinality of references between files. For performance reasons, testing may be limited to the set of concepts that have changed in some way in the prospective release, and components associated with them.
Active extension descriptions are referred to in one or more language reference sets
All concepts associated with an active description in the description file are present in the concept file of either the extension, the International Edition, or a module from another extension on which the extension modules depend.
Primary keys are unique within each file
For files in the full release, the combination of the id and the effectiveTime is unique
For files in the snapshot and delta releases, the id is unique
Component
To test assertions about the integrity of SNOMED CT components. In this kind of validation, the content of each file is tested against the editorial principles and logical design of SNOMED CT.
All active concepts must have:
An active description of type | Fully specified name|
At least one active description of type | Synonym|
At least one active relationship
A transitive relationship to the root concept
A definitionStatusId which refers to an active descendant of
All active relationships must conform to the following rules:
sourceId and destinationId must both refer to active concepts
typeId must refer to an active descendant of
characteristicTypeId and modifierId
All active descriptions must conform to the following rules:
conceptId must refer to a valid concept (which may be active or inactive)
typeId and caseSignificanceId must refer to appropriate active metadata concepts
Extension producers should ensure that validation is performed during the authoring process to ensure that new and updated content complies with editorial principles. An authoring tool should perform validation checks for all editorial rules that can be tested automatically. Additionally, classification during authoring is recommended, as it ensures that the content within the extension sits in the SNOMED CT hierarchy as expected and that no errors have been introduced. For more information on classification, please see Classifying an Edition.
The table below provides some examples of automatic validation checks that should be performed when authoring components and reference sets. Please note that this table presents rules that are relevant for all SNOMED CT extensions, but there may be additional national linguistic and/or modelling guidelines which shoud be followed.
Table: Automatic validation of components and reference sets during authoring
Components
To ensure that the components comply with authoring principles, at the time of authoring.
Each concept must be the source of at least one relationship of type | Is a|
Each concept must have at least one FSN and at least one synonym
All attribute relationships specified for a given concept are valid to use in the given domain (based on the concept model rules defined in the MRCM)
Reference Sets
To check, at the time of authoring, that reference sets and their members are created and modified according to the associated specification and principles.
Common reference set checks
The reference set and its members comply with the reference set pattern specified in the | Reference set descriptor reference set|
Reference set attribute values of type | Component type| are available in either
The extension,
The International Edition, or
A module from another extension on which the given extension depends.
Map reference set checks
The map target must specify a valid code in the target code system
Every source code in a map that uses map rules must
Have at least one group starting with mapGroup 1
End with a "TRUE" rule
Validating the content in an extension is the process of ensuring that all components and reference sets within the extension comply with the authoring principles. As illustrated in the image below, this process involves three main steps: Validation during authoring, post-authoring review, and pre-release validation.
Effective and high quality terminology authoring processes should include thorough automated validation. This is required to ensure that all terminology components added, updated or inactivated in the extension comply with all automatically verifiable authoring principles, including concept model rules, the SNOMED CT logical design and referential integrity constraints. After the authoring process, it is important to also perform a human review of all authored content to ensure that relevant editorial guidelines and principles are followed (including those which may not be able to be automatically checked), and that the updated content is acceptable from an author and user perspective. Finally, automated validation is required before the extension is released to ensure the correctness and consistency of the release as a whole.
The following pages explain each of these key validation steps further.
Human review of all new and updated content in an extension is important to ensure the quality and correctness of the extension. This allows editorial rules that can not be automatically tested to be checked by an author who was not directly involved in the authoring of the given content. Post authoring review should be performed by individuals with both knowledge of SNOMED CT editorial principles as well as adequate clinical knowledge. In some situations, additional national linguistic or modelling guidelines also apply. A reviewer should, for example, be able to assess whether the definition of a concept has been authored correctly. The table below describes a range of different types of post authoring review, and provides some examples of each. For further information, please refer to the editorial guide.
Table: Post authoring review of components and reference sets in an extension
Collaborative authoring and review approaches are recommended to produce high quality content. Examples of authoring and review approaches include:
Single author with single reviewer
One author develops the terminology content. Another author reviews the changes and either accepts them or reports issues that need to be considered and resolved.
Multiple authors with multiple reviewers
Maps
To validate that the map between each SNOMED CT component and the associated codes from the other code system is correct
Review the set of maps to ensure that:
Each mapGroup represents an appropriate set of map rules for the given referencedComponentId
The mapTarget has a sufficiently similar meaning to the referencedComponentId to meet the user requirements of the map (given the associated correlationId)
Dual blind authoring with adjudicator
Two authors work on the same task independently. For example, the authors may both map the same set of concepts to a target code system. Any discrepancy between the work of the two authors is automatically detected, An independent adjudicator then reviews the discrepancies and decides which author's work to approve.
Components
To validate that the components created within the extension comply with editorial guidelines and are clinically correct.
Review fully specified name (FSN) to ensure that it provides an unambiguous linguistic representation of the meaning of the concept.
Review all descriptions to ensure that they each follow editorial guidelines for General Naming Conventions
Review the defining characteristics of new or updated concepts to ensure that:
They each represent a true and necessary characteristic of the meaning of the concept
If the concept is marked as fully defined, that the definition is sufficient to uniquely define the concept
The concept complies with all relevant editorial principles and concept model rules
Reference Sets
All reference set types
To validate that all reference sets meet their user requirements, such as the scope, size, functionality and user acceptance criteria. For more information, please refer to .
Review the reference set to ensure that its quality is sufficient to meet the intended use cases of the reference set
Subsets
To validate that all members of the subset are within the intended scope of that subset, and that no component is missing from the subset that is required to meet the subset's intended purpose.
Review the set of referencedComponentIds to ensure that:
All referencedComponentIds refer to a component that is in the intended scope of the subset.
No component within the intended scope of the subset is missing from the set of referencedComponentIds.
The mapRule is appropriate
The mapAdvice is useful