No destination for message (105)

[Jeff Dinsmore]

I have an interface with custom trxid proc for routing. It’s throwing an occasional error that I can’t explain.

The trxid proc returns the message type in MSH.9.1 and the sending system in MSH.3 separated by an underscore. So, for the following example, it would return ORM_PCM

MSH|^~&|PCM|C|80100|C|20120509000012||ORM^O01|24762592|P|2.2|||AL|NE

The error it’s returning is “No destination for message (105)” which is self-explanatory enough. But, it routes successfully when I run it through “routes” in the testing tool – AND, it routes fine when I resend it!

The offending message was the first through this interface after our nightly archive script ran.

Any idea what might be going on?

Running CL5.6 if it makes any difference.

Jeff Dinsmore
Chesapeake Regional Healthcare

Topic

[John Hamilton]

Without the script and message it is kind of hard to help.

What do you see in the error database ?

[Jeff Dinsmore]

I don’t think it’s a trxid script issue since the error isn’t repeatable with the same data, and it’s been in use in dozens of other interfaces for quite some time.

The trxid script:

Code:

proc trxid_hl7_system { msgId } {
# Retrieve the Message Type from the message
set msg [msgget $msgId]
set fs [string index $msg 3]
set sfs [string index $msg 4]

set fieldList [split $msg $fs]

set msgType [lindex [split [lindex $fieldList 8] $sfs] 0]
set sendingApp [lindex $fieldList 2]

return “$msgType_$sendingApp”
}

From error DB:

Quote:

msg: 0x0xb7dbd03c

   msgType           : DATA

   msgClass          : ENGINE

   msgState          : No destination for message (105)

   msgPriority       : 5120

   msgRecoveryDbState: 3

   msgFlags          : 0x8002

   msgMid            : [0.0.89125993]

   msgSrcMid         : midNULL

   msgSrcMidGroup    : midNULL

   msgOrigSrcThread  : ob_pool_to_cbord

   msgOrigDestThread : cbord_orm_ob

   msgSrcThread      : ob_pool_to_cbord

   msgDestThread     : cbord_orm_ob

   msgXlateThread    :

   msgSkipXlate      : 0

   msgSepChars       :

   msgNumRetries     : 0

   msgGroupId        : 0

   msgDriverControl  : {CONNID 24540}

   msgRecordFormat   :

   msgRoutes         :

   msgUserData       :

   msgStaticIsDirty  : 0

   msgVariableIsDirty: 0

   msgTimeStartIb    : 1336536020.175

   msgTimeStartOb    : 1336536020.174

   msgTimeCurQueStart: 0.000

   msgTimeTotalQue   : 0.001

   msgTimeRecovery   : 1336536020.783

   msgEoConfig       : 0x(nil)

   msgData (BO)      : 0x0xb7dbd120

   message           : ‘MSH|^~&|PCM|C|80100|C|20120509000012||ORM^O01|24762592|P|2.2|||AL|NEx0dPID|1’

Jeff Dinsmore
Chesapeake Regional Healthcare

[Ian Morris]

It looks like this message has the letter “O” instead of the number “0”.  I imagine the engine doesn’t know what to do with this:  ORM^O01

I think it should be like this instead:  ORM^001

Do you know what I mean?

Jeff W Dinsmore wrote:

I have an interface with custom trxid proc for routing. It’s throwing an occasional error that I can’t explain.

The trxid proc returns the message type in MSH.9.1 and the sending system in MSH.3 separated by an underscore. So, for the following example, it would return ORM_PCM

MSH|^~&|PCM|C|80100|C|20120509000012||ORM^O01|24762592|P|2.2|||AL|NE

The error it’s returning is “No destination for message (105)” which is self-explanatory enough. But, it routes successfully when I run it through “routes” in the testing tool – AND, it routes fine when I resend it!

The offending message was the first through this interface after our nightly archive script ran.

Any idea what might be going on?

Running CL5.6 if it makes any difference.

[Jeff Dinsmore]

The “O” in the “O01” trigger is as it should be and is expected.

As I mentioned in my original post, the message behaves properly when run through the testing tool and it works fine when it’s resent from SMAT.

So, it’s definitely not a problem with the message itself. If it were a message problem, it would be repeatable.

Thanks,

Jeff.

Jeff Dinsmore
Chesapeake Regional Healthcare

[John Hamilton]

Is there anything in the error Database ?

There should be.

I might also add some echo or puts in the script for debuging.

[Robert Kersemakers]

The message is in the error DB, as Jeff already showed here.

I just wonder what is in the error log: it should give you more information about what’s going on. Can you show us that as well?

And what is the route you have defined? For the message in the error-DB, you should have a route defined for ‘PCM_ORM’, as you said before.

I am now wondering about this part of the code:

Code:

return “$msgType_$sendingApp”

Shouldn’t that be something like

Code:

return “${msgType}_${sendingApp}”

?

I am not sure about the in the string.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Tom Rioux]

We do something similar here for our ADT’s.   We have our ADT’s split into routing groups such as “ADTA, ADTB, ADTC, ADTD”.   Our trxid’s that we route on would then be ADT_ADTA, ADT_ADTB, and so on.  

I agree with Robert that you may need to return your trxid differently.  We don’t use the quotes or the backslash.   We simply return something like this:

return ${msgType}_$msgGroup

Either way should work.  Try it and let us know how it turns out.

Tom

[Jeff Dinsmore]

The backslash just escapes the underscore so it’s not interpreted as part of the variable name. So, both are equivalent.

The error logs themselves have basically the same message as displayed in the error DB. But your suggestion to check the logs prompted me to look again.

I discovered that the message ID in the error DB and the one in the error log are different – 0.0.89125993 vs 0.0.89125996

Error log excerpt:

Quote:

lastDefSendSec= 1336535927

Timed send

[xlt :xlat:ERR /0:ob_to_cbord_xlate:05/09/2012 00:00:20] [0.0.89125996] No destination list on message!

lastDefSendSec= 1336536020

So, I did some more digging…

Here’s how this particular interface works:

When a diet order comes from our Horizon Clinical system (HCI), it’s sent on to our CBORD dietary system unless it’s a discontinue action with a future effective date – something like discontinuing a regular diet at midnight so we can start NPO in advance of some procedure.

CBORD doesn’t handle future discontinue orders properly – it discontinues immediately rather than at the future effective date/time. So, we drop these future messages into a DB and then send them at that future date/time.

We have a separate, timed UPOC protocol thread that reads the “mature” messages from this DB, creates messages with the content of the deferred messages and sends them on to CBORD. This part is working correctly.

There’s also the same resend code in the “run” section of the TCL proc for this interface. It reads from the deferred messages database and sends messages when they’re “ripe”.

The problem was that I was using the same msgcreate inside the “run” part of the proc as I was using for the “time” section and the resultant messages apparently did not have the routing metadata required. So, instead, I switched it to use msgcopy to create the resent messages and now, everything’s working as expected.

Thanks to all for your suggestions.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Author]

Replies