Multiple messages from one

[Jason Russell]

Is there a way to clear whole or parts of an outbound message in the translate function itself? Essentially we have lab results that are sending multiple results over a single message, and the receiving system can’t parse them, and are expecting us to split the message in a specific way (Lab, discrete microbiologies, and pathologies). So for example, a message will have a Lab, a Micro, and a Micro. They want the lab as one message and the micro as another message. I’d like to clear the ‘results’ group itself, or if there is a clean way to just nuke the whole outbound message and rebuild it. I cannot find a way to easily do this.

The problem is, like above, if we have Lab, Micro, Micro, we create the lab, then iterate over the results, it will create multiple extra OBR segments (since they’re required by structure). I can give some more examples, but clearing the outbound data between messages would be easiest way.

Topic

[Jim Kosloskey]

There are a number of ways to address this.

Have you considered using Xlate chaining?

One could also set up a route for the Lab and another for the micro each having their own Xlates. You would start with a clean OB message on each route.

Another option is to PATHCOPY @null at a segment level to clear out the unwanted segments between handling of Lab and Micro.

If you would like to discuss off-line, email me.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jason Russell]

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.

[Jim Kosloskey]

Chaining, in this case, would be useful IF the OB message structure is the same as the IB. Is that the case?

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jason Russell]

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.

[Jim Kosloskey]

Yes, the ability to clear the ‘buffer’ in an Xlate is a shortcoming.

Here is how I would consider use Chaining in your circumstance:

1. Chain of 2 Xlates
2. First Xlate –
   1. Place a unilateral SUPPRESS at the top of the Xlate.
   2. Create the Lab OB message
   3. Do a SEND. The difference between SEND and CONTINUE is SEND places the message in the OB thread directly, bypassing post Xlate processing. CONTINUE passes the OB message to the next state (in this case the second chained Xlate).
   4. Do a BULKCOPY with a CONTINUE. This will make a ‘copy’ of the IB message fo the next Chained Xlate.
3. Second Xlate –
   1. Create the Micro messages using SUPPRESS and CONTINUE as needed. As I understand it you would likely have multiple Micro messages.

Just be aware if any post processing of the SEND Lab message is needed, the Tcl code would be placed at the OB thread not the post-xlate. For the Micro messages, post-xlate could be used or at the OB thread.

Of course, another valid method is to use PATHCOPYs at each of the Group (or Segment) level (depending on the message structure) nulling out the Group by Group and Segments outside of Groups. Using the PATHCOPY at the Group level properly.

And lastly, something different…

1. Change the OB format to make the entire message a group (mark the MSH through last Group/Segment as repeating).
2. In your Xlate:
   1. PATHCOPY the MSH segment to the OB and anything else you need to do (the Xlate needs the MSH info in the OB buffer to parse the mesage).
   2. After you have CONTINUEd your message, PATHCOPY @null to the MSH Group (the entire message) this should ‘clear’ the OB buffer.
   3. Don’t forget to have a SUPPRESS (likely unilateral).

 

Jim

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

I will offer that most times I don’t need to ‘clear’ the entire message buffer between multiple message issuances. Especially for results, it is usually the OBR Group or the OBX group that is different the rest of the message is rather static (meaning most of the data in the rest of the message is the same for each of the messages being created).

So, by using a PATHTCOPY Action at the OBR Group level I can clear out only that portion of a message needed to be cleared.

Something like:

@null    PATHCOPY    1(0).1         where…

The OB format is the basic 2.5 ORU^R01 (see attached file).

This will clear all of the ORC group including the OBR segment, and OBX subordinate groups. This section of the message is typically all that changes with the issuance of a new OB message.

If there is only one ORC group and if the OBR changes, I can PATHCOPY @null to the OBR segment and the OBX Group to just clear that part of the buffer. If the OBX Group is all that changes, I can PATHCOPY @null to the OBX Group.

By just clearing the pieces that need clearing, I can avoid the overhead of building the unchanging portions for every created message. Sometimes a ballpeen hammer is more useful than a sledgehammer.

 

• This reply was modified 3 weeks, 3 days ago by Jim Kosloskey. Reason: Typo correction

Attachments:

You must be logged in to view attached files.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jason Russell]

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.

[Jim Kosloskey]

Note the Group Address Path does not have the trailing (0). If that is there the PATHCOPY only handles the first ITERATION. Without that (in my example – 1(0).1 – ending with the actual group identifier, all iterations should be affected by the PATHCOPY.

Let me know what you find out. I will try a test here as soon as I get some time.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

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.

 

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jason Russell]

Jim Kosloskey wrote:

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.

[Author]

Replies