Purpose

The |Module dependency reference set| represents dependencies between different SNOMED CT release modules. In each case, the dependency indicates which targetEffectiveTime of each particular module a given sourceEffectiveTime of the dependent module requires.

Data structure

The 900000000000534007 |Module dependency reference set| is a String - String reference set which is used to represent dependencies between modules, taking account of module versioning. Its structure is shown in the following table.

Each row in the release files for components and reference set members has a . This refers to the module that the component is maintained in. Each module is either part of the SNOMED International Release or part of a single SNOMED CT Extension. The has a partition-id which indicates whether it is part of the SNOMED International Release and, if not, its namespace identifier indicates the SNOMED CT Extension that it belongs to.

A module is simply a collection of SNOMED CT components maintained as a unit by a single organization. It is the organization 's responsibility to organize the components in each extension that it is responsible for into one or more modules, in a way that best fits its business needs.

A module is represented by a descendant of in the metadata hierarchy. The immediate subtype descendants of represent groups of modules maintained by an organization and subtypes of these can be used to arrange that organizations modules into a number of groups. For example, all modules maintained by SNOMED International will be children of .

At any point in time a component must be in one, and only one module. It is possible for components and reference set members to be moved between modules (subject to constraints explained elsewhere). In this case, a new row is added to the release file with the same but with a new and a new .

Each extension must include one or more modules. Each module must be part of either the SNOMED International Release or one and only one extension. A module may not move from one extension to another over time. If components or reference set members in a module are to be moved from an extension to the SNOMED International Release or to another extension, they must either be added to an existing or newly created module maintained by the destination organization.

The does NOT represent dependencies between module. Instead, module dependencies are modeled using the .

At the point of release, if any component within a module has changed, then a new row must be added to the for each dependency of that module. The of the added rows must set to the date of the new release. The updated records indicate that some components within the module have been updated in this release. If there have been no additions, updates or inactivations of components or reference set members within a module, then a new records need not be added unless there is a requirement to declare that the unchanged module is compatible with a later release of the module(s) on which it dependents.

The recommended practice is for the column to contain the same identifier for all versions of the dependencies between the same pair of modules. This approach means that at any given time only one version of each module has effective dependencies. The dependencies of earlier versions can be reviewed by reviewing a snapshot for the effectiveTime of the earlier release.

