Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

About the process

Updated on April 26, 2021

During benefit determination, each individual claim line is mapped to a corresponding benefit that has been configured in the Pega Foundation for Healthcare application’s Flattened structure. The Benefit Repository which would typically be housed in a Product application would use a utility to push the Benefit data to send it to the flattened structure of the foundation application. Claims data is then matched on a claim-line by claim-line basis and the benefit matched is placed on the clipboard which is used for the adjudication.

The claim data required to successfully execute benefit determination varies according to the benefits that are represented in the adjudicated claim. However, these key elements are consistently used in identifying each core benefit:

  • Header — Primary Diagnosis and Bill Type Code (institutional claims)
  • Claim Line — Procedure Code, Rendering Provider, and Place of Service (professional claims)

As part of the benefit determination, now users have an option to select multiple diagnosis codes for determining a specific benefit.

In Business analyst portal, under system settings configuration page, the user will have an option to select how many diagnosis codes should be considered for determining a benefit. The below is the snap shot as how the user can select how many diagnosis codes he can choose for benefit determination.

The configuration is applicable only for Professional and Dental claims. For both P and D claim types, the user can select a maximum of 4 Diagnosis codes at the claim line level and hence the configuration option is given to choose maximum up to 4 diagnosis codes to be considered for benefit determination.

Information retrieved once a benefit is matched can be broken down into three Subcategories: Product / Plan information, Benefit Definition Information and Benefit Coverage Information. Once the core benefits are identified, retrieving the remaining conditional data, such as cost shares, limits, and authorization requirements, requires additional data from the claim, such as age, sex, and provider tier.

The successful matching and validation of benefits on a claim-line by claim-line basis results in the continued progression of the claim to the next sequenced module. Unsuccessful benefit matching or validations typically results in the creation of audit messages or the pending of claims for manual review, as required. Once the Plan is matched to, it shows up as follows on the claim:

All the Plan Level details available in the Flatten Structure would be seen once clicked on the hyperlink.

Once the Benefit is matched to, the benefit hyperlink would show up as follows on the claim.

Once the Benefit hyperlink is clicked, it would show all the information available in the flattened structure for the given Benefit:

Process steps:

The benefit determination module retrieves all the benefits associated with a claim and then accurately maps each benefit to each individual claim line.

  1. The process starts with CE_DetermineBenefitES collection. Within this collection, first step would be to consider the Benefit Network.
  2. DetermineBenefitNetwork DT will fetch the benefit network. The process will be like as specified below.
    1. If a network is found in rate sheet selection module then this network will be considered in benefit determination to cross walk through the PCS network and find whether the claim can be adjudicated as in-network or out-network or needs to be suspended.
    2. If a network is determined in the rate sheet module then this network will be compared against the HCIF network if configured with the plan participating network. If this is the case, then the claim will be processed as an in-network/participating network.
    3. If a network is determined in the rate sheet module then this network will be compared against the participating network within the plan based on cross walk of HCIF network configured within the PCS network. If participating network is not found, then the claim will be processed as a non-participating/out of network.
    4. If a network is determined and the participating network is not found through cross walk, then SCE will check for non-participating network and if non-participating network is not found then SCE will raise an event SBD-0022
    5. As part of the rate sheet selection, if no network is found then in benefit determination, out of network will be considered for adjudication.
    6. As part of the rate sheet selection, if no network is found then in benefit determination also no out of network is found then the system will raise SBD-0022 event.

    The high-level benefit network determination flow will be like as shown below.

  3. The second step will be DetermineBenefitES Activity, which consist of a data transform that enables the data page initialization and clipboard setup prior to identifying and retrieving the required benefit data.
  4. Within the DetermineBenefitES itself are Java Calls / Elastic search call is created which fetches the Benefit based on different matching criteria. The benefits from the selected product are now matched to the properties on a claim-line by claim-line basis, retrieved, and placed on the clipboard.
  5. In the Last Step of the DetermineBenefitES activity, each core benefit data such as cost shares, benefit limits, and authorization requirements that contribute to the benefit’s unique corresponding conditions.is fetched.
  6. The last step within the CE_DetermineBenefitES collection will be “Service Covered” flag check: Once the Benefit is determined then SCE will now check the “Service Covered” flag. This flag can be configured at the benefit level in the flattened structure (using PCS).
  7. The below snap shot in PCS instance where the user can configure whether the benefit is covered or not.

If the box was checked it means the benefit Is not covered and the Claim can be denied using the event code SBD-0006.

Even if the claim line hits the benefit as the Service covered flag is checked in, this benefit will not be considered for processing and that line will be denied.

Benefit Determination0006Claim line levelClaim Line did not match any of the Coverages listed for this BenefitThis Event code is raised when the system matches a claim line to a benefit which is configured with the flag "Not Covered". SCE looks at the “Service Covered” Flag. This flag can be configured at the benefit level in the Flattened structure (using PCS). If the box was checked it means the benefit Is not covered and the Claim can be denied using the event code SBD0006.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us