Insufficient room error on bulkcopy

[Bob Schmid]

MESSAGE 1

[0:TEST] Insufficient room for integer part of numeric value ‘x80-x6-x498’

Bulkcopy failure:

I “x”‘d out first numeral of the number fore hippa concerns on this post

in 5.8.4 …any ideas ?

field defined as ST

Topic

[Levy Lazarre]

Robert,

This error most likely indicates that the field length in your outbound HL7 variant is too short and Cloverleaf is truncating the output.

Even though the field is defined as “ST”, you are sending in it a string beginning with digits, so Cloverleaf thinks that it’s a floating point number, hence the misleading warning about the “integer part of numeric value”.

Anyhow, just increase the length of this “ST” field in your outbound HL7 variant to a sufficient value (at least 11 chars in your example) and that should take care of the issue.

I hope this helps.

[Jim Kosloskey]

Hmmm is BULKCOPY affected by field lengths on the outbound?

We don’t use BULKCOPY here so I am not sure but I seem to recall it does not care.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Levy Lazarre]

In our institution, we make very limited use of BULKCOPY, but our experience has been that BULKCOPY indeed honors the field and segment lengths in the outbound HL7 variant, and will truncate the output values if the outbound lengths are less than the inbound ones.

We can easily verify this:

1. Create two HL7 variants, TestInbound (for input) and TestOutbound (for output)

2. In the TestOutbound variant, decrease the length of MSH.13 (Message Sequence Number, NM) and PID.19 (Social Security Number, ST) to 2 characters total each.

3. Create a test Xlate based on these two variants, with “BULKCOPY” as the only action.

4. Run any HL7 message through the Xlate.

Result:

1. The Message Control Number in the output is truncated to 2 chars and Cloverleaf issues the warning message “Insufficient room for integer part of numeric value…”

2. The SSN number in the output is also truncated to 2 chars.

A similar outcome occurs if a segment in the outbound variant has less fields than the corresponding segment in the inbound variant; fields will be dropped in the output.

The documentation is not clear, but people need to be aware of these caveats when using BULKCOPY.

[Peter Heggie]

We just got the same error on a PATHCOPY. For PV2.20 – expected number of insurance plans – someone entered -1.

Luckily the output was already a limited-use variant, so I increased the length to 3 and changed the type to ST and that worked.

Peter Heggie

[Jo Ellen Laansma]

I’m having this same problem with HL7 v2.6 FT1-29 which is defined as CWE length 250.  The value is 58160081146.  I tried changing to ST length 250 and it yields the same error.  I tried PATHCOPY and still the same error.  It seems most people have had success increasing the size.  Has anyone not been successful by increasing the size?

[Rob Abbott]

This “insufficient room” warning is most likely a field type issue.  If you define the field as “ST” instead of “NM” the error should go away.  The engine is trying to convert NM typed values to integer internally instead of treating them as a string.  I know it works this way with FRL.

@Levy – WRT fields being truncated during a COPY operation (this includes BULKCOPY, PATHCOPY, etc), an option was introduced in a recent release to “not truncate” regardless of field length.  This option is set on the variant under Options->Control Field Length

Rob Abbott
Cloverleaf Emeritus

[Author]

Replies