Ansi Companion Guide

834 Companion Guide

834 Companion Guide

Proprietary and Confidential Page 2 Last Updated:10/22/2008

Disclaimer This Independence Blue Cross / Keystone Health Plan East (hereinafter referred to as IBC / KHPE) Companion Guide to EDI Transactions (the Companion Guide) provides trading partners with guidelines for submitting electronic batch transactions. Because the HIPAA ASC X12N Implementation Guides require transmitters and receivers to make certain determinations/elections (e.g., whether, or to what extent, situational data elements apply), this Companion Guide documents those determinations, elections, assumptions, or data issues that are permitted to be specific to IBC / KHPEs business processes when implementing the HIPAA ASC X12N 4010A1 Implementation Guides. This Companion Guide does NOT replace or cover all segments specified in the HIPAA ASC X12N Implementation Guides. It does not attempt to amend any of the requirements of the Implementation Guides, or impose any additional obligations on trading partners of IBC / KHPE that are not permitted to be imposed by the HIPAA Standards for Electronic Transactions. This Companion Guide provides information on IBC / KHPE specific codes relevant to IBC / KHPEs business processes and rules and situations that are within the parameters of HIPAA. Readers of this Companion Guide should be acquainted with the HIPAA Implementation Guides, their structure, and content. This Companion Guide provides supplemental information to the Trading Partner Agreement that exists between IBC / KHPE and its trading partners. Trading partners should refer to their Trading Partner Agreement for guidelines pertaining to IBC / KHPEs legal conditions surrounding the implementation of the EDI transactions and code sets. However, trading partners should refer to this Companion Guide for information on IBC / KHPEs business rules or technical requirements regarding the implementation of HIPAA-compliant EDI transactions and code sets. Nothing contained in this Companion Guide is intended to amend, revoke, contradict, or otherwise alter the terms and conditions of the Trading Partner Agreement. If there is an inconsistency between the terms of this Companion Guide and the terms of the Trading Partner Agreement, the terms of the Trading Partner Agreement will govern. If there is an inconsistency between the terms of this Companion Guide and any terms of one of the Implementation Guides, the relevant Implementation Guide will govern with respect to HIPAA edits, and this Companion Guide will control with respect to business edits.

834 Companion Guide


Table of Contents

I. Introduction _______________________________________________ 5

II. ANSI x12 Transactions Supported_______________________________ 7

III. General Information___________________________________________ 8 A. Contact Information:_______________________________________ 8

B. EDI Processing Hours:______________________________________ 8

C. Password changes: ________________________________________ 8

IV. ANSI Requirements____________________________________________ 9

V. EDI Processing & Acknowledgements _____________________________ 10 TA1 Interchange Acknowledgement Transaction __________________ 10

997 Functional Acknowledgement _____________________________ 10

Interchange Data - Verification________________________________ 10

Submission Analysis Report (SAR) X12 864 ______________________ 10

VI. Payer-Specific Requirements ___________________________________ 11 ISA Interchange Control Header _______________________________ 12

GS Functional Group Header __________________________________ 13

DTP File Effective Date ______________________________________ 14

INS Member Level Detail_____________________________________ 15

REF Subscriber Number______________________________________ 16

REF Member Identification Number ____________________________ 17

NM1 Member Name_________________________________________ 19

ICM Member Income_______________________________________ 199

VII. Business Processing Guidelines _________________________________ 20 Customer Coverage Key Data _________________________________ 20

Group and Account Numbers__________________________________ 20

Subscriber Processing _______________________________________ 21

834 Companion Guide


Dependent Processing_______________________________________ 23

Plan Coverage Description ___________________________________ 25

Coverage Changes__________________________________________ 26

Maintenance Type and Reason Codes ___________________________ 30

Coverage or Benefit Dates____________________________________ 32

Communicating the Provider ID _______________________________ 34

Special Processing Situations _________________________________ 35

VIII. Transactional Testing Processes _______________________________ 36

IX. APPENDIX A ________________________________________________ 37 EMPLOYER EDI PROFILE _____________________________________ 38

COMMUNICATION PROTOCOLS SUPPORTED _____________________ 39

X. APPENDIX B________________________________________________ 411 TRADING PARTNER AGREEMENT ______________________________ 41

XI. APPENDIX T_______________________________________________ 42

XII. Full File Synchronization Requirements _________________________ 46 BGN Beginning Segment _____________________________________ 46

INS Member Level Detail_____________________________________ 47

HD Health Coverage ________________________________________ 48

834 Companion Guide


I. Introduction This Companion Guide contains the information necessary to establish and support the trading partner relationship with Independence Blue Cross / Keystone Health Plan East (hereinafter referred to collectively as IBC / KHPE). Establishing a trading partner relationship with IBC / KHPE requires completion of the following steps: 1. Review this Companion Guide and Appendices thoroughly for an understanding of

IBC / KHPEs requirements and business processes. 2. Submit a completed Employer EDI Profile: A copy of this form is contained in this

Companion Guide (Appendix A). This will initiate the work necessary to establish the trading partner relationship and begin setting up connectivity. Return the completed form to your assigned Enrollment System Analyst. Your marketing representative will give you the name of the Analyst assigned to you.

3. Submit a signed Trading Partner Agreement: This material documents the legal

trading partner relationship. Your assigned Enrollment System Analyst will provide a copy of the Trading Partner Agreement to you.

4. Obtain a Logon ID and Password: Upon receipt of the Trading Partner Agreement

and Employer EDI Profile, the trading partner will be sent a letter or email containing a Trading Partner ID (IBC / KHPE logon) and password. The trading partner will use this information when accessing IBC / KHPEs system for submission or retrieval of transactions.

5. Set up Connectivity: Connectivity with IBC / KHPE must be established and tested.

Options are discussed in Appendix A of this Companion Guide, and will be discussed with you after the Employer EDI Profile is completed.

6. Testing: After connectivity is set-up and fully tested, the transaction-testing phase

