Web Call from TPS

[Robert Milfajt]

Background:  I need to call a web service from Cloverleaf to translate a physician ID in a message from the source system ID to the destination system ID.  Neither source, nor destination have the capabillity to perform a mapping, but we have a third system with all of the MD mappings, and a web service to call to obtain the information.

Plan:  I plan to use a proc in the sms_ob_data TPS.  This proc will use TclCurl to query the web service based on value in message and replace it with the returned value.  Things work well if the web service is available, and turn around times are excellent.

Question:  I am not sure how to program a failed web service call.  My plan was to either PROTO or OVER the message, not sure which, and stop the thread, not sure how.

Does my plan seem feasible?  Should I OVER or PROTO the message?  What is the best way to stop a thread from the sms_ob_data TPS?

Thanks,

Bob

Robert Milfajt
Northwestern Medicine
Chicago, IL

Topic

[Rob Abbott]

Bob – if you are going to stop the thread, you should probably not return the message at all if the WS call fails.

e.g. in your tps have a global stopping initialized to 0

If you encounter an error, set stopping to 1, exec the thread stop, and return “”

At the top of your run mode you have this

if { $stopping } { return ‘” }

To stop a thread from TPS, you can

Code:

exec $env(HCIROOT)/bin/hcicmd -p -c ‘ pstop’ &

When the thread is restarted anything that failed will still be in pre-TPS and will reprocess.

Hope this makes sense.

Rob Abbott
Cloverleaf Emeritus

[Robert Milfajt]

Excellent!  I did not even think to return “”.  It works great.  I was going along  much more difficult UPOC tangent after I had no success with PROTO and OVER!

Thanks,

Bob   8)

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Darren Tomlinson]

Robert,

what you described is exactly what i am attempting to do right now.  we have an in-house SQL database which is keeping linked Doctor Numbers.  I need to have the ability to look up another facility’s doctor number based on the one i have in an HL7 message and translate to the new number on the fly.  The designer of the Doctor EID program wants me to use a Web Service to pass in and get out my desired information.  I am very unfamiliar with this process.  Can you please shed some light on the scripts that you put in place to get this to work?  Any help will be much appreciated.

Darren Tomlinson

[Robert Milfajt]

This is the meat of it, the web service call, which is called from sms_ob_data.  I use this web call for seven fields within the message, so it became its own TCL proc.  At the end, I check for the RETARGS.ERROR item in the return list, and if it is true, I print an error to the log, return “”, else I CONTINUE the message.  I will provide a snippet of that code too.

Here’s the code that makes the web call.

Code:

######################################################################
# Name:         md_ext_id_lkup
# Purpose:              This proc will call Epic web service with some
#               external provider ID and prefix of second external
#               system, and return any matching providers IDs for
#               the second system.
# UPoC type:    other
# Args:         ARGS – user supplied arguments
#                       ID – Provider ID for an external system
#                       PREFIX – Prefix for external system
# Returns:              RETARGS —
#                       IDLIST – List of provider IDs found
#                       ERROR – 0 if error in lookup, else non-zero int.
# Notes:        
#

proc md_ext_id_lkup { args } {
       package require TclCurl
       keylget args ARGS.ID lkpId
       keylget args ARGS.PREFIX lkpPre
       set retList {}
       set url “http://nmffcharttest/mychartdev/webservice/webservice.asp”
       set pairs {}
       set name “epicRequest”
       set value ”

 test3
 
 
   
    $lkpId
    $lkpPre
   
 
 
”

       lappend pairs “[curl::escape $name]=[curl::escape $value]”
       set data [join $pairs &]
       set curlHandle [curl::init]
       $curlHandle configure -url $url -bodyvar httpBody -post 1 -postfields $data
       catch { $curlHandle perform } curlErrorNumber
       set IdList {}
       if { $curlErrorNumber == 0 } {
               set rExp {(.*?)}
               set rExpList [regexp -inline -all — $rExp $httpBody]
               for {set x 1; set i 0} {$i<[regexp -all — $rExp $httpBody]} {incr i; incr x 2} {
                       set Id [lindex $rExpList $x]
                       lappend IdList $Id
               }
       }
       $curlHandle cleanup
       lappend retList "RETARGS" [list "IDLIST [list $IdList]" "ERROR [list $curlErrorNumber]"]
       return [list $retList]
}

Here’s the code that checks for the error.  The stop_thread TCL call is another proc which executes the hcicmd command Rob specified earlier, however, we do reuse it in other places, so it became its own TCL proc.

Code:

             if {$iserr == 0} {
                 msgset $mh [join $newsegs r]
                 lappend dispList “CONTINUE $mh”
             } else {
                 set module [lindex [info level 0] 0]
                 package require TclCurl
                 set curlErr [curl::easystrerror $iserr]
                 set errmsg “$module/$HciConnName: WEB SERVICE ERROR: $curlErr.”
                 echo
                 echo $errmsg
                 set stopping 1
                 stop_thread $HciConnName
                 set dispList “”
             }

Here’s the code that gets the value TCLCurl return code to use for checking for an error.  This stops the routine from checking the next MD field and is used at the end (see above) for the return value of the proc.

Code:

   set lkup [md_ext_id_lkup $myargs]
   keylget lkup RETARGS.ERROR iserr

And finally, the line in the begginning the routine to stop the next message from processing until the thread stops.  Remember to make stopping a global variable.

Code:

             if { $stopping } { return “” }

Hope this helps,

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Author]

Replies