EDI Service Provider
What is an 834 Transaction Set and what does an EDI 834 File Contain?
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.
Also Read: Frequently Asked
Questions for Benefiting from Outsourcing EDI 834
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.
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
Also Read: How
Outsourcing EDI Solution Can Help You Overcome 834 Challenges?
- 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.
Conclusion
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.