Trx ID TPS Error

[Krishna Kumar]

I am trying to write a simple TPS that can be used as a UPOC.

This process is supposed to read MSH-3 value from messages and then based on this I am setting a TrxID  for the messages in the TPS. Then messages use TrxID to select the proper translate since I am using more than one translate in this thread.

For example if MSH -3 has value

Topic

[Bob Richardson]

Greetings,

The tester tool cannot handle testing Trxid procs.   You need to do this in a running engine (process).  The testing tool expects you to return a message disposition and message handle.

Also:  suggest using set command instead of append as memory may not be cleared with subsequent messages and your “appended” variable will just keep growing (and thus be invalid).

Add to your route lines a generic “bit bucket” where anything not expected can be deleted (a static route or default Trxid of _DEL_ ).

Good luck.

[Keith McLeod]

Can you route based on Trx id determination Format –> Field Routing –> Select HL7, your variant and field to route by and set it to MSH:3?

This is on the inbound tab.  Create Routes for the values contained in MSH:3. like OPTIFLEX, SOFTLAB or MUSE….

I have done something like this to make use of a multiserver thread to handle different source labs….  I have not put it into production but experimented with it since a project request came up asking for me to route potentially from many different labs to a single destination.  This allowed me to separate code based on the individual lab.

Let me know if this looks like something that might work for you?

[Krishna Kumar]

Hello Keith,

I already knew that approach, but I am tring to ccomplish that using a UPOC.

Thanks

-Krishna

[Jim Kosloskey]

Why? Do you just want the practice?

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

[Krishna Kumar]

Yes

[Jeff Dinsmore]

Here’s mine.

It returns _ – something like ORU_XYZLAB

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”
}

Jeff Dinsmore
Chesapeake Regional Healthcare

[Peter Heggie]

possibly you need to insert this line of code:

set segList [split $msg r]

So instead of this:

set segList [msgget $mh]

Try this:

set msg [msgget $mh]

set segList [split $msg r]

Peter

Peter Heggie

[Jon Melin]

Kevin,

I know this is an older thread but you had an interesting suggestion that might be helpful in something I am trying to do. I want to allow only A31 messages with a certain word to go down one route, and be blocked on all the other routes. Right now I am just routing by what kind of ADT it is and filtering the word in MSH13 by a pre-proc (to block to all systems), but since I have a new system coming online that wants these specific A31 messages and the other systems don’t, this sounds like a good way to split it up. The tricky part is some A31 messages don’t have this word in MSH13, and the downstream systems WANT these ones, just not when the word is there, except for this 1 new system.

I understand how to create the field route and select the field you want to look at but where do I the “word” I want to either filter by, or allow through? I was looking through the help document (Help >> Configuration >> Network Configurator >> Tabs >> Inbound Tab) and it doesn’t list how to do the actual filter. I’ve went through and tried to setup a route using what I’ve created but I couldn’t seem to find it.

Attached is a screenshot of what I’ve created. I am running version 6.0

Thank you,

Jon

[Jim Kosloskey]

Jon,

Cloverleaf does not yet possess a configurable way to filter messages based on data content (something that has been asked for since – forever?).

You will need to use a Tcl proc or use the Xlate itself to filter.

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

[Jon Melin]

Jim,

Thanks for the response. That’s what I was thinking I was going to have to do. What does this feature I was mentioning accomplish then?

Thank you,

Jon

[Jim Kosloskey]

Jon,

It allows you to specify a TrxID be built from data elements of a definable message. Of course you then need routes which will match the result.

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

[Terry Kellum]

You can use a roundabout way to kill messages based on a TrxID.  You create an outbound thread that is saved to the file /dev/null. You then use the TrxID that identifies unwanted records and you raw route it to the detail of your “bitbucket”.

I also use a “bitbucket” when I know that there will be messages that I don’t want to go anywhere.  This has the effect of keeping messages from erroring on their way to nothingness….

[Max Drown (Infor)]

Your trxid script looks good. I tested it here locally and it worked as expected. I made a few small changes below. You can only return one string from this proc, not a list. This one string must match a route name or Cloverleaf will return an “Unknown TrxId error”.

You can test trxid procs with the testing tool by using the Routes tab. You must first add the trxid to an inbound thread and setup your routes. In the testing tools, select hciroutetestshowbydest for the Send to Proc. The output will show you how the messages will be routed.

The best practice method for killing unwanted messages is by using a raw route with a label like “DISCARD” or whatever (if using a trxid UPoC), selecting the *source thread* as the destination, and selecting hcitpsmsgkill as the pre-proc. This will cleanly kill messages without adding any additional overhead and without using up another thread.

proc trxid_test { mh {args {}} } {
[code]proc trxid_test { mh {args {}} } {

-- Max Drown (Infor)

[Author]

Replies