Claim business audits
This module (SBA) is responsible for performing claim edits against historical claims or against lines within the current claim. These edits require claim history to be available.
The business audits module has 6 areas of edits that are available:
- Interim bills – validation for hospital interim bills with validation for the associated frequency codes and gaps in claims
- Duplicate claim edits – support for suspect and exact duplicate at the claim, line and within the current claim
- Fraud, waste, and abuse – support for a configuration to identify claims that meet specific criteria
- NCCI edits – supports the editing of the claims with respect to the National Correct Coding Initiative (NCCI) with support for Medically Unlikely Edits (MUE) and Procedure to Procedure Edits (PTP).
- Hospital readmissions – supports the review of inpatient hospital claims, and the identification and resolution of unplanned hospital readmissions.
- Predetermination – validation of dental predetermination and subsequent billing claims
The business audits module utilizes claim history to perform the appropriate edits. The claim types used for populating the history of the member are defined in the Claim types used for Patient History Retrieval section of the Claim Engine Configuration screen, and the amount of history to pull is identified in the Claim history lookback days defined in the System configuration tab in the System settings. This information, along with the custom search properties for the Claim and Claim Line are used to match the current claim against claims in history.
The fields identified in the Custom search properties can be accessed by Records->SysAdmin in the Dev Studio. The classes used are PegaHC-CLM-Work-Claims and PegaHC-Data-ClaimLine.
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/claim_history_retreival.jpg)
Note: if new fields need to be added to the claim or claim line for searching after the application is in production, the search classes will need reindexing.
Note: the history review in the claims audits utilizes Elastic Search. Reference the Enabling Elasticsearch chapter in the implementation guide to configure this.
Claim business audits event codesEvent code | Name | Description |
SB1-0001 | Multiple interim "first claims" | The claim was submitted with a frequency code of 2, indicating it is the first in an expected series of claims, but there are already one or more claims in the system with a frequency code of 2. |
SBA-0002 | Multiple interim "last claims" | The claim was submitted with a frequency code of 4, indicating it is the last in an expected series of claims, but there are already one or more claims in the system with a frequency code of 4. |
SBA-0003 | Out of sequence "last claim" | The claim was submitted with a frequency code of 4, indicating it is the last in an expected series of claims, but no "first claim" (frequency code 2) is found in the system. |
SBA-0004 | Interim bill - overlapping dates | This interim bill contains overlapping dates of service with other claims from the same provider for the same member. |
SBA-0005 | No admission date - interim bill | The claim frequency code is 2, 3 or 4, indicating an interim bill, but no admission date is found. |
SBA-0006 | Duplicate - claim header | The claim header information is an exact match to a claim in history. The claim meets the defined criteria and weighting to be considered an exact match duplicate. |
SBA-0007 | Possible duplicate - claim header | The claim header information is a possible match to a claim in history. The claim meets the defined criteria and weighting to be considered a possible duplicate. |
SBA-0008 | Duplicate - claim line | The claim line is an exact match to a claim line in history. The claim line meets the defined criteria and weighting to be considered an exact match duplicate. |
SBA-0009 | Possible duplicate - claim line | The claim line is an exact match to another claim line on this claim. The claim line meets the defined criteria and weighting to be considered an exact match duplicate. |
SBA-0010 | Duplicate - claim line, same claim | The claim line is an exact match to another claim line on this claim. The claim line meets the defined criteria and weighting to be considered an exact match duplicate. |
SBA-0011 | Possible duplicate - claim line, same claim | The claim line is a possible match to another claim line on this claim. The claim line meets the defined criteria and weighting to be considered a possible duplicate. |
SBA-0012 | Suspected FWA | The claim meets the defined criteria for possible FWA (fraud, waste, abuse). |
SBA-0013 | Reporting threshold exceeded - duplicate claim lines | The total number of possible duplicate claim lines matched are more than the configured threshold value. |
SBA-0014 | Reporting threshold exceeded - duplicate claim headers | The total number of possible duplicate claim headers matched are more than the configured threshold value. |
SBA-0015 | PTP | The service billed on the claim line has triggered an NCCI (National Correct Coding Initiative) PTP (procedure-to-procedure) edit. PTP edits define pairs of codes that should not be reported together on the same claim or on different claims for the same DOS (date of service). |
SBA-0016 | MUE | The service billed on the claim line has triggered an NCCI (National Correct Coding Initiative) MUE (medically unlikely edit). MUEs define the maximum number of units a provider would render to a patient on a single DOS (date of service). |
SBA-0017 | Hospital readmission | This claim meets the defined criteria for a hospital readmission. |
SBA-0020 | Predetermination references predetermination | The submitted predetermination references another predetermination. |
SBA-0021 | Predetermination not found | The predetermination ICN referenced on the claim is not found in the system. |
SBA-0022 | Invalid predetermination | The predetermination ICN referenced on the claim does not match the member, provider, billed amount, procedure code, etc. on this claim. |
SBA-0023 | Predetermination lookback period exceeded | The claim was not received within the configured predetermination lookback period. The claim service from date compared to the predetermination received date does not fall within the configured number of lookback days. |
SBA-0024 | Duplicate predetermination | The services submitted on this predetermination have already been submitted by another provider. |
The interim bill edits provide validation to ensure when an institutional provider is billing for periods of care, the claims are sequenced correctly and that there are no gaps. The interim bill logic is driven from the frequency code submitted on the claim. This is the third digit in the Uniform Bill Type Code for paper claims or submitted in the Claim Frequency Type Code in the 837I.
Frequency codes:
- 2 – First claim
- 3 – Interim claim
- 4 – Last claim
When submitting interim claims, the frequency codes of 2 and 4 can only be reported once, but there can be multiple frequency codes of 3. The identification of the related interim bills is based on the same admission date and billing provider. The claims are validated to ensure the admission date is consistent and that there are no gaps in dates of service once the final claim is submitted.
The following event codes are set on the interim bills:
- SBA-0001 – When another claim matching the same provider and admit date has a frequency code of 2. This indicates multiple “first” claims have been submitted.
- SBA-0002 - When another claim matching the same provider and admit date has a frequency code of 4. This indicates multiple “last” claims have been submitted.
- SBA-0003 – When a claim is submitted with a frequency code of 4, indicating that it is the last claim in the series, but there are no “first” claims submitted for the same provider and admit date.
- SBA-0004 – When a claim is submitted that has overlapping dates of service with another claim in the interim sequence for the same provider and admit date.
- SBA-0005 – When a claim is submitted with a frequency code of 2, 3 or 4 indicating an interim sequence, but no admission date is submitted.
The SCE provides the ability to compare the current claim to claims in history to identify if they are an exact duplicate or suspect duplicate based on configuration. The SCE can review the current claim against another, current claim lines against lines in another claim and claim lines within the current claim to validate that the criteria for duplicates has not been met. The SCE also provides the ability to define different configurations for duplicates across different claim types and different claim identifiers. This enables a flexible way to define when claims meet the criteria for a duplicate.
Configuring duplicate event codesThe configurations to manage the duplicate handling is in the Duplicate Claim Edits section in the Claim edits tab of the Claims Engine Configuration screen.
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/configuring_duplicate_event_codes.jpg)
The fields defined in this screen are detailed below and are duplicated for both the claim and the claim line editing. Claim line duplicate edits can utilize information found at the claim and line levels. Claim level duplicate edits can only utilize information found at the claim level.
Field | Description |
Property | The Field used to match against in the duplicate processing query. |
Associated weight | Enter a number to define the weighting of the possible duplicate result. This can be used in a calculation to determine whether this is a Possible Duplicate Claim or Claim Line. |
Total for Exact Match | Enter a number to represent the total of "Exact Match" weights that would indicate an exact duplicate claim or line |
Minimum Weight for Possible Match | Enter a number to calculate the total of "Weight" amounts that represents the minimum amount for a possible duplicate claim or line. |
Maximum Duplicate Claim/Claim line Results | This is the maximum number of claims that can be matched for review for dupe check. This helps control the number of possible claims returned supporting performance. This should be set to the maximum number of claims a member may have during the period bounded by the claim types, history lookback days, claim statuses and the dupe criteria configured used for selection. |
Reporting Threshold Size | If this number is exceeded, then event codes SBA-0013 or SBA-0014 will be assigned to the claim depending whether the max was at the claim or line level. The maximum results determine the number of records that can be returned. The ES dupe query also returns the total count of records that meet the criteria, which is used to drive this reporting item. The threshold should always be higher or equal to the maximum number of duplicate results. |
To edit the settings, double click on the expanded view for the claim type to open the edit window. From this window, you can modify the weights and thresholds and add new fields to the matching criteria. Selecting down arrow once in the editable property box will give you the list of fields that are available for matching. You would select the appropriate field and provide the weight associated with that field. The fields available are those defined in the custom search properties for the claim and line.
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/claims_edits.jpg)
Different configurations are available for each claim type and each claim identifier. The claim level configurations only use custom search properties defined for the claim. The claim line level configurations use both the custom search properties for the claim and the line.
The queries for dupe check also use a series of standard attributes along with the fields listed in the configuration. These include:
- Patient ID
- Claim types for consideration from the selected claim types in the configuration for the history retrieval
- Claim statuses – Pending-Approved, Resolved-Paid and Resolved-Completed
- Service start and end dates utilizing the amount of history to retrieve in the configuration to provide the date boundaries.
The standard query can be extended by adding other standard attributes, if required, in the data transform PrepareESStandardQuery_Ext.
Setting exact duplicateThe SCE matches the current claim or line to those in history for the same member, or in the case of line, against another line in the same claim. For each field in the configuration that matches, the weight is summed. If the total weight meets or exceeds the Total for exact match, then the exact duplicate event codes of SBA-0006, SBA-0008 or SBA-0010 will set depending upon whether it is the historical claim, historical claim line or a line within the same claim.
Setting suspect duplicateLike the exact duplicate, SCE matches the current claim or line to those in history for the same member, or against another line in the same claim. For each field in the configuration that matches, the weight is summed. If the total weight meets or exceeds the Minimum weight for suspect match, then the suspect duplicate event codes of SBA-0007, SBA-0009 or SBA-0011 will set depending upon whether it is the historical claim, historical claim line or a line within the same claim.
Resolving suspect duplicate event codesThe SCE provides two guided event flows for the suspect duplicate event codes. These are PR_DuplicateClaimlevel and PR_DuplicateClaimLinelevel. These guided flows perform two tasks. The first is to ensure that the duplicate still holds. In the instance that the original claim has since been denied, voided, or cancelled or if the configuration has been updated, the SCE re-executes the matching query against the claims. If no claims are found, then a message is displayed to the end user. The other reason for performing this step is to pull the list of fields that matched and presenting them to the user as part of the guided flow. The duplicate event guided flow, shown below, provides access to open the associated claim for a full review, as well as detailing the fields from the configuration that matched and the total matched weight for those fields.
The standard resolution buttons configured for the event code will also be available as options to resolve the event.
Fraud and abuse editsSmart Claims Engine for Healthcare provides comprehensive analysis and editing methodologies to protect the integrity of health plans as well as members, providers, and employer groups from fraudulent claims activities.
To detect Fraud and Abuse on the claim, Smart Claims Engine for Healthcare analyzes any practice on the claim that is not consistent with the goals of providing patients with services that are medically necessary, meet professionally recognized standards, and priced fairly.
Examples of medical or clinical abuse include billing for services that were not medically necessary, charging excessively for services or supplies, and misusing codes on a claim, such as upcoding or unbundling codes.
The fraud and abuse event code is configured by the CE_FraudAbuseEdit decision table used to hold billing entity ID, the rendering provider ID, the service facility ID, and procedure codes. If a claim matches all the values, then the fraud and abuse event code (SBA-0012) is set. This table can be extended and configured as necessary to add other criteria to match upon.
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/claim_business_audits_con.jpg)
The edits provided as part of the National Correct Coding Initiative (NCCI) provide validations to on multiple procedure billing (procedure to procedure - PTP) and maximum units per procedure (medically unlikely edit - MUE). The Centers for Medicare and Medicaid Services (CMS) provides the information listing the procedures and units in downloadable files.
Procedure to procedure edits (PTP)The PTP edits determine which procedure codes cannot be billed together on the same claim encounter. Different procedure code files exist for hospital and professional claims. The audit not only looks at the current claim, but also claims in history submitted by the same provider to ensure that the claims haven’t been split to avoid the edit being set. The PTP edit file included edits where two procedures could not be performed at the same patient encounter because the two procedures were mutually exclusive based on anatomic, temporal, or gender considerations.
An encounter is defined as the same practitioner (rendering provider) on the same date of service for the same member. The files from CMS contain pair of codes. If the code in column 1 exists, then the claim cannot contain the code in column 2 on another line for the same date of service unless an appropriate modifier has been submitted and the configuration allows modifier overrides.
In this situation, the procedure on the first line would pass the edit, and the second procedure would set the PTP edit. The code pairs have effective and end dates in the file and the claim dates of service must be within those dates. If a modifier can be present to override the event, the PTP table indicates this. A decision table is available to show the available modifiers that can override the edit. The decision table will include both a procedure code and a modifier. If either the modifier and/or modifier/procedure code combination exists, then the audit will bypass.
An example of the PTP file is below:
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/ptp_file_example.jpg)
The PTP file used for processing is identified as the PTP edit in the data objects in App Studio for the SCE.
The modifier column in the file indicates if a modifier can override the audit. The modifier codes are detailed below:
- 0 – Not allowed
- 1 – Allowed
- 9 – Not Applicable
If a modifier override is allowed, the CheckModifierToBypass decision table is reviewed. This looks to see if the procedure code and/or modifier listed enables an override. If so, then the decision table returns a true statement. This table can be easily extended as necessary to add other procedure/modifier combinations or other modifiers.
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/modifiers.jpg)
If the provider bills a claim, or claims, that meet the criteria for the PTP edit, then event code SBA-0015 is applied.
Medically unlikely edits (MUE)The MUE edits identify the maximum units of service a provider would typically bill for a single date of service. CMS developed Medically Unlikely Edits (MUEs) to reduce the paid claims error rate for Part B claims. An MUE for a HCPCS/CPT code is the maximum units of service that a provider would report under most circumstances for a single beneficiary on a single date of service. Not all HCPCS/CPT codes have an MUE. A sample of the CMS MUE file is pictured below.
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/MUE.jpg)
The MUE file used for processing is identified as the MUE edit in the data objects in App Studio for the SCE.
If the provider bills a value higher than the MUE value for the units of service in the claim, then event SBA-0016 is reported, and the rationale logged in the audit trail.
Hospital readmission auditsIn executing the hospital readmission audit, Smart Claims Engine for Healthcare leverages CMS’ definition of an unplanned hospital readmission, including:
- A configurable look-back period for unplanned hospital readmissions.
- Application of readmission rules to short-stay, acute hospitals.
- Certain hospitals types are excluded based on taxonomy.
- Exclusion of certain planned admissions based on procedures and diagnoses.
The process for hospital readmission review follows the following process.
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/hospital_readmission.jpg)
The SCE first determines whether the current claim being adjudicated warrants additional review to determine its potential status as an unplanned hospital readmission. In this review, the SCE validates the following:
- Claim form type = Institutional (I)
- Diagnosis type = ICD10
- Bill type inclusions. Driven by the ClaimBillType decision table. For example: 0111 – Hospital inpatient admit through discharge
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/readmission_review.jpg)
- Admission source code exclusions. Driven by the AdmissionSourceCode decision table. For example: 4 – transfer from hospital
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/readmission_review2.jpg)
- Servicing facility’s primary specialty exclusions. Driven by the PrimarySpeciality decision table. For example: 282NC0060X - critical access hospital
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/readmission_review3.jpg)
If all the criteria are met, then the SCE will log that the claim meets the criteria for review in the audit trail. If the criteria are not met, then the reason for exclusion is also logged.
Exclude planned admissionsAfter a claim has met the initial criteria, and warrants additional review, the SCE then determines whether the claim can be excluded based on meeting planned admission criteria. The flow for identifying the planned admission is detailed below:
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/planned_admission.jpg)
The following data tables are used to support this process.
- Readmission planned procedure table – D_PegaHCDataReadmissionPlannedProc
- Readmission planned diagnosis table – D_ReadmissionPlannedDaignosis
- Readmission potential planned procedure table – D_PotentialPlannedProcedures
- Readmission acute diagnosis table – D_ReadmissionAcuteDiagnosis
Claims that have been identified as planned admissions from the process defined above will have a note displayed in the claim audit history indicating the result of the review.
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/planned_admission2.jpg)
Once the SCE determines that the claim being adjudicated meets the criteria for additional review, and is not excluded according to the planned admission criteria, it then queries hospital inpatient claims in the patient’s history that would support designating the current claim as an unplanned readmission.
The criteria used to identify a readmission at this stage uses the same configuration for the bill type and admission source code, but the discharge date of suspect claim must fall within 30 days of the admission date of the claim currently being adjudicated.
Note: This setting is defined by the Match days configuration in the hospital readmission section of the system configuration page. The default setting is 30 days.
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/default_setting.jpg)
Upon the positive match of historical claims against the current claim, the SCE declares the current claim to be a hospital readmission. If multiple claims are identified as possible readmission matches, it will select the most current claim (the claim whose discharge date is closest to the current claim's admission date) as the matching claim.
When Smart Claims Engine for Healthcare identifies an unplanned readmission, it triggers event code SBA-0017 - Hospital Readmission.
In addition to the event code assignment, once an unplanned readmission has been identified, the user may view the matched readmission claim in the Related claims section from of the Claims UX. From here, the user may click on the claim ID hyperlink to view the details of the matched claim.
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/resolving_unplanned_admission.jpg)
Unplanned hospital readmissions are resolved using Smart Claims Engine for Healthcare application’s guided event resolution process. The event resolution associated with Event code SBA-0017 allows the user 2 options: waive member co-pay, and manually reprice the claim line.
- Waive member co-pay
The member co-pay for an unplanned readmission may be waived, based on a user-defined readmission copay look back period configured in the system configuration page (the Pega-provided default is 48 hours).
The intent of the WCP action code is to trigger the waiving of member co-payment for the claim determined to represent a hospital readmission. This should be a default action, so that when a user completes the line-level pricing for a readmission, the member’s co-pay for that claim is automatically waived. However, if the user elects not to reprice the claim (e.g., selects override, no action required, etc.), the waiver will be removed, and the co-pay will be applied.
When the co-pay is waived, the SCE sets the member co-pay field in the claim line to $0.00 and displays a note in the Claims history.
- Manually reprice claim line
Unplanned hospital readmissions can be resolved using the SCE guided event resolution process. The event code SBA-0017 can be configured to use the RepriceClaimLine resolution process. This will provide the user the ability to manually reprice the claim along with the standard resolution options. Manually repricing the claim line is achieved by performing the following steps:
- Select the Reprice claimline button in the display
- Select either the Price at $ or % checkbox and enter the appropriate amount or percentage.
- Enter the resolution comment if necessary.
- Select submit
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/Manually_reprice_claim_line.jpg)
Upon reprocessing, the previous claim line allowed amount is overridden with the new manual price. In addition, the pricing source and methodology are updated in the adjusted claim line Execution results UI, and the manual pricing source and methodology are then added to the list of pricing source and methodology considerations in the claim line Pricing sources section.
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/pricing_sources_section.jpg)
The SCE manages predetermination claims and their subsequent billing claims. The SCE provides logic to edit against the predeterminations and apply successful matches to the related claims section in the UX.
Predetermination editsThe SCE performs a series of edits on dental claims to validate both predetermination and billing claims. The SCE looks at billing claims to attempt to match to a predetermination and to validate duplicate or errors in predeterminations.
The following edits are applied for predetermination.
- When the predetermination is submitted with a predetermination identification number, then the system attempts to match the submitted number with an existing ICN to see if a match exists. If a match is found, the system raises the event code: SBA-0020 - Predetermination references predetermination.
- When the claim is submitted with a predetermination identification number, then the system attempts to match the submitted number with an existing ICN to see if a match exists. If a match is not found, the system raises the event code: SBA-0021 - Predetermination not found.
- The claim received with a matched predetermination number is further checked
to see if the below information on the claim and predetermination matches.
If not, the system raises the event code: SBA-0022 – Invalid
predetermination. The fields compared are the following:
- Patient id
- Billing provider
- Billed amount
- Procedure code
- Tooth number
- The claim received with a predetermination which is not within the configured number of days, the system raises the event code: SBA-0023 – Predetermination lookback period exceeded. The lookback period is defined as the difference in days between the submitted date on the predetermination and the from date of service on the claim. The range for lookback is defined in the configurable system setting:
![](https://docs.pega.com/sites/default/files/drupal/dita/out/2316/strategic-apps-user-guide/Content/SCE/Images/predefined_system_settings.jpg)
- Submitted predeterminations go through the duplicate logic to see if there
is an exact match with an existing predetermination. If a duplicate is found
the SCE raises event code: SBA-0024 – Duplicate predetermination.
This is assigned if the services are for the same or a different provider.
The fields compared are the following:
- Patient id
- Procedure code
- Tooth number
The SCE will look for predeterminations and match them to the billing claim in the related claims section of the UX and display key information in the audit log.
- If a claim is submitted without a predetermination number, the SCE will look
to see if an existing predetermination matches the claim utilizing the
following criteria:
- Patient id
- billing provider
- billed amount
- procedure code
- tooth number
- If a match for a predetermination is successful, an audit is added with the
identified predetermination ID.
- The related claims section for predetermination also shows the matched
claims and predeterminations.
- If a claim is received without a predetermination id and finds multiple predetermination in the system, then the system adds all the predetermination claims to current claim under related claims section.
- If multiple predeterminations are found, the system uses the newest one as defined by the submit date.
If the claim matches more than one predetermination, the audit message defines which line matches each predetermination.
Previous topic Claim business edits Next topic Third party liability edits