The SCE provides the module Benefit determination (SBD) to perform this function. Failure to match to a benefit will assign event codes for further review and processing. The successful match to a benefit will enable the SCE to review the rules associated with that benefit and utilize them in the adjudication of the claim. Once a benefit has been matched to the claim, it is visible in the UX for review.

There are three core steps to the benefit matching process.

1. Determine the benefit network – this matches the providers network list against the networks associated with the members’ plan.
2. Match the benefit – this uses claim data along with the benefit matching criteria to attempt to match each claim line to a benefit under the plan
3. Check that the benefit is covered – this verifies that the matched benefit is covered.

This step of the process ensures that the claim is billed by a provider associated with the networks configured for the plan. The SCE compares the list of networks on the plan against the primary network identified for the provider contract.

If the network is found and the network is configured as “Participating” or “Full”, then this network is assigned to the claim.

If the network is found and the network is configured as a “Carveout” network, then event code SBD-0021 is applied to the claim.

If the network is listed as “Non-Participating”, then this network is associated with the claim.

If no network is found, then the services were provided by an Out-of-Network provider, and event code SBD-0022 is applied to the claim.

To support the matching of the network to the benefit, the networks list embedded in the data page D_CE_PlanDetails is utilized.

During benefit determination, each individual claim line is mapped to a corresponding benefit that has been configured in the Pega Foundation for Healthcare (PFHC) application’s benefit structure. The Product Composer System (PCS) can be used to create the appropriate benefit structure for adjudication, or alternatively, another application can be used and mapped to the benefit structure for adjudication. Claims data is matched on a claim-line by claim-line basis and the benefit matched is placed on the clipboard which is used for the adjudication. This matching is performed by an Elasticsearch query using the information on the claim to match against the associated fields configured on the benefit.

The claim data required to successfully execute benefit determination varies according to the benefits that are represented in the submitted 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)

Claim fields used in the matching process

The table below covers the list of code groups that are also used for matching benefits. The groups are created in the Pega Foundation for Healthcare for use in matching.

Note - all code group purposes are available for matching.

For professional claims and dental claims, multiple diagnosis codes submitted on the claim can be used to help match a specific benefit. To configure the number of diagnosis codes available for matching, the Professional diagnosis or Dental diagnosis for benefit determination needs to be set appropriately. This configuration is available in the Benefits section of the system configuration screen.

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.

Dental benefits also incorporate another level of detail to support the dentition, tooth ranges, surface, and oral quadrants. These fields are part of the service definition structure of the benefit. These extra fields ensure that the dental information on the claim can be mapped to a specific dental benefit. The fields and the associated structures are listed below:

Notes on dental code/surface/dentition matching:

• For any dental claim line, the system expects that along with tooth information there could be a tooth code/tooth surface, a tooth code only with no surface, or an oral cavity with no tooth number. There will not be a tooth number and an oral cavity.
• Claim lines that have tooth code/surfaces combinations, the system can derive the dentition (primary, permanent) and choose the benefit accordingly. The dentition determination logic would be as follows:
  • Tooth code is in the range 1 through 32 -> dentition: Permanent
  • Tooth code is in the range A through T -> dentition: Primary
• For a claim line that only has oral cavity designation codes and no supporting tooth code information to derive the dentition. In these situations, the dentition defined in the benefit is ignored while matching against the CDT code.

If the plan is matched, it is displayed as a hyperlink in the member information, which can be selected to show the information associated with the plan.

If the benefit is matched, the benefit hyperlink would show up as follows on the claim.

Selecting the hyperlink will show the key benefit information:

It also displays the information used in the mapping of the benefit to the claim. From the example above, the claim was matched to the benefit via the submitted type of bill code of 0111.

The matched benefit will also be added to the claim line information in the clipboard under the benefit definition.

In the instance a benefit is not matched, or that the claim line matched multiple benefits, the SCE will apply the following event codes:

• SBD-0004 – No benefit match
• SBD-0020 – Multiple benefits matched

In the benefit matching logic, multiple data pages are needed for the processing. These are listed below:

• D_CPTCodes – these set the parameters for the CPT codes in the Elasticsearch query for the benefits
• D_HCPCSCodes – these set the parameters for the HCPCS codes in the Elasticsearch query for the benefits
• D_CodeinCodegroupES – these set the parameters for the code groups in the Elasticsearch query for the benefits

The final step in the benefit determination process reviews the coverage indicator on the matched benefit. If the service covered indicator is set to false, then event code SBD-0006 (Service not covered) is applied to the claim.