This document explains the claim adjudication process in detail and is intended for MCS and MCO Support audiences. This is not intended for Provider release:
TOPICS COVERED IN THIS DOCUMENT
General Adjudication Information Adjudication Method by Claim Type
o ED Claims (ED) o Inpatient Claims (IP) o ICF/MR (ICF) o Residential/PRTF (RES) o Facility Fee (FF) o Professional: ( ' ' )
Processing Reversals and Replacements o Reversal/Replacement Edits
Identify Consumer Primary, Claim Primary Payer (COB) and COB edit bypass o Identify Secondary o Identify Consumer Primary o Primary (COB) Edit Bypass o Collect data points used during adjudication o Claim Format Edits
Claim Site Adjudication Determination o Site Identification o Identify Priorities
Benefit Plan Determination o Virtual Benefit Plan Matrix Example o Authorizations o Site Ambiguity o Eligibility Edits
Contracts o Valid Contracts o Allowed Billable days o Contract Edit
Get Rates from Contracts or Rate Schedule o Rate Types
o Set rate and adjudicated amount o Contract Rate Edit
Billing, Rendering and Clinician Validation and Edits o Identify Rendering Data Points o Rendering and Attending Edit o Service Matrix and BP Edits
Diagnosis Assessment Period o Assessment Edit
Target Population (Benefit Plan) Validation and Automation o Target Population Edits
Pass-through Days and Pass-through Units o Duration Types o Other Auth bypass situations
Non-Compatibility List (NCCI and CCP) o Configuration Options o Compatibility Edits
Non-Compatibility List (NCCI and CCP) o Duplicate Claims o Duplicate Claim Edits o Benefit Limit Periods o Benefit Plan Limit Adjustments o Benefit Plan Limit Edits o Unmanaged Units o Authorization Limits o Authorization Edits
Adjudication Edit configuration o Manual Review o COB Adjustments and the “Lessor of Methodology” o COB Adjustment Edits o Funding Capitation Limits o Map GL accounts o Adjudication Rollback o Adjudication Completion Summary Email
GENERAL ADJUDICATION INFORMATION The claims adjudication process runs twice nightly after claims processing. At 6PM EST MCS will begin processing UB04s and CMS1500 claims submitted through the portal. Immediately after portal claims processing, the adjudication process runs. At 9PM EST MCS will begin processing 837i and 837p EDI files received for the day. Immediately after EDI processing, claims adjudication will run again to adjudicate those claims. Data points collected during the adjudication process must be database records that are active [active = 1]. When collecting date dependent data points, the effectiveness of the record is identified by the claim date of service on the claim, unless noted otherwise. Inpatient claims will use the Statement Period To date of the claim. For dated data records that do not have a date set (no end date on a record) then that record is viewed as being effective from the effective date of the record until 12/31/2099.
ADJUDICATION METHOD BY CLAIM TYPE The MCS adjudication process allows edit configuration by claim type. This is done by determining the claim type at the beginning of the adjudication process by bill type and service submitted. Claim types in MCS are broken out by ED (ED), Inpatient Claims (IP), ICF/MR (ICF), Residential/PRTF (RES), Facility Fee (FF) and then all else (‘ ‘) which professional claims and all other claims not able to be identified as any of the previous types. Claims not specifically identified as one of the 5 claim types it will be considered a professional claim and go through professional claim adjudication
ED Claims (ED)
Professional Claims submitted with place of service code 23 for Emergency Room Hospital Institutional Claim submitted does not have an Inpatient Bill Type (011_)
Claims submitted with ED revenue code of 045_ or revenue code between 0940 - 0945
Inpatient Claims (IP)
Institutional Claim submitted with an Inpatient bill type of 011_ Revenue code 0100 or 045_ or revenue code 0940 through 0945 does not exists on the claim. The only exception being, if the client presented through the ED initially. However, those lines would deny for non-covered ancillary. Service marked as DRG in the service Matrix
Inpatient revenue codes are rolled up to 0101. Only this code needs to be set in a providers contract and authorized for all inpatient revenue codes.
Institutional Claims submitted with an ICF/MR bill type of 065_ or if HCPCS code 0100 exists on the claim
Claim is not yet designated with an Adjudication Method
Residential/PRTF (RES)
Institutional Claim submitted with a Residential bill type of 089_ or 086_ or revenue code 0183, 0911 or 0919 exists on the claim
Claim is not yet designated with an Adjudication Method
Facility Fee (FF)
Institutional Service billed is set as a Facility Fee service in the Service Matrix ('0900', '0901', '0904', '0910', '0914', '0915', '0916', '0918', '0903', '0905', '0906', '0907', '0912', '0917')
ED service code ‘045_’ does not exist on the claim
Claim is not yet designated with an Adjudication Method
Professional: ( ' ' )
Professional Professional claims submitted via 837p or Portal CMS1500
Claims not designated for a specific adjudication method
PROCESSING REVERSALS AND REPLACEMENTS Reversal/Replacement claims for claims currently in a re-adjudication status or a manual review status do not get replaced. Those are removed from the adjudication process.
Claims submitted with a bill type ending in a 7 (replace) or an 8 (reversal/void). Or claims with a resubmission reference number present are considered replacement and reversal claims.
Resubmission claim header number appears in the Resubmission Reference Number field: [dbo].[tb_claim_headers].[resub_ref_num]
Reversal/Replacement Edits: o (93) Invalid Document Control
If the resubmission number is blank or the resubmission number is not numeric
o (94) Resubmitted DOS is after the original claim submission date If the DOS is after the received date of the original claim
o (95) Submitting Replacement Provider does not match original Provider Replacement claims submitted with a bill type ending in 7 Compares the received date, provider ID, patient ID, service code, place of
service, date of service and diagnosis code. If there are more than 3 elements that differ between the original and replacement claim, it will deny.
o (96) Referenced claim has already been resubmitted. Cannot resubmit again If the original claim found is already voided
[dbo].[tb_claim_headers].[voided] = 1 Reversal/Void claims are removed from further processing and original claim
is reverted
IDENTIFY CONSUMER PRIMARY, CLAIM PRIMARY PAYER (COB) AND COB
EDIT BYPASS Identify Secondary
o Claim was billed with a Primary Amount Header Level for Institutional [tb_claim_headers.oi_pmt_amt] Line Level for Professional [tb_claim_lines.cob_amt]
o … or a COB reason submitted on the claim [tb_claim_lines.cob_rsn] o … or a COB primary payer was submitted on the claim
[tb_claim_headers.oi_payer_nm]
Identify Consumer Primary o Identify Medicare A consumers by active and effective COB layers for the claim date
of service where the COB type record is matched to a type of ‘Medicare.’ These are typically the manually entered primary consumer eligibilities
o Identify Medicare A consumers by active and effective COB layers for claim date of service where the COB name is like ‘Medicare A’ or like ‘Medicare Part A.’
These are typically the GEF loaded consumer eligibility layers o Process is repeated to identify Medicare B and C o Consumer has commercial (TPL) if..
Primary payer submitted on the claim and is not Medicare or.. The consumer has an active and effective primary eligibility layer where the
name is not like ‘Medicare’
Primary (COB) Edit Bypass o Bypass is active and effective for the date of service for the claim o Bypass for Medicare A, B, C and Commercial (TPL)
o State funded “Y Codes” are hard coded to not deny for Primary Payer o A COB amount is considered present on the claim if a patient amount or a primary
amount exists that is greater than 0. o COB reason is considered as submitted on the claim when the COB reason segment
Collect data points used during adjudication o Pend for Manual review due to billed claim amount submitted
Limit set in the system parameters [dbo].[tb_sys_parameters].[type] = ‘Manual_review_$_limit’
Typically set to $5,000, per claim line Does not include Inpatient (IP), Residential (PRTF) or ICF/MR (ICF) claim types
due to normal high dollar value. o Consumer Age for Date of Service
Get the consumer’s age from the recorded date of birth from the Patient Maintenance record to the claim dos.
o Clinician Based Claims Identify clinician based services by service code submitted on the claim and if
the service is set as a Clinician Based service in the Service Matrix. [dbo].[tb_proc_codes].[is_clin_based]
o Rebill Claims If the resubmission claim number field is not blank ..Or the bill type ends in 7 ..Or a prior denied claim exists for the same consumer, service, date of
service and provider ..and the prior claim did not originally deny for timely filing or number
of days between the date of service and received date of the prior claim is w/in 90 days.
..and prior claim not in a manual review, overridden, reverted or re-adjudication status
o Clearing House Clearing house linked to claim by current clearing house set for the provider
in Provider Network. [dbo].[tb_providers].[clear_house_id]
o Fiscal year Begin Date The beginning of the fiscal year is determined by the date of service on the
claim [dbo].[fn_FinancialYearStart(clm_dos)]
Claim Format Edits
o (19) Patient could not be identified when the 837 claim was collected, the Patient Name (ID) could not be
identified and blank. If the consumer does not exist in Patient Maintenance Identifying consumer information submitted on the 837 is not enough or
does not match to the consumer’s record in Patient Maintenance o (27) Invalid Provider NPI
Billing/Provider NPI submitted on the claim is not linked or effective to a Provider in Provider Maintenance.
The NPI must exist in the Site Numbers for the Provider Record. [dbo].[tb_claim_headers].[prv_npi_num]
o (34) Resubmission claim has already been resubmitted and Approved If a claim is found with the same resubmission number in an approved status
then subsequent claims will deny. [dbo].[tb_claim_headers].[ resub_ref_num]
o (91) Invalid Revenue Code If the revenue code submitted does not exist in the Service Matrix. [dbo].[tb_claim_lines].[rev_code]
o (14) Non-Billable Service/HCPCS Code If the service code submitted does not exist in the Service Matrix. [dbo].[tb_claim_lines].[pc_id]
o (135) Discontinued Service If the Revenue Code exists in the service matrix but not effective for
Institutional claims, or if the service code exists in the service matrix but not effective.
[dbo].[tb_claim_lines].[rev_code] o (33) Non-Billable Service
If the Revenue Code exists and effective but not marked as Billable in the Service Matrix. Service Code for Professional claims.
[dbo].[tb_proc_codes].[is_billable] o (134) Invalid HCPCS code
Checks the existence of the HCPCS code for institutional claims in the Service Matrix.
[dbo].[tb_claim_lines].[pc_id] o (115) Invalid /Incomplete Diagnosis
If the first diagnosis on the claim (diagnosis #1) does not exist in AlphaMCS or the diagnosis exists but not marked as Billable(complete).
[dbo].[tb_claim_lines].[dx1] || [dbo].[tb_diagnosis_codes].[complete] o (6) Claim Submitted before service date
Date of service on the claim is before the claim received date. o (29) Invalid Units: 0 or negative
If the units billed on the claim is 0 or a negative value. Units billed on claim but not evenly divisible by the bed days.
Example: statement period = 1/1 – 1/31. That is 31 days, the claim only has 30 units billed. 30 units cannot be applied to 31 days or you’ll have fractions of units applied. In this case, the total units for the adjudication detail will be 0.
o (136) Invalid Units Below minimum for procedure: edit specific to H2035, if claim billed under 4
units for professional claims. [dbo].[tb_claim_adj_dets].[tot_units]
o (137) Invalid Units for Discharge Claim Units billed not equal to the number of bed days from Admission Date to the
Statement Period To date (minus one day for discharge) for Admission through discharge claims (___1). For Discharge claims (___4) where the admission date is before the Statement Period From date, then the Statement Period From date is used.
Example: claim has a bill type ending in 1 or 4 for a statement period of 1/1 – 1/31. That is 31 days but the last day on the 31st being the discharge day, that day is not reimbursable so the claim is expected to have 30 claimed units. If not, then the claim will deny for this edit.
If the admission date is after the Statement Period From date then the admit date is used as the first day of the bed day number. Else the Statement Period From date is used.
Example: claim has a bill type ending in 1 or 4 for a statement period of 1/1 – 1/31, but an admission date of 1/2. That is 30 days but the last day on the 31st being the discharge day, that day is not reimbursable so the claim is expected to have 29 units. If not, then the claim will deny for this reason.
[dbo].[tb_claim_lines].[units] o (138) Invalid Units for interim/continuing claim
Bill type not ending in a 1 or a 4. Units billed not equal to Statement Period From date and Statement Period
To days for interim or continuing claim type. Example: claim has a bill type not ending in 1 or 4 for a statement
period of 1/1 – 1/31. That is 31 days. The claim is expected to have 31 units billed. If not, then the claim will deny for this edit.
o (100) - Invalid date range / Invalid date for discharge claim Like reason 137 Claim is an inpatient discharge claim ending in a 1 or a 4. Deny the date of service that is the same as the Statement Period To date. If this edit is hit, then there may have been a processing issue since the
Statement Period To date should not be processed for discharge claims. Legacy v1 Edit
o (22) Invalid Claim Amount claim amount is $0 or a negative amount [dbo].[tb_claim_adj_dets].[clm_amt]
o (107) The procedure code/bill type is inconsistent with the place of service
Inpatient Claims with an inpatient bill type Service is not set as an R&B service in the service matrix.
o (142) Invalid or Missing Discharge Code for Discharge Claim Discharge claims with a bill type ending in a 1 or 4 the discharge code is set to deny in the Discharge Code list [dbo].[tb_discharge_status].[deny_claim] .. or the claim is an ED claim and a discharge status code was not submitted
o (143) Ungroupable or Missing DRG Code Non-Inpatient roll up Revenue codes on Inpatient claims that is not marked
as a DRG code in the service matrix. Non-R&B codes [dbo].[tb_proc_codes].[is_rb] Not set as a DRG code [dbo].[tb_proc_codes].[is_drg]
o (148) Admit date and/or Admit Source missing for Inpatient Claim claim is identified as inpatient and adjudicated with the Inpatient method
where the admission date was not submitted or the admission date is after the Statement Period To date.
[dbo].[tb_claim_headers].[admit_dt] o (155) Admission date is not valid for the bill type
claim is identified as an inpatient claim claim adjudicated with the Inpatient method the admission date is on or after the Statement Period From date the bill type ends in a 3 (interim) or a 4 (discharge claim). [dbo].[tb_claim_headers].[admit_dt]
o (149) Discharge status code missing for Inpatient Claims [FL 17] claim is identified as inpatient and adjudicated with the Inpatient method bill type ending in 1 (admit through discharge) or a 4 (discharge claim) where
a discharge status code was not submitted. [dbo].[tb_claim_headers].[disch_status]
o (150) ED consumer admitted to Inpatient Facility claim is identified as an ED claim with the ED adjudication method a prior approved inpatient claim for the same provider (by inpatient bill type)
with a date of service the day after the adjudicated date of service for the ED claim.
CLAIM SITE ADJUDICATION DETERMINATION Claims processed and adjudicated need to be attached (linked) to a specific site (site_id) for the provider in the Provider Network Maintenance module. The data elements submitted for the claim on the 837 are the Billing NPI and Billing Zip Code. Those elements are then compared to the site configuration in Provider Network to determine the site. Portal claims are not included in this process as the site is chosen explicitly by the end user submitting the claim.
Available sites are ranked during adjudication and highest ranked site is chosen based on a priority list explained below:
Site Identification o Get all active sites for the provider where the date of service is between the effective
and end dates for the site itself. o Identify all sites that contain the Billing NPI submitted on the claim that is registered
for the site in the Site Numbers tile. o If there is only one distinct site match from the Billing NPI submitted on the claim
then that site will be identified as the site for the claim and will not continue for determination.
o Identify all active and effective sites where the zip code plus 4, which is set in the Site profile, matches the billing zip code plus 4 submitted on the claim.
Identify Priorities
(1) First Priority: Portal Claim OR Distinct match using NPI Only
Claim is a Portal claim
Distinct match using NPI Only: If there is a single site chosen meaning, the billing NPI submitted on the claim only matches one active and effective site.
(2) 2nd Priority: Match on Billing NPI and Billing Zip and Contracted Site
The Billing NPI matches to a Site for the Provider
.. And the Billing Zip Code matches the Zip Code for the Site
.. And the service billed on the claim is contracted for the site
(3) Third Priority: Match on Billing NPI and Billing Zip
The Billing NPI matches to a Site for the Provider
.. And the Billing Zip Code matches the Zip Code for the Site
(4) Fourth Priority: Match on Billing NPI Only
Only the Billing NPI matches to a Site for the Provider
Only the Billing Zip code matches to a site for the Provider
(99) Last Priority: No Match
The Billing NPI and Billing Zip code do not match any site for the provider
Pick the first active site ordered by site ID
All sites for the lowest priority is identified and used in the benefit plan determination process.
Note: that it’s possible to have multiple candidate sites with the same priority. If this is true a tie breaker for the ambiguity is performed in the benefit plan determination process.
BENEFIT PLAN DETERMINATION With the various possibilities of benefit plan and site, a virtual matrix is created during the adjudication process and all possible combinations of claim adjudication ID, benefit and site are collected. The procedure will identify requisite data elements to then select the highest ranked site and benefit plan combination. If a specific benefit plan cannot be determined then the claim will deny for one of the benefit plan edits. Also, if a specific site cannot be determined due to ambiguity, the claim will deny for the site ambiguity edit (122).
Virtual Benefit Plan Matrix Example
o Claim ID Each individual Claim Adj ID goes through the benefit plan determination
matrix o Eligible Funding
Identify each payable MCO funding source to pick the best candidate (State, Med B, Med C)
o Site Site or sites identified as candidate sites during site determination
o Consumer Eligibility
Clai
m A
dj ID
Elig
ible
Fund
ing
Site
Cons
umer
Elig
ibili
tySe
rvice
in B
P
Diag
nosis
for B
PSi
te C
ontra
cted
Any
Site
Cont
ract
edSi
te is
Aut
hed
Site
BP is
Sel
ecta
ble
BP is
app
rova
ble
BP R
ank
123456789 State 1122 Yes Yes No No No No No No 99
123456789 State 3344 Yes Yes No No No No No No 99
123456789 Med B 1122 Yes Yes Yes No Yes No Yes No 2
123456789 Med B 3344 Yes Yes Yes Yes Yes Yes Yes Yes 1
123456789 Med C 1122 No No Yes No Yes No No No 99
123456789 Med C 3344 No No Yes Yes Yes Yes No No 99
Identify all eligibility plans for the consumer that is active and effective for the date of service for the claim.
o Service in BP Identify all eligible funding sources for the service submitted on the claim Effective by the date of service on the claim Inpatient claims (IP) will check against revenue code 0101. Institutional ED and Facility Fee claims are not checked and automatically
considered eligible for the Benefit Plan. The HCPCS code is checked on institutional claims when the HCPCS is a YP8_
service. Set in the Service Matrix.
o Diagnosis for BP Diagnosis code submitted on the claim is mapped to a behavioral health
diagnosis group The service on the claim is mapped to the same diagnosis group as the
diagnosis code Both mappings need to be active and effective for the date of service for the
claim Inpatient, ED and Facility Fee claims are not checked and automatically
considered eligible o Site Contracted
The site(s) chosen as candidate site on the claim is specifically contracted for the service on the clam
o Any Site Contracted If there is a site that exists that is contracted for the service System Parameter: [dbo].[tb_sys_parameters].[type] =
‘contracted_for_any_site’ If contracted_for_any_site = 1: As long any site is contracted for the service
on the claim then the claim will not deny for service not in contract (36). If contracted_for_any_site = 0: Then the service must be contracted for the
site determined on the claim, if not the claim is subject to deny for service not in contract (36).
o Site is the Authed Site Identifies if the candidate site is the site authorized if an authorization exists
o BP is Selectable A benefit plan is selectable when.. .. the consumer is eligible .. and the service is set in the benefit plan .. and the service is contracted for any site
o BP is Approvable A benefit plan is approvable when ..
.. the consumer is eligible for the benefit plan .. and the service is set in the benefit plan .. and the diagnosis is valid for the benefit plan .. and the service is contracted for the site .. or the service is contracted for any site and the service is not authorized
site enforced
Authorizations Rate Types Authorized Site Enforcement List: Services can be designated as requiring the site authorized to match the site determined on the claim. Only authorizations with sites that match a candidate site in the running benefit plan matrix will be considered. If the site or sites considered in the matrix is not a site on an existing candidate authorization, then that authorization will not be considered. The site enforcement list is located in SQL table [dbo].[ tb_pc_to_bp_site_enforcement]. For services, not on the site enforcement list, then the site on the authorization does not need to match a candidate site and will be used regardless.
EPSDT: If the processed SAR of the Authorization was submitted as EPSDT, this is identified to bypass subsequent adjudication edits later in the process. Edits bypassed are:
(21) Invalid Age Group and Service (24) Invalid Service to Diagnosis (25) Invalid Service to POS
Inpatient Candidate Authorization: only authorizations created for the inpatient rollup code of 0101 is considered. If the Auth is any other inpatient roll up code that is not 0101, then the authorization will not be considered and the current Authorization will need to be voided and new SAR submitted with the 0101 rollup service.
Authorization Bypass: Certain claims and situations will bypass the authorization denial (35)
Facility Fee Claims Consumers w/in their unmanaged units period Services w/in the pass-through period (by pass through days or pass through
units) Secondary claims where primary paid something
Site Ambiguity If there are multiple sites identified with the same priority, the logic to pick the best possible option is contingent if the service is actively effective on the site enforcement list and if a benefit plan was successfully identified on the claim.
First, the process will identify if a benefit plan was successfully selected
Yes – identify if the site that is selectable for the determined benefit plan. If there is still a tie, the site is ambiguous. A benefit plan is identified on the claim, but not a site.
No – site is chosen independently from the benefit plan based on rank and highest priority is chosen. Claims where a benefit plan was not successfully chosen will deny for ambiguity
At this point the process has identified a benefit plan and site for the claim as well if the contracted service requires an authorization. If these items were not identified then the claim will deny respectively.
Eligibility Edits: o (18) Patient has no insurance
the consumer does not have any active and effective eligibility for the date of service on the claim.
o (144) Service lapsed in contract for site on the claim Only for MCOs with the “Contracted for any site” parameter off forcing the
site selected to match a contracted site. The site determined and the contracted services match, but the contracted
service had ended prior to the date of service on the claim. o (36) Service not in Contract
Set to “Contracted for any Service: ON” the service submitted on the claim is not contracted for any site.
“Contracted for any Service: OFF” the service submitted on the claim is not contracted for the site determined for the claim.
ED claims are currently coded to pay under the Medicaid Benefit. If a state benefit plan was determined as the best benefit option from the matrix, then State funded ED claims will deny for this reason.
o (108) No Combination of patient/service/provider/dx is valid A benefit plan could not be determined for reasons other than consumer
eligibility. Typically means the consumer has eligibility, but not for the selectable
benefit plan. o (147) Member ineligible based on age/service/provider type
The site determined is set as an IMD site in Provider Network the consumers age is between 21 and 64 years old
o Contracts that are not in a draft status at the time of adjudication o Contract record is active and effective for the date of service on the claim o Contract details are active and effective for the date of service on the claim. o Contracts are not currently suspended at the time of adjudication. o Institutional ED claims get contracts for the HRCCR service while o Professional ED claims use the service submitted on the claim. o Inpatient claims identify contracts for rollup service 0101.
Allowed Billable days
The allowed number of days a provider must submit a claim from the date of service on the claim for Professional claims. This is set in each of the provider’s contracts (Both Medicaid and State). The billable days passed is calculated based on the date of service of the claim to the received date of the claim. Institutional claim days are calculated from the Statement Period To date to the received date of the claim. If the billable days are not set for the contract, the days default to 90. An additional 90 days is added to the contracted billable days when one of the two below criteria applies. If both apply only one additional 90-day period is applied. The most time a provider has to bill a claim is the contracted claim days (generally 90) plus 90 (180).
o the claim is identified as a rebill and the original claim was not denied for claim
received after billable period (5). o The claim is secondary (COB)
Contract Edit
o (5) Claim received after billable period If the total number of days from the date of service to the received date of
GET RATES FROM CONTRACTS OR RATE SCHEDULE o Identify and get a list of all active provider specific rates by contract, service and
license group o Identify and get a list of all active rates by rate schedule, service and license group.
Rate Types
o Rate Types 1 – 6 are assigned in a priority type method. This means if Rate Type #1 wasn’t assigned, then the claim will fall to see if rate type #2 can be assigned, if not there, then continue through to #6 until a rate is determined. Another way of understanding is a claim will not be assigned rate type #2 if the claim was already identified as having Rate Type #1.
o Rate Types 7 – 14 are assigned in a more independent manner in that the rate logic for these types are specific to the claim type and services submitted on the claim.
(1) Patient Specific Rate A rate exists in the provider contract for that consumer
The service is contracted for the site determined on the claim
The Rate is currently active and effective for the date of service on the claim
The Site the consumer rate is linked to is the site determined for the claim
Contract is not currently suspended at the time of adjudication
(2) Provider Specific Rate, Clinician Based
A patient specific rate could not be determined
The service on the claim is clinician based
A provider specific rate exists for the site determined on the claim The provider specific rate license is set to ALL or the license group identified for the rate matches the license group the clinician's license is mapped to
The clinician's license is effective for the date of service on the claim
The contracted site for the rate matches the site determined on the claim
(3) Provider Specific rate, non-Clinician Based
A rate was not determined under rate type 1 or 2
The service on the claim is non-clinician based
A provider specific rate exists for the site determined on the claim
The contracted site for the rate matches the site determined on the claim
(4) Rate Schedule, Clinician Based
A rate was not determined under rae type 1, 2 or 3
The service on the claim is clinician based A rate exists in the Rate Schedule (Dummy Provider prv_id = 100) for the funding source determined on the claim (State and Medicaid)
The license group for the rate matches the license group the clinician's license is mapped to.
The clinician's license is effective for the date of service on the claim
(5) Rate Schedule, non-Clinician Based mapped to all license groups
A rate was not determined under rate type 1, 2, 3 or 4
The service on the claim is non-clinician based
The rate on the rate schedule is set to license group "All"
(6) Rate Schedule, All license groups, non-Clinician based
A rate was not determined under rae type 1, 2, 3, 4 or 5
The service on the claim is non-clinician based A rate exists in the Rate Schedule (Dummy Provider prv_id = 100) for the funding source determined on the claim (State or Medicaid)
Service is contracted for the site determined on the claim
(7) Facility Fees
Claim determined a Facility Fee claim
MCO has an effective HRCCR rate set in their system parameters
The provider has service HRCCR contracted for the site determined on the claim The provider has a rate set for the HRCCR service for the site determined on the claim that is effective for the date of service.
(Claim Line Amount * MCO HRCCR Rate * Provider HRCCR Rate) / units billed
(8) Inpatient Rates
Claim has been determined an Inpatient claim
Revenue code is an Inpatient Revenue code
Provider is contracted for rollup code 0101 for the site determined on the claim
Rate setup for contracted site for the site determined on the claim
(9) Detox
Claim has been determined an Inpatient claim
Revenue Code 0116 or 0126 submitted on the claim
0116 or 0126 is specifically contracted for the site selected on the claim
A rate exists specifically for service 0116 or 0126.
If any of the above is not true, the provider inpatient rate will apply
(10) Institutional ED with HRCCR applied
Claim is Institutional
Claim has been identified as an ED claim
Revenue code is 045_
HRCCR service rate is active and effective for the site determined on the claim
(11) Institutional ED non-HRCCR - Lab and Professional claims Claim is Institutional
Claim has been identified as an ED claim
Revenue code is not 045_ Rate pulled from ED Service matrix where the HCPCS service has a designated category code of LB (Lab) or PF (Professional) that is effective for the date of service on the claim
(12) Institutional ED with HRCCR applied other than Lab or Pharmacy
Claim is Institutional
Claim has been identified as an ED claim
Revenue code is not 045_ Rate pulled from ED Service matrix where the HCPCS service does not have a designated category code of LB (Lab) or PF (Professional) that is effective for the date of service on the claim
(13) Professional ED
Claim is Professional
Claim is clinician based
Claim submitted with POS code 23 A rate exists in the Rate Schedule (Dummy Provider prv_id = 100) for the funding source determined on the claim (State and Medicaid)
The license group for the rate matches the license group the clinician's license is mapped to.
The clinician's license is effective for the date of service on the claim
(14) Innovations Variable Rate
Service is contracted for the service determined on the claim
Contracted service for the set is set and identified as a variable rate (variable_rate = 1)
(Claim Amount / total units)
Rate Types o Contract rate and numerical rate type indicator from above is set to the claim. o In the event the provider bills less than the contract rate identified for the claim
then the contract rate is adjusted and identified by appending .9 to the rate type numerical indicator.
Example: the rate for service H2011 is 33.68 for one unit. This rate type is a non-clinician standard rate and would be assigned rate type #5. However, the provider only billed $30.00. In this scenario, the contract rate for the claim will be adjusted from 33.68 to 30.00. This is identified when the rate type of 5 has .9 appended to it. In this case the rate type would be 5.9.
[dbo].[tb_claim_adj_dets].[rate_type] o Calculate and set the current adjudicated amount to the claim. The adjudicated
amount is the contract rate multiplied by billed units. Adjustments to the adjudicated amount and units happens later in the process.
o Identify and set the adjusted amount for the difference (above contract rate) of the billed amount and the adjudicated amount. The adjudicated units are set from the billed units at this time.
o Set the rate type ID as the database identifier for the drop-down list value. [dbo].[tb_dd_list_values].[dd_val_id] [dbo].[tb_claim_adj_dets].[rate_type_id]
o Create the adjudication adjustment detail for (1) Adjusted above contract rate.
Contract Rate Edit o (32) No Rate Available
A specific contract rate could not be identified during the rate determination process
BILLING, RENDERING AND CLINICIAN VALIDATION AND EDITS Identify Rendering Data Points
o Clinician Based? Determined earlier in the process from the current service setup in the Service Matrix
o Rendering NPI Submitted? Yes, if a rendering NPI exists on the claim o Clincian Associated with Provider? Yes, if the rendering clinician exists and effective
for the date of service in the Provider’s profile in Provider Network o Clincian License Match? Yes, if the active and effective license and license group for
the service and date of service matches the clincian’s active and effective license and license group for the date of service.
Contract Edit o (9) Clinician not licensed to perform the service
the clinician does not have an eligible and effective license that is mapped to the service.
o (156) Benefit Plan not valid for the Service/License Combo Clinician based service Service to License group mapping dos not exist for the benefit plan on the
claim .. or the service to license group to benefit plan mapping is not effective for
the date of service. o (140) Clinician not associated with the provider by rendering NPI or Attending NPI
(PRTF): Based on Rendering NPI unless PRTF claim then the Attending NPI is
validated Clinician is not associated with the Provider
.. or the clinician association is not effective for the date of service on the claim
o (28) Invalid Rendering NPI when a rendering NPI was submitted but does not match to a clinician or a
site. .. or when a rendering NPI is missing from the claim.
o (121) The Rendering Provider is not eligible to perform the service billed when the claim is for a clinician based service and the rendering NPI is a
provider NPI .. or when the claim is not clinician based and the rendering is a clinician NPI.
o (132) Attending Provider is not an MD for PRTF claims when the claim is for a PRTF service and the attending clinician NPI does not
have an effective MD license for the claim date of service. o (152) Billing taxonomy submitted is not associated with the Billing NPI
The Billing Taxonomy is effective for the Date of service .. and the Billing Taxonomy is mapped to any effective Bill Type
Specialty .. and the effective Bill Type Specialty is mapped to an effective Billing
NPI for the Site’s Numbers (Site Numbers Tile). Billing NPI is effective for the DOS and Site on the claim (Site Numbers
Tile) Must be complete and effective mapping from the date of service on the
claim for the Billing NPI to the Determined Site to the Bill Type specialty to the Billing Taxonomy registered for the site.
o (153) Rendering taxonomy submitted is not associated with the Rendering NPI Non-clinician based claim The Rendering Taxonomy is effective for the Date of service
.. and the Rendering Taxonomy is mapped to any effective Bill Type Specialty
.. and the effective Bill Type Specialty is mapped to an effective Rendering NPI for the Site’s Numbers (Site Numbers Tile).
Rendering NPI is effective for the DOS and Site on the claim (Site Numbers Tile)
Must be complete and effective mapping from the date of service on the claim for the Billing NPI to the Determined Site to the Bill Type specialty to the Rendering Taxonomy registered for the site.
o (154) Clinician Taxonomy submitted is not associated with the Clinician the claim is for a clinician based service the rendering clinician NPI and rendering taxonomy is not an effective
taxonomy in the clinician’s profile for the date of service on the claim
Service Matrix and BP Edits o (25) Invalid PC/POS combo
checks the existence of an effective and complete service to place of service mapping that is benefit plan specific.
EPSDT service authorizations bypass this edit. o (24) Invalid PC/Diagnosis combo
checks the existence of an effective and complete service to diagnosis group mapping and diagnosis group to diagnosis code that is benefit plan specific.
EPSDT service authorizations bypass this edit. o (21) Invalid Age Group to Diagnosis
checks the existence of an effective age group to diagnosis group mapping. EPSDT service authorizations bypass this edit. [dbo].[tb_age_groups] || [dbo].[tb_pc_to_age_groups]
o (23) Invalid Age Range for Diagnosis checks the existence of an effective age group to diagnosis group mapping. [dbo].[tb_age_range_for_diags]
DIAGNOSIS ASSESSMENT PERIOD Adjudication process creates a virtual list of all diagnosis to diagnosis group and diagnosis group to service code mappings for the AO (Assertive Outreach) diagnosis group. Diagnosis assessment claims are determined by the diagnosis and service code submitted on the claim. The total number of units submitted and used within the current adjudication batch is counted.
Out of the list of claims identified as assessment claims, identify the claims where the consumer’s age at the end of the month from the date of service is between 6 and 17 for state funded claims and then consumers under the age of 21 for Medicaid funded claims. Get the total units approved from prior claims.
Get the totals of claims history not in the current adjudication batch. Only approved claims are considered in the total.
Assessment Edit o (151) Assessment or Differed Diagnosis period has passed
When the total number of approved differed diagnosis units exceeds 6.
TARGET POPULATION (BENEFIT PLAN) VALIDATION AND AUTOMATION Only State funded claims are validated against the consumer’s target population. The MCO has the option to enable the “TP automation process” available in the System Parameters. When enabled, the consumer’s claims when the claim billed applies to a predetermined list of Target Pops, will bypass the validation edits. The Target Pop the consumer is missing will be loaded outside of the adjudication process. The Target Pop automation job runs daily at 8PM. Adjudication runs starting at 6PM then again at 9PM. Claims adjudicated at 6PM will have the identified missing TPs added to the consumer’s record when the job runs at 8PM. For ones identified as missing during the 9PM run will be added the next day when the TP automation job runs again. Coded Automated Target Populations: 'AMI', 'CMSED', 'ASTER' and 'CSSAD' TP Exclusions List: The exclusions list is used to omit target pops to not be validated for the TP to Diagnosis mapping. This list can be found in table [dbo].[ tb_tp_validation_exclusions]
Target Population Edits o (101) Patient does not have any effective TP for the DOS
no target pop exists for the consumer effective for the DOS. This is not checked for MCOs who have TP automation enabled and the
missing TP will be added during the TP Automation process. o (102) Patient TP is not mapped to the diagnosis on the claim
the diagnosis code submitted on the claim is not a valid diagnosis for any of the consumer’s effective target.
The TP exclusions list is used here, if the target pop is effective in the list then those claims are not checked.
This is not checked for MCOs who have TP automation enabled and the missing TP will be added during the TP Automation process.
o (103) Patient TP is invalid for the service submitted the service submitted on the claim is not mapped to an effective TP in the
consumer record. This is not checked for MCOs who have TP automation enabled and the
missing TP will be added during the TP Automation process.
PASS-THROUGH DAYS AND PASS-THROUGH UNITS Pass Through Days will allow authorization required service claims to bypass the auth validation edits up to a certain number of days.
o The window begins on the first date of service of the fiscal year to the number of days set in the benefit plan.
o Pass-through days process is coded to a fiscal year duration. This means on 7/1 of the consumers pass through is “reset.”
Example of Pass Through Days: Service is set to 30 pass-through days, the first date of service for the FY2017 is 8/15/17. Claims submitted for the service with dates of service from 8/15 to 9/13 will not require an auth. Any claim submitted with a DOS after 9/14 will deny if the service is not authorized. Beginning on 7/1/18, the consumer will receive another 30-day pass through period for FY2019.
When the total number of days between the first DOS and the DOS on the claim is under or equal to the limit set, then the (35) edit for authorization is bypassed. Pass Through Units is like pass through days but instead of the number of days, it is the total number of approved units. Generally, these are also set to fiscal year, however with pass through units the MCO has the option to choose the duration.
Duration Types
o Per Claim: service does not require an auth for units billed up to the pass-through limit for each claim submitted. Example: PT set to 30. A provider bills a claim every day for 35 units. 30 will approve while 5 will be adjusted for no authorization.
o Per Episode: service does not require an auth for units billed from the admission date submitted on the claim up to the limit set w/out an authorization. If an admission date is not submitted on the claim then the claim will not be a candidate for Episode pass through.
o Calendar year: service does not require an auth for units billed up to the pass-through limit from the first date of service after January 1.
o Fiscal year: service does not require an auth for units billed up to the pass-through limit from the first date of service after July 1.
o Lifetime: service does not require an auth for units billed up to the pass-through limit from the first date of service to all time. These pass-through units are not ever reset.
Other Auth bypass situations o Revenue code 0183 is coded specifically to not require an Authorization.
o Primary payer is Medicare on the claim -or- the consumer has an effective Primary payer (Medicare or TPL)
… and a COB reason exists ...but not reason 15, 96, 109, 197 or 198
…and there is a Primary paid (COB) amount
NON-COMPATIBILITY LIST (NCCI AND CCP) Service to Service Compatibility: The non-compatibility list is a list of service to service pairs that cannot be billed on the same day contingent on mapping configuration. Service to Group of Services Compatibility (collective limits): a separate list of compatibility edits for a group of services to be limited to the number of units set for the date of service. Example of a collective limit: Limit 90832, 90833+, 90834, 90836+, 90837, 90838+, 90839, 90846, 90847, 90849, 90853, 90791, or 90792 to two units per day, different attending, same billing provider. This means that a clinician A can bill 1 unit of any of these services. Clinician B can bill 1 of any of these services. Both claims from both clinicians are expected to be billed from 1 provider. Anything outside of that will deny for (11).
Configuration Options: o Same Attending Provider: When on, claim considered having a concurrent service
when a prior claim exists for the same consumer, provider and DOS performed by the same clinician.
o Same Billing Provider: When set to Yes, claim is considered has having a concurrent non-compatible service when a prior claim exists for the same consumer, provider and DOS regardless if the clinician is the same or not.
o If both Same Attending Provider and Same Billing Provider is set to “No” then the
claim is considered concurrent regardless if the rendering clinician or billing provider is the same or not.
Compatibility Edits o (11) Another concurrent service has been approved or waiting to be processed
when the claim is not valid for the same DOS as a prior claim for the same DOS using the service to service non-compatibility list.
[dbo].[tb_non_compatible_pcs] o (145) NCCI - Collective limit for the day exceeded
when the claim is not valid for the same DOS as a prior claim for the same DOS using the Collective Limit list.
[dbo].[tb_pc_collective_limits] || [dbo].[tb_pc_collective_limits_to_pcs] o (112) Add-on code cannot be billed by itself
when the accompanying service for the add on code does not exist or did not approve. This is using the list found in [dbo].[tb_accompanying_pcs]
[dbo].[tb_accompanying_pcs].[pc_id] represents the add-on code. [dbo].[tb_accompanying_pcs].[accomp_pc_id] represents the “base” code.
BENEFIT PLAN LIMITS, UNMANAGED UNITS, AUTH LIMITS AND DUPLICATE
CLAIMS Benefit plan limits are set in the Service Matrix. There is a daily, weekly, monthly, quarterly, yearly and lifetime limit that exists for each Service under each benefit plan. Overriding the benefit limits for certain situations is possible by SAR submission. When overriding limits exist on the authorization those limits override the limits set in the benefit plan.
Duplicate Claims o Professional Claim: considered a duplicate if a prior approved claim exists for the
same consumer, service, date of service, provider and claim type (I or P). o Institutional Claim: considered a duplicate if a prior approved claim exists for the
same consumer, revenue code, HCPCS code, date of service, place of service (bill type), provider and claim type (I or P).
Duplicate Claim Edits o (15) Duplicate Claim
a prior approved claim exists based on the criteria mentioned above o (141) Another Approved R&B Service Exists, cannot bill another
if a prior approved claim that exists for the same date of service where the HCPCS code on the prior claim is marked as an R&B service in the service matrix.
Edit applies to Inpatient claims only.
Benefit Limit Periods How the limit period is determined will vary depending on the limit type and if the claim is adjudicating against an authorization or not. If the claim is adjudicating with an authorization the authorization effective date is used, otherwise the origin date set for each limit period in the MCS Claim Limit Periods reference table [dbo].[tb_claim_limit_periods] is used.
No Authorization limit period is the date of service
With Authorization limit period is the date of service
Weekly Limits
No Authorization uses a reference date of 1/2/2000 which is known to be a Sunday. Weeks for non-authorized services start on Sunday. To identify the start of the week for the given date of service then the number of full weeks between the reference date to the claim date of service. That number, in weeks is added to the reference date to get the start of the weekly period for the date of service.
With Authorization uses a reference date of the effective date of the auth which could be any day of the week. To identify the start of the week for the given date of service then the number of full weeks between the reference date to the claim date of service. That number, in weeks is added to the reference date to get the start of the weekly period for the date of service
SQL Function DATEADD(WEEK, DATEDIFF(WEEK, @clp_start_date, clm_dos), @clp_start_date)
Monthly Limits
No Authorization uses a reference date of 1/1/2000 which is known to be the first of the month. Weeks for non-authorized services start on the first of every month. To identify the start of the week for the given date of service then the number of full months between the reference date to the claim date of service. That number, in months is added to the reference date to get the start of the monthly period for the date of service.
With Authorization uses a reference date of the effective date of the auth which could be any day of the month. To identify the start of the month for the given date of service then the number of full months between the reference date to the claim date of service. That number, in months is added to the reference date to get the start of the monthly period for the date of service.
SQL Function DATEADD(MONTH, DATEDIFF(MONTH, @clp_start_date, clm_dos), @clp_start_date)
Quarterly Limits
No Authorization uses a reference date of 7/1/2000 which is known to be the beginning of the first quarter of the fiscal year. Quarters for non-authorized services start on the first day of every 3rd month. To identify the start of the quarter for the given date of service then the number of full quarters between the reference date to the claim date of service. That number, in quarters is added to the reference date to get the start of the quarterly period for the date of service.
With Authorization uses a reference date of the effective date of the auth which could be any day of the quarter. To identify the start of the quarter for the given date of service then the number of full quarters between the reference date to the claim date of service. That number, in months is added to the reference date to get the start of the monthly period for the date of service.
SQL Function DATEADD(QUARTER, DATEDIFF(QUARTER, @clp_start_date, clm_dos), @clp_start_date)
uses a reference date of 7/1/2000 which is known to be the beginning of the of the fiscal year. Years for non-authorized services start on the first day of the fiscal year. To identify the start of the year for the given date of service then the number of full years between the reference date to the claim date of service. That number, in years is added to the reference date to get the start of the yearly period for the date of service.
With Authorization
uses a reference date of the effective date of the auth which could be any day of the year. To identify the start of the year for the given date of service then the number of full year between the reference date to the claim date of service. That number, in years is added to the reference date to get the start of the monthly period for the date of service.
SQL Function DATEADD(YEAR, DATEDIFF(YEAR, @clp_start_date, clm_dos), @clp_start_date)
Benefit Plan Limit Adjustments
o Full adjustment(Denial): If the total amount of currently used and approved units equals to or is more than the limit amount set for a given interval then the date of service meeting or exceeding the limit is fully adjusted and denied for the limit interval that was reached.
Example: Weekly limit set to 10, 10 units currently approved. Another claim is billed for 10 units for the same week then all 10 will deny for Weekly limit exceeded.
o Partial Adjustment: If the total amount of currently used and approved units is under the limit set for the interval, but the claim billed will meet that limit and more. The difference between the limit set for the interval and the amount used plus the amount billed will be adjusted off for the interval limit that was exceeded.
Example: Weekly limit set to 10, 8 units are currently approved. Another claim is billed for 4 units. 2 units for the date of service will be adjusted off for Weekly Limit exceeded while the other 2 units for the date of service will approve and continue through the adjudication process.
Benefit Plan Limit Edits o (13) Daily Limit Exceeded
The adjustment for the units billed over the daily limit amount o (40) Weekly Limit Exceeded
The adjustment for the units billed over the weekly limit o (31) Monthly Limit Exceeded
The adjustment for the units billed over the monthly limit o (124) Quarterly Limit Exceeded
The adjustment for the units billed over the quarterly limit o (125) Yearly Limit Exceeded
The adjustment for the units billed over the yearly limit
Unmanaged Units The unmanaged units are services that are typically set as auth required in the providers contract but allow up to a certain number of initial units without requiring an authorization. Unmanaged units are broken into four groups, Child (0-17) and Adult (18+) and then by funding source of either State or Medicaid. Unmanaged units are set in table MCS [dbo].[tb_basic_unit_periods]. Unmanaged periods have an annual fiscal year period and consumers become eligible for more unmanaged units at the beginning of each fiscal year.
Unlike Pass through units as being set per service, unmanaged units are calculated collectively in that all approved services where the service is marked as a Basic service in the Service Matrix are counted towards the unmanaged unit limit.
Only claims that did not adjudicate against an authorization are calculated towards the used unmanaged units. It is possible to have claims approve under unmanaged units, then have claims adjudicate against an auth, and then again as unmanaged if the consumer has not consumed all their units for the fiscal year period.
After the total number of units used on previous claims and units used in the current adjudication batch, it is then determined if the claim is under or over the unmanaged limit. If the claim is under the unmanaged limit, then the claim is set to bypass reason (35) for Service Not Authorized. If it has been determined the consumer has used all unmanaged units and the consumer does not have an effective auth then the claim will deny for (4) for Basic Units Consumed.
Authorization Limits Authorized Units used are calculated by totaling all adjudicated units for approved claims that adjudicated against the auth (and the auth is linked to the claim). Units are then adjusted off for reason (3) Authorized Units Exceed of the difference between the total units currently approved against the auth plus the amount billed minus the authorized units total available. If any remaining units remain to approve then those units will continue through adjudication.
Authorization Edits
o Authorized Units Exceed The difference in the (Units Billed + Units Approved) – Authorized Units
o (35) Service not Authorized when a service is marked as auth required in the provider’s contract for the
site and an effective authorization for the claim does not exist. o (123) Non-Covered days/Room charge adjustment: [Disabled]
deny claims where the date of service is the same as the statement period to for services marked as “Do not pay discharge day” in the service matrix.
o (7) Patient has Other Insurance (COB Primary) when the consumer has an effective primary payer that is not on the bypass
for the service and the primary payer is eligible to pay towards the service where the claim was billed to the MCO as primary.
Benefit Plan on the claim is either State or Medicaid B. Medicaid C claims are not checked for Primary Payer.
The service is not on the bypass list for the consumers effective primary eligibility.
o (90) Non-covered Ancillary Services applies to inpatient R&B claims only. For ancillary revenue codes billed with
the R&B revenue code of 01__ or a HCPCS code of YP82_
ADJUDICATION EDIT CONFIGURATION The claim adjudication process can be configured by the MCO by disabling edits entirely or disabling an edit by claim type (Professional, ED, Inpatient, Residential (PRTF), ICF/MR and Facility Fee claim types). Edits can also be future dated or end dated. The effective dates will reference the received date of the claim. Edits can also can be re-prioritized to a custom order.
For full adjustments (denials), the lowest ordered adj edit for the claim is set as the denial reason and the other adj edits the claim hits is set in the other adjudication reasons field on the claim. [dbo].[tb_claim_adj_dets].[other_adj_reasons]
Manual Review Only when claims flagged as Manual Review claims (ie: ED claims or claims with a large billed amount) AND have not denied for any other reason, in other words would approve otherwise, will pend for Manual Review. ED claims that pend for Medical Review will have “Pend for Medical Review” in the adjudication reason comments
COB Adjustments and the “Lessor of Methodology”
o Primary Payer Adjustments: If a primary payment amount is submitted on the claim then that amount is applied to the claim in order of adjudication ID. The NET amount that remains from the difference of the MCO (contract rate * adjudicated units) – Primary Paid amount will be applied to the remaining claim days. If the claim was also submitted with a Patient PML amount or some other Patient amount then that amount is included in the total primary paid amount.
PML Value Codes: 23, D3 Other Patient Amount Value Codes: 31, 66
o Patient Responsibility: If a patient responsibility amount is submitted, then instead of paying the net amount due for secondary payment, the lessor amount between the Patient Responsibility amount and the Net amount due is paid and applied to the remaining days after the Primary paid (COB) adjustment. https://www.nctracks.nc.gov/content/public/providers/provider-communications/provider-announcements/Medicare-Crossover-Update.html
COB Adjustments and the “Lessor of Methodology” o (10) Coinsurance Amount
CoB adjustment reason for professional claims Adjustment made due to the primary payer payment amount towards the
service o (127) The impact of prior payer(s) adjudication including payments and/or
adjustments CoB adjustment reason for Institutional claims. Adjustment made due to the primary payer payment amount towards the
service o (128) Amount in excess of prior payer(s) coinsurance
Amount adjusted due to patient responsibility amount. This is the amount used for the Lessor of Methodology. The lessor amount between the Patient Responsibility amount vs. the Net
amount after the primary payment is applied. o (129) Monthly Medicaid patient liability amount
amount adjusted due to the patient monthly liability amount. o (130) Coinsurance amount
adjustment reason for other patient amount types that is not PR or PML. o (157) Adjustment due to COB Allowable Amount
COB allowed amount is submitted and that amount is less than the claim amount
Funding Capitation Limits At the end of the adjudication process when the process has finished approving and denying claims in the batch, is when the funding caps and claim adjustments are made. A claim is tagged with the funding cap ID based on claim elements and how the funding cap is setup. A claim can only be tagged with one single funding cap. This is to keep claims that are currently under one cap from being calculated under another effective funding cap for the provider. The funding cap process will collect all approved claims in the current batch and find the corresponding funding cap and tag newly received claim with the cap identified.
After funding caps have been identified for the new claims, all claims previously received and processed and the new claims are totaled. At this point, if the total cap used for previous claims plus the total adjudicated amount for the current batch is over the cap amount, then the difference is then deducted from claims order by descending claim adjudication ID. Funding caps for claims in the current adjudication batch are then updated with the current used amount. Since the claim is tagged with a funding cap once the claim is approved, and if an update to the funding cap is made after the claim was received and tagged, then the funding cap and claims will be updated by the next day after the nightly funding cap reclassification process runs. This process will find any funding caps that was updated that day and if one is found, then all funding caps for the provider that is currently effective or has an end date ending this year then those funding caps will be reclassified to then update the claims to the updated funding cap. If no errors during the adjudication process then Claim Adjudication results are set to the claim. GL entries are created for GP payment/recoupment transactions. Note: Any claims already denied for 97 - Charges are covered under a capitation agreement/managed care plan would need to be re-adjudicated to hit the cap if more funds were added.
Map GL accounts
Approved claims with an adjudicated amount more than $0 and claims that are not for a sub capitation agreement are mapped with a GL account. These are GP Accounts used to classify payments to a provider.
Adjudication Rollback In the event the adjudication process runs past midnight, then the adjudication details will be for the day after the claim was processed. For this, those claims are identified and rolled back to the last second before midnight: [ ie: 2017-07-01 23:59:59.000 ]. This ensures claims do not miss a cutoff date if the adjudication process runs long.
After the adjudication process completes, an email will be sent out with an adjudication summary and list of top 20 denial reasons.
Current Adjudication Batch RunTime Batch ID: each adjudication job gets assigned a batch ID. This is the numerical
identifier for the execution job. o [dbo].[tb_adjudication_batches]
Batch Type: Can either be FULL or Partial o FULL is indicating this adjudication process was executed on all claims
waiting for adjudication o PARTIAL is when only one claim header was adjudicated.
Start Time: The time of day the adjudication batch started End Time: the time of day the adjudication batch completed RunTime: the amount of time, in minutes/seconds the batch took to complete Approval %: total approved claims divided but total number of approved and
adjusted claims times 100 o Approved Claims / (Approved claims + Adjusted Claism) * 100 o Contract Rate adjustments (Adj Reason 1) and non-covered ancillary
services (Adj Reason 90) are not included in the total number of adjusted claims due to commonality.
o ED claims, reverted claims and overridden claims are not included. Adjudication Claims Status Totals Status ID: Numerical claim status ID
o [dbo].[tb_claim_statuses] Status Description: Description for the status ID Total Claims (adj_id): Total claims by adjudication ID Claim Type Totals (by Header) Claim Type: Type of Claim (Pro, ED, FF, IP, RES, ICF) Total Claim Headers: total number of claims for each type by header ID Top 20 Denials Reason ID: The adjudication reason edit ID Reason Description: Description of the Edit Total Claims (adj_id): Total number of claim adjudication IDs that hit the edit for
