Recent posts:
Recent replies:

There is a way to "re-route" telnet over a secure SSH tunnel with a product called 'stunnel.' There are free stunnel implementations for Windows, Linux and AIX, and I have tested using it across architectures (Windows Client to an AIX server, Linux client to Windows server, etc.) so it's basically architecture agnostic.

You will have to install stunnel on the server and every client so there is some work, but it can be done "over time" so there shouldn't be much downtime.

First, install stunnel on your server and configure it for a high port - for this example, let's use 6707. Configure stunnel encrypted SSH traffic on port 6707 and 're-route' the decrypted traffic to port 23, but don't disable port 23 just yet; you'll be able to use both ports temporarily until you get all the workstations switched.. On each workstation, install stunnel and re-route unencrypted port 23 traffic to encrypt and send out on port 6707. Once you get all of the workstations converted (which means you're no longer sending unencrypted traffic) then reconfigure the server to disable any input on port 23 on your network card(s), and rely solely on the SSH traffic on port 6707. Keep in mind, you can't disable port 23 on - stunnel will need that, but as that's wholly internal to the OS it should satisfy your network scanner.

If stunnel & your firewall are set up correctly, it works invisibly with Cache / HealthShare / Iris and  every telnet client I've tested (NetTerm, putty, a couple others that don't immediately come to mind) because they still talk on port 23 locally, but stunnel does all the encryption and rerouting automatically. The only issue I've seen is if you _already_ have network issues and timeouts, stunnel can experience disconnects more often than straight telnet due to the increased overhead of the encryption.

Hope this helps!

ED Coder,

Your post is a bit confusing (to me, anyway), as I don't work much with HL7 on a daily basis, and I'm not sure what you mean by $GLOBAL, so I am going to try to clarify -- but I'll warn you, my crystal ball is usually pretty cloudy so I might be way off. If I am, I apologize in advance. But I hope this helps anyway.

Now, I'm going to assume that instead of $GLOBAL you really meant ^GLOBAL for where your info is stored -- as in, you've set up this info beforehand:

Set ^GLOBAL("123","bone issue")="Spur"   ; Sorry, but I added some data. You'll see why later.
Set ^GLOBAL("234","joint issue")="Ache"  ; Also on this one.

I'm going to assume one other thing for this post: that the local variable name that contains your data is called HLSEG. We can simulate this with this command:

Set HLSEG="$GLOBAL(""123"")"

Now, I realize that you may not be able to use carats (where I work we call 'em "uphats" -- don't ask me why...) in HL7 data so that's why you may have substituted the '$' symbol to indicate a global.

So, with those assumptions in place, here's a possible process on how you could get the data from a global into your segment.

First, if we assume that if the data doesn't start with a '$' symbol (indicating the need to reference a global) then just exit the process:

If $Extract(HLSEG,1)'="$" Quit

$Extract (in this case) gets just the first character of the HL Segment and if it isn't a '$' character then just quit. Here's documentation on $Extract:

If it does start with a '$' then we need to turn that into a carat. If your HL7 data can't contain '$' symbols beyond the first one, we can use the Translate function (documentation here: )

Set HLSEG=$Translate(HLSEG,"$","^")

That turns *all* '$' symbols to '^' in your variable, so if your HL7 data _could_ contain more '$' characters, this won't work for you. In that case, we'll just strip off the first character (no matter what it is), save the rest and prefix that with a '^':

Set HLSEG="^"_$Extract(HLSEG,2,$Length(HLSEG))

Now that we have the actual global name in HLSEG, we can use the Indirection operator to access the global through HLSEG, and use the $Data function (documentation here: )to see to see if that global exists:

If $Data(@HLSEG)=0 Quit ; no data here.

$Data will return a '10' or '11' if there's a subnode (for ^GLOBAL("123") the subnode is "bone issue") so if there is, let's put that in the local variable SUBNODE - for that we need the $Order (documentation here: ) function:

If $Data(@HLSEG)>9 Set SUBNODE=$Order(@HLSEG@(""))

Now SUBNODE will contain "bone issue". We can use the $Data function to see if that subnode actually contains data [[ this is why I changed your example a bit, to make it easier to demonstrate this ability ]], and if it does we'll put that in the ISSUE variable:


Now the variable ISSUE will contain "Spur".

Now that you have the info for the SUBNODE and ISSUE local variables populated, you should be able to  use them to assign what you need in your segments.

Again, it's possible I'm way off base on this and this didn't help you - if that's the case then I apologize but you might want to provide a more descriptive example of what you're trying to accomplish. I also apologize in retrospect if any of my code examples contain bugs. But I really do hope it helps you!

Not sure if this will help, but Ensemble does (or at least did) support SNMP, so if your organization already runs a Network Monitoring platform like SolarWinds, OpenNPM or the like, you may be able to import a custom OID into that tool and let it do the monitoring for you.

That said, I do _not_ know if Ensemble's SNMP support is granular enough to be able to report on HL7 statistics, but at least it might be a place to start.

Full disclosure: I've never worked with Ensemble's SNMP support before, although I've read a bit about it. I was "more than passable" working with SolarWinds about a decade ago, enough that I could create custom OIDs and monitor specific things through custom Python scripts.

Hope this helps!

Roger has no followers yet.
Roger has not followed anybody yet.
Global Masters badges:
Roger has no Global Masters badges yet.