Draft Website - For Review Purposes Only

5 Constraints

This section presents the constraints that can be applied during the profiling process. The types of constraints that can be applied to the various parts of a profile were given in the previous section. For each of these constraints, this section provides a description and definition, and, additionally, the compliance and compatibility rules are presented.

For each of the conformance constructs described, the standard defines a set of “allowable constraints” (i.e., the rules for profile compliance) that can be applied. Allowable constraints are a means of restricting requirements in the base standard (or another profile) to make those requirements more specific. As such, elements that are “Required” cannot be relaxed, e.g., changed to “Optional”.

5.1 Usage

Usage rules govern the expected behavior of the sending application and the receiving application with respect to an element. The usage indicators expand/clarify the optionality indicators defined in the HL7 base standard. Usage determines, from an implementation perspective, whether an element must be supported. Additionally, from an operational perspective, usage determines whether the element must be present, can be present, or must not be present in a message instance for the sender. For the receiver, usage influences the processing of the element.

Table 5.1 provides an overview of the allowable usage indicators in message profiles (i.e., for constrainable and implementable profiles). While the base standard allows for all optionality indicators in some capacity, message-profile usage indicators have restricted use for a profile level.

Table 5.1: Conformance Usage Indicators and Definitions

Indicator	Name	Description
R	Required	The element is required and must be present in the message instance.
RE	Required, but may be Empty	The element is required to be supported and may be present in the message instance.
C	Undeclared Conditional	The usage of the element is conditional and is based on the outcome of a predicate that may not be defined initially. The usage indicator does not define an exact usage for the true and false outcomes and does not define an explicit predicate. Although the definition may be informative, the definition is incomplete and must be further defined. The undeclared conditional usage is the predominate form of conditional usage in the base standard. At this level, the specific context may not be known completely, therefore, precise constraints can’t be specified. In constrainable message profiles, a “C” usage may be used and is interpreted as a “passthrough” from the base standard (i.e., the specifier is indifferent). The “C” usage indicates implementation requirements are yet to be determined and, in this sense, behaves much like the “O” usage indicator, except it is known that a condition (details to be determined or removed) is associated with the element. For an implementation profile, all elements designated as undeclared conditional usage must be constrained to R, RE, C(a/b), or X.
C(a/b)	Declared Conditional	The usage of the element is conditional and is based on the outcome of a predicate. The usage indicator defines exactly the usage for the true and false outcomes and defines an explicit predicate that determines the true and false outcomes. The declared conditional defines explicit implementation requirements. The true and false outcomes must be constrained to R, RE, O, or X (therefore, nesting is not possible).
O	Optional	The usage requirements for the element have not been defined at this stage of specification. For an implementation profile, all elements designated as optional usage must be constrained to R, RE, C(a/b), or X.
X	Not-supported	The element is not supported and must not be present in the message instance.
B	Backward Compatible	The element has been designated for removal from a future version of the standard, and current use is discouraged. For an implementation profile, all elements designated as backward compatible usage must be constrained to R, RE, C(a/b), or X.

Conditional usage in the base standard often is under-specified in terms of explicitly defining a predicate and the true and false outcomes. Additionally, in many cases such a complete declaration is not possible, since the specific use requirements are unknown at the base standard level; only at the profile level can they be fully determined. Observing this reality, the conformance methodology specification henceforth recognizes this unadorned conditional usage designation as an undeclared conditional usage that can be used in constrainable message profiles. Undeclared conditional usage is distinguished from a declared conditional usage that is fully defined. The introduction of the undeclared conditional usage along with the declared conditional usage allows for multiple types of conditional usage to co-exist in message profiles without ambiguity. Undeclared conditional usage asserts no implementation requirements, but declared conditional usage does.

5.1.1 Usage Requirements for Sending Applications

Table 5.2 shows the usage rules requirements for a sending application. These requirements are expressed from the perspective of implementation and operational requirements. Usage implementation requirements indicate what the application must support for the element. Usage operational requirements indicate what the application must provide in a message instance. What is provided is sometimes dependent on conditions and data availability. Table 5.2 indicates what must be supported by the implementation and what must be provided in the message instance, not how it is accomplished.

Table 5.2: Usage Requirements Sending Applications

Indicator	Description	Implementation Requirement	Operational Requirement
R	Required	The application must support an element with an “R” usage designation.	The application must value an element with an “R” usage designation.
RE	Required, but may be empty	The application must support an element with an “RE” usage designation.	The application must value an element with an “RE” designation if data is known for that element.
C	Undeclared Conditional	There are no implementation requirements. The “C” usage designation is a placeholder indicating that the usage for this element has not yet been specified.	Not Applicable.
C(a/b)	Declared Conditional	The application must support the implementation requirements as indicated by the true (“a”) outcome and by the false (“b”) outcome usage indicators in the declared conditional definition.	The operational usage designation for the element is determined based on the outcome of an associated predicate at runtime. If the predicate associated with the element is true, follow the usage rule requirements for “a”, which must be one of “R”, “RE”, “O”, or X”: If the predicate associated with the element is false, follow the usage rule requirements for “b”, which must be one of “R”, “RE”, “O”, or X”.
X	Not supported	There are no implementation requirements.	The application must not value an element with an “X” usage designation.
O	Optional	There are no implementation requirements. The “O” usage designation is a placeholder indicating that the usage for this element has not yet been specified.	Not Applicable.
B	Backwards Compatible	There are no implementation requirements. The “B” usage indicates that the element is retained for backwards compatibility of the element. Another usage indicator may be assigned in a derived profile.	Not Applicable.

The use of the RE usage code is qualified with the “if data is known” clause. The sender must interpret the clause as “the capability must always be supported, and data must always be sent if known”. To clarify, the sender does not determine whether the data should be sent; to be conformant to the rule, the data must be sent. There is a misconception where the RE usage is interpreted as “the capability must always be supported, and data may or may not be sent even when known based on a condition external to the profile specification”. If there are valid external conditions, then the profile does not describe the use case accurately, and the profile needs to be modified accordingly, or possibly another profile needs to be created. This is not to say that the sender doesn’t control what data they send in production systems, but it is an indication that the sender is not conformant to the profile to which they are claiming conformance. The consequence of non-conformity created by not sending known data for an RE element is out of scope for this specification. See Section 1.5.1 for insight on how installed systems can handle non-conformities.

5.1.2 Usage Requirements for Receiving Applications

Table 5.3 shows the usage rules requirements for a receiving application. These requirements are expressed from the perspective of implementation and operational requirements. Usage implementation requirements indicate what the application must support for the element. Usage operational requirements indicate what the application must process in a message instance. The concept of “must process in a meaningful way” is intentionally vague at the interface level specification. Exactly what this means can be further defined in the profile definition in the context of a use case or in a functional requirements specification. The phrase “process in a meaningful way” can mean many things, as illustrated in the simple examples given below:

• Commit the data element to a data base
• Use the data element for some task (e.g., patient matching) and then discard the data
• Display the data element in the context of a report
• Evaluate the data element and, based on that evaluation, perform a certain task
• Compare the data to existing data base content and, if different, decide which data to keep based on source reliability or other factors

