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

Files

Combined Enrollment & Payment File

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 Acknowledgment File

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

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 File

Oscar uses 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

Below are the 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.

What’s the difference between enrollment.external_policy_id, enrollment.application_id and enrollee.external_member_id?

• enrollment.external_policy_id: This is the enrollment primary key. It’s the vendor’s identifier for a policy that remains constant across policy updates and is shared by all members on a policy. For example, a change sequence such as INITIAL ENROLL -> ADD_DEPENDENT -> UPDATE DEMOGRAPHIC should maintain the same external_policy_id for all members on the policy. However, the id SHOULD change for situations such as:
  • Policy change
  • Renewal for new plan year
• enrollment.application_id: The vendor’s identifier for a specific enrollment application, and therefore only unique amongst initial enrollment and changes. This field is used by Oscar in a tracking capacity to augment the enrollment.external_policy_id. For example, if there is a change transaction for a family, there will be a new application_id, but the external_policy_id will remain the same.
• enrollee.external_member_id: The vendor's identifier for an enrolled member. This is used to ensure parity between vendor’s and Oscar’s identification of a member. Each member has their own ID (unlike external_policy_id), and the ID remains constant across time.

Servicing Agent Fields

In Oscar enrollments, we support two concepts of an attributable entity:

1. Broker / Agent of Record (AOR): This is the entity that is paid commissions by Oscar and owns the business, from Oscar's perspective.
2. Servicing Agent: This is the entity that has sourced the policy and has the right to service the member. This is commonly referred to as the writing agent from the platform's perspective.

While not required to include both, Oscar strongly recommends ICHRA vendors include both in their enrollment files for best member and platform experience.

Enrollment Transactions

Oscar's CSV enrollment files have different field requirements depending on the enrollment transaction type. Oscar supports the following transaction types:

Initial Enrollment

Use Enroll a new member or add new dependents to an existing policy.

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

Change Transactions

When any active member needs to change information, including demographic information, plan, mailing address, residential address, or coverage start date, platforms can send an enrollment transaction with a change type of CHANGE.

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.

Platforms should not use change type CHANGE to send updates to members' coverage end dates; changes to coverage end dates must be sent with change type CANCELLATION or TERMINATION.

Demographic Change

When to use: Changing an existing member's demographic information.

When sending Oscar a CHANGE type enrollment transaction, platforms need to include all the members’ information under the policy. For any member on the policy that has an update, include the changes as well as change type CHANGE. For any members on the policy that do not require updates, use change type 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 Table 2: Demographic change

Policy Change

When to use: Changing an existing member's policy.

Platforms should utilize a CHANGE enrollment transaction when a member switches policies mid-year due to a qualifying life event (QLE) and enrolling during a special enrollment period (SEP).

In the sample transaction below, members are changing their plan. The new plan has a change_effective_date of 2025-05-01, which is the date the new plan will go into effect.

Table 3. Policy change

Address Change

When to use: Updating an existing member's address.

Platforms should send a CHANGE change_type enrollment for residential or mailing address updates.

In the below example, the members’ new address would go into effect as of May 1, 2025 as indicated by the change_effective_date.

Table 4. Address change

Add Dependent

When to use: Adding a new dependent to an existing subscriber’s policy

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.

Table 5. Add dependent change example

Remove Dependent

When to use: Removing a dependent from an existing policy.

Use 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.

Table 6. Remove dependent change example

Leave platform

When to use: 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.

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.

Table 7. Leave platform change example

Cancellation & Termination Transactions

Cancellation (“Cancel”)

When to use: 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

Termination ("Term")

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.

Table 9. Terminations

Reinstatement Transactions

When to use: recover a cancelled/terminated policy with the original policy information and coverage start date.

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.

Table 10. Reinstatements

Appendix

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