- This topic has 10 replies, 4 voices, and was last updated 14 years, 4 months ago by
.
-
Topic
-
-
Replies
-
-
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)
-
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.
Code:proc tps_filter_examDate { args } {
package require extexpfilter
keylget args MODE modeswitch -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)
-
Here is hl7get.tcl
Code: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-fieldset FldSep [string index $MyMsg 3] ;# get the field seperator
set SubSep [string index $MyMsg 4] ;# get the sub-field seperatorset RetVal “” ;# Initialize the return value to NULL
set LenSubFld [string length $MySubFld] ;# See if the user spcified a sub-fieldset 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 forif { $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)
-
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.
-
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.
-
-
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.
-
Scott,
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.
-
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.
-
-
- The forum ‘Cloverleaf Secure Courier’ is closed to new topics and replies.
