| Field | member1 | member2 |
|---|---|---|
| plan.hios_id | 12345NY100001 | 12345NY100001 |
| enrollment.external_policy_id | plat_policy_ID_1 | plat_policy_ID_1 |
| enrollee.first_name | Joe | Jane |
| enrollee.ethnicity | 2135-1 | 2135-1 |
| enrollee.relationship_to_policy_holder | 18 (subscriber) | 01 (spouse) |
| enrollee.coverage_start_date | 2025-03-01 | 2025-03-01 |
| enrollee.coverage_end_date | (leave blank) | (leave blank) |
| enrollee.mailing_address.address_line_1 | 123 first st | 123 first st |
| enrollee.change_type | ADDITION | ADDITION |
| enrollee.change_effective_date | (leave blank) | (leave blank) |
| enrollee.addtional_maintenance_reason | (leave blank) | (leave blank) |
| … | … | … |
CSV Implementation Guide
Introduction
ICHRA Connect also supports a CSV file-based data integrations in addition to the EDI file-based data integration. This includes bi-directional data transfers for net new enrollments as well as other enrollment types, including terminations, cancellations, reinstatements and updates.
Integration Summary
The integration between a carrier and the administrator includes four CSV data files. All file directions are in relation to carrier:
- Inbound Enrollment File: Combined Payment & Enrollment
- Outbound Ack File: Enrollment file acknowledgment
- Outbound Enrollment File: Enrollment confirmation
- Outbound Reconciliation: Billing & Eligibility reconciliation
Combined Enrollment & Payment Spec.
The ICHRA Platform administrator sends the carrier member enrollment information and payment information in a single combined enrollment & payment CSV file (Inbound Enrollment File). Carrier ingests and enrolls members from this file as they would with a standard enrollment integration.
Payment information sent in this file includes one Automated Clearing House (ACH) account number per member (payment instrument). We do not accept credit card or debit card numbers as payment instruments.
At the time of enrollment, carrier enables Autopay for each enrolled member, withdraws members’ initial binder payments, and effectuates them. Members must affirmatively confirm that the employer will be making payments on their behalf as part of the administrator enrollment flow.
After autopay is enabled, carrier will automatically draft:
- Binder payments: before state regulatory deadlines, which may be as early as the enrollment date.
- Full outstanding balance: members may be drafted one or more times per month to ensure balance is paid by the premium due date. Exact auto-draft dates will be selected by carrier and the administrator.
More detailed specifications could be found in inbound spec page.
Enrollment file acknowledgment Spec.
Enrollment file acknowledgements verify whether enrollments and payment information were successfully received, or if problems were encountered. As such, the issuer will provide acknowledgement file for each inbound file received.
For more information on the acknowledgements sent by issuer, see acknowledge spec page.
Enrollment confirmation file Spec.
Enrollment confirmation files will be generated when enrollments were successfully effectuated by the carrier. These files provide confirmation for each enrollment processed, including details about the IDs that administrator could utilize to match the original enrollment, coverage effective dates, basic demographic information, status, etc. The administrator uses these files to ensure that enrollments have been successfully completed and to address any discrepancies.
For more information on the enrollment confirmation files sent by the carrier, see enrollment confirmation spec page.
Reconciliation
We use a weekly reconciliation file to ensure eligibility and billing data is aligned between carrier and the administrator in order to avoid disruptions to member coverage or experiences; for example, a mid-month increase to members’ premiums that could result in declined transactions at time of auto-pay.
The reconciliation file is a full change file that contains a snapshot of all plan year YTD membership, including cancelled and termed members, plus a 3 month prior-year lookback.
Each enrolled member will have one record per month enrolled with the corresponding monthly premium amount for that month.
Detailed Implementation Specifications
The sections that follow provide the instructions on how to implement enrollment and payment CSV specification for ICHRA platforms. Administrator will find several examples of potential enrollment transactions along with specific instructions for each.
Each section includes tables that specify the requirements for inbound enrollment. This implementation guidance highlights the key fields that must be changed, but does not imply these are the only fields required to send an enrollment. For the full table of columns, please refer to the csv specification.
Administrators can update the status of an ICHRA policy by submitting an initial enrollment, cancellation/termination, reinstatement and several policy maintenance updates.
Key Fields Descriptions
Below are descriptions of key fields that are commonly used across the CSV files for ICHRA integrations:
enrollee.issuer_member_id: The member ID assigned by issuer. issuer will generate a member ID when enrolling a new member. This ID will be sent back to the platform in the outbound confirmation file. Platforms need to utilize this ID within future enrollment transactions for this member.
enrollee.external_member_id: The member ID assigned by the platform. Platforms need to keep it constant.
enrollment.external_policy_id: The unique ID for the policy assigned by the platform.
enrollee.change_effective_date: the date when the intended change takes effect.
Enrollment Types
In this section, we will explain how the file looks like in different enrollment types
Enrollment Type: Initial Enrollment
Use case: Enroll a new member/family
Instructions: Typically, the Initial Enrollment transaction is the first transaction to be sent for a member. It is created after an applicant has been determined to be eligible and they have selected a Qualified Health Plan (QHP)
When members enroll in a new policy or add a dependent to an existing policy, regardless of whether the member is new or existing, the vendor sends “ADDITION” as the change type for all new enrollees.
Example Table 1. Initial Enrollment
Enrollment Type: Change Enrollment
When any active member needs to change information including demographic information, plan, mailing address, residential address, coverage start date, platforms can send an enrollment with change type of CHANGE for the member that contains any change. Platforms should not use enrollment with change type of CHANGE to send coverage end date change, that must be sent with change type as CANCELLATION/TERMINATION.
Unless otherwise specified, all the following change cases are assumed to occur after the initial enrollment. To minimize misunderstandings between removing and changing data, the platform should continue to send all data for fields that have not been altered.
Change Type: Demographic Change
Use case: Edit demographic information for an existing member Instructions: The platform sends Oscar a CHANGE enrollment. In the enrollment, the platform needs to include all the members’ information under the policy. If there is any change for a member, use change type of CHANGE for this member, otherwise, please use NO_OP.
In the example below, the subscriber changed their ethnicity, but there is no change for the dependent. In this case, subscriber’s change type would be CHANGE since there are changes involved, and dependents’s change type would be NO_OP since no change is made and no operation is required.
Example Subscriber found that their demographic information (In this example, the ethnicity) is incorrect and needs to be updated.
Table 2. Demographic change
| Field | member1 | member2 |
|---|---|---|
| enrollment.external_policy_id | plat_policy_ID_1 | plat_policy_ID_1 |
| enrollee.first_name | Joe | Jane |
| enrollee.ethnicity | 2135-2 | 2135-1 |
| enrollee.relationship_to_policy_holder | 18 (subscriber) | 01 (spouse) |
| enrollee.coverage_start_date | 2025-03-01 | 2025-03-01 |
| enrollee.coverage_end_date | (leave blank) | (leave blank) |
| enrollee.mailing_address.address_line_1 | 123 first st | 123 first st |
| enrollee.change_type | CHANGE | NO_OP |
| enrollee.change_effective_date | 2025-03-01 | (leave blank) |
| enrollee.addtional_maintenance_reason | (leave blank) | (leave blank) |
| … | … | … |
Change Type: Policy Change
Use Case: Switch policy for an existing member
Instructions: The platform will utilize a CHANGE enrollment transaction when a member switches policies mid-year due to a qualifying life event.
Example
In this case, the members are changing their plan effective 2025-05-01, meaning the change will take effect on 2025-05-01.
Table 3. Policy change
| Field | member1 | member2 |
|---|---|---|
| plan.hios_id | 12345NY100022 | 12345NY100022 |
| enrollment.external_policy_id | plat_policy_ID_1 | plat_policy_ID_1 |
| enrollee.first_name | Joe | Jane |
| enrollee.relationship_to_policy_holder | 18 (subscriber) | 01 (spouse) |
| enrollee.coverage_start_date | 2025-03-01 | 2025-03-01 |
| enrollee.coverage_end_date | (leave blank) | (leave blank) |
| enrollee.mailing_address.address_line_1 | 123 first st | 123 first st |
| enrollee.change_type | CHANGE | CHANGE |
| enrollee.change_effective_date | 2025-05-01 | 2025-05-01 |
| enrollee.addtional_maintenance_reason | (leave blank) | (leave blank) |
| … | … | … |
Change Type: Address Change
Use Case: Update the address of an existing member
Instructions: Platforms send a CHANGE change_type enrollment for residential or mailing address updates.
Example
In this case, the members’ new address would go into effect as of May 1, 2025 as indicated by the change_effective_date.
Table 4. Address change
| Field | member1 | member2 |
|---|---|---|
| plan.hios_id | 12345NY100022 | 12345NY100022 |
| enrollment.external_policy_id | plat_policy_ID_1 | plat_policy_ID_1 |
| enrollee.first_name | Joe | Jane |
| enrollee.relationship_to_policy_holder | 18 (subscriber) | 01 (spouse) |
| enrollee.coverage_start_date | 2025-03-01 | 2025-03-01 |
| enrollee.coverage_end_date | (leave blank) | (leave blank) |
| enrollee.mailing_address.address_line_1 | 123 first st | 123 first st |
| enrollee.change_type | CHANGE | CHANGE |
| enrollee.change_effective_date | 2025-05-01 | 2025-05-01 |
| enrollee.addtional_maintenance_reason | (leave blank) | (leave blank) |
| … | … | … |
Change Type: Add Dependent
Use Case: Add a new dependent to an existing subscriber’s policy
Instructions: use CHANGE change_type for the subscriber and ADDITION for the new dependent. Platforms should send all information for the covered members whether or not there is a change for those members. If there is a change for a member, use change type of CHANGE for this member; otherwise, use NO_OP.
Example
Table 5. Add dependent change
| Field | member1 | member2 | member3 |
|---|---|---|---|
| enrollment.external_policy_id | plat_policy_ID_1 | plat_policy_ID_1 | plat_policy_ID_1 |
| enrollee.first_name | Joe | Jane | Jack |
| enrollee.relationship_to_policy_holder | 18 (subscriber) | 01 (spouse) | 19 (child) |
| enrollee.coverage_start_date | 2025-03-01 | 2025-03-01 | 2025-05-01 |
| enrollee.coverage_end_date | (leave blank) | (leave blank) | (leave blank) |
| enrollee.mailing_address.address_line_1 | 123 first st | 123 first st | 123 first st |
| enrollee.change_type | CHANGE | NO_OP | ADDITION |
| enrollee.addtional_maintenance_reason | (leave blank) | (leave blank) | |
| … | … | … | … |
Change Type: Remove Dependent
Use Case: To remove a dependent from an existing policy
Instructions: use the change_type CANCELLATION or TERMINATION. If the coverage end date is equal to coverage start date, it will be categorized as CANCELLATION; otherwise, use TERMINATION. The platform needs to send the information for all covered members, regardless of whether there is any change for these members. If there is any change for a member, use change type of CHANGE for this member; otherwise, use NO_OP.
Since the financial amount for the subscriber will change if members want to remove the dependent, the change type of subscriber should be CHANGE.
Example:
Table 6. Remove dependent change
| Field | member1 | member2 |
|---|---|---|
| enrollment.external_policy_id | plat_policy_ID_1 | plat_policy_ID_1 |
| enrollee.first_name | Joe | Jane |
| enrollee.relationship_to_policy_holder | 18 (subscriber) | 01 (spouse) |
| enrollee.coverage_start_date | 2025-03-01 | 2025-03-01 |
| enrollee.coverage_end_date | (leave blank) | 2025-03-01 |
| enrollee.mailing_address.address_line_1 | 123 first st | 123 first st |
| enrollee.change_type | CHANGE | CANCELLATION |
| enrollee.addtional_maintenance_reason | (leave blank) | (leave blank) |
| … | … | … |
Change Type: Leave platform
Use case: If an employer decides to switch ICHRA platform administrators or an employee loses their ICHRA benefits (e.g. through loss of a job), they still may retain their carrier’s ACA IFP coverage as a non-ICHRA member and pay for their coverage out of pocket.
For administrator platforms, this is especially important to implement to avoid having premium payments withdrawn or failed autopay runs for employees and employers who are no longer using your platform.
Instructions: To let the carrier know when a member is no longer enrolled through the administrator platform but has not terminated their coverage, the administrator will send a CHANGE type enrollment transaction with maintenance reason code LEAVE_PLATFORM on an inbound enrollment transaction.
Example:
Table 7. Leave platform change
| Field | member1 | member2 |
|---|---|---|
| enrollment.external_policy_id | plat_policy_ID_1 | plat_policy_ID_1 |
| enrollee.first_name | Joe | Jane |
| enrollee.relationship_to_policy_holder | 18 (subscriber) | 01 (spouse) |
| enrollee.coverage_start_date | 2025-03-01 | 2025-03-01 |
| enrollee.coverage_end_date | (leave blank) | (leave blank) |
| enrollee.mailing_address.address_line_1 | 123 first st | 123 first st |
| enrollee.change_type | CHANGE | CHANGE |
| enrollee.change_effective_date | 2025-08-15 | 2025-08-15 |
| enrollee.addtional_maintenance_reason | LEAVE_PLATFORM | LEAVE_PLATFORM |
| … | … | … |
Enrollment Type: Cancellation/Termination
Cancellation (“Cancel”)
Use Case: Terminate a policy before coverage has begun (i.e. coverage start date is in the future) Instructions: A cancellation will result in coverage being cancelled for all members on the policy, but only the subscriber’s information needs to be sent. To cancel a member’s policy, the change type for the subscriber must be set to CANCELLATION.
Please note that the coverage end date will be the same as the coverage start date for cancellation.
Example:
Table 8. Cancellations
| Field | member1 |
|---|---|
| enrollment.external_policy_id | plat_policy_ID_1 |
| enrollee.first_name | Joe |
| enrollee.relationship_to_policy_holder | 18 (subscriber) |
| enrollee.coverage_start_date | 2025-03-01 |
| enrollee.coverage_end_date | 2025-03-01 |
| enrollee.mailing_address.address_line_1 | 123 first st |
| enrollee.change_type | CANCELLATION |
| enrollee.addtional_maintenance_reason | (leave blank) |
| … | … |
Termination (“Terminate”)
Use Case: Terminate a policy after coverage has begun (i.e. coverage end date is after coverage start date) Instructions: To terminate a member’s policy, the change type for the subscriber must be set to TERMINATION. The platform only needs to send the subscriber’s information.
Please note that the coverage end date will not be the same as the coverage start date for termination.
Example:
Table 9. Terminations
| Field | member1 |
|---|---|
| enrollment.external_policy_id | plat_policy_ID_1 |
| enrollee.first_name | Joe |
| enrollee.relationship_to_policy_holder | 18 (subscriber) |
| enrollee.coverage_start_date | 2025-03-01 |
| enrollee.coverage_end_date | 2025-10-15 |
| enrollee.mailing_address.address_line_1 | 123 first st |
| enrollee.change_type | TERMINATION |
| enrollee.addtional_maintenance_reason | (leave blank) |
| … | … |
Enrollment Transaction Type: Reinstatement
Use case: recover a cancelled/terminated policy with the original policy information and coverage start date.
Instructions:
The change type for the subscriber must be set to REINSTATEMENT, and a transaction must be sent for all members on the policy who should be reinstated
If the members update their information during the reinstatement procedure, the platform needs to send another change enrollment to include the updated information.
Example:
Table 10. Reinstatements
| Field | member1 | member2 |
|---|---|---|
| enrollment.external_policy_id | plat_policy_ID_1 | plat_policy_ID_1 |
| enrollee.first_name | Joe | Jane |
| enrollee.relationship_to_policy_holder | 18 (subscriber) | 01 (spouse) |
| enrollee.coverage_start_date | 2025-03-01 | 2025-03-01 |
| enrollee.coverage_end_date | (leave blank) | (leave blank) |
| enrollee.mailing_address.address_line_1 | 123 first st | 123 first st |
| enrollee.change_type | REINSTATEMENT | REINSTATEMENT |
| enrollee.addtional_maintenance_reason | (leave blank) | (leave blank) |
Appx
Refunds
Eligibility changes resulting in premium changes, negative or positive, will be handled as usual for IFP members: adjustments will be made to future amounts owed, and if not sufficient, carrier will be able to facilitate refunds directly to members.
File Details
Inbound Enrollment File
- Direction: Carrier inbound/administrator outbound
- File type: CSV
- File spec: Inbound Enrollment Spec
- Cadence: Daily
- Naming convention: FROM_ADMIN_NAME.EMT.YYYYMMDDThhmmss.P.csv
- Delta file or full file: Delta
- File transfer type: SFTP
- Sample file: here
Outbound Enrollment Ack File
- Direction: Carrier outbound/administrator inbound
- File type: CSV
- File spec: Outbound Enrollment Ack File Spec
- Cadence: Daily
- Naming convention: TO_ADMIN_NAME.ACK.YYYYMMDDThhmmss.P.csv
- Sample file: here
Outbound Enrollment File
- File type: CSV
- File spec: Outbound Enrollment File
- Cadence: Daily
- Naming convention: FROM_CARRIER.OUT.YYYYMMDDThhmmss.P.csv
- Delta file or full file: Delta
- Sample file: here
Outbound Reconciliation File
- File type: CSV
- File spec: Outbound Reconciliation File
- Cadence: Weekly
- Full or Delta: Full snapshot of plan year, with 3 month look back to previous year
- Naming Convention: FROM_CARRIER_SNAPSHOT.OUT.YYYYMMDDThhmmss.P.csv
- Sample file: here