Table 5.3 indicates what must be supported by the implementation and what must be processed by the implementation, but not how the processing is to be accomplished.

Table 5.3: Usage Rules Requirements for a Receiving Application

Indicator	Description	Implementation Requirement	Operational Requirement
R	Required	The application must support an element with an “R” usage designation.	The receiving application must process in a meaningful way the information conveyed by an element with an “R” usage designation. A receiving application must raise an exception due to the absence of a required element. A receiving application must not raise an exception due to the presence of a required element.
RE	Required, but may be empty	The application must support an element with an “RE” usage designation.	The receiving application must process in a meaningful way the information conveyed by an element with an “RE” usage designation. The receiving application must process the message if the element is omitted (that is, an exception must not be raised because the element is missing). A receiving application must not raise an exception due to the presence of a required element.
C	Undeclared Conditional	There are no implementation requirements. The “C” usage designation is a placeholder indicating that the usage for this element has not yet been specified.	Not Applicable.
C(a/b)	Declared Conditional	The application must support the implementation requirements as indicated by the true (“a”) outcome and by the false (“b”) outcome usage indicators in the declared conditional definition.	The operational usage designation for the element is determined based on the outcome of an associated predicate at runtime. If the predicate associated with the element is true, follow the usage rule requirements for “a”, which must be one of “R”, “RE”, “O”, or X”: If the predicate associated with the element is false, follow the usage rule requirements for “b”, which must be one of “R”, “RE”, “O”, or X”.
X	Not supported	There are no implementation requirements.	None if the element is not present. If the element is present, the receiving application may process the message but must ignore the element content and may raise an exception. The receiving application must not process the information conveyed in an element with an “X” usage designation.
O	Optional	There are no implementation requirements. The “O” usage designation is a placeholder indicating that the usage for this element has not yet been specified.	Not Applicable. The receiver in an implementation profile or implementation makes a choice of an allowable usage indicator and operates based on that usage.
B	Backwards Compatible	There are no implementation requirements. The “B” usage indicates that the element is retained for backwards compatibility of the element. Another usage indicator may be assigned in a derived profile.	Not Applicable.

5.1.3 Conditional Usage

Conditional usage has several facets that necessitate further explanation, including formal definitions of undeclared and declared conditional usage, factoring conditional usage to a non-conditional usage, and predicate definition.

5.1.3.1 Undeclared Conditional Usage

Undeclared conditional usage is a designation that the element is conditional on another element or elements, however, the specific requirement can’t be determined at the current level of use case knowledge. Additionally, the conditional usage may be out of scope for the use case, but the specifier chooses to be silent on the element requirements; that is, the specifier neither fully defines the conditional usage nor eliminates its potential use in a derived profile. The undeclared conditional usage can be thought of as a “passthrough” in a message profile; and it is analogous to an optional element in the base standard, remaining as an optional element in a constrainable profile.

Although an undeclared conditional usage isn’t fully or formally defined, that fact does not imply that any requirements specified are not obligatory in a derived profile if “activated”. A requirement defined in the undeclared conditional usage must be preserved in any subsequent definition if the underlying condition hasn’t changed.

5.1.3.2 Declared Conditional Usage

The Declared Conditional usage is a fully-specified declaration of the true and false outcome usages based on an explicitly defined predicate. The formal definition is:

C(a/b) with an associated predicate where “a” and “b” in the expression are placeholders for usage codes representing the true (“a”) predicate outcome and the false (“b”) predicate outcome of the condition. The condition is expressed by a conditional predicate associated with the element. “a” and “b” must be one of “R”, “RE”, “O”, and/or “X”. As such, the conditional usage construct cannot be nested. The values of “a” and “b” cannot be the same; logically, if this is the case, the usage indicator resolves to a single non-conditional usage.

5.1.3.3 Factoring Conditional Usage to Non-conditional Usage

Table 5.4 describes various use cases for profiling conditional usage. The examples employ an excerpt of the CWE data type (as of version 2.7). CWE.1 (Code) is the code identifier, CWE.2 (Text) is the text that describes the code concept, CWE.3 (Code System) is the name of the code system of which the code (CWE.1) is a member, and CWE.14 (Code System OID) is the OID of the code system of which the code (CWE.1) is a member. The BASE column indicates the specification as given in the base standard, in which the Code and Text are optional and the Code System and Code System OID are conditional. The conditions and relationships for the CWE definition as defined in the base standard are that if a code is provided, then either the code system or the code system OID must also be provided.

Table 5.4: Examples of Conditional Usage

Element	Name	Base	DTF1	DTF2	DTF3	DTF4	DTF4 Predicate
CWE.1	Code	O	R	X	R	RE
CWE.2	Text	O	RE	R	RE	C(R/RE)	If CWE.1 is not valued.
CWE.3	Code System	C	R	X	X	C(R/X)	If CWE.1 is valued.
CWE.14	Code System OID	C	C	X	R	C(O/X)	If CWE.1 is valued.

Four profiling examples of the CWE data types that represent a data type flavor (DTF1, DTF2, DTF3, DTF4) are explained below, with references to information in Table 5.4:

DTF1: The specifier is requiring a code and the associated code system. Additionally, the specifier is making no statement on the requirement for CWE.14. This requirement designation is left to be specified in a derived profile. The usage of “C” is used instead of “O” because of the dependency of the element. Since the original condition has been satisfied by requiring CWE.3, CWE.14 can be profiled to one of R, RE, or X in a derived profile. There is no need to specify an explicit predicate since the condition is an undeclared conditional usage.

DTF2: The specifier is indicating that a code is not to be supported, therefore, CWE.3 and CWE.14 must also not be supported. The text component in this case is required. Since the original predicate will always resolve to false, the specification of a predicate is not necessary, and a non-conditional usage indicator can be specified (“X” in this example).

DTF3: The specifier is indicating that a code and the associated code system OID are required. The code system name is not to be supported. Since the original condition is satisfied by requiring CWE.14, the specifier has the option to constrain CWE.3 to R, RE, X or leave it to be determined in a derived profile (usage = C). In this case the specifier decided not to support (X).

DTF4: The specifier is constraining the data type flavor such that a code must be supported, and, if available, it must be valued (CWE.1). If the code is not available, then text describing the concept must be valued (CWE.2). If a code is provided, then the code system name (CWE.3) must be provided as well. The specifier is leaving it up to the specifier of a derived profile as to whether the code system OID (CWE.14) must be supported. Since a declared conditional usage is specified, an explicit condition predicate is given (Column DTF4 Predicate).

5.1.3.4 Predicate Definition

The predicate may be expressed in a computable language (recommended) or in plain text. This specification does not prescribe a specific method for expressing a predicate. However, a pseudo language (See Appendix A) has been developed to concisely and consistently express conditional usage predicates. The language is specifically designed for HL7 v2 in terms of relatability and ease of use. When possible, use of this language is recommended.

5.1.4 Usage Compliance

Table 5.5 presents the allowable transitions for each Usage code at each possible profile-level transition. The “Usage Code” column indicates the usage code for the “starting” profile level. The columns to the right of the Usage Code column indicate the possible usage code for the “ending” profile level. The “starting” profile level is indicated by the top line in the column heading, and the “ending” profile level is indicated by the bottom line in the column heading. For example, in the first row of the Usage Code column, the usage code is R, which is the usage of the element as defined in the Base standard. This usage code can only transition to R in a constrainable profile, as indicated by the Usage Code = R and Base-to-Constrainable coordinates.

