Conformance Implementation Manual

It should be mentioned that this is the working draft!

INTRODUCTION

Health Level Seven (HL7) has started specifying messaging standards in 1987 (HL7 v2.x). Nowadays, this approach (HL7 V3) has evolved towards an architecture standard.

Nevertheless, the problem with messaging stays the same. It is very difficult for either vendors as well as users to specify the conformance requirements as well as to declare conformant behaviour of an application against an existing conformance statement.

This document should help vendors as well as users to create conformance statements as well as to declare conformance.

Scope

status for vendors

status for users

What are Profiles?

where to find info => chapter 2B

what you have to describe

usage codes

length information

v2.x: Optionality, Usage and Interversion compatiblity

Talking about profiles we have heard that two types of profiles do exist: A constrainable profile with optional elements and implementable profiles without optional elements.

Within chapter 2B we can read that constrainable profiles must be further constrained in order to become an implementable profile.

I am a little bit in doubt what "further" means. A simple interpretation is to remove any optionality. Of course, that is true. Another interpretation is "to add constraints", i.e. the requirements are getting harder. One can make an optional element required, but not vice versa. Right?

Based on this assumption I provide a new table indicating what kind of further constraints are allowed based on a given usage.

Based on the fact that optionality may change among version, we have to think about what will happen with a formerly conformant application. Therefore I provide another new section.

2.B.7.2 Usage in v2.x Standard

Usage refers to the circumstances under which an element appears in a message. Some elements must always be present, others may never be present, and others may only be present in certain circumstances. A set of codes has been defined to clearly identify the rules governing the presence of a particular element.

The rules govern the expected behavior of the sending application and limited restrictions on the receiving application with respect to the element. These usage codes expand/clarify the optionality codes defined in the HL7 standard.

Value	Description	Comment
R	Required	A conforming sending application shall populate all "R" elements with a non-empty value. conforming Conforming receiving application shall process (save/print/archive/etc.) or ignore the information conveyed by required elements. A conforming receiving application must 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 must be sent by the sending application if there is relevant data. A conforming sending application must be capable of providing contents for all "RE" elements. If the conforming sending application knows the required values for the element, then it must send that element. If the conforming sending application does not know the required values, then that element will be omitted.Receiving applications will be expected to process (save/print/archive/etc.) or ignore data contained in the element, but must 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.If the predicate is satisfied:A conformant sending application must always send the element. A conformant receiving application must process or ignore data in the element. It may raise an error if the element is not present.If the predicate is NOT satisfied:A conformant sending application must NOT send the element. A conformant receiving application must NOT raise an error if the condition predicate is false and the element is not present, though it may raise an error if the element IS present.
CE	Conditional but it may be empty	This usage has an associated condition predicate. If the predicate is satisfied: If the conforming sending application knows the required values for the element, then the application must send the element. If the conforming sending application does not know the values required for this element, then the element shall be omitted. The conforming sending application must be capable of knowing the element (when the predicate is true) for all "CE" elements.If the element is present, the conformant receiving application shall process (display/print/archive/etc.) or ignore the values of that element. If the element is not present, the conformant receiving application shall not raise an error due to the presence or absence of the element.If the predicate is not satisfied:The conformant sending application shall not populate the element.The conformant receiving application may raise an application error if the element is present.
X	Not supported	For conformant sending applications, the element will not be sent. Conformant receiving applications may ignore the element if it is sent, or may raise an application error.

2.B.7.3 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.

HL7 Optionality	Allowed Conformance Usage	Comment
R - Required	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	O is only permitted for constrainable definitions
W - Withdrawn	R, RE, O, C, CE, X

2.B.7.x Relationship for conformance usage in order to further constrain profiles

The following table should provide an overview, which usage is allowed as a further constraint based on a given usage in an underlying profile.

Given Usage	Allowed Constraint Usage	Comment
R – Required	R
RE – Required, but may be empty	R, RE
O - Optional	R, RE, O, C, CE, X	O is only permitted for constrainable profiles
C - Conditional	C, CE, R
CE – Conditional, but may be empty	C, CE, R, RE
X – Not Supported	X

