SNOMED Documentation Search


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

Current Version - Under Revision

The namespace-identifier continues to identify the Extension in which the component originated. However, it no longer implies a permanent immutable responsibility for maintenance. Instead, within specified limits and with agreement between the responsible organizations, the maintenance responsibility may be reassigned without issuing a new Identifier .

The permitted reassignments of responsibility are limited to ensure that the organization responsible for maintaining a component can be determined. Thus the end result of any transfer of responsibility must result in the component being maintained by one of the organization responsible for one of the following:

The values of the of the partition-identifier which previously indicated that a component was part of an Extension , continue to indicate that the SCTID contains a namespace-identifier . However, some components with a namespace-identifier may now be maintained as part of the International Release . Therefore, for clarity, the definition of partition-identifier has been revised to indicate that the values determine whether the SCTID (data type) conforms to the long format (with a namespace-identifier ) or the short format (without a namespace-identifier ). Only the IHTSDO can issue short formatSCTID (data type) (without a namespace), whereas an Extension owner must issue a long formatSCTID (data type) (including a namespace-identifier that is registered as belonging to them).

The moduleId (field) field, introduced in Release Format 2 and held against each component , records the organization currently responsible for maintaining the component . The moduleId (field) must refer to a module delivered by the organization maintaining the component and the namespace-identifier of this moduleId (field) must belong to the maintaining organization .

Following the change, migration of components between Extensions would be possible without a change to their SCTID (data type) , according to the following rules:

In all other cases, the existing rules for moving components between Extensions should be used. These require a change of SCTID (data type) to occur with tracking of inactivation in the appropriate Component Inactivation Reference Sets and cross-references created in the appropriate Historical Association Reference Sets (or as historical relationships in Release Format 1 ).

CAUTION:

Components that originated in the International Release must not be moved to any Extension without a change to the SCTID (data type) .

In order to make explicit which Extensions are parents of which other Extensions , concepts under the Namespace Concept may now be rearranged as a nested hierarchy of namespaces. All namespaces at the top level of this hierarchy are considered to have as their parent the International release . The Namespace Concept for an Extension that is dependent on another Extension may be nested as a child (sub-type) of the Namespace Concept for the Extension on which it depends.

CAUTION:

Components that originated in an Extension must not be moved to any other Extension unless the Namespace Concept associated with the target Extension is an ancestor of Namespace Concept associated with source Extension . The ancestry of Namespace Concepts is determined by the subtype hierarchy distributed as part of the International Release . Other moves between Extensions require a change of SCTID (data type) .

Guidance has been developed for producers and consumers of SCTID (data type), to help avoid conflicts of ownership and to facilitate identification of owning organizations (see Guidance for Producers of SNOMED CT Extensions and Guidance for Consumers of SNOMED CT Extensions ).


Feedback