Epic Resolute Correspondence Workflow

[Christina_Fisch]

Hello,

We are looking to improve our Billing Resolute Correspondence Workflow.  It is currently setup to export a daily file to Epic.  Our users have reported the following:

• The documents always go to the primary insurance bucket and they have to manually move it to the secondary insurance bucket.
• Sometimes the documents don’t even cross. There isn’t a good way to track import errors.

There has been some discussion about having someone manually create the correspondence file in Epic and attaching the document handle that way .  We have also looked at using Doc Pop.  The problem with Doc Pop is we are unable to figure out how to notify the biller they have correspondence to work.

What are other sites doing?

Thank you

Christina

[#2]

Hello Christina, 

These are issues I have heard from many other Hyland/Epic customers. 

There are ways to remedy the primary bucket issue. But requires some change in approach. 

To make sure that the document files to the correct insurnace bucket, the only way to insure that is you either populate the Epic Invoice number or the Epic BucketID from Onbase to Epic. That will ensure that it files to the correct invoice/bucket. But its a double edged sword, because you may not have that information in your HAR autofill in OnBase and have to do manual entry which is not ideal. 

The way i worked around this problem is the following. Luckily we use an outside vendor to scan our images and I take the index files and the images from that vendor and DIP the images to Onbase. I required the vendor to provide us with the Invoice number from Epic Resolute HB or PB on the doc types where it makes sense to ensure that they file to the correct bucket. And they send that to me. In the OnBase to Epic import process if you provide the Invoice number, Epic will file the correspondence to the correct bucket. 

If INV # not the Epic default logic is that it will file to the first Active Insurance bucket with non-zero balance that is not closed, cancelled or voided. 

Secondly, your epic team can send a email with today's errors by using an Reporting workbench template for daily errors.

email me ediz@evetsolutions.co for additional questions. 

[Michelle_Troxel]

Hi Christina,

     We have DocPop and my customers tell me it doesn't work consistently. However I'm unable to reproduce the issues they have. Caveat - we have 2 app/web servers that are load balanced and I think that plays a part. Also with that, we have 2 autofills - one for DocPop CQV (combined query viewer) and one for the HAR autofill for indexing. We get our autofill from ADT so if they split a bill on the EPIC side, we don't have that new HAR in OnBase. Then they manually index those but the documents don't show up in the DocPop viewer since they weren't sent over to populate the autofill. I saw there was an option to do a DCS record for these instead of the correspondence file so maybe that is the better way to go. The link to the document would be in EPIC and you wouldn't depend on the autofill part to pull the documents. We've only done DCS records for chartview so far. I'm unclear how that works with the workqueues though.

    I'm just now working on the correspondence file to go to EPIC for HB. I appreciate your question so I can give them a heads up on the insurance part. 

    We receive image files from a vendor as well but I have not seen an EPIC INV# in those files for HB. Interesting thought, thanks Ediz!

   I would be interested in your progress on this!

Michelle

[David_Juhlin]

We are implementing a new 'Correspondence Entry' workflow (working with Hyland Services) that will create the files for us.  We mapped the various Doc Types to Epic work queue types so that the documents go to the right queues in Epic.  (We use an AFKS that allows us to post the appropriate Epic Queue number based on the Doc Type.)  We are still working out how to identify/review load errors.  We are trying to minimize those through edits in our Life Cycle (validate HAR/EAR, etc.) and leave the documents in an OnBase queue for review.  (Once 'fixed', we run the document back through the edits, and if it passes then we write the record to create the link.)

[Michelle_Wolfe1]

So, this post is a year old, and you all have hopefully been live for a bit and might have some words of wisdom for me.

@Ediz Tufekcioglu  - do you know which RWB report was used to send the errors / skips when Epic processes the Context files?  I've seen some mention on the Epic User web about needing reconciliation process due to the issues of not being able to create a correspondence record with voided invoices.  Based on your comment you also can't create a correspondence record to closed or cancelled.  I understand why you might not be able to create to a cancelled invoice. It's somewhat like void.  But closed too?  Do you know if this applies to both PB and HB? 

I wish Epic had the common issues and considerations spelled out in the Support / Admin Guide vs making their customers and staff recreate the wheel each time. Our project's AM and AC can't find much on a reconciliation process need within the Epic internal resources.  Luckily we are just setting this up and have time to pivot some things as needed.

Our scope includes:

We have correspondence linking to EAR, HAR (mainly HB), and INV (PB only).  

• We are also using the EOB rendering of an 835 in OnBase (tole they need to match to an INV)
• Currently our HAR AFKS is being populated by HL7, but the HL7 doesn't have any INV information, so as of now it's missing an optional field to store the INV.
• The INV AFKS is being populated with daily RWB PB and HB CLP/INV extracts for yesterday's accepted claims.

After reading this thread, I'm thinking that we might want to use the HB INV Extract to also update the HAR AFKS.  This would allow an indexer to use a secondary keyword of the invoice number, and still send the context as the HAR.  If there's not an match for the INV, then they could use just the plain HAR match that the HL7 message created.

Has anyone considered doing a secondary export for INV/CLPs for when their status is updated to a "bad" status, where Epic would skip the record if included in the context file?  Assume you store the Invoice status as a field in the AFKS in OnBase.  Then:

1. Epic to generate a daily RWB extract for INV/CLP update to include when claim status changes to a "bad" status.
2. OnBase updates existing record in AFKS table, changing the status from Accepted to the "bad" status (Closed, Void, Canceled). 
3. Depending on the options available in OnBase, exclude these records from being used to match with new images needing to be indexed.  Or, somehow highlight the status field and / or prevent the index to save when the status is a "bad" status.  I'm not familiar with the edits in a Lifecycle but will ask our OnBase technical person about this option.

There are several assumptions with this approach but is something I'm trying to work out to prevent as many skips / errors occurring during the correspondence batch job.