View source for 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
# normative maximum length,
# conformance length, and
# 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: <code>ABC</code>, <code>SYL</code>, or <code>IDE</code>

The length information is given in one of two forms:
* the minimum and the maximum length separated by two dots, e.g. <code>m..n</code>
* the list of possible values for length separated by commas, e.g. <code>x,y,z</code>

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 <code>1..2</code> 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

= Example =

In 2.7, the <code>PID</code> segment has a mixture of lengths:

{| class="wikitable"
|-
!SEQ
!LEN
!C.LEN
!DT
!OPT
!RP/#
!TBL#
!ITEM#
!ELEMENT NAME
|-
|1
|1..4
|
|SI
|O
|
|
|00104
|Set ID - PID
|-
|...
|-
|5
|
|
|XPN
|R
|Y
|0200
|00108
|Patient Name
|-
|23
|
|250#
|ST
|O
|
|
|00126
|Birth Place
|-
|24
|1..1
|
|ID
|O
|
|0136
|00127
|Multiple Birth Indicator
|-
|25
|
|2=
|NM
|O
|
|
|00128
|Birth Order
|}

= 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