The effectiveTime of at least one row for each pair of modules should be the same as the sourceEffectiveTime. Otherwise, there will be a period of time when a snapshot view will not show the dependencies. However, it is theoretically possible for an additional row to be added with a later effectiveTime in cases where an otherwise unchanged release of an extension, declares itself to be compatible with an updated release of the target module (in this case the effectiveTime and targetEffectiveTime are changed but the sourceEffectiveTime remains unchanged.

A module dependency only needs to be inactivated if the dependency is found to be erroneous. This is because, the module dependency is specific to a particular version of the source and target module. Therefore, if that dependency was valid at the outset it remains valid indefinitely in respect of those specified module versions, even if the dependencies between subsequent versions differ.

Module version dependencies are represented using a single . Thus all module dependency rows have the same refsetId ().

It is the responsibility of the organization owning and maintaining a dependent module to identify all modules on which it depends. They do this by adding rows to the within the dependent module. Because these added member must be in the dependent module, the moduleId of the reference set member record is also the identifier of the dependent (source) module.

The column not only indicates that this reference set member is in the specified module, it also indicates that this is the module that is the source of the dependency. As a result, in this reference set the moduleId column is immutable (i.e Mutable=NO). This is an exception to the usual rule and implies that a member of this reference set cannot move from one module to another.

The target module on which the source module depends is identified by the . Like the source module this is also immutable and this implies that if a module ceases to be dependent on another module, a new row inactivating the dependency can be added but the same member cannot be used to represent a different dependency (even if that dependency is a direct replacement of the inactivated dependency). However as noted above,

A module version may depend on one or more other module versions, and many module versions may have a dependency on a single module version. Cyclic module version dependencies are not allowed. If module-A depends on module-B, then module-B cannot depend on module-A.

Dependencies are not transitive and this means that dependencies cannot be inferred from a chain of dependencies. If module-A depends on module-B and module-B depends on module-C, the dependency of module-A on module-C must still be stated explicitly.

Any release should consist of a set of module versions that are certified as being compatible. Each release should also identify other module versions that it is dependent on even when these are outside the scope of the release. For example, the dependencies of modules in an Extension on the International Release must be stated.

Dependencies are specified between module versions, not just dependencies between modules. Therefore, it is possible to specify a dependency from a module released on one date to an earlier version of another module. The version of the dependent module is specified by the and the version of the module on which it depends is specified by the .

The following metadata in the "Foundation metadata concept " hierarchy supports this reference set

The table below shows the descriptor that defines the structure of the .

Example : The table below holds example entries for the in a snapshot view of the January 2014 SNOMED CT International Release .

This SNOMED CT International Release contains three modules:

• which has no dependencies;

• which depends on the ; and

• which depends on both the other modules.

In this case all the 2014-01-31 modules depend on 2014-01-31 versions of the other modules. However, in some case a module may depend on an earlier version of another model (e.g. an extension module may be releases after the SNOMED CT International Release to which it applies).

Dependencies are not transitive. The fact that is dependent on may seem to imply a dependency on . However, in practice all dependencies must be explicitly specified, not just immediate dependencies.

A SNOMED CT International Release includes three distinct release types. Table 3.2-1 describes the release types and the differences between them.

SNOMED CT Release Types

There are practical use cases for each Release Type.

• The full release allows access to all versions of the release. This is valuable for reviewing data entered using earlier versions and more generally supporting change management.

• The snapshot release only includes the latest version of each component. This can be useful to optimize access to the current version but does not provide access to earlier versions.

• The delta release only includes changes made between one version and the next. This provides a simple way to identify new and changed components to support change management and can also be used to update the previous version of the full release to the new version of the full release. However, the delta release cannot be used as a stand alone resource.

When considering which release type to use, it is worth noting that delta and snapshot views can be readily generated from the full release type. For this reason organizations that maintain SNOMED CT extensions are required to provide the full release type, while distribution of the other release types are optional.

The Transitive Closure is the complete set of relationships between every concept and each of its super-type concepts, in other words both its parents and ancestors.

A transitive closure table is one of the most efficient ways to test for subsumption between concepts.

Snapshot Transitive Closure File

Transitive Closure Perl scripts can be used to generate a snapshot view of the transitive closure from the snapshot release of the Relationship. The output of such a script would usually adhere to the following file structure. Note that the primary key for this table consists of both columns.

Transitive Closure File - Detailed Specification

A versioned view of the Transitive Closure can also be generated by combining the snapshot views for different effective times and removing redundant rows (e.g. where the transitive closure has not changed between release versions). The generated file could then be represented using the example specification below. Note that the unique key for this file would consist of the subtypeId, supertypeId and effectiveTime.

Versioned Transitive Closure File - Example Specification

The release file naming convention specified in this section applies to all SNOMED International release files starting with the January 2010 International release. The release package naming convention specified was added subsequently to provide additional clarity through a structured name applied to the folder (and zip archive name) containing a set of release files. This package naming convention first applied to releases by SNOMED International during 2017.

These naming specifications provide the following benefits:

• A consistent naming convention across the International edition and each National edition.

• Predictable file naming, providing a stable structure for naming over time between releases.

• A standard way to identify the source country and namespace of the organization responsible for a release file.

• A consistent mechanism for representing version of release files and packages of release files.

• An human readable way to identify the content of a file, at a summary level.

• A mechanism for identifying the type of information stored in a release file (e.g. documentation, tooling, etc.).

• Guidance on file naming for release files in non-English extensions.

• Assurance that file names will be unique across the International release and releases from individual National release centers and across separate releases from each center over time.

Quality Assurance checks, performed during the International release process, ensure that this naming convention is enforced. Equivalent checks should also be performed as part of each National Release Center's release process.

This section summarizes the ways in which SNOMED CT concept definitions are represented. It outlines the rationale for changes to the way in which the stated view of concept definitions is represented. The changes are occurring during a transitional period that started in July 2018 and is due to be completed in 2019.

The Concrete Value file holds one relationship per row. Each relationship is of a particular type, and has a source concept and a value. An example of a relationship taking a concrete value is given below:

322236009 |Product containing precisely paracetamol 500 milligram/1 each conventional release oral tablet (clinical drug)| 1142135004 |Has presentation strength numerator value (attribute)| #500 where:

• 322236009 |Product containing precisely paracetamol 500 milligram/1 each conventional release oral tablet (clinical drug)| is the source concept;

• 1142135004 |Has presentation strength numerator value (attribute)| is the relationship type concept and;

• #500 is the value

Concrete Value file - Detailed specification

In general, the rules and behaviour of the Concrete Value file is identical to that of the Relationship file, with the destinationId column replaced with a value column.

Only one relationship record with the same id field will be current at any point in time. The current record will be the one with the most recent effectiveTime before or equal to the point in time under consideration.

If the active field of this record is false ('0'), then the relationship is inactive at that point in time. If the active field is true ('1'), then there is a relationship between the SNOMED CT concepts identified by sourceId and value.

The sourceId, typeId, value, relationshipGroup, characteristicTypeId and modifierId will not change between two rows with the same id. In other words, they are immutable. Where a change is required to one of these fields, then the current row will be de-activated (by appending a row with the same id and the active field set to false) and a new row with a new id will be appended. The relationshipGroup field is used to group relationships with the same sourceId field into one or more logical sets. A relationship with a relationshipGroup field value of '0' is considered not to be grouped. All relationships with the same sourceId and non-zero relationshipGroup are considered to be logically grouped.

The relationshipGroup field will be an unsigned Integer, and will not be limited to a single digit value. There is no guarantee that they will be assigned sequentially, and the values will not be unique across concepts.

The value field is restricted to 4096 (4K) characters in length.

• S.

Overall Package Naming Pattern

_{SnomedCT_[Product][Scope(optional)][Format(optional)]_[ReleaseStatus]_[ReleaseDate]T[ReleaseTime][TimeZone]}

_{e.g. SnomedCT_InternationalRF2_PRODUCTION_20250701T120000Z.zip}

Package Name Elements

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

Several description logic features, which would improve the completeness and precision of classification, cannot be represented in individual concept definitions.

Property Characteristics

If particular characteristics of the attributes used to define concepts are identified, this can enhance classification. For example, knowing that an attribute like 123005000 |Part of| is transitive would allow the classifier to make infer that an entire finger is part of the entire upper limb.

Property Chains

Property chains are in some ways similar to transitivity but involve more than one attribute. For example, 127489000 |Has active ingredient| can be declared to chain with 738774007 |Is modification of|. In that case, suppose the definition of 387307005 |Calcium carbonate| includes 738774007 |Is modification of| of 5540006 |Calcium|, a DL classifier can determine that a tablet that 127489000 |Has active ingredient| = 387307005 |Calcium carbonate| by definition has a modification of 5540006 |Calcium| as its active ingredient. Thus in the example shown the classifier can determine that |calcium carbonate tablet| is a subtype of |calcium tablet|.

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

Associations between Component Files

The logical model of associations between the components in the release files is shown in the Figure below The component class represents columns present in all three component files. The individual classes (description, concept and relationship) only show the additional columns present in those files. The colored lines between descriptions and concepts and between relationships and concepts represent the link between the foreign keys (shown in bold) and the id of the concept. These provide the functional connections between components described in this document. The grey lines indicate additional links between columns that are populated with concept identifiers that provide enumerated values.

A More Complete View of Release File Associations

The below Figure provides an extended view of the associations between release files following changes complete in July 2019 release of SNOMED CT. These changes enable SNOMED CT to use enhanced description logic features and resulted in a significant change to the way in which the stated view of concept definitions are represented. However the changes did not significantly affect the structure and associations between the main component files shown in the Figure above.

The following diagram provides an extended view of the associations between release files following changes complete in July 2019 release of SNOMED CT . These changes enable SNOMED CT to use enhanced description logic features and resulted in a significant change to the way in which the stated view of concept definitions are represented. However, the changes did not significantly affect the structure and associations between the main component files shown in the diagram above.

Each concept is represented by a row in the Concept and the concept is identified by the id column in that row. There can be more than one row with the same id but with different effectiveTime values, in which case each of these rows represents a version of that same concept. Thus each row represents a version of a clinical concept.

Each concept has two or more descriptions associated with it:

• At least one Fully Specified Name; and

• At least one synonym.

Each description is represented by a row in the description file and is identified by the id column in that row. There can be more than one row with the same id but with different effectiveTime values, in which case each of these rows represents a version of that same description. Thus each row represents a version of a description. Each description applies to one concept to which it is linked by the conceptId. All versions of a description must relate to exactly the same identified concept (i.e. the conceptId must not change between versions).

Each relationship, from a source concept to a destination concept, is represented by a row in the relationship file. There can be more than one row with the same id but with different effectiveTime values, in which case each of these rows represents a version of that same relationship. Thus each row represents a version of a relationship. The source, destination and type each relationship are identified respectively by the sourceId, destinationId and typeId columns. All versions of a relationship must have the same sourceId, destinationId and typeId. The typeId refers to concept, that is also held within the concept file. The only concepts that can be used as the relationship typeId are or concepts that are subtypes of .

The most basic form of relationship is the |is a| relationship. This relationship states that one concept is a subtype of another concept. Each subtype concept is connected to its parent subtype(s) by relationships with the typeId 116680003 |is a| and this form the main SNOMED CT hierarchy. In this hierarchy, a child concept may have more than one parent concept. The root of the hierarchy is , which has a set of top level children, each forming its own sub-hierarchy.Relationships with typeid values that are subtypes of |Concept model attribute| are referred to as attribute relationship and contribute to the formal definition of the source concept.

This section briefly outlines two distinct types of views of SNOMED CT concept definitions. More detailed illustrations of some of the points on this page are provided in Stated and Inferred Definitions - Examples.

Stated View of Concept Definitions

SNOMED CT concepts are defined by assertions made by SNOMED CT authors. The concept definitions asserted by SNOMED CT authors are known as the stated view.

The stated view is a representation of concept definitions consisting only of assertions made or revised by SNOMED CT authors.

Description Logic Classification

A description logic classifier can apply logical rules to the stated view to create inferences. The end result of this process is an inferred view of concept definitions.

Inferred Views of Concept Definitions

The inferred view is a representation of concept definitions that is logically derived by applying a description logic classifier to the stated view.

Choosing the View to Use

The decision on whether you need access to the stated view and/or inferred view depends on your answers to the following questions.

The following subsections provide details of the format of the SNOMED CT component release files.

• Concept File Specification

• Description File Specification

• Relationship File Specification

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.

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

• All modules , except the , have dependencies on other modules specified by the

A Boolean field that specifies whether an identified component or is an active from the point in time specified by the effectiveTime .

Note: Field name in SNOMED CT Release Format 2.

SNOMED CT core release files include metadata concepts that represent each of the allocated namespace-identifiers.

A namespace concept has the following characteristics:

• It is a subtype child of 370136006 |Namespace concept|

• The fully specified name of the concept has the term

  • Extension Namespace {nnnnnnn}(namespace concept)

• A synonym associated with each concept has the term

  • Extension Namespace {nnnnnnn}

• Where appropriate further synonyms may be included to identify the nature of the responsible organization.

As the release file formats contain a number of concept enumerations, it is necessary to define sets of concepts that represent the allowed values. As well as the enumerated values, other metadata supporting the extensibility mechanism and the concept model is required.

The concept is a subtype of the root concept (138875005 |SNOMED CT Concept|), and contains the metadata, supporting the release.

The subtypes of |SNOMED CT Model Component (metadata)| are described in the following table and the top three levels of the hierarchy are shown in the figure below this.

SNOMED CT Model Component (metadata)

An Annotation Reference Set field containing additional information linked to a SNOMED CT component .

Note: Field name in SNOMED CT Release Format 2.

• (Deprecated)

The Concept File holds the clinical concepts that make up SNOMED CT. A concept is given meaning by its Fully Specified Name, which is held in the Description. A concept may be distinguished from or refined by association with other concepts using relationships, which are held in the Relationship.

As illustrated in Figure 2.3.4.1-1, each defining relationship is represented by a row in the relationship file. The concept being defined is referenced by the sourceId, the concept that represents the type of relationship (attribute) is referenced by the typeId and the destinationId refers to the concept that represents the value of that attribute.

The relationship file also has a relationshipGroup which allows two or more defining relationships to be grouped together.

The definitionStatusId of the source concept, indicates whether the combination of defining relationships provide provides sufficient definition of that concept.

Example of stated view of |Excision of stomach structure| represented by stated relationships

Section , illustrated the following three points, which are not supported by the current use of relationships to represent concept definitions:

1. A concept may have more than one sufficient definition.

   • Use of relationships only supports representation of a single sufficient definition for each concept. If a concept is marked as sufficiently defined, all it relationships are considered to be part of its sufficient definition.

2. A concept may have a sufficient definition that includes some assertions that are not necessary conditions

Section , identifies other useful features that are supported by description logic tools but cannot be represented using only SNOMED CT.

Relationships can be distributed in an easy to understand relational file structure. The relationship file has been an established part of the standard set of SNOMED CT release files since the first release in 2002, with a revision in 2011-2012 to use RF2 to enhance versioning capabilities. Relationships can be retrieved, displayed and processed using widely understood techniques such as SQL making it easy to join the relationships to the concepts to which they relate.

The stated view of concept definitions needed to be enhanced to allow more flexible and expressive use of description logic. The structure of the relationship file was not suitable for this and a decision was made to adopt the OWL Functional Syntax so that new DL features could be added over time. As a result, the stated relationship file was deprecated.

Information about the new representation for the stated view is included in section .

The current relationship file continues to be released containing the inferred view. Due to limitations of the relationship file format, the inferred definitions do not contain the more sophisticated DL features. The relationship file:

• only contains necessary conditions

• does not distinguish between multiple sufficient definitions, regardless of whether each necessary condition is part of any of the sufficient definitions.

Nevertheless, the end result is still more complete and precise than the previous content of this file. The reason for this is that the inferred relationships in the file is generated by processing the enhanced stated view. Details of the way the inferred relationships are generated from the stated view are documented in .

This section describes four categories of reference set types, each of which contain several sub-types.

The SNOMED CT Release File Specification formally defines the format in which SNOMED CT is provided to licensees (Affiliates). For information about SNOMED CT licensing and availability of release files please refer to the Member Licensing and Distribution Service (MLDS) - .

The data type is a 64-bit positive integer.

When rendered as a string an SCTID must always be represented using decimal digits and when rendered as a string has a maximum permitted length of 18 digits and a minimum length of 6 digits.

Note : Leading zeros are always omitted from the string rendering of an SCTID. For example the value "101291009" must not be rendered as "0101291009".

If the partition-identifier indicates a long format , the seven-digits immediately to the left of the partition-digit are a namespace-identifier. The namespace-identifier is an integer value, left padded with 0 s as necessary to ensure there are always seven digits in the value. The namespace-identifier does not hold meaning.

Each organization that is authorized to generate SCTID is allocated a namespace-identifier by the SNOMED International. Each allocated namespace is represented in the Namespace Concept metadata sub-hierarchy, released as part of the International release (see details in The Namespace hierarchy ).

To check the validity of a SNOMED CT Identifier, please visit the SNOMED International Component Identifier Service, which can do this check for you - https://cis.ihtsdotools.org/info

Provide Feedback

Overall Naming Pattern

The basic pattern for SNOMED CT release file names consists of five elements, each separated by an underscore (" _ ") and followed by a full stop (" . ") and a file extension:

_{[FileType]_[ContentType]_[ContentSubType]_[CountryNamespace]_[VersionDate].[FileExtension]}

Each element in the above structure is described in more detail by table in the following section.

FileType Element

The FileType element of the filename designates the type and intended use of the release file. It consists of a 3 to 5 alphanumeric code with letters in lowercase.

The code comprises the following three sub-elements. The Type sub-element is required in all cases, other elements are required where relevant and otherwise omitted.

FileType Element - Sub-elements and Permitted Values

The ContentType element is mandatory for all FileTypes. It describes the content and purpose of the file. It consists of 2-48 alphanumeric characters in camel case.

The content of this element depends on the first element (FileType) of the filename, as described below:

ContentType Element - Permitted Values for FileType "sct"

ContentType Element - Permitted Values for FileType "der"

ContentType Element - Permitted Values for FileTypes "doc","res" and "tls"

The ContentSubType element is mandatory for all FileTypes. It provides additional information to describe the content and purpose of the file, including the language/ dialect, where appropriate. Its format is 2-48 alphanumeric characters in camel case (except for the capitalization rules specified below for languagecode). Hyphen (" - ") is a permitted character in conjunction with a language code, as described below.

ContentSubType Element - Sub-elements and Permitted Values for FileTypes "sct" and "der"

ContentSubType Element - Sub-elements and Permitted Values for FileType "doc"

ContentSubType Element - Sub-elements and Permitted Values for FileTypes "res" and "tls"

Examples of ContentSubType

• der2_cRefset_AttributeValueSnapshot _INT_20180131.txt

  • Summary=AttributeValue (type of refset),

  • Release type=Snapshot,

The CountryNamespace element is mandatory for all FileTypes. It identifies the organization responsible for developing and maintaining the file. It is a string of 2 to 10 alphanumeric characters consisting of the two sub-elements described below. At least one of these two sub-elements must be present. SNOMED International or a National Release Center (NRC) may optionally include both sub-elements where they consider this to be appropriate.

CountryNamespace Element - Sub-elements and Permitted Values

The VersionDate element is mandatory for all FileTypes. It identifies the SNOMED CT version with which the file is intended to be used. Its format is an 8-digit number in the pattern "YYYYMMDD", in compliance with the standard.

• For Data Files(sct ,der or res), and for Documentation (doc) with a status tag value of "Current ", the value of this element should always be the same as the SNOMED CT version date with which the file is associated.

• For other file types, the VersionDate element will identify the (past) date of the SNOMED CT release for which the file was intended. A file distributed with a past version date has not been updated to reflect changes to SNOMED CT since that date, nor has it been validated as correct or appropriate for current use.

The extension element of the filename identifies the file format (encoding convention) of the file, such as " txt ", " pdf " or " zip ". It has a format of 1-4 alphanumeric characters.

File Extensions Applicable to Different FileTypes

• ​Simple Reference Set​

• ​Attribute Value Reference Set​

  • Component Inactivation Reference Sets​

• ​

  • ​

• ​

• ​

• ​

  • ​

  • ​

• ​

This section outlines the logical model at the heart of the design of SNOMED CT. It then provides a summary of the ways in which different elements of this logical model are represented in release files. Finally, it provides an overview of the concept definitions that provide the semantic foundation for meaningful processing of clinical information.

This Figure provides a high-level view that illustrates the concept-centric design of SNOMED CT. The subsections below describe the different elements illustrated here.

Concepts

A concept is defined as a clinical idea to which a unique concept identifier has been assigned.

Notes

• SNOMED CT concepts are distributed in the concept file.

• Concepts are associated with descriptions that contain human-readable terms describing the concept.

• Concepts are related to one another by relationships and OWL axioms that provide a formal logical definition of the concept.

Authors create a new SNOMED CT concept for each distinct clinical meaning added to the terminology. Every concept is uniquely identified and this identifier allows the concept to be unambiguously recorded in a clinical record. The concept identifier also allow other related information to be linked to a specific concept. This linked information includes human-readable terms and formal concept definitions.

A description is defined as an association between a human-readable phrase (term) and a particular SNOMED CT concept.

• Each description is represented by a separate row in the Description File.

• Each description has a unique identifier and connects a concept with a term of a specified description type. All concepts have descriptions with description types fully specified name and synonym. Other description type can be defined and may be applied to some concepts.

Terminology authors create a set of descriptions each of which links a term to an identified concept. The linked terms must all be legitimate ways to label or refer to the concept to which they are linked. Translators also create descriptions to link appropriate terms in other languages or dialects to the same concepts. Since usage of terms varies depending on languages and dialects, the design also support addition of information about which descriptions contain terms that are preferred or acceptable in each language or dialect.

Terminology authors associate each concept with a formal stated definition. This stated concept definition consists of description logic axioms that are known to be true for that concept (for example stating that appendectomy is a procedure that applies the method excision to the appendix structure). Because these axioms are stated in a formal way, a description logic classifier can be applied to all the axioms in the terminology to generate additional logical inferences. Therefore, the overall model is designed to enable representation of both the original stated concept definition and the inferred view of the concept definition.

In practice, a description logic classifier can generate more than one inferred view, depending on whether all logically inferred axioms are retained and on whether some types of redundant axioms are omitted from the inferred view.

The SNOMED CT design also enables a wide range of customizable information to be linked to the concepts and descriptions mentioned above. The extensible design of SNOMED CT enables consistent representation and distribution of:

• subsets of concepts or descriptions

• ordered lists of concepts or descriptions

• language preferences associated with different descriptions

This section briefly outlines different aspects of assertions made about concepts and the extent to which they are necessarily true or form part of a sufficient definition of the concept. More detailed illustrations of some of the points on this page are provided in .

The stated view of concept definition consists of one or more assertions made by SNOMED CT authors.

Each time an assertion is made about a concept, an author must decide if that assertion is a necessary condition. If the assertion is always true for that concept and its subtypes, it is a necessary condition.

• This implies that for all instances of that concept or its subtypes, the assertion must be true, even if it has not been explicitly stated.

The penultimate two-digits of the (second and third from the right), are the partition identifier.

The partition identifier indicates the nature of the component identified. This allows the identifier of a description to be distinguished from the identifier of a concept.

The partition identifier also indicates whether the SCTID contains a namespace identifier (long format) or follows the short format applicable to identifiers of components that originated in the International Release. Identifiers of components that originated in the International Release of SNOMED CT have one of the following partition identifier values:

Partition identifier Values for Short Format SCTIDs

National Release Centres and others may create additional reference sets. A namespace is required to create a new reference set, as each reference set is defined by a concept. The concept's FSN and a synonym are used to name the reference set. Where a new reference set is created against an existing pattern, then the following naming convention should be used (where the text "Specific name " is to be replaced by the specific name of the reference set).

• FSN = Specific name attribute value reference set (foundation metadata concept )

• PT = Specific name attribute value map

Purpose

A |Simple type reference set| allows a set of components to be specified for inclusion or exclusion for a specified purpose. This type of reference set represents an extensional definition of a subset of SNOMED CT components. Thus it can be used to fully enumerate a subset of concepts, descriptions or relationships.

See also Query specification reference set, which can be used to represent an intensional definition of a subset of SNOMED CT components. In an intensional definition, the members of the subset are specified by rules rather than by enumerations (e.g. all subtypes of a specified concepts).

Reference Set Data Structure

A Simple Reference Set does not have any additional fields.

Simple Reference Set - Data Structure

Simple References Sets are subtypes of in the metadata hierarchy.

Simple Reference Sets in the Metadata Hierarchy

The table below shows the descriptor for a specific reference set that follows the pattern.

Refset Descriptor rows for the Simple Reference Set Type

Example Data for a Simple Reference Set

Representation of the Logical Model - Before July 2018

The Figure below shows how SNOMED CT release files prior to July 2018 represented the various elements in the logical model. The revised representation of these elements are shown on in Representation of the Logical Model.

Release file representation of the logical model (before update)

The , was used to represent the stated view of relationships prior to a transition process between July 2018 and July 2019. In July 2019 this file became obsolete and was completely replaced by two (the OWL axiom reference set file and the OWL ontology reference set file).

Figure 1 shows the associations between files that represent the stated and inferred views prior to the transition. It shows the associations between the release files that following these changes.

The stated relationship file is now obsolete as it has been completely replaced by two (the OWL axiom reference set file and the OWL ontology reference set file).

During the transitional period the stated relationship file continued to be distributed, but the OWL axiom reference set introduced advanced aspects to concept definitions which could not be represented in the stated relationship file.

In January 2012 the SNOMED International switched from the original Release Format (used for SNOMED CT distribution since 2002), to the more flexible and consistent Release Format 2 (RF2). This means that from that date onward the primary source data for the SNOMED CT International Release is maintained and distributed in the RF2 format.

The SNOMED International recognizes that, while implementers will which to benefit from the features of the new format, there is inevitably a transitional period during which both format are in use. Therefore, the SNOMED International provides the following resources to support users whose system do not yet support SNOMED CT Release Format 2:

• Release Format 1 files will continue to be included in the International Release for a limited period

  • These files are not the authoritative version of SNOMED CT but are generated from the authoritative RF2 data using a software utility developed for this purpose.

  • The resulting RF1 data retains the functionality of the original release data but does not support any of the features of RF2. While all the clinically relevant SNOMED CT hierarchies are identical in both releases, the additional "Metadata Hierarchy" added as part of the RF2 upgrade is not included in the RF1 converted data. In addition there are some cases where Cross Maps

The "RF2 to RF1 Conversion Tool" and the "RF1 Compatibility Package" are available for Members and Affiliates to download in the same way as the SNOMED CT International Release.

These files are located in the top-level directory of the SNOMED CT Release packages, and contain various information related to the specific Release package in which they reside.

release-package-information-.json file - Detailed Specification

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

This section of the SNOMED CT Release Files Specification provides details of the structure and content of reference set files distributed by SNOMED International as part of the SNOMED CT International Release. This is also the standard format in which producers of SNOMED CT extension are required to distribute any reference sets that they produce to their sublicensees.

The files specified by this section form part of SNOMED CT Release Format 2 (RF2) - the standard release format for SNOMED CT since 2012. RF2 is a flexible, simple stable format with support for robust versioning. It enables innovation through adaptations to cater for changing requirements. This format is only mandated as the standard distribution format for SNOMED CT International and SNOMED CT Extensions. Internal representations of SNOMED CT resources within an application may vary provided such representations faithfully retain the information represented in the release files.

Reference set data structures provide a generic mechanism for configuration and extensibility of SNOMED CT to a wide range of different requirements. Reference sets act as building blocks that provide a common foundation that enables those developing SNOMED CT extensions to customize the way their users interact with SNOMED CT. The flexibility offered by reference sets also enables adaptation of existing system to support changing requirements.

The string of digits to the left of the partition-identifier (in a short format ) or to the left of the namespace-identifier (in a long format SCTID) is referred to as the item-identifier.

These values are available to uniquely identify an individual entity within the specified partition or namespace. The same item-identifier can be allocated in each partition of each namespace as the SCTID is rendered unique by the partition-identifier and the namespace-identifier. For components in the International Release of SNOMED CT, item-identifiers will usually be issued in the arbitrary order in which components are added to SNOMED Clinical Terms. However, due to management of the editing process the sequence of issued item-identifiers may be discontinuous.

SNOMED Clinical Terms Components are identified and referenced using numeric identifiers. These identifiers have the data type SCTID (SNOMED CT Identifier).

The SCTID data type is 64-bit integer which is allocated and represented in accordance with a set of rules. These rules enable each SCTID to refer unambiguously to a unique component. They also support separate partitions for allocation of Identifiers for particular types of component. In the case of components that originate in an Extension, the SCTID also supports separate namespaces that distinguish between different issuing organizations.

Provide Feedback

Purpose

The 900000000000538005 |Description format reference set| specifies the text format and maximum length of each supported description type. This permits additional description types to be specified in future in addition to the three existing description types ( synonym, fully specified name and textual definition).

Data structure

The 900000000000538005 |Description format reference set| is a C-I ( component- Integer) reference set which is used to specify the length and format of the terms in descriptions of this description type. Its structure is shown in the following table.

Description format reference set - Data structure

The following metadata supports the description format reference set:

Description Format Reference Set in the Metadata Hierarchy

The table below shows the descriptor that defines the structure of the .

Refset Descriptor rows for Description Format Reference Set

This example holds the all the members of the in the SNOMED CT International Release for July 2014. Other members may added to future versions of the International Release if new description types are introduced. Owners of Extensions that support additional description types must also add members to the .

Sample Content from the Description Format Reference Set

Purpose

An 900000000000521006 |Association type reference set| represents a set of unordered associations of a particular type between components.

Data structure

An Association reference set is a reference set used to represent associations between components. Its structure is shown in the following table.

Association Reference Set - Data Structure

The following metadata supports this reference set:

Association Reference Sets in the Metadata Hierarchy

- this has many subtypes

See for an example of the reference set description and data representation in an association type reference set.

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).

