Forum Replies Created
-
AuthorReplies
-
Have been bitten by this “feature” many times. As to where it is, Debbie is correct; Preferences tab at the top, System tab at the left, its on the right side of the pane at the top. Seems to be consistent location, at least between versions 6.1 and 21.1. Make sure it’s disabled. First thing I do when installing/upgrading GM, making sure it’s disabled. Makes maintenance on the engine a real PITA when it keeps restarting the monitor daemon on you. We’ve also encountered issues in the past with it creating “ghost” ones, where it thinks it’s down, so it spins up another instance, and so you have duplicates.
Also, any time you make a change(i.e. to configuration and/or adding/removing a site), I would recommend bouncing the Global Monitor service. The host server is supposed to be dynamic when it notices a change in the server.ini file, but can’t hurt to bounce that too.
HTH,
TIM
Tim Pancost
Trinity HealthAs it stands, if an MRN type id is found, you’re not updating dispList, so you have a message leak.
Looks like somewhere along the way you lost the check if the id retrieved is the MRN. The section:
set mrn [hl7::get_field hl7 PID.3($i).1]
if { [string equal $mrn “”] eq 1} {
lappend dispList “CONTINUE $mh”
}
set found_mrn $mrnShould be more like:
if { [hl7::get_field hl7 PID.3.($1).5] eq “MR”} {
set found_mrn [hl7::get_field hl7 PID.3($i).1]
lappend dispList “CONTINUE $mh”
}And then, later on, remove the “} else {” before the KILL, it’s not supposed to be there:
echo “Killing message with Message Control ID: |$MSH_10| because of $errormsg”
} else {
lappend dispList “KILL $mh”Should be more like:
echo “Killing message with Message Control ID: |$MSH_10| because of $errormsg”
lappend dispList “KILL $mh”One more thing, your close brace after your sourceconn check should be after sending the email. As it stands, it’s always going to try to send an email, missing MRN or not:
if {$sourceconn eq “”} {
set sourceconn TestTool
}}#Create the e-mail
###echo “This is sourceconn: |$sourceconn|”
set mailto [tbllookup Missing_MRN_Email $sourceconn]
#echo “This is mailto: |$mailto|”
set mailfrom [tbllookup Missing_MRN_Email “MailFrom”]
set mailhost [tbllookup Missing_MRN_Email “MailHost”]
set PORT [tbllookup Missing_MRN_Email “MailPort”]
set mailsubjectprefix [tbllookup Missing_MRN_Email “MailSubjectPrefix”]
#set subject “$mailsubjectprefix Cloverleaf – Patient X Number: $PID_3_1 – THH message from $MSH_5 i.e. thread $sourceconn with message ID $MSH_10 needs manual intervention!”
set subject “$mailsubjectprefix Meditech sent an HL7 Order Message without the MRM number to Cloverleaf”
#set errormsg “This is the message ID: $MSH_10 \nThis is the reason why:\n\n$errormsg \n Patient X Number: $PID_3_1 \n Minor Patient ID: $MRG_1_1 \n The Major UHB patient ID is: $PID_4_1 \n The minor UHB Patient ID is: $mrgid\n\n Please check that the UHB ID matches the correct HCA Patient ID.”
set errormsg “This is the message ID: $MSH_10 \n\n This is the reason why:\n\n$errormsg \n Patient X Number: (PID.3) $PID_3_1”
#echo “This is errormsg: |$errormsg|”
set emailbody $errormsgSendEmailAsAlert $mailto “” $emailbody $subject $mailfrom “” “” $mailhost $PORT “0” “0”
###echo “email should have been send now”}
Should be more like:
if {$sourceconn eq “”} {
set sourceconn TestTool
}#Create the e-mail
###echo “This is sourceconn: |$sourceconn|”
set mailto [tbllookup Missing_MRN_Email $sourceconn]
#echo “This is mailto: |$mailto|”
set mailfrom [tbllookup Missing_MRN_Email “MailFrom”]
set mailhost [tbllookup Missing_MRN_Email “MailHost”]
set PORT [tbllookup Missing_MRN_Email “MailPort”]
set mailsubjectprefix [tbllookup Missing_MRN_Email “MailSubjectPrefix”]
#set subject “$mailsubjectprefix Cloverleaf – Patient X Number: $PID_3_1 – THH message from $MSH_5 i.e. thread $sourceconn with message ID $MSH_10 needs manual intervention!”
set subject “$mailsubjectprefix Meditech sent an HL7 Order Message without the MRM number to Cloverleaf”
#set errormsg “This is the message ID: $MSH_10 \nThis is the reason why:\n\n$errormsg \n Patient X Number: $PID_3_1 \n Minor Patient ID: $MRG_1_1 \n The Major UHB patient ID is: $PID_4_1 \n The minor UHB Patient ID is: $mrgid\n\n Please check that the UHB ID matches the correct HCA Patient ID.”
set errormsg “This is the message ID: $MSH_10 \n\n This is the reason why:\n\n$errormsg \n Patient X Number: (PID.3) $PID_3_1”
#echo “This is errormsg: |$errormsg|”
set emailbody $errormsgSendEmailAsAlert $mailto “” $emailbody $subject $mailfrom “” “” $mailhost $PORT “0” “0”
###echo “email should have been send now”}}
HTH,
TIM
Tim Pancost
Trinity HealthLong story short, it’s killing it because you told it to kill it.
After going through the repetitions of PID-3 to (hopefully) find the MRN, you set a variable, errormsg to “”. Then it looks like you’re building an email, regardless if you’re going to be sending it or not. You then check if errormsg is “”, which it will always be, as you never change it after initializing it. And inside that if statement, you send the e-mail and kill the message, although your comment says to continue it.
I would think that somewhere you would need to check if the mrn variable is blank, and use that to determine if errormsg should be populated with something. Then, if it is populated, build and send the e-mail and kill the message, otherwise continue the message. So something along the lines of:
if {$mrn eq “”} {
set errormsg “This message has no MRN identifier included.”
} else {
set errormsg “”
}
Then:
if {$errormsg eq “”} {
lappend dispList “CONTINUE $mh”
} else {
…build/send e-mail section
lappend dispList “KILL $mh”
}
Or something to that effect.
HTH,
TIMTim Pancost
Trinity HealthTo go along with Jeff’s suggestion, I might also wonder if the get_field proc/command needs another argument to say what level you want(whole field, particular component, particular repetition).
Also, I’m thinking that it should be $hl7 in the call to get_field, not hl7. You want to pass the content of the variable, not the name of it.
Also, I’m wondering about the calls to get PID-3 and PID-3.5. Is that just to echo out their values during debugging? Otherwise, you’re looping through the repetitions of that field later on to find the MR, so the initial calls are unnecessary.
HTH,
TIM
Tim Pancost
Trinity HealthHey, Rob,
Congrats on the retirement! Pretty sure the first time I met you was at my Level 1 training WAY back in January, 1995! It’s been a pleasure working with you throughout the years. We always knew we’d get an answer to whatever question we had once Rob got involved.
Now go use up those frequent flyer miles you must’ve accumulated through the years! And have a Pan-Galactic GargleBlaster on me!
-TIM
Tim Pancost
Trinity HealthNo, we are not in the cloud, with no intention to be so.
Tim Pancost
Trinity HealthMarch 5, 2024 at 9:07 am in reply to: Upgrading from Cloverleaf 6.2.3 to 22.09 – Testing and Issues #121228Oops, forgot to turn on reply notifications, so a bit late “back to the game”. I should clarify my comment about Infor not doing critical patches/hot-fixes. I meant customer-specific critical patches/hot-fixes. Versions and patches are released quite regularly, and Rob is absolutely spot-on with installing available patches. When we went to 20.1, we also installed the 20.1.1.0 and 20.1.1.3 patches(those available at the time).
We’re planning on upgrading this fall, so wish us all luck!
TIM
Tim Pancost
Trinity HealthHmmmm, something about that doesn’t seem quite right. AIX has been 64-bit compatible, from what I’ve read, since version 5. Are you on an earlier AIX version than that? Looking at our own AIX box(AIX version 7.2.0.0), the kernel is in 64-bit mode:
CHiep1 /cloverleaf/cis20.1/integrator/bin
$ getconf KERNEL_BITMODE
64That being said, when you look at the hciengine executable, it is a 32-bit application:
$ cd $HCIROOT/bin
CHiep1 /cloverleaf/cis20.1/integrator/bin
$ dump -ov hcienginehciengine:
***Object Module Header***
# Sections Symbol Ptr # Symbols Opt Hdr Len Flags
7 0x007d33d6 51601 72 0x1042
Flags=( EXEC DYNLOAD DSA DEP_SYSTEM )
Timestamp = “Feb 11 00:03:31 2022”
Magic = 0x1df (32-bit XCOFF)So, to me, the question is, would Infor offer a 64-bit version of Cloverleaf?
HTH,
TIM
Tim Pancost
Trinity HealthFebruary 29, 2024 at 10:20 am in reply to: Upgrading from Cloverleaf 6.2.3 to 22.09 – Testing and Issues #121203While we didn’t go all the way to 22.09, we did go from 6.2.3 to 20.1.1.3. FWIW, we’re also on AIX. Different O/S’ may have different upgrade paths.
- Testing – Our testing was based on identifying a several dozen key interfaces and focusing on them. We also made sure we had a good diversity of systems(e.g. ADT-only, radiology, lab, cardiology, etc…) and message types(e.g. ADT, orders, scheduling, results, documents, etc…). Testing each thread individually, of 2500+, just wouldn’t be feasible. Once the new version was installed on the test box, we transferred inbound production SMAT DB’s over to the test box, then ran them through the Route Testing tool in both the old and new versions. We then compared the output files to ensure they were either identical, or we could explain why they weren’t. Almost all of them were, and none that did have differences couldn’t be explained(e.g. ‘T’ vs ‘P’ for the HL7 processing type in the MSH segment).
- Challenges – Our only really challenge with the upgrade was that we didn’t realize that Infor had changed the way they do security sometime around version 19(?). This means that you’ll need to request a new customer certificate from Infor. You can either put in a ticket in the Support Portal, or contact your rep. We struggled with this one for a while, as we didn’t feel it was terribly well documented, at least not when you jump over the version where the switch occurred.
- Performance – We just used standard O/S-based tools to watch performance, i.e. topas. We really did not notice any performance difference. Given that Cloverleaf is such a mature product, we weren’t really expecting any. Versions now are more about added features and such, rather than updating the core of the engine. It was fairly well optimized some time ago.
- Support – We didn’t really have much of anything in the way upgrade-related issues, and certainly not that would be noticed by users of downstream systems. Kinda the whole point of testing, so they DON’T see anything. As for patches/hot-fixes, Infor doesn’t really do that, at least I’ve never known them to.
- Lessons learned – Our experience was quite smooth, honestly, so I don’t know that there was much we would’ve done differently. As for best practices, I would say those are the same as for anyone working with Cloverleaf. Learn it. Read everything you can about it. Understand the engine internals. Don’t just use the IDE, understand the file structure. Once you have that, upgrades are mostly a matter of getting permission to bring the engine down for a couple hours when you upgrade production.
HTH,
TIM
Tim Pancost
Trinity HealthHey, Colin,
Doesn’t look to me like you actually have any error. Looks like you’re in debug mode, so it’s listing out the entire PDL code. That “error” you’ve highlighted is what would happen if the switch statement evaluates to “input-error”. Other options are “no-match” and “default”.
Seems like you have your engine output jacked WAY up on your test box.
HTH,
TIM
Tim Pancost
Trinity HealthJuly 5, 2023 at 8:46 am in reply to: message deleted in one route, but also in another incorrectly #120672It is attached to my previous post, tps_genContinueKill.tcl.
Tim Pancost
Trinity HealthJune 30, 2023 at 4:29 pm in reply to: message deleted in one route, but also in another incorrectly #120665I can provide you with a generic proc that allows you to filter based on a specific value or values within a specific HL7 segment/field/component. It is attached. The arguments are the segment, field, component, value(s) you’re looking for, and the disposition of the messages that contain the value(s). So, in your instance, I don’t know what A-3-1 is, nor the “A01 neq XX” in your earlier message, but something equal to ‘P’ in an HL7 message often refers to MSH-11(Processing ID). In this case, your argument list would look like:
{SEGMENT MSH}
{FIELD 11}
{COMPONENT 0}
{VALUES {P}}
{DISPOSITION CONTINUE}This will CONTINUE any message that has a ‘P’ for the Processing ID, rather than, say ‘T’ or ‘D’.
Alternately, if you wanted to only specifically KILL the other two, your argument list would look like:
{SEGMENT MSH}
{FIELD 11}
{COMPONENT 0}
{VALUES {T D}}
{DISPOSITION KILL}HTH,
TIM
Attachments:
You must be logged in to view attached files.Tim Pancost
Trinity HealthJune 30, 2023 at 3:50 pm in reply to: message deleted in one route, but also in another incorrectly #120663Ah, young Padawan, this reminds me of an old saying, “There are no stupid questions.” And that may very well be true. But I will add to that with, when it comes to Cloverleaf, and particularly routing and filtering, “There are no simple questions.” It’s ALL about the details.
I will say that we, as a best practice, do not doing filtering with Xlates. It’s inefficient, and could very well end up causing performance issues with high-volume interfaces. We take the mind-set of “get rid of unwanted messages as soon as we can”. So all filtering takes place either in the IB Data TPS of the source thread, or in the Pre Procs TPS of the route detail. That means writing Tcl procs to do the filtering. Another bonus of this is that you can re-use those filters on other threads that need to do similar filtering.
By using SUPPRESS within an Xlate, you may have stumbled on a “feature” of using that action within a route, in that it behaves like the message errored in the xlate. I do see this in the help doc for the SUPPRESS action: “SUPPRESS suppresses processing of the original input message beyond the XLT phase.”
HTH,
TIM
Tim Pancost
Trinity HealthJune 30, 2023 at 3:20 pm in reply to: message deleted in one route, but also in another incorrectly #120660Without knowing your exact set up, it’s going to be difficult to say. If you’re using using chaining/branching, and you kill the message at the top, nothing below is going to get the message.
If you’re using more straight-forward routing, it could depend on how you’re “deleting” the message. If you’re simply KILL’ing it in a pre-proc on the detail, then yes, it should still go through other route details. But if you’re ERROR’ing it, and you have “Remove all messages when any route detail fails” set on your route, nothing in that route is going to get the message.
Think we might need some more detail in your exact configuration to really say.
HTH,
TIM
Tim Pancost
Trinity HealthHey, Charlie,
Sad indeed. Greg helped us set up our first HA failover scripts “back in the day”, and some other scripts that we still use to this day. Sorry to hear of his passing.
-TIM
Tim Pancost
Trinity Health -
AuthorReplies