"B" and "W" are not allowed in a profile.

2.B.7.x Interversion compatibility for conformance usage

Conformance is generally claimed to a specific profile for a specific HL7 version. The following table should provide an overview, what will happen to the conformance status given the fact that the underlying profile will change the usage from version to version: A formerly conformant application (profile) will become non-conformant!

Usage in profile	v2.3.1	v2.4	v2.5
R	R	R	R
R	O	R	R
R	O	B	W
RE	R	R	R
RE	O	R	R
RE	O	B	W
X	R	R	R
X	O	R	R
X	O	B	W

The color indicates the status:

green:	is conformant
yellow:	is going to become non-conformant with future version without any consideration
red:	is non-conformant

Open Clarifications:

In 2.B.7.2 it is said for "RE" elements that an application must be capable of providing the information.

In other words: There must be at least a single situation, where this application definitely fills in this information!

"RE" cannot be constrained to "X".

Open Questions:

A silly question: "How to deal with RE elements, if a system has no database field to provide this value (in general)?"

Answer A): The vendor has to change his application (database).

Answer B): The vendor can constrain the usage to "X".

V3: Mandatory, Required and Conformance

Cardinality	Mandatory	Conformance	Default or Fixed Value	Sender expectations	Receiver expectations	Notes
0..x	Mandatory	Not Permitted	None	Impossible (can't have mandatory and not permitted)
0..x	Mandatory	Not Permitted	Fixed or Default	Impossible (can't have mandatory and not permitted)
0..x	Mandatory	Optional	None	Impossible (can't have mandatory and optional)
0..x	Mandatory	Optional	Fixed or Default	Impossible (can't have mandatory and optional)
0..x	Mandatory	Required	None	impossible (can't have mandatory, minimum cardinality of 0 unless a non-null default or fixed value is specified)
0..x	Mandatory	Required	Default or fixed (not a null flavor)	Senders must support this element, but they don't have to send a value. If they do send a value it must not be a null flavor.	Receivers should always process this element. If no value is specified in the instance, they should behave as if the fixed or default value had been sent. If a null value is specified in the instance, they may raise an error.	1)
0..x	Mandatory	Required	Default or fixed (is a null flavor)	impossible (can't have mandatory, minimum cardinality of 0 unless a non-null default or fixed value is specified)
0..x	Not Mandatory	Not Permitted	None	Senders aren't allowed to specify this element. It should never appear in instance messages with a value or a null with a null flavor.	Receivers should not process this element if received. They may raise an error if a value or null flavor is present in the instance.
0..x	Not Mandatory	Not Permitted	Fixed or Default	Impossible (can't have defaults or fixed values for non-permitted items.)
0..x	Not Mandatory	Optional	None	Systems don't have to support this element. If they do support it, they don't have to send a value, and if they do send a value, it's allowed to be null with a null flavor.	Systems don't have to support this element. If they don't support it, they must ignore it. They must not return an error because a value is present just because they've chosen not to support the element. If they do support it and no value is sent, they interpret it as having a null flavor of "No Information".
0..x	Not Mandatory	Optional	Default (may be null flavor)	Systems don't have to support this element. If they do support it, they don't have to send a value, and if they do send a value, it's allowed to be null with a null flavor.	Systems don't have to support this element. If they don't support it, they must ignore it. They must not return an error because a value is present just because they've chosen not to support the element. If they do support it and no value is sent, they interpret it as if the default or fixed value had been sent.	2)
0..x	Not Mandatory	Optional	Fixed (may be null flavor)	Systems don't have to support this element. If they do support it, they don't have to send a value, and if they do send a value, it's allowed to be null with a null flavor.	Systems don't have to support this element. If they don't support it, they must ignore it. They must not return an error because a value is present just because they've chosen not to support the element. If they do support it and no value is sent, they interpret it as if the default or fixed value had been sent. If a value is present that differs from the fixed value, the receiver may raise an error.	2)
0..x	Not Mandatory	Required	None	Senders must support this element but they don't have to send a value. If they do send a value, it's allowed to be null with a null flavor.	Receivers must be capable of processing a value if present. However, if no value is sent, they interpret the value as having a null flavor of "No Information".
0..x	Not Mandatory	Required	Default (may be null flavor)	Senders must support this element but they don't have to send a value. If they do send a value, it's allowed to be null with a null flavor.	Receivers must be capable of processing a value if present. However, if no value is sent, they interpret the value as if the default value had been sent.	2)
0..x	Not Mandatory	Required	Fixed (may be null flavor)	Senders must support this element but they don't have to send a value. If they do send a value, it must be the fixed value.	Receivers must be capable of processing a value if present. However, if no value is sent, they interpret the value as if the fixed value had been sent. If a value is present that differs from the fixed value, the receiver may raise an error.	2)
1..x	Mandatory	Not Permitted	None	Impossible (can't have mandatory and not permitted)
1..x	Mandatory	Not Permitted	Fixed or Default	Impossible (can't have mandatory and not permitted)
1..x	Mandatory	Optional	None	Impossible (can't have mandatory and optional)
1..x	Mandatory	Optional	Fixed or Default	Impossible (can't have mandatory and optional)
1..x	Mandatory	Required	None	Senders must support this element and must always send a non-null value.	Receivers should always process this element. If no value is specified in the instance or a null value is specified, they may raise an error.
1..x	Mandatory	Required	Default	Impossible (no defaults unless min 0)
1..x	Mandatory	Required	Fixed value (null flavor)	Impossible (fixed value can't be null flavor when mandatory)
1..x	Mandatory	Required	Fixed value (not null flavor)	Senders must always send the fixed value.	Receivers should always process this element and may raise an error if the value is missing or differs from the specified fixed value.
bgcolor=red|1..x	Not Mandatory	Not Permitted	None	Impossible (can't have a value with minimum cardinality 1 that is not permitted)
1..x	Not Mandatory	Not Permitted	Fixed or Default	Impossible (item can't be 'not permitted' unless minimum cardinality is 0) NOTE: Not sure that this rule exists yet. || ||
1..x	Not Mandatory	Optional	None	Impossible (can't have minimum cardinality of 1 and optional)
1..x	Not Mandatory	Optional	Fixed or Default	Impossible (can't have minimum cardinality of 1 and optional)
1..x	Not Mandatory	Required	None	Senders must support this element and they must send a value or a null with a null flavor.	Receivers should always expect to receive a value or a null flavor. If a value or null flavor is not present, the receiver may raise an error.
1..x	Not Mandatory	Required	Default	Impossible (no defaults unless minimum cardinality is 0)
1..x	Not Mandatory	Required	Fixed	Senders must always send the fixed value which may be a null with a null flavour	Receivers should always process this element and should expect that the value will always be the fixed value. Receiver may raise an error if the value is missing or differs from the fixed value.

Notes:

1) Visio doesn't presently allow this. There is some opinion that defaults or fixed values should always be transmitted, meaning that minimum cardinality should be 1 and this combination wouldn't be allowed.

2) There is some opinion that defaults or fixed values should always be transmitted, meaning that minimum cardinality should be 1 and this combination wouldn't be allowed.

Comments:

Support for a sender means they have some way of capturing the data, either from database extraction, user entry or through receiving data from a third system and once captured are able to include the data in their message if the intended recipient has the necessary permissions/agreements in place to receive that data.

Support for a receiver means they are able to capture the data and do something useful with it - display, print, analyze or take some other action as appropriate for the business role fulfilled by that system. I.e. They cannot 'ignore' the data.

References

HL7 Version 2.x

• HL7 Version 2.6, (HL7 Health Level Seven, Inc., 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI, 2004), chapter 2B

HL7 Version 3.0

• HL7 Constraints, Refinement and Localisation, (HL7 Health Level Seven, Inc., 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI, 2004)