Conformance Implementation Manual
It should be mentioned that this is the working draft!
Contents
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
1..x || bgcolor=red|Mandatory || bgcolor=red|Not Permitted || None || Impossible (can't have mandatory and not permitted) || || 1..x || bgcolor=red|Mandatory || bgcolor=red|Not Permitted || Fixed or Default || Impossible (can't have mandatory and not permitted) || ||| 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 | 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.
Levels of Conformance
parseable
interpret against business logic
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)
