Transactions Per Second Alert

I haven’t setup this type of an alert either but taking a guess at what I see in your screen shots that you say are working, I would try adjusting the “compare >= 12”.

My guess is that 60/12=5 messages per second is when your alert gets triggered the way it is right now, which is greater then 4 messages per second.

So if that is true, then setting “compare >= 10” might cause the alert to be triggered at 60/10=6 messages per second average over a 1 minute period.

Since we are going to Epic ourselves it is good to hear they can do better than our minimum requirement of 3 messages per second.

Our fastest interfaces have hit as high as 150 messages per second and half that is not uncommon on a steady basis during peak hours.

I can’t imagine having to deal with a situation where 4 messages per second is too fast because that is where I start to think of it as barely being fast enough.

I’m curious about what action you take when you get a cloverleaf alert that messages from Epic are being generated at a rate of more than your desired threshold of 4 messages per second?

In other words, how do you respond to an alert like this?

Sorry to hear Epic sends a batch of message via real-time interface.

As we know real-time is just that and is challenged when sent a large burst of messages.

I have that probem with pharmacy system (Centricity) that sends a huge batch burst of messages around 5 AM each morning and it takes 20 minutes for downstream Pyxis system to catch up.

Knowing this we just adjusted our alerts to be less reesponsive during this known window, but it does put stress on the integration during that time window.

I’m also sad to hear that looking at a patient in EPIC wihtout making any change creates A08.

We have that problem with our current HIS system and is a tremendous souce of overconsuming cloverleaf unecessarily.

Do the A08’s generated by EPIC at least populate all the fields for every A08 which could let us do some filtering?

With our currnet HIS it only popluates A08 fields that might of changed and most of the fields are empty, preventing us from doing any filtering.

I will at least know to talk to the EPIC folks when we implement to ask if nothing changes don’t send an A08 and cross my fingers they can accomodate.

Bob,

Thanks for the clarification.

Do the A08’s generated by EPIC at least populate all the fields for every A08 which could let us do some filtering?

Not sure if this is controlled by the interface (profile variables) or a standard part of the interface, but the EVN segment has two pieces of data that may help in filtering.

In our implementation, EVN-3 contains the trigger that generated the message.  The batches, may have their own trigger ID for you to filter on, or the ability to set this trigger ID.  EVN-5 contains the user who triggered the event.  If your batch is run by a designated user, i.e., EMP record #1, EVN-7 might look like 1^EPIC^USER, again something you can filter on.

I would like to point out that any inbound ADT message also triggers outbound message(s), so that may be another source you can filter out.

Hope this helps,