Table 5.5: Usage Compliance

Usage Code	Base-to-Constrainable	Constrainable-to-Constrainable	Base-to-Implementation	Constrainable-to-Implementation	Implementation-to-Implementation
R	R	R	R	R	R
RE	R, RE	R, RE	R, RE	R, RE	R, RE
O	R, RE, C(a,b), O, X	R, RE, C(a,b), O, X	R, RE, C(a,b), X	R, RE, C(a,b), X	N/A
C	R, RE, C, C(a,b), X	R, RE, C, C(a,b), X	R, RE, C(a,b), X	R, RE, C(a,b), X	N/A
C(a/b)	R, RE, C(a,b), C(a’/b’), X	R, RE, C(a,b), C(a’/b’), X	R, RE, C(a,b), C(a’/b’), X	R, RE, C(a,b), C(a’/b’), X	R, C(a,b), C(a’/b’)
X	X	X	X	X	X
B	R, RE, C(a,b), O, X, B	R, RE, C(a,b), O, X	R, RE, C(a,b), X	R, RE, C(a,b), X	N/A
W	X	N/A	X	N/A	N/A

In an implementable profile, ultimately only two possibilities are allowed: either a specific element is supported ("R or RE") or it is not ("X"). For a conditional usage, the true and false outcomes must also be defined only as R, RE, or X.

An element with a usage of withdrawn is not to be used. The usage code “W” can only be profiled to “X”, and use of “X” is required in the profiles. The usage code “B” in a constrainable profile can be profiled to another usage indicator; however, this approach is not recommended (unless it is being profiled to "X"), since the intent of the authors of the standard is that this element not be used in the future.

5.1.4.1 Conditional Usage Compliance

Table 5.6 indicates the circumstances in which an undeclared conditional usage remains an undeclared conditional usage and the implications of that transition; and the circumstances in which an undeclared conditional is constrained to a declared conditional usage and the implications of that transition. Note, the conditional usage in the base standard is not referred to as an undeclared conditional usage.

Table 5.6: Use of Undeclared Conditional Usage

Indicator	Transition	Resulting Indicator	Comments
C	Base-to-Constrainable Constrainable-to-Constrainable	C	The message profile does not further specify the element definition beyond what is defined in the base standard. Since the message profile does not declare an explicit definition of the conditional usage and condition predicate, there are no implementation requirements. The specifier does not make an explicit declaration on the inclusion of the element. Therefore, the “C” usage is treated the same as the “O” usage indicator in terms of implementation requirements (i.e., the implementation requirements are determined in a derived profile).
C	Base-to-Constrainable Constrainable-to-Constrainable Base-to-Implementable Constrainable-to-Implementable	C(a/b) with predicate	The message profile explicitly defines the true (a) and false (b) usage outcomes for the conditional usage based on the predicate statement. A predicate statement is required. This declaration defines explicit requirements for implementation.

Elements with a conditional usage indicator require a separate examination, because a specialization allows for different combinations depending on the characteristics of the constraint.

Compliance assessment for elements with conditional usage (i.e., C(a/b)) is dependent on the respective true and false usage code specification. For example, if conditional usage for an element is specified as C(RE/O), the true usage code “RE” can be profiled to “RE” or “R” in a derived profile. The false usage code of “O” can be profiled to “R”, “RE”, “O”, or “X”. The conditional usage codes may collapse to a single non-conditional code if the usage codes are profiled to the same code. For example, if the “RE” and “O” usage are both profiled to “R”, then the usage code can be specified simply as “R” and not C(R/R). Table 5.7 summarizes the possible constraints applicable to conditional usage.

Table 5.7: Summary of Compliance Rules for Constraining Conditional Usage

Base Profile	Derived Profile	Comment
C(a/b)	C(a/b)	The derivation remains unchanged.
C(a/b)	C(a’ / b’ )	a’ is a valid specialization (constraint) of a, and b’ is a valid specialization of b; a and b can be constrained individually, the condition remains unchanged.
	a	If b’ is a valid specialization of b, and this is equal to a. For example, the usage is C(R/O), and because of the specific use case being profiled the specifier wants to further constrain the false outcome to R. Therefore, the conditional is C(R/R), which resolves to R.
	b	If a’ is a valid specialization of a, and this is equal to b. For example, the usage is C(O/X), and because of the specific use case being profiled the specifier wants to constrain the true outcome to never allow that element. Therefore, the conditional is C(X/X), which resolves to X.
C(a/b)	a	If the condition is always met in a specific use case.
C(a/b)	b	If the condition is never met in a specific use case.

5.1.5 Usage Compatibility

Compatibility is determined from the perspective of a receiver. Table 5.8 provides a compatibility analysis of an element’s usage in a sender profile to an element’s usage in a receiver profile. For a pair of profiles to be compatible, all element pairs in the profiles must adhere to the profile compatibility rules. For example, if the sender profile specifies an element as required and the receiver profile also specifies the corresponding element as required, then the profiles are compatible for that element. If, however, the sender profile specifies an element as not-supported and the receiver profile specifies the corresponding element as required, then the profiles are not compatible for that element, since the receiver is expecting data that the sender will never provide.

Table 5.8 addresses implementable profiles where each element must be profiled; that is, no elements can be optional. Table 5.9 addresses additional optionality choices available for constrainable profiles. Tables 5.8 and 5.9 do not take conditional usage into account; an analogous analysis can be performed for each true and false outcome of the conditional usage.

Optional elements apply only to constrainable profiles. Often specifiers develop constrainable-level profiles for national specifications. Their goal is to specify elements that are needed to meet their use case requirements. Beyond that, they allow trading partners to negotiate among themselves regarding local customization of the remaining un-profiled (or optional) elements.

Defining compatibility among systems requires a comparison of the capabilities of the sending side to the requirements on the receiving side through the means of profiles. For assessing compatibility, use case requirements are defined in higher-level constrainable profiles and are thus not considered. That is, expectations of the sender and receiver for each element have already been decided upon. For example, the assignment of “R” usage for an element on the sending side expresses the fact (or the intent) that this element is always valued in every message instance that is sent. “RE” usage expresses the intent that data will be present in messages if the data are entered into the system or are made available in some other way. In other words, these usage requirements identify what a receiver can expect in messages being sent to them. Statements for a receiver are clear expressions of their requirements. Therefore, a required element (“R” usage) indicates that the receiver must get this information in order to be able to process the message or a specific part of the message. Having said this, the pairing “R X” is deemed compatible, since the receiver can ignore a data element for which the sender always provides data, because the receiver does not need the data to fulfill its use case. although this behavior may not fulfill a certain use case or meet external expectations. Use case requirements must, therefore, be introduced as higher-level requirements in the form of a constrainable profile that must be fulfilled by both sender and receiver, i.e., the implementable profiles must be compliant to this higher-level constrainable profile. Providing such a use case requirement would mean that the applications are compatible, although the receiver is not compliant (i.e., the receiver’s implementable profile is not compliant with the constrainable profile). The receiver is conformant to its implementable profile, because this profile does not support the element; however, the fact that the receiver is not compliant prevents interoperability. In summary, specific aspects of compliance, compatibility, and conformance need to be met to enable interoperability.

