How to: Receive one ADT/A17 message, send two A02's in DTL

Question

Question

Sergey Sevastyanov · Feb 12, 2020

Ensemble beginner here. One of the downstream applications requires to send two A02 messages instead of one A17. We do it easily in Cloverleaf - either in translation or TCL. How do I create 2 target messages out of one source message in DTL?

Discussion (10)0

Log in or sign up to continue

Jeffrey Drumm · Feb 19, 2020

I set up a test scenario based on your criteria. I created a service, HL7 router process and 3 operations:

Service: HL7 MLLP, target HL7 Router, AckMode=Application

Process: HL7 Router, ForceSyncSend: True, ReplyCodeActions: E=F

Target Operation 1: HL7 File Out

Target Operation 2: Custom Operation that returns an HL7 NAK, sets IsError to 1, logs an error code of 5001 with text "Forced NAK", ReplyCodeActions: E=F

Target Operation 3: HL7 File Out

Observations:

Message arrives in router process
Routes to Operation 1, completes successfully
Routes to Operation 2, receives error
Router responds to Service with Error; shuts down ... no message delivered to Operation 3
Service returns NAK to sending application
Message remains queued for Router

Isn't this what you would want to happen?

0 0

score 0 · Answer 1 · 2020-02-12T09:07:48-05:00

In the routing engine, you can transform and send one message to as many transformations and targets you want to.

score 0 · Answer 2 · 2020-02-12T09:38:17-05:00

Sergey Sevastyanov · Feb 12, 2020

Thank you, Neerav Adam

0 0

score 0 · Answer 3 · 2020-02-12T09:09:00-05:00

If the order of the A02s is not important, you can simply create a routing rule with two Send actions for the same target; the first Send is configured with a DTL that creates an A02 for the first transfer, and the second a DTL for the second transfer.

Many receiving systems will have an issue with this, though, as both patients temporarily end up in the same bed. While it might be fun for the patient, the transfers may be rejected. In some cases you may need to perform 3 transfers: Transfer patient 1 to a dummy bed, transfer patient 2 to patient 1's prior location, transfer patient 1 to patient 2's prior location. In this scenario, it would probably be prudent to use a BPL to enforce synchronous behavior, guaranteeing that the transfers happen in a specific order.

score 0 · Answer 4 · 2020-02-12T09:20:14-05:00

Neerav Verma · Feb 12, 2020

Hey Jeffrey, In routing engine if you say Yes to - Force Sync Send this could be avoided, isn't it?

0 0

score 0 · Answer 5 · 2020-02-12T10:09:00-05:00

Yes Neerav, that will avoid it, but at the possible expense of both performance and robustness. If one process called from the routing rule doesn't complete, nothing else does either.

In a BPL you have more granular control over sync/async works.

score 0 · Answer 6 · 2020-02-12T11:53:27-05:00

On that note, I had one question.

ForceSyncSend is true.

Let's say I have 2 transform & send in one rule. If first transform is successful and sends to first target and that target returns a false in a response status property as 0 - Can we stop all next sends to not do anything depending on the response or should the first target throw an exception instead of sending 0 in a response property.

score 0 · Answer 7 · 2020-02-12T12:04:00-05:00

Jeffrey Drumm · Feb 12, 2020

While I haven't tried it, I'm fairly confident that this would be handled via ReplyCodeActions in the router.

0 0

score 0 · Answer 8 · 2020-02-17T08:37:10-05:00

ReplyCode will take response only from one i think.

Think of this situation

1. Read a EDI/HL7 File

2. Send to RoutingEngine

3. Router - Has ForceSyncSend as true
a. Transform & Send - Op1
b. Transform & Send - Op2
c. Transform & Send - Op3

and so on.

Should the ops throw an error or should we catch it in the op and send Status = 0 as response?
Where do we handle the response in the routing engine as there is no place for that ?

Ideally if either op1, op2 or op3 fails, it should not move forward.

score 0 · Answer 9 · 2020-02-12T09:37:25-05:00

Thank you Jeffrey. The receiving system doesn't care - they just need to know where to find the patient. So as long as the location is updated for both patients they are good. We've been sending this through Cloverleaf for many years now, but we are switching to Ensemble and converting our interfaces.