SNOMED Documentation Search


 Other Documents
Skip to end of metadata
Go to start of metadata

Current Version - Under Revision

The following subsections discuss details of the key changes between RF2 and the previous Release Format .

Release Format structures and the abstract model

The following tables illustrate the correspondence between the fields of Release Format 1 ( RF1 ) and Release Format 2 ( RF2 ). Release Format 2 fully represents the Logical Abstract Model for SNOMED CT concept and derivatives .

Release Format 1 represents a snapshot view which is less completely aligned with the logical model. As the tables illustrate all the information represented by RF1 can be fully captured in the RF2 representation. However, the reverse is not true. Therefore, some added functionality provided by RF2 cannot be provided using the RF1 data.

Table 1. Map between RF1 Concepts Table and RF2 Concept file

 

RF1 Concepts Table

RF2 Concept File

Concepts . ConceptId

Concept .id

<not supported>

RF1 releases contain a snap-shot view of the state of each concepts at the time of release.

Concept . effectiveTime (field)

Concepts . ConceptStatus

Concept . active

<not supported>

RF1 does not support identification of separate modules.

Concept . moduleId (field)

Concepts .FullySpecifiedName

Concept . Description . term (field)

Fully specified name

;

Concepts .Ctv3Id

|CTV3 simple map reference set (foundation metadata concept)|

Concepts .SnomedId

|SNOMED RT identifier simple map (foundation metadata concept)|

Concepts . IsPrimitive

Concept . definitionStatusId (field)

Defined

;

Primitive

.

Table 2. Map between RF1 Descriptions Table and RF2 Description file

 

RF1 Descriptions Table

RF2 Description File

Descriptions . DescriptionId

Description .id

<not supported>

RF1 releases contain a snap-shot view of the state of each description at the time of release.

Description . effectiveTime (field)

Descriptions . DescriptionStatus

Description . active

<not supported>

RF1 does not support identification of separate modules.

Description . moduleId (field)

Descriptions . ConceptId

Description .conceptId

Descriptions . Term

Description . term (field)

Descriptions . InitialCapitalStatus

  • 0 (Initial character case insensitive);
  • 1 (Case sensitive);
  • <other values not supported>.

Descriptions . caseSignificanceId (field)

Descriptions . DescriptionType

Preferred

in language / dialect Refset

Acceptable

in language / dialect Refset

  • 3 ( Fully specified name ).

Description . typeId (field)

Descriptions . LanguageCode

  • Includes

    dialect

    where relevant;
  • Language Subsets recommended for representing preferences in

    dialects

    .

Description .languageCode

Table 3. Map between RF1 relationships tables and RF2 Relationship file

 

RF1 Relationships Table

RF2 Relationship File

Relationships . RelationshipId

Relationship .id

<not supported>

RF1 releases contain a snap-shot view of the state of each active relationship at the time of release.

Relationship . effectiveTime (field)

<not supported>

Only active Relationship rows are included in the distribution file for each version.

Relationship . active

<not supported>

RF1 does not support identification of separate modules.

Relationship . moduleId (field)

Relationships . ConceptId1

Relationship . sourceId (field)

Relationships .RelationshipType

Relationship . typeId (field)

Relationships . ConceptId2

Relationship . destinationId (field)

Relationships . CharacteristicType

  • 0 (Defining):
    • Inferred - in Relationships Table
    • Stated - in separate Stated Relationships Table
  • 1 (Qualifying).
  • 2 (Historical).
  • 3 (Additional).

Relationship . characteristicTypeId (field)

Inferred relationship

;

Stated relationship

;

Qualifying relationship

;

Additional relationship

.

Relationships . Refinability

Represented by the |Relationship refinability attribute value reference set (foundation metadata concept)| .

<not supported>

modifierId (field)

Addition of effectiveTime and active fields

The effectiveTime (field) and active fields enable the use of a "log style" append-only data model to track all changes to each component for full traceability. Historic data will be supplied in the RF2 release files , dating back to the first release in 2002.

Once released, a row in any of the RF2 release files will remain unchanged through future releases. In order to change certain properties of a current component (and, therefore, to create a new version of it), a new row must be added to the applicable file, containing the updated data. The active field in the newly added row is set to true and the timestamp in the effectiveTimefield indicates the point in time at which the new version comes into effect.

By contrast, 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 by adding a new row 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 (field) field indicating the nominal release date at which the final version ceased to be valid.

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

