Mass Billable Charge Creation (Fully Insured Group and Individual)

Oracle Revenue Management and Billing provides the ability to create multiple billable charges for the health insurance business at once through the Upload Request feature. You can create regular pass-through and SQI based billable charges through an upload request. To create a pass-through billable charge, you need to specify at least one pass-through charge line details. Similarly, to create an SQI based billable charge, you need to specify at least one SQI based charge details. The regular billable charges are then considered during regular billing cycle.

You can also create non-recurring (i.e., one-time) and recurring billable charges through an upload request. Note that you can only specify a bill period for a recurring billable charge. Therefore, by default, the recurring flag of the record is set to BP when the bill period is specified in the record. You can create these billable charges at the group membership or individual membership level or at the policy plan level. If the group membership details could not be derived from the record, the system enables you to create a billable charge at the policy plan level. The system derives the appropriate contract against which the billable charge should be created at the membership or policy plan level.

The C1-BillableChargeUploadFI business object enables you to create an upload request for mass billable charge creation. You need to create an upload request type for the C1-BillableChargeUploadFI business object. You can then upload a mass billable charge creation file in the CSV format using the respective upload request type. The mass billable charge creation file should contain records with the following information – Contract or account details, start date, end date, description on bill, recurring details, pass-through charge line details or SQI based charge details, pricing information, and characteristic details. If the contract ID is not specified, the record should contain the following additional information:

• Subscriber Identifier Type, Subscriber Identifier, Membership Type, External Membership ID

• Source System, Policy Number, and Plan Number (only in case of the fully insured group business)

• Health Plan Code (only in case of the fully insured individual business)

For more information, see Mass Billable Charge Creation CSV Format (Fully Insured Group) and Mass Billable Charge Creation CSV Format (Fully Insured Individual).

On uploading a mass billable charge creation file, the system creates an upload request in the Draft status. The data records are created in the Pending status. The system validates the following for each record:

• Either the account ID or account identifier type and account identifier is specified in the record.

• Start and end dates are specified in the record.

• Price item is specified in the record.

• Either the contract ID or source system, policy number, and plan number is specified in the record for the fully insured group business.

• Either the contract ID or health plan code is specified in the record for the fully insured individual business.

If the account ID is not specified in the record, the system derives the account ID using the respective account identifier type and account identifier combination. If the system could not derive the account ID using the account identifier type and account identifier combination, the status of the record is changed to Invalid.

If the Plan Based Contract Creation Eligibility option type of the C1-ASOBLLNG feature configuration is not set to Yes and if the contract ID is not specified in the record, the system derives an active contract of the account for the coverage period using the contract type specified in the price item. However, if the Plan Based Contract Creation Eligibility option type of the C1-ASOBLLNG feature configuration is set to Yes and if the contract ID is not specified in the record, the system derives policy plan or health plan specific contract of the account for the coverage period depending on the information given in the record. Before deriving the contract for the fully insured group business, the system derives the policy plan ID using the source system, policy number, and plan number combination.

The system then derives the active contract for the policy plan using the contract type (associated with the price item), policy plan ID, and coverage period combination. However, in case of the fully insured individual business, the system derives the active contract for the health plan using the contract type (associated with the price item), health plan code, and coverage period combination. If the system could not derive the policy plan ID or contract ID, the status of the record is changed to Invalid. In addition, if any of the above validations fail, the status of the record is changed to Invalid.

The system then checks whether the characteristic type specified in the Membership ID Characteristic for Billable Charge option type of the C1-ASOBLLNG feature configuration is available in the record. If so, the system derives the membership ID from the specified characteristic in the record. However, if the required characteristic is not available in the record, this algorithm tries to derive the group or individual membership using either of the following combinations:

• Subscriber Identifier Type and Subscriber Identifier

• External Membership ID

• Membership Type, External Membership ID, Subscriber Identifier Type and Subscriber Identifier

On clicking the Validate button, the system checks whether the upload request must be validated in the real time (i.e., immediately) or in the deferred mode (i.e., in the background). If the total number of records in the upload request does not exceed the online record validate limit, the system validates the following in the real time:

• The account ID given in the record is valid.

• The contract ID given in the record is valid.

• The source system, policy number, and plan number given in the record are valid.

• The health plan code given in the record is valid.

• The membership ID or policy plan ID given in the record is valid.

• The policy plan number is unique for the given source system and policy number combination within the given date range.

• The external membership ID for the membership is unique across the system.

• The contract type specified in the price item belongs to the division of the account.

• The billable charge’s start date is equal to or later than the contract start date and earlier than or equal to the contract end date.

• The billable charge’s start date is equal to or earlier than the billable charge’s end date.

• The billable charge’s end date is equal to or later than the billable charge’s start date.

