Unsupported Trixid (101)

Unsupported TrxId means that the value returned by whatever you have chosen to use in the Inbound>”Trxid determination Format” box is not covered by the routes defined unter the Route Messages tab.

This error can also happen if an outbound thread receives a message while it isn’t waiting for a reply, and the message doesn’t have a route defined on the “route replies” tab.

In the message that shows with the error you mentioned : see what is in

MSH:8 or MSH:9

and

compare it to your route to be translated on the route messages tab for the inbound thread.

I hope this helps

Mike

[/b]

I have taken over for Sarah, and I am now looking into this issue. It is for an outbound ADT interface to an ODBC connection. The interface is checked for Outbound Only, and does not await replies.

It is very intermittent. We will process over 1,000 ADTs a day, and many days we have no failures.

However, on occasion, there will be a message that errors out with the Unsupported TrxId error. The message is below (with some data anonymized).

msg: 0x3000003c

   msgType           : DATA

   msgClass          : ENGINE

   msgState          : Unsupported Trxid (101)

   msgPriority       : 8192

   msgRecoveryDbState: 3

   msgFlags          : 0x8002

   msgMid            : [0.0.194131649]

   msgSrcMid         : [0.0.194131483]

   msgSrcMidGroup    : midNULL

   msgOrigSrcThread  : f_cern_a

   msgOrigDestThread : t_cdi_a

   msgSrcThread      : f_cern_a

   msgDestThread     : t_cdi_a

   msgXlateThread    :

   msgSkipXlate      : 0

   msgSepChars       :

   msgNumRetries     : 0

   msgGroupId        : 0

   msgDriverControl  :

   msgRecordFormat   :

   msgRoutes         :

   msgUserData       :

   msgStaticIsDirty  : 0

   msgVariableIsDirty: 0

   msgTimeStartIb    : 1361300091.830

   msgTimeStartOb    : 1361300091.937

   msgTimeCurQueStart: 0.000

   msgTimeTotalQue   : 0.040

   msgTimeRecovery   : 1361300092.877

   msgEoConfig       : 0x0

   msgData (BO)      : 0x30000120

   message           : ‘MSH|^~&|||||||ODB||P|2.2x0dXDB|A04||400720982|001090589|FIRST|LAST|1900-01-01|ATC|R|999-99-9999|2013-02-19||28|||C|FIRST|LASTx0d’

I have checked it against successful A04 messages, and they look identical to me. Any assistance would be appreciated.

Would this happen on days when maybe something is being resent from the SMAT tool?

Thanks,

Jerry

Sometimes the TrxId (101) can be misleading.  I would do an hcidbdump -e -c    (for context) to see what the real error is and check the process log/error log.  Sometimes a translation error gets misreported as a 101.

Hope this helps.

Jim Cobane

Henry Ford Health

The message that you included has ‘A04’ in MSH-9. This should be ‘ADT^A04’, so this is most probably the reason why you get the Unsupported TrxID error. You probably have ‘ADT_A04’ configured as one of your routes.

Find out where this ‘A04’ is coming from and correct it so ‘ADT^A04’ is send in MSH-9.

Are your other A04-messages also sent with ‘A04’ in MSH-9?

Actually the MSH-9 contains ODB (I don’t know of any valid HL/7 Message Type or Event of ODB).

Moreover the first segment is an XDB (again not a valid HL/7 segment as far as I know) and it is that segment that contains the A04 reference:

‘MSH|^~&|||||||ODB||P|2.2x0dXDB|A04||400720982|001090589|FIRST|LAST|1900-01-01|ATC|R|999-99-9999|2013-02-19||28|||C|FIRST|LASTx0d’

Looks to me like a bogus message.

Oops: you’re right Jim, I was too quick and in full ADT-mode.

So there is no route defined for ‘A04’. Or the ‘Trx id determination Format’ is wrong…

From the looks of it, definitely looks like a custom deal (message type).  I would make sure that the HL7 variant inbound has an ODB message type defined, with XDB segment, and that you have a route defined for the ODB message.  If you are trying to route based off ata in the XDB custom segment, you need to make sure you have a trxid proc, and that a route is defined for what that proc returns.

Hope this helps,

Thanks to all of you for the prompt and thorough replies. I will look into each of your suggestions in an effort to track down the root cause. This is a custom interface that uses a odbc tcl proc to insert the message into the database. I was not present when this interface was created, nor do I have familiarity with the ODBC proc.

That being said, there were a number of A08 and A04 messages that errored out with the Unsupported Trxid. However, there were 306 A04 and 781 A08 messages that were successfully transmitted yesterday, which makes me question whether or not this is actually a routing TrxID issue.

Comparing the successful A04 messages to the ones that error out produces no discernible difference in their structure, which makes it even more curious.

Quick update: Running the hcidbdump -e command with the -c flag indicates that it is an xlate error. I will do more thorough investigation of the source message and the output, looking for discrepancies that might identify where the xlate is erroring out.

I had never used the -c flag before. Big hat tip for the recommendation!

We continue to have intermittent messages showing up in the error database. It is less than 0.1% of the messages that are sent, and all of them indicate xlate errors with the hcidbdump -e -c command.

The ones that are currently in the database are dated from 4/23-4/25, and I believe that I did resend quite a few ADTs on that date, which Jerry had asked.

The other thing is that this thread does not await replies, and it may be receiving error replies from the database.

An interesting aside is that the inbound message is a standard ADT^A04, and the outbound message is the XDB, but the XDB shows up in the error DB.

Greetings,

For all inbound threads we usually create a static route after all the legitimate routes of message types that we expect whose detail

is “generate” with a proc available from INFOR (Cloverleaf)

“hcitpsmsgkill”.  This traps the garbage coming in and sends it

to the bit bucket.  Unless of course you want to see what is sent

for debugging purposes.

Alternatively, you can create a static route to a thread and add

your own message kill Tcl procedure in a Raw detail.

Hope this helps.

I usually include a “bitbucket” thread in my processes, and put in a static route to the bitbucket (/dev/null).  The model that we use is to pickup the messages we are interested in and the others then have a route that they can flow to.

It also helps in troubleshooting in that you can quickly turn on a SMAT to see what is being dumped in the river…

You might want to conisder a TrxID proc and routing those that aren’t defnied via a CATCH_ALL route to a file thread so you can inspect the garbage to see if any of it is valid or valuable.  We did this with a new ADT interface with Epic.  We put an alert on the file such that if it changes in size it fires off.  So far nothing, but you never know.

The problem seems to be that these messages aren’t garbage, they are good xlated messages that are not inserted into the database for some reason. If I save the messages from the error DB and resend them to the outbound thread, they process and post successfully.

I’ll just have to keep doing this workaround until we upgrade, I suppose. I’ve appreciated the various viewpoints related to this issue, as it helps me to see different angles from which to approach.

This reminded me of an issue I have dealt with before where you are sending what appears to be a valid transaction and getting a invalid Trxid response. Since this is sending to a database I wonder if at that moment the record it is trying to access is currently locked and unable to process the transaction at that time and inadvertantly giving the wrong response “Invalid Trxid”. Perhaps there could be a way to work around this error.