Active field

As mentioned above, each file contains a Boolean (data type) active field, used to indicate whether, after the point in time specified in the effectiveTimefield, the version of the component expressed in the row is active or inactive .

This field replaces the status field with a simple binary state. In the previous Release Format , this field was overloaded to enumerate both whether the concept was active , why it was inactivated, and whether it was about to change (or had changed) authority.

The additional information encoded in RF1 's status enumeration is represented in RF2 using the following reference sets :

These three reference sets conform to the Attribute Value reference set pattern, and are further described in the " SNOMED CT Release Format 2 - Reference Set Specifications" document.

History tables

History tracking in RF2 's main files uses a log-style, append-only data model. Therefore, the separate ComponentHistory file that formed part of the original Release Format is no longer required with RF2 .

The associations between inactive and active Concepts that are currently supported by Historical Relationship types (e.g. |SAME AS| , "REPLACED BY) will continue to be supported. References held in the References table from an inactive component to other equivalent or related components that were current in the Release Version in which that component was inactivated will also continue to be supported.However, both of these associations have now moved from the Relationships file and the References file to one of the following |Historical association| reference sets .

Table 4. RF1 to RF2 History Field Mappings

 

RF1 source

RF2 *

Historical association

MAYBE A (in Relationships table )

POSSIBLY EQUIVALENT TO association reference set

Refers to ('7' in References table )

REFERS TO concept association reference set

Similar to ('3' in References table )

SIMILAR TO association reference set

MOVED FROM (in Relationships table )

Moved from ('6' in References table )

MOVED FROM association reference set

MOVED TO (in Relationships table )

Moved to ('5' in References table )

MOVED TO association reference set

Alternative ('4' in References table )

ALTERNATIVE association reference set

WAS A (in Relationships table )

WAS A association reference set

REPLACED BY (in Relationships table ); and

Replaced by ('1' in References table )

REPLACED BY association reference set

SAME AS (in Relationships table )

Duplicated by ('2' in References table )

SAME AS association reference set

These reference sets all conform to the Association reference set pattern, and are further described in the " SNOMED CT Release Format 2 - Reference Set Specifications" document.

Field naming

Lower camel case has been used for field names in distribution file headers and in documentation that describes these files. File names will use upper camel case (starting with a capital letter). File names have also been altered to use a singular not plural form.

An example of upper Camel Case is ThisIsUpperCamelCase. An example of Lower Camel Case is thisIsLowerCamelCase.

Field Ordering

Records in the Concept , Description , Relationship and Reference Set member files each start with the following four fields:

The four fields have the following meanings:

  • The id field provides a unique

    Identifier

    for the component described by the record;
  • The effectiveTimegives the nominal release date at which this version of the component came into effect;
  • The

    active

    flag states whether the components

    active

    or

    inactive

    ;
  • The moduleId (field) identifies the source module in which the component is maintained.

The Identifier file does not follow the same format, as it works in a slightly different way to the other files, and is described in more detail in the " SNOMED CT Release Format 2 - Data Structures Specification" document.

Concept enumerations

Concept enumerations have been used across RF2 to replace Integer (data type) enumerations that can only be understood by referencing external documentation. For example, in RF1 , a concept status value of '4' indicates concepts that are inactive because they are ambiguous. In RF2 , concept enumeration simply uses concepts in a metadata hierarchy to represent the enumerated value set rather than using arbitrary Integer (data type) values directly. Using concepts to represent the enumerated values has the following advantages:

  • The terminology is self contained, removing the requirement for external documents to explain the meaning of enumerated values;
  • Full

    language

    handling capabilities are available for the enumerated values' representation, useful for standardized multi-lingual representation, and translation support;
  • Machine readable model constructs can be used to further describe and enrich the enumerated values.

The following fields have been converted to concept enumerations:

Table 5. RF1 to RF2 enumerated field changes

 

 

File

Existing RF1 field name

RF2 field name

 

Concept

IsPrimitive

definitionStatusId (field)

 

Description

DescriptionType

typeId (field)

 

Description

InitialCapitalStatus

caseSignificanceId (field)

 

Relationship

CharacteristicType

characteristicTypeId (field)

 

Care should be taken not to confuse Concept Enumerations with the term (field) "enumeration" as used in representational formats. A Concept Enumeration is a concept whose immediate children represent possible values in a range. Each possible value is represented by a single child concept , whose preferred term may be used, for example, to enable selection from a pick-list of one or more values from the range.

Mappings from RF1 values to RF2 concept enumerations are given below:

Table 6. RF1 to RF2 enumerated value mappings

 

 

RF2 field name

RF1 value

RF2 *value

*

 

definitionStatusId (field)

0

|Defined|

 

 

1

Primitive

 

typeId (field)

(no specified value)

|Definition|

 

 

3

Fully Specified Name

 

 

0, 1 or 2

Synonym

 

caseSignificanceId (field)

0

|Initial character case insensitive|

 

 

1

|Case sensitive|

 

 

(no specified value)

|Case insensitive|

 

charactristicTypeId

3

Additional relationship

 

 

0

Inferred relationship

 

 

0

Stated relationship

 

 

1

Qualifying relationship

 

 

2

(no specified value) - now modeled through the inactive association reference set .

 

Reference Set Data Structures

Overview of Reference Sets

Reference Set data structures provide the foundation pieces for RF2 's generic extensibility mechanism. These building blocks provide a common foundation for extension builders to extend SNOMED CT , and provide RF2 with the capability to grow with the IHTSDO 's requirements over time.

Conventions applied to the RF2 files such as field naming, field ordering and history tracking have also been applied to the Reference Set specification. This has been done to provide consistency across all components in the Release Format .

Generic data structures for Reference Sets have been used to create a simple core structure that can be extended to meet a variety of requirements, rather than a complex and inextensible structure that can only be used in a finite and constrained number of ways to enforce editorial policy. This stems directly from a desire to decrease impact on the SNOMED CT community by being able to meet future requirements without having to alter the underlying data structures.

Using these generic structures, it is possible to extend the data stored within the main files of SNOMED CT to satisfy new use cases without altering the primary structure itself. Containing this extended information in externalised structures such as Reference Sets also enables terminology consumers to opt in or out of the content without burdening the primary files with the content. This prevents users from having to download all content and filter out what they don't want, and instead allows them to import the extension content should it be desired.

Reference Sets allow the SNOMED CT core data structures to be extended, allowing existing components to be grouped together into a set, each tagged with a number of additional fields. Each of these additional fields may either be another SNOMED CT component , a String (data type) or an Integer (data type). Reference set descriptors are also introduced, providing a way to identify the format and purpose of each additional field in a machine readable way. Examples of reference set data structures are provided in the " SNOMED CT Release Format 2 - Reference Set Specifications" document.

RF1 Subsets Representation

The RF1 Subset mechanism consists of two tables: a Subsets table and a Subset Members table. Each row in the Subsets table describes a Subset and characteristics of that Subset , as described in the table below.

Table 7. Subsets Table

 

Field

Description

SubsetId

The unique SNOMED CT Identifier for this Subset

SubsetOriginalId

The unique SNOMED CT Identifier for the original Subset of which this Subset is a version.

SubsetVersion

An Integer (data type) incremented for each revised release of a Subset

SubsetName

A name that describes the purpose or usage of this Subset .

SubsetType

Indicates the nature of the Subset and the type of SNOMED CT

Component that may be a member of the Subset .

LanguageCode

Identifies the Language and optionally the Dialect to which the Subset applies (only used for description -based subsets : Language , Realm Description , and Realm Concept ).

RealmId

Identifies the Realm to which the Subset applies.

ContextId

May identify the Context Domain to which the Subset applies

Each row in the Subset Members table sets the status of a member of an identified Subset .

Table 8. Subset Members Table

 

Field

Description

SubsetId

The unique SNOMED CT Identifier for this Subset

MemberId

The SNOMED CT Identifier of this Subset Member . This may be a

Concept Identifier , Description Identifier or RelationshipId .

MemberStatus

An Integer (data type) specifying the status, type or order (field) of this member.

LinkedId

Valid for Navigation and Duplicate Terms Subsets only. For Navigation Subsets it is the SNOMED CT Identifier for a Concept that is a Navigation child of the Subset Member. For Duplicate Terms Subsets it is the SNOMED CT Identifier for the highest priority Descriptions haring theDuplicate Term .

Some Subsets and their members are generated automatically from an XML definition file.

Representing Subsets as Reference Sets

An existing RF1 Subset may be represented as an RF2 Reference Set in the following way:

A concept should be created in the | Reference Set | metadata hierarchy , using information in the Subset table record. A Descriptor for the Reference Set should also be set up using information in the Subset table record. Then, one Reference Set member record should be created for each Subset Member table record.

The way in which the subsets are represented in RF2 depends on the SubsetType value, as follows:

Table 9. Representing Subsets as Reference Sets

 

 

 

SubsetType value

Description

Mapping to RF2

1

Language

Language type Reference Set

2

Realm Concept

Ordered type Reference Set

3

Realm Description

Language type Reference Set

4

Realm Relationship

Ordered type Reference Set

5

Context Concept

Ordered type Reference Set

6

Context Description

Language type Reference Set

7

Navigation

Ordered type Reference Set .

8

Duplicate terms

Ordered type Reference Set

Representing Subsets as Ordered type Reference Sets

|Ordered type| Reference Sets can be set up as follows:

First, set up a new concept for the Reference Set in the |Ordered type| metadata hierarchy . The position in the hierarchy should be given by the RealmId and ContextIdfields in the Subset record, as follows:

SNOMED CT Model component

Foundation metadata concept

Reference set

Ordered type

RealmId

ContextId

If either the RealmId field or the ContextId fields are "0", "1", blank or null in the Subset record, then that level should not be set up in the metadata hierarchy . If a concept already exists under |Ordered type| with a matching RealmId and ContextId, then the new Reference Set should be set up in that position (as opposed to creating two |Ordered type| children with duplicate names).

First, the concept describing the Reference Set should be created with the following values:

Table 10. Reference Set Concept

 

 

Field

Data type

Set to

id

SCTID (data type)

A unique id in your namespace .

effectiveTime (field)

Time (data type)

The nominal date of release for your Reference Set . If a full state valid representation of a subset 's history is required, then each previous release of the Subset files must be processed in turn (by identifying Subset records with a matching SubsetOriginalId, in their SubsetVersion order (field)), and each amended version must be applied to the reference set by appending rows in the usual fashion. The effectiveTimeof each applied change should be set to the date that each version of the Subset was released.

active (field)

Boolean (data type)

'1'

moduleId (field)

SCTID (data type)

The module Identifier for your authoring organization .

Then, add up two Descriptions for the FSN and the Preferred Term of the concept :

Table 11. Reference Set Descriptions

 

 

 

Field

Data type

Set to

id

SCTID (data type)

A unique id in your namespace .

effectiveTime (field)

Time (data type)

The nominal date of release for your Reference Set .

active (field)

Boolean (data type)

'1'

moduleId (field)

SCTID (data type)

The module Identifier for your authoring organization .

conceptId

SCTID (data type)

The Identifier of the concept describing the Reference Set that you've just added.

languageCode

String

The language of the Description . This field should be set to the language that the Subset was defined in, for example - 'en' for English.

typeId (field)

SCTID (data type)

Create two Description records, one for each of the following types: |Fully specified name| ,

Synonym

.

term (field)

String

The term (field) for the

Synonym

should be set to the SubsetName field in the Subset record. The term (field) for the

FSN

should be set to the same, but appended with " reference set (foundation metadata concept )".

Finally, add one Reference Set member record for each record in the Subset Members table for the Subset :

Table 12. Converting a Priority Subset to an Ordered Reference Set

 

 

Field

Data type

How to populate

id

UUID (data type)

A new unique Identifier

effectiveTime (field)

Time (data type)

The nominal date on which this release was made.

active (field)

Boolean (data type)

'1'

moduleId (field)

SCTID (data type)

Set to the moduleId (field) of the authoring organization .

refsetId

SCTID (data type)

A reference to the concept describing the Reference Set that you've just created.

referencedComponentId (field)

SCTID (data type)

Set to MemberId in the Subset Members table record.

order (field)

Integer

Set to MemberStatus in the Subset Members table record.

Note: Although a Navigation Subset can be represented in an |Ordered type| reference set as described above, the values of the linkedToId (field) field would then have a different meaning, referencing a child concept instead of grouping components together.

A Descriptor can also be set up for the Reference Set if required, as follows:

Where Concept describing refset is the Concept that you've just set up to describe the Reference Set . The | Order | and |Linked to| concepts that describe each additional Attribute in the Reference Set can also be replaced by more descriptive ones if required. To do this, create the new concepts describing the additional fields under the | Reference set Attribute | metadata hierarchy .

Representing Subsets as Language type Reference Sets

Language type Reference Sets can be set up in a similar fashion to the above, with the following exceptions:

The LanguageCode field in the Subset record should be used to link the Reference Set 's concept into the appropriate place in the | Language type| metadata sub-hierarchy . For example, a value of "en-US" in the LanguageCode field would result in the Reference Set 's concept being created under |US English|:

SNOMED CT Model component

Foundation metadata concept

Reference Set

Language type

English

US English

RealmId

ContextId

  • Where the SubsetType is "

    Language

    " and the LanguageCode is a single level (e.g. "en"), then the

    Reference Set

    should be created at the first level, under |English| in the example above;
  • Where the SubsetType is "

    Language

    " and the LanguageCode is a two level (e.g. "en-US"), then the

    Reference Set

    should be created at the second level, under |US English| in the example above;
  • Where the SubsetType is "

    Realm

    Description

    ", then the

    Reference Set

    should be created under RealmId in the example above (where RealmId is the value of the RealmIdfield in the

    Subset

    record);
  • Where the SubsetType is "Context

    Description

    ", then the

    Reference Set

    should be created under ContextId in the example above (where ContextId is the value of the ContextId field in the

    Subset

    record and RealmId is the value of the RealmIdfield in the

    Subset

    record).

The Reference Set member records should be created as described in the following table:

Table 14. Converting a Language Subset to a Language Reference Set

 

 

Field

Data type

How to populate

id

UUID (data type)

A new unique Identifier

effectiveTime (field)

Time (data type)

The nominal date on which this release was made.

active (field)

Boolean (data type)

'1'

moduleId (field)

SCTID (data type)

Set to the moduleId (field) of the authoring organization .

refsetId

SCTID (data type)

A reference to the concept describing the Reference Set that you've just created.

referencedComponentId (field)

SCTID (data type)

Set to MemberId in the Subset Members table record.

A Descriptor can also be set up if required.

Metadata hierarchy

As the RF2 data structures and extensibility mechanism contain a number of concept enumerations, it is necessary to define concepts that represent these values. As well as the enumerated values, there are other machine-readable concept model structures not visible in the Release Format that require metadata (for example, the structures that define the format of a description type).

To meet this need, a new top-level hierarchy has been defined as a sibling to the | SNOMED CT Concept |, called | SNOMED CT Model component |. Note that existing metadata concepts held within the | SNOMED CT Concept | sub-hierarchy (|Linkage| and | Namespace |) will be moved to the | SNOMED CT Model component | sub-hierarchy .

The top level of the SNOMED CT Model component hierarchy is structured as follows:

Figure 2. SNOMED CT Model Component Hierarchy

Note that only |is a| relationships will exist between concepts in the |SNOMED CT Model Component| | hierarchy |. Other associations between concepts in this hierarchy can be modeled using an |Association type reference set (foundation metadata concept)| (see Association Reference Set ).

SCTIDs and UUIDs

UUID (data type) are unique universal Identifiers . These 128 bit unsigned Integer (data type) can be used to identify all SNOMED CT components internally.

SCTID (data type) will continue to be used as primary and foreign keys for concepts and descriptions , both to identify a component and to reference other components. This form is essential for vendors and implementers who will reference concepts in Clinical Information Systems and messages. SCTID (data type) will also be used to identify relationships . However, UUID (data type) will be used to identify Reference Set members.

In addition, any UUID (data type) used in development can also be published as additional Identifiers via the Identifier file .

Description text

The values permitted within the description term (field) field have been extended to support arbitrary length content, and support mark-up content such as XHTML. The 900000000000538005 |Description format reference set| allows a maximum length and format to be associated with each description type within the Description file (see Description Format Reference Set ) .

This mechanism allows descriptive text of different formats (other than Fully Specified Names and Synonyms ) to be associated with concepts , while appropriately constraining existing description types. This enables all descriptions associated with concepts that may require translation to be held in one place in the Description file .

LanguageCode

The languageCode field is retained in the Description file, but is restricted to contain only coarse-grained language information (e.g. "English" or "French"). Reference sets are used to indicate dialects and contexts, where required. As an example, the term (field) "Bulldozer" would appear once in the Descriptions file with the language code en ("English"), but be listed separately in each of the Australian, UK and US English language national dialect Reference Sets as a valid term (field) in all three dialects .

The languageCode field in RF2 is a text field and is bound to the ISO 639-1 two-character language codes.

Addition of a modifierId field

The underlying semantics on which SNOMED CT is based assumes that all relationships are existential restrictions. In other words, a relationship in SNOMED CT implies that there is some instance of that relationship from each instance of the source concept to any instance of the target concept . Other types of relationship , such as universal restrictions do exist and have been studied extensively. For example, the existence of a universal relationship in SNOMED CT would require that all instances of that relationship from each instance of the source concept be to an instance of the target concept .

As an example, take the following hypothetical relationship |Has child | between two concepts |Woman| and |Girl| :

|Woman| |Has child| = |Girl|

In SNOMED CT , the relationship is implicitly an existential relationship , that we can make explicit in the above syntax by adding the modifier "some:", as follows:

|Woman| some: |Has child| = |Girl|

This means that every instance of |Woman| has at least one |Has child| relationship that has as its target an instance of |Girl| . In other words, in our hypothetical world, every woman would have at least one daughter, but may also have any number of sons.

If the existential relationship were changed to a universal relationship , as follows, then the meaning would be changed:

|Woman| all: |Has child| = |Girl|

This means that, for every instance of |Woman| , all its |Has child| relationships must have a target of |Girl| . In other words, in our hypothetical world, women could only have daughters or no children at all, and could not have sons. This has a very different meaning from the existential relationship currently implied within SNOMED CT .

A new modifierId (field) field has been added to the Relationship file to allow future expansion. This concept enumeration field will initially be set to |Some| to keep compatibility with the existing semantics of SNOMED CT . Widening the range of this field to include other values (such as |All| ) would in future increase the expressive power of SNOMED CT . However, this is likely to come at the cost of an increase in reasoning complexity, leading to potential issues for classification tooling. Therefore, before extending the range of this field beyond |Some| , a test of the impact on tooling will need to be performed, and the results reviewed and approved.

Notes:

  1. The modiferId field has been included at this stage as the

    RF2

    format is likely to be stable for at least a five year period, without addition or deletion of fields. Within that period it is anticipated that other modifierId (field) values will be added. Therefore, although not fully implemented at this stage, this field has been included in the initial RF2 specification as it represents an integral part of the

    Description Logic

    used by

    SNOMED CT

    .
  2. Any expansion of

    SNOMED CT

    to include

    relationships

    with a modifierId (field) set to a value other than

    |Some|

    will be discussed with

    Members

    first and approved by the Technical Committee.

Addition of moduleId field

A moduleId (field) field has been added to help identify content and dependencies in a release. This enables release centers to compose a unified release (in a single set of release files ) from a number of different modules, yet still identify the origin of content down to a row level within each of the releases. For example, this may be used to differentiate SNOMED CT International content, Australian Medicines terminology and Pathology content within the Australian National release . Currently this is only possible if all modules are assigned unique sub - namespaces , and content consumers parse Identifier namespaces to differentiate modules.

Components may move from one module to another within a particular namespace . Without a moduleId (field), there would be a need to retire a component in one namespace , and add another (with a new SCTID (data type)) to the namespace that the component is moved to. Additional relationships would also need to be set up, to link the old and new components together. None of this administrative and error-prone work is required if moduleId (field) are used.

Combining the moduleId (field) with Reference Sets provides a powerful versioning mechanism. The Module Dependency reference set (described in more detail in the SNOMED CT Release Format 2 - Reference SetSpecifications" document) can represent interdependencies between modules and define compatible versions. This functionality can thus be used to represent version information for a terminology's components within the terminology's content itself, in a machine processable way.

The diagram below provides an example of this structure. It shows the components making up an Australian national SNOMED CT extension release, containing subcomponents. The links can be described using members of the Module Dependency Reference Set . In the example below:

Figure 3. Illustration of module dependencies

Fully Specified Names and Preferred Terms

RF2 , like the original Release Format , allows Fully Specified Names (FSNs) to be specified in each language using the Description file. Multiple FSNs and multiple synonyms may exist with the same languageCode for a concept . However, a particular language Reference Set will only contain a single FSN and a single preferred term for a concept .

As part of the language modifications made in the RF2 , only a broad definition of a language can be made for a Description . For example, it is possible to declare a Description as English, but not US English. Also RF2 no longer contains a description type value for a " Preferred Term ", only types of | Fully Specified Name | and | Synonym |. Each Synonym can then be assigned an |Acceptability value| of either |Acceptable| or |Preferred| when included in a language reference set .

As a result of these changes, the preference for particular descriptions in a language or dialect is now represented using a Reference Set . This matches the specified use of Language Subsets in RF1 , and deliberately removes the deprecated approach applied in some releases where preferences were derived directly from the released Descriptions file.

Language reference sets also introduce the notion of overriding or inactivating particular Descriptions that may be appropriate in one dialect , but not appropriate in another dependent dialect or context. This is achieved by allowing Descriptions that are inherited from a parent language reference set to be overridden in a child language reference set .

Field removals

A number of fields that appeared in the previous Release Format do not appear in RF2 . These fields are listed in the table below, with an explanation of why each field has been removed and to where it has been moved. Note that where a reference set replaces a field, this reference set will be provided with the RF2 distribution.

Table 15. RF1 fields that are not use in RF2

 

 

 

 

File

Field

Rationale for change

Moved to

Concept

CTV3Id

To avoid cluttering the concept table.

Moved to the

CTV3 simple map

Reference Set .

Concept

SNOMEDID

To avoid cluttering the concept table.

Moved to the

SNOMED RT IDsimple map

Reference Set .

Concept

FullySpecifiedName

This field duplicates one of the fully specified names represented in the Description file. This duplication has led to misunderstanding of the use of fully specified names in multi-lingual distributions of SNOMED CT .

The original FSN, which may be required for translation purposes, can be identified as the FSN for the concept that has the earliest effectiveTime (field) .

Relationship

Refinability

As this information is only useful in some environments, it has been moved out of the Relationship file to avoid cluttering it.

Moved to the

Relationship refinability reference set

.

Identifier file

The Identifier file has been added to provide a standardized means of attaching co-referent Identifiers from many different schemes to SNOMED CT components . This provides a means to:

This provides a mechanism for generically binding SNOMED CT components to an arbitrary number of alternative Identifiers . It is a more scalable solution than appending columns as needed to the Concept file .

Note that the Identifier file is not intended as a mapping solution. This structure is only intended to support cases where the external Identifier means exactly the same thing as the SNOMED CT component to which it is attached. For example, it is not envisioned that ICD-9, ICD-10 or CTV3 codes would be entered into this file.

The Identifier file is intended to provide a mechanism to represent external codes for SNOMED CT components where the meaning is exactly the same. For example, in the Australian Medicines terminology (AMT), concepts are "generated" from data sourced from the Therapeutic Goods Administration (TGA) and the TGA has an ARTGID for every therapeutic item. This mechanism allows the ARTGIDs to be attached directly to the corresponding AMT concept when generated. In this instance, the Identifier file assists meeting the use case without burdening the descriptions file or concepts file with this content.

References table

In the previous Release Format , the References Table contained References from inactive components to other equivalent or related components that were current in the Release Version in which that component was inactivated. Each Reference indicated the nature of the relationship between the inactive and persistent component.

In RF2 , this information is held in Historical Association Reference Sets .

Textual Descriptions

In the previous Release Format , a separate Textual Descriptions file held long descriptions (of up to 512 bytes, in plain text format). In RF2 , these textual descriptions are transferred to the Description file .

Mapping

Mapping Overview

No bespoke mapping file structures (for example, CrossMapSets tables) have been defined in RF2 . Instead, the simple map Reference Set pattern and alternate map Reference Set pattern should be used, in conjunction with other Reference Set patterns, to define Reference Sets for mapping purposes. See the " SNOMED CT Release Format 2 - Reference Set Specifications" document for more details.

Mapping in RF2

RF1 CrossMaps that have a type of either one-to-one or one-to-many can be represented in RF2 as described below. The type of an RF1 CrossMap can be identified from the MapSetType field in the CrossMapSets table. The following values in the MapSetType field are possible:

Table 16. RF2 Mapping Type Representations

 

 

 

Value

Meaning

Examples

Mapped to RF2

1

One-to-one

ICD-O

Can be mapped automatically, as described below

2

One-to-many

ICD-9-CM

Can be mapped automatically, as described below

3

Alternate on-to-one maps

None known of

Can be mapped automatically. Further definition will be given if necessary.

4

Alternate one-to-many

None known of

May need manual intervention to map.

For CrossMaps that have a MapSetType of either '1' or '2', first, create a concept under the |Complex map| sub-hierarchy to describe the Complex map Reference Set , in the following location:

SNOMED CT Model component

Foundation metadata concept

Reference Set

Complex map

MapSetRealmId

Where MapSetRealmId is set to the contents of the MapSetRealmId field in the CrossMapsSets record of the CrossMap to be represented in RF2 format. Where the MapSetRealmId field is blank or null, then an intermediate concept should not be created, and the Map Reference Set concept should be created as a direct child of |Complex map|. The concept should be created as follows:

Table 17. RF2 Map Versioning

 

 

Field

Data type

Set to

id

SCTID (data type)

A unique id in your namespace .

effectiveTime (field)

Time (data type)

The nominal date of release for your Map Reference set . The year of the nominal release should tie up with the year in the MapSetSchemeVersionfield in the CrossMapSets record.

active (field)

Boolean (data type)

'1'

moduleId (field)

SCTID (data type)

The module Identifier for your authoring organization .

Once the concept is created, add two Descriptions for the FSN and a Synonym .

Table 18. RF2 Mapping Metadata

 

 

Field

Data type

Set to

id

SCTID (data type)

A unique id in your namespace .

effectiveTime (field)

Time (data type)

The nominal date of release for your reference set .

active (field)

Boolean (data type)

'1'

moduleId (field)

SCTID (data type)

The module Identifier for your authoring organization .

conceptId

SCTID (data type)

The Identifier of the concept describing the Reference Set that you've just added.

languageCode

String

The language of the Description .

typeId (field)

SCTID (data type)

Create two descriptions , with each of the following types:

FSN

,

Synonym

.

term (field)

String

Terms for the FSN and the Synonym . The Synonym should be set to the MapSetName in the CrossMapSets record. The FSN should be set to: MapSetSchemeName + "("+ MapSetSchemeId + ")" + " reference set (foundation metadata concept )".

Finally, add members to the Reference Set that you've just created.

To do this, identify each CrossMaps table record with a MapSetId that matches the MapSetId field in the CrossMapsSets record for the CrossMap that you're representing in RF2 . For each CrossMap table record, identify the related CrossMapTarget record using the MapTargetId field in the CrossMaps record. The TargetCodes field in the CrossMapTarget record will contain zero or more target codes , each separated by a separator character identified by the MapSetSeparator field of the CrossMapSets record.

One Reference Set member record should be created for each target code identified within the TargetCodes field, as follows:

Table 19. RF2 Mapping Representation

 

 

 

Field

Data type

Purpose

id

UUID (data type)

A unique UUID (data type) for the new member record.

effectiveTime (field)

Time (data type)

The nominal date of release that this member is to be first introduced in.

active (field)

Boolean (data type)

'1'

moduleId (field)

SCTID (data type)

The module Identifier for your authoring organization .

refsetId

SCTID (data type)

The id of the concept that describes the Reference Set that you've just created.

referencedComponentId (field)

SCTID (data type)

Set to the MapConceptId in the CrossMaps record.

mapGroup

Integer

This field should be set to '1' for the first target code within TargetCodes field of the CrossMapTargets record. If there is more than one target code in the field (separated by a separator character), then this field should be set to '2', '3', etc. For each subsequent code.

mapPriority

Integer

'1'

mapRule

String

Set to null

mapAdvice

String

Set to null

mapTarget

String

Set to the target code in the TargetCodes field of the CrossMapTargets record.

Release Types

Release Format 1 only supports a single Release Type which represented the entire set of currently relevant components. In contrast Release Format 2 supports three different Release Types including a full historical view of all components ever released and a delta release that contains only the changes from one release to another.

The Release Format 2 - Introduction describes the Release Types and the WIPTSG provides advice on Choosing a Release Type to import .

Interchange format

RF2 is conceived as a replacement for the current Release Format . It is designed to provide a way to publish releases of SNOMED CT Release to implementers and other licensees. There is a close relationship between the requirements to support distribution of content and the requirements for exchanging components during content development. However, there are also significant differences related to the requirement for additional development information (author, change time, etc) and a need to support work with 'interim' incomplete and unpublished components which have not yet been assigned a SNOMED CT identifier .

Previous IHTSDO work resulted in a draft specification of SNOMED Interchange Format (SIF) which addressed some of these issues. Some of the provisions of RF2 are already supported by SIF but others will require revisions to the SIF specification.

Post Coordinated expression Syntax

RF2 allows relationship types to be extended from "existential qualification" to other types of relationship such as "universal qualification". This extension will not be used in initial releases until the complexity of the underlying semantics has been fully tested, but once it is introduced, post coordinated expression syntax will also need to be extended to cater for this.


Feedback