[Jason Russell]

The xlateInVals is going to be a list of the inputs. Each line is a separate list item. Since it’s one line, you’ll need to split it. If you’re confident it will always be two sets of strings with no additional spaces you can make that assumption, however, if they don’t do that (for whatever reason) it could cause problems. The simplest pre-proc is the following:

set xlateOutVals [split [lindex $xlateInVals 0] { }]

Then set your destination as you have above. lindex will remove the {}’s around your input. Split will split it into a list,  on spaces. setting it to xlateOutVals will send it out.

This is because it is putting the input in a set of braces {} as there is a space to show it’s together. This creates a lot of potential issues, and this is not assuming any characters (braces, quotes, protected items \$, etc). There are ways to get around this, but if you trust your data that one line will do what you need. Adding additional spaces will throw this off.

For the other data, you should really have a descriptor in OBX-3 you can use to only do this to the specific data you want. OBX-3 should have something like GESTATIONAL_AGE, BIRTH_WEIGHT or some other moniker that you can use to make sure you’re only doing this to the birth weight. If they don’t that really complicates things and makes it a lot harder to do what you need to do (but it can be done).

[Jason Russell]

I’m seeing your reply, and quite frankly, that’s not how HL7 works as a whole. You don’t ‘exchange’ orders and results. From a very high level standpoint, the ordering system sends an order. This is a Dr, Tech, someone saying “I have this specimen, and I need someone to look at it and give me their findings”. This is sent to the lab system. This populates their system with basic patient data and specimen data. The specimen is then looked at by someone, and they record their findings. At this point, the lab system then sends a result. What they are saying sounds like a ‘synchronous’ feed where you send a message then wait for them to send a reply. This isn’t how Orders and Results work. This works in other situations (Pumps, certain queries, etc), but not here. You send them a message, then they send you a message.

From a more technical standpoint, HL7 has an “acknowledgement” system, much like TCP/IP but on a higher layer in the OSI model. System A sends System B a message. System B then responds with an ACK (acknowledgement) or NACK (non-acknowledgement) that says they got the message. In most situations (probably 90%+) the sending system will not send another message until they get some form of ACK (whether ACK or NACK). Some systems will send over and over. Some will error (Cloverleaf default), some will shut down. this prevents messages from going out of order.

The rare situations where you get a ‘response’ they’re not results. They’re different types of ACKS where you’re forwarding an immediate response back to the sending system. This is a messy rabbit hole I had to dive in to get some infusion pumps working correctly.

I would say if they were sending an immediate response to your order it could possibly work, however what they’re suggesting isn’t feasible. I just came off of eGate — It would be a hard “no” simply because the engine couldn’t do it.

I’m curious as to who this lab system is, and if they’re new to the game. None of the lab systems I’ve worked with would ever request this (Mako, LabCorp, Arup, there’s a few others).

[Jason Russell]

I have to agree with David. HL7 in and of itself is not a bidirectional data type. You’re not routing acknowledgements, you’re routing actual messages. This creates a mess when you’re trying to acknowledge the incoming messages and not acknowledge the acknowledgements. It could probably be done the way you want, but you’re talking a complex setup where you have to investigate each message to see if it’s an acknowledgement or an actual message, and then send (or not send) an ACK back for the non-ACK messages. It makes things incredibly overly complex and difficult to troubleshoot.

You should (as David said) have two sets of interface groups. Orders and results. You send the orders to them, then when they’re done, they send results to wherever it needs to go on a different set of interfaces.

[Jason Russell]

To be fair, their documentation matches TCL’s documentation which is not very good either. A good technical writer would help tremendously.

[Jason Russell]

Documentation is under Services User > Reference Guide > Engine NetConfig interface extension or you can search for NCI. There is another recent thread about this as well. This is the only documentation available, and I think it became available in 19 or 2022. It is still pretty barebones.

[Jason Russell]

This is definitely a work in progress; it functions as it sits (for us at least). I didn’t use the keylget pairs at the time, not sure if I will or not considering how oddly some of the setup is. This distinguishes from TCP/IP, File based (ftp, fileset local, etc). I’m working on adding a switch that adds a ‘connected’ column where it will parse netstat data to show if a thread is connected.

A lot of the script relies on our naming schemes to function properly, and I haven’t pushed some of script into procs yet. As I said, work in progress.

Attachments:

You must be logged in to view attached files.

[Jason Russell]

Documentation is under Services User > Reference Guide > Engine NetConfig interface extension or you can search for NCI. I’ve been working on a listing script since it only parses partial data, with searching functionality so I can narrow down to specific threads within a site. It’s a bit more tailored to us specifically, but it is useful. However, the netconfig script doesn’t get super granular. I was actually writing my own script at one point that did what this does in a similar fashion when I stumbled across this.

