(Medicare Claims Processing Manual)

Effective with July 2007, CMS directed its A/B MACs and DME MACs  to now base their severe error decision calculus upon the number of 111 errors received rather than percentage of such errors.  Therefore, when an A/B MAC or DME MAC or its shared system maintainer receives a BCRC  Detailed Error Report that indicates that the trading partner is in production and the number of 111 (flat file) errors is equal to or greater than one, the A/ B MACs and DME MACs shared system shall suppress the generation of special provider notific ations, as provided in  70.6.1 of this chapter, until after the severe error condition(s) has/have been analyzed.  ( NOTE:  If the 222 and/or 333 errors indicated on the BCRC  Detailed Error Report do not  exceed the four (4) percent parameter, then the A/B MAC and DME MAC shall continue with the generation of the provider notification letters for those errors while it is analyzing the 111 severe error(s).)   IMPORTANT:  Effective October 1, 2007, A/B MACs and DME MACs  and their systems shall have the capability to initiate a claims repair process, internally or at CMS direction, for situations in which they encounter high volume 222 or 333 error rejections that do not meet or exceed the established error threshold parameters.  Before initiating a cl aims repair for error situations that fall below the established percentage parameters, the affected A/B MACs and DME MACs shall first contact a member of the CMS COBA team to obtain clearance for that process.   When an A/B MAC or DME MAC or its shared sys tem maintainer receives a BCRC Detailed Error Report that indicates that the trading partner is in production and the percentage of 222 (HIPAA ASC X12 837) errors and 333 (trading partner dispute) errors is equal to or greater than four (4) percent, the  shared system shall suppress the generation of special provider notifications, as provided in 70.6.1 of this chapter, until after the severe error condition(s) has/have been analyzed.  NOTE:  If the number of 111 errors indicated on the  BCRC Detaile d Error Report is not  equal to or greater than one (1), then the A/B MAC or DME MAC shall continue with the generation of the provider notification letters for those errors while it is analyzing the 222 and 333 severe errors.   For each of the severe er ror situations discussed above, A/B MACs and DME MACs, or their shared systems, shall suppress the special provider notification for a minimum of five (5) business days.  The shared systems shall also have the capability to adjust the parameters for genera tion of the provider notification letters, as referenced in 70.6.1 of this chapter, of up to 14 work days while analysis of the claims that are being held for possible full claim file repair is proceeding.   Effective October 1, 2007, all A/B MACs and DM E MACs  shall have the capability to suppress their provider notification letters for a timeframe of up to 14 work days, or longer at CMS direction, where they initiate a claims repair process when claims with 222 or 333 errors fall below the normally established four (4) percent threshold.   Also, for each of the situations discussed above, the A/B MACs and DME MACs shared systems shall establish percentage parameters for each error source code (222 and 333) that allow for flexibility within a range ( e.g., 1 to 10 percent). b. Additional Information Highlighting Possible Severe Error Conditions on the BCRC Detailed Error Reports.   Effective with July 2006, the BCRC  will report one of the following error sources and error codes/trading partner dispute codes that may be indicative of a severe error condition on the returned BCRC  Institutional and Professional Detailed Error Reports:  1.) Error source code 111 will be reported in field 10, along with a 6-digit error code in field 11 (note:  unlike routine reporting of flat file errors, a full claim file error condition would be indicated if there were numerous instances of the same error code repeated throughout a Report); the description of the problem(s) that has/have caused the full claim file to  be unusable will be reported in field 12 (error description);  2.) Error source code 222 will be reported in field 10, along with a 6-digit error code in field 11 that begins with an N; the description of the problem(s) that has/have caused the full claim file to be unusable will be reported in field 12 (error description);  3.) Error source code 333 will be reported in field 10; an error/trading partner dispute code 999 (trading partner disputeother) will be reported in field 11, left- justified  and followed by spaces; and a description of the problem(s) that has/have caused the full claim file to be unusable will be reported in field 12 (error description).  DME MACs and their shared systems shall process NCPDP Detailed Error Reports returned from the BCRC  that contain the following combination of error source codes, error/trading partner dispute codes, and error descriptions within the Reports:  1.) Error source code 111 will be reported in field 9, along with a 6-digit error code in field 10 (NOTE: U nlike routine reporting of flat file errors, a full claim file error condition would be indicated if there were numerous instances of the same error code repeated throughout a Report); and a description of the problem(s) that has/have caused the full claim file to be unusable will be reported in field 11; or   2.) Error source code 333 will be reported in field 9; an error/trading partner dispute code 999 will be reported in field 10, left-justified and followed by spaces; and a description of the proble m(s) that has/have caused the full claim file to be unusable will be reported in field 11 (error description).   c. A/B MAC and DME MAC Actions Following Suppression of the Special Provider Notification Letters to Analyze Possible Severe Error Conditions   When A/B MACs and DME MACs receive BCRC  Detailed Error Reports that contain 222 or 333 errors with percentages that are at or above the established parameters or if the MACs receive 111 errors that are at or above zero (0) they shall work closely wi th their  shared system maintainers to determine the timeframes for developing, testing, and applying a fix to correct the severe error(s) that was/were identified within the ASC X12 837 or NCPDP files that were previously transmitted to the BCRC .  The shared system maintainers shall then report the timeframes for developing, testing, and applying a fix to the full claim file problem in accordance with their procedures as outlined in their systems maintenance contract.  If CMS determines that the timeframes for affecting a full claim file repair of the previously transmitted claims exceed what is considered reasonable (a maximum of 14  work days, unless determined otherwise by CMS), a designated COBA team representative will notify the A/B MACs and DME MACs an d their shared system maintainers via e -mail to abort the full claim file repair process.   As noted above, effective October 1, 2007, all A/B MACs and DME MACs shall have the capability to suppress their provider notification letters for a timeframe of up to 14 work days, or longer at CMS direction, where they initiate a claims repair process when claims with 222 or 333 errors fall below the normally established four (4) percent threshold.  Upon receipt of a notification from the CMS C OBA team representative that indicates that the timeframes for fixing a full claim file problem exceed those that are acceptable to CMS, the A/B MACs and DME MACs shared systems shall abort the full claim file repair process.  A/B MACs and DME MACs shall then follow the requirements provided in 70.6.1 of this chapter with respect to the special provider notification and other COBA crossover operational processes.  In such cases, however, A/B MACs and DME MACs shall not be required to wait the customary fi ve (5) business days before generating the special provider notification letters to their affected physicians/practitioners, suppliers, or other providers of service.  In the event that CMS indicates that a full claim file repair process is feasible, the A /B MACs and DME MACs shared systems shall have the ability to cancel the generation of the provider notification letters, as stipulated in 70.6.1 of this chapter, for the repaired claims and only generate the provider notification letters for the claims containing legitimate 111, 222, or 333 errors not connected with the severe error condition(s).   3. Steps for Ensuring that Only Repaired Claims are Re -transmitted to the BCRC   Once the A/B MACs and DME MACs shared systems have determined that they ar e able to affect a timely repair to the full claim files that were previously transmitted to the BCRC , they shall take the following actions:   a) Apply the fix to the unusable claims;   b) Compare the claims files previously sent to the BCRC  with the repaired claims file to isolate the claims that previously did not  contain the error condition(s);   c) Strip off the claims that did not contain the error condition(s), including claims that conta ined 111, 222, and 333 errors that were not connected with the severe error condition(s).  For the latter set of claims (those with 111, 222, and 333 errors that were not connected to the severe error condition), MACs shall then generate the provider notif ication letters, as stipulated in 70.6.1 of this chapter and specified in the concluding paragraph of the above sub- section entitled, Contractor Actions Following Suppression of the Special Provider Notification Letters to Analyze Possible Severe Error Conditions;   d) Recreate the job; and   e) Send only the repaired claims to the BCRC .  The shared systems shall add an indicator18 to the BHT02 (Beginning of the Hierarchical Transaction/Transaction Set Purpose Code) segment of the HIPAA ASC X12 837 flat file  to designate that the file contains only repaired claims.  In addition, the shared systems shall include the repaired claims in different ST -SE envelopes to differentiate the repaired claims from normal ASC X12 837 flat file transmissions.    The DME MAC sh ared system shall add an indicator R after the COBA ID reported in the Batch Header Record in the Receiver ID field (field number 880- K7) of the NCPDP claim when transmitting the repaired claims to the BCRC .  4. COBA Repair Process Changes Effective with  July 2012   A. Repairing  Flat File (111) Errors All A/B MACs and DME MACs shall effectuate repair of even one 111 errored COB claim if the COBA trading partner is currently in production mode.  ( NOTE:   Parties interested in previewing a listing of all 111 errors that the BCRC  will apply to incoming COB flat files should refer to 70.6.1.1 of this chapter.)   The shared systems shall accept the 111 error codes (see 70.6.1.1 of this chapter) that the BCRC  generates during its application of business level editing to incoming ASC X12 837 COB flat files.  The shared systems shall also make modifications to any 111 error tables that they maintain only in association with ASC X12 837 COB flat files.  IMPORTANT:  A/B MACs and DME MACs shall only issue special provider notification letters in association with their receipt of 111 errors if:  1) the timeframe for effectuating a claims repair falls outside acceptable parameters (e.g., will take 30 -60 days or longer); and 2) the volume of affected claims is low (i.e., under 1,000 claims per week).  A/B MAC and DME MAC crossover contacts should contact a member of the CMS COBA team if they have questions regarding how they should proceed in association with a given 111 error situation.  B. Repairing 222 and 333 Errors Associated With Production New Version Format Claims   A/B MACs and DME MACs and their shared systems shall repair 222 or 333 errors in association with production new format versi on claims if the error percentage they encounter meets or exceeds four (4) percent.   A/B MACs and DME MACs shall alert their shared system or Data Center, as per established protocol, for purposes of initiating each needed claims repair process in associat ion with new format version COB claims.  IMPORTANT:  A/B MACs and DME MACs that wish to effectuate a repair of new format version production claims whose error percentage falls below four (4) percent shall contact a member of the CMS COBA team before att empting that action.  ( NOTE:   As a rule, CMS will grant approval for such a repair if the volume of errored claims justifies that action and  if the timeframe for repair is acceptable.)