Chapter 2: Control – Conformance
2.A.1.0 Usage
Message content is governed by the cardinality specification associated (explicitly or implicitly) with each element of an HL7 message. Usage rules govern the expected behavior of the sending application and place limited restrictions on the receiving application with respect to the element. These usage codes expand/clarify the optionality codes defined in the HL7 standard. Usage codes are employed in a message profile to constrain the use of elements defined in the standard. The usage code definitions are given from a sender and receiver perspective and specify implementation and operational requirements.
The standard allows broad flexibility for the message structures that HL7 applications must be able to receive without failing. But while the standard allows that messages may be missing data elementfields or may contain extra data elementsfields, it should not be inferred from this requirement that such messages are conformant. In fact, the usage codes specified in a message profile place strict conformance requirements on the behavior of the application.
Usage Rules for a Sending Application
Presence Indicator / Description / Implementation Requirement / Operational Requirement /R / Required / The application shall implement “R” elements. / The application shall populate “R” elements with a non-empty value.
RE / Required but may be empty / The application shall implement “RE” elements. / The application shall populate “RE” elements with a non-empty value if there is relevant data. The term “relevant” has a confounding interpretation in this definition[1].
C / Conditional / The application shall implement “C” elements. / The application shall populate “C” elements with a non-empty value if the condition predicate associated with the element is true (See section 2.A.1.4, "Condition predicate"). The application shall NOT populate “C” elements if the condition associated with the element is false.
(NOTE: If the condition predicate is satisfied, C and R are equivalent from an operational viewpoint. If the predicate is NOT satisfied, C and X are equivalent from an operational viewpoint).
CE / Conditional but it may be empty / The application shall implement “CE” elements. / The application shall populate “CE” elements with a non-empty value if the condition predicate associated with the element is true and if there is relevant data (See section 2.A.1.4, "Condition predicate"). The application shall NOT populate “CE” elements if the condition associated with the element is false.
(NOTE: If the condition predicate is satisfied, CE and RE are equivalent from an operational viewpoint. If the predicate is NOT satisfied, CE and X are equivalent from an operational viewpoint).
X / Not supported / The application shall not implement “X” elements. / The application shall not populate “X” elements.
O / Optional / None. The usage indicator for this element has not yet been defined. For an implementation profile all optional elements must be profiled to R, RE, C, CE, or X. / Not Applicable.
Usage Rules for a Receiving Application
Presence Indicator / Description / Implementation Requirement / Operational Requirement /R / Required / The application shall implement “R” elements. / The receiving application shall process (save/print/archive/etc.) the information conveyed by a required element.
A receiving application shall raise an exception due to the absence of a required element. A receiving application shall not raise an error due to the presence of a required element,
RE / Required but may be empty / The application shall implement “RE” elements. / The receiving application shall process (save/print/archive/etc.) the information conveyed by a required but may be empty element. The receiving application shall process the message if the element is omitted (that is, an exception shall not be raised because the element is missing).
C / Conditional / The application shall implement “C” elements. / The receiving application shall process (save/print/archive/etc.) the information conveyed by a conditional element if the condition predicate associated with the element is true (See section 2.A.1.4, "Condition predicate").
A receiving application shall raise an exception due to the absence of a conditional element if the condition predicate associated with the element is true.
A receiving application shall not raise an error due to the presence of a conditional element if the condition predicate associated with the element is true,
A receiving application shall raise an error due to the presence of a conditional element if the condition predicate associated with the element is false,
CE / Conditional but it may be empty / The application shall implement “CE” elements. / The receiving application shall process (save/print/archive/etc.) the information conveyed by a conditional but may be empty element if the condition predicate associated with the element is true. The receiving application shall process the message if the element is omitted (that is, an exception shall not be raised because the element is missing).
A receiving application shall raise an error due to the presence of a conditional but may be empty element if the condition predicate associated with the element is false,
X / Not supported / The application shall not implement “X” elements. / The receiving application shall not process the message and raise an error if an element is sent.
O / Optional / None. The usage indicator for this element has not yet been defined. For an implementation profile all optional elements must be profiled to R, RE, C, CE, or X. / None.
Value / Description / Comment /
R / Required / A conforming sending application shall populate all "R" elements with a non-empty value. A conforming receiving application should process (save/print/archive/etc.) or ignore the information conveyed by required elements. A conforming receiving application shall not raise an error due to the presence of a required element, but may raise an error due to the absence of a required element.
Any element designated as required in a standard HL7 message definition shall also be required in all HL7 message profiles of that standard message.
RE / Required but may be empty / The element may be missing from the message, but should be sent by the sending application if there is relevant data. A conforming sending application should be capable of populating all "RE" elements. A conforming sending application that knows the required values for the element, should send that element. A conforming sending application that does not know the required values, shall omit the element.
Receiving applications will be expected to process (save/print/archive/etc.) or ignore data contained in the element, but should be able to successfully process the message if the element is omitted (no error message should be generated because the element is missing).
O / Optional / This code indicates that the Usage for this element has not yet been defined. A usage of ‘Optional’ may not be used in ‘implementation’ profiles (no-optionality profiles). Conformance may not be tested on an Optional field. Narrower profiles may be defined based on this profile, and may assign any usage code to the element
C / Conditional / This usage has an associated condition predicate (See section 2.B.7.9, "Condition predicate").
If the predicate is satisfied, follow the rules for R:
If the predicate is NOT satisfied, follow the rules for X.
CE / Conditional but it may be empty / This usage has an associated condition predicate (See section 2.B.7.9, "Condition predicate").
If the predicate is satisfied, follow the rules for the RE usage.
If the predicate is not satisfied, follow the rules for X.
X / Not supported / For conformant sending applications, the element shall not be sent. Conformant receiving applications may ignore the element if it is sent, or may raise an application error.
2.A.1.1 Relationship between HL7 optionality and conformance usage
Conformance usage codes are more specific than HL7 Optionality codes. Because of the requirement that conformance statements must be compliant with the HL7 message definition it is derived from, there are restrictions on what usage codes may be assigned to an element based on the HL7 Optionality. For example, any element designated as required in a standard HL7 message definition shall also be required in all HL7 message profiles of that standard message.
HL7 Optionality and Conformance Usage
HL7 Optionality / Allowed Conformance Usage / Comment /R - Required / R
RE - Required but may be empty[2] / RE, R
O - Optional / R, RE, O, C, CE, X / O is only permitted for constrainable profiles
C - Conditional / C, CE, R
X – Not Supported / X
B – Backward Compatibility / R, RE, O, C, CE, X / B is only permitted for constrainable definitions
W - Withdrawn / X
2.A.1.2
2.A.1.3 Draft 1: R. Snelick 03/11/11
Health Level Seven, Version 2.7 ©2010. All rights reserved. Page 207
Final Standard November 2010
[1] There are multiple interpretations of “RE” when a value is known. One is “the capability must always be supported and a value is sent if known”, the other is “the capability must always be supported and a value may or may not be sent even when known based on a condition external to the profile specification. The condition may be noted in the profile but can not be processed automatically”. This is what can be interpreted from the “relevant” part of the definition. Regardless of the interpretation the “RE” usage code, a set of test circumstances can be developed to sufficiently test the “RE” element. See the “Conformity Assessment of Conformance Constraucts” section for more details.
[2] This is a optionality added with 2.7. The meaning is slightly different from the message profile usage code of RE.