I’ll drop my script, but there’s some stuff specific to how we operate and how our environment was set up that wouldn’t be applicable to others. Let me grab the file and upload it.

[Jason Russell]

Yeah that error is pretty bad. It took us a LONG time to figure out what was going on when I first ran into it.

[Jason Russell]

We are a rural hospital system with 4 hospitals, hundreds of clinics, etc. We have a prefix on our sites to determine if they’re ‘development’, ‘test’, or ‘production’. Beyond that standard shorthand with a number (if the sites need to be split later):

apps1 (ungrouped apps) , cardio1, coding1, CSN1 – CSN is ADT, some have evolved into other functionalitly. 1 has additional HAR/second ADT, 3 has general orders (lots of combined feeds), 4 and 5 are both general ADT, devpat (devices), devres (mainly capsule items, high volume feeds), doc1 (MDMs, document ORUs), ems1 (Dealing with a complex set up for our ambulance charging interfaces), epicadt (the main ADT in, supplies all the other sites with general ADT), lab1 (about to split), rad1, rx1, sched1, sftp (SFTPs that picks up or feeds other interfaces), toepic (general results back into epic), split1 (site dedicated to splitting identical feeds, this was a legacy thing our former lead made us do), too1 (another site that deals primarily with our DMS).

When I look and think about that list and there’s some changes that I want to make, as we’ve just 100% gotten onto cloverleaf (just finished a 3 year migration from eGate — Don’t ask).

[Jason Russell]

You likely have duplicate lines. Make sure you don’t have duplicates on the first column of your spreadsheet.

Also check there are no encoded ‘invisible’ characters (tabs, nonbreaking spaces, etc). Use Notepad++ or vi -b (on Linux) to check for them.

• This reply was modified 2 weeks ago by Jason Russell.

[Jason Russell]

I would say SiteDoc could be the topic if they incorporated other things (like the GUI visual links, having different files associated to threads, etc) instead of the barebones “Here are the files in the site” listing it currently is. I did fill out the survey, but we’re likely talking years before that is put into effect.

[Jason Russell]

There’s a few ways to do this, but the simplest in your case is set a variable to a phrase that shows there is a PDF. So in your if statement, put “YES” (or True or whatever) in @hasPDF, and at the end, check that variable and suppress if it isn’t true. So if @hasPDF ne =YES, then suppress.

[Jason Russell]

I haven’t seen any. The spreadsheet is hard to read. You can filter out bug reports, and you filter on specific parts. I haven’t read through them fully yet.

[Jason Russell]

Keith, i tried that with powershell or just cmd.exe as well as cygwin and none launched. There may be something I’m missing with them. It doesn’t complain — Jut doesn’t launch. It will complain if it can’t find the file (IE: I type the wrong location).

[Jason Russell]

Without writing your own external tools, I don’t think there’s anything that will do what you want natively.

There are a few limited pre-built tools:

1. CLI – Unlimited access, only limited by what you want to do, programming skills, time, etc. However, if I’m not mistaken you do NOT have access to the CLI on Infor’s cloud solutions. Other solutions you have access (AWS, Azure, etc) just like you would locally.
2. GUI – Requires engineer access, no real reporting. Full access.
   1. They have a ‘site documentation’ tool, but all it seems to do is a printout of the NetConfig and various files being used (TCL, PDL, Xlates, Tables, etc). Not very informative imo.
3. Global Monitor – Has a listing of all interfaces in one space, can access all connection data (though not easily). Gives basic access to start/stop threads and processes. Essentially a monitoring for connectivity.
4. Cloverleaf Wizard – Web-based access to some very limited development tools. Can modify Global Variables, ports, thread names. Cannot (currently) modify xlates, scripts, etc. We haven’t used this at all so I’m not sure how deep functionality goes. This is more a tool for non-engineer analysts to update tables and other basic functions.

Infor seems to be expanding their Wizard tool. We’re on 2022.03, and I haven’t read the release notes for 2025 fully yet (we’re not quite ready to upgrade yet). I wouldn’t be able to speak on versions prior to 2022.03.

So point by point, I will try to point you to the best tool:

<strong class=”d4pbbc-bold”>From netconfigs

