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.x 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

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 definition as provided in the R1 data type specification. In that instance, there is no requirement that the string source in the displayName attribute actually come from the code system. This allows users to place whatever string they prefer in the data type.
2. 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 that does not restrict the displayName to a string defined by the code system, only that the meaning of the term does not change the meaning of the code as defined by the code system.
   2. Additional confusion comes from usage notes explaining that the major purpose is for debugging messages, not providing an interface term.
3. 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 supplied multiple possible 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.
4. 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:

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.