Table 5.8: Sender/Receiver Pair Profile Compatibility Rules

Sender	Receiver	Compatible	Comment
R	R	Yes	Sender and Receiver have the same expectations.
R	RE	Yes	Receiver supports this element but is not always expecting it.
R	X	Yes	Receiver doesn’t support this element.
RE	R	No	Receiver is not guaranteed to get required data.
RE	RE	Yes	Sender and Receiver have the same expectations.
RE	X	Yes	Receiver doesn’t support this element.
X	R	No	Receiver will not get required data.
X	RE	No	Receiver will not get the data it needs for certain use cases. Note: a data value must be needed in at least one instance; otherwise, the element should not be profiled to RE. On the other hand, RE is the only construct that expresses the capability of the receiving system to handle the data.
		Yes	The element is not necessary for operation.
X	X	Yes	Sender and Receiver have the same expectations.

The analysis of optional elements for profile compatibility provides guidance for pairing potential implementable profiles derived from constrainable profiles. A definitive assessment of profile compatibility can’t be made until implementation profiles are developed; however, the guidance provided here will aid in the specification of constrainable profiles. As is to be expected, profile compatibility of constrainable profiles is directly linked to the requirements of the compatibility rules of Implementable profiles.

Table 5.9: Compatibility Analysis for Optional Elements

Sender	Receiver	Compatible	Comment
R	O	Yes	Receiver does not express any expectations or requirements for the data and may support this element in the future. Compatible receiver profiling in the implementable profile includes R, RE, or X.
RE	O	Only RE, X	Receiver does not expect data and may support this element in the future. Compatible receiver profiling includes RE or X.
X	O	Only X	Receiver does not expect data and may support this element in the future. However, compatibility can only be achieved if usage for the element is constrained to X.
O	R	Only R	Receiver requires the data. Compatible sender profiling option is R.
O	RE	Only R, RE	Receiver expects data in certain instances. Compatible sender profiling options are R or RE.
O	X	Yes	Compatible sender profiling options are R, RE, or X.
O	O	Possible	Compatibility can be achieved by following the rules for Implementation profiles as given above.

5.1.6 Usage and Conformance

The base standard allows broad flexibility for the message structures that HL7-conformant applications must be able to receive without failing; but, while the base standard allows messages to be missing data elements or to contain extra data elements, no inference should be made from these declarations that such messages are conformant in the context of a message profile. In fact, the usage codes specified in a message profile impose strict conformance requirements on the behavior of the application. For example, the presence of unexpected content for an unspecified element in the message profile is a conformance violation. A case in point would be where data are present for a fourth component of a data type, but the message profile only defines three components for the data type.

5.2 Cardinality

A data element often must occur more than once in the instance of a message. Cardinality is the conformance construct that is used to indicate this requirement. Cardinality controls the number of occurrences of an element an implementation must support and the number of instances of an element that can appear in a message. Some elements shall always be present (e.g., cardinality [1..1], [1..n]). Others shall never be present (i.e., cardinality [0..0]). Still other elements may or may not appear in the message instance, with zero or more occurrences (e.g., cardinality [0..n]). In certain circumstances, the maximum number of occurrences may have no specified/practical limit. In this case, it is identified with "*" (e.g., [1..*]).

Table 5.10: Cardinality

Cardinality	Interpretation	Valid Usage
[0..0]	Element is never present	X
[0..1]	Element may be omitted, and it can have at most one occurrence	RE, C(a/b), O
[1..1]	Element must have exactly one occurrence	R
[0..n]	Element may be omitted or may have up to n occurrences	RE, C(a/b), O
[1..n]	Element must appear at least once and may have up to n occurrences	R
[0..*]	Element may be omitted or may have an unlimited number of occurrences	RE, C(a/b), O
[1..*]	Element must appear at least once and may have an unlimited number of occurrences	R
[m..n]	Element must have at least m occurrences and may have at most n occurrences. When the usage indicator is RE, the element may be omitted (“zero occurrences”). m must be greater than 1 and n must be greater than or equal to m; the case where m equals 1 is addressed separately.	R, RE
[m..*]	Element must have at least "m" occurrences and may have an unlimited number of occurrences. When the usage indicator is RE, the element may be omitted (“zero occurrences”). m must be greater than 1; the case where m equals 1 is addressed separately.	R, RE

Cardinality boundaries apply both to primitive data of a simple data type and a collection of data contained in a complex data type. An explicit cardinality range is required for segment groups, segments, and field elements. Component and sub-component elements do not explicitly include a cardinality range, but a cardinality range is implicitly associated with each component and sub-component element. The associated cardinality depends on the element's usage code. For components and sub-components with a usage code of R, the associated cardinality range is [1..1]; for all elements with a usage code of RE or O, the associated cardinality is [0..1]; for all elements with a usage code of C(a/b), the associated cardinality is determined by the resultant usage based on the evaluation of the condition predicate; and for all elements with an X usage code, the associated cardinality is [0..0].

5.2.1 Relationship between usage and cardinality

• If the usage of an element is Required (R), the minimum cardinality for the element shall be equal to or greater than 1.
• If the usage of an element is not Required (R) (i.e., any code other than 'R'), the minimum cardinality shall be 0 except in the following condition:
• If the profile author wishes to express a circumstance where an element will not always be present, but when it is present it must have a minimum number of occurrences greater than one, they may document this rule by specifying the RE usage code with the minimum cardinality representing the minimum number of occurrences when the element is present. This expression would be in the form [m..n], indicating that permitted occurrences are either zero or the range of m through n.

Table 5.11: Example Cardinality-Usage Combinations

Cardinality	Usage	Interpretation
[1..1]	R	There will always be exactly 1 occurrence.
[1..5]	R	There will be 1 to 5 occurrences inclusive.
[0..1]	RE	The element must be supported, but may not always be present.
[0..5]	C(R/X)	If the condition predicate is true, there will be 1 to 5 occurrences inclusive. If the condition predicate is false, there will be 0 occurrences.
[3..5]	RE	If any values for the element are valued, there must be at least 3 and no more than 5 occurrences. However, the element may be absent (0 occurrences).
[3..5]	R	There will be 3 to 5 occurrences inclusive.

5.2.2 Repetition, Occurrence, and Cardinality

Historically, the base standard has used the term “repetition” to indicate the upper limit and not the actual number of times an element may repeat (in contrast to its well-established dictionary definition). The terms “maximum occurrences” or “maximum cardinality” are the preferred terms when describing the number of times an element may appear in a message. It is important to note that if the upper boundary for repetition is n it means n occurrences and not n repetitions (i.e., n+1 occurrences). This document uses the terms occurrences and cardinality.

5.2.3 Cardinality Compliance

Table 5.12 lists the rules for constraining cardinality. The left-most column indicates the cardinality for an element as defined in the “Parent Profile” (e.g., the base standard). The combination of the information in the “Derived Profile” column (always m..n) and the “Valid Compliance Rule” column indicates possible modifications of the cardinality constraint. The associated “Example(s)” column provides valid instances. Likewise, the information in the “Derived Profile” column (always m..n) and the “Invalid Compliance Rule” column indicate possible modifications (invalid in this case) of the cardinality constraint. The associated “Example(s)” column provides non-valid instances.