will begin. IBC / KHPEs testing methodology is described in Appendix T of this Companion Guide.

7. Full vs. Transactional File: IBC / KHPE prefers files to be in the full file format. If

transactional files are sent, we will only perform full file synchronizations with customers on a periodic basis (i.e. quarterly, semi-annually or annually based on discussions between both parties). Full file customers need to reference this guide as well as the 834 Companion Guide Addendum.

834 Companion Guide


If there are any questions regarding information contained in this Companion Guide, please contact your assigned Enrollment System Analyst.

834 Companion Guide


II. ANSI x12 Transactions Supported

IBC / KHPE processes the following ANSI X12 HIPAA transactions for enrollment:

ANSI X12 834 v4010 x095A1 (HIPAA) Benefit Enrollment and Maintenance ANSI X12 TA1 v4010 x095A (HIPAA) Response to the X12 transactions when

errors are encountered in outer envelopes (ISA/IEA & GS/GE)

ANSI X12 997 v4010 x095A (HIPAA) Functional Acknowledgement ANSI X12 864 v4010 Response to 834 by functional group

(Submission Analysis Report)

834 Companion Guide


III. General Information

A. Contact Information:

Please have your Trading Partner ID available when contacting IBC / KHPE. It will help facilitate the handling of questions.

Technical/Business questions should be routed to your eBusiness Deployment Consultant. eBusiness Deployment Consultants are available 8:00 a.m. - 5:00 p.m. Eastern Standard Time, Monday through Friday.

B. EDI Processing Hours:

Standard EDI processing hours are 6:00 a.m. - 4:00 p.m. Monday through Friday. IBC / KHPE will not process data files on weekends or company holidays.

If a file is received during non-standard hours, weekends, or company holidays, it will be processed on the next IBC / KHPE business day.

C. Password changes:

EDI transactions submitted by unauthorized trading partners will not be accepted.

Trading partners should protect the privacy of their sign-on and password by limiting knowledge of this information to key personnel. The password should be changed if there are personnel changes in the trading partners office, or at any time the trading partner deems necessary. If a change in password is necessary, please contact your assigned Enrollment System Analyst.

834 Companion Guide


IV. ANSI Requirements

The purpose of this section is to outline IBC / KHPEs technical requirements. These requirements are mandatory for all trading partners. All data interchanges MUST conform to the following specifications:

ENVELOPING Inbound transactions to IBC / KHPE must include transactions intended for only one ISA/GS receiver code. Any other transactions processed through IBC / KHPE on behalf of other payers or organizations should be included in separate files and deposited in their proper mailboxes with the receiver organization identified in the receiver codes in the ISA/GS fields in the data.

At this time, outbound 864 transactions will not contain multiple functional groups per ISA-IEA.

CHARACTER FORMAT

Data files submitted must be in all upper case letters.

DELIMITERS

IBC / KHPE utilize the following: Delimiter Value

Segment Terminator ~ (tilde) Data Element Separator * (asterisk) Sub-element Separator : (colon)

Note: The character following the first Segment Terminator must be the G from the GS segment. Hidden characters such as new-line or carriage-return should not be placed after the Segment Terminators. The Segment Terminator must only be one character.

The Segment, Element, and Component Delimiters that are received in the inbound ANSI X12 file will be the same Delimiters that are used in the outbound ANSI X12 response files.

834 Companion Guide


V. EDI Processing & Acknowledgements The purpose of this section is to outline IBC / KHPEs processes for handling the initial processing of incoming files and the electronic acknowledgement generation process.

TA1 Interchange Acknowledgement Transaction

All X12 file submissions are pre-screened upon receipt to determine if the ISA or IEA segments are readable. If errors are found, IBC / KHPE will send a TA1 response transaction to notify the trading partner that the file could not be processed. No TA1 response transaction will be sent for error-free files. Example: Once IBC / KHPE determines if the file is readable, validation is performed on the ISA and IEA loop information. If these segments have a non-standard structure, the file will receive a full file reject and the TA1 response transaction will be sent to the trading partner.

997 Functional Acknowledgement

If the file submission passes the ISA/IEA pre-screening above, it is then checked for ANSI x12 syntax and HIPAA compliance errors. When the compliance check is complete, a 997 will be sent to the trading partner informing them if the file has been accepted or rejected. If multiple transaction sets (ST-SE) are sent within a functional group (GS-GE), the entire functional group (GS-GE) will be rejected when an ANSI x12 or HIPAA compliance error is found.

Interchange Data - Verification

IBC / KHPEs processing includes the verification of the Interchange Control Numbers (ISA13), Interchange Sender ID (ISA06), and Interchange Control Version Number (ISA12) for uniqueness. If a potential duplicate file is received, the entire file will be rejected and the trading partner will be contacted to determine the proper course of action.

Submission Analysis Report (SAR) X12 864

A Submission Analysis Report,SAR, is sent by IBC / KHPE in X12 864 format. The data file will be transmitted to the trading partner for each functional group processed. It will report the status of all members submitted and any business rules or edits which failed.

834 Companion Guide


VI. Payer-Specific Requirements

The purpose of this section is to delineate specific data requirements where multiple valid values are presented within the 4010A Implementation Guide. Additional instructions and other critical information regarding this transaction are contained in subsequent sections of this Companion Guide.

834 Companion Guide


Segment: ISA Interchange Control Header Level: Detail Usage: Required - By Implementation Guide

Data Element Summary

Ref Des Element Name Element Note ISA07 Interchange ID Qualifier Enter code value: 33 (National Association of

Insurance Commissioners NAIC)

ISA08 Interchange Receiver ID Enter value: 54704

834 Companion Guide


Segment: GS Functional Group Header Level: Detail Usage: Required - By Implementation Guide


Ref Des Element Name Element Note GS02 Application Senders

Code Expect value: Trading Partner ID (8 characters)

GS03 Application Receivers Code

Enter value: 54704

834 Companion Guide


Segment: DTP File Effective Date Level: Header Usage: Required - By Implementation Guide


