LLP Listener will not connect to remote host…
Trying to configure LLP Listener to an IP address on our network and can not get a connected message on my HL7 server or getting any inbound messages. I have verified IP addresses and port is correct (Port 8000). If I telnet to the hl7 server on port 8000, I generate a connected message on the server logs, so its not a connection issue.
Settings in Iguana-
Channel Type – LLP to Channel
Source – LLP Listener
Encoding – Unicode (UTF-8)
LLP Delimiters – Normal LLP
Enable port sharing – Yes – connections are limited to the hosts below
Remote host – 10.66.36.244
Connection timout – Yes after 1 minute of inactivity
IPv6 support – No
Ack – Fast
Use SSL – No
I have tried playing with Ack settings and using the legacy VMD autoAck but that has not worked either.
I feel like I am missing something obvious here… Anyone know what I am doing wrong?
Which direction is the data flowing? Are you attempting to send messages from the remote system into Iguana?
If yes, then the remote system should actually be an LLP Client, and would be responsible for initiating the connection to Iguana (which you’ve correctly configured as an LLP Listener). I’m suspecting that the remote system may actually be configured as an LLP Server, though, and needs to be reconfigured to connect as a client.
If that’s the only system connecting on the port you’ve configured, you don’t need to specify any IP addresses on the Iguana side; they’re only needed when you have multiple external systems connecting as clients to the same Iguana port.
I am looking to get messages SENT to Iguana which I then want to filter out some things and then put the remaining information into an access DB.
The sending system is a Philips Intellivue patient monitoring database server and I have attached a section of their HL7 programming specifications guide detailing the type of connection I am trying to build.
I believe I need to use the active_llp_producer_plugin, which i was playing with earlier today and I couldn’t quite figure out how to configure the parameters as that particular tutorial were written without examples and that makes understanding it more difficult.
Attachments:You must be logged in to view attached files.
That documentation doesn’t supply a lot of detail, does it? 🙂
But from what I can tell, it looks like you’ve run across one of those rare LLP situations where the remote system wants to be both the server (listener) and sender of the data, which isn’t the usual situation with HL7 LLP. You may be able to code this functionality in a channel with a translator as the source, using the net.tcp methods. Not an optimal solution, unfortunately. Is there any other option for message delivery from this application?
I have an entire guide from them that I could send you, but in short, no there is not much flexibility.
In fact, here is the guide so you can look it over.
The funny thing is, I have built an interface partially with Mirth that worked and it was easy to setup, but the part of Mirth that was killing me was trying to figure out their translator. I am not a programmer and I am self-taught on all of this material so I dont have a strong coding background to fall back on. Iguana seemed much easier to use once I played with it in the demo. Now if I could just get the initial connection out of the way, I am sure I could build the rest of the interface.
Looking over the documentation, it appears as though my initial observations are confirmed. The remote application is a listener and requires that the interface engine establish the connection and then receive (and acknowledge) the HL7 messages. The solution remains the same; A channel with a translator source, coded with the appropriate net.tcp.* methods, would accomplish your message delivery needs.
While generally speaking I don’t think Iguana requires a strong programming/scripting background, this may be an area where a coder might come in handy.
Given that Philips is over 50% of the medical device market, I think Interfaceware needs to develop this type of connectivity so its easier to do. I had Mirth configured in about 2 hours and was getting messages. It was because the 2nd half of the translator was not very intutive to figure out that I decided to give Iguana a try instead.
Thanks! I’ll look over the material on net.tcp and post some more questions I’m sure 🙂
I believe Lev has provided the best option with the active_llp_producer plugin. My apologies, I didn’t realize that was an available plugin for Iguana; I assumed it was a GE component (FYI, I’m not an Interfaceware employee, but my company does a lot of work with them).
So I don’t think you need to spend any time with net.tcp.*; you should be able to configure the plugin per the documentation he forwarded to you.
You must be logged in to reply to this topic.