For instance, a cardinality defined in the parent profile as [0..0] and then constrained to [0..0] (m=0 and n= 0) is a valid constraint (row 1 – valid column); however, if the cardinality is constrained to [1..4], it is invalid (row 1 – invalid column). In Table 5.12 it is assumed that “m” is always less than or equal to “n”. Generally speaking, the cardinality range must be constrained by increasing the lower boundary and decreasing the upper boundary. The minimum cardinality has to be less than or equal to the maximum cardinality. Additionally, for some of the examples listed in Table 5.12 a specific value for a variable is used to facilitate the explanation.

Table 5.12: Compliance Assessment for Constraining Cardinality

Parent Profile	Derived Profile	Valid Compliance		Invalid Compliance
		Rule	Example(s)	Rule	Example(s)
[0..0]	[m..n]	m=0 and n=0	[0..0]	m≠0 or n≠0	[0..1], [1..4]
[0..1]	[m..n]	m≤1 and n≤1	[0..0], [1..1]	m>1 or n>1	[0..3], [1..2]
[0..x]	[m..n]	n≤x	x=3, [0..0], [0..3]	m>x or n>x	x=3, [4..6], [0..4]
[0..*]	[m..n]	m≤n	[0..200], [2..40]	m>n	[1..0], [5..1]
[1..1]	[m..n]	m=1 and n=1	[1..1]	m≠1 or n≠1	[0..1], [1..2]
[1..x]	[m..n]	m≥1 and n≤x	x=3, [1..3], [2..2]	m<1 or n>x	x=3, [0..3], [1..5]
[1..*]	[m..n]	m≥1 and n≥1	[1..1], [2..200]	m<1 or n<1	[0..0], [0..200]
[x..x]	[m..n]	m=x and n=x	x=3, [3..3]	m≠x or n≠x	x=3, [0..3], [3..4]
[x..y]	[m..n]	m≥x and n≤y	x=3, y=5, [4..5]	m<x or y<n	x=3, y=5, [3..6]
[x..*]	[m..n]	m≥x and n≥x	x=3, [3..3], [4..5]	m<x or n<x	x=3, [2..2], [2..6]

It is important to note that this analysis does not account for the dependencies that an associated usage constraint places on cardinality constraints. In Table 5.12, the usage reference point is O-optional. For a cardinality of [0..1], a valid constraint is [0..0] as indicated in row 2 – Valid Compliance column; additionally, [1..1] is also a valid constraint. In the context of a related usage, such constraints may not be valid. For example, for a cardinality of [0..1] and an associated usage of “RE-required, but may be empty”, the maximum cardinality must be 1 (allowing for appearance of the element). Likewise, if the usage is “X-not-supported”, then a cardinality setting of [0..0] is the only valid constraint of [0..1]. See Section 5.2.1 for additional information on the dependencies between usage and cardinality.

Note that the set of constraints given in Table 5.12 can be applied to any profile level in the hierarchy (i.e., the constraint table can be applied recursively). Additionally, once a constraint has been applied, only further (or the same) constraints can be specified in the (another) derived profile. For example, if the base profile “A” has a cardinality of [0..1] that is constrained to [1..1] in a derived profile “B”, then in derived profile “C” the cardinality constraint must remain as [1..1] (as indicated in row 5 of the Table). On the other hand, if the base profile “A” cardinality of [0..*] is constrained to [1..5] in a derived profile “B”, then in derived profile “C” the cardinality can be further constrained to [2..4]. In this example, the constraints transitioned from [0..*] (see row 4 of the Table) to [1..x] (see row 6 of the Table), and finally to [x..y] (see row 9 of the Table).

5.2.4 Cardinality Compatibility

Compatibility is a measure that indicates whether two specifications (or systems that implement the same specification) have harmonized requirements. Compatibility is determined from the perspective of a receiver. Table 5.13 presents an analysis of compatibility for a set of sender/receiver cardinality pairs. The analysis is a direct assessment of the sender/receiver pairs indicated and does not consider what pairs might actually be enacted for an element in a particular use case. For example, in the case of a sender cardinality of [1..1] and a receiver cardinality of [0..0], the receiver doesn’t need the data element to be valued in order to operate. If the sender has an expectation that the receiver must process the data element, however, then this requirement is indicated in the use case, and, as such, the receiver must set the cardinality for the element to [1..1], which would be part of the profile/interface negotiations.

Table 5.13: Compatibility Analysis for Cardinality

Sender	Receiver	Compatible	Comment
[0..0]	[0..0]	Yes	Sender and Receiver have the same expectations.
[0..0]	[0..m]	Yes	Receiver can process data but can also handle absence of data.
[0..0]	[n..m]	No	Receiver will not get required data if n>0.
[0..1]	[0..0]	Yes	Receiver has no expectations.
[0..1]	[0..1]	Yes	Sender and Receiver have the same expectations.
[0..1]	[0..m]	Yes	Receiver supports more than the sender.
[0..1]	[n..m]	No	Receiver will not get required data if n>0.
[1..1]	[0..0]	Yes	Receiver has no expectations.
[1..1]	[0..1]	Yes	Receiver processes the data.
[1..1]	[1..1]	Yes	Sender and Receiver have the same expectations.
[1..1]	[1..m]	Yes	Receiver supports more than the sender.
[1..1]	[n..m]	No	Receiver will not get required data if n>1.
[x..y]	[n..m]	Yes	If m<x.
[x..y]	[n..m]	No	If n>y.

5.3 Data Type Specialization (Flavor)

Data types and specializations of data types are core aspects of the HL7 v2.x standard and implementation guides. The HL7 v2.x standard provides a set of data types (referred to as the “base” data types). Typically, the base data types are not used “as-is” in implementation guides; instead they are constrained for a particular need in the profiling process. The specialization of the data type is referred to as a data type “flavor”. Each element in the data type can be constrained following the rules defined by the conformance constructs. The data type flavor is assigned a new identifier that can be referenced by other elements as part of the profiling process.

An example of data type specialization was given in Section 4.4. Additionally, a detailed discussion on data type specializations and on the HL7 v2 standardized data type library can be found in the HL7 Version 2 Specification: Data Type Specializations, Release 1 (currently in ballot resolution) and on the web site https:/v2.hl7.org/datatypeflavors (forthcoming). The goal of standardized data type flavors is to promote consistency and reuse of commonly used data type specializations.

5.3.1 Root Data Type Substitution

Under certain circumstances, a use case may require a data type substitution at the root level. One example would be when an IS data type is replaced with a CWE data type. Root data type substitutions are promotions, that is, more functionality is specified. The following compliance and compatibility rules apply:

• A primitive data type can replace a primitive data type at any level.
• A primitive data type must not replace a complex data type.
• A complex data type can replace a primitive data type but only at the field level.
• A complex data type can replace a complex data type at any level.
• A data type substitution must follow the conformance constructs compliance rules for all the constitute parts of the data type.
• The data type substitution must not reduce capabilities of the data type it is replacing
• The data type substitution must be backwards compatible with the data type it is replacing