Ref Des Element Name Element Note DTP01 Date/Time Qualifier Enter code value: (choose one)

007 (File Effective Date) 303 (Maintenance Effective Date) 382 (Enrollment)

DTP02 Date/Time Period Format Qualifier

Enter code value: D8 (Date Expressed in Format CCYYMMDD)

DTP03 Date/Time Period Enter value: Date associated with file referenced above

834 Companion Guide


Segment: INS Member Level Detail Loop: 2000 Level: Detail Usage: Required - By Implementation Guide Business Rules:

The following Individual Relationship Codes are valid for all IBC / KHPEs products except as noted below:


Ref Des Element Name Element Note INS02 Individual Relationship

Code Enter code value: (choose one)

01 (Spouse) 05 (Grandson/Granddaughter) Non-HMO only 07 (Niece and Nephew) Non-HMO only 08 (Cousin) Non-HMO only 09 (Adopted Child) 10 (Foster Child) 17 (Stepson or Stepdaughter) 18 (Self Subscriber; Sponsored Dependent) 19 (Son or Daughter) 23 (Sponsored Dependent) Non-HMO only 24 (Dependent of Minor Dependent) 25 (Ex-Spouse) Non-HMO only 38 (Collateral Dependent) Non-HMO only 53 (Life Partner)

834 Companion Guide


Segment: REF Subscriber Number Loop: 2000 Level: Detail Usage: Required Business Rules:

This information should be transmitted for each member submitted.


Ref Des Element Name Element Note REF01 Reference Identification

Qualifier Enter code value: 0F (Subscriber Number)

REF02 Subscriber Supplemental Identifier

Enter value: Subscribers ID

834 Companion Guide


Segment: REF Member Identification Number Loop: 2000 Level: Detail Usage: Situational Business Rules:

This information should only be transmitted when required under the insurance contract between the plan sponsor and IBC / KHPE.


Ref Des Element Name Element Note REF01 Reference Identification

Qualifier Enter code value: DX (Department / Agency Number)

REF02 Subscriber Supplemental Identifier

Enter value: Enter payroll number

Note: This data element must be numeric to successfully process. (Refer to the ICM segment, on the next page, for payroll / work location.)

834 Companion Guide


Segment: NM1 Member Name Loop: 2100 A Level: Detail Usage: Required Business Rules:

This information should be transmitted for each member submitted.


Ref Des Element Name Element Note NM103 Member Last Name Enter value: Limited to 20 characters NM104 Member First Name Enter value: Limited to 19 characters

834 Companion Guide


Segment: ICM Member Income Loop: 2100 A Level: Detail Usage: Situational Business Rules:

This information should only be transmitted when required under the insurance contract between plan sponsor and IBC / KHPE.


Ref Des Element Name Element Note ICM04 Work Location Enter value: Enter work location

834 Companion Guide


VII. Business Processing Guidelines Customer Coverage Key Data

The eBusiness Deployment Consultant assigned to your group will provide you with a Coverage Key. To submit x12 834-v 4010A1 transactions, you will need the following information from the Coverage Key: Non-HMO Group Numbers required if you subscribe to Non-HMO lines of business HMO Account Numbers required if you subscribe to HMO lines of business HMO Group Numbers:

- Optional if you subscribe to HMO lines of business - Required for HMO Cobra Direct Pay (See Special Processing Situations below)

Coverage Code required if you subscribe to Non-HMO lines of business BCA Plan Code required if you subscribe to Non-HMO lines of business HMO Benefit Package ID required if you subscribe to HMO lines of business

Group and Account Numbers

Use the x12 834-v 4010A1 policy number data element to communicate the appropriate group or account number for each member transaction. The x12 834-v 4010A1 transaction set allows for policy number placement in several loops and segments. Header Loop - REF segment: called Master Policy Number and applies to all

members within the transaction set (ST SE)

Master Policy Number can be used if it is necessary to communicate an HMO Group Number. The HMO Group Number is optional except in specific contract situations. (See Special Processing Situations below) It is important to remember that when the Master Policy Number is used, it applies to all members within the transaction set.

Loop 2000 - REF segment: called Member Policy Number and applies to the member

in the preceding Loop 2000 / INS Segment and all coverage data provided in subsequent Loop 2300 / HD Segments

Member Policy Number will be used to communicate the Non-HMO Group Number or the HMO Account Number for each member or employee transaction. For currently enrolled members, the group or account number sent in the Member Policy Number field is always the group or account they are currently enrolled in. For new member enrollment, the Member Policy Number is the group or account they are enrolling in.

834 Companion Guide


If the member contract is split and more than one group number exists (e.g. HMO and an optional Non-HMO Drug or Vision coverage), Loop 2300 REF segment must be used. See the description below.

Loop 2300 REF segment: called Health Coverage Policy Number and applies to

the coverage provided in the preceding 2300 Loop HD Segment only

Health Coverage Policy Number is to be used to communicate situations where several Group and Account Numbers were provided for a coverage package or when coverage is split across lines of business. After each HD Segment, the respective Group or Account Number would be contained in a REF segment with a 1L qualifier.

Subscriber Processing

CHANGING a Members IDENTIFYING INFORMATION

INCORRECT MEMBER NAME To correct or change a members name, the 2100B Incorrect Member Name Loop / Segments must be submitted with only those data elements that are changing. If a name change is sent without the old name contained in these Loops / Segments, the transactions for that member will be rejected.

MEMBER ID CHANGES

Member ID changes should be submitted by using the Incorrect Member Name Loop.

DEMOGRAPHIC CHANGES

Changes to Gender Code and Date of Birth will be accepted within Loop 2100A DMG Segment or within the Incorrect Member Demographics Loop.

If the DMG Segment is populated with a different Gender Code or Birth Date than what is currently on file for the member, IBC / KHPE systems will process the data contained in the transaction as an update.

If the Incorrect Member Demographics Loop is sent, IBC / KHPE systems will update the member information accordingly.

834 Companion Guide


