Get on a Roll with the Epic Enrollment Filer

Solve (some of) your enrollment file problems by transitioning to the Enrollment Filer

Enrollment files are the fundamental basis of business for any health plan. Eligibility files from different payers can vary widely in quality, have different formats, and each file has their unique quirks and special data needs. Epic‘s Enrollment Filer is a flexible tool that will allow organizations to ingest and clean up the data at the same time, but getting started with a transition to the filer can be a daunting task. Use this guide to make the move as seamless and painless as possible.

Put the Fun in Functional

Epic has recently announced that most customers will need to transition to the Enrollment Filer with an upgrade to Epic version May ’25. Some organizations have been using the batch load process for dozens of years, so this can be a daunting task. Here are some initial questions to ask that can help you get off on the right foot. 

1. Do we need to continue to use a third party pre-load scrubber?
   • Many organizations have a clearinghouse or pre-Epic scrubber that can make the enrollment data a little friendlier before loading into the system. Tapestry can now take on most of that pre-load scrubbing by itself, but that doesn’t mean it has to. If you are satisfied with the pre-load scrubbing you are already doing, you can load those files directly in the system with minimal additional configuration. However, getting rid of a third party system can save time and money down the road, and the ROI on ending a contract could offset the costs of getting started on the enrollment filer. 
2. Who will be resolving the staging area codes that result from the file loads?
   • Even if a file is the cleanest it can be prior to loading, there will still likely be discrepancies between the file data and the system data that need to be reviewed and reconciled. For example, address and other demographic differences are very common and usually need review in order to resolve. Discussions should take place to determine which team or teams will be working those errors/warnings and resolving them. Additionally, there are still also going to be transactions that only IT can address – things like missing employer groups, data validation errors, or group and plan mismatches are not uncommon. 
3. What frustrations exist today that could be addressed by moving to the enrollment filer?
   • Part of the enrollment filer functionality is the ability to add rule-based staging area codes to any transaction that meets the rule’s criteria. For example, a rule could be created to flag all transactions for newborns to make sure they are matching to the correct patient record. Or, perhaps someone always sends dates with strange delimiters – the filer can handle it! Alternatively, it’s common and easy to flag and track members who are missing PCPs for plans that require PCP assignment. If there are any enrollment functions that take time to address and are hard to pin down, the right configuration in the enrollment filer can make that better. 
4. Is there special processing that takes place on any incoming enrollment file before it gets loaded into Epic today?
   • Payers sometimes send files with data that makes no sense, or data that is not in a format that is easily readable by the system. Take note of any special processing that is done on incoming files today so that similar processing can be built out or accommodated in the filer if necessary.
5. Can system build be re-used?
   • Absolutely! If a payer sends multiple files in the same format, it is very possible to re-use filer build between the different files. AIR records can be shared between batch type definitions, and scrubbing actions can be re-used or shared at the enrollment customer profile level or the batch type level. Shared build saves time and effort, and can make future maintenance easier. 

But, how?

It’s as easy as 1-2-3! Seriously, transitioning to enrollment filer can be relatively painless as long as the right steps are followed.

1. Plan
   • Get the right people involved, and start early.
     • Identify operational stakeholders, and particularly leadership and super users who will be reviewing testing results and potentially even doing some of the testing themselves. Workqueues and new workflows need to be designed, so involving operational managers is important.
     • Be sure to involve any BI users or who work on pre-scrubbing or downstream workflows pre-filer to ensure everyone understands the scope of the work. There may be some additional changes to the data model that BI users need to account for in downstream extracts.
   • Decide on where the changes need to be made. Since the enrollment filer is so flexible, settings can be different at multiple  levels of the enrollment process. The settings at the facility-level profile are likely to be a lot more general than the settings at the employer group or batch type level. Ops, leadership, and IT should collaborate to decide on the right settings at the right place. For example, certain payers may need IDs to generate in a specific way, which would happen at a lower-level like a batch type, but member matching identity configuration can likely live at the facility level.
   • Engage the right analysts who have experience using and building the enrollment filer, and make sure they’re informed about the specific quirks for any enrollment file processes or payer agreements. 
   • Decide on a timeline. Depending on the number of files, the complexity of the scrubbing, building out new batch type definitions, translation records, customer profiles, and scrubbing can take anywhere from days to weeks, so rely on your analyst’s estimate of build time but add some cushion to fix issues when things need adjusting during testing. The good news is that files can go live one at a time, so the files that need less attention can start getting loaded in production while others are still being worked on in lower environments. 
2. Build/Test
   • Functional testing: test the basic settings to make sure that the data is coming in correctly. Files should be processing and collecting warnings and errors in an appropriate fashion and not rejecting completely. Scrubbing should be reviewed to make sure that dates, IDs, and especially important member  information is being saved correctly to the transaction.
   • Operational testing: Operational testing is key to any Enrollment Filer project. They should review the transactions coming in from the files to make sure that the data matches what they see on the raw files, and that data saves into the system as designed. For example, address updates are applied from the file depending on the settings in the customer profile. Patients from the file are matched to the appropriate members in the system, and new members and coverages are correctly saved once the transaction is applied. 
   • Workflow/App testing: Performing workflows to make sure all of the cogs are working together seamlessly. For example, making sure that kicking off the file load batch job picks up the file and it runs through the enrollment filer, etc.
     • This is especially important for groups that have Medicare Advantage plans. Plan to run through the entire process from OEC>BEQ/BEQR/MARx/DTRR. The staging area codes that trigger for Medicare coverages are very different from those that trigger for commercial coverages, so reviewing those codes and ensuring the right codes trigger at the right points is crucial.
   • Parallel testing: Prior to launch, enrollment filer build should be moved to SUP or another patient data environment so that enrollment files can be loaded and compared in parallel to the same loads through the batch process in production. This will ensure that the number of errors in the enrollment filer is similar to the batch load for the same file in production, and that data saves and behaves the same way for both file loads. 
3. Launch
   • At go-live, files should load into the system in Compute Only mode, which means that the files will sit and wait to be committed. That gives the operational stakeholders a chance to review not only individual transactions, but the health of the file as a whole. 
   • Several weeks after go-live, once stakeholders and analysts are sure that the file processes are behaving as expected, files can be moved to Commit Clean, which will allow clean transactions to file immediately into the system and speed up the time between file load and getting new members into the system.

Analysts, assemble!

Any enrollment analyst who has kept up to date on their Epic certifications should be able to get started with this project. However, the scrubbing actions that may be required for complex enrollment processes are often tricky at first and it may be helpful to engage a consultant analyst with experience.

Canopii consultants are here to help you —acting as a true extension of your team. We ensure warm handoffs, clear knowledge transfer, and a seamless experience from start to finish. Let’s bring your project to life—together.

CONTACT US TO COLLABORATE!

---

This article was peer reviewed by Tapestry Enrollment & Eligibility expert, Emily Jacob, a seasoned Tapestry Analyst with over 12 years of experience in the Epic ecosystem. She spent seven years at Epic, where she developed deep expertise in the Tapestry module and its applications in managed care. Today, she leverages that knowledge to help healthcare organizations streamline operations and improve outcomes.