This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "V2 Lengths"

From HL7Wiki
Jump to navigation Jump to search
(added more information)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
= Background =
 
= Background =
  
−
* '''long''' controversy concerning lengths
+
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.
−
** most implementers do not take care of length at all, i.e. no change of application with other length definitions!
+
 
−
* lack of clarity concerning what we are trying to do
+
Specifically, HL7 2.5 section 2.5.3.2 says:
−
* problem of the back door
+
: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.
−
** introduced by local requirements
+
 
−
** max length must be exceeded in certain circumstances
+
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.
−
** normative max length is defacto '''useless'''
+
 
 +
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 =
 
= Solution =
Line 51: Line 139:
 
*whatever a vendor has done, i.e. each individual use of lengths, must be documented
 
*whatever a vendor has done, i.e. each individual use of lengths, must be documented
 
*try to make conformance statements required for conforming applications
 
*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

Latest revision as of 16:45, 14 September 2008

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

Example

In 2.7, the PID segment has a mixture of lengths:

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
Retrieved from "https://wiki.hl7.org/w/index.php?title=V2_Lengths&oldid=18781"