Medicare Claims Processing Manual (Pub. 100-04), Ch. 22 § 40.1

ASC X12 835

Length: 796 wordsOfficial source
40.1 - ASC X12 835 (Rev.: 4388; Issued: 09-06-19; Effective: 10-07-19; Implementation: 10-07-19) The ASC X12 835 is a variable-length record designed for wire transmission and is not suitable for use in application programs. Therefore, shared systems generate a flat file version of the ASC X12 835. MACs must translate that flat file into the variable length ASC X12 835 record for transmission to providers or their billing services or clearinghouse. See Chapter 24 for technical information about transmission of the ASC X12 835. The updated flat files are posted at: https://www.cms.gov/Medicare/Billing/ElectronicBillingEDITrans/Remittance.html Go to “Downloads”, and click on the file you want. The MAC requirements are: • Send the remittance data directly to providers or their designated billing services or clearinghouses; • Provide sufficient security to protect beneficiaries’ privacy. The MAC does not allow any party to view beneficiary information, unless authorized by specific instructions from CMS • Issue the remittance advice specifications and technical interface specifications to all requesting providers within three weeks of their request. Interface specifications must contain sufficient detail to enable a reasonably knowledgeable provider to interpret the RA, without the need to pay the MAC or an associated business under the same corporate umbrella for supplemental services or software; • A/B MACs (A) allow Part A providers to receive a Standard Paper Remittance Advice (SPR) in addition to the ASC X12 835 during the first 31 days of receiving ERAs and during other testing. After that time, A/B MACs (A) do not send a hard copy version of the ASC X12 835, in addition to the electronic transmission, in production mode. They should contact CMS if this requirement causes undue hardship for a particular provider, and a waiver is needed; • A/B MACs and DME MACs must suppress the distribution of SPRs to those Part B providers//suppliers (or a billing agent, clearinghouse, or other entity receiving ERAs on behalf of those providers/suppliers) after 45 days of receiving both SPR and ERA formats. In rare situations (e.g., natural or man-made disasters) exceptions to this policy may be allowed at the discretion of CMS. A/B MACs and DME MACs should contact CMS if a waiver is needed; • MACs may release an ERA prior to the payment date, but never later than the payment date; • Ensure that their provider file accommodates the data necessary to affect EFT, either through use of the ACH or the ASC X12 835 format; • Pay the costs of transmitting EFT through their bank to the ACH. Payees are responsible for the telecommunications costs of EFT from the ACH to their bank, as well as the costs of receiving ASC X12 835 data once in production mode; and • Provide for sufficient back-up to allow for retransmission of garbled or misdirected transmissions. Every ASC X12 835 transaction issued by A/B MACs and DME MACs must comply with the implementation guide (IG) requirements; i.e., each required segment, and each situational segment when the situation applies, must be reported. Required or applicable situational data element in a required or situational segment must be reported, and the data in a data element must meet the minimum length and data attribute (AN, ID, R, etc.) specifications in the implementation guide. Back end validation must be performed to ensure that these conditions are met. A/B MACs and DME MACs are not required to validate codes maintained by their shared systems, such as Healthcare Common Procedure Coding System (HCPCS), that are issued in their shared system’s flat file for use in the body of an ASC X12 835, but they are required to validate data in the ASC X12 835 envelope as well as the codes that they maintain, such as claim adjustment reason codes and remittance advice remark codes, that are reported in the ASC X12 835. MACs do not need to re-edit codes or other data validated during the claim adjudication process during this back end validation. Valid codes are to be used in the flat file, unless: • A service is being denied or rejected using an ASC X12 835 for submission of an invalid code, in which case the invalid code must be reported on the ASC X12 835; • A code was valid when received, but was discontinued by the time the ASC X12 835 is issued, in which case, the received code must be reported on the ASC X12 835; or • A code is received on a paper claim, and does not meet the required data attribute(s) for the HIPAA compliant ASC X12 835, in which case, “gap filling” would be needed if it were to be inserted in a compliant ASC X12 835. Additionally A/B MACs and Common Electronic Data Interchange (CEDI) for DME MACs must follow the CMS instructions for Receipt, Control and Balancing.
Medicare Claims Processing Manual (Pub. 100-04), Ch. 22 § 40.1: ASC X12 835 | Justis AI