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


RF1Concepts Table

RF2Concept 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

Concepts. ConceptStatus


Concept. active


<not supported>

RF1 does not support identification of separate modules.

Concept. moduleId

Concepts .FullySpecifiedName

Concept. Description. term


Fully specified name

;


Concepts .Ctv3Id

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


Concepts .SnomedId

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


Concepts. IsPrimitive


Concept. definitionStatusId


Defined

;


Primitive

.

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


RF1Descriptions Table

RF2Description 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

Descriptions. DescriptionStatus


Description. active


<not supported>

RF1 does not support identification of separate modules.

Description. moduleId

Descriptions. ConceptId

Description .conceptId

Descriptions. Term

Description. term

Descriptions. InitialCapitalStatus


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

Descriptions. caseSignificanceId


Descriptions. DescriptionType


Preferred

in language / dialect Refset


Acceptable

in language / dialect Refset


  • 3 ( Fully specified name ).

Description. typeId


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


RF1Relationships Table

RF2Relationship 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

<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

Relationships. ConceptId1

Relationship. sourceId

Relationships .RelationshipType

Relationship. typeId

Relationships. ConceptId2

Relationship. destinationId

Relationships. CharacteristicType


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

Relationship. characteristicTypeId


Inferred relationship

;


Stated relationship

;


Qualifying relationship

;


Additional relationship

.

Relationships. Refinability

Represented by the .

<not supported>

modifierId

Addition of effectiveTime and active fields

The effectiveTime 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 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 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. 168666000 |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


RF1source

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 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 enumerations that can only be understood by referencing external documentation. For example, in RF1, a conceptstatus 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 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 RF1field name

RF2field name


Concept

IsPrimitive

definitionStatusId


Description

DescriptionType

typeId


Description

InitialCapitalStatus

caseSignificanceId


Relationship

CharacteristicType

characteristicTypeId


Care should be taken not to confuse Concept Enumerations with the term "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



RF2field name

RF1value

RF2 *value

*


definitionStatusId

0

900000000000073002 |Defined|



1

Primitive


typeId

(no specified value)

900000000000550004 |Definition|



3

Fully Specified Name



0, 1 or 2

Synonym


caseSignificanceId

0

900000000000020002 |Initial character case insensitive|



1

900000000000017005 |Case sensitive|



(no specified value)

900000000000448009 |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 or an integer. 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 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 specifying the status, type or order 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

A unique id in your namespace .

effectiveTime

Time

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

Boolean

'1'

moduleId

SCTID

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

A unique id in your namespace .

effectiveTime

Time

The nominal date of release for your Reference Set .

active

Boolean

'1'

moduleId

SCTID

The module Identifier for your authoring organization .

conceptId

SCTID

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

SCTID

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

Synonym

.

term

String

The term for the

Synonym

should be set to the SubsetName field in the Subset record. The term 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

A new unique Identifier

effectiveTime

Time

The nominal date on which this release was made.

active

Boolean

'1'

moduleId

SCTID

Set to the moduleId of the authoring organization .

refsetId

SCTID

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

referencedComponentId

SCTID

Set to MemberId in the Subset Members table record.

order

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 linkedTo 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 Conceptdescribing 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

A new unique Identifier

effectiveTime

Time

The nominal date on which this release was made.

active

Boolean

'1'

moduleId

SCTID

Set to the moduleId of the authoring organization .

refsetId

SCTID

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

referencedComponentId

SCTID

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 116680003 |is a| relationships will exist between concepts in the 900000000000441003 |SNOMED CT Model Component| | hierarchy |. Other associations between concepts in this hierarchy can be modeled using an 900000000000521006 |Association type reference set (foundation metadata concept)| (see Association Reference Set ).

SCTIDs and UUIDs

UUIDs are unique universal Identifiers. These 128 bit unsigned integers can be used to identify all SNOMED CT components internally.

SCTIDs 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. SCTIDs will also be used to identify relationships. However, UUIDs will be used to identify Reference Set members.

In addition, any UUIDs used in development can also be published as additional Identifiers via the Identifier file .

Description text

The values permitted within the description term 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 specification ) .

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 "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 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 224526002 |Woman| and 431549007 |Girl| :

224526002 |Woman| |Has child| = 431549007 |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:

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

This means that every instance of 224526002 |Woman| has at least one |Has child| relationship that has as its target an instance of 431549007 |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:

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

This means that, for every instance of 224526002 |Woman|, all its |Has child| relationships must have a target of 431549007 |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 has been added to the Relationship file to allow future expansion. This concept enumeration field will initially be set to 900000000000451002 |Some| to keep compatibility with the existing semantics of SNOMED CT. Widening the range of this field to include other values (such as 900000000000452009 |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 900000000000451002 |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 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 set to a value other than 900000000000451002 |Some| will be discussed with Members first and approved by the Technical Committee.

Addition of moduleId field

A moduleId 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, there would be a need to retire a component in one namespace, and add another (with a new SCTID) 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 moduleIds are used.

Combining the moduleId 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 .

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

Relationshiprefinabilityreference 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:

  • link UUIDs and SCTIDs , and;
  • add external Identifiers such as LOINC codes, where these are truly co-referent; and;
  • track history and organizational responsibility by linking old SCTIDs to new ones, where components are transferred from one name space to another, in order to allow uninterrupted use of the old SCTIDs .

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

RF1CrossMaps 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 RF1CrossMap 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 MapReference 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

A unique id in your namespace .

effectiveTime

Time

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

active

Boolean

'1'

moduleId

SCTID

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

A unique id in your namespace .

effectiveTime

Time

The nominal date of release for your reference set .

active

Boolean

'1'

moduleId

SCTID

The module Identifier for your authoring organization .

conceptId

SCTID

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

languageCode

String

The language of the Description .

typeId

SCTID

Create two descriptions, with each of the following types:

FSN

,

Synonym

.

term

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

A unique UUID for the new member record.

effectiveTime

Time

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

active

Boolean

'1'

moduleId

SCTID

The module Identifier for your authoring organization .

refsetId

SCTID

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

referencedComponentId

SCTID

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 Specification describes the Release Types and the WIPTSG provides advice on importing different Release types .

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
  • No labels