Show all interfaces for a given external system (e.g.,

<em class=”d4pbbc-italic”>Epic

inbound / outbound connections / associated xlates / tables and ports

• This can be done with either the GM or Wizard. Wizard is a little more ‘pretty’. GM is a teensy bit easier to switch between sites (by like 2 clicks).

Search by: IP address / port number

• I haven’t found any way to search via either the wizard, GUI, or GM. The only way I’ve been able to ‘search’ for a port is via the command line. There are ways to view (GM+Wizard) and edit (Wizard), but not search/list that I’ve found.

Quickly answer:

“What interfaces are tied to this endpoint?”

• Both GM and Wizard have route views, much like the Network Monitor and NetConfig.

“What breaks if this port/IP changes?”

• I don’t think this is possible to answer via a command. I mean that’s a “it doesn’t work the same way”. Not sure that is answerable by any method other than just doing it and testing.

 

<strong class=”d4pbbc-bold”>From xlates (where things get really interesting)

I don’t think any of this is going to be available with the current tools, and I’m not sure if there’s any plans for implementation. This would require 3rd party scripts/programs/etc to do any of the items listed under this. I get the need for this, but not for non-engineers. Doing this in-place (ie no exports) is possible from the command line.

<strong class=”d4pbbc-bold”>Nice-to-haves / future state

Generate interface diagrams from structured data

• See GM and CL Wizard above. I’m not sure if there’s much more  you want than what they already offer in this regard. It looks very similar to the NetConfig/Network monitor screens in the GUI.

Potentially use <strong class=”d4pbbc-bold”>Copilot / AI  to: visualize flows / explain xlate logic

• This requires documentation. You can potentially use AI to read the code, but it would have to understand how to read the Cloverleaf NetConfig and Xlates (which are essentially TCL lists). Honestly, we don’t document as well as we should either, but the difficulty of this comes from attempting to do this globally. There is still a lot of ‘legacy’ code in many instances which would complicate this. Then you have the fact that people code differently, and there’s different ways to execute different ways to drop messages in Cloverleaf. AI may get you a good head start, but I have a feeling that regardless of the tool it’s going to require intervention to make sense. This also only applies to workflows and data flows in one piece. This wouldn’t take into consideration an order and result paired feed, as Cloverleaf nor AI would really have a way to link those without naming schemes or other ways to ‘automatically’ link these. AI tools can help you write these, but I don’t think there’s going to be a good way to do this automatically.

surface dependencies automatically

• This could be done with scripts, but again you, Ai, or whomever else is going to have to write in how to do this and be able to link the pieces together to do this properly.

Something maintainable and auditable (not tribal knowledge)

• My thought on this here is “document, document, document”. Use AI tools to help you, but I don’t think any automatic tool is going to replace you documenting your work and what it does.

<strong class=”d4pbbc-bold”>Questions for the group

How are others solving this today?

• Scripts! We just got into Cloverleaf fully (finished our migration), now the next step is to start working on scripts to do this. We are a CLI and GUI shop and have no intent to change, so doing a lot of this from “outside” the server doesn’t suit us. We use the Global Monitor, and I’ve been looking at the Wizard for non-interface people to maintain a few things. Documenting is key. We may have to change how we work, but right now using a mix of tools is how we do it.

parsed xlates structurally (segments/fields used)?

• Not yet, not sure if we’ll do that, or just continue to expand documentation. I did look into parsing HL7 messages themselves to see what is being used, but that was a pet project of mine that kept getting sidetracked.

 

With all of that said, it seems you’re looking for an ‘easy’ button to quickly understand a workflow and intricacies of data flow within Cloverleaf. I don’t think that’s really possible. This especially true with attempting to get this information to “outside the team”. I, personally, would not want people trying to make sense of any code. There should be documentation to help explain the function of an interface. Using tools to attempt to read code, directions, filters, translates, etc without an ‘interpreter’ of sorts is a bad idea, in my opinion. I feel like interface, especially are on the decline (definitely not gone any time soon), and with Epic pushing their App Orchard and FHIR really hard, as well as other vendors getting on board with that, I would expect many of the HL7 interfaces to be on their way out, and eventually be a legacy thing.

With all of that said, even Epic does not have a ‘magic button’ to show all data flows. It takes analysts and tools and interpreting. But the larger and more complex  your system, the harder it is to do that without attempting to homogenize data so it’s all the same for everybody (which it will never be). We’re running into that issue with a few vendors who keep claiming “we work with Epic!” and then everything they want to do won’t easily integrate with our Epic implementation.

It’s also REALLY hard for a ‘middleman’ software (which is what Cloverleaf is) to see data flow from a global level.  You can force linking via different methods (again, naming schemes primarily), but there’s no easy way to say how the data flows, ESPECIALLY if it hits another piece of software then comes back in. Almost any thing to help ‘explain’ what is going on would be through notes and documentation.

[Author]

Replies