834 Transaction Set Listing
008020X333 Benefit Enrollment and Maintenance- Loop 1000A - SPONSOR NAMERequired1
- Loop 1000B - PAYERRequired1
- Loop 1000C - TPA/BROKER NAMESituational2
- Loop 1100C - TPA/BROKER ACCOUNT INFORMATIONSituational1
- Loop 2000 - MEMBER LEVEL DETAILRequired>1
- Loop 2100A - MEMBER NAMERequired1
- Loop 2100B - INCORRECT MEMBER NAMESituational1
- Loop 2100C - MEMBER MAILING ADDRESSSituational1
- Loop 2100D - MEMBER EMPLOYERSituational3
- Loop 2100E - MEMBER SCHOOLSituational3
- Loop 2100F - CUSTODIAL PARENTSituational1
- Loop 2100G - RESPONSIBLE PERSONSituational13
- Loop 2100H - DROP OFF LOCATIONSituational1
- Loop 2200 - DISABILITY INFORMATIONSituational>1
- Loop 2300 - HEALTH COVERAGESituational99
- Loop 2310 - PROVIDER INFORMATIONSituational30
- Loop 2320 - COORDINATION OF BENEFITSSituational10
- Loop 2330 - COORDINATION OF BENEFITS RELATED ENTITYSituational3
- Loop 2500 - TAX ADVANTAGE ACCOUNTSituational10
- Loop 2700 - MEMBER REPORTING CATEGORIESSituational>1
- Loop 2750 - REPORTING CATEGORYRequired1
ISA - INTERCHANGE CONTROL HEADER
- For compliant implementations under this implementation guide, ISA13, the interchange Control Number, must be a positive unsigned number. Therefore, the ISA segment can be considered a fixed record length segment.
- The first element separator defines the element separator to be used through the entire interchange.
- Spaces in the example interchanges are represented by "." for clarity.
- The ISA segment terminator defines the segment terminator used throughout the entire interchange.
- All positions within each of the data elements must be filled.
- The Interchange Control Number, ISA13, must be identical to the associated Interchange Trailer IEA02.
- Must be a positive unsigned number and must be identical to the value in IEA02.
GS*BE - FUNCTIONAL GROUP HEADER
ST*834 - TRANSACTION SET HEADER
- This element must be populated with the guide identifier named in Section 1.2.
- This field contains the same value as GS08. Some translator products strip off the ISA and GS segments prior to application (ST-SE) processing. Providing the information from the GS08 at this level will ensure that the appropriate application mapping is utilized at translation time.
BGN - BEGINNING SEGMENT
If BGN05 is present, then BGN04 is required.
Explanation: If the original transaction has already been processed, an incoming transaction using this code may be rejected by the receiver. The rejection will be identified to the sender by telephone or other direct contact.
- This element is the transaction set reference number assigned by the sender's application. It uniquely identifies this occurrence of the transaction for future reference.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
REF*38 - TRANSACTION SET POLICY NUMBER
At least one of REF02 or REF03 is required.
DTP - FILE EFFECTIVE DATE
QTY - TRANSACTION SET CONTROL TOTALS
- R0204
At least one of QTY02 or QTY04 is required. - E0204
Only one of QTY02 or QTY04 may be present.
- This is intended to submit the total number of members within the file.
- The QTY02 values, when QTY01 = ET plus when QTY01 = DT, equals the QTY02 value when QTY01 = TO.
Count values: QTY02 + QTY02 = QTY02
When QTY01 = ET + DT = TO - Since an individual member's record may be transmitted more than once within the ST-SE, the quantity in QTY02 when QTY01 = TO, does not necessarily reflect a count of unique member records.
N1*P5 - SPONSOR NAME
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
N1*IN - PAYER
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
N1 - TPA/BROKER NAME
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
ACT - TPA/BROKER ACCOUNT INFORMATION
- P0304
If either ACT03 or ACT04 is present, then the other is required. - C0506
If ACT05 is present, then ACT06 is required. - C0705
If ACT07 is present, then ACT05 is required.
INS - MEMBER LEVEL DETAIL
If either INS11 or INS12 is present, then the other is required.
- The value 18 must be used for the subscriber.
- For dependents, this value identifies their relationship to the subscriber. For example, a daughter would be value 19.
REF*0F - SUBSCRIBER IDENTIFIER
At least one of REF02 or REF03 is required.
REF*1L - MEMBER POLICY NUMBER
At least one of REF02 or REF03 is required.
REF - MEMBER SUPPLEMENTAL IDENTIFIER
At least one of REF02 or REF03 is required.
DTP - MEMBER LEVEL DATES
DTP*903 - ONLINE APPLICATION DATE/TIME
NM1 - MEMBER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
The Social Security Number must be a string of exactly nine numbers with no separators.
For example, sending "111002222" would be valid, while sending "111-00-2222" would be invalid.
PER*IP - MEMBER COMMUNICATIONS NUMBERS CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
- When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number must always include the area code and phone number using the format AAABBBCCCC where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number. Therefore, the following telephone number (555) 555-1234 would be represented as 5555551234. Do not submit long distance access numbers, such as 1, in the telephone number. Telephone extensions, when applicable, must be submitted in the next element immediately following the telephone number. When submitting telephone extensions, only submit the numeric extension, do not include data that indicates an extension, such as "ext" or "x-".
- Send communication information in the order of preference when contacting the member.
N3 - MEMBER ADDRESS
N4 - MEMBER CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
DMG*D8 - MEMBER DEMOGRAPHIC INFORMATION
- P0102
If either DMG01 or DMG02 is present, then the other is required. - P1011
If either DMG10 or DMG11 is present, then the other is required. - C1105
If DMG11 is present, then DMG05 is required.
If either C05602 or C05603 is present, then the other is required.
EC - MEMBER EMPLOYMENT CLASS
ICM - MEMBER INCOME
AMT - MEMBER POLICY AMOUNTS
HLH - MEMBER HEALTH INFORMATION
Or
Required when an enrollment update and a member's medical information has changed and is available. If not required by this implementation guide, do not send.
LUI - MEMBER LANGUAGE
- P0102
If either LUI01 or LUI02 is present, then the other is required. - L040203
If LUI04 is present, then at least one of LUI02 or LUI03 are required.
NM1*70 - INCORRECT MEMBER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
The Social Security Number must be a string of exactly nine numbers with no separators.
For example, sending "111002222" would be valid, while sending "111-00-2222" would be invalid.
DMG*D8 - INCORRECT MEMBER DEMOGRAPHIC INFORMATION
- P0102
If either DMG01 or DMG02 is present, then the other is required. - P1011
If either DMG10 or DMG11 is present, then the other is required. - C1105
If DMG11 is present, then DMG05 is required.
If either C05602 or C05603 is present, then the other is required.
NM1*31 - MEMBER MAILING ADDRESS
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
N3 - MEMBER MAIL ADDRESS
N4 - MEMBER MAIL CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
NM1*36 - MEMBER EMPLOYER
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
PER*EP - MEMBER EMPLOYER COMMUNICATIONS NUMBERS CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
N3 - MEMBER EMPLOYER ADDRESS
N4 - MEMBER EMPLOYER CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
NM1*M8 - MEMBER SCHOOL
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
PER*SK - MEMBER SCHOOL COMMUNICATIONS NUMBERS CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
- When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number must always include the area code and phone number using the format AAABBBCCCC where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number. Therefore, the following telephone number (555) 555-1234 would be represented as 5555551234. Do not submit long distance access numbers, such as 1, in the telephone number. Telephone extensions, when applicable, must be submitted in the next element immediately following the telephone number. When submitting telephone extensions, only submit the numeric extension, do not include data that indicates an extension, such as "ext" or "x-".
- Send communication information in the order of preference when contacting the member.
N3 - MEMBER SCHOOL ADDRESS
N4 - MEMBER SCHOOL CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
NM1*S3 - CUSTODIAL PARENT
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
The Social Security Number must be a string of exactly nine numbers with no separators.
For example, sending "111002222" would be valid, while sending "111-00-2222" would be invalid.
PER*PQ - CUSTODIAL PARENT COMMUNICATIONS NUMBERS CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
- When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number must always include the area code and phone number using the format AAABBBCCCC where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number. Therefore, the following telephone number (555) 555-1234 would be represented as 5555551234. Do not submit long distance access numbers, such as 1, in the telephone number. Telephone extensions, when applicable, must be submitted in the next element immediately following the telephone number. When submitting telephone extensions, only submit the numeric extension, do not include data that indicates an extension, such as "ext" or "x-".
- Send communication information in the order of preference when contacting the Custodial Parent.
N3 - CUSTODIAL PARENT ADDRESS
N4 - CUSTODIAL PARENT CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
NM1 - RESPONSIBLE PERSON
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
The Social Security Number must be a string of exactly nine numbers with no separators.
For example, sending "111002222" would be valid, while sending "111-00-2222" would be invalid.
PER*RP - RESPONSIBLE PERSON COMMUNICATIONS NUMBERS CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
- When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number must always include the area code and phone number using the format AAABBBCCCC where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number. Therefore, the following telephone number (555) 555-1234 would be represented as 5555551234. Do not submit long distance access numbers, such as 1, in the telephone number. Telephone extensions, when applicable, must be submitted in the next element immediately following the telephone number. When submitting telephone extensions, only submit the numeric extension, do not include data that indicates an extension, such as "ext" or "x-".
- Send communication information in the order of preference when contacting the Responsible Person.
N3 - RESPONSIBLE PERSON ADDRESS
N4 - RESPONSIBLE PERSON CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
NM1*45 - DROP OFF LOCATION
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
N3 - DROP OFF LOCATION ADDRESS
N4 - DROP OFF LOCATION CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
DSB - DISABILITY INFORMATION
If either DSB07 or DSB08 is present, then the other is required.
DTP - DISABILITY ELIGIBILITY DATES
HD - HEALTH COVERAGE
Explanation: Certain situations, such as military duty and TRICARE, classify the subscriber as ineligible for coverage or benefits. However, dependents of the subscriber are still eligible for coverage or benefits under the subscriber. Subscriber identifying elements are needed to accurately identify dependents.
DTP - HEALTH COVERAGE DATES
DTP*903 - ONLINE APPLICATION DATE/TIME
AMT - HEALTH COVERAGE POLICY AMOUNT
REF - HEALTH COVERAGE NUMBERS
At least one of REF02 or REF03 is required.
REF*QQ - PRIOR COVERAGE MONTHS
At least one of REF02 or REF03 is required.
- This field will contain the number of months of prior health insurance coverage that meets the portability requirements of the HIPAA certification requirements. To be sent on new enrollments when available.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
IDC - IDENTIFICATION CARD
LX - PROVIDER INFORMATION
- The primary care provider effective date is defaulted to the effective date of the product identified in the DTP segment of the 2300 loop. When an enrollee switches from one primary care provider to another through the sponsor, the new provider must be listed with the effective date of change.
- Use one iteration of the loop to identify each applicable health care service provider.
NM1 - PROVIDER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
N3 - PROVIDER ADDRESS
N4 - PROVIDER CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
PER*IC - PROVIDER COMMUNICATIONS NUMBERS CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
- When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number must always include the area code and phone number using the format AAABBBCCCC where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number. Therefore, the following telephone number (555) 555-1234 would be represented as 5555551234. Do not submit long distance access numbers, such as 1, in the telephone number. Telephone extensions, when applicable, must be submitted in the next element immediately following the telephone number. When submitting telephone extensions, only submit the numeric extension, do not include data that indicates an extension, such as "ext" or "x-".
- Send communication information in the order of preference when contacting the provider.
PLA*2 - PROVIDER CHANGE REASON
COB - COORDINATION OF BENEFITS
REF - ADDITIONAL COORDINATION OF BENEFITS IDENTIFIERS
At least one of REF02 or REF03 is required.
DTP - COORDINATION OF BENEFITS ELIGIBILITY DATES
NM1 - COORDINATION OF BENEFITS RELATED ENTITY
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
N3 - COORDINATION OF BENEFITS RELATED ENTITY ADDRESS
N4 - COORDINATION OF BENEFITS OTHER INSURANCE COMPANY CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
PER*CN - ADMINISTRATIVE COMMUNICATIONS CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
FSA - TAX ADVANTAGE ACCOUNT
OR
adding, updating or removing a member's Tax Advantage Account
OR
auditing a member with a Tax Advantage Account.
If not required by this implementation guide, do not send.
AMT - TAX ADVANTAGE ACCOUNT AMOUNT
DTP - TAX ADVANTAGE ACCOUNT DATE
REF*A8 - TAX ADVANTAGE ACCOUNT INFORMATION
At least one of REF02 or REF03 is required.
LS - ADDITIONAL REPORTING CATEGORIES
LX - MEMBER REPORTING CATEGORIES
N1*75 - REPORTING CATEGORY
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
REF - REPORTING CATEGORY REFERENCE
At least one of REF02 or REF03 is required.
DTP*007 - REPORTING CATEGORY DATE
- Use this segment to associate a date or date range with a reporting category.
- Date ranges are reported with the first occurrence of CCYYMMDD as the beginning date and the second occurrence as the ending date.
LE - ADDITIONAL REPORTING CATEGORIES LOOP TERMINATION
SE - TRANSACTION SET TRAILER
GE - FUNCTIONAL GROUP TRAILER
IEA - INTERCHANGE CONTROL TRAILER
| | 834 Benefit Enrollment and Maintenance (008020X333)NOVEMBER 2021 Copyright © 2008-21, X12 Incorporated, Format © 2008-21 Washington Publishing Company. Exclusively published by the Washington Publishing Company. No part of this publication may be distributed, posted, reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission of the copyright owner. All rights reserved. Abstract The Benefit Enrollment and Maintenance Implementation Guide describes the use of the X12 Benefit Enrollment and Maintenance (834) transaction set and addresses the enrollment and maintenance of human resources benefit plans including:
|
PrefaceX12 standards are developed to identify the broadest data requirements for a transaction set. Type 3 Technical Reports (TR3), also known as implementation guides, define the explicit data requirements for a specific business purpose. Trading partners who implement according to the instructions in this TR3 can exchange data consistently with multiple trading partners. As X12 does not define transport requirements, trading partners define their specific transport requirements separately. |
1.1 Implementation Purpose and ScopeFor the health care industry to achieve the potential administrative cost savings with Electronic Data Interchange (EDI), standards have been developed and need to be implemented consistently by all organizations. To facilitate a smooth transition into the EDI environment, uniform implementation is critical. The purpose of this implementation guide is to provide standardized data requirements and content to users of Version 008020 of X12, Benefit Enrollment and Maintenance (834). The 834 is used to transfer enrollment information from the sponsor of the insurance coverage, benefits, or policy to a payer. The intent of this implementation guide is to meet the health care industry's specific need for the initial enrollment and subsequent maintenance of individuals who are enrolled in insurance products. This implementation guide specifically addresses the enrollment, maintenance of health care products, and tax advantage account products. |
1.2 Version InformationThis implementation guide is based on the October 2020 X12 standards, referred to as Version 8, Release 2 (008020). The unique Version/Release/Industry Identifier Code for transaction sets that are defined by this implementation guide is 008020X333. The two-character Functional Identifier Code for the transaction set included in this implementation guide:
The Version/Release/Industry Identifier Code and the applicable Functional Identifier Code must be transmitted in the Functional Group Header (GS segment) that begins a functional group of these transaction sets. For more information, see the descriptions of GS01 and GS08 in Appendix C EDI Control Directory. |
1.3.1 Batch and Real-Time UsageThere are multiple methods available for sending and receiving business transactions electronically. Two common modes for EDI transactions are batch and real-time. Batch - In a batch mode the sender does not remain connected while the receiver processes the transactions. Processing is usually completed according to a set schedule. If there is an associated business response transaction (such as a 271 Response to a 270 Request for Eligibility), the receiver creates the response transaction and stores it for future delivery or transmits the response transaction back to the sender of the original transaction. The sender of the original transmission reconnects at a later time and picks up the response transaction. Note: The sender of the original transmission may not always be the entity that picks up the response transaction at a later time (e.g. Provider submitting through a clearinghouse.) Real-Time - In real-time mode the sender remains connected while the receiver processes the transactions and returns a response transaction to the sender. This implementation guide does not set specific response time parameters for implementers. This implementation guide was based on requirements for batch mode. Willing trading partners may use batch or real-time mode. |
1.3.2 Other Usage LimitationsThere are no other usage limitations. Any response back to the Sponsor from the received transaction is outside the scope of the 834 and is the responsibility of the sponsor and payer. |
1.4.1 Health Care Transaction FlowEach X12 implementation guide explains how to use X12 transaction sets to meet a single defined business purpose. The diagrams found at https://www.x12.org/flow depict the business functions supported by the X12 health care implementation guides. |
1.4.2 Information FlowsFigure 1.1 - Health Care Transaction sets included in the information flow diagram:
|
1.4.3 Location of Insurance Product IdentifiersThe 834 allows three locations for Insurance Product Identifiers, such as policy numbers and group numbers:
The work group found that there was no consistent use for the Insurance Product Identifier at any level. For this reason, the consensus by the work group was to make the Insurance Product Identifier situational at all the levels. However, at least one REF segment containing the Insurance Product Identifier must be present for each Insurance Product either at the Transaction, Member, or Health Coverage level. The work group selected code "38", Master Policy Number, at the Transaction level. This identifier is to be sent when the Insurance Product Identifier applies to all the Insurance Products in the Transaction. The work group found that most of the time the Insurance Product Identifier is communicated at the Member level (loop 2000). The work group selected code "1L", Group or Policy Number, at this level. The Group or Policy Number applies to all the Health Coverage iterations (loop 2300) for the member named in loop 2000. Other iterations of the REF segment with other qualifiers are included to support business needs under the specific policy. The developers of this implementation guide were not able to limit the sender to a single code because of the variety of different insurance plans. At the Health Coverage level (loop 2300), the sender also has the option of sending the Group or Policy Number. The work group selected code "1L", Group or Policy Number, at this level. This applies when different policy numbers exist for each Insurance Product specified in the HD segments. |
1.4.4 Linking a Dependent to a SubscriberSubscribers and dependents are sent as separate occurrences of Loop ID-2000. The initial enrollment for the subscriber must be sent before sending the initial enrollment for any of the subscriber's dependents. The enrollment of a dependent may follow the subscriber's enrollment in the same transmission, or it may be sent separately in a later transmission. Maintaining the existing enrollments of a subscriber and dependents can occur in any sequence. Payers use various means to link dependents to the subscriber. The most common method is to use the subscriber's Social Security Number (SSN). To allow linking between subscribers and dependents without making assumptions about the receiving system, use the code "0F," Subscriber Number, in the REF segment, Loop ID-2000, position 0200. The subscriber's unique identifier is sent in this segment in both the subscriber's and the dependent's Loop ID-2000. The individual's SSN is sent and identified as such in NM108, Loop ID-2100A, position 0300. This applies to both subscribers and dependents. If the SSN is used for linking, then the subscriber's SSN is sent in both locations on the subscriber's Loop ID-2000. |
1.4.5 TerminationThe content of transactions intended to terminate coverage for subscribers and/or related members was the subject of extensive discussion during development of this implementation guide. The work group attempted to strike a balance between the systemic and operational benefits of highly detailed, rich data content and the reality of a current practice in which many plan sponsors and other originators of this transaction may have less than complete data on hand. To accommodate the greatest possible number of users, the work group adopted a guiding principle that only the minimum necessary data would be required for a given type of termination, but that additional data could be sent at the sender's discretion. Trading partners should agree on their approach to communicating terminations in their trading partner agreement. Regardless of additional data and trading partner agreements, transactions of certain format and content must cause very specific outcomes in receiver systems. A termination date passed at the INS level for an individual who is the subscriber (That is, a termination date passed in the DTP segment in position 0250 in the 2000 loop for an INS segment with INS01 = 'Y') indicates that all coverages for that subscriber and any associated dependents are to be terminated in the receiver's system on the indicated date. Said another way, if a subscriber, spouse and two children are all enrolled in medical, prescription and vision coverages in the receiver's system, an "Eligibility End" date passed in that DTP segment for the subscriber must cause the termination of all three coverages for all four individuals in the receiver's system on the date provided in DTP03. A termination date passed at the INS level for an individual who is not the subscriber (That is, a termination date passed in the DTP segment in position 0250 in the 2000 loop for an INS segment with INS01 = 'N') indicates that all coverages for that individual are to be terminated in the receiver's system on the indicated date. If a subscriber, spouse and two children are all enrolled in medical, prescription and vision coverages in the receiver's system, an "Eligibility End" date passed in that DTP segment for the spouse must cause the termination of all three coverages for one individual (the spouse). A termination date passed at the HD level (that is, a termination date passed in the DTP segment in position 2700 in the 2300 loop for an HD loop of any coverage type) applies singly to an individual and a coverage. If a subscriber, spouse and two children are all enrolled in medical, prescription and vision coverages in the receiver's system, a "Benefit End" date passed in the DTP segment subordinate to the vision coverage for the spouse indicates that the last day of the spouse's vision coverage is the date provided in that segment's DTP03. Coverage for other lines of coverage for the member will not be affected, nor will any coverage for any other member linked to the same subscriber. Termination dates are not to be sent at both the HD and INS levels for a particular occurrence of loop 2000. For an individual who is not the subscriber, terminating all lines of coverage at the HD level is the equivalent of terminating that dependent at the INS level. For a subscriber, terminating all insurance products at the HD level is not equivalent to passing the termination at the INS level. Passing terminations at the INS level for a subscriber causes all coverages for all linked dependents to be terminated. Passing terminations at the HD level for a subscriber does not affect the coverages of other individuals linked to that subscriber - dependents may continue to be covered in dependent-only coverage. A change of coverage or an addition of coverage may not automatically result in the termination of existing coverage unless this is clearly agreed upon in the trading partner agreement. Member records that were previously reported as covered and subsequently omitted from the full file replacement can be terminated by the receiver if the process is clearly agreed upon in the trading partner agreement. |
1.4.6 Updates, Versus Full File Audits, Versus Full File ReplacementsThe 834 transaction can be used to provide either updates to the enrollment database, full file audits of the 834 enrollment process, or full file replacements. An update is either an "add", "terminate" or "change" request. The transaction only contains information about the changed members. This is identified in BGN08 by a code value of '2', Change (Update). A full file audit lists all current members, whether involved in a change or not. This facilitates keeping the sponsor's and payer's systems in sync. This is not intended to contain a history of all previous enrollments. The full file audit is intended to identify all active members, at a given point in time and may or may not include terminated members based on your trading partner agreement. The full file audit is not intended to be used to make any changes to the enrollment database. This type of transaction is identified by a BGN08 code value of '4', Verify. Any response back to the sponsor from the received transactions are outside the scope of the 834 and are the responsibility of the sponsor and payer. In addition, INS03 in Loop 2000 and HD01 in Loop 2300 must be set to a value of '030', Audit or Compare. This transaction allows a payer to identify additions, terminations, and changes that need to be applied to the payer's system. A full file identified in BGN08 by a code value of 'RX', Replace, is intended to identify all active members, at a given point in time and may or may not include terminated members based on your Trading Partner Agreement. In addition, INS03 in Loop 2000 and HD01 in Loop 2300 must be set to a value of '030', Audit or Compare. |
1.4.7 Coverage Levels and DependentsDifferences exist in how Payers handle Dependents. Some Payers identify a Coverage Level (HD05) for the Subscriber which defines the coverage for eligible Dependents as well. Other Payers need detailed information on each Dependent in order to maintain their databases. Still other Payers require both types of information. The trading partner agreement between the Payer and the Sponsor must identify the member reporting requirements for the Enrollment transaction. When the trading partner agreement requires the Coverage Level code and no Dependent information, HD05 is required for all initial enrollment or changes to the Coverage Level Code. When Dependent information is required without the Coverage Level Codes, separate INS loops are required for enrollment or change for each Dependent. See the Termination section for more information. HD05 is not used for any Dependent. When the Dependent information and Coverage Level Code are Required, the Coverage Level Code (HD05) must be used for all Subscriber initial enrollments or when the Subscriber's Coverage Level Code changes. This change applies to all covered Dependents of the Subscriber. The Coverage Level Code is not used with Dependent enrollment, changes or terminations. Note: If a Dependent addition or termination effectively changes the Coverage Level Code of a Subscriber, the Subscriber must be changed directly if the trading partner agreement requires use of the Coverage Level Code. |
1.5 Business TerminologyTo ensure consistent use of terms, definitions, and acronyms across X12 products, X12 maintains the Wordbook, a comprehensive corporate glossary. The included terms are either proprietary to X12, cite definitions published by another authority, or represent common terms and definitions that are relevant to X12's work. The terms and definitions defined in the Wordbook are used in X12 work products when applicable, without modification or revision. The Wordbook can be referenced online at wordbook.x12.org. |
1.5.1 Date TerminologyUsers of past 834 implementation guides encountered considerable confusion about what codes should be used for dates related to the insured in Loop ID-2000 and to the insurance coverage in Loop ID-2300. This confusion resulted because several codes with very similar uses were available. These codes include the following: effective date, eligibility date, enrollment date, plan date, coverage date, and benefit date. The tendency has been to try to use the same terminology as that used in the application systems. Lengthy discussion was required to reach a resolution because the application systems' terminology often differed among different systems. To facilitate communications between different systems, the developers of this implementation guide have limited the codes in Loop ID-2300 DTP, with the term "benefit" being used for actual dates of coverage. The developers of this implementation guide recommend that the term "Eligibility" is used from the point of view of the plan sponsor. That is, an individual's "eligibility" dates are those during which he or she may choose to be covered by the sponsor's benefits. The developers further recommend that the term "enrollment" be used from the point of view of the payer. In this case, an individual's "enrollment" dates are those dates during which he or she is covered by a particular benefit. Many more codes are listed in the DTP segment in Loop ID-2000. The developers of this implementation guide recommend that the term "eligibility" be used to refer to the dates on which an insured individual may choose to be covered. |
1.6 Transaction AcknowledgmentsThe purpose of transaction acknowledgments is to report to the sender whether the transaction being acknowledged was accepted or rejected. The X12 Technical Report Type 2, Acknowledgment Reference Model provides guidance on several control structures and transaction set standards intended to augment EDI auditing and control systems. |
1.7 Related TransactionsThere are no transactions related to the transactions described in this implementation guide. |
1.8 Trading Partner AgreementsTrading partner agreements are used to establish and document the relationship between trading partners. A trading partner agreement must not override the specifications in this implementation guide if a transmission is reported in GS08 to be a product of this implementation guide. |
1.9 Transaction ComplianceThere are three types of compliance that may be relevant to a transmitted transaction. Compliance with implementation guide requirements Compliance with state and federal regulation Compliance with trading partner contractual agreements |
1.9.1 Transaction Compliance with Implementation Guide RequirementsA transaction complies with X12 implementation guide requirements if the transaction satisfies all format and content rules and constraints specified in the applicable X12 standards and the implementation guide (also known as a TR3) itself. Should additional clarification of an X12 implementation guide requirement be desired, two options are available.
X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that are not TR3-compliant based on its own business process. A receiver may specify its business rules in a trading partner agreement or companion document. As stated in §1.8, these documents do not override TR3 requirements, nor change how transaction compliance with this TR3 is determined. |
1.9.2 Transaction Compliance with State and Federal RegulationsThis implementation guide has been developed for use as an insurance industry implementation guide. At the time of publication it has not been adopted as a state or federal standard. Should this implementation guide be adopted as a standard, the adopting authority will establish compliance dates for its use by impacted entities. X12 is not the authority for determining compliance with regulatory requirements that might further constrain implementation guide requirements. Questions of compliance for regulatory requirements should be directed to the governing authority. X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with applicable regulatory requirements as specified by the applicable regulation(s) or governing authority. |
1.9.3 Transaction Compliance with Contractual RequirementsX12 is not the authority for determining compliance with contractual requirements that might further constrain implementation guide requirements. Questions of compliance for contractual requirements should be directed to the contracting entity. X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with contractual requirements as specified by the applicable contract or contracting entity. |
2.1 Presentation ExamplesThe X12 standards are generic. For example, multiple trading communities use the same PER segment to specify administrative communication contacts. Each community decides which elements to use and which code values in those elements are applicable. This implementation guide uses a format that depicts both the generalized standard and the insurance industry-specific implementation. In this implementation guide, IMPLEMENTATION specifies the requirements for this implementation. X12 STANDARD is included as a reference only. The transaction set presentation is comprised of two main sections with subsections within the main sections: Transaction Set Listing There are two sub-sections under this general title. The first sub-section concerns this implementation of a generic X12 transaction set. The second sub-section concerns the generic X12 standard itself. This section lists the levels, loops, and segments contained in this implementation. It also serves as an index to the segment detail. This section is included as a reference. Segment Detail There are three sub-sections under this general title. This section repeats once for each segment used in this implementation providing segment specific detail and X12 standard detail. This section is included as a reference. This section is included as a reference. It provides a pictorial view of the standard and shows which elements are used in this implementation. This section specifies the implementation details of each data element. These illustrations (Figures 2.1 through 2.5) are examples and are not extracted from the Section 2 detail in this implementation guide. Annotated illustrations, presented below in the same order they appear in this implementation guide, describe the format of the transaction set that follows. Figure 2.1 - Transaction Set Key - Implementation Figure 2.2 - Transaction Set Key - Standard Figure 2.3 - Segment Key - Implementation Figure 2.4 - Segment Key - Diagram Figure 2.5 - Segment Key - Element Summary |
2.2.1 Industry UsageIndustry Usage describes when loops, segments, and elements are to be sent when complying with this implementation guide. The three choices for Usage are required, not used, and situational. To avoid confusion, these are named differently than the X12 standard Condition Designators (mandatory, optional, and relational).
|
2.2.1.1 Determining Transaction Compliance with Industry Usage RequirementsA transmitted transaction complies with the governing implementation guide when it satisfies the requirements as defined within the implementation guide. Specifically, the presence or absence of an item (loop, segment, or element) complies with the industry usage specified by this implementation guide according to the following table.
|
2.2.2 LoopsLoop requirements depend on the context or location of the loop within the transaction. See Appendix B for more information on loops.
|
3. ExamplesBusiness scenario examples for use of this transaction can be found on the X12 Examples website at http://examples.x12.org. The X12 Examples website provides convenient access to examples of X12 transaction transmissions, including the data stream and a description of the associated scenario. |
| Â | ||||
Appendix A. External Code SourcesPrior to this publication, X12 TR3s contained a subset of the overall Code Source Directory, formerly known as Appendix A of X12.3. External code lists are not part of the X12 standard and are provided for information purposes only. The full listing is available in Glass, X12's On-Line viewer. Read more about Glass here: https://glasshelp.x12.org/. Where an external code source is referenced in this publication, the implementer is required to use only the codes from that list. Codes must be reported as listed in the code source (e.g. with leading zeroes). Implementers must follow the instructions for code use that are supplied by the code set owner. | ||||
| Â | ||||
B.1.1 Referenced and Related StandardsThis technical report is based on the X12 EDI standard which comprises a series of interdependent publications. Implementers are advised to consult these publications when using this technical report. The following standards are required to interpret, understand, and use this technical report:
The following guideline is useful to interpret, understand, and use this technical report:
The following reference model is useful to interpret, understand, and use this technical report:
All of the documents above are available online using links to X12's Online Viewer. | ||||
| Â | ||||
B.1.1.1 Transmission Control SchematicRefer to X12.5 - Interchange Control Structures, Section 3.5 - Order of Control Segments, and Chapter 5 Interchange Segment Specifications. Similar transaction sets, called "functional groups," can be sent together within a transmission. Each functional group is prefaced by a group start segment; and a functional group is terminated by a group end segment. One or more functional groups are prefaced by an interchange header and followed by an interchange trailer. Figure B.1 - Transmission Control Schematic, illustrates this interchange control. Figure B.1 - Transmission Control Schematic | ||||
| Â | ||||
B.1.1.2 Constraints applicable to the suite of TR3sRefer to X12.6 - Application Control Structure, Section 3.2.8 - Minimums/Maximums. Data element minimum and maximum lengths are set by the X12 standard. This implementation guide may further restrict minimum and maximum lengths within the bounds set by the standard. Such restrictions may occur implicitly by virtue of the allowed qualifier for the data element, or they may be stated explicitly in a note attached to the element or in the general limitations below. | ||||
| Â | ||||
B.1.1.2.1 Maximum Length of Data Element 127 Reference IdentificationThe current X12 standard allows a maximum length greater than 50 characters for data element 127. For implementations governed by this implementation guide, unless another value is specified in an attached note, the maximum length of each occurrence of this data element is constrained to 50 characters. | ||||
| Â | ||||
B.1.1.2.2 Maximum Length of Data Element 782 Monetary AmountFor implementations governed by this implementation guide, unless another value is specified for an instance of Data Element 782 within Section 2 (Transaction Set), each occurrence of Data Element 782 (Monetary Amount) will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). Note that the decimal point and leading sign, if sent, are not part of the character count. EXAMPLE
| ||||
| Â | ||||
B.1.1.3 DecimalWhile the X12 standard supports usage of exponential notation, this guide prohibits that usage. | ||||
Appendix D. Change SummaryThis Implementation Guide (008020X333) defines the X12 requirements for the Benefit Enrollment and Maintenance. It is based on version/release/subrelease 008020 of the X12 standards. |