A/B MACs, and CEDI Edit Requirements

60.1 - A/B MACs, and CEDI Edit Requirements (Rev. 2803, Issued: 10-28-13, Effective: 09-17-13, Implementation: 09-17-13) A/B MACs and CEDI are required to edit submitted transactions at the front end to determine whether they are sufficiently complete to enable processing. Transactions that are not legible, or do not include adequate data to be considered an acceptable EDI transaction, must be rejected or returned as unprocessable. “Rejected” or “returned” transactions are not classified as “received” by Medicare. A/B MACs and CEDI are not required to assign a control number or a receipt date to those transactions rejected or returned as unprocessable. Nor are they required to retain any record of those transactions pending correction and resubmission by the original sender. See § 50 and § 70 of this chapter for further editing and testing requirements. CEDI is required to assign a control number and a receipt date to those claims transactions accepted by CEDI. They are required to retain any record of those originally submitted transaction pending correction and resubmission by the original sender. See § 50 and § 70 of this chapter for further editing and testing requirements. A. Translation and Date of Receipt Editing If a shared system detects an improper flat file format/size (incorrect record length, record length exceeding 32,700 bytes, etc.), the flat file will be rejected back to the file’s submitter (A/B MACs and CEDI) by the shared system with an appropriate error message. The date of receipt of a claim is the date a claim is received by the A/B MACs and CEDI and not a subsequent date on which the claim may have been received by the shared system. The date of receipt must be an actual calendar date and may not be all zeroes or a future date. See § 80.2.1 of Chapter 1 of this manual for additional information on establishing the date of receipt of a claim. B. Implementation Guide (IG) Edits: ASC X12 Version 5010 and NCPDP Version D.0 In conjunction with front-end translation, A/B MACs (A)are to also conduct IG edits to identify submitted data elements that do not comply with data element requirements added by the IG developers, using either software available from FISS or other software which is able to edit at this level. A/B MAC (B) shared systems conduct IG edits for transactions sent to the A/B MACs (B). CEDI conducts IG edits for transactions sent to the DME MACs. In many cases, IG edits are more restrictive than those established by the ASC X12 standard that served as the platform for development of the TR3. For instance, the ASC X12 standard might allow a maximum of 30-digits in a data element, but an IG note could limit the maximum size to 20-digits. Or the number of valid digits that may be entered in a data element as identified by the qualifiers that apply to the data element, might not permit reporting of more than 15-digits even though the standard permits up to 30-digits. No national standards have been adopted under HIPAA for acknowledgment or error reporting for any of the HIPAA format transactions. However, Medicare has adopted the ASC X12 999 implementation acknowledgment and ASC X12 277CA claim acknowledgment for this purpose effective with the implementation of version 5010. For Version 5010 DME MACs will continue the use of proprietary error reporting for CMN rejection reports, which are returned to DME submitters through CEDI. IG and Medicare program error reports related to electronic transactions must be sent to the submitters of those transactions electronically. IG level edits typically affect a small number of the transactions in a batch. Whenever not precluded by the standard, A/B MACs and CEDI are expected to reject individual transactions that are identified via IG edits and not reject the entire batch of transactions in which those transactions were submitted. A/B MACs (A) share IG editing responsibilities with FISS (shared system documentation indicates which IG edits are conducted by the shared system). A/B MACs (B) shared systems are responsible for IG editing of Part B professional transactions. CEDI is responsible for IG editing of DME transactions. When editing for IG compliance, the responsible party must verify that: • Amounts, percentages, integers, and other fields designated in the IG as numeric are right-justified and zero-filled if the incoming data are smaller than the Medicare flat file field size; • Fields designated in the IG as alphanumeric are left justified and space filled if the incoming data are smaller than the Medicare flat file field size; • All non-Medicare data field lengths correspond to the maximum IG length. • Incoming alphanumeric non-Medicare data are left justified and space filled if the data are smaller than the Medicare flat file field size; • Incoming numeric non-Medicare data are right justified and zero-filled if the data contain fewer integers than the Medicare flat file field size; and • Non-Medicare data (and Medicare data elements where field sizes are in excess of the core system) are mapped to the Medicare flat file (and later written to the store-and-forward repository (SFR) by the shared system).