Filtering messages

Ariba.

We do a fair bit of this kind of thing and our method may not be applicable to you!

We set the inbound thread routing to FRL and a ‘proc’ and use TCL code to return a route type and go from there.

In the example below (used in a ‘timing’ site and not production), we will be receiving multiple hospital ADT messages on a thread and wish to route them based on information (hospital code) in the MSH segment.

When we use this routing code in production, we ensure that the code returns a ‘bad’ route for any error and route this to a SMAT file, so we can produce a report.

proc tim_code_trx {aMsgId} {

               #

               # grab the first part of the message, containing the MSH

               #

       set myMsh [csubstr [msgget $aMsgId] 0 60]

       set myFS [csubstr $myMsh 3 1]

               #

               # split the segment into the fields and return the third field

               # should be PJ@

               #

       set myTrxId [lindex [split $myMsh $myFS] 2 ]

       return “$myTrxId”

}

This is a Unit Test script for routing code and may make testing easier.

#!/usr/bin/ksh

# this line to escape the next line from the tcl interpreter

exec hcitcl “$0” “$@”

global HciConnName

set HciConnName gen_smat_ai_gen_rcv

proc msgget {aId {aAction NONE}} {

       global gMsg

       if {$aAction == “S”} {

               set gMsg $aId

               return

       }

       return $gMsg

}

set myMsg {MSH|^~&|HL7LAB||CLOVERLEAF|qdxi01p|200510131611||ORU^R01|4139137|D|2.1|||||^MPID|||A9994292||A^A||19850108|M|||A^^F|||||||||||^MPV1||O|INFD||||||||||||||||$myAcct||||||||||||||||||||||||||

|||||^MOBR|1||11|MSYPH^SYPHILUS^L||200510181408|200510181359|||||||200510181408||034020CW^M&L|||$myReq@OBR19|FTH^|112703C|200510131611||$myPerf@OBR24|F|||||||||||^MOBX|1|FT|Y29JSY^^L|| TEST RESULTS|||

|||F|||||^M}

foreach myAcct {FH@123456789012 F123 AA@123456789012 {} } {

       foreach myReq {FH AA XX X {}} {

               foreach myPerf {FH AA XX X {}} {

                       echo “Acct >$myAcct<"                        echo “Req  >$myReq<"                        echo “Perf >$myPerf<"                        msgget “[subst -nobackslashes -nocommands $myMsg]” S                        echo “tReturn [ris_code_trx_id 1]”                }        } } exit

Ariba – alternatively, you could use the kill_msg proc on the appropriate route of your inbound thread(s).  The arguments to include the patient type would be something like  {PASSCOND pttype} {SEGNAME FT1} {FIELDNUM 18} {SUBFIELDNUM 0}.  To exclude the patient type in your filter (i.e. let every message but that patient type through), you just use a tilde (~) in your PASSCOND argument:  {PASSCOND ~pttype} {SEGNAME FT1} {FIELDNUM 18} {SUBFIELDNUM 0}.

I just noticed that for my applications, the location of the patient type is not consistent.  My pharmacy charge messages provide the patient type in the FT1 segment, but not in the PV1 segment.  My lab charge messages provide the patient type in the PV1 segment, but not the FT1.  I hope your messages are a bit more consistent, to make this task less complicated…

You’ll need to type the exact code for your outreach patient type, as found in the HL7 charge message in either FT1.18 or in PV1.18.  The patient type is found in either place, and both are optional, meaning the message doesn’t have to contain that information – unless you have an HL7 variant requiring that field to be populated.  At my site, for example, ER patients have the code “ER”, which is the patient type, in FT1.18 for some charges, and that same information is found in the PV1.18 segment of the charge message from other applications.  Hopefully, all your DFT (charge) messages will contain the patient type code in the same place consistently.

If that’s true, then here’s how you can route your messages to the desired outbound thread:

In the GUI, go into thread configuration.  Right click on your inbound thread, and select thread properties.  Click on the route messages tab.  Highlight the route to the OB thread that will get all but the outreach patient type charges, and click on properties, which will bring up a raw route details dialog window.  (My routes are almost all “raw” routes…)  For the “Procs:” field, hit the Edit button, click ADD, and select the kill_msg proc from the drop down menu.  Type your arguments in the arguments window, using ~pttype in the PASSCOND argument.  Remember that you have to use the actual code, so what you type will look something like this, if ORPT is your code for outreach patient type:

{PASSCOND ~ORPT} {SEGNAME FT1} {FIELDNUM 18} {SUBFIELDNUM 0}.

Repeat all of the above steps to route charge messages to the OB thread for outreach patient type, except don’t use the ~ in your PASSCOND argument.  (And, remember that you’ll be adding the kill_msg proc to a different route – the one going to the appropriate OB thread).

Clear as mud?  It’s really very simple – the kill_msg proc can be very versatile…

hcitpsmsgkill as a proc will kill ALL messages, so it’s no wonder that a) no messages are going out, and b) therefore, there’ll be nothing in your error database.  That’s definitely not the same as kill_msg…    

The proc you want is kill_msg – and it should be there.  Let me know if it’s not, and I’ll send it to you.

Feel free to email me directly…