CHANGING COVERAGE

When changing existing coverage for a subscribers contract, dependent data must be provided. Dependent processing is described further in the DEPENDENT Section below. Specifics concerning Coverage Changes are further described in the COVERAGE CHANGES section below. Dependent information is not required when changing demographics that apply to an entire enrollment contract.

ALTERNATE ADDRESSES Addresses are maintained at the subscriber level and apply to each member covered on the contract.

Mailing Address: If sent, this address will replace the address of record for all members in the contract.

Responsible Party Address: If sent, Responsible Party Address will be accepted. An internal approval process must be completed before the address information is updated.

Custodial Parent Address: Custodial Parent information will be accepted. However, an internal Custodial Parent approval process must be completed before the address information is updated.

School Address: Dependent school addresses are used for informational purposes only and do not replace the address of record.

IDENTIFICATION CARD REPLACEMENT The 834 transaction permits the request of ID Cards via electronic transactions. If the ID card replacement Loop 2300 IDC is submitted to replace an ID card, the same Plan Coverage Description rules must be followed as stated in the COVERAGE section of this Companion Guide. Be advised that whenever a Members Name, Coverage, or PCP information changes, an updated ID card will automatically be sent. Therefore, it is not necessary to submit Loop 2300 - IDC in these cases.

834 Companion Guide


Dependent Processing

Dependent data must always follow subscriber data when both are supplied. Dependent demographics, (e.g. Gender Code and Birth Date) are required for every dependent transaction. NEW ENROLLMENT When submitting a new enrollment, all dependent information must be provided. REINSTATEMENT OF ENROLLMENT When reinstating an enrollment, all dependent information must be provided. CHANGES IN ENROLLMENT As stated in the HIPAA 834v4010A1 Implementation Guide, coverage changes cannot be implied. Therefore, to ensure continuity of coverage for dependents, always submit covered dependent data when adding, modifying, or terminating coverage. 1. Dependent-only Coverage Changes: Changes to contract coverage for a

dependent-only should be submitted as:

A subscriber change transaction followed by the dependent transaction (e.g. Subscribers INS and HD Maintenance Type Code = 001)

Example: If the subscriber wishes to drop his/her spouse from his/her dental coverage, the dependent INS Segment would indicate a change maintenance type code (001) and the dependent HD Segment would indicate a cancellation/termination maintenance type code (024). The appropriate coverage data must be provided in the dependent HD Segment (specifically the Plan Coverage Description field) and the termination date would be contained in Loop 2300 / DTP Segment with a qualifier of 349'.

2. Group / Account Transfers: If a change is made to a contract that requires a

change in Non-HMO Group or HMO Account Number, the following applies to dependent processing:

The dependents provided in the update transaction will be transferred to the new

group or account with the subscriber. Any dependents that are not provided in the transaction but are active on the old

contract in the old group or account will be removed when the transfer is effective.

Example: If the subscriber is retiring with benefits, a transaction to transfer the contract from the active employee group to the retiree group may be necessary. The transaction should include any dependents that will also be covered.

834 Companion Guide


3. Dependent Removal: If a dependent member is to be removed from a contract

(e.g. overage dependent removal, removal of former spouse, etc.), the transaction for that member is all that is required. If the subscriber record is sent, the subscriber transaction must be sent as a change transaction (e.g. Maintenance Type Code 001 at Loop 2000 / INS Segment). As recommended in the HIPAA 834v4010A1 Implementation Guide, the most efficient method of removing a member from a contract is to submit a Loop 2000 INS Segment with all required data and the Loop 2000 DTP Segment with the date qualifier of 357. When submitted in this manner, no further data is required.

4. Demographic Changes: Dependent information is not required when changing demographics that apply to an entire enrollment contract. If any dependent specific demographics are updated, a dependent change transaction may be submitted.

Example: If the dependent eligibility is maintained although that dependent may reside with a former spouse, a responsible party or custodial parent address may be necessary. If this condition is a change, a dependent change transaction may be submitted with the appropriate address information. See Alternate Addresses in the Subscriber Section of this Companion Guide.

TERMINATION OF ENROLLMENT When terminating an entire contract, dependent information is optional.

834 Companion Guide


Plan Coverage Description

The eBusiness Deployment Consultant will provide in the form of a Coverage Key the coverage information required in the Loop 2300, HD Segment, and HD04 Data Element. Loop 2300 HD Segment Data Element HD04 is called Plan Coverage Description. Plan Coverage Description is required when a transaction is adding, changing, or terminating coverage. Loop 2300 IDC Segment Data Element IDC01 is called Plan Coverage Description. Plan Coverage Description is required when requesting a replacement ID card.

FORMATTING PLAN COVERAGE DESCRIPTION For Non-HMO Coverage, a 4-character coverage code and a 3-digit BCA Plan Code are required in this field, separated by a dash (e.g. MM10-362). For HMO Coverage, a 4-character benefit code is required in this field in the following format: XNNN where X is an alpha character and NNN is a 3=digit numeric.

Coverage Changes

In order to ensure that changes in coverage process correctly in our systems, we strongly recommend submission of specific and individual transactions. This will require multiple transaction sets (ST SE) when multiple transactions apply to an individual member. (e.g. a member is terminating from one group and enrolling in another). When removing a coverage, send a termination / cancellation transaction for the member or

coverage. When adding coverage, send a separate add transaction for the member and new coverage. However, you have the option of submitting one transaction utilizing the change maintenance type code at the coverage level, which will result in a termination and an addition of old and new coverage, respectively. The description that follows describes processing at IBC / KHPE for each of the above methods of sending coverage changes in detail:

834 Companion Guide


EXAMPLE: SPECIFIC, INDIVIDUAL TRANSACTIONS

When the removal of an employee or member from one group or account and the addition of the same employee or member to a new group or account are sent explicitly, two (2) transactions are typically sent each within their own ST-SE. The first transaction will terminate or cancel the member from the group or account where

