Beacon Healthcare Solutions' Home Page
Login to Beacon Healthcare Solutions' subscription only areas
Shop Beacon Healthcare Solutions for all your Medicare Data needs
Search Beacon Healthcare Solutions
Contact Information for Beacon

Medicare Data Final Action Algortithms

Choose from Institutional or Non-Institutional

ALGORITHM FOR "NETTING" INSTITUTIONAL CLAIMS

Deriving a "netted" or final action file from a raw claims file requires the resolution of two major problem areas: the paper matching of debit/credit pairs and the elimination of duplicate claims. Following is the algorithm developed for institutional claims:

1. Use the following data elements to sort the institutional claims:

  1. HIC (BENE_CLM_ACNT_NUM and CTGRY_EQTBL_BENE_IDENT_CD)
  2. Provider Number (PRVDR_NUM)
  3. Claim From Date (CLM_FROM_DT)
  4. Claim Through Date (CLM_THRU_DT)

NOTE: All records with these four elements are considered a "group" and are analyzed in memory together.

2. Keep those groups consisting of a single original debit; i.e., Query Code (CLM_QUERY_CD) = 3.

NOTE: 91% of the groups fall into this category, requiring no further analysis.

3. Analyze remaining groups by checking the following data elements:

  1. Query code (CLM_QUERY_CD)
  2. CMS Processing Date (NCH_WKLY_PROC_DT)
  3. ICN (FI_DOC_CLM_CNTL_NUM and/or FI_ORIG_CLM_CNTL_NUM)

NOTE: Prior to Version G implementation, only the document control number for the current transaction was utilized. With Version G, both the current ICN and the original ICN were used. Prior to Version H, the CMS(previously HCFA) Processing Date was named HCFA_CLM_PROC_DT.

4. For Inpatient, Skilled Nursing Facility, and Hospice claims, keep only one record. Use the following logic to identify which record to retain:

  1. If all records in group have the same Query code, keep the latest CMS processing date.
  2. Otherwise (where grouped records have different Query code), drop any cancel-only debit/credit pairs.
  3. From the remaining records, keep the latest CMS Processing date with Query code = 5 or Query code = 3 (if no 5), or Query code = 1 (if no 5 or 3).

NOTES: For 1992, about 6.5% of all Inpatient transactions were dropped. Of those dropped, 60% were classic debit/credit/replacement debit variety; 7% were duplicates; and the remaining were cancel-only debit/credit pairs.

5. For Outpatient and Home Health Agency claims, legitimately there can be multiple claims for the same period from the same provider. Use the following logic to identify which record(s) to retain:

a. Attempt to pair credits to debits by matching ICN, or Total Charges* (CLM_TOT_CHRG_AMT), or oldest debits first. (Apply match routine in that order: first check ICN. If no match on ICN, then look at total charges, followed by oldest debits.)

*NOTE: Prior to Version G implementation, the Reimbursement Amount (CLM_PMT_AMT) rather than Total Charges was used in this match criteria.

b. After matching, which will result in either no debits or a number of debits remaining, check for duplicates.

  1. If multiple records have same valid ICN, keep only one claim.
  2. If multiple records have different valid ICNs, keep all claims (even if total charges are the same).
  3. If multiple records have invalid or missing ICNs and total charges are the same, keep only the latest claim.
  4. If multiple records have invalid or missing ICNs and total charges are different, keep all claims.

NOTES: For 1992, about 4% of the Outpatient transactions were dropped. Of those dropped, 65% were cancel-only debit/credit pairs; 30% were debit/credit/replacement debit groups; and 5% were duplicates. In approximately half of the Outpatient groups, multiple claims were kept.

6. Keep no claims with Query Code = 0.

back to top

 

ALGORITHM FOR "NETTING" PART B PHYSICIAN/SUPPLIER/DMERC CLAIMS

 Following is the algorithm developed for deriving a "netted" or final action file from a raw physician/supplier or DMERC claims file:

1. Use the following data elements to sort/sequence the claims:

  1. HIC (BENE_CLM_ACNT_NUM and CTGRY_EQTBL_BENE_IDENT_CD)
  2. Carrier Control Number (CARR_CLM_CNTL_NUM)
  3. CWF Accretion Date (CWF_CLM_ACTRN_DT)
  4. CWF Accretion Number (CWF_CLM_ACRTN_NUM)
  5. CMS Processing Date (NCH_WKLY_PROC_DT)

NOTE: Elements a. and b. (in ascending order) are the sort keys that uniquely identify a single physician/supplier or DMERC claim. Elements c. through e. (in descending order) are used to sequence the grouped claims. Prior to Version H, the CMS Processing Date was named: HCFA_CLM_PROC_DT).

2. If the first record has a Disposition Code (CLM_DISP_CD) = 01 (61) or 02 (62), accept as a final debit. Discard any records following within the sequence of HIC and Carrier Control Number.

3. If the first record has Disposition Code = 03 (63), meaning that the final action was a credit canceling any previous debits, discard the entire sequence of claims with the same HIC and Carrier Control Number.

4. After cleaning the claims, the user may wish to eliminate any "fully-denied" claims; i.e., where the claim (including all line items) was denied in its entirety. Use the Payment/Denial Code (CARR_CLM_PMT_DNL_CD) to identify denied physician/supplier claims. Drop any claim with a Payment/Denial Code = 0, P, X, or Y.

NOTES: For 1992, 5% of all physician/supplier transactions were dropped. Of the final records kept, about 90% were allowed claims; 10%, denials. Also, the final action claims were initial records in 98% of the cases; replacement records, in 2%. Prior to Version H, the Payment/Denial Code was named: CWFB_CLM_PMT_DNL_CD).

back to top

 


Home | About BHS | What's New | Products | Compliance | Beacon Healthcare SolutionsServices |Healthcare Reference Information | Additional Resources

Copyright © 2000-2006, Beacon Healthcare Solutions, LLC
Technical problems? Please contact our web development team.