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, section 220.127.116.11 of HL7 2.5 says this: 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:
The length information is given in one of two forms:
- the minimum and the maximum length separated by two dots, e.g.
- the list of possible values for length separated by commas, e.g.
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
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
- some lengths are authoritative
- 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
- 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