Search



You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

The basic reference set data structure consists of the following fields:

Field

Data type

Purpose

id

UUID

A 128 bit unsigned Integer, uniquely identifying the reference set member.

NO

effectiveTime

Time

Specifies the inclusive date at which this change becomes effective.

YES

active

Boolean

Specifies whether the member's state was active or inactive from the nominal release date specified by the effectiveTime field.

YES

moduleId

SCTID

Identifies the member version's module. Set to a child of 900000000000443000 | Module| within the metadata hierarchy .

YES

refsetId

SCTID

Uniquely identifies the reference set that this extension row is part of. Set to a descendant of 900000000000455006 | Reference set| within the metadata hierarchy .

NO

referencedComponentId

SCTID or UUID

Uniquely identifies the component that this row relates to, thus defining membership of this component in the Reference Set. This field can be set to the Identifier of a record within the Concept, Description, Relationship or Reference Set member file. However, the content of this field can be further restricted for each reference set by the reference set descriptor (see the " SNOMED CT Release Format 2 - Reference Set Specifications" document for more details).

NO

Zero or more other fields dependent on reference set type

SCTID, String, or Integer

Optional field(s) serving purposes specific to the reference set type. For details see 5.2 Reference Set Types.

Depends on refset type

Each reference set is identified and named by a concept in the metadata hierarchy. Therefore the reference set is identified by a concept identifier (an SCTID). 

Each row in a reference set file represents a reference set member.

  • Individual reference set members are uniquely identified by a identifier represented as a UUID
  • Each reference set member belongs to a single reference set, and it is linked to that reference set by the refsetIdfield. 
  • Each reference set member is also associated with a single referenced component by its referencedComponentId field. The referenced component may be a conceptdescriptionrelationship. If the referenced component is a concept that identifies another reference set than that reference set may be considered to be the target of the reference.
  • Like components,  reference set members can be versioned to inactivate or change the status of the member. So there may be several rows in a full release file and in this case the one with the most recent effectiveTime before or equal to the point in time under consideration represents state of that reference set member. If the active field of this row is false ('0'), then the reference set member is inactive at that point in time, which means that component it refers to is not a member of the reference set. If the active field is true ('1'), then the component referenced by the referencedComponentId field is deemed to be a member of the reference set.

The refsetId and referencedComponentId fields 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, the current row will be inactivated (by appending a row with the same id and the active field set to false). Another row with a new id will be appended to reference another component.

A component may belong to any number of reference sets.  A component may also be referenced by more that one member of the same reference set. This is not useful in the case of a simple reference set but is relevant for some reference sets. For example, a SNOMED CT concept may map to or from more than on codes in another code system.


Feedback
  • No labels