Membership Benefit Audit Process

Oracle Revenue Management and Billing enables you to calculate the charges for the availed Medicare Part D LIS, Medicare Part D LEP, or APTC benefit for the group or individual membership. The benefit charges are calculated and recalculated (whenever the benefit end date, amount, or status changes) using the Entity Audit framework. The entity audit framework is already configured for the C1-Benefits business object by:

• Setting the Eligible for Audit Event option type to Y

• Attaching the C1-FIAUDEV algorithm to the Audit system event

You need to create an active audit event type for the Benefits business object. While creating an active audit event type for the Benefits business object, you need to ensure the following:

• Set the status of the audit event type to Active

• Set the entity business object of the audit event type to Benefit

• Set the audit usage of the audit event type to Premium Calculation

• Ensure that the Update All option is not selected and the Add Action and Delete Action options are selected

• Add the fields (such as, benefitAmount and endDate) of the C1-Benefits business object for which you want to enable the audit process

• Add the statuses (such as, ACTIVE, INACTIVE, and DISCARD) of the C1-Benefits business object for which you want to enable the audit process

While creating or editing a membership benefit from the user interface, through a health care inbound message, or through the membership repricing inbound web service, the system derives the policy or health plan of the group or individual membership for which the benefit is created or updated. It then checks whether a benefit pricing rule type is associated with the policy or health plan. If so, the system refers the benefit pricing rule type associated with the policy or health plan. If the listed elements (such as benefit end date, benefit amount) are updated or when the status of the membership benefit is set to ACTIVE (during creation), INACTIVE (during modification), or DISCARD (when it is discontinued), the system creates an audit event for the membership benefit using the audit event type given in the benefit pricing rule type. Note that the system considers only the active audit event type given in the benefit pricing rule type.

The audit event is created in the Pending status. Note that the system creates one audit event for a membership benefit irrespective of the number of changes made to the membership benefit. In addition, an effective date is stamped corresponding to the audit event which later helps in deriving the timeline. Note that the effective date is set to the membership benefit's start date.

The system then creates a repricing entity detail record for each group or individual membership, pricing rule type, and effective date combination in the CI_​REPRC_​ENTITY_​DTL table. The status of the repricing entity detail record is set to P.

For example, an audit event is created while adding the following group and individual membership benefits:

For the AE1 audit event, the system creates three repricing entity detail records with the following combinations in the CI_​REPRC_​ENTITY_​DTL table:

• GRPMEM, AGE-BASED_​01, 01-Jan-2024

• GRPMEM, ADDITIONAL_​FEE_​01, 01-Jan-2024

• GRPMEM, BENEFIT_​01, 01-Jan-2024

Similarly, for the AE2 audit event, the system creates three repricing entity detail records with the following combinations in the CI_​REPRC_​ENTITY_​DTL table:

• INDMEM, AGE-BASED_​01, 01-Jan-2024

• INDMEM, ADDITIONAL_​FEE_​01, 01-Jan-2024

• INDMEM, BENEFIT_​01, 01-Jan-2024

Once the repricing entity detail records are created successfully, the status of the audit event is set to Complete. However, if an error occurs while creating the repricing entity detail records for an audit event, the status of the audit event is set to Error.