P476 Minimum length

This is a page of type Category:InM Closed Action Items.

Proposal 476

• Change Length Definition for attribute tables and data types Section 2.5.3 + 2.?? + 2.B.??

History

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.

Short Description

This proposal replaces proposal #435, which has been adopted earlier.

The intent of the original proposal was to migrate the length definition from the attribute table in the standard to the message profiles. In the meantime it became obvious that we need the length in the attribute table in an improved manner. (The elimination of the length definitions is still part of this proposal.) However, the sole definition of the maximum length is contra productive, so that we want to enhance the length definition to maintain the information for the minimum length of a field as well.

Both committees (Conformance and InM) has adopted this change in a former discussion, so that this proposal should formally bring forward the intended change.

Justification:

Within the v2.xml encoding and in V3 there is no length.

Within the v2.x family using standard encoding (ER7) it causes a lot of trouble to maintain the appropriate length in a consistent way among the different attribute tables.

Anyhow, within different localizations the length is just treated as a recommendation without any practical impacts. The maximum length is something site specific or highly depending on the implementation i.e. database table definition. Therefore, the values should be eliminated from the standard itself in general.

For an interoperable solution a length definition is still required, so that they should be moved to the definition of message profiles. With the latter, a user can ask a vendor to support a minimum to a maximum length of a certain field, a vendor is enforced to specify the exact length he can support.

• Some examples are:

field description length comment

• • MSH-1 field delimiter 1..1 we must have a delimiter. Per definition the length is equal to 1.
  • MSH-2 other delimiters 2..4 According to the descriptions (= implicit definition) of the different delimiters we can drop the last two, so that a minimum length f 2 and a maximum length of 4 is obvious.
  • MSH-7 time of message 4..22 The minimum length of a point in time is "year", so that the minimum can be set to 4 in general. However, it should be discussed whether "seconds" (or another degree of precision) must be supported so that the minimum length can be set to a higher value.
  • MSH-9 message type 15..15 all components with an exact length are required
  • OBX-2 data type of OBX-5 3..3 In order to support all data types, the minimum and the maximum length must be set to 3.
  • OBX-5 observation value 1..* Per definition this field has no limitation in its length.

And for data types:

data type description length comment DTM point in time 4..22 minimum is a year, maximum is the full length as a concatenation of all parts

??

It is anticipated that there are only a few data elements and data types that need an exact length definition in the standard. Most of the values highly depend on the site-specific implementation. Even for data elements with an assigned table and suggested/required values do not enforce an exact length definition. Here, a length would be helpful, but is not essential.

If no value can be defined, it can be left blank.

The minimum value should always be greater than zero. Expressing that this field can be empty must be done by using the usage code.

Proposed Solution

Keep the length column in attribute and component tables as normative.

Drop most of the values for the maximum length from all attribute tables. The ones that must be retained needs to be defined (see example) or can be edited in again later.

Update the conformance section (chapter 2B) in a way to make the length information optional for constrainable profiles. Whether in an implementable profiles the lengths should required needs further discussion, because some vendors provides the ability the maintain values of any length. (Well, this way it can be set to "*".)

Apply the same to data types (component tables).

V3 Implications

none

v2.xml Implications

none