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.
2. If there is a need to transmit a description not supported by the code system, the description should be sent in the alternate code triplets supported by the data type. The local code and code system identifier must be supplied to identify the source of the term.

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

R1 CD data type

There are few limitations on the use of displayName in the R1 data type definitions (similar to the v2.6 CWE data type) with the following caveats:

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. The displayName is provided as a convenience only and should not be used to convey meaning. 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.
   1. The challenges associated with validating the appropriateness of a supplied string has the same problems as outlined for the CWE data type.

R2 CD data type

The V3 R2 CD data type is much more restrivitve in the use of displayName. General guidance for appropriate use includes:

1. Only descriptions supplied by the code system may be used in the displayName component.
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 must 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.

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 capability in the current CD, CNE or CWE data types to specify the desired interface term (term to display to the user). A proposal to address this should be submitted.
2. Need to add guidance for use of original text (who is the originator?)
3. How do extension terminologies work in this environment? Give examples for each code system.
4. Post-coordination in v2.x? Use of displayname for postcoordinated expressions?

Use Cases

Public Health Use Case

Reference testing for Salmonella

Public health labs need to be able to send 2 different display names for the same concept in the same message.

1. First we will report identification to the subspecies level– even here the lab SME might have a preference for description, that is NOT the same as the preferred term in SNOMED, or might not even be in SNOMED yet:

e.g. Salmonella enterica subspecies I (JTC - There is no subspecies I, this is a serogroup. It is listed in SNOMED CT as a child of serogroup O:3,10.) The SNOMED CT concept ID is [398342009] Salmonella I, group O:3,10

1. Then the lab reports the serovar name of the Salmonella in question using LOINC 20951-0

Serovar Fufu (SNOMED CT conceptID 41677008)

1. The lab also wants to report the antigenic formula using LOINC 56475-7

(SNOMED CT description Salmonella 3,10:z:1,5) I 3,10:z:1,5 (

Both serovar name and antigenic formula belong to the same SNOMED concept: 41677008^Salmonella Fufu (organism)

If descriptionIDs cannot be messaged, would it be legal to create a local code system to unambiguously message those descriptions? If not, one option would be to have explicit result value sets for each LOINC code, other options?