These files provide standardized ways of providing users with Metadata regarding the Release Package and the SNOMED CT components contained therein.
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
effectiveTime
String
Specifies the inclusive date at which the package has been versioned
Note : In distribution files the effectiveTime should follow the short ISO date format (YYYYMMDD)
previousPublishedPackage
String
The name of the last Release package to have been published for this specific SNOMED CT Product
licenceStatement
String
The licence statement that applies to this particular version of the Product, and which must be adhered to when using the package.
languageRefsets
String
Details of all language refsets included within the package (eg) { "id": "900000000000508004", "term": "Great Britain English language reference set" }, { "id": "900000000000509007", "term": "United States of America English language reference set" }
packageComposition
String
essentialComponents
String
Any information useful to the users, regarding components that are a mandatory part of each version of the package.
optionalComponents
String
Bespoke fields can be created in this section in order to provide users with any additional information that may be specific about this particular Product, especially in regard to components that might (but don't have to) be included in each version of the package. See below for examples:
MapDirectionality
String
States which direction each map file is mapped in (eg) SNOMED to external product, or external product to SNOMED
SNOMEDMapSource
String
The version of SNOMED CT that the map is based upon (eg) SNOMED CT version 20250701, released July 2025
externalMapSource
String
The version of the external product upon which the map is based (eg) Orphanet version July 2025
dependency
String
The external product version upon which this package is dependent
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:
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.
id
SCTID
Uniquely identifies the relationship.
NO
YES
(Full/ Snapshot)
effectiveTime
Time
Specifies the inclusive date at which the component version's state became the then current valid state of the component.
Note : In distribution files the effectiveTime should follow the short ISO date format (YYYYMM DD) and should not include the hours, minutes, seconds or timezone indicator.
YES
YES
(Full) Optional (Snapshot)
active
Boolean
Specifies whether the state of the relationship was active or inactive from the nominal release date specified by the effectiveTime field.
YES
NO
moduleId
SCTID
Identifies the relationship version's module. Set to a child of within the metadata hierarchy.
YES
NO
sourceId
SCTID
Identifies the source concept of the relationship version. That is the concept defined by this relationship. Set to the identifier of a concept.
NO
NO
value
String
Identifies the concrete value that is related to the relationship version.
This could be an Integer, Decimal or String. Numbers are prefixed with a # (hash) symbol. Strings are surrounded with " (double quote) with double quotes inside the string escaped using \ (backslash).
Note that the values that can be applied to particular attributes are formally defined by the.
NO
NO
relationshipGroup
Integer
Groups together relationship versions that are part of a logically associated relationshipGroup. All active Relationship records with the same relationshipGroup number and sourceId are grouped in this way.
YES
NO
typeId
SCTID
Identifies the concept that represent the defining attribute (or relationship type) represented by this relationship version.
That is the concept representing the value of the attribute represented by the typeId column.
Set to the identifier of a concept. The concept identified must be a subtype of . The concepts that can be used as in the typeId column of the Concrete Value file are formally defined as follows: < .
Note that the attributes that can be applied to particular concepts are formally defined by the .
NO
NO
characteristicTypeId
SCTID
A concept enumeration value that identifies the characteristic type of the relationship version (i.e. whether the relationship version is defining, qualifying, etc.) This field is set to a descendant of in the metadata hierarchy.
YES
NO
modifierId
SCTID
A concept enumeration value that identifies the type of Description Logic (DL) restriction (some, all, etc.). Set to a child of in the metadata hierarchy.
Currently the only value used in this column is and thus in practical terms this column can be ignored. For further clarification please see .
YES
NO
The Description holds descriptionsthat describe SNOMED CT concepts. A description is used to give meaning to a concept and provide well-understood and standard ways of referring to a concept.
Description file - Detailed Specification
Only one description 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 description is inactive at that point in time. If the activefield is true ('1'), then the description is associated with the concept identified by the conceptId field.
The conceptId field, the languageCode field and the typeId field 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 component will be inactivated (by appending a row with the same id and the active field set to false) and a another row will be added representing a new component with a new id. Only limited changes may be made to the term field, as defined by editorial rules.
Each concept will have at least one active description with a typeId of |synonym| and at least one active description with a typeId of |Fully specified name|.
Where a concept only has one active description with a typeId of |Fully specified name| across all language codes within a release, then that Description can be taken as the Fully Specified Name for all languages and dialects, and need not be explicitly included in every language reference set associated with that release.
The term field will be restricted as follows:
to an overall maximum length of 32Kb;
to a maximum length, configurable for each description type as defined in the member associated with that description type- see the specifications document for more details.
The Description Format Reference Set also defined the format of the term field (plain text, limited HTML, XHTML) for each description type.
Control characters (including TABs, CRs and LFs) will not appear in
id
SCTID
Uniquely identifies the description.
NO
YES (Full/Snapshot)
effectiveTime
Time
Specifies the inclusive date at which the component version's state became the then current valid state of the component
Note : In distribution files the effectiveTime should follow the short ISO date format (YYYYMM DD) and should not include the hours, minutes, seconds or timezone indicator.
YES
YES
(Full)
Optional (Snapshot)
active
Boolean
Specifies whether the state of the description was active or inactive from the nominal release date specified by the effectiveTime .
YES
NO
moduleId
SCTID
Identifies the description version's module. Set to a child of within the metadata hierarchy.
YES
NO
conceptId
SCTID
Identifies the concept to which this description applies. Set to the identifier of a concept in the |SNOMED CT Concept| hierarchy within the Concept. Note that a specific version of a description is not directly bound to a specific version of the concept to which it applies. Which version of a description applies to a concept depends on its effectiveTime and the point in time at which it is accessed.
NO
NO
languageCode
String
Specifies the language of the description text using the two character ISO-639-1 code. Note that this specifies a language level only, not a dialect or country code.
NO
NO
typeId
SCTID
Identifies whether the description is fully specified name a synonym or other description type. This field is set to a child of in the Metadata hierarchy.
NO
NO
term
String
The description version's text value, represented in UTF-8 encoding
YES
NO
caseSignificanceId
SCTID
Identifies the concept enumeration value that represents the case significance of this description version. For example, the term may be completely case sensitive, case insensitive or initial letter case insensitive. This field will be set to a child of within the metadata hierarchy.
YES
NO
This file provides a standardized way of associating alternative Identifiers from various schemes with SNOMED CT components.
At any point in time , an alternativeIdentifier within a particular scheme will be associated with one and only one SNOMED CT component. A SNOMED CT component may be associated with zero or mor e alternativeIdentifiers within a single scheme.
It is important to note that the SNOMED CT component and it' s alternativeIdentifiers all identify precisely the same real-world object.
Note: The Identifier file is not currently used in the SNOMED CT International Release as use of the more flexible Simple map type references set structure is preferred for links to alternative codes. The only known current use of this file is for internal identification of components during the content development process.
Identifier file - Detailed Specification
Only one record with the same identifierSchemeId and alternateIdentifier fields 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 association is inactive at that point in time. If the active field is true ('1'), then there is an identity at that point in time between the referencedComponentId (a SNOMED CT component) and the alternateIdentifier in the scheme identified by identifierSchemeId.
alternateIdentifier
String
String representation of the alternative Identifier in its native scheme.
NO
YES (Full/Snapshot)
effectiveTime
Time
Specifies the inclusive date at which the alternative Identifier was associated with the SNOMED CT component.
YES
YES
(Full)
Optional (Snapshot)
active
Boolean
Specifies whether the association was active or inactive from the point in time specified by the effectiveTime .
YES
NO
moduleId
SCTID
Identifies the source module that this association was created in.
Set to a child of within the metadata hierarchy.
YES
NO
identifierSchemeId
SCTID
Identifier of the concept enumeration value from the Metadata hierarchy that represents the scheme to which the Identifier value belongs. Set to a descendant of within the metadata hierarchy.
NO
YES (Full/Snapshot)
referencedComponentId
SCTID
Uniquely identifies the SNOMED CT component with which the alternative Identifier is associated.
YES
NO
The following subsections provide details of the format of the SNOMED CT component release files.
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.
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
subtypeId
SCTID
Id of the concept playing the subtype role. Set to an Identifier of a concept.
YES
supertypeId
SCTID
Id of the concept playing the supertype role. Set to an Identifier of a concept.
YES
subtypeId
SCTID
Id of the concept playing the subtype role. Set to an Identifier of a concept.
YES
supertypeId
SCTID
Id of the concept playing the supertype role. Set to an Identifier of a concept.
YES
effectiveTime
Time
Specifies the inclusive date at which the transitive closure record was added or changed its active state.
YES
active
Boolean
Specifies whether at the transitive closure represented by the subtypeId and supertypeId became valid (active) or invalid (inactive) from the point in time specified by the effectiveTime.
NO
The Relationship file holds one relationship per row. Each relationship is of a particular type, and has a source concept and a destination concept.
An example of a relationship is given below for: |Outpatient procedure| where:
371883000 |Outpatient procedure| is the source concept;
116680003 |Is a| is the relationship type concept and;
is the destination concept.
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 destinationId.
The sourceId, destinationId, relationshipGroup, typeId, 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.
.
id
SCTID
Uniquely identifies the relationship.
NO
YES
(Full/
Snapshot)
effectiveTime
Time
Specifies the inclusive date at which the component version's state became the then current valid state of the component.
Note : In distribution files the effectiveTime should follow the short ISO date format (YYYYMM DD) and should not include the hours, minutes, seconds or timezone indicator.
YES
YES
(Full)
Optional (Snapshot)
active
Boolean
Specifies whether the state of the relationship was active or inactive from the nominal release date specified by the effectiveTime field.
YES
NO
moduleId
SCTID
Identifies the relationship version's module. Set to a child of within the metadata hierarchy.
YES
NO
sourceId
SCTID
Identifies the source concept of the relationship version. That is the concept defined by this relationship. Set to the identifier of a concept.
NO
NO
destinationId
SCTID
Identifies the concept that is the destination of the relationship version.That is the concept representing the value of the attribute represented by the typeId column. Set to the identifier of a concept. Note that the values that can be applied to particular attributes are formally defined by the .
NO
NO
relationshipGroup
Integer
Groups together relationship versions that are part of a logically associated relationshipGroup. All active Relationship records with the same relationshipGroup number and sourceId are grouped in this way.
YES
NO
typeId
SCTID
Identifies the concept that represent the defining attribute (or relationship type) represented by this relationship version.
That is the concept representing the value of the attribute represented by the typeId column.
Set to the identifier of a concept. The concept identified must be either 116680003 |Is a| or a subtype of 410662002 |Concept model attribute|. The concepts that can be used as in the typeId column are formally defined as follows:
OR <
Note that the attributes that can be applied to particular concepts are formally defined by the .
NO
NO
characteristicTypeId
SCTID
A concept enumeration value that identifies the characteristic type of the relationship version (i.e. whether the relationship version is defining, qualifying, etc.) This field is set to a descendant of in the metadata hierarchy.
YES
NO
modifierId
SCTID
A concept enumeration value that identifies the type of Description Logic (DL) restriction (some, all, etc.). Set to a child of in the metadata hierarchy.
Currently the only value used in this column is and thus in practical terms this column can be ignored. For further clarification please see .
YES
NO
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.
id
Only one concept record with the same id field is current at any point in time. The current record will be the one with the most recent effectiveTime before or equal to the date under consideration. If the active field of this record is false ('0'), then the concept is inactive at that point in time.
When a concept is made inactive, the following operations take place:
A new row is added to the Concepts file for the concept, with the active flag set to inactive and the definitionStatusId set to primitive;
All relationships that have as source the concept to be inactivated will themselves be inactivated by adding a new row to the Relationship for each relationship, with the active flag set to inactive;
All active descriptions associated with the concept will remain unchanged unless incorrect for the concept;
Rows will be added as needed to the , to model associations from the inactive concept to other concepts;
Active descriptions that are still associated with the inactive concept will be added to the , with an associated value of
SCTID
Uniquely identifies the concept.
NO
YES (Full/Snapshot)
effectiveTime
Time
Specifies the inclusive date at which the component version's state became the then current valid state of the component.
Note : In distribution files the effectiveTime should follow the short ISO date format (YYYYMM DD) and should not include the hours, minutes, seconds or timezone indicator.
YES
YES
(Full) Optional (Snapshot)
active
Boolean
Specifies whether the concept was active or inactive from the nominal release date specified by the effectiveTime.
YES
NO
moduleId
SCTID
Identifies the concept version's module. Set to a descendant of within the metadata hierarchy.
YES
NO
definitionStatusId
SCTID
Specifies if the concept version is primitive or defined. Set to a descendant of in the metadata hierarchy.
YES
NO