Allow HL7 field to single outbound thread while removing for others

[Michael Burrows]

Hello,

I have a vendor who is looking for a nonstandard value in an HL7 ADT field from our EMR. Specifically, they want us to send “subscriber name if different” in IN1.15 (typically unused, but defined as “Plan Type”). We plan to ask the source EMR to customize the HL7 feed to include this info.

The tricky part is this:

The ADT coming from the EMR is sent to dozens of downstream systems. I want to allow the new IN1.15 value to go to the single system that is requesting it, while removing that value for every other destination, just to be sure we avoid any issues in those systems.

Our overall filtering and formatting methodology is to use TCL procs on raw routes; we never use Xlates or HL7 Variants.

We use a single Static Route with Raw Route Details to each destination system. On each raw route, we will place TCL procs for any customizations the destination system needs.

I know that I can use a simple TCL proc to remove the value for every other downstream system, but I don’t want to have to put that on every single route detail. I’d rather have some kind of process that blocks the value for every destination *except* the one that needs the custom value.

This seems pretty basic, but I can’t figure out how exactly to accomplish it. I’m sure I’m overlooking something simple. (I blame our possibly outdated approach of using TCL combined with raw routes and never even trying to do it any other way. I haven’t done an Xlate since my training in 2012.)

Any ideas? Thanks in advance.

Attachments:

You must be logged in to view attached files.

Topic

[Jeff Dinsmore]

Perhaps you could just leave the EMR’s ADT feed as it is and make the IN1-15 change for the one system that requires it.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Michael Burrows]

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

[Keith McLeod]

Another thought would be to only allow this for the desired destination using metadata.  I know in the translate it used code like this.

xpmmetaget $xlateId DESTCONN

I would suspect it would be something like

msgmetaget  $mh DESTCONN

and using the logic to allow or not allow this….

[Michael Burrows]

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!

[Jim Kosloskey]

You could contact the receiving systems and find out if this is an issue. You may find none of the systems (other than the known one) care or at least reduce the set.

One way, although kludgy, might be to null that element out in a TPS IB Proc then add it back for only those systems that want it in a pre proc. The value in the element could be placed in USERDATA Metadata field before it is nulled that way the pre procs would not need to know what the value is (in case the value is changed in the future) they would just use the value in the USERDATA.

 

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Michael Burrows]

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!

[Charlie Bursell]

Why not simply have two translation files, one that would null out the field and other would not.  Am I I overlooking something here?

[Michael Burrows]

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!

[Jim Kosloskey]

You can have multiple routes for an IB Thread.

 

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Michael Burrows]

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

[Author]

Replies