HL7 proposed guidance on use of displayName(V3 CD) and Text (V2.x CNE,CWE)

Draft recommendations from Vocabulary WG display name project

Overview:

The current definitions for the use of displayName (V3 CD data type attribute) and Text (V2.6 CNE and CWE data type) were used as the basis for the recommendations. They are currently defined as: V3 (May 2010 ballot)

R1 data type definition:

displayName (ST) - A name or title for the code, under which the sending system shows the code value to its users.

R2 data type definition:

displayName (ST) - A name, title, or representation for the code or expression as it exists in the code system (emphasis added) identified by the value of codeSystem.

V2.6 Definitions

CNE Text - The … descriptive or textual name of the identifier, e.g., myocardial infarction or X-ray impression. This is the corresponding text assigned by the coding system (emphasis added) to the identifier. Usage Note: Text description of code is optional but its use should be encouraged since it makes messages easier to review for accuracy, especially during interface testing and debugging.

CWE Text - The … descriptive or textual name of the identifier, e.g., myocardial infarction or X-ray impression.

Issues:

1. Confusion on the proper use of displayName is exacerbated by the ambiguity of the definitions as provided in both version 2.x (CWE) and the R1 data type specification. In these cases, there is no requirement that the string source in the displayName attribute actually come from the code system. This effectively allows users to place whatever string they prefer in the data type.
2. Additional ambiguity comes from version 2.6 usage notes: "CWE.2 - Descriptive Text is never required, and there are no hard and fast rules (emphasis added) on what text may be sent in this component. Of course, common sense suggests that if valued, the text should complement the identifier code of CWE.1."
3. The moniker of the attribute “displayName” further confuses the implementer by implying that the string in this attribute SHOULD be used as the interface term displayed to users on a system.
   1. In data types R1 this is further confused by the usage notes for the component, which states only that the meaning of the term in the displayName attribute does not change the meaning of the code as defined by the code system. This cannot be algorithmically evaluated, thus almost impossible to enforce.
   2. Additional confusion comes from usage notes explaining that the major purpose of displayName is for debugging messages, not providing an interface term.
4. While the use of displayName in V3 has been clarified in the R2 data types specification, there is no guidance on which assigned representation for the code is to be used in situations where the code system supplies multiple description terms for a single code.
   1. R2 usage notes have not changed from R1 and indicates that alternative displayName strings may be used as long as they do not change the meaning of the code. (Are usage notes normative? -JTC)
5. In situations where a sender or receiver requires a specific interface term be used that is not a component of a code system, (and may or may not be semantically equivalent to the concept represented by the code in a code system) there is no provision in either the V3 R1 or R2 data type specification to transmit this preferred interface term.

Proposed guidance:

Version 2.x

CNE data types

For attributes with a CNE data type, the standard specifies that the text description associated with the code SHALL come from the code system. The standard does not specify which description associated with a code must be used, thus any decription defined by the code system may be used in the text component of a CNE data type.

1. Conformance should be assessed algorithmically as all defined descriptions for a concept should be available within the code system used.

Example

A patient arrives in an emergency clinic in a state of hypothermia from exposure. The local terminology for this finding is "abnormally low body temperature". The SNOMED CT concept for this finding is [386689009] hypothermia and includes a number of alternative descriptions (body temperature below normal, decreased body temperature, state of hypothermia, termperature subnormal). The system may transmit any of the five descriptions associated with [386689009] as defined by SNOMED CT. Sending the local term above would be non-conforming with the standard as it is not represented in the list of description for the concept "hypothermia".

CWE data types

For attributes with a CWE data type the standard is sufficiently unspecified that one can essentially send any text string in CWE.2 with the following caveats:

1. The text string "should" represent either a text string provided by the code system from which the code is derived, or a text string that is "reasonably synonymous" with the semantics of the concept description. This would necessarily be enforced through implementation conformance or agreements between messaging partners.
2. In cases where there appears to be a conflict between the code in CWE.1 and the text description in CWE.2, the true meaning of the coded value is provided by the code and a code system defined description (i.e. the text description provided cannot override or change the meaning of the code as defined by the coding system).

Example

A public health laboratory would like to send the term "stool" as a specimen type description for the SNOMED CT code [119339001] in a lab reporting message as that is the term used on their paper reports (a CLIA requirement). The current description of the concept in SNOMED CT includes "stool specimen", but not "stool". This is allowed in v2.6 messages since this does not change the meaning; however, sending the term "fluid feces" would not be correct as this represent a different concept in SNOMED CT [258457009] (a child of stool specimen).

Version 3

1. The V3 CD displayName attribute is optional, but may only be valued with a human readable string that is provided by the code system.
2. Given that the displayName is not meant to convey meaning, any string provided by the code system may be used to populate displayName (e.g. SNOMED CT preferred term, LOINC Short Common Name)
3. Preferred interface terminology that is not a member of the description set supplied by the code system may NOT by used to populate the displayName attribute.
   1. This would include interface terms developed by third-party vendors.

Outstanding issue(s):

1. Interface terms that are not supported by code systems currently do not have a place in the CD data type. The following options need to be considered:
   1. Original text may be used if the CD.code value is not already derived from prior supplied original text value (dangerous).
   2. Translation may be used if the interface term is supported by another code system.
   3. There is no process in the current CD data type to specify the desired interface term and must be added to the data type.