V2 Lengths

Background

HL7 V2.x provides guidance on field lengths. Historically the lengths provided were "recommended" lengths. The challenge with lengths is there is rarely a "perfect" length and some implementers wanted the ability to modify the lengths to fit local needs.

Specifically, HL7 2.5 section 2.5.3.2 says:

The length of a field is normative. Changes to the field length may be negotiated by a site agreement such as a conformance profile. [...] When this is done, it shall not render the implementation non-conformant.

The challenge with this language is that a "conformant" HL7 implementation can change the length of any field on a site-to-site basis or by creating a conformance profile with new lengths. Thus, effectively HL7 had no useful length value.

In an ideal world, the standard would be able to determine the maximum length for a value with authority, and all implementations would be able to handle the maximum length. However neither of these are true, and so starting with HL7 2.7 the specification defines

1. normative maximum length,
2. conformance length, and
3. whether a value may be truncated.

Normative lengths are only specified for primitive data types. Examples of value domains that have clearly established boundaries for minimum and maximum length:

• A date/time field
• A coded value component that may contain one of the following values: ABC, SYL, or IDE

The length information is given in one of two forms:

• the minimum and the maximum length separated by two dots, e.g. m..n
• the list of possible values for length separated by commas, e.g. x,y,z

When a normative length is asserted, conformant messages must have a length that lies within the boundaries specified. The boundaries are inclusive, so a length of 1..2 means the length of the item may be either 1 or 2.

Examples of value domains that do not have clearly established boundaries for minimum and maximum length:

• Parts of Names and Addresses
• Codes defined in external code systems
• Descriptive text

Solution

1. stop reporting lengths on complex types

• value is increasingly difficult to determine
• in an application only "atomic" information is stored
• (value is specific to vertical bar representation)
• value is useless and misleading
• only define lengths for primitive types (ST etc)
• only report lengths were the context of use has different rules to definition of type

2. differentiate between authoritative lengths and arbitrary lengths

• some lengths are authoritative
  • e.g.:
    • for codes coming from HL7-defined tables (they are a MUST)
    • control information
    • segment/field references
    • within realms: a set of fixed values is required in realm specific messages
  • authoritative lengths are fixed and normative - may not be violated
  • systems must support valid data that they encounter
• some lengths are arbitrary - any particular length is wrong
  • e.g.:
    • lengths of local codes and names, address parts
  • Do not make normative rules. But some length guidance is still useful
  • so provide a "conformance length": the minimum length that must be supported
    • any higher length is accepted, but not shorter
  • conformance length offers a degree of predictability without preventing real world problems being solved

3. add support for truncation pattern

• applications currenly truncates data, that is too long
  • in most cases without any notification/recognition
• it works better if systems are able to communicate about truncation
• truncation allows this.
• truncation pattern is not required
  • it is a new optional (5th) character in MSH-2
• some content (identification, clinical descriptions) are not allowed to be truncated
  • this is controlled by a special indication in C.LEN
• some data type specific truncation rules (numbers, dates)

4. make vendors aware of conformance statements/profiles

• documentation is the overall and optimal solution
• whatever a vendor has done, i.e. each individual use of lengths, must be documented
• try to make conformance statements required for conforming applications

Update from Ballot

There were a number of ballot comments about all this. Some brief summary points:

• No negative in principle comments
• A couple of requests for better document
• Some in principle concern about aspects of the truncation pattern
• lots of comments about inconsistency associated with the introduction of a new separator character