Importing Release File Data

Importing and Validating Release Files

When working with SNOMED CT, it is critical to ensure that release packages are correctly validated and imported. Proper validation safeguards data integrity and ensures that terminology services, applications, and users can rely on accurate and consistent content. This section outlines the general integrity checks required for all release packages, additional checks for extensions, and the requirements for importing release files.

---

General Release Package Integrity Checks

To validate the integrity of SNOMED CT release packages:

• Consistency of distribution files

  • All imported files must be from the same release.

  • The set of files must be complete and include all mandatory components.

• Delta releases

  • Previously imported data must be from the version immediately prior to the delta release being imported.

• Snapshot or full releases

  • Pre-existing data must be removed before import, or

  • The process must overwrite duplicates so that:

    • A snapshot import does not contain obsolete rows.

    • A full release import matches the full release exactly.

• Component identifiers

  • Must have a valid partition identifier for the type of component.

  • Must include a valid check-digit.

• Field constraints

  • All fields must comply with data type, size, and value constraints defined in the Release File Specifications.

• Concept integrity

  • All concepts must have at least two active descriptions:

    • One Synonym (900000000000013009).

    • One Fully Specified Name (900000000000003001).

  • All active concepts (except the root concept 138875005 | SNOMED CT Concept|) must have at least one active Is a relationship (116680003).

• Other consistency checks

  • May be applied as needed to ensure overall data integrity.

---

Additional Checks for Extension Release Files

When importing an extension, additional checks must be performed to ensure proper installation and compatibility:

• Recognition and approval

  • The extension must be recognized and formally approved by an appropriate authority.

• Compatibility

  • The extension must be based on, or supported by, the currently installed version of the International Edition.

  • Required versions of other dependent extensions must already be installed (or be part of the same import process).

• Module dependencies

  • All dependencies of the extension module must be listed in the Module Dependency Reference Set.

  • Each dependency row must:

    • Match the extension’s moduleId.

    • Have a sourceEffectiveTime that matches the current version of the extension.

    • Reference the correct dependent modules and target effective times.

• Component validation

  • All components must have a valid moduleId for the extension.

  • All component identifiers must:

    • Be unique per effectiveTime.

    • Have a valid partition identifier.

    • Use a namespace identifier appropriate to the extension provider.

    • Include a valid check-digit.

  • All fields must meet data type, size, and value constraints.

---

Importing Release Files

Terminology service providers must ensure that terminology services provide access to all the data in selected versioned views of a selected SNOMED CT edition.

• Applies to all editions and versioned views the service can access.

• Data must support the purposes defined in the SNOMED CT Release File Specifications, though storage format does not need to match the release file structures exactly.

• The simplest approach is to import all files from the full release and/or snapshot release of the required edition.

• Where this is not possible, alternative sources may be used (see below).

---

Alternative Sources for Importing Release Views

Exception	Notes
Importing snapshot data from a full release (same version)	Import only rows with the most recent effectiveTime for each unique id. Discard all other rows.
Importing snapshot data from a full release (later version)	Discard rows newer than the required version date. From the remaining rows, import only the most recent effectiveTime for each unique id.
Importing delta data from a full or snapshot release (same version)	Import only rows with an effectiveTime greater than the previous release date.
Importing delta data between two versions from a full release	Import only rows where: • effectiveTime > start date • effectiveTime ≤ end date. If multiple rows exist for the same id, import only the most recent.
Importing edition data from a multi-edition release package	Import only rows where the moduleId matches the edition’s moduleId or the moduleId of a dependent module.
Importing edition data from multiple release packages	Import only rows where the moduleId matches the edition or dependent modules. If dependencies are missing, import from additional packages. Avoid duplicates (rows with the same id and effectiveTime).

---

Notes

The data structure of each release file is defined in the SNOMED CT Release File Specifications:

• Overview