• At least one pass-through charge line or SQ based charge details is specified in the record.

• The Description on Bill, Amount, and Currency are specified when the record contains pass-through charge line details.

• The SQI and SQI Value are specified when the record contains SQ based charge details.

• The distribution code is required when the Memo Only flag of the respective pass-through charge line is set to N.

• The distribution code is not specified when the Memo Only flag of the respective pass-through charge line is set to Y.

• The distribution code given in the record is valid.

• The currency code given in the record is valid.

• The amount matches the decimal positions of the respective currency.

• The SQI given in the record is valid.

• The same SQI is not repeated multiple times in the record.

• The contract ID given in the record is valid and is not in the Canceled status.

• If both the account ID and contract ID are given in the record, the contract belongs to the account.

• The charge type given in the record is valid.

• The price item given in the record is valid.

• The Price Item Usage flag of the price item is set to Pricing and Billing.

• The contract type considered for billing should match the contract type specified in the price item.

• If the Use Calendar Billing field in the contract type is not set to Allow Advanced Billing, then bill after date is not earlier than the contract start date.

• The bill period given in the record is valid.

• If the Multi Price Parameter option type of the C1_​PPARM_​FLG feature configuration is set to TRUE, then only the price item is given in the record.

• The price item parameters are not specified when the price item is not given in the record.

• The same price item parameter is not repeated multiple times in the record.

• The characteristic type given in the record is valid and its characteristic entity is set to Billable Charge.

• The adhoc characteristic values are validated as per the validations defined in the respective algorithm.

• The predefined characteristic value is already defined for the characteristic type.

• The foreign key reference characteristic value is valid.

• The mandatory parameter of the price item is included in the record when the billable charge start and end dates fall within the price item parameter date range.

  Note: If the billable charge start and end dates do not fall within the price item parameter date range, the billable charge can be created without the mandatory price item parameter.

• The adhoc, predefined, and reference price item parameter values are valid.

• The source entity of the price item parameter is set to Transaction.

• Both the price item parameter and its value are given in the record.

• The price item parameter should be valid for the price item in the given date range.

If any of above validations fail, the status of the record is changed to Invalid. However, if all the above validations are successful, the status of the record is changed to Valid. Once all the pending records in the upload request are validated, the status of the upload request is changed to Validated.

However, if the total number of records in the upload request exceeds the online record validate limit, the system changes the status of the upload request to Deferred Validation. The system then validates the records and changes the status of the upload request from Deferred Validation to Validated when the C1-UPLRQ batch is executed.

On clicking the Submit button, the system checks whether the approval is required for the upload request. If the approval is required for the upload request, the status of the upload request is changed to Approval In Progress. However, if the approval is not required for the upload request, the status of the upload request is changed to Submitted.

The approver can either approve or reject the upload request based on the observations. On approving an upload request, the status of the upload request is changed to Approved. However, on rejecting an upload request, the status of the upload request is changed to Rejected.

Once the status of the upload request is changed to Submitted or Approved, the system checks whether the upload request must be processed in the real time (i.e., immediately) or in the deferred mode (i.e., in the background). If the number of valid records in the upload request does not exceed the online record process limit, the system changes the status of the upload request to Processing. However, if the number of valid records in the upload request exceeds the online record process limit, the system changes the status of the upload request to Deferred Processing. The system then changes the status of the upload request from Deferred Processing to Processing when the C1-UPLRQ batch is executed.

Once the status of the upload request is changed to Processing, the system fetches a list of records which are in the Valid status. For each valid record, the system checks whether the membership ID is available in the record. If so, the system creates a billable charge against the contract at the respective group or individual membership level. It then stamps the membership ID as a characteristic on the billable charge. While stamping the characteristic, the system considers the characteristic type specified in the Membership ID Characteristic for Billable Charge option type of the C1-ASOBLLNG feature configuration.

However, if the membership ID is not available in the record, the system checks whether the characteristic type specified in the Plan Id Characteristic Type option type of the C1-ASOBLLNG feature configuration is available in the record. If so, the system creates a billable charge against the contract at the respective policy plan level. It then stamps the policy plan ID as a characteristic on the billable charge. While stamping the characteristic, it considers the characteristic type specified in the Plan Id Characteristic Type option type of the C1-ASOBLLNG feature configuration.

If the characteristic type specified in the Plan Id Characteristic Type option type of the C1-ASOBLLNG feature configuration is not available in the record but if the contract ID is available in the record, the system creates a billable charge against the contract.

Finally, the status of the billable charge is set to Billable. Once the billable charge is successfully created, the status of the record is changed to Processed. However, if any error occurs while creating the billable charge, the status of the record is changed to Error. Finally, the status of the upload request is changed to Processed.