• Field names are represented using lower-camel-case

  • First letter of name is lower case

  • First letter of each words apart from the first word in the name is upper case

• The name, datatype and usage of the fields in each file are specified in the following sections of this guide

  • .

This section describes SNOMED CT Release Format 2 (RF2), to be used for official production releases of SNOMED CT. This format is not mandated for internal terminology development usage or as an interchange mechanism between terminology development systems. RF2 provides a format that is flexible, unambiguous and useful. It was designed to strengthen SNOMED CT by providing a simple and stable format that enables innovation through adaptations to cater for changing requirements.

The component release files are defined in the following sections:

• Associations Between Release Files

• File Format Specifications

Background

SNOMED CT is the most comprehensive and precise clinical health terminology product in the world. It has been developed collaboratively to ensure it meets the diverse needs and expectations of clinicians worldwide and is accepted as a common global language for health terms. SNOMED CT enables meaning-based retrieval and processing of clinical data because it applies description logic techniques to represent the meaning of clinical concepts. As a result, patients and healthcare professionals benefit from improved health records, clinical decisions and analysis, leading to higher quality, consistency and safety in healthcare delivery.

SNOMED International distributes SNOMED CT to its licensees as a package of release files that can be loaded into software applications that enable and optimize access to the terminology.

Purpose