they are currently enrolled. The second transaction will add the member to the new group or account. The following provides the (member specific) Loops and Segment records expected for the termination and the add transactions: Termination or Cancellation from the current group or account

1) Loop 2000, INS Segment a. INS01 = Y b. INS02 = 18 c. INS03 = 024 (Cancellation or Termination) d. INS04 = AI (Depends on the Transaction - See Maintenance Type &

Reason Codes Section) e. INS05 = A (Depends on the Transaction) f. INS06 = * (Depends on the Transaction) g. INS07 = * (Depends on the Transaction) h. INS08 = * (Depends on the Transaction)

2) Loop 2000, REF Segment (Subscriber Number)

a. REF01 = 0F b. REF02 = Member Contract ID

3) Loop 2000, REF Segment (Member Policy Number)

a. REF01 = 1L b. REF02 = Non-HMO Group or HMO Account Number

4) Loop 2000, DTP Segment a. DTP01 = 357 Eligibility End or Termination Date b. DTP02 = D8 c. DTP03 = Termination Date from their current group or account

834 Companion Guide


Addition to another group or account

5) Loop 2000, INS Segment a. INS01 = Y b. INS02 = 18 c. INS03 = 021 Addition d. INS04 = AI (Depends on the Transaction - See Maintenance Type and Reason

Codes Section) e. INS05 = A (Depends on the Transaction) f. INS06 = * (Depends on the Transaction) g. INS07 = * (Depends on the Transaction) h. INS08 = * (Depends on the Transaction)

6) Loop 2000, REF Segment (Subscriber Number)


7) Loop 2000, REF Segment (Member Policy Number)

a. REF01 = 1L b. REF02 = new group or account number to be assigned

8) Loop 2000, DTP Segment

a. DTP01 = 356 b. DTP02 = D8 c. DTP03 = Date employee or member is being add to the new group or account

9) Loop 2300, HD Segment

a. HD01 = 021 b. HD03 = HLT (Depends on the Transaction) c. HD04 = XNNN (HMO), XXXX-NNN (Non-HMO) coverage id (see Coverage

Change Section) d. HD05 = E1D (Depends on the Transaction and is optional)

834 Companion Guide


EXAMPLE: ONE TRANSACTION SEVERAL UPDATES When a single transaction results in the transfer of an employee or member from one group or account to another group or account, the following provides the (member specific) Loop and Segment records to be submitted in this situation: Termination or Cancellation from a group or account and Add to another group or

account in one change transaction

1) Loop 2000, INS Segment Member Detail a. INS01 = Y b. INS02 = 18 c. INS03 = 001 Change d. INS04 = AI (Depends on the Transaction - See Maintenance Type &

Reason Codes Section) e. INS05 = A (Depends on the Transaction) f. INS06 = * (Depends on the Transaction) g. INS07 = * (Depends on the Transaction) h. INS08 = * (Depends on the Transaction)

2) Loop 2000, REF Segment - Subscriber Number


3) Loop 2000, DTP Segment

a. DTP01 = 303 Maintenance Effective b. DTP02 = D8 c. DTP03 = Maintenance Effective Date for Change

4) Loop 2100A, NM1 Segment - Member Name

a. NM101 = IL b. NM102 = 1 c. NM103 = Employee or members last name d. NM104 = Employee or members first name e. NM108 = 34 f. NM109 = Employee or members social security number

5) Loop 2100A, N3 and N4 Segments Member Residence Address

a. Provide only if it is changing

834 Companion Guide


6) Loop 2300, HD Segment Health Coverage One occurrence per coverage

a. HD01 = i. 002 or 024 Delete or Cancel (followed by the appropriate DTP and REF

segments) ii. 021 or 025 or 026 Add, Reinstate, or Correction: Any of these

maintenance type codes will be treated as an addition of coverage (followed by the appropriate DTP and REF segments)

b. HD03 = HLT (Depends on the Transaction) c. HD04 = XNNN (HMO), XXXX-NNN (Non-HMO) coverage id d. HD05 = E1D (Depends on the Transaction and is optional)

7) Loop 2300 DTP Segment Health Coverage Dates

(At least one DTP is required per Loop 2300 HD Segment) a. DTP01 = Date/Time Qualifier

i. 348 = Benefit Begin: Always provide for the coverage that is being added or transferred to

ii. 349 = Benefit End: Always provide for the coverage that is being cancelled or terminated. Benefit End must be used with HD01=024.

iii. 303 = Benefit Change Date: Provide for coverage being removed for a correction

b. DTP02 = D8 c. DTP03 = The actual date that applies to the qualifier above

8) Loop 2300 REF Health Coverage Policy Number

(At least one REF is required per Loop 2300 HD) a. REF01 = 1L b. REF02 = Group or Account that applies to the coverage in the previous HD

Segment The effect of the above transaction:

1. The coverage specified in Plan Coverage Description with a maintenance type code of 024/002 will be terminated as of the effective date in its respective DTP segment.

2. The coverage specified in the Plan Coverage Description with a maintenance type code

of 021/025/026 will be added effective the date in its respective DTP segments.

3. Please refer to the Dependent Processing Section of this Companion Guide for impact to covered dependents.

834 Companion Guide


Maintenance Type and Reason Codes

The 834 transaction contains numerous maintenance type and reason codes at various loops and segments. The following maintenance codes to be used to ensure accurate processing of your transactions:

1) Loop 2000, INS Segment, INS03: This Maintenance Type Code will determine the type of processing you are requesting for the specified member.

a. 021 Addition and 025 Reinstatement: The effect is the same for both codes -

the member is added to the contract.

b. 001 Change: Used when a members data is changing and their contract already exists. Use of this when a member does not exist will result in an error.

c. 024 Cancellation / Termination. Used when a contract is being terminated or

for the removal of individual members. Loop 2000, the INS DTP segment qualifier should be 357 in these cases.

(Note: If the member being removed is a dependent and family status is changing, the subscriber record should be included as a change - 001 with the new family status value.)

