Check for message size

[Gary Atkinson]

Is there a way to check the message size before it leaves the engine?  I would like to check the message for X MB size and if it is greater than X to send the message to the error database.  I am received MDM messages and sometimes the message size is greater than the receiving system (Cerner) can handle.

Topic

[Jim Kosloskey]

There are two ways I can think of.

You will need a Tcl proc and I think this could be done either in a Tps proc or in an xltp proc (this one I am not sure of).

You need to get the message from the message handle.

Once you have that in a variable, you can either:

Do a string bytelength

    or

Do a string length

The difference is that if UTF is in use the bytelength will give you the actual number of bytes (that might be important and would be different than what string length returns), string length on the other hand returns the number of characters no matter how many bytes of storage are actually consumed.

So if a character in UTF takes 3 bytes and you have a single character message, bytelength would return 3 and length would return 1. Both would be correct but with different meanings.

If it were me, given the scenario you posted, I would use bytelength.

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

[Gary Atkinson]

Thanks Jim.

[Jim Kosloskey]

Another option (I have done this before):

Usually there is one field or one repeating segment that causes the excessive message size.

Sometimes the receiving system can agree that if a certain size is exceeded, all of the data up to that limit (minus a length of an eye-catcher) be issued and a fixed literal be inserted so that the person on the receiving system can know they have an incomplete message.

This is accomplished in the Xlate (with some reusable procs).

That has worked well a couple of times for me in the past and may be worth persuing.

If that looks like a possibility for you, let me know and I will be happy to share the procs and the techinque with you.

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

[Gary Atkinson]

Sure Jim, just shoot me an email: gatkinson@bwmc.umms.org

[Gary Atkinson]

The below proc does not return anything when using hcitpstest.  Here is the code:

Code:

######################################################################
# Name: check_msg_size
# Purpose:
# UPoC type: tps
# Args: tps keyedlist containing the following keys:
#       MODE    run mode (”start”, “run” or “time”)
#       MSGID   message handle
#       ARGS    user-supplied arguments:
#              
#
# Returns: tps disposition list:
#          
#

proc check_msg_size { args } {
   keylget args MODE mode               ;# Fetch mode
   set comment “MESSAGE IS TOO LARGE, NOTIFY VENDOR”
   set dispList {} ;# Nothing to return

   switch -exact — $mode {
       start {
           # Perform special init functions
   # N.B.: there may or may not be a MSGID key in args
       }

       run {
   # ‘run’ mode always has a MSGID; fetch and process it
           keylget args MSGID mh
           set msg [msgget $mh]
           set msg_len [string bytelength $msg]
           if { $msg_len > 4089446 } {
                    msgmetaset $mh USERDATA $comment
            lappend dispList “ERROR $mh”
           } else {
            lappend dispList “CONTINUE $mh”
           }
       }

       time {
           # Timer-based processing
   # N.B.: there may or may not be a MSGID key in args
       }
       
       shutdown {
   # Doing some clean-up work
}
   }

   return $dispList
}

[Gary Atkinson]

I did run a very small message through and hcitpstest returned the disposition and the message.

[Sergey Sevastyanov]

Gary,

To add to Jim’s 3rd option – we split long MDM messages that we send to one of our vendors into 2 or more messages using continuation pointer in MSH-14 and ADD and DSC segments. Of course the receiving system should be able to receive such messages.

[Jim Kosloskey]

Sergei,

I did not mention that as an option because I have never found a vendor that could understand or support the continuation concept.

So you say you have a vendor that does – would you care to name the vendor and system so we can all be aware of a vendor/product that has some potential?

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

[Sergey Sevastyanov]

Sure, Jim,

The vendor is Partners Healthcare (www.partners.org). We break long MDM messages with Radiology results and OP Notes and Discharge Summaries.

[Author]

Replies