HTTP Interface Configuration Help

[Michael Sierra]

Hi All,

I am currently creating a VXU interface to CHIRP (Indiana State Vaccination Registry) using the HTTP-CLIENT protocol and I was wondering if someone can help me who may have a similar setup.

Given our current settings (see HTTP Properties attachment) it appears we are able to connect to CHIRP but they are sending an ACK with the error: USERID webservice parameter not found.

According to my contact at CHIRP they see the message but they do not see the USERID or PASSWORD headers and that is why they are rejecting the message. I know the user id and password are correct because I can test this through the website they want us to connect to, https://phchub.isdh.in.gov/phchub/HL7Server. Besides we have a separate connection with CHIRP that we connect directly from our EPIC EMS and do not have any issues.

I believe the issue is with my configuration. I have tried adding the userid and password in the headers section and using the “Authorization” option but I get the same error no matter how I set this up. I added a copy of one of the logs. Note that I removed the actual username and passwords from these documents.

 

Attachments:

You must be logged in to view attached files.

Topic

[Jim Kosloskey]

I did not see your log. However, if you set the cURL Option for VERBOSE (cURL Options Tab) you will get more detail during the connection attempt and perhaps you can see more.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Michael Sierra]

Thanks Jim, I have that option setup already but it looks like clovertech blocked that file. Let me try uploading it again.

Attachments:

You must be logged in to view attached files.

[Ab Lugtenburg]

Is it possible that you put the userid and password in the fields by authorisation ? Then remove your settings for userid and password in the headers

[Robert Kersemakers]

I’m a total noob with http, but we got this working with an Authorization header. Our ‘Headers’ looks like this:

{Content-Type “text/xml; charset=utf-8”} {User-Agent “CIS”} {Authorization “Basic cGlhcHBsdxxxxxxxxxxxxxxxMwMQ==”}

Here a snippet from wiki on how to construct the credentials:

For example, if the browser uses <tt>Aladdin</tt> as the username and <tt>OpenSesame</tt> as the password, then the field’s value is the base64-encoding of <tt>Aladdin:OpenSesame</tt>, or <tt>QWxhZGRpbjpPcGVuU2VzYW1l</tt>. Then the <tt>Authorization</tt> header will appear as:<code>
Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l
</code>

If I remember correctly using the ‘Authorization’ option in the http-protocol worked as well, but had some weird side-effects.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Dawn Magsam]

We are also looking at sending to CHIRP via our Cloverleaf engine (we currently send directly from the EMR.)  I am following this thread for any information that may be of assistance to us in getting this set up.

[Michael Sierra]

We weren’t able to do this using the HTTP-CLIENT  protocol. I still never figured out was wrong with our set up. We use similar set ups with other systems that work fine but CHIRP just wouldn’t accept the message.

We ended up creating a route to a file thread pointed to dev/null. In the route we created a post proc script. In this script is where we connect to CHIRP and send the message.

Keep in mind CHIRP acknowledges everything with an error so you may need to write code to handle those as well. Here is an example of an acknowledgment of a good message.

 

MSA|AE|64|
ERR|||0^Message accepted^HL70357|I||||Patient ***** “*****” with 1 vaccination accepted into vaccination staging table|

[Tipu Razaq]

Can you try adding the colon symbol between the key-value pairs in each of your headers? If Cloverleaf uses cURL in the background to make these calls, then I suspect this may be the issue.

I’ve tried running cURL from the command line before and although cURL didn’t throw an error, it wouldn’t acknowledge headers without the colon symbol resulting the headers not being sent with the call.

[Author]

Replies