Allow HL7 field to single outbound thread while removing for others

Yes, that’s what we’d do normally. But in this case, the “change” is that new data (inaccessible from elsewhere) will be coming from the source system, so it will be in every message.

Thanks,

Michael

I see, so the code for that would be something to the effect of:

#Get the destination
set n [msgmetaget $mh DESTCONN]

#If destination is not the one that needs the customization…
if ![cequal $n “name_of_destination_to_allow_new_val”] {
#Code to blank out IN1.15 and then continue the message
} else {
#Continue the message without blanking out IN1.15
}

Then I’d have to figure out at what point to place the code for it to be effective, but this is something to think about. Thanks!

Ah! I like this idea. It’s kind of non-standard but then so is our methodology!

We rarely use and never *set* metadata in our normal day-to-day operations, but I think this will work. I can place this on the IB tab, then use a proc on the route of the single destination to pull it out.

Thanks a lot!

That would be the way we’d normally do it. But this ADT feeds about 50 threads, so I wanted to avoid having to put a translation on the other 49 to null it out.

Although now that you mention it, surely there’s a way to reconfigure my routes to allow for this. But you can only have one static route on each inbound thread, right?

I don’t doubt there’s something more obvious that I am overlooking with routes. But we have never used anything but a single static route with TCL scripts on each route detail.

Thanks!

When I create a static raw route, it names the route “_HCI_STATIC_ROUTE_”. If I try to create another one, it defaults to that same name, and gives me an error “…’_HCI_STATIC_ROUTE_’ already exists for this thread…“.

I can think of at least one way around this, maybe by using wild cards in a defined TRXID route, but on further contemplation it really that wouldn’t matter anyway for what I’m trying to do here.

Thanks,

Michael