Cerner ADT Back Logs

[Robert Milfajt]

We are running Cloverleaf 6.0 on AIX, and feeding ADT data from Epic to Cerner.  We notice that when Cerner gets an A34 (merge) message; it sometimes takes a long time (up to an hour) to process that message.  For those who know Cerner, the ESI server keeps queuing, and even though we have multiple ESI servers to balance the load, the backlog can prevent ADT getting through and patient moves, etc. not available for inpatient orders/charting.

I’d like to hear about any experience anyone may have had with this type of issue, and what, if anything, you did to solve it.

That said, one possible solution we are kicking around is to send the merges (and any updates for those patient) to a separate interface on Cerner (and separate bank of ESI servers).  The thought would be to keep those MRN in a SQL Lite dB on Cloverleaf until such time as the patients we’ve sent to Cerner via this interface have been processed.  Not sure on the details of this, but assuming that is possible, I’d like to hear ideas on how to accomplish this routing, given that we currently only use _HCI_Static_Route_ for all ADT messages from Epic.

We could do this via trxID, and split off the Cerner ADT processing from the rest of the static routes, but is there a way to do this after the trxID and before sending by manipulating the metadata?  I’d like to hear any theories on how we might be able to accomplish this outside the trxID routing.

Thanks in advance,

Robert Milfajt
Northwestern Medicine
Chicago, IL

Topic

[Russ Ross]

We have Cerner ML and are switching from SMS to EPIC, so I’m curious if I might see a similar issue.

Is it known what is causing a single A34 to take one hour to process in Cerner ML and does that mean it takes one hour to ACK that A34?

Russ Ross
RussRoss318@gmail.com

[Robert Milfajt]

If you have two patients, one with many visits and a lot of data (clinical events), and the A34 is merging the patient with all that data into the other patient, then the movement of that data (updating all the Cerner tables) takes forever, as their database is quite flat, and they update all the pointers to the patient table in all the clinical events and encounters table entries.

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Tim Pancost]

Welcome to the joys of Cerner!  🙂   We’ve been dealing with this “feature” for years.  What we’ve found is that the combine is almost always actually completed, it just doesn’t seem to get back to the ESI server to tell it so.  So we will stop the ESI, remove the message from the queue, and start the ESI back up.  We’ll then go into PowerChart to confirm that the combine actually did complete.  It almost always has.  If not, we send the message to our Person Management team, and they perform the combine manually in HNA Combine.

As far as minimizing/eliminating the issue, we have yet to find a complete solution.  You have to be VERY careful about routing combines to another set of ESI servers.  ‘Cause if another message comes in for that patient on the “regular” ESI’s while the combine is going on, you can end up in a database deadlock condition, and it can affect the entire domain.  That’s the voice of experience, BTW…   😥   What we have done is implement what Cerner calls “Reverse Combines”, where they reverse what person row is kept.  This helps minimize the processing for “regular” combines.  

The caveat to this solution is that it makes “active” combines take longer.  We call an “active” combine one where the surviving record has an active encounter attached to it.  Normally, we only combine records that have no active encounters.  This allows us to generally keep the “older” record as the survivor, as it usually has more encounters associated with it.  An example of an active combine would be where a Jane/John Doe comes into the ER, and so has to be entered as a new patient.  When they are subsequently identified, and already have a record in the database, the clinicians want all the information together.  Since the ER visit is still active, that person row has to be kept as the survivor, and all the visits from the “old” record have to be moved over.  Sometimes, this can be in the dozens or even hundreds!

When we were making the decision to move to the reverse combine, it was felt that “regular” combines were the most prominent, so we would be getting the most “bang for our buck” by using the reverse combine.  What we’ve found, though, over the past few years is that the clinicians are getting much more comfortable with and reliant on the EHR, so are making more and more requests for “active” combines, so we’re starting to see an uptick in the number of ESI backups.

HTH,

TIM

Tim Pancost

Trinity Information Services

Tim Pancost
Trinity Health

[Robert Milfajt]

Thank you Tim.  This was quite helpful and timely.  We considered putting in a dB table to keep track of MRNs we sent to the merge processing, so we could route other patient updates to that thread.  We would truncate that dB when we could prove all the merge ESI servers had 0 queue depth.  We have a meeting this afternoon to discuss options, and my #1 option has always been ignore merges and send report to Medical Records to combine manually.

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Anonymous]

Our HIMS uses a two step process to avoid long ESI processing times on combines. It typically goes like this for the scenario where they want to

[Author]

Replies