Reconciliation of Individual Health Insurance Subsidy Payments

Several states have established health insurance exchanges to offer health and dental insurance coverage options to their respective residents. Individuals within these states can compare and purchase coverage from a selection of health and dental plans, which are referred to as Qualified Health Plan (QHP).

Individuals who enroll for these QHPs may be eligible for Federal Tax Credits and Cost-Sharing Reductions (CSRs), which are subsidies based on the subscriber's income, to help pay for their health insurance and lower their out-of-pocket costs. The Centers for Medicare & Medicaid Services (CMS) makes monthly payments to insurers for the individuals who receive these credits.

CMS has established and instituted the State-Based Exchange (SBE) or Federally Facilitated Marketplace (FFM) reconciliation process to ensure that insurers enrollment information aligns with Marketplace enrollment information. The dispute process provides a mechanism for insurers to correct an FFM enrollment record or related payment information that the monthly reconciliation process cannot resolve.

Oracle Revenue Management and Billing (ORMB) may receive either the exact or different payment amount from the exchange for the sponsored charges due to various reasons. ORMB now enables you to reconcile the payments from the exchange against the bill line items for the fully insured individual business, thereby ensuring that the discrepancy is identified and resolved on time to quickly recover the money from CMS via the dispute process.

The reconciliation process in ORMB is enhanced to support both the fully insured group business and fully insured individual business. For the fully insured group business, the system stamped the policy ID and plan ID in the C1_FT_EXT table while freezing a financial transaction on the bill completion. These details were later used to reconcile the pay instructions against the bill line items. In this release, the C1-STMPFTINF algorithm type (which is attached on the FT Freeze system event of a customer class) is enhanced to support the fully insured individual business. It stamps the health plan code and price item in the C1_FT_EXT table while freezing a financial transaction on the bill completion for the fully insured individual business. These details are later used to reconcile the pay instructions received from the exchange against the bill line items of the exchange account.

A new field named Reconciliation Category is available while defining a reconciliation type. It helps to differentiate between the fully insured group and fully insured individual reconciliation objects. If you want to upload and process a pay instruction file for a fully insured group business using a reconciliation type, you must set the reconciliation category of the reconciliation type to Group. However, if you want to upload and process a pay instruction file for a fully insured individual business using a reconciliation type, you must set the reconciliation category of the reconciliation type to Individual.

A new algorithm type named C1-PAYINSEXC is introduced in this release. You need to attach an algorithm created using the C1-PAYINSEXC algorithm type to the Upload Pay Instructions system event of a reconciliation type where the reconciliation category is set to Individual. This algorithm parses a pay instruction file which is received from the exchange. It reads each record in the pay instruction file and creates one or more pay instructions in a reconciliation object depending on the number of exchange payment types received in the record. For example, if a record contains information about two exchange payment types (i.e. EP1 and EP2), the system will create two pay instructions for the record - one for EP1 and another for EP2. The exchange payment types (i.e. health insurance coverage) maintained in the CMS system might be different from the price items maintained in ORMB. Therefore, ORMB enables you to map an exchange payment type with a price item using the C1-PayTypePrcItemMap extendable lookup. Note that no values are shipped for this extendable lookup from the product. You need to create a value for the C1-PayTypePrcItemMap extendable lookup wherein each payment type received from the exchange is mapped to a price item. You can map a price item to one or more payment types based on the requirements.

While creating an algorithm using the C1-PAYINSEXC algorithm type, you need to specify the following parameters:

Pay Instruction Business Object - Used to indicate the business object using which you want to create a pay instruction.
Date Format - Used to indicate the format in which you want to store the coverage period start and end dates.
Payment Type - Price Item mapping - Used to indicate the C1-PayTypePrcItemMap extendable lookup value using which you want the system to derive the price item for each payment type received from the exchange.

The system enables you to upload a pay instruction file received from the exchange in the CSV file format. You can upload pay instruction files in the CSV format from the specified location on the server using the Pay Instruction CSV File Upload (C1-RECUP) batch. While receiving a pay instruction file from the exchange, you need to ensure that each record in the pay instruction file contains the following information:

Payor (i.e. exchange person) or its account from where the payment is received
Subscriber (i.e. individual membership) for whom the payment is received
Health plan and its coverage period for which the payment is received
At least one exchange payment type (i.e. health insurance coverage) and its subsidy amount which is sponsored by the exchange

Note:

The system assumes that the exchange person will have only one account. Therefore, if an exchange person has multiple accounts, the system will not allow you to upload and process a pay instruction file received from the respective exchange. Hence, if the exchange person has a single account in the system, you can either provide the payor or its account details in the record. However, if the exchange person has multiple accounts in the system, you must provide the payor's account details in the record.

You can create an exchange person and its account in the system through the health care inbound message. While creating an account for an exchange person, ensure that you set the Eligible for Member Reconciliation (C1-RCELG) characteristic of the account to Y.