d. 030 Audit or Compare This code is only used when active membership

synchronization is scheduled. Transactional data is not to be sent in an Audit or Compare file.

2) Loop 2000, INS Segment, INS04:

This Maintenance Reason Code will not determine the type of processing you have requested for the member and is an optional data element in IBC / KHPE processing.

3) Loop 2300, HD Segment, HD01:

This Maintenance Type Code will determine the type of processing you are requesting for the member at the coverage level. The appropriate Date (DTP) segment must follow each of the following:

a. 001 Change indicates that the coverage exists and is changing (e.g. Family

status changes). b. 002 Delete indicates that the coverage described in the HD Segment is being

cancelled or terminated.

c. 021 Addition indicates that the coverage described in the HD Segment is being added to the members contract.

834 Companion Guide


Maintenance Type and Reason Codes (cont.)

d. 024 Cancellation or Termination indicates that the coverage described in the HD Segment is being cancelled or terminated.

e. 025 Reinstatement indicates that the coverage described in the HD

Segment is being added to the members contract.

f. 026 Correction indicates that the coverage described in the HD Segment is being added to the members contract.

It is preferred that 001-Change be used if the coverage is being modified and 002-Delete or 024-Cancellation or Termination be used to remove coverage.

g. 030 Audit or Compare indicates that the coverage described in the HD

Segment is provided to use in synchronization between the sender and the receiver.

834 Companion Guide


Coverage or Benefit Dates

The 834 transaction contains numerous maintenance dates at various loops and segments. The following describes the use of those dates in processing transactions at IBC / KHPE:

1) HEADER File Effective Date: This date is required and will be used as the valuation date of the file.

a. 007 File Effective Date is preferred.

b. 303 Maintenance Effective will be used in the same manner as File Effective Date.

c. 382 Enrollment will be used in the same manner as File Effective Date.

d. 388 Payment Commencement not a valid code for IBC / KHPE.

2) Loop 2000, Member Level Dates:

The following Date/Time Qualifiers affect the processing of member transactions:

a. 303 - Maintenance Effective Date: Provide for changes at the member level (e.g. Address changes).

b. 336 Employment Begin Date: This date is not required. However, if

provided for employee add transactions, this date will be stored.

c. 338 Medicare Begin Date: The date is not required unless you are sending members who qualify for Medicare Secondary Payer benefits.

d. 339 Medicare End Date: This date is not required unless you are sending

members who qualify for Medicare Secondary Payer benefits.

e. 340 COBRA Begin Date: This date is not required unless you are sending enrollment for members under COBRA.

f. 341 COBRA End Date: This date is not required unless you are sending

enrollment for members under COBRA.

g. 350 Education Begin Date: This date is not required unless you are communicating enrollment for or updating a dependent member who qualifies for benefits because of their student status. This only applies if you (the employer) are contractually required to perform overage dependent student verification.

i. Employer Performed Student Verification - If your contract requires

that you, as the employer, perform the verification of eligible overage dependents, the appropriate Student Indicator (Loop 2000, Member Level

834 Companion Guide


Detail - INS09) and School information (Loop 2100E, Member School) should be provided when available.

ii. Carrier Performed Student Verification If we, as the carrier, have agreed to perform the student verification of eligible overage dependents, do not send student data within the transaction set. Sending student information under these circumstances will result in an error.

h. 351 Education End Date: Provide when terminating dependent members

who qualified for benefits because of their student status. (See 350-Education Begin Date for Student Verification Rules).

i. 356 Eligibility Begin Date: Provide when enrolling an employee or eligible

member. This date will not be used in place of the coverage level effective dates.

j. 357 Eligibility End Date: Provide this date to:

i. Remove a member; (include only that member in the transaction). ii. Cancel or terminate a contract; (include the subscriber only otherwise, all

members will be terminated automatically).

3) Loop 2200 Disability Eligibility Dates: These dates should not be sent for an employee or member who has been verified as HANDICAP.

a. Communicating Handicap Status: Handicap members are indicated by valuing

Loop 2000 Member Detail, INS10 as a Y.

b. Handicap Status Verification: Upon receipt of a transaction that indicates a member is handicapped, our enrollment staff will verify the HANDICAP status.

4) Loop 2300 Health Coverage Dates: This date indicates when coverage is effective,

terminated or changed.

a. 303 = Maintenance Effective: When applicable, provide for each Loop 2300 HD Segment when the change is not the addition or cancellation of coverage.

b. 348 = Benefit Begin: When applicable, provide for each Loop 2300 HD Segment that adds coverage. It indicates when the coverage is effective.

c. 349 = Benefit End: When applicable, provide for each Loop 2300 HD Segment

that cancels or terminates coverage. It indicates when the termination is effective.

To terminate a contract (all coverage and members), refer to Loop 2000, Member Level Dates in this section and utilize the cancellation / termination qualifier 357.

d. 543 = Last Premium Paid Date: This qualifier will be ignored by IBC / KHPE in

processing.

834 Companion Guide


Communicating the Provider ID (PCP or NPI)

Primary Care Provider (PCP) is the 10 digit provider number for HMO products. National Provider Identifier (NPI) is a unique 10 digit identification number issued for Health Care Providers by Claims Management Systems (CMS). Both numbers (PCP and NPI) can be utilized in the ANSI 834 file format. 834 Loops/Segments are required to send PCP or NPI information.

To appropriately communicate the provider ID for HMO products, utilize the following:

Loop 2310 - Provider Information Segment Description

Code

LX01 Assigned Number 01 NM1 Provider Name (SITUATIONAL) NM101 Entity Identifier Code P3 - Primary Care Provider NM102 Entity Type Qualifier 1

NM103 Name Last or Organization Name Not Required

NM104 Name First Not Required

NM105 Name Middle Not Required

NM106 Name Prefix Not Required

NM107 Name Suffix Not Required

NM108 Identification Code Qualifier XX - For NPI SV - For PCP

NM109 Identification Code 10 digit NPI Value or 10 digit PCP