When a substitution is made, a data type in which all constituent parts and attributes are compatible must be specified. Many substitutions are possible, and specifiers should exercise caution when changing the root data type, as detecting non-compliance can be challenging. Table 5.14 provides a few examples of root data type substitutions and an analysis of the substitution.

Table 5.14: Root Data Type Substitution

Original	Replaced By	Analysis	Comments
IS	CWE	Valid	1st component of CWE is compatible with “IS” data type
CWE	IS	Invalid	Data type demotion; fewer capabilities
TX	FT	Valid	Primitive data types; expands capabilities of text
FT	TX	Invalid	Reduces the capabilities of the element
CWE	CNE	Valid	Same structure, added usage constraint; in essence CNE is a data type flavor of CWE.
ST	TX	Valid	Contains the same sort of data. Allowable content differs.

5.3.2 Data Type Compatibility

Data Type Flavors can be replaced in derived profiles; however, requirements can only be strengthened. In general, the compatibility rules apply for each element in the data type flavor. For example, if a data type flavor specifies an element with R usage, the replacing data type flavor must also specify that element with R usage.

5.4 Content

Content constraints limit the allowed values of an element. Content constraints include coded values, fixed values, pattern restrictions, arbitrary data values, and element relationships.

Content is restricted based on a vocabulary definition that is bound to an element. The vocabulary definition may include a set of codes that can be used to populate an element in a message instance. The code set is associated with a specific element (which is known as “binding”), and the bound vocabulary should only contain codes that are meaningful for that element in a given context (use case). The base standard does not and cannot provide the necessary granularity or depth of specification, because it is designed to have broad utility. Therefore, the base standard provides a starting point, which includes normative (HL7) tables or informative (User) tables or may merely include a placeholder (i.e., a concept domain). The process of profiling elements that are bound to code values includes providing the value set definition, the binding to the element, and the strength of that binding.

Vocabulary constraints (coded values) are described in detail in Section 6.

Fixed Value: A fixed value constrains the content to a single value, e.g., “A08” that indicates an update event type in ADT messages. The more detailed and specific a certain data exchange specification is, especially in the case of specific use cases, the fewer possible options are valid for a data element. In some cases, the options for an element are reduced to a single value, thus providing a fixed (constant) value. A Fixed Value is represented in the message profile by the fixed value constraint attribute or can be specified by a conformance statement (See Section 5.7).

Pattern Restricted Value: A pattern-restricted value constrains the content of the element based on the specified pattern matching algorithm (e.g., a Medical Record Number format). A pattern-restricted value is specified using the conformance statement mechanism (See Section 5.7).

Element Relationships: Elements may have relationship constraints that must be maintained. This includes dependency of data values. Element relationships are supported by the co-constraint construct (see Section 5.8) and conformance statements (See Section 5.7).

5.5 Length

Length is defined as a constraint on the number of characters that may be present in the data value of one occurrence of a data element (object). The definition is system-independent; the number of characters is what is important at the application level. The application must be designed to ensure that storage space is adequate to suit the defined length, even if more bytes are necessary to physically store the data.

The definition and requirements for length in the base standard have changed over various versions. Although specific requirements were not always clear in the base standard, specifiers have the opportunity in message profiles to be definitive in specifying length requirements. Specification of length requirements are optional in message profiles. Additionally, length requirements can be specified selectively for certain elements where length requirements are of concern. Those length requirements that are specified using the methods in this document are deemed to be normative. Length requirements are only applicable to primitive data elements. Length constraints include Minimum and Maximum Length, Conformance Length, and Truncation Indicators.

5.5.1 Minimum and Maximum Length

Length is expressed as either a minimum and maximum pair (e.g. 1..20) and indicates the number of characters an occurrence of an element may have. A constraint on length restricts the range and thus reduces the capabilities, e.g., [1..2048] to [1..1024]. In some sense the length constraint is a bit counterintuitive when compared to usage. Usage requires that an application add capabilities, whereas a constraint on length may mean reducing an application’s current capability (as configured). The specific needs of a use case will dictate whether length constraints must be applied.

Table 5.15: Minimum and Maximum Length

Length	Interpretation
0..0	Not supported element; minimum and maximum set to 0.
1..1	Element must have exactly one character
1..n	Element may have up to n characters
n..n	Element must have exactly “n” characters
1..*	Element may have any length.
m..*	Element may have any length which is greater than or equal to “m”, where “m” is greater than or equal to 1.
m..n	Element must have a minimum length of “m” and a maximum length of “n” where “m” is less than or equal to “n” and “m” is greater than or equal to 1.

Length compatibility (Table 5.16) is based on a single criterion, that the receiver’s capabilities encompass the sender’s capabilities.

Table 5.16: Testing Possible Combinations of Implemented Length

	Sender		Receiver	Compatible
Implemented Minimum Length	s_min_len	<	r_min_len	No
	s_min_len	=	r_min_len	Yes
	s_min_len	>	r_min_len	Yes
Implemented Maximum Length	s_max_len	<	r_max_len	Yes
	s_max_len	=	r_max_len	Yes
	s_max_len	>	r_max_len	No

5.5.2 Conformance Length

5.5.3 Truncation

The conformance length or maximum length can be indicated with truncation behavior requirements. In the base standard, “=” denotes that the content of the element must not be truncated, and the “#” denotes that the content of the element may be truncated, and, if truncated, the rules for indicating data truncation must be followed.

Table 5.17: Truncation Flag Setting Allowable Transitions

Indicator	Transition	Allowed?	Comments
#	#	Yes	Same requirement
#	=	Yes	Requirement Strengthen
=	#	No	Requirement Relaxed
=	=	Yes	Same Requirement

5.5.4 General length Conformance Rules

The following list provides a general sets of length rules and observations that need to be considered when applying length constraints in message profiles:

Length constraint specification is optional in message profiles, either entirely or at specific data elements. If not specified, base standard requirements apply.

If specified, the following length rules apply:

Length constraints can only be applied to primitive data elements.

The Minimum Length and Maximum Length must be both be specified.

The Minimum Length and Maximum Length must be specified as a range of two non-negative integers in which the Maximum Length must be equal to or greater than the Minimum Length; an exception to these rules apply:

In a constrainable profile, the Maximum Length may be unknown and therefore may not be specified; in this case, the Maximum Length must be represented as ‘*”, e.g., 1..*.

Minimum Length must be 1 or greater (except for elements with X usage).

0..0 would be the length of an element with a usage of X if specified (best practice is to not specify a length).

In a derived profile, the Minimum Length must remain the same or can increase (given that the increased value is not greater that the Maximum Length).

Whereas the base standard (versions 2.3 to 2.6 inclusive) specifies the Maximum Length as normative, it is not considered as a constraint in a message profile. There are contradicting requirements. The specifier, at their discretion can specify any length constraint that satisfies their use case requirements.

Whereas earlier versions of the base standard specifies the Maximum Length for composite data elements, a message profile must not.

The Conformance Length constraint is not applicable in an implementation profile and must not be specified.

For conformance testing of a message that claims conformance to a constrainable profile, the Conformance Length will be treated as a Maximum Length constraint.

