The basic reference set data structure consists of the following fields:
Field | Data type | Purpose | Part of Primary Key | |
id | A 128 bit unsigned Integer, uniquely identifying this reference set member. Different versions of a reference set member share the same id but have different effectiveTime. This allows a reference set member to be modified or made inactive (i.e. removed from the active set) at a specified time.
| NO | YES (Full /Snapshot) | |
The inclusive date or time at which this version of the identified reference set member became the current version. Note: In distribution files the effectiveTime should follow the short ISO date format (YYYYMMDD) and should not include the hours, minutes, seconds or timezone indicator. The current version of this reference set member at time T is the version with the most recent effectiveTime prior to or equal to time T .
| YES | YES (Full) Optional (Snapshot) | ||
The state of the identified reference set member as at the specified effectiveTime . If active = 1 (true) the reference set member is part of the current version of the set, if active = 0 (false) the reference set member is not part of the current version of the set.
| YES | NO | ||
Identifies the SNOMED CT module that contains this reference set member as at the specified effectiveTime . The value must be a subtype of 900000000000443000 | Module (core metadata concept)| within the metadata hierarchy.
| YES | NO | ||
NO | NO | |||
NO | NO | |||
Zero or more other fields dependent on reference set type | Optional field(s) serving purposes specific to the reference set type. For details see 5.2 Reference Set Types. | YES | NO |
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 refsetId field.
- Each reference set member is also associated with a single referenced component by its referencedComponentId field. The referenced component may be a concept, description, relationship. If the referenced component is a concept that identifies another reference set, 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