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
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
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 Validation
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
Full release files
Component Validation
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
At least one active description of type
At least one active relationship
Snapshot release files: the id is unique, since each component appears only once, reflecting its current (most recent) state.
Delta release files derived from two consecutive releases, or from a snapshot: the id is unique, since a component can have changed at most once between those two points.
Delta release files derived by comparing two arbitrary (non-consecutive) versions of SNOMED CT (for example, using the delta generator tool) the combination of id and effectiveTime is unique, since a component may have changed more than once between the versions being compared, resulting in multiple rows sharing the same id.
A transitive | Is a| relationship to the root concept
A definitionStatusId which refers to an active descendant of | Definition status|
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 | Attribute|
characteristicTypeId and modifierId must refer appropriate active metadata concepts
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
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