This document provides the formal specification of the file structures in which SNOMED CT is distributed. The specified file structures apply to the releases of the SNOMED CT International Edition, and to SNOMED CT extensions distributed by Members and Affiliates .

Audience

The intended audiences for this guide are those involved in the creating or consuming SNOMED CT release files. This includes:

• SNOMED International staff involved in creating or quality assuring SNOMED CT release files.

• National Release Centers and Affiliates that create, maintain and distribute SNOMED CT extensions.

• Software designers and developers responsible for SNOMED CT enabled software applications that need to access data provided in SNOMED CT release files.

• Anyone interested in a detailed understanding of the logical design of SNOMED CT and way that logical design is represented in release files.

Notes

This section outlines some of the features of concept definitions and the impact of different ways of representing concept definitions on the precision and completeness of those definitions. This section has been kept as brief as possible and is only intended to raise awareness of the changes. For those interested in understanding more about each of the topics mentioned, a more detailed appendix is provided which illustrates each of the points made in this section.

The permissible value for the s are limited by the following rules:

• Only positive integer values that are greater than 105 and less than 1018 are permitted.

• The only valid renderings of the identifier value are String of decimal digits (0-9), commencing with a non zero digit.

Each identifies a SNOMED CT component. The identifier itself does not contain information related to the meaning of a concept or description. This means it is not possible to infer anything about the meaning of a concept from the numeric value of the identifier or from the sequence of digits. The meaning of a concept can be determined from relationships to other concepts and from associated descriptions that include human readable terms.

The SCTID does however have a structure which includes valuable information about the nature and source of the identified component and the validity of the identifier. This structure supports the following features:

• Check-digit validation of the identifier.

A field in a that indicates the acceptability of a Description in the language or dialect specified by that Reference Set . Values include "preferred" and "acceptable".

Note: Field name in a

The basic reference set file structure enables representation of subsets fo SNOMED CT components. However, the reference set format is extensible, allowing it to be used for a wide range of other purposes. For more details about the requirements that reference sets can address please see the .

The basic reference set structure can be extended by adding one or more fields. Each of these fields will hold additional specific values related to each member. Three general data types are supported in the additional columns. These are

• Integer

• String and