Purpose

In a typical health care model, there is an insurance company (“payer”) in between a hospital (“provider”) and an employer (“sponsor”). The payer is a healthcare organization that pays claims and administers insurance or benefit product. The sponsor buys the health benefit product from the payer for its employees. That means the employees become members and eligible to go to hospital when they need care. The providers are paid by the payer for the service provided to their members.

The healthcare related EDI 834 transaction set is used by a sponsor (employers, unions, government agencies) to enroll members to a payer program. Examples of payers include an insurance company, a health maintenance organization (HMO), a preferred provider organization (PPO), and government agencies (Medicaid, Medicare, etc.).

This transaction is used to

EDI 834 is a broad standard developed to accommodate a large variety of practices among many different types of payers. In order to use this generic standard to its practical needs, each payer has its own companion guide which is a tailored version of the standard. It is important to follow the companion guide of that payer carefully while exchanging 834 formatted data for that payer.

Format

In EDI 834 enrollment related information is organized in a hierarchical way as shown below.

Looking at the listing above, it is easy to see that there are 3 levels of hierarchies in 834. The first level information in Table 1 encompasses the entire transaction (between ST and SE segments). The second level loop is for member specific information and the third level loop is for one or more health coverage data blocks for each member.

Features

During implementation, we need to consider the following important features about the EDI 834 standard document.

Incremental Update, Complete Audit, or Complete Replace

The 834 transaction set is used mainly for the following 3 purposes and they represent high level use cases for transactions. In the first use case, it is used to enroll, terminate, or change the membership and health coverage. This is the most common use of the 834 transaction. It is identified by making BGN08 value to be 2. The second use case is to send information about all active members for auditing purpose. This is identified by making BGN08 value to be 4. The third use case is to replace all active member information for the purpose of syncing between the databases of sponsors and payers. This is identified by making BGN08 value to be RX, with RX meaning replacement. Note that the second and the third uses can produce very similar 834 documents, but only in the third use case (synching) the information sent can be used by payer system to change its database. For any given EDI document (transaction), there will be only one type of transaction happening because there will be one instance of BGN segment per document.

Insurance Information

The question is where should we show insurance related information like policy number, group number, etc.?

In 834, insurance related information can be expressed in all 3 levels of hierarchies, depending upon need. There is an REF segment (Transaction Set Policy Number) at position 0300 on Table 1, another REF segment (Member Policy Number) at position 0200 in Loop ID-2000, and the final REF segment (Health Coverage Policy Number) at position 2900 in Loop-ID 2300. It is possible to send group information valid for all members in Table 1 and member specific policy number at member level. Also, if there are different policy numbers for different health coverage (vision, dental, etc.), the policy numbers will be sent at the health coverage level.

Subscribers and Dependents

In 834, each member (whether it is subscriber or dependent) is sent as a separate occurrence by having a loop for each member. The question comes, if that is the case, how to connect dependents with the subscriber. This is done by using REF with 0F value in ‘Subscriber Identifier’ segment in Loop ID-2000, position 0200.

REF*02*920399938~

Also, INS01 describes if the member being described in the loop is a subscriber or not.

New Enrollment, Changes, and Termination

When creating or processing the 834 transaction, for each member in Loop ID-2000, one of the following types of information is being communicated.

These are some important points that need to be considered. When a subscriber and dependents are enrolled, the subscriber information has to appear first in the member loop, before the information on dependents. When a subscriber’s membership is terminated, there is no need to send information on terminating the dependents.

In implementing the 834 transaction set (new enrollment, benefit changes and termination) the following segments play more important roles than any other segments. It is important to study these segments before attempting to read/write 834 transaction set.

INS Member Level Detail (located at position 0100 in Loop ID-2000)
HD Health Coverage (located at position 2600 in Loop ID-2300)
DTP Member Level Dates (located at position 0250 in Loop ID-2000)
DTP Health Coverage Dates (located at position 2700 in Loop ID-2300)

The INS segment can be thought of as the main anchor that describes the reason of having this member in the member loop. If the data changes are related to a particular health coverage (medical, dental, pharmacy, etc.) then HD segment plays a prominent role. Note that INS is always required, DTP (Member) is situational, HD is situational, and DTP (Health Coverage) is required if HD is included.

Here are some samples of the INS segment.

An Example

There are many examples provided in the EDI 834 - 5010 standard set (www.wpc-edi.com). When studying them, give particular attention to INS and HD segments.

Here is an example copied from the 834 Standard as it is. After the explanation above, I thought the example will be easier to understand. I put the example here in the hope that it will make the understanding of EDI 834 better, without having to refer to the Standard Document.