You can specify either the health plan code or Health Insurance Oversight System (HIOS) ID in the record. If you are planning to use the Health Insurance Oversight System (HIOS) ID for a health plan, you need to attach an algorithm created using the C1-STMPHLPN algorithm type to the Enter system event (with the lowest sequence number) of the Pending status in the C1-MemberReconciliation business object. This algorithm will then derive the code of the health plan, to which the individual is enrolled for the coverage period, using the HIOS ID. Note that, while creating a pay instruction, the system will derive the health plan code when the HIOS ID is present in the record irrespective of whether the health plan code is present in the record or not. However, if the HIOS ID is not present in the record, the system will use the health plan code that is present in the record.

If a subscriber has enrolled for multiple insurance coverages of a health plan for the same coverage period and if the subscriber is eligible for subsidy for one or more insurance coverages, you will receive the subsidy amount for the respective insurance coverages from the CMS system. The subsidy information is received in the form of exchange payment type and amount. At a time, you can specify maximum 10 exchange payment types and their amounts in each record of a pay instruction file.

The C1-RECUP batch is enhanced to support the fully insured individual business. On executing the C1-RECUP batch, the system reads the pay instruction file from the specified location and validates it. Once a file is successfully validated, the reconciliation object is created for the file in the Draft status. The reconciliation object is immediately transitioned to the Send Notification status and the algorithms attached to the Send Notification status are executed. Once the To Do is created, the status of the reconciliation object is changed to Pending. One or more pay instructions are created for a record of a pay instruction file and its status is set to either Pending or Error depending on whether it is successfully validated or not. While creating a pay instruction, the system derives the health plan code (if not available), individual membership and the exchange account. For more information about the C1-RECUP batch, refer to Oracle Revenue Management and Billing Batch Guide.

You need to then specify the payment ID against which you want to reconcile the bill line items for which you have received the pay instructions. Once you specify the payment information and submit the pay instructions for reconciliation, the payment amount is distributed against the reconciliation contract of the exchange accounts for which you have received the pay instruction. The status of the reconciliation object is changed to Pending Reconciliation. On reconciling the pay instructions, the system finds the open and unmatched bill line item of the exchange account against which the pay instruction must be reconciled using the health plan, subscriber, price item, and coverage period combination. The system creates a reconciliation adjustment for a pay instruction which is successfully reconciled. While reconciling the pay instructions, the system sets the pay instruction matching level characteristic type of the reconciliation object to MEMBER.

You can manually reconcile the pay instructions of a reconciliation object, or you can execute the Reconciliation Periodic Monitor (C1-RCNM) or Pay Instruction Processing Batch (C1-RCPM) batch at regular intervals to reconcile the pay instructions.

Note: While executing the C1-RCPM batch, you need to specify a member reconciliation preference whose attributes you want to use while reconciling all pay instructions of a file at the member level.

For more information about the above batches, refer to Oracle Revenue Management and Billing Batch Guide.

If you attach an algorithm created using the C1-VALMRPYCN algorithm type to the Payment Cancellation system event of the required customer class, the system automatically cancels the payment and reconciliation object associated with the payment when you cancel its corresponding payment tender. The status of the reconciliation object is changed to Pending Cancelation and the status of all pay instructions in the reconciliation object is changed to Canceled.

If required, you can also manually cancel a reconciliation object. However, you can cancel a reconciliation object only when it is in the Open or Completed status. On canceling a reconciliation object, the status of the reconciliation object is changed to Pending Cancelation. Before canceling a pay instruction, the reconciliation adjustment (if any) corresponding to the pay instruction is also canceled.

You need to configure the Reconciliation Cancellation Periodic Monitor (C1-RCNMD) batch to execute at the regular intervals. This batch monitors whether there are any reconciliation objects in the Pending Cancelation status. If there is a reconciliation object in the Pending Cancelation status, the status of the reconciliation object and the status of all pay instructions in the reconciliation object is changed to Canceled. For more information about the C1-RCNMD batch, refer to Oracle Revenue Management and Billing Batch Guide.

If all pay instructions in a reconciliation object are successfully reconciled, the system changes the status of the reconciliation object to Completed. However, if one or more pay instruction in a reconciliation object is not successfully reconciled, the system changes the status of the reconciliation object to Open. If you want the system to automatically reconcile the open pay instructions of the account when you bill the account each time, you need to attach an algorithm created using the C1-RCLOPNRCN algorithm type to the Post Bill Completion system event of the required customer class. The system will then trigger the reconciliation process to reconcile the open pay instruction against the open and unmatched bill line item of the exchange account and will accordingly update the status of the pay instruction and reconciliation object.

If you attach an algorithm created using the C1-VLPYINACN algorithm type to the Adjustment Cancellation system event of the adjustment type (using which the reconciliation adjustments are created), the system ensures that no one can cancel a reconciliation adjustment until it is linked to a non-canceled pay instruction.