ANSI 834 file, 5010 format
Guardian is the exception to the rule - the Self Service EDI Engine can transmit enrollment & eligibility data for the following plan models:
- Medical, Dental, Vision, Group/Basic & Voluntary Life & AD&D, STD, LTD, Accident & CI. Please see the note below for applicable instructions during the testing process.
- Dependent Basic Life is NOT supported
- No other plan types are supported at this time (as of October 2017)
Guardian has 2 Carrier Processing Systems:
- 834 5010/4010- Win SCP Portal/Vitria Mapping/ Zues Mainframe System - Supported by EN
- Proprietary- Win SCP Portal (Different Mapping)/Vitria/ Zues Mainframe System - Unsupported by EN
Plan Configuration/Setup Helpful Hints:
- Initiate request to transmit data to EDI Unit.
- Guardian will respond within 3-5 business days outlining process, providing file guide, naming convention, PGP key, and plan specific requirements. (Attach Guardian How to submit an electronic Eligibility Feed Test file Guide (see attached)
- Guardians Goal is to complete testing within 15 business days of the receipt of the first test file
- You will be required to complete an FTP Questionnaire as well (see attached)
- Guardian 834 companion guide is posted online: https://www.guardianlife.com/glife11pp/groups/camp_internet/@stellent_camp_website_glife_group_edits/documents/document/hipaa834_elec_enroll_userguide.pdf
- ISA06 = Sender's Federal Tax ID
- GS02 = Sender's Federal Tax ID
- GS06 = Unique Group Control Number assigned by the sender - recommend broker Federal Tax ID
- REF02 = Group Number
1000A Loop: Plan Sponsor Name
- N102 = Plan Sponsor/Company Name
- N104 = Plan Sponsor/Company Federal Tax ID
1000C Loop: TPA/Broker Name
- N101 = 'BO' if broker, 'TV' if TPA
- N102 = Broker or TPA Name
- N104 = Broker or TPA Federal Tax ID
2000 Loop: Member Level Detail
Carrier has many optional REF and DTP segments that may be used for transmitting additional date elements, based on plan design.
For simplicity, we recommend excluding all DTP segments, except the DTP_336 and DTP_337, unless carrier indicates otherwise. Many of the optional REF segments and the specific carrier use cases as listed below. if carrier doesn't indicate they need any of the following segments, they can be excluded from the file.
- REF_1L: Group or Policy Number (Employee and Dependents)
- REF01 = '1L'
- REF02 = Group Number provided on group structure
- REF_3H: Division Code (Employee)
- REF01 = '3H'
- REF02 = Division Code provided on group structure email
- REF_DX: Department Number (Employee and Dependent)
- REF01 = 'DX'
- REF02 = Department Number provided on group structure email
- REF_ZZ: Classification Code (Employee and Dependent)
- REF01 = 'ZZ'
- REF02 = Classification Code provided on group structure email
2100ALoop: Member Name
- Data in this loop has mostly been configured automatically to pull member demographic information. There are additional segments, which may not be needed based on the contracted plans. These can be excluded if not required by the carrier.
2100D Loop: Member Employer
- Situational loop, can be excluded if carrier does not require it.
2300 Loop: Health Coverage
Carrier will provide specific requirements for HD04 and REF segments needed for plan design. There are many other option REF which can be excluded if not required for the specific plan design.
- HD04: If more than one benefit is available, email will identify required value for HD04 (See below)
- HD05: Coverage Tier. Enter "EMP" in the Value field, unless email instructs otherwise (see below)
- REF_1L: Group or Policy Number
- REF01 = '1L'
- REF02 = Group Number provided on group structure
- REF_17: Situational, Email will identify if used
- REF01 = '17'
- REF02 = Email will identify value if used
- REF_ZZ: Situational, Email will identify if classification code needs to be sent in the 2300 loop
- REF01 = 'ZZ'
- REF02 = If needed, classification code value provided in email.
- Guardian is contractually obligated to offer benefits to eligible employees so they are given to any active member who may be passed without a class code. Please ensure the file is passing an accurate class for all employees.
- DTP: Member Level Dates
- DTP_348: Benefit Begins - Required
- DTP_349: Benefit Ends - Required
2310 Loop: Provider Information
- Optional loop will be identified in email if used.
- GE02 = Group Control Number (same value as GS06 in Header)
- Ended coverage will drop the latter of 14 days from the date terminated in the system or the termination date.
- Null coverage is set to transmit an end date equal start date
- Send the earliest eligibility start date (DTP356) & latest eligibility end date (DTP357)
- Send the latest maintenance effective date if included on file (DTP303)
- COBRA paid through date is set to transmit + 1 day
- PGP key ending in =8dK4 is saved at the carrier level. EN recommends sending SFTP with PGP encryption when the carrier permits to insure double layer of encryption.
Various Notes related to sending life model plans:
Employee Navigator's export engine is designed for 834 files that fit into the medical model. While we are able to accommodate the Guardian plan types in the 834 file, please note 2 items:
Mapping Benefit Volume (HD04):
If Guardian is requiring that you report the volume for a benefit, you have 2 options to map this value. From the 2300 Loop >> HD04, you can set the drop-down to "Benefit Amount." This will apply to ALL plans and there is no way to exclude one plan over another.
The other option would be to configure in Plan Options >>HD04 which will allow you to send a benefit volume based on each individual plan. Within that advanced tool, there are 2 options from the drop-down menu:
- "Benefit Amount" is the EN approved benefit volume based on plan configuration rules (GI specifically)
- "Requested Amount" is the EN pending amount; once approved, it goes back to full benefit amount. From our experience, Guardian wants to see the Requested Amount in a VL or non-GI level CI plan so we recommend that you confirm with Guardian as to their expectation for each plan type.
- If you do not want to send a volume at all, leave the specific plan set to "Select"
NOTE: If there is not a benefit volume associated with the voluntary plan the you cannot map the volume on the file from the HD04 value. For example, if you build a medical model Accident plan there is not a volume associated with it on the Benefit Summary, therefore it could not be mapped to "Benefit Amount" in either option outlined above.
- Mapping Coverage Tier values (HD05):
- Any plan that doesn't have a coverage tier assigned will need to have EMP entered in Loop 2300 HD05. That will enable the system to pass the coverage tier of EMP for the plans.
- When sending voluntary benefits for dependents Guardian requires an HD05 value of CHD for any children and SPO for a spouse in the HD05 segment. Employee Navigator's EDI engine does not currently export this information on the dependent record as the HIPAA 834 guide does not require or even recommend it. As a result, you will need to communicate to Guardian during testing that the HD05 will not transmit the relationship value for the dependent, in doing this they will know to overlook it during testing.
- Guardian's Open Enrollment file FAQs are attached - please review.
- Guardian's preferred open enrollment method is to include both open and ended enrollments on the file.
- Provide Guardian with the date the last eligibility maintenance file for the prior plan year will be sent
- The open enrollment file should be sent at least two weeks prior to the open enrollment effective date.
- Notify email@example.com when the open enrollment file is being sent.
- If there are any manual changes for the prior enrollment period after the file has been sent, these can be sent to GuardianMaintenance_Billing@glic.com.
- Production Files Contact/Technical Issues : firstname.lastname@example.org or
- Guardian will send error reports via Secure email.
- Guardian reports will have 3 attachments to include an EDI Reconciliation Report, an Explanation of Error Messages, and a Missing Information report. It is important to review both the EDI Reconciliation report and the Missing information report for errors/issues.