Primary Issue: Make sure that your firewall is allowing traffic in and out over the ports you've selected in your listener profile(s). You might have to create application "exceptions" in your firewall for your COREHL7 Listener executables (CoreHL7ListenerConfig.exe, COREHL7ListenerService1.exe and COREHL7ListenerServiceX.exe)

Using Network Shares or Mapped Drives

It is very important to remember that running a profile locally is NOT the same as running a profile in a Windows Service. The most common support contact we have EVER had for our server products is because people misunderstand this issue.

When you run locally the program is executing as YOU (the Windows User) and (unless YOU changed it) the Windows Service is NOT. By default the Windows Service will run as the built-in Windows account LocalSystem.

This means that IF when you created your listener profile(s) you selected a data folder which resides on a network share, mapped drive, or NAS (Network Attached Storage) device, you may have an issue when your CORE HL7 Listener services try to run. This is because when running locally YOU have access to these network resources while the service, running as LocalSystem, likely does NOT.

Luckily, if you encounter this scenario, there are a couple of easy fixes to resolve.

1.Change your listener profile and select a data folder which resides on a local HDD and share that folder on your network so that other applications can access it.

2.If #1 is not an option, you will need to modify your CORE HL7 Service(s) and have them run as a Domain User which DOES have access to the network resource you are trying to use. To this just click on the toolbar to open the MS Windows Services, then RIGHT CLICK on the preferred service and select Properties. In the Service Properties go to the Log On tab and enter the domain user you (or your network admin) have created to run the service(s).

Configure Windows Service Logon

SCENARIO 1: You have your CORE HL7 Listener(s) running as Windows Services. When the server reboots your trading partner(s) cannot connect to your Listener(s) even though the services are running. The problem resolves itself if you restart the Service(s).

SCENARIO 2: You have your CORE HL7 Listener(s) running as Windows Services. Throughout the day your trading partner(s) are able to deliver messages to you but then at some point they cannot connect to your Listener(s) even though the services are running. You can test the connection to your listener using the CORE HL7 Simulator and it works? The problem resolves itself if you restart the Service(s).

What is likely happening: The key to understanding what is happening is this statement from the scenario "The problem resolves itself if you restart the Service(s)". Since everything works if you restart the service(s) we know that there's not some type of fundamental error or firewall issue happening. These issues are almost always related to a VPN being used (and usually one that's hosted on the same computer/server as the CORE HL7 Listener).

First you need to understand what happens when a CORE HL7 Listener starts up. It will bind (listen) on the port number selected for EVERY IP Address on the computer. This means that if your server has 10 NIC cards with 10 different IP addresses and your profile port number is 5000 your listener will be listening on ALL 10 IP addresses for HL7 data on port 5000. Now, IF your server has <x> IP address(es) AND also hosts a VPN (or attaches to a VPN) which then assigns the server another IP address <x+1> what does the CORE HL7 Listener do?? Well, it depends on what comes first. If your CORE Listener starts BEFORE the VPN attachment it will bind to <x> IP address(es). If it starts AFTER the VPN attachment it will bind to <x+1> IP Addresses. The same situation applies to Scenario 2. Everything started up fine and the Listener was listening on all IP Addresses (including the dynamically assigned VPN address) but then, for some reason the VPN goes down, and then comes back up. What happens here can vary depending on the VPN configuration, but it MAY result in the CORE HL7 Listener not receiving traffic on the newly re-connected VPN IP address.

How to Fix: There are a couple of things that you can do that will usually alleviate this problem. We recommend that you implement them all if possible.

1.Change the start mode of your CORE HL7 Listener services from "Automatic" to "Automatic (Delayed Start)". This way if your server is creating (or attaching to) a VPN on boot-up the CORE Listener services will start AFTER this occurs.

2.In your Listener Profile(s) implement an idle restart by checking the Restart Listener if idle for too long box.

3.Be proactive and monitor your VPN and restart your CORE Listener services if there's a disruption in service.

See this discussion about installing and removing the Windows Services.

If the client is using a HL7 Standard TCP/IP Sender make sure your CORE Listener is not configured as a secure encrypted Listener. If it is not and you are sure that your Listener profile is running check the following:

•Is your client sending to the correct Port Number and TCP/IP Address?

•For the client, can they open a Command Prompt and PING your TCP/IP Address? If not, that's definitely a problem.

•Verify that Firewalls on both sides (yours and theirs) are allowing the HL7 traffic through.

If you have verified all of this then it might be time to get the network administrator involved. One very quick and easy test is for YOU to try and send a test message to your CORE HL7 Listener on the same computer. You can download and install our free UltraPort Ad Hoc HL7 TCP/IP Sender to do this (download here). If you cannot receive a test message sent on the same computer there is no way that you will be able to receive one sent from another computer.

Other things you might try:

•Run your Listener Locally. If it works when Running Locally but NOT when you run as a service see that discussion in Troubleshooting.

I have configured my Secure Listener according to the instructions, however, my client using their own secure encrypted HL7 TCP/IP Sender (not the CORE HL7 Sender) cannot connect to my Listener. What's the problem?

Well to answer that you would need to know exactly what type of error the client is getting when they try to connect. Be aware that their secure HL7 TCP/IP Sender might not be able to connect to our CORE HL7 Secure Listener. It depends on how they (the client's software vendor) implemented their secure sender. You can refer them to the Technical Specifications of our CORE HL7 Secure SSL/TLS Listener for more information. You can contact us here and we would be happy to sit in on a call with you, them, and (hopefully) their software vendor to work it out if possible.

The difficulty with secure encrypted HL7 TCP/IP data transfer is that there is NO HL7 STANDARD for it. The HL7 Standards for HL7 Listener and Sender software mandates NO ENCRYPTION. There is a decent discussion of this here.

Our CORE HL7 Listener and CORE HL7 Sender software adhere to the worldwide TCP/IP Standard (NOT the HL7 Standard) for secure encrypted data transfer using X.509 Certificates. The main problem with THAT is that there are several different TCP/IP Standards for how to do this. For instance, this (the CORE Listener and Sender) isn't the first time that TransWorld Scribes has created a secure encrypted HL7 Listener. We did it years ago in our CORE HL7 Postmaster (see here) with our IPSec Tunnel Listener and Sender. That product also uses a X.509 Certificate to create a secure specialized TCP/IP Listener BUT it uses a totally different TCP/IP Standard method of connection.

With the CORE HL7 Listener and CORE HL7 Sender we have studied this issue for years, knowing that we had to provide a solution, if only because there are unscrupulous software vendors out there who prey on unsavvy decision makers with pressure saying that they MUST have this SSL/TLS feature when if you already have a secure VPN it is quite possible that you do not need it

What we have done with our software is designed our secure encrypted Listener and Sender to use the TCP/IP Standard for encrypted data transfer which is the closest possible to the HL7 Standard.

We back this up by not charging extra for SSL/TLS functionality. Is that true of your other HL7 Software Vendors?