Table of Contents
- Brief History of EDI 834
- Defining EDI Benefit Enrollment and Maintenance
- What makes a Benefits Enrollment and Maintenance Document?
- How is EDI 834 Processed and Used?
- EDI 834 Specifications and Format
- Healthcare EDI Solutions
- Challenges with EDI 834 Processing
- X12 EDI 834 Mapping & Translation
When thinking of a private health insurance exchange, you just think of a marketplace full of options. But that’s not it! There is a lot of work that goes behind the curtains, such as enrollment files, member maintenance files, plan data, billing data, and rating data.
This article focuses on the standard way to exchange the enrollment data via ASC and HIPAA EDI 834 – Benefit Enrollment and Maintenance File format.
Brief History of EDI 834
The question that comes to mind is, why do we use certain file formats when we have common protocols like XML? To answer this, let us go back to EDI 834’s inception.
EDI 834 came in 1991, with the formation of the Workgroup for Electronic Data Interchange (WEDI). The very next year, EDI standard sets were dictated to be adopted by the American National Standards Institute (ANSI). Most health insurance carriers follow the set format and accept the 834 formats for delivering health insurance enrollment and maintenance data.
Defining EDI Benefit Enrollment and Maintenance
EDI 834 is a transaction set representing the Benefits Enrollment and Maintenance document. This transaction set is used by employers, government agencies, enrolling members, insurance agencies, union agencies, and others included in a healthcare benefits plan.
EDI 834 establishes a seamless communication between the sponsor of an insurance product and the payer. To clarify, a sponsor is a party that pays for the benefits plan, and the payer (insurance company) administers the insurance product.
Not to mention, that the EDI 834 file format was specified by the HIPAA 5010 standard for electronic exchange. Other than new enrollments and plan subscriptions, 834 transactions may be used for –
- Changes in any member’s enrollment.
- Reinstating a member’s benefits enrollment.
- Disenrollment of any member (termination of plan membership).
What makes a Benefits Enrollment and Maintenance Document?
The EDI 834 file is organized into segments and data elements, where data elements contain a data field while the segment contains one data element.
Within a data element – you will find the date of transaction, type of insurance plan, premium amount, as well as coverage details. However, EDI 834 offers multiple avenues for the company to use the format and include data within.
How is EDI 834 Processed and Used?
The entire process of EDI solutions starts from receiving the EDI documents into a system – be it accounting or ERP. Every trading partner using EDI has a guide manual for its implementation outlining specific segments, values accepted, applicable business rules, and data elements that are followed.
The EDI document is received by the insurance sponsor, and as soon as the document is received, an acknowledgment – 997 Functional Acknowledgement – is sent to the receiver to indicate successful accrued.
The EDI format has a standard meaning of all record types and properties, which have information classified in a way that may differ from carrier to carrier. So, a file configured by UnitedHealth can be sent to many insurance providers or carriers. The health insurance data can further be segregated into dental plans or medical plans.
Utilized EDI for healthcare includes different benefits plans and insurance types communicated, inclusive of short-term disability and long-term disability. Usually, a carrier requires different information or a modified version of an 834-file format. It is also necessary that 834 is accepted by the law.
EDI 834 Specifications and Format
As aforementioned, the transaction set establishes the communication between the sponsor and the payer of an insured product. The sponsor can be an employer, union, association, government agency, or other who pays for the coverage, whereas the payer can be an insurance company, health maintenance organization (HMO), preferred provider organization (PPO), agency (Medicare, Medicaid, Champus & more) or a contracted entity who pays for the claims and administers the coverage or product or a benefit.
Note: Remember that EDI 834 transactions may not take place through a third-party administrator. However, a TPA can be contracted by the sponsor to handle covered data gathering.
Below is the EDI 834 format defined and used by most EDI managed services providers.
ISA’01*0000000000-01-0000000000*ZZ ABCDEFGHIJKLMNOʻZZ*123456789012345 101127*1719*U*00400*000003438*0*P”>
N1 P5 COMPAN_NAME FI”000000000
NM1’IL 1 JOHN DOE’R”*34*1’0000000
N3’123 SAMPLE RD
DMG D8 19690101 F
Creating a benefits enrollment can be done manually into the standard EDI document or pulling out information from data B2B EDI integration from the in-house managed providers.
With automated EDI, creating and sending the information becomes even faster. The EDI translator converts the data received into 834 documents while meeting the strict guidelines set by ANSI X12 EDI standards.
Healthcare EDI Solutions
A flexible and modern EDI supports all EDI communications methods for the payer and the receiver to seamlessly share valuable data with absolute security despite changing industry standards and trends. As EDI solutions have accelerated and been adopted, most EDI providers use advanced solutions to communicate or transmit data, like –
- Cloud based EDI
- On-premise EDI
- Hosted EDI
- Off-premise EDI
- Strategy Consultation
- HIPAA Compliance
- EDI Assessment
- Process Automation
- EDI Van Services
Challenges with EDI 834 Processing
- Continuous human intervention sometimes leads to errors.
- Many companies have experienced EDI 834 approaches as a black box, making it difficult to enable custom enrollment policies and rules in the software.
- Tedious and complicated monthly file processing in bulk, especially during the open enrollment period.
- Time is wasted to eliminate the invalid or corrupt formatted files during the intake of the process.
- Files, such as transaction type and member record, that are logically out of order lead to inaccuracies in membership records.
- EDI services providers not adhering to the ANSI and HIPAA standards and rules leads to variations in data.
- Only when an entire EDI 834 membership snapshot files are shared for processing only then the software logic determines the delta transactions.
The benefits of integrating EDI systems eliminate the typical process of faxing paper enrollment forms to carriers or inputting the enrollment data manually into the carrier’s website. The automated method today is more secure and accurate, eliminating the misinterpretation of manual data entry.
X12 EDI 834 Mapping & Translation
Modern EDI solution providers, like A3logics, offer end-to-end EDI solutions consisting of EDI mapping and translations, secure methods of file transmission with partners, and backend integration to simplify the transformation flows.
EDI 834, explained as Benefits Enrollment and Maintenance contains information of the payer, sponsor, and the member involved in offering a benefits product. This transaction set is commonly used by insurance agencies, government agencies, unions, and employers to enroll their staff members in employee benefits administration solutions. Recently, it is most widely used in the Healthcare Industry, following the specific HIPAA 5010 standards for electronic data exchange, such as plan subscription, benefits, employee demographics information, and much more.
EDI 834 is also the backbone of the enrollment and maintenance transaction between insurers and federal and state exchanges. In order to change or replace the 834 formats, Congress has to introduce a new standard. Seeing that government agencies have many priorities and any regulation requires re-configuring all state and federal exchanges, we expect 834 to stay for a very long time.