NM110 Entity Relationship Code 25 Established Patient 26 Not Established Patient 72 - Unknown

834 Companion Guide


Special Processing Situations

TRANSACTIONS INVOLVING MIXED LINES OF BUSINESS It is recommended that any transactions that involve coverage data in multiple lines of business (e.g. HMO and optional drug and vision) should be sent as individual transactions within multiple transaction sets (ST-SE). HMO COBRA DIRECT PAY MEMBERS Cobra members are those members who maintain their benefits through COBRA for whatever reason. HMO Cobra Direct Pay is unique in that the member is directly billed for the coverage and the member submits premium payments directly to the carrier. However, the group or organization will submit changes to the carrier when demographics or coverage information changes on behalf of the member. Your contract will specify whether or not the HMO Cobra Direct Pay option applies to your organization. When enrolling or updating a member in the HMO Cobra Direct Pay situation, you will have been provided an HMO Group Number only. (An HMO Account Number is established at the time of members enrollment and is unique to each individual member.) All transactions for HMO Cobra Direct Pay groups must include the Header Loop - REF Segment or Master Policy Number. It must contain the HMO Cobra Direct Pay Group Number provided to you in your Coverage Key. Therefore, all member transactions contained within the HMO Cobra Direct Pay transaction set (ST SE) must be enrolling or be enrolled in the HMO Cobra Direct Pay group.

834 Companion Guide


VIII. Transactional Testing Processes The purpose of this section is to outline IBC / KHPEs recommended testing processes. All trading partners must complete the IBC / KHPE testing process in order to provide both parties a level of confidence for a successful production implementation. It is recommended that the trading partner obtain HIPAA Certification from an approved testing and certification third party vendor, (e.g. CLAREDI), prior to testing.

Methodology and Requirements A trading partner must accomplish the following testing milestones prior to moving into production status:

1. Complete communication connectivity testing. 2. Submit test files electronically using the tested and approved method of

connectivity. 3. Submit test files that are 100% HIPAA compliant. 4. Submit test files for each of the lines of business and business test case that

the trading partner is planning to implement in production. 5. Successfully process all test files to both the trading partner and IBC /

KHPEs satisfaction. IBC / KHPE has established a number of required test cases and scenarios. The cases are categorized according to transaction type and line of business. This information is outlined in Appendix T of this Companion Guide. Choose only those that are applicable to the lines of business the trading partner subscribes. The assigned Enrollment Systems Analyst will assist you with establishing test cases. During a start-up implementation for the HIPAA X12 834v4010A1, the trading partner must test all of the required cases. However, it is recommended that as many additional cases as possible are tested, as this increases the expectation for a successful implementation.

834 Companion Guide


IX. APPENDIX A Please update the Employer EDI Profile on the next page. Electronically forward to your IBC / KHPE eBusiness Deployment Consultant or print and fax.

EMPLOYER EDI PROFILE

This completed form will communicate the introduction of a new trading partner or changes to a current trading partner. The clearinghouse-trading partner must submit one form per Employer Group submitted and complete

Sections II, III and IV. An Employer Group as the Trading Partner must complete section I, III, IV.

Clearinghouse Employer Group Date: _____________

I. Name: ______________________________________________ Trading Partner ID:______________

Are you currently submitting electronic transactions with IBC / KHPE? Yes/No

Use this form to indicate: Effective Date of Change: __/__/____ ___ A New Trading Partner

___ Add (or) ___Remove an Employer Group ___ Update the demographics associated with this Trading Partner ___Other _________________________________________________

II. Clearinghouse Information Name: ____________________________________________________________________________ Address: ___________________________________________________________________ City: ______________________________________________________________________________ State: __________ Zip Code: ______________

Executive Contact: Technical Contact:

Name: _________________________________ Name: _________________________________ Title: __________________________________ Title: __________________________________ Phone #: _______________________________ Phone #: _______________________________ Fax: ___________________________________ Fax: ___________________________________ Email: __________________________________ Email: __________________________________ III. Employer Group Information

Name: ________________________________________________________________________ Address: _______________________________________________________________________ City: __________________________________________________________________________ State: __________ Zip Code: ______________

Executive Contact: Technical Contact:

Name, Title: _____________________________ Name, Title: _________________________________ Phone #: ________________________________ Phone #: ___________________________________ Fax: ____________________________________ Fax: _______________________________________ email: __________________________________ email: ______________________________________

IV. Type of Connection:

___ CONNECT: Direct ___Secure FTP Server ___ IE (Information Exchange) ___ TCP/IP

Please return this form completed in its entirety to: Independence Blue Cross / KHPE.

Attention: eBusiness Deployment Department 1901 Market Street, 20th Floor Philadelphia, PA 19103-1480

834 Companion Guide


COMMUNICATION PROTOCOLS SUPPORTED

Asynchronous and synchronous communications are available for batch file transmissions. IBC / KHPE receives all batch data file transmissions on an OS/390 Enterprise Server. 1. sFTP

This method is available for external customers who want to receive or have PHI (Personal Health Information) data extracted via sFTP. IBC will send our SSH key to the client. It is IBCS standard to do sFTP through port 22. IBC will accept one IP address from the external customer. IBC must have a signed Business Agreement with the customer on file in the Corporate Compliance Office. The following information is needed.

Customer Name: Customer IP address: Customer server This can be exchanged via email with Network public key finger print: Systems Admin.

2. FTP with PGP Encryption: IBCs preferred method, FTP with PGP Encryption can be completely automated. IBC can schedule to pick up a customer file or deliver any reports to the customer without any manual intervention. This method is available for external customers who want IBC to pick up or deliver PHI (Personal Health Information) data via FTP. IBC and the customer will have to swap PGP keys. It is IBCS standard to do passive FTP through ports 20 and 21. IBC will accept one IP address from the external customer. The following information is needed. Customer Name: Customer IP address: Customer PGP key:

834 Companion Guide


3. Secure Transport Server (formerly FILEDRIVE):

