- This topic has 14 replies, 2 voices, and was last updated 9 months ago by
.
-
Topic
-
CL Version: 20.1.1
So have a question about structures and how Cloverleaf calls structures. We have a “generic” structure for multiple messages (ADT A01, A02, A03, etc). Rather than call a translate for each one individually, we call ADT_REG when designing the structure. All the messages types flow through the ADT_REG. However, when we add a segment to this structure, we have to go back and add the structure to all the individual structures for it to work correctly (ADT_A01, ADT_A02, etc).
Netconfig:
{ ROUTE_DETAILS {
{ TYPE xlate }
{ XLATE x_ptExpREG_F_epicREG_231.xlt }
}
} }
{ ROUTE_ENABLED 1 }
{ TRXID ADT_A(01|02|03|04|05|06|07|08|11|12|13|14|16) }
{ WILDCARD ON }Xlate:
prologue
xlt_infile: hl7 2.3.1 epicHL7 ADT_PER
who: russjmc
date: September 28, 2023 3:22:34 PM EDT
xlt_outfile: hl7 2.3.1 epicHL7 ADT_PER
type: xlt
version: 7.0
end_prologueThis shows we are using the epicADT variant created with ADT_PER.
I initially noticed this when using the testing tool, but since we’ve added segments to the engine and run it end-to-end, it’s still not updating until we add the segment to the individual structures.
-
Replies
-
-
After adding the structures, did you either purge caches (might work) or cycle the process (definitely should refresh)?
The formats are loaded and cached the first time they are referenced in the engine. If they are changed (or Tables for that matter), the cache remains the same until the caches are purged either by purging caches (can be done command line or vie NetMonitor) or cycling the process.
Maybe that is what is happening.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
I apologize. I just looked at your original post more closely and realize what you were indicating is that if you add XXX Seg to ADT_REG you also need to add them to the specific Message/Event Type variants (A01, etc.).
What release of Cloverleaf? I seem to recall seeing this before but not on every release I worked on if I recall correctly. I am going to try this out on 2209. What seems to be happening is the Xlate is actually loading the variant associated with MSH-9 rather than the variant specified in the prologue.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
Same thing happening in 2209. I guess what I recall (again if my recollection is accurate) of it not working this way must have been on an older release. I am not sure I like this behavior.
I am going to experiment to see if the Xlate honors MSH-9.3 vs MSH-9.1 as specified in later releases of HL/7.
If and when I get to that, I will report back.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
Well, I think I really misunderstood what you are doing.
I think I have it now.
Did you build an ADT_REG Variant and in that Variant did you build a Message/Trigger(Event) of ADT_REG in that Variant?
In the Xlate you reference the Variant but the actual message MSH-9 contains the normal ADT Message/Triggers (ADT_A01, etc.).
The Xlate then (rightfully so) looks for a message structure in the ADT_REG Variant to match what is in the MSH-9 (which is NOT ADT_REG). Thus I think that even though you added a segment in the ADT_REG Message of the ADT_REG Variant, the other Messages, which will actually be presented to the Xlate do not have the segment.
In order for this to work, I think you actually would need to change the actual MSH-9 to ADT_REG in the messages as they flow – not something I think you want to do.
Does the above describe your setup? If not, please correct what I have.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
That’s a fairly accurate statement. I think this is going to come from a fundamental misunderstanding of how CL is designed vs what we’re used to (eGate).
This opens up a lot of questions on my side, but with us getting on the same page, is there a way to ‘group’ structures like we’re trying to do? If not, does Cloverleaf actually expect different scripts for individual message types?
-
I am probably not the best one to answer this as I have never done the ‘global, one Xlate’ concept.
I think there are others out there that are doing what you want to do, just differently. Hopefully one of them will respond.
If no one responds within the next couple of days, and you would like to brainstorm some possibilities, email me. Perhaps I am still missing something about your setup. I would like to learn more but I don’t want to get in the way of your work.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
-
I attempted to replicate what I think you are trying (Cloverleaf 2209) but am not receiving an issue. I must have something set up differently.
A question, does this seem to work in the testing tool but not in the engine? The reason I ask is I am just using the testing tool (Xlate) to see what happens and maybe that is why I am not seeing what you see.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
OK I think I finally am experiencing what you are experiencing (at least in the Testing Tool).
If you want to only have to maintain a single Message/Event in the HL/7 Variant, then you need some Tcl pre and perhaps post Xlate.
Introduced in later than 2.3.1 HL/7 was the MSH-9.3 component which is the structure to which the message is actually built (while MSH-9.1 and MSH-9.2 still indicate the active Message/Event). So, something like ADT^A01^ADT_A01.
I think in your case the message from the source system MSH-9 looks like this ADT^A01.
The Xlate is using MSH-9.1 and MSH-9.2 to select the Message Structure from the ADT_REG Variant to be used for parsing.
If you were to have a Tcl proc pre Xlate that copied MSH-9.1 and MSH-9.2 (ADT^A01), created MSH-9.3, then placed the value from MSH-9.1 and MSH-9.2 in MSH-9.3 you would have something like this: ADT^A01^ADT^A01.
Next place ADT^REG in MSH-91. and MSH-9.2 resulting in ADT^REG^ADT^A01 in MSH-9.
Now the Xlate should see ADT^REG and use that message structure from the variant for parsing (I think – I still need to verify that).
Then in a post Xlate Tcl proc you would move what is in MSH-9.3 to MSH-9.1 and MSH-9.2 so that what came in as ADT^REG^ADT^A01 goes out as simply ADT^A01 – or – if needed out as ADT_A01^ADT_REG (thus indicating which structure was used in Cloverleaf to map the message).
I have not verified a couple of points above but in theory I think that will work.
Again, if you would like to brainstorm the above, email me. At this point, unless I hear different, I have done all I can. I hope this helps some and I really hope others who like to try to use the single Xlate approach will contribute how they approach the challenge.
Personally, I don’t see the issue of multiple Xlates being that big.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
So as a follow-up (Sorry, been a bit busy!), I spoke with support and they basically confirmed what you did Jim. Basically there are a few options (We did option 1):
Option 1 – Change a structure (We’re still using the ‘group’) and use a script to overwrite the other scripts in the group. We use the “group” to define the translate, then just let the parser pull each individual structure that was copied. I set up a basic array to control this in bash:
declare -A structArr=( [REG]=”A01 A02 A03 A04 A05 A06 A07 A08 A11 A12 A13 A14 A16 A23″
[PER]=”A28 A29 A31 A33 A52 A53″
[MRG]=”A18 A34 A35 A36 A40 A41 A42 A45 A47″
[TRK]=”A09 A10 A21 A22 A23 A24 A25 A26 A27″
[SIU]=”S12 S13 S14 S15 S16 S17″ )Option 2 – Change the MSH-9 in a pre-proc, and change it back inside the translate or via a post-proc.
Option 3 – Individual scripts for each structure type (no thanks).
So yeah, confirmed that the parser will use a translate set up via a group, but you have to have the individual structures the same.
Thanks for all your help with this Jim!
-
-
- You must be logged in to reply to this topic.
