Since founding MillsonJames in 2010, one of the most common topics we’ve fielded from our agency partners has centered on carrier interface files. Some call them EDI files, others refer to them as 834 files. However, the most common reference to these files typically comes with a preceding four-letter adjective. We’re guessing that you’ve probably been in the middle of a finger pointing session with a carrier and benefits admin company. You know the scenario — one blames the other and you often are called upon to be the referee in a game where you don’t fully understand all of the rules. While these files are generally considered the Achilles Heel of our industry, there are steps you can take to help ensure that your clients don’t feel the pain from these mysterious files. Our hope is that we can begin to demystify these files and provide you with insight and guidance to ensure a smoother implementation and utilization of these critical file feeds. We’ll start with a general overview – an EDI 101 class if you will. It all starts with the Health Insurance Portability and Accountability Act (HIPAA). HIPAA requires that all health plans or health insurance carriers accept a “standard” enrollment format, ANSI 834A, Version 5010 from enrollment and eligibility vendors. It is within these files that a benefits administration system communicates enrollment and eligibility information to a carrier, notifying them that John Doe elected a benefit, providing his personal information, appropriate benefit grouping and plan election data, as well as communicating dependent enrollment and indicative data. Sounds pretty straight forward, right?!?! It isn’t. Trust me. To the naked eye, a standard file that contains common information should be pretty simple to produce and manage. To be honest, the use of the term “standard” may be the root cause of 90% of all challenges experienced. You see, there is absolutely nothing standard about the standard enrollment format set forth by HIPAA. I liken it to God’s creation of mankind. Yes, there is generally a standard for each person: two eyes, two ears, a mouth, arms, legs, hair (some less than others)… However, no two people look alike. Not even close. This is very similar to the HIPAA 834 files. There is generally a standard that dictates the format of the files; however, each carrier establishes a “Companion Guide” that governs their particular nuances for their particular files. Within this Companion Guide, the carrier establishes File Format, Transmission Type, and Account Structure. The first two are relatively straight forward and can be knocked out pretty easily. It is the Account Structure that creates the web of variability. The Account Structure establishes the classes, plans, and plan types, and each employer’s data and structure differs from the next. There are a literally a multitude of variations of these structures and trying to standardize those variations can be like nailing jello to a wall. There are generally seven steps a benefits administration company takes when establishing an 834/EDI file. Five of these steps are pretty straight forward and do not require your involvement as a benefits agent. However, there are two steps where you must insert yourself to dramatically improve the success rate for your clients when implementing an 834/EDI file.

1. Client selects Carrier & requests data feed be established
2. Ben Admin contacts Carrier to initiate
3. Ben Admin & Carrier complete Companion Guide
4. Ben Admin programs format
5. Ben Admin tests format with Carrier
6. Ben Admin loads & tests data with Carrier
7. Ben Admin sends production files

The two key steps for you to jump in and get involved are steps #2 and #6. As silly as it sounds, Step #2 is among the most frustrating and time consuming steps within the EDI setup process. There have been countless times when wheels spin unnecessarily at step 2 and weeks (and sometimes months) go by without the appropriate parties connecting. At the root of this challenge is the fact that carriers are massive organizations that are dealing with hundreds of thousands of customers and tons of red tape. It has been our experience that when a broker gets involved initially to drive the introduction of players, ensures that the broker’s carrier sales rep helps find the right person inside the carrier EDI team, and connects the parties, the implementation goes much smoother. Carriers react much quicker and more thoroughly to a broker and/or client than they will a random benefits administration company, with whom they have zero accountability. We have found that it also helps to have a translator involved — someone that can help speak the language between benefits and the EDI developers. MillsonJames has played this role for many of our agencies and it has been helpful to involve someone that can bridge the gap sooner than later. So…get involved upfront and save yourself pain on the back-end (in more ways than one). The other critical step is Step #6. Once the file specs have been validated (Companion Guide) and the file formats have been initially tested, the real fun begins. The degree of fun depends on how clean an employer’s data is and this is where you can also help. You can help prep the client by setting the expectation that the cleaner the data, the smoother the process. For example, if Company Location/Department is a key component of an employer’s Account Structure, then ensuring the Location data inside the ben admin system is clean and accurate will go a long, long way to ensuring success with the EDI files. Equally as important is the need to ensure someone has reconciled the two systems before moving files to production. If the data resident on the two databases about to be tied together (carrier and ben admin) is out of sync, the production load will likely lead to production errors. So, the old adage of an ounce of prevention (clean data) is worth a pound of cure certainly applies here. For too long, brokers have tried to distance themselves from this seemingly unknown and convoluted process. The results have, unfortunately, been predictable: dissatisfied clients, rocky relationships with ben admin vendors and carriers, short-lived relationships with these vendors, and, even worse, employees with incorrect coverage or no coverage because of an incorrect EDI file. Our encouragement is for you, acting as the trusted adviser for a client, to jump into the middle of this process, educate yourselves on the details of the above seven steps, and help guide the process. It isn’t rocket science, but it does require diligence and a dedicated focus within an agency. At MillsonJames, we can assist you in helping demystify this historically confusing process and help ensure a much higher degree of success in implementing these files for your clients.