Xlate Enchancement…

[Tom Rioux]

Just wanted to get others thoughts on something:  what is the opinion of Cloverleaf making an enhancement to the Network Configurator to allow multiple xlates to be placed in a route?   Here is why I ask.  We have multiple routes that use the same xlate.  We then have some tcl procs that do some modifications to the messages in the outbound tps.  I was thinking, (please correct me if I am wrong), that since the xlate essentially uses in tcl in the background, why not have a main xlate that can perform the bulk of the work…the work that is the same for all downstreams.  That way if something needs to be changed for all, then you can go change it in that main xlate.  Then have a second xlate that is designed for each downstream system where needed.  This could elimate the need for possible multiple outbound tps procs.

Tom Rioux

Topic

[Max Drown (Infor)]

I’m pretty sure they have this under development or plan to in the near future.

-- Max Drown (Infor)

[James Cobane]

If I understand the proposal correctly, you would like to be able to run translations in serial, i.e. the inbound goes through xlate1, then the output from xlate1 goes through xlate2, correct?  As you know, you can accomplish this by setting up a couple of sets of threads:

inbound1 –xlate1–> outbound1  ….. inbound2 –xlate2–> outbound2

                                                                          –xlate3–> outbound3

                                                                          –xlate4–> outbound4

                                                         ……….      

                                                                          –xlate(n)–> outbound(n)

where outbound1 is localhost connection to inbound2.

    With that said, one consideration is that creating a “normalized” transaction is fine and dandy until outbound2 now needs data that was never supplied in the Xlate to outbound1.  You now modify xlate1 and have to test xlate2, xlate3, xlate4, etc to make sure nothing broke.

    We take the approach to map the raw/native inbound to the desired outbound for each system.  That way if system A now wants something different, we are only effecting system A’s Xlates.  We had some previous configurations that were utilizing a “normalized” HL7, and then when one of the systems wanted something that wasn’t in the “normalized” HL7 layout, we had to go back re-test all of the other systems for potential impact.  We have since re-worked the interfaces that used the normalized transaction to map directly from the actual inbound layout to the desired outbound layout.

Anyway that is just our approach.

Jim Cobane

Henry Ford Health

[Robert Milfajt]

True, but wouldn’t it be cool if you could have.

Inbound -> xlate1 -> xlate2 -> xlate3 -> … -> Outbound

Then you could have resuable xlates that do some component of work repeatable among multiple interfaces.

Thus you might have:

Inbound1 -> xlate1 -> xlate2 -> xlate3 ->Outbound1

Inbound1 -> xlate1 -> xlate4 -> xlate3 ->Outbound2

I favor the idea, just wonder how it would be pulled off.

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Author]

Replies