Description of elements (in terms of SNOMED CT)

Populating the CodeableConcept

This section shows you how to populate each field where the code carried is a SNOMED CT code and where it’s not a SNOMED CT code. It also includes population scenarios with examples.

Field by field population guidance

SNOMED CT

Other coding

Sending dm+d codes

Where a supplier is using the dm+d codes which does not contain any data at the descriptionId level, then we would not expect the descriptionId extension to be populated. Where the descriptionId is available then this SHALL be included.

The example below demonstrates how a dm+d code SHOULD be sent where there is no descriptionId available.

Sending a SNOMED CT concept with its associated preferred term

When sending a SNOMED CT concept id with its preferred term and the SNOMED CT Description ID is known, then the HL7 common extension coding-sctdescid SHALL be used and the element sctdescid SHALL be populated. Where the SNOMED CT Description ID is not known, then the codeable concept MAY be sent without it.

In the example below, the SNOMED CT Description ID is populated with the the preferred term, but there is no description ID display as the concept id was entered by the user and the preferred term was displayed to them when it was added.

Sending a concept where the coding system and code is unknown

In the exceptional case that the code is not known, then the code.text element MAY be populated without the need to populate a coding element.

Sending a SNOMED CT Description ID that is not the preferred term

In this case, the SNOMED CT Description ID represents a term that is different from the preferred term and therefore the description display will be different from that used to populate the code.coding.display element. Therefore the extension Extension UKCore-CodingSCTDescDisplay SHALL be populated with the term corresponding to the SNOMED CT Description ID.

Sending a translation set

In the case where a code was entered into the clinical system using a legacy coding system and the code was mapped to a SNOMED CT translation, the following scenario SHALL be considered.

In SNOMED CT, all concept ids always have more than one associated description: all have at least one fully specified name and at least one additional associated synonym. Of these, exactly one fully specified name and one synonym will be declared to be “preferred” at any point in time within a Realm Language Reference Set, but which terms are designated “preferred” can and does change over time.

Therefore, in most cases where such mappings have been created, they will have been mapped to an explicit pairing of one SNOMED CT concept id and one of its legitimate description IDs. The particular description ID selected might also correspond to the preferred term but often does not.

Exceptionally, mappings could correspond to a SNOMED CT concept id only and so no particular description is declared in the map. In these cases the description originally entered by the clinician in the legacy coding system SHALL be considered to be the clinically relevant text.

Rules for populating legacy coding

Read Code

All Read Codes SHOULD be represented using a full five characters.

• Where 4-byte codes are used these SHALL be preceded by a full-stop as in the NHS Clinical Terms superset (e.g. 4-byte code "6521" is represented as ".6521").
• Trailing full-stops are significant and SHALL be included (e.g. "H43" is not a valid Read Code and SHALL be represented in full as "H43..").
  • Care should be taken in any environment where a Read Code may have been subjected to auto-correction because:
    • Upper/lower case is significant
    • Conversion of a sequence of three full-stops "..." to a single "…" (ASCII Hex "85" Unicode Hex "2026") special character occurs in some environments and creates invalid Read Codes.

Read Code version 2 term code

Read Codes Version 2 uses a "Term Code" to distinguish between some alternative terms associated with the same Read Code. A Term Code is represented as a two-digit string and is only unique within the context of a single Read Code.

It is now widely recognised that many of the terms associated with a Read Code are not true synonyms. This issue was partially resolved in NHS Clinical Terms Version 3 and further disambiguation has occurred in development of SNOMED CT. However, in the meantime where Term Codes are stored these SHOULD be communicated with the Read Code.

A Read Code + Term Code combination is communicated as a single seven character code. Thus the code "7001200" represents the Term Code "00" associated with the Read Code "70012".

Note: that this specification requires the term to be conveyed in the message in addition to any coded representation. Therefore, safe communication is not dependent on use of the Term Code in all systems. Therefore, a sending system that does not support Term Codes for a particular item of information SHOULD NOT send a Term Code. Similarly a receiving system that does not support Term Code storage MAY ignore the Term Code when constructing a record entry. However, where a sending system stores the Term Code this SHOULD be included in the message and where a receiving system stores the Term Code this SHOULD be retrieved from the message.

NHS Clinical Terms Version 3 – Term Id

In NHS Clinical Terms Version 3 the TermId is a five character string that uniquely identifies an associated term (or set of two or three terms of alternative lengths). Although it is globally unique it says nothing about the associated concept and thus SHALL be combined with the Read Code. There are no plans to use the TermId in NHS Clinical Terms Version 3 and thus inclusion of TermId is not permitted.

Sending a description id not in the UK Edition

Sending a description id not in the UK Edition, but for a concept id that is in the UK Edition

Includes the case where the description id is locally declared to be the preferred term.

Sending a description id and concept id where neither is in the UK Edition

Clinical codes

Storage

When storing the item, the receiving system MAY choose to store any or all of the clinical codes associated with the item.

However, where the system supports SNOMED CT codes it SHALL store any SNOMED CT codes associated with the item.

Where the receiving system does not understand any of the supplied coding.system which a coding has been associated with the item (or no clinical codes were supplied), it MAY choose to record the item under a degraded code. The appropriate SNOMED CT degrade code SHOULD be used within the system to store the code.

Where an item that is being degraded is contained within a resource that infers a particular type of degrade then the appropriate code SHALL be used e.g. a code in a FHIR medication resource SHALL use the ‘Degraded medication’ code.

Clinical systems SHALL NOT attempt to infer a particular type of degrade code where there is no clear indication that a specific type of data has been degraded. In these scenarios the ‘Transfer degraded record entry’ code SHALL be used.

Display

When displaying the item to end users, it is the choice of the receiving system to design their system and user experience in a safe manner that best suits their users.

Propagation

When propagating coded data to another system, the system which received the item MAY choose which clinical codes to include when sending the item.

If a receiving system receives a SNOMED CT code that it does not understand it SHOULD store this code and propagate it onwards if the data is exported. If systems decide to do this, a consideration that might be useful is what would happen if the data item is changed/edited.

Original term text

Storage

When processing an item, the receiving system SHALL always store the original term text of the item. That is, the text chosen/manually entered by the clinician/user to describe the item they are recording. Failure to do this could result in the intended meaning of the item being altered.

The original term text will be available in one of the following fields in order of descending priority:

1. text
2. coding.extension.valueString in Extension UKCore-CodingSCTDescDisplay where coding.userSelected = TRUE (or is unpopulated, and only one coding element is present)
3. coding.display where coding.userSelected = TRUE (or is unpopulated, and only one coding element is present)

Where the receiving system can derive the original term text from the clinical code and the derived text is lexically identical to the original term text, then the receiving system is not required to store the text separately.

However, where the system supports SNOMED CT codes it SHALL store any SNOMED CT codes associated with the item where the coding.userSelected is set to ‘TRUE’ and propagate these onward in any future export of the data. As noted previously, some SNOMED CT codes received may be from a release or extension of SNOMED CT not available on the receiving system.

Display

When displaying an item to end users, the receiving system SHALL always display the original term text of the item.

Propagation

When propagating an item to another system, the receiving system SHALL always include the original term text of the item.