Passing really long (over 100K) messages through the engine

[Mark Brown]

We’re trying to set up a new thread (from Muse to McKesson’s HPF) where a Z segment is very likely to be over 100K.  I was told by the vendor that other Cloverleaf users reported a problem with segments/messages over 100K.  They sent me two tcl procs that are supposed to split a long segment and then re-assemble it.  They didn’t write the procs and have no idea how to implement them.  I’ve tried a couple of ways, but nothing works.

Has anyone else experienced a problem with segments over 100K and how did you overcome the probem?  We’re running 5.3 of Cloverleaf on a Windows 2003 machine.

Any ideas would be appreciated.

Thanks

Topic

[Jim Beall]

We’ve been sending EKGs from MUSE with uuencoded PDFs in a Z segment for several years now.  I just checked some of the messages from today and they’ll all close to or greater than 100K and we’ve never had an issue.  We on 5.2 (an upgrade to 5.6 is IP) running on HP UX and we send to ChartMaxx, not HPF.

[Jim Kosloskey]

Mark,

Sometimes the issue is the data is contained in a single field and it is the field length not the segment length that becomes the issue.

The largest field defined in the HL/7 standard is 65k. However, in the Cloverleaf(R) variant one can make a field infinite in length.

It used to be you could do that via the GUI (the TK GUI) but I think the newer Java based Guis do not allow the specification necessary.

However, not all is lost. If you have a field that needs to be infinite, go into the HL/7 configurator for that variant and change the field in question to some length. That will create an entry for you in the field file in the formats directory for that variant and you can edit that with an editor (something I RARELY do) and change the length to the value for infinite.

Now the 64k question is what is that value? I seem to recall it is either 0 (zero) or -1 but maybe it is something else. I would try 0 (zero) from the GUI configurator and if the GUI does not let me change to that I would try that first (remember I said the GUI did not allow the proper change?). If the GUI allows specification of zero, try a message. If the mesage is truncated, try -1.

If the GUI does not allow 0 (zero) use the editor on the fields file and test. If that takes care of the problem – joy!.

If zero does not work, try -1. There IS a value that you can put in a field that allows it to be infinite.

To me that is a lot better than deploying Tcl for this issue.

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

[Michael Lacriola]

I have had experience with the Muse result issue going back to 2000. This is when the engine could nout support a field greater than 65,535 bytes.

The easiest way we handled it is to create a tps inbound proc that strips off that data and store it in a file based on some unique identifier from the message (like mrn.order.ekg).

Then, after the message flows through the engine and you do whatever translates, you simply attatch that informaito back on at the end (usually the OB tps stack).

Works great. We also use this strategy for a dictaphone report when they send two HL7 messages for one complete document when it is too big to fit in their message structure (they are limited to so many OBX segments).

Hope this helps.

[James Cobane]

Mark,

We have several interfaces that pass embedded .pdfs that are well over the 100K.  As Jim K. indicated, it is generally a field length that needs to be adjusted in the variant….

Jim Cobane

Henry Ford Health

[Jim Kosloskey]

Mike,

I have been using Cloverleaf(R) since release 3.1.

I think we could always specify a field to be infinite in length in the variant and there was not an issue in Cloverleaf(R).

The only issue I recall is in the later GUI wherein you cannot key in the value to indicate infinite (I now think the value for infinite is -1).

Do you recall specifying infinite and it did not function?

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

[Mark Brown]

Thanks everyone for their replies.  After some experimenting, it seems it was another case of the vendor blaming the engine as it appeared the problem was ultimately on the system receiving the data.

Thanks again

[Tim Wanner]

Cloverleaf 5.5 and below.  When setting up variants, there is a 100K limit on the size of a field, this was causing our ENCODED documents in the OBX segment to be chopped causing decoding issues.  You cannot increase the size through the GUI, but if you edit the “fields” file in the variant directory, you can increase this size with SUCCESS.

*** Important to note though, if you edit the variant again in the GUI, even if you do not touch that field, it will revert back to an eratic size.

[Author]

Replies