Claim history retrieval

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.

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 Elasticsearch. Reference the Enabling Elasticsearch section in the implementation guide to configure this.

Claim business audits event codes

Interim Bills

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.

Duplicate claim edits

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.

The configurations to manage the duplicate handling is in the Duplicate Claim Edits section in the Claim edits tab of the Claims Engine Configuration screen.

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.

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.

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.

The 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.

Like 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.

The 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 edits

Smart 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.

NCCI edits

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:

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.

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.

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 audits

In 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.

Identify claim for readmission review

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

• Admission source code exclusions. Driven by the AdmissionSourceCode decision table. For example: 4 – transfer from hospital

• Servicing facility’s primary specialty exclusions. Driven by the PrimarySpeciality decision table. For example: 282NC0060X - critical access hospital

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 admissions

After 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:

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.

Identifying historical claims for analysis

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.

Set the hospital readmission event code

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.

Resolving an unplanned readmission

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

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.

Dental predetermination processing

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 edits

The 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:

• 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

Related claims and audit logging for predeterminations

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.