V2 lengths - normative status
V2 Lengths
- A history by --A julian 14:29, 7 February 2008 (PST)
Contents
Proposal 435
Proposal 435 (Short Description: Drop the column for the maximum length from the attribute tables.) This was accepted by INM and conformance in WGM 01/06 and 05/06.[user:a_julian] The proposal was subsequently withdrawn.
Proposal 476
- Proposal 476 (Short Description: Keep length column as normative. Populate it with min/max. Drop most of the maximum, except where the lengths are well understood. E.G. MSH:1 is 1...1. MSH:2 length is 4...4. )
- Proposal was revisited October 8, 2007 in telcon.
- 20071008 Telcon: Motion (Doug/Grahame) (5-0-2)
- InM opposes across-the-board minimum length in the standard. Where necessary and appropriate, minimum length will be documented in the associated narrative of the individual fields. (e.g., MSH-2 Delimiters)
- 20071008 Telcon:Motion (Doug/Sandy) (7-0-0) Table further proposal 476/length discussion.
- 20071015 Telcon:Motion (Tony/Grahame) (3-0-0) 15October 2007 Move that further discussion is deferred to the working group meeting in January, and that we publicize the time to encourage maximum attendance.
- 20080114 WGM MOTION:Grahamm/Jenni P. We will not report maximum lengths for any fields or composite datatypes. Field and composite datatypes can be derived from their primitive components. We will define maximum lengths for the primitive datatypes. OBX-5 length is defined by the derived type from OBX-2.
- Proposed amendment: Where it is desired to further constrain the length it will be done in the narrative.
- Proposed amendment : change: OBX-5 length is derived from the length of the datatype from OBX-2.
- Motion to table Grahame/Klaus 16-0-0.
- Motion: Grahame/Klaus: (10-0-5)Changes to the field length may be negotiated by a Realm or site agreement such as a conformance profile. (CP 2.5.3.2)
- 10080117 WGM Motion:(Tony/Frank) (7-5-3) to approve Change length definition for attribute tables / data types
Current Length Language V2.6
- Chapter 2.
- 2.5.3.2 Maximum length
- Definition: Maximum number of characters that one occurrence of the data field may occupy.
- In the segment attribute tables this information is in a column labeled LEN.
- The maximum length is not of conceptual importance in the abstract message or the HL7 coding rules. The length of a field is normative. Changes to the field length may be negotiated by a site agreement such as a conformance profile. See section 2.B, "Conformance Using Message Profiles". When this is done, it shall not render the implementation non-conformant. The receiver must be able to receive up to the maximum field length, and the sender can send up to the maximum field length.
- Field length is determined based on the data type lengths, and should fall between the lower and the upper bounds for the corresponding data types. It is calculated to include the component and subcomponent separators. Because the maximum length is that of a single occurrence, the repetition separator is not included in calculating the maximum length See Section 2.5.3.5, "Repetition".
- The following conventions have been applied:
- a) The maximum length of the data field shall be expressed as a number.
- b) If the maximum length needs to convey the notion of a Very Large Number, the number 65536 should be displayed to alert the user. This convention takes the place of the practice in versions prior to 2.4 of abbreviating this expression as 64K.
- c) If the maximum length cannot be definitively expressed because the data type for the field is variable, the symbolic number 99999 should be displayed. This convention takes the place of the practice in versions prior to 2.4 of displaying the notation "varies" or some other non-numeric description.
In v 2.5 maximum lengths are being assigned to data types.
The length is normative - except . . .
- --A julian 14:16, 7 February 2008 (PST)The standard itself allows the use of alternate character sets, such as UNICODE UTF-8 which consists of a variable length code set, each code being 1,2 or 3 bytes. Therefore normative lengths in the standard may not be encodable in full UTF-8. Refer to Chapter 2.14.9.18
Comments
Hans,
no - the other way around: Length information in the standard should be normative! But with the current definition which allows for site-specific agreements make them informative. The problem is, that most of the length information causes trouble. This is the reason for this back-door in chapter 2.
As a consequence, the column should be kept, but most of the length information should be deleted. We can keep the current length as an informative appendix. So the status of length is unchanged in the future and no information is lost from the standard. Furthermore, we do have a normative length an implementer must follow.
This proposal represents a win-win situation and results in an improved standard. Nothing will be lost.
The big question for ARB is: What is the status of length information in the current standard given the back door in chapter 2? Normative or informative?
Frank
Buitendijk, Hans (MED US) schrieb:
Hopefully lengths as informative information will pass to avoid the lengthy debates they otherwise yield.
Siemens Medical Solutions USA, Inc. Hans J. Buitendijk 51 Valley Stream Parkway, Malvern, PA 19355-1406 Phone: +1 610 219 2087 Mobile: +1 484 354 6474 Fax: +1 610 219 3054 E-Mail: hans.buitendijk@siemens.com
Original Message-----
From: Grahame Grieve [1] On Behalf Of Grahame Grieve Sent: Friday, January 18, 2008 15:54 To: ShakirConsulting@cs.com Cc: mnm@lists.hl7.org Subject: Re: Lengths in v2
This is interesting news. Will this take affect in v2.7?
that's unknown; it might make it into this committee ballot. Will it pass that? who knows....
Will there be a way specify length contraints in profiles?
yes, always
Grahame
