Killing nearly duplicate A31s

[Mike Strout]

We are an Epic shop and as those of you who have taken an Epic ADT feed know, it is very chatty, especially with A31s, which I calculated yesterday account for 61% of our ADT traffic. Epic has some filters to kill off some of them, but until we upgrade to 2014 late this year, we can’t take advantage of the last one that will make the biggest difference.

Here is the deal with Epic. Everytime it sends an A08, it also sends an A31 for each guarantor on the patient’s account, typically all one after the next. The downstream system that is struggling to keep up with all these message doesn’t care about GT1, so I was thinking about strategies to kill some of these A31s.

I was considering using a pre-proc that does the following…

1. compare the contents of a file to the message with the MSH, EVN and GT1 segments stripped.

2. If they are the same, kill the message.

3. If they aren’t the same, replace the message in the file with the new message, minus the stripped segments.

I am concerned that the comparison of the two message would slow and resource intensive.

Thoughts?

Mike

<><

Topic

[James Cobane]

Mike,

We are on Epic 2012 and have the profile variable ‘SEND_ALL_ACCOUNTS’ set to ‘4-Send Visit Account Without Additional A31s’.  This reduced the amount of A31s by a substantial amount.  Not sure if this is one of the filters you already have in place.

Jim Cobane

Henry Ford Health

[Keith McLeod]

On Epic, We set the same profile variable as James, but set it to 0 ‘Only send the Active Accounts’.

We went from ADT_A31’s being nearly 80% of the ADT message volume down to less than 20%.

This made a major difference.  

One other note is that when any kind of EPIC backfills are perform, there is a flag(You will have to check on which) that does not cause ADT_A31 messages to be sent for each record imported.  This can bury your engine by having 100s of thousands of messages A31’s all sent at once..

[Mike Strout]

Thanks guys for your comments. Sadly, we are still on Epic 2010 for another 6 months. We have SEND_ALL_ACCOUNTS set to 3 right now, because 4 isn’t an option. I will have to look at option 0.

Thanks for the note on the backfills. We learned from that one the hard way a while back when an expiration date was changed on a registration form, causing a triggering of an A31 for every patient ever seen. DOH.

Assuming the SEND_ALL_ACCOUNTS needs to be set as it is, any thoughts on the strategy in my previous email?

Mike

Trinity Mother Frances

Hospitals and Clinics

<

[Elisha Gould]

I’ve recently done this for webPAS A31 messages.

The way we did it here was:

set up a sqlite database with message type, patient id, date, and message columns.

Strip the MSH/EVN segments off.

Select the patient id message from the database.

   If non insert the stripped message

   otherwise compare the message

       If it matches delete the message

       otherwise update the database with the new message and details, then continue the message.

I also set up a upoc thread that runs daily to deletes data from the database that is older than 48 hours. This means there can be another duplicate message sent through after that point, but it’ll be another 48 hours before another one comes through.

For us this reduces our file io and processing considerably as well, as the message is blocked before routing to the translations for each of the applications. So instead of processing the message 100+ times it is processing and removing it once.

[Robert Milfajt]

Epic has a standard programming point to stop sending these duplicate messages, and reduce the “noise”.  We’re 2010, going to 2014 and have this set (of course I recommend running this by your Epic Bridges TS, standard Epic disclaimer).

PRE_MSG_SEND = d skip^ASROTR1(“MSH,EVN”,””,1)

The message shows up in Bridges queue, but has status “S” or that it was skipped and not sent out the interface.  This code is very similar to your idea of writing pre-proc code, but done in Epic.  Also you would add GT1 to the list of segments above to implement your idea as you stated it.

Hope this helps,

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Author]

Replies