This subsection explains features that apply to all SNOMED CT release files.

• General Structure of Release Files

• Release File Data Types

• Fields Present in All Release Files

The following rules apply to all SNOMED CT Release Files.

• SNOMED CT Release Files are UTF-8 encoded, tab delimited text files.

• Each line, including the final line, ends with a carriage return character (hex 0D) followed by a line feed character (hex 0A).

• The first line of each file, contains the names of each column (also know more generally as a field).

Each component has an associated active field, which can take values of true (1) or false (0). The meaning of this flag is described by component type in the following table:

Behavior of Active and Inactive Components

The following data types are used in the release files:

Data Types Used in Release Files

Concept enumeration is the a set of SNOMED CT concept identifiers used to represent values for a property of a SNOMED CT component or reference set member.

Notes

• Concept enumeration serves the same purpose as more general approaches to providing enumerated lists of values (i.e. assigning a number to a value). However, the use of SNOMED CT concept identifier allows access to the human readable meaning of each enumeration using descriptions in the same way for other concepts.

• The SNOMED CT concepts used to represent concept enumerations are usually subtype children (or descendants) of concepts in the SNOMED CT metadata hierarchy. Each possible value is represented by a single child concept. This allows updates to the permitted values to be tracked using the component history mechanism.

Example

Concept enumerations for description.typeId:

• 900000000000446008 |Description type (core metadata concept)|

  • 900000000000003001 |Fully specified name (core metadata concept)|

  • 900000000000013009 |Synonym (core metadata concept)|

Concept enumeration values (subtypes of 900000000000442005 |Core metadata concept|

The first four columns in all release files are shown in Table 3.1.3-1. The next three sections of the specification explain the ways in which these fields are used to support identification, versioning and modularization.

Fields present in all release files

The effectiveTime and active fields in the release file enable the use of a "log style" append-only data model to track all changes to each component, providing full traceability. Once released, a row in any of these files will always remain unchanged. Historic data is supplied in the RF2 release files, dating back to the first release in RF1 format in 2002.

In order to change the properties of a current component a new version of that component is created with the same identifier. This done by adding a new row to the relevant release file, with the column values updated to represent the changes. The active field must be set to true and the timestamp in the effectiveTime field indicating the nominal date on which the new version was released. Note that the existing row is not changed in any way.

To inactivate a component, a new row is added, containing the same data as the final valid version of the component, but with the active field set to false and the timestamp in the effectiveTime fi eld indicating the nominal date of the release in which the final version ceased being valid. Note again that the existing row is not changed in any way.

Where editorial policy does not allow a particular property of a component to be changed whilst keeping the same Identifier, the component as a whole is inactivated (as described above), and a new row added with a new id, the effectiveTime set to the nominal date of the release in which this version of the component became valid, and the active field set to true.

It is thus possible to see both the current values and any historical values of a component at any point in time.

New content, changes and inactivations must have the effectiveTime for the release that it appears in. Pre-releases for testing may set the effectiveTime as the date of the future scheduled release but in general the effectiveTime must not be later that the scheduled release data, Where there is a business requirement for specifying a future activation date for some components, this may be represented using reference sets.

Each SNOMED CT component is managed and maintained in a module identified by its moduleId field.

A SNOMED CT module is defined as a group of SNOMED CT components and/or reference set members managed, maintained, and distributed as a unit.

Notes

• Components and reference set members that are part of the same module share the same moduleId value.

• All modules , except the 900000000000012004 | SNOMED CT model component module| , have dependencies on other modules specified by the Module Dependency Reference Set.

  • components and reference set members, that are part of the same module, share the same moduleId value.

  • components and reference set members are part of only one module , at any given time.

• The organization responsible for maintaining an extension must:

  • create and maintain at least one module identified by a moduleId that it has created;

  • apply a moduleId that it has created to all components and reference set members in its extension ;

• The organization responsible for maintaining an extension may:

  • create and maintain multiple modules ;

  • organize its components and reference set members within the modules it manages in a way that best meets its business needs;

  • move a component or reference set member between its modules by creating a revised version of that component or reference set member with a different

• Components and reference set members may be moved between modules maintained by different organizations. However, such moves must only be made:

  • with the consent of the organizations responsible for both the source and target modules; and

  • in accordance with rules specified by SNOMED International.