@jmcrussellfirsthealth-org
Forum Replies Created
-
AuthorReplies
-
The ‘cleanup’ comes when the specific accounts are no longer being sent at all (visit is over!), and there’s nothing to tell the script that this is the last message (it likely just stops). So to keep the DB minimal, you’d have to run a process outside the script itself to remove old accounts over x days old.
October 7, 2025 at 5:21 pm in reply to: Trying to replace an entire message with msgset, still only sending old message #122187Did you restart your process fully? Is the tclproc fully saved and showing up in the list? Just seems like the new code hasn’t been updated in memory.
We do something similar with another vendor who sends a lot of patient data over and over. Just got to make sure you have enough data to make sure you can tell the difference. As for cleaning I would have a scheduled task that would run on a daily/weekly and checks the date/time stamp and removes them if they’re more than x time frame old.
I did, using a script inte parsing directory as you mentioned. It picks up all the results and sends a single message as response, works as expected, thank you!
So each instance of the trigger only happens once, so if it picks up a file based on the directory, it won’t pull the others until the next time trigger?
Well, I had a few minutes, and my test shows the results are dependent upon the variant definition. This is not surprising. In the standard ORU^R01 message the OBR is a required segment in the ORC Group (see layout in an above post). So, when PATHCOPYing @null at the group level, as many empty OBR segments as were created before the PATHCOPY will remain as empty OBR segments. Those can be reused but cannot be removed within the Xlate. The Xlate always outputs required segments even as empty segments. However, if one makes the OBR segment optional it will be gone after the PATHCOPY. The relationship between message variants and what wants to be done in the Xlate is essential to accomplish the transformation needs.
This confirms our findings. A little annoying, but it’s what we have to deal with.
September 8, 2025 at 4:46 pm in reply to: Pros and Cons of filtering messages in TCL vs Xlate #122162I think you’ve noted some of the major pros and cons between the two. I think Jim Kosloskey has done a load and timing comparison doing TCL vs Xlate, and I think the difference was minimal.
I will add this, when we were coming onboard with Cloverleaf, they (Cloverleaf reps/trainers) pushed against filtering in Xlate.
However, the answer comes down to “it depends”. It’s a whole lot easier and cleaner to write generic filters (we have a lot of facility and department filtering) that are stored in master that a LOT of our interfaces use. You call the filter, pass in a table, and it does it’s work based on that. When troubleshooting, while it does add an extra step, you know it’s there, it’s marked and you immediately understand what it does. There is no need to parse the entire message (just pop out the data you need, check to see if it needs to go, and work it based on that).
On the inverse, when you get to specific filtering that is unique to a specific vendor/interface, it’s almost easier to do in the XLate. However, when doing it that way, there has to be an easy way to see if you’re filtering in the Xlate. Comments and whatnot can help, but again, that’s a high level design choice. Filtering in TCL helps quickly see IF it’s happening, and then you dig deeper to see how it’s happening. Keeping the filters in Xlates means you have to dig into the Xlate itself and see if it’s filtering and how it’s filtering it.
And this is my personal opinion, to me it’s easier to read filter rules in TCL, depending on how it’s written (assuming some decent style guides and good variable naming).
One of the things that a senior tech has emphasized is “make it so it’s easy as possible to troubleshoot at 3 AM after being woken up out of a deep sleep, and you didn’t write it”.
That’s what I would look for, but clearing that group doesn’t seem to clear all iterations of it, just the first. There is an interface where we do that, but in this instance we may have two repetitions before needing it cleared.
I’ll try that again just to be sure, but it didn’t seem to work the way we wanted.
I agree with Jim. Your scan interval controls how often (in seconds) it looks, read controls how often it reads a new set of lines in the file, and number of messages controls how many messages it reads at a time. I usually keep ours at 1 scan, 1 read, and 10000 messages, but we rarely load large datasets, and when we did (millions of messages), we had to adjust so we wouldn’t cause data delays due to cloverleaf processing inbounds first.
Beyond that, there is a bit of a delay even picking up the files, usually a few seconds (it also depends on how large the file is).
with the resend function, you’re injecting the messages directly into the engine skipping all of the file reading delays.
But with the defaults, method 1 would take forever (picking up a message, waiting 30 seconds then picking up a new message). Method 2 wouldn’t be much better (picking up a message, reading a line then waiting 5 seconds to read the next message).
If you’re looking to pick up a single file that you control when it picks up, file is another option that should be faster. You would control when it picks up by restarting the thread. Once it reads the file it’s done until another file with the same name is placed and the interface restarts.
Yes, the IB and OB are the same, however, my understanding of chaining may be lacking where we would use SEND vs CONTINUE.
I still find it interesting that Cloverleaf doesn’t have a way to simply clear the outbound message completely, allowing you to start a new message from scratch.
September 3, 2025 at 1:57 pm in reply to: Is there a way to use both a TCL proc and Output Message Format on a route? #122145Interestingly enough, we use a mix of TCL and xlate for our interfaces. TCL for filtering, XLates for actual HL7-HL7 translations and functionality.
As far as I am aware, the xlate is built on top of TCL and the only extra overhead is loading the structure and parsing the message out completely, which should be nearly instant. I would be curious as to your throughput (how many messages) and what kind of hardware you’re on (even if you’re in VMs).
How many threads and processes are in your sites? There are some things that we were doing (and still are to some extent) that could help reduce processing on messages that cloverleaf recommends.
As for field lengths, we disabled field length checks completely. Considering data changes and software updates, if we need to limit fields we do that manually on an as-needed basis.
You should also be checking your monitord logs ($sitedir/exec/hcimonitord/hcimonitord.log). We had a site do this, the monitor daemon would crash causing the issues you described. the threads were still processing, but the gui would never load right. Ours was caused by an issue where alerts sending emails were stepping on each other’s toes, and would leave a file that the engine couldn’t do anything with, causing the monitord to fail.
Sometimes restarting the monitord process would work, sometimes we’d have to kill. Sometimes it’d come back up on it’s own, but the pid file in the same directory as the log was not clearing out properly causing the ‘status’ to read incorrectly.
Chaining is an interesting thought, but I may be mistaken on how it works. My understanding is that you have multiple translates, and each step modifies the translate before hitting the end point. I’ve worked with branching where you do work at a high (chain) level, then do some minor work for each individual system on the branch, but it seems that wouldn’t work for chaining.
September 2, 2025 at 2:00 pm in reply to: Is there a way to use both a TCL proc and Output Message Format on a route? #122135I’m curious why you’re converting xlates to TCL? They both have their pros and cons. TCL can do some really fancy stuff as scripts and basic bulk actions. Xlates use HL7 formats to make sure data goes from a message to an outgoing message. They really have different functionalities. The entire point of the Xlate is to use the structures to make sure the messages are formatted properly, with the correct segments in the correct places.
There are HL7 libraries for TCL, but they are very basic processors, and don’t use formatted structures. There is a reason you want to use a structure for HL7, they can get messy quickly if you don’t.
What version of Cloverleaf are you using?
-
AuthorReplies
