"Sub" CSNs and document indexing

[Amy_Lupkes]

Looking for some help or direction.  With Epic we have an admission CSN and then we have, what we are calling "sub" CSNs, that roll up to the admission CSN.  Any document that is indexed to the "sub" CSN errors out in the Epic Interface.  We have end users manually selecting these CSNs as they are just choosing one, but we also have barcoding picking up the "sub" CSN off of the patient labels that are used for that area.

We are wondering if there is a recommended set up or how other Epic organizations are handling these.   Are you preventing the "sub" CSNs from coming into OnBase?  Then all the barcoded documents will fail?  Do you allow scanning to all CSN's?  How did that set up look?  We have received conflicting information from our Interface team about this. 

We are working roughly 1,000 interface errors per month and the majority are sub CSN related.  Any help is extremely appreciated!

[#2]

We use perceptive - in general we try to not muddy up the waters with the "Sub CSN" and always go with the primary CSN. You might coordinate with your bridges/ HL7 interface engine to do a couple of things different. One thing is to only send the primary CSN in the interface....suppress the SUB CSN... The sub CSN is required for some apps. There is a good article in EPIC that covers EPICS crazy account # situation. Hope it helps a little bit. 

[Amy_Lupkes]

Thanks Adam - That was our initial thoughts too, but with so many documents having the sub CSN bar code label on them, it made us reconsider since we were unsure if those will all fail in barcode processing, increasing the manual indexing for the HIM users which would not go over well.

[Joshua_Schultz1]

Hi Amy,

Is the "CSN" your primary value for the auto fills on your documents?

We use Barcode Labels that have the CSN in the barcode printed from Epic, this can be a problem because if the users printed labels from a visit that isn't the primary CSN that was admitted, we may not have Auto fill rows for the redirected/related encounters. Since we have CSN as our primary keyword that triggers auto fill completion, we solved this with an SIU interface from Epic to OnBase for our hospitals. It added a sizeable volume of HL7 to OnBase, but we get check in messages now for appointments, so we have all the CSN rows in our AFKWS. Another option we explored was changing the check in trigger in Epic to send ADT messages out, but that was a more significant Epic change that could have affected other systems outside of OnBase.

We also reviewed having have label print group updated so the CSN doesn't pull from the current encounter but rather from the primary encounter, I guess Epic has smarttext/print groups that can support this.

Alternatively perhaps this could be fixed in Epic via workflow, having users print labels from the primary encounter if that CSN is the one you want everything to file too. This would take training to use a census, or patient station to find the encounter and print the labels.