CSC Filtering Beyond TRXID

  • Creator
  • #50814

    I would like to filter messages based upon the content in the HL7 message, like when the provider ID in PV1 7 is null, Block the message?

    I see there is an option to create two Regular Expression filter but I see no examples to use.

    Is it possible to use these filters in the manner outlined above?

Viewing 9 reply threads
  • Author
    • #67650

      Yes, it is possible and there are a couple or more ways to do it.

      You use the trxId procs for creating the routing logic. If you want to route messages based on the content of the message to different downstream threads, you use trxId procs. However, if you want to filter, suppress, or kill messages based on the content in the messages, then you can either use tps procs somewhere in the thread (like in the xlate pre-proc section) or create a SUPPRESS statement in your xlate.

      I’ll add an example filtering tps proc in a minute.

      -- Max Drown (Infor)

    • #67651

      Here is a tps proc that filters on exam date (SCH.11.04). Note that hl7Get is another proc that does HL7 parsing for us.


      proc tps_filter_examDate { args } {

         package require extexpfilter
         keylget args MODE mode

         switch -exact — $mode {
             start {
                 # Do nothing.

             run {
                 set debug 0
                 keylget args MSGID mh
                 set msg [msgget $mh]
                 set dispList “{CONTINUE $mh}”
                 set sch_11 “”
                 set examDate “”
                 set msh_10 [hl7get $msg MSH 9]
                 set sch_11_04 [hl7get $msg SCH 11 3]
                 regexp {(d{8})d{4}} $sch_11_04 match examDate
                 set now [clock scan now]
      set now “1240894800”    ;# “1240894800” is the result of [clock scan 20090428]. Remove this line at go-live.
                 set examDate [clock scan $examDate]

                 if {[expr $examDate < $now]} {
                     set dispList "{KILL $mh}"
                     if {$debug} {puts "Message $msh_10 KILLED. Exam Date [clock format $examDate -format %Y%m%d] is < now [clock format $now -format %Y

                 return $dispList

             shutdown {
                 # Do nothing.

             default {
                 # Do nothing.

      By putting the proc in the xlate pre-proc field, it kills any message that meets a certain criteria before the message is passed to the xlate.

      -- Max Drown (Infor)

    • #67652

      Here is hl7get.tcl


      proc hl7get {args} {

        set MyMsg [lindex $args 0]                                         ;# 1st argument is the message
        set MySeg [lindex $args 1]                                         ;# 2nd argument is the segment
        set MyFld [lindex $args 2]                                         ;# 3rd argument is the field
        set MySubFld [lindex $args 3]                                      ;# 4th argument is the sub-field

        set FldSep [string index $MyMsg 3]                                 ;# get the field seperator
        set SubSep [string index $MyMsg 4]                                 ;# get the sub-field seperator

        set RetVal “”                                                      ;# Initialize the return value to NULL
        set LenSubFld [string length $MySubFld]                            ;# See if the user spcified a sub-field

        set SplitMsg [split $MyMsg r]                                     ;# Split the message into a list of segments
        set TheSegment [lindex $SplitMsg [lsearch $SplitMsg $MySeg*] ]     ;# Extract the segment we want
        set SplitSegment [split $TheSegment $FldSep]                       ;# Split the segment into a list of fields
        set TheField [lindex $SplitSegment $MyFld]                         ;# Get the field number we’re looking for

        if { $LenSubFld > 0 } {                                            ;# If the user specified a sub-field
           set SplitField [split $TheField $SubSep]                        ;# split the field and return the sub-field
           set RetVal [lindex $SplitField $MySubFld]                       ;# otherwise return the whole field
        } else {
           set RetVal $TheField

        return $RetVal                                                     ;# Return the value of the field


      -- Max Drown (Infor)

    • #67653

      Thanks for the reply Max, but what I wasz looking to do is to block the message at the CSC on tyhe client site before it gets to the engine so I can minimize the amount of remote data sent to the engine. With the CSC client I have the ability to restict messages from being sent based upon a list of TRXID’s but I would like to go a level deeper and evaluate the message and block it before it gets to the server.

      I know I can filter on the Cloverleaf server but I would really like to stop it at the client site instead of sending to the server and then having to kill the message at that point.

    • #67654
      Charlie Bursell

      Possible error here Max. You are dong a glob search with the statement

      set TheSegment [lindex $SplitMsg [lsearch $SplitMsg $MySeg*] ]

      It will look for the letters anywhere within a list element.  You may not get what you asked for  😉

      Much safer would be:

      set TheSegment [lindex $SplitMsg [lsearch -regexp $SplitMsg “^$MySeg”] ]

      Now you are anchoring the letters to the start of the list element.

    • #67655

      Charlie Bursell wrote:

      Possible error here Max. You are dong a glob search with the statement

      set TheSegment [lindex $SplitMsg [lsearch $SplitMsg $MySeg*] ]

      It will look for the letters anywhere within a list element.

      -- Max Drown (Infor)

    • #67656
      Scott Folley

      Greg, I attempted this in CSC 4.0 and did not have a great deal of luck with it.  What you refer to is very appealing though because the ability of CSC to ignore/trash messages before they become “internet traffic” does have strong potential to save bandwidth.

      If you have figured it out, please enlighten me.  If you have not then I am in the process of upgrading to CSC 4.2 and I am going to see if I have better luck with it there.

      The one caveat that I would say to any discussion of message filtering on CSC either by HL7 transaction type or by regular expression brings with it many potential issues because the sending system will definitely have sent it and there is very little indication that you ever received it in any way.  If the regular expression filter were even remotely too greedy you could be throwing out messages that you really wanted.

    • #67657


      Thanks for the reply. We have not gone any farther with this. We are in the process of upgrading to 4.3 to take advantage of the better throughput and Global Monitor connection. We still need to determine if there might be a way to accomplish this in the future.

      To your point about the audit trail, we are hoping that the inbound log which denotes what messages are passed and which are blocked will give us the audit of all messages received and their disposition.

      I will let you know if we figure anything out.

    • #67658
      Scott Folley

      We just installed CSC 4.3 since that is the version that was sent to us.  My first impression is WOW.  I have to admit that many of the things that just did not work properly in CSC 4.0 are working extremely well.  I will belabor that review more in a different post.

      As for the regular expression filtering, I will be giving that a shot tomorrow and I will let you know how that turns out.

    • #67659
      Scott Folley

      I guess tomorrow turned into 6 months or so.

Viewing 9 reply threads
  • The forum ‘Cloverleaf Secure Courier’ is closed to new topics and replies.

Forum Statistics

Registered Users
Topic Tags