For customers who cannot support the FTP connection, IBC has Secure Transport Server, a secure internet site where the customer would manually upload their file for IBC. Any reports would then by uploaded by IBC for the customer to pick up. Browser based interface for external customers to drop and pick up data via a secure lock connection over the Internet. Internet Explorer 5.0 and Netscape 4.75 or above are required for 128 bit encryption HIPAA compliancy. This method is suitable for those customers you will be sending and receiving PHI data (Personal Health Info). IBC will provide a userid and documentation for the external customer to access and use the Secure Transport Server. The following information is needed. Customer Name: Customer email address: Customer requires: File Drop Off File Pick Up

4. Connect:Direct (NDM): This option is available for customers who already have an existing connection established through a service provider (AT&T for example). The prospective customer must have an account with AT&T Global Services. The following information is needed. Global Services ID: Applid: Node ID: Net ID: For example: Global Services ID: INBC Applid: A28NDM2 Node ID: PENNIBCP.A28NDM2 Net ID: PENNIBCP

834 Companion Guide


X. APPENDIX B TRADING PARTNER AGREEMENT

834 Companion Guide


XI. APPENDIX T TESTING SCENARIOS

CYCLES/MILESTONES TYPE OF TRANSACTION BUSINESS USE CASE - SCENARIOS

CYCLE 1 Milestone #1 ADD Contracts using

Test Data; Connectivity Test

Add Single Contract Add Husband & Wife Contract Add Family Contract

Milestone #2 ADD Contracts using Test Data

Add Single Contract Add Husband & Wife Contract Add Parent & Child Contract Add Parent & Children Contract Add Family Contract

Milestone #3 ADD Optional Coverage to existing contracts using Test Data

Add Drug Coverage (when applicable) Add Dental Coverage (when applicable) Add Vision Coverage (when applicable)

Milestone #4 ADD Dependents to existing test contracts

Add Spouse Add Newborn Add Child Add Overage Student

CYCLE 2 Milestone #5 CHANGE to existing

Test contract demographic data

Change Home Address Change Home Telephone Number Change Last Name Change Last Name, Home Address,

and Telephone Number

834 Companion Guide


APPENDIX T (cont.) CYCLES/MILESTONES TYPE OF TRANSACTION

BUSINESS USE CASE - SCENARIOS

CYCLE 3 Milestone #6 ADD/TERM within

same and different groups / account using Test Contract Data

Change Groups (IBC / KHPE Grp To IBC / KHPE Grp) - Same Product

Change Groups (IBC / KHPE Grp To IBC / KHPE Grp) - Different Product

Change Groups (IBC / KHPE Grp To HMO Grp) - Different Product

Change Groups (HMO Grp To IBC / KHPE Grp) - Different Product

Add Additional Product Line Of Business (All Dependents)

Add Additional Product Lines Of Business (All Dependents)

Add Additional Product Line of Business (Member Only)

Add Additional Product Lines of Business (Member Only)

Milestone #7 ADD/TERM - Change Of existing Coverage within the same group

Change Coverage - Different Product (Same Group)

Change Coverages - Different Products (Same Group)

Change Coverage, Add Drug - Different Product (Same Group)

Change Coverages, Add Drug - Different Products (Same Group)

Change Coverage, Add Dental - Different Product (Same Group)

Change Coverages, Add Dental - Different Products (Same Group)

Change Coverage, Add Vision - Different Product (Same Group)

Change Coverages, Add Vision - Different Products (Same Group)

834 Companion Guide




CYCLE 4 Milestone #8 TERM of contract

using Test Contract Data

Term Single Contract Term Husband & Wife Contract Term Family Contract Term HMO Contract & IBC / KHPE Drug

Coverage (2 Different Groups) Term HMO Contract & IBC / KHPE

Dental Coverage (2 Different Groups) Term HMO Contract & IBC / KHPE

Vision Coverage (2 Different Groups) Milestone #9 TERM of Optional

Coverage only using test contracts

Term Drug Coverage (when applicable) Term Dental Coverage (when

applicable) Term Vision Coverage (when

applicable) Term Multiple Coverage (when

applicable) Milestone #10 TERM of

Dependents only using Test Contract Data

Term Spouse Term Child Term Children Term Spouse & Child(ren) Term Overage Student

Production Parallel Milestone #11

(applicable only when customer

is currently electronic)

Production Parallel testing of ADD, CHANGE and TERM when available; When not available submit a test file using production data

Add Single Contract Add Husband & Wife Contract Add Family Contract Add Line Of Business (IBC / KHPE

ONLY)) Change Home Address Change Home Telephone Number Change Last Name Term Single Contract Term Husband & Wife Contract Term Family Contract Term Line Of Business (IBC / KHPE

ONLY) Retiree Coverage (Member &

Dependent Records)

834 Companion Guide




Full Synchronization Data

Synchronization (Production Data)

See Section XII * We will determine Data Discrepancies

Implementation PRODUCTION

READY FILE Begin Transmission of Real Production

Enrollment Eligibility for Adds, Changes, and Terms

834 Companion Guide


XII. Full File Synchronization Requirements

Segment: BGN Beginning Segment Level: Header Usage: Required Business Rules:

This information should be transmitted for ST-SE contained in the file.


Ref Des Element Name Element Note BGN08 Action Code Enter code value: 4 (Verify)

834 Companion Guide


Segment: INS Member Level Detail Loop: 2000 Level: Detail Usage: Required Business Rules:

This information is required for each member submitted.


Ref Des Element Name Element Note INS03 Maintenance Type Code Enter code value: 030 (Audit or Compare)

INS04 Maintenance Reason Code

Enter code value: XN (Notification Only)

or Omit this data element

834 Companion Guide


Segment: HD Health Coverage Loop: 2300 Level: Detail Usage: Situational Business Rules:

This information is required for each member submitted.


Ref Des Element Name Element Note HD01 Maintenance Type Code Enter code value: 030 (Audit or Compare)

Documents

Ansi Companion Guide