Conformance Implementation Manual

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.

2.B.7.3 Relationship between HL7 optionality and conformance usageConformance 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.

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.

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! The color indicates the status:

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

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

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