HL7 Messages Posted to a Webservice

[Mike Shoemaker]

We have an interface to a custom built patient/bed tracking application.  The interface uses the HTTP TCL package to POST HL7 messages to a webservice running IIS.  I am using an Outbound TPS proc to post the HL7 messages.  It “kinda” works as long as the receiving webservice is up and running.  When it goes down, the messages write out to the error database and are lost until they are resent.  With a tcp/ip socket connection however, when the remote host is unreachable, the connecting cloverleaf thread goes into ‘opening’ status and when messages start pending, the thread turns red.  Once the remote system comes back online, the thread connects and the messages flow as expected.  Is there any way that this can happen for an HTTP post type of delivery?  Since each time a message is posted to a url, you connect, post and then disconnect, how can the availability of a remote host be determined and when its not available, hold the messages until the host is available? I do not want an “error” to happen when the remote host is down, i simply want to hold the messages in queue until the remote side is available as is currently happening with a dedicated socket connection.

Thanks

Mike

Topic

[Pete Gilbert]

What kind of return code are you getting from the service? We have seen instances where the remote web server is up, but the web service is not. The return code will be in the 4xx or 5xx range and will give you some hint as to what the trouble was on the far side.

[Mike Shoemaker]

Pete Gilbert wrote:

What kind of return code are you getting from the service? We have seen instances where the remote web server is up, but the web service is not. The return code will be in the 4xx or 5xx range and will give you some hint as to what the trouble was on the far side.

I receive a timeout when the server is down, but the thread pointing to the webserver always shows as “UP” therefore messages do not queue up. What I would want the thread to do is go into an ‘OPENING’ status and have the messages queue until the webserver comes back online. However, with a web posting, as far as i can tell, there isn’t any type of persistent “connection”.  I’m trying to avoid a loop checking the server response.

[Pete Gilbert]

I ended up coding this using curl (because the httpquery package wouldn’t allow me to configure the http headers properly). We are actually sending an HL7 2.x message in a SOAP wrapper. I ended up handling the errors like this:

if {[catch {curl::transfer -url $url

               -post 1

               -httpheader $httpHeader

               -postfields $soapEnv

               -httpauth basic

               -userpwd $useridpw

               -verbose 0

               -sslverifypeer 0

               -infohttpcode httpcode

-errorbuffer error

               -bodyvar httpResponse } ]} {

echo “***ERROR from tclcurl sending to REMOTE. Error is ” $error

sleep 30

return “{ERROR $mh}”

}

#

# a returncode of 200 is success.

#

       if {$httpcode == 200} {

               echo “Message was successfully sent to REMOTE”

       } else {

             echo “*** Error sending to REMOTE”

             echo $httpcode          

             echo $httpResponse

   echo “Original Message from LAB:”

   echo $msg

   echo “Soap Envelope that was sent to REMOTE:”

   echo $soapEnv

   sleep 30

   return “{ERROR $mh}”

       }

               

          return “{CONTINUE $mh}”      

}

Note that because I am doing this in a UPOC, returning ERROR actually puts the message into the recovery database and it will try to resend. I am told that this is a feature 🙂 So, if there is an error (like the remote server is down, or it thinks the message is invalid), we queue up and keep on trying. This will cause the thread to back up, and our operators will notice and we will start troubleshooting.

[Robert Gordon]

You might want to reconsider using the unix/aix command “sleep“.  Alice and me found that sleep can run outside of the tcl on the system and cause detection problems on the engine.  Problems are related to inbound connections where the command “sleep” put a whole site to sleep and so vendors where sending multiple messages due to a lack of ack.  This might not be the instance in later versions of the Quovadx product as we are using 3.8.1P at the moment, but it is better to be safe then sorry.

[Pete Gilbert]

sleeping seemed preferable to having the engine try to reconnect 20 times a second 🙂 We put this thread into its very own process, because I didn’t want it to break anything else.

And the process works. The remote service was unavailable earlier this morning (404 error), and when it came back up, it started rejecting every message that we sent to it (500 error). So, we queued things up..the thread is showing RED in Global Monitor with 125 messages in the queue. Our operators notified us and I sent a note off to the vendor’s tech support.

We tested for this kind of failure. This is our first https interface, and since we had to write the code ourselves, I wanted to make sure that it failed gracefully. It’s nice to see it actually do so.

[Author]

Replies