Whereas Conformance Length is informative in the base standard, Conformance Length is normative in a constrainable profile when explicitly specified in a message profile.

Whereas the base standard is not prescriptive on the strength of the truncation indicator, the conformance methodology (this specification) is, and asserts it as normative.

5.6 Slicing

5.6.1 Slicing Using a Discriminator

The slicing type “discriminator” assigns a data type flavor to the field slice (occurrence) based on an evaluation of a discriminator value. The discriminator must be a primitive component within the field. For example, when PID-11.7 (address type) = ‘H’ then the data type flavor XAD_1 is assigned to the field slice (PID-11). PID-11.7 (address type) is the discriminator and ‘H’ is the discriminator value. The discriminator value can have three evaluation types:

• Fixed Value, i.e., a literal value (e.g., PID-11.7 = ‘H’)
• Exists, i.e., a Boolean value (Present or Non-presence)
• Pattern, i.e., a Regular Expression

5.6.1.1 FIXED VALUE DISCRIMINATOR SPECIFICATION AND EXAMPLES

Table 5.18 and Table 5.19 show an example of slicing for the Patient Address field using the Fixed Value discriminator method. Table 5.18 shows the field definition for PID-11 (Patient Address). The cardinality is defined as 0..*. The base data type is XAD and the default slice data type is set to the XAD_0 data type flavor. The discriminator is 7 (Address Type), which indicates a component position within the field.

Table 5.18: Field Definition of Patient Address (PID-11): Slice Type = Discriminator Fixed

Field	Min Cardinality	Max Cardinality	Base Datatype	Default Datatype	Discriminator (Position)
PID-11 (Patient Address)	1	*	XAD	XAD_0	Address Type (7)

Table 5.19 shows the definition for each slice. The discriminator indicates the actual value that triggers and defines a “slice”. The first row in the table indicates that when (if) the discriminator contains the value of “H” then the field must conform to the requirements defined by the XAD_1 data type flavor. The field slice with these characteristics must appear in the message instance and only can appear once in the message instance. The requirements that dictate whether the field slice must appear are specified by the slice minimum and slice maximum parameters. Likewise, if the discriminator value contains “M” then the field instance follows the requirement indicated by the XAD_2 data type flavor. The field slice with this definition need not appear in the message (Slice Min = 0) or can appear more than once (Slice Max = *). Other discriminator values can also apply, but, since they are not explicitly listed, the default data type flavor defines the requirement for such field instances; in this case, XAD_0 is the data type flavor (see Table 5.19).

Table 5.19: Slice Definitions

Discriminator Value	Slice Datatype	Slice Min	Slice Max	Comment
“H” (Home)	XAD_1	1	1	If PID-11.7 = “H”, then the requirements for this field slice are defined by XAD_1 data type flavor. A field of this definition must appear once and only once.
“M” (Mailing)	XAD_2	0	*	If PID-11.7 = “M”, then the requirements for this field are defined by the XAD_2 data type flavor. The field slice need not appear or may appear an unlimited number of times.

Slicing is used most often for a field that has multiple occurrences. However, the discriminator method can be used for a field with a maximum cardinality of one. In this case, the field instance requirements vary based on the discriminator value, even though there can be only one instance of the field. For example, the discriminator could be the address type as in the previous example. If the address type is “H”, then the field instance would follow the requirements specified in the XAD_1 data type flavor. Likewise, if the address type is “M”, then the field instance would follow the requirements specified in the XAD_2 data type flavor. So, the field would follow one or the other definition based on the address type value (discriminator value) and in aggregate can only appear once, since the cardinality of the field is 1..1. Note, for this example, the default data type is not defined by specifier choice. Table 5.20 and Table 5.21 show the specification of this example.

Table 5.20: Field Definition of Patient Address (PID-11): Slice Type = Discriminator Fixed

Field	Min Cardinality	Max Cardinality		Base Datatype	Default Datatype	Discriminator (Position)
PID-11 (Patient Address)	1	1		XAD	NA	Address Type (7)

Table 5.21: Slice Definitions

Discriminator Value	Slice Datatype	Slice Min	Slice Max	Comment
“H” (Home)	XAD_1	0	1	If PID-11.7 = “H”, then the requirements for this field slice are defined by XAD_1 data type flavor. A field of this definition need not appear and at most will appear once.
“M” (Mailing)	XAD_2	0	1	If PID-11.7 = “M”, then the requirements for this field are defined by the XAD_2 data type flavor. A field of this definition need not appear and at most will appear once.

5.6.1.1.1 EXISTS DISCRIMINATOR SPECIFICATION AND EXAMPLES

The “Exists” discriminator methods work much like the “Fixed Value” discriminator method except that the discriminator value can be either “valued” (True) or “not-valued” (False). Only those two possibilities exist. Table 5.22 and Table 5.23 provide examples. The field definition defines the minimum and maximum cardinality for the field and the discriminator. However, there is no default data type flavor since the slicing definition (Table 5.23) covers all possibilities.

Table 5.22: Field Definition of Patient Address (PID-11): Slice Type = Discriminator Exists

Field	Min Cardinality	Max Cardinality	Base Datatype	Default Datatype	Discriminator (Position)
PID-11 (Patient Address)	1	*	XAD	NA	Address Type (7)

If only one of the discriminator values is specified, then a default data type flavor is necessary (in essence, the default is specifying the requirements for the slice in which the discriminator value was indicated).

Table 5.23: Slice Definitions

Discriminator Value	Slice Datatype	Slice Min	Slice Max	Comment
True	XAD_1	0	*	If PID-11.7 is valued, then the requirements for this field slice are defined by XAD_1 data type flavor. The field slice need not appear or may appear an unlimited number of times.
False	XAD_2	0	1	If PID-11.7 is not valued, then the requirements for this field are defined by the XAD_2 data type flavor. A field of this definition need not appear and at most will appear once.

5.6.1.1.2 PATTERN DISCRIMINATOR SPECIFICATION AND EXAMPLES

The “Pattern” discriminator method uses a pattern to determine the slice that is triggered. Table 5.24 and Table 5.25 illustrate an example. The use case in this scenario is that if a postal code is valid for the United States or Canada, then specific constraints are specified for the field instance. If the postal code is neither, then a default set of constraints are applied. Note that for the United States, two types of postal codes are acceptable, hence there are two separate slices that refer to the same data type flavor (XAD_1). The discriminator values are represented as a pattern, and the discriminator (position) is PID-11.5 (ZIP or Postal Code).

Table 5.24: Field Definition of Patient Address (PID-11): Slice Type = Discriminator Pattern

Field	Min Cardinality	Max Cardinality	Base Datatype	Default Datatype	Discriminator (Position)
PID-11 (Patient Address)	1	*	XAD	XAD_0	ZIP or Postal Code (5)

The above example shows how an application can handle different requirements of XAD based on the postal code. In most cases, a message is likely to contain only one type or the other, but both could be supported in the same message for a patient. This specification supports either configuration. Note that a similar result could be accomplished using conditional usage.

Table 5.25: Slice Definitions

