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 permissiveness 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. 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” 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 the usage notes for the component state only that the meaning of the term in the displayName attribute not change the meaning of the code as defined by the code system. This cannot be algorithmically evaluated, thus almost impossible to enforce.
   2. 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 for displayName 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.
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 V3 R1 or R2 data type specification to transmit the intent to use a description as a 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.
2. When the need to transmit a description not supported by the code system is mandated by jurisdiction, the description SHALL be sent in the alternate code triplets supported by the data type. The alternate local code and alternate code system identifier must be supplied to identify the source of the term.

Example 1

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

Example 2 - jurisdictional requirement

A US public health laboratory performs analysis for determination of the presence of Influenza in a patient with flu-like illness. The results of the laboratory analysis identify a "seasonal" influenza virus of the H1N1 subtype. The SNOMED CT concept for this organism is [442352004] Influenza A virus subtype H1N1 (organism). The laboratory reports the result on its paper report with a local term "Flu A H1N1", which is not one of the synonyms contained in the SNOMED CT terminology. Regulations from CLIA require that any messages transmitted about this result contain the same description string as appears on a printed report.

In this case, the system MAY send any of approved descriptions in text. The preferred display term SHALL be sent in the alternative text component of the CNE including a local code and code system identifiers.

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

Overview

During discussion on this topic, it was determined that the intent of the usage of displayName in data types R1 is explicitly represented in data types R2. Thus usage guidance for displayName is the same for both R1 and R2 data types.

CD data type

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. 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 includes interface terms developed by third-party vendors.
3. If there is a need to transmit a description not supported by the code system, the description SHALL be sent in the translation component supported by the data type. The local code and code system identifier must be supplied to identify the source of the term and evaluate the equivalence of the translation.
   1. Any string representation of the code is allowed, provided that it does not alter the meaning of the code as defined by the code system.

Use of Original Text

During the discussion of this topic, the use of orginalText was often brought up as an option for use as the "viewable" term to meet this need. Many issues surrounding the perception of what is to be included in originalText precludes it from use. These issues include:

1. source of orginal text
   1. Populated from a standardized "pick-list" derived from a standard terminology
   2. Populated from a standardized "pick-list" derived from an internally controlled terminology.
   3. Populated from a free text entry by the user.

Options 2 and 3 above may include localized representations that are not generally understandable, thus originalText is used to verify the veracity of the conversion of the text to a coded value.

1. It is unclear how to correctly use originalText in an extended series of transactions. i.e. is originalText only the representation that initiated the set of transactions or is it the text that originated with each of the transactions?

This lack of clarity on use in addition to its limitation as a referenced entity prohibits orginalText from being reliable representation of the preferred interface (display) term.