(Medicare Claims Processing Manual)

For ASC X12 transactions A/B MACs and CEDI  translators must also:   Convert lower case to upper case;    Pass all spaces to the flat file for fields that are not present in an inbound transaction but which are included in the flat file;    Map Not Used data elements for A/B MACs and CEDI based upon that segments definition only, i.e., if a data element is never used, do not map it.  However, if a data element is required or situational in some segments but not used in others, then it must be mapped;   Not Used data elements are not to be mapped to the flat file; and    Accept multiple interchange envelopes within a single transmission. This is only applicable to ASC X12 transactions as NCPDP only processes a single batch per transmission.    Translate data for outgoing transactions supplied by the shared system in the flat file format into the appropriate, compliant IG standard as adopted under HIPAA. Translation of outgoing transactions is to follow the same character set and case requirement s noted for incoming translation. A/B MACs and CEDI  are not required to accept or process ASC X12 999 implementation acknowledgment transactions from trading partners for any outgoing ASC X12 transactions.  See Section 60 for additional A/B MACs and CEDI  translator edit requirements that may be specific to individual standards.   50.3 - Common Edits and Enhancements Module (CEM) - General Description Across All Versions  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  The CEM e stablishes consistent editing, acknowledgments, and error handling of the electronic data interchange (EDI) transactions across Medicare Administrative Contractor (MAC) jurisdictions.  The CEM is implemented by each A/B MAC in their local data center (LDC) . The Part A and Part B CEMs were developed by their corresponding Medicare Shared System Maintainers (SSMs).  The Durable Medical Equipment (DME) MACs editing, acknowledgment, and error handling of EDI transactions is processed by the Common Electronic Da ta Interchange (CEDI) contractor.  Each A/B MAC has integrated the CEM into its Front- End Systems for both inbound and outbound EDI transaction processing.  The CEM, in conjunction with the A/B MAC Commercial Off -the-Shelf (COTS) translator and any additional Front End Solution, is responsible for editing current ASC X12 standard transactions established under HIPAA via Technical Report Type 3 (TR3s).   The CEM provides submitters with quicker acknowledgments for the claim transaction(s) ASC X12 version(s) 005010 and beyond inclusive of any adopted errata under HIPAA.  This allows submitters to correct any errors and resubmit their transactions without having to wait for a batch cycle.   The CEM includes the following capabilities:   Code set editing   Medicare- specific editing    Duplicate submission checking   Claim Control Number assignment of Internal Control Number (ICN) or Document Control Number (DCN)    Creation of the ASC X12 277CA claim acknowledgment (flat file)    Creation of a CEM -edited transaction flat file    Receipt/Control/Balancing between the local data centers (LDCs) and EDCs for claims, claim status request and responses, and remittance advice    Reporting Capabilities based on the Control Record database   50.3.1 - Claim Numbering (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  The CEM will assign a claim control number to each accepted claim.  An accepted claim is a unit of work, 2300 loop followed by a 2400 loop, as described in the ASC X12 837 claim TR3 that has passed all translator syntax/semantic and CEM Medicare business edits and has been assigned a claim control number.  The assigned claim control number will be reported back to the submitter via the ASC X12 277CA claim acknowledgment.  This will provide the submit ter with the claim control number earlier in the adjudication process, thus enabling the submitter to perform more specific claim status inquiries on individual claims instead of entire submissions via standard HIPAA adopted transactions or via traditional  IVR/ARU (Interactive Voice Response/Automated Response Unit methods.  50.3.2 - Receipt Control and Balancing  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Upon receiving an ASC X12 276 claim status request or ASC X12 837 cl aim (institutional or professional)current standard transaction adopted under HIPAA, the A/B MAC will process the file through their Front End EDI solution, composed of at minimum a COTS translator.  The COTS translator creates the appropriate CMS defined flat file, based on transaction type.  The CMS defined flat file will include a skeleton Control Record, either a Detail Record (CTRD) or a Resubmission Record (CTRR), for each Interchange Control Header/Interchange Control Trailer (ISA/IEA) present, and t he A/B MAC then loads/places this file into the designated folder for the CEM to pick up and process.   The CTRD/CTRR record is placed in the designated transaction outbound folder for the A/B MAC LDC to move via Network Data Mover (NDM) to the EDC.  The ED C will run a receipt/control/balancing process upon receipt of a file to ensure that what was sent by the LDC is what the EDC received.  Once the EDCs have checked the files, the Received portion of the Control Records will be populated, and a copy of the Control Record shall be sent back to the LDC and logged in the Control Record database.  If the file balances, the Control Records will be stripped off and the file will be queued up to be pulled in to the next processing cycle.  If file does not balance , Received portion of the Control Records will be populated, and a copy of the Control Record shall be sent back to the LDC and logged in the Control Record database.  An alert will be sent to the LDC to indicate there is a problem with a file, and the b ad ISA/IEA will be stripped out of the file.  Once the LDC has identified and fixed the issues, they resubmit the bad ISA/IEA.   The Receipt/Control/Balancing process will also be in place for the outbound ASC X12 835 remittance advice and the ASC X12 277 c laim status response.  The shared system maintainers (SSMs) will create the appropriate CMS defined flat file, based on transaction type.  The CMS defined flat file will include the Control Records.  The transactions will be sent to the MAC/CEDI local data  center, where they will be passed through the receipt/control/balancing process to ensure if the CMS defined flat file is balanced.  During the outbound translation process the A/B MACs shall remove the control records prior to translating the CMS defined flat files to ASC X12 EDI format.   50.3.3 - Acknowledgements  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  The A/B MACs front end process uses the transaction appropriate CMS edits spreadsheet to determine whether an edit failure necessitates the rejection of the entire transaction set via the ASC X12 TA1 interchange acknowledgment or ASC X12 999 implementation acknowledgment edit, back to the submitter or whether those errors are accepted and passed onto the CEM for claim level rejection via the ASC X12 277CA claim acknowledgment.  Errors that the translator passes to the CEM are referred to as ASC X12 999 implementation acknowledgment Accepted, but Errors Noted (ASC X12 999E implementation acknowledgment) edits.   The CEM  will receive CMS defined 837 and 276 flat files from the A/B MACs translator.  The CEM will flag any 837 flat file data in error and will report that data back to the submitter via the ASC X12 277CA claim acknowledgment. Any 276 flat file data in error w ill be reported back to the submitter via an ASC X12 277 claim status request response transaction.  All accepted data will be sent to the SSM for processing.   1. If the translator sets an  edit that does not necessitate rejection of the entire ST -SE transacti on set (ASC X12 999E implementation acknowledgment edit), the contractor front end:   a. Creates an STC segment to document the error and inserts it into the ASC X12 837 claim CMS defined flat file following the segment containing the error.   b. Returns the ASC  X12 999 implementation acknowledgment to the submitter indicating the affected ST -SE transaction was accepted with errors noted.   c. Inserts a receipt date segment (+RC DTP segment) into the ASC X12 837 claim CMS defined flat file.   d. Creates a skeleton (350 c haracter space filled) Control Record (CTR segment) and, if desired, populates CTR17.  The CTR is placed in front of each ISA segment.   e. Submits the ASC X12 837 claim CMS defined flat file containing STC error segments to the CEM.   2. If the translator does not set any edits, the contractor front end:   a. Returns the ASC X12 999 implementation acknowledgment to the submitter indicating the affected ST -SE transaction was accepted.   b. Inserts a receipt date segment (+RC DTP segment) into the ASC X12 837 claim CMS defined flat file.   c. Creates a skeleton CTR segment and if desired, populates CTR17.  The CTR is placed in front of each ISA segment.  d. Submits the ASC X12 837 claim CMS defined flat file to the CEM.   50.3.3.1 - Outbound File Compliance Check  (Rev. 2803, Issued: 10 -28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  The ASC X12 999 implementation acknowledgment, the ASC X12 835 remittance advice, ASC X12 276/277 claim status response and the ASC X12 277CA claim acknowledgment outbound files shall be com pliance checked for the following:    Basic syntactical integrity and specific syntax requirements on all outbound files;   Balanced field totals, financial balancing of claims or remittance advices, and balancing of summary fields, if appropriate for all out bound file;    Specific inter -segment situations described in the HIPAA Implementation Guides for all outbound files; and   Valid TR3 specific code set values and other code sets adopted as HIPAA standards for all outbound files.  50.3.4 - Common Edits and Enhancement Module (CEM) Code Sets Requirements  (Rev.: 4388; Issued: 09- 06-19; Effective: 10- 07-19; Implementation: 10 -07-19)  The functionality of the CEM is dependent on the standard system maintainers (SSM) providing current code sets for inbound claims and claim status inquiries to be edited against.  This requires the CEM maintainer to update the following code sets on a quarterly release basis in order to align with industry:    Country Codes (ISO 3166- 1)  Country Subdivision Codes  (ISO 3166- 2)  State Codes (United States, Canada, Mexico)   Not Otherwise Classified (NOC) Procedure Codes (as defined by CMS)   National Uniform Billing Committee (NUBC) Condition Codes (that are valid for use on the 837 Professional claim per the National Uniform Claim Committee (NUCC))   Ambulance Modifiers   Health Insurance Prospective Payment System (HIPPS) (as updated and maintained by CMS)   A/B MACs are required to validate the incoming codes listed above against the most recent codes sets provided by the S SM. CMS will notify the shared system maintainers (via Recurring Update Notification) to load the most recent code sets into the CEM environment for download to the A/B MAC local data center (LDC) in conjunction with the quarterly release.   The CEM maintainer also updates the following code sets on a frequency basis other than quarterly in order to align with industry:    ZIP codes   Claim Adjustment Reason Codes (CARC)   Anesthesia Modifiers   Diagnosis Related Groups (DRG) codes   Healthcare Common Procedure  Coding System (HCPCS) codes   Health Insurance Premium Payment System (HIPPS) codes   International Classification of Diseases, (ICD) codes   National Drug Codes (NDC) (as published by the Federal Drug Administration(FDA))   National Provider Identifier (NPI)   Remittance Advice Remark Codes (RARC)   Taxonomy Codes   Procedure Code Modifier Codes   Admission Source Codes   Admission Type Codes   Patient Status Codes   Condition Codes   Occurrence Codes   Occurrence Span Codes   Value Codes   Revenue Codes   Uniform Bill Type codes   Provi der Control File (PCF) -  Part B only