Discriminator Value	Slice Datatype	Slice Min	Slice Max	Comment
[0-9]{5}	XAD_1	0	*	If PID-11.5 matches the five-digit pattern for United States zip code, then the requirements for this field slice are defined by XAD_1 data type flavor. The field slice need not appear or may appear an unlimited number of times.
[0-9]{5}-[0-9]{4}	XAD_1	0	*	If PID-11.5 matches the nine-digit pattern for United States zip code, then the requirements for this field slice are defined by XAD_1 data type flavor. The field slice need not appear or may appear an unlimited number of times.
(?!.*[DFIOQU])[A-VXY][0-9][A-Z] ?[0-9][A-Z][0-9]	XAD_2	0	*	If PID-11.5 matches the pattern for Canada postal code, then the requirements for this field are defined by the XAD_2 data type flavor. The field slice need not appear or may appear an unlimited number of times.

5.6.1.2 Slicing Using Ordering

Ordered slicing defines specific requirements based on the order sequence in which the given field instance appears. That is, the order sequence in which the field instance appears is significant for the use case. Table 5.26 illustrates a field definition for Patient Name (PID-5). Table 5.27 defines the requirements (data type flavor) for the associated slice occurrence. For the first occurrence of PID-5 the data type definition is XPN_1, for the second occurrence of PID-5 the data type definition is XPN_2, and for any other occurrence of PID-5 the data type definition is XPN_0 (the default data type flavor assigned).

Table 5.26: Field Definition of Patient Name (PID-5): Slice Type = Ordered

Field	Min Cardinality	Max Cardinality	Base Datatype	Default Datatype
PID-5 (Patient Name)	1	*	XPN	XPN_0

This strategy can be combined with the data type flavors and constant values to specify particular occurrences of the type of patient name. For example, if it were necessary to constrain the Patient Name field tightly such that the first occurrence of the field is the legal name (PID-5.7 = ‘L’), then the data type flavor, XPN_1 in this example, can set the XPN.7 (Name Type Code) to ‘L’ as a constant value.

Table 5.27: PID-5 Ordered Slicing Definition

Occurrence	Slice Datatype
1	XPN_1
2	XPN_2

The occurrence value is not required to be specified for each field instance nor is an order sequence required. For example, if a specifier only wanted to assign a specific data type flavor to the second occurrence, then only the second occurrence would be specified. All other occurrences, including occurrence one, would follow the requirements defined by the default data type flavor for Patient Name.

5.6.1.3 Non-Selective Slicing

The “Non-selective” slicing method can be employed in cases where the specifier wishes the field instances to follow the constraints of one of a number of constraint sets (data type flavors). Table 5.28 and Table 5.29 illustrate the use case.

Table 5.28: Field Definition of Patient Address (PID-11): Slice Type = Non-selective

Field	Min Cardinality	Max Cardinality	Base Datatype
PID-11	0	*	XAD

In this specification, the PID-11 can occur an unlimited number of times. A field occurrence must follow the constraints of any one of the three data type flavors (XAD_1, XAD_2, XAD_3)

Table 5.29: PID-5 Ordered Slicing Definition

Slice Datatype List	Comment
XAD_1, XAD_2, XAD_3	The field instance must adhere to the constraints specified in one of the specified data type flavors (XAD_1, XAD_2 or XAD_3).

5.7 Conformance Statement

A conformance statement is a mechanism to express a constraint using a natural or computable language. An example is:

“IF RXA-18 (Substance/Treatment Refusal Reason) is valued THEN RXA-20 (Completion Status) SHALL contain the value 'RE' (Refused)”.

Conformance statements provide a catch-all mechanism for expressing a constraint that can’t be defined by the constraint types provided by the other conformance constructs (e.g., usage). Conformance statements should not be used in place of the conformance constructs, i.e., do not use a conformance statement to constrain the usage of an element (e.g., “PID-8 (Administrative Sex) is Required.”).

The forms in which a conformance statement can be expressed vary and can appear as a text description or a computable expression. In both forms a specific syntax should be used to ensure that the requirement details are complete and to improve readability for the implementer. This specification does not require a specific method or language. However, a pseudo language specifically for HL7 v2 has been developed and is the recommended method for expressing conformance statements (See Appendix B).

5.8 Co-Constraints

The co-constraint construct is a related constraint concept that is used to express dependencies among a set of data values. An HL7 v2 message in which observations are conveyed is one example of how co-constraints are used. Such constraints typically follow the form of “if OBX-3.1 = LOINC code XXXXX-X then OBX-2 SHALL BE “CE” and OBX-5.1 SHALL contain a value from the value set YYY” or a similar form. A co-constraint is not limited to use with observations, but it appears most frequently with observations. A convenient way to illustrate a set of co-constraints is to present them in a table format. Table 5.30 illustrates an example for a set of immunization observations.

Table 5.30: Excerpt of Co-Constraints of Immunization Observations

LOINC(OBX-3)	Description	Data Type(OBX-2)	Data Type Flavor (OBX-2)	Value Set(OBX-5)	Units (OBX-6)
30973-2	Dose number in series	NM	NM	Not applicable	“NA” from HL70353
59782-3	Number of doses in series	NM	NM	Not applicable	“NA” from HL70353
59783-1	Status in Immunization series	CE	CE_01	Local Value Set
30956-7	Vaccine Type	CE	CE_01	CVX - Vaccine Group
30980-7	Date next dose is due	DT	DT_D	Not applicable
59779-9	Immunization Schedule	CE	CE_01	ScheduleIdentifier
30963-3	Vaccine funding source	CE	CE_01	FundingSource

Usually the OBX-3 (Observation Identifier) is the key upon which data dependencies are based. For example, when OBX-3 contains the LOINC code 30956-7 (for Vaccine Type), the data type in OBX-2 must be “CE” (for coded element), and OBX-5 (the Observation Value) must contain a code from the CVX value set (specifically from the Vaccine Group). The data type representation for OBX-5 is given by the data type flavor CE_01 definition. This example shows how co-constraints are typically expressed in HL7 v2. Other mechanisms can also be used. Additionally, co-constraints can be grouped or predicated on a condition. For example, a group of OBX segments with interdependences may be required predicated on a certain value in the segment group (e.g., OBR-4).

5.9 Semantic Refinement

Every element has associated data semantics that define the sort of data the element is carrying and how those data should be interpreted. That is, the data element is bound to a concept (logical meaning). The base standard provides these element definitions. In some instances, the definitions are broad, because the context of a given use case is unknown. Profiles, therefore, can refine the semantics of a data element based on the use case. This refinement is in prose, and hence not conducive to computerized understanding, that is, implementers will have to read and adjust implementation accordingly. Best practice is to provide only refined element semantics in profiles, and not to repeat existing element definitions from the base standard. HL7 v2 profiles have an Annotation mechanism that supports documentation of semantic refinements in a structured way.

5.9.1 Annotations

An annotation is descriptive text that accompanies a standard element definition or concept and provides additional information pertaining to the use of the element (i.e., it is an elaboration of the concept as it relates to the use case to which it is being applied). An annotation may be associated at any defined element level in a message profile (e.g., a field). HL7 v2 supports a number of predefined annotation types:

Annotations do not introduce new requirements in the form of constraints or extensions; they are informative and can be used to supplement the understanding of the element.