clm104c22.pdf

 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 SP R 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 d ate, 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 a re 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 applic able 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 systems flat file f or 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 submis sion 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.   40.2 - Generating an ERA if Required Data is Missing or Invalid  (Rev. 2843, Issued: 12- 27-13, Effective: 01- 28-14, Implementation: 01- 28-14)  The ASC X12 835 IG contains specific data requirements, which must be met to build a HIPAA compliant ERA. A claim could be received on paper that lacks data or has data that does not meet the data attributes or length requirements for preparation of a HIPAA -compliant ERA. If not rejected as a result of standard or IG level editing, a MAC must either send an SPR advice or a gap filled ERA to avoid noncompliance with HIPAA. For example, if a procedure code is sent with only four characters and the code set specified in the IG includes five character codes in the data element, and the code is not rejected by the front end edits, the claim would be denied due to the invalid procedure code. Preparation of an ERA with too few characters though would not  comply with the IG requirements. The noncompliant ERA could be rejected by the receiver.   The shared system maintainers, working in conjunction with their MACs, must decide whether to generate an SPR, which is not covered by HIPAA, or to gap fill in thi s situation, depending on system capability and cost. Except in some very rare situations, gap filling would be expected to be the preferred solution. Shared System Maintainers must follow CMS gap -filling instruction. The MAC must notify the trading partners, if and when their files are affected, as to when and why gap -filling characters will appear in an ASC X12 835.  40.3 - Electronic Remittance Advice Data Sent to Banks  (Rev. 2843, Issued: 12- 27-13, Effective: 01- 28-14, Implementation: 01- 28-14)  Under  the HIPAA Privacy requirements, U. S. health care payers are prohibited from sending table two ASC X12 835 data (portion of ASC X12 835 containing protected patient health care information) (or protected patient health care information in any other paper or electronic format) to a bank, unless:     That bank also functions as a health care data clearinghouse;    The provider has authorized the bank as a health care data clearinghouse to receive that data; and    The bank has signed an agreement to safeguard the privacy and security of the data.   The definition of a financial clearinghouse, as used by banks for transfer of funds, differs from the definition of health care data clearinghouse as used by HIPAA.  The HIPAA definition must be met if a bank is to be aut horized for receipt of table two or equivalent patient health care data.   Table two contains protected patient information that is not approved for release to a bank that is not an authorized health care data clearinghouse. A non- health data clearinghouse bank cannot receive ASC X12 835 data, except as provided in table one.   40.4 - Medicare Standard Electronic PC -Print Software for Institutional Providers (Rev. 3288, Issued: 07- 02-15, Effective: 08- 03-15, Implementation: 08- 03-15)  The PC Print software en ables institutional providers to print remittance data transmitted by Medicare.  A/B MACs (A) are required to make PC Print software available to providers for downloading at no charge.  A/B MACs (A) may charge up to $25 per mailing to recoup costs if the software is sent to providers on a CD/DVD or any other means at the providers request when the software is available for downloading.  This software must include self -explanatory loading and use information for providers.  It should not be necessary to furnish provider training for use of PC Print software.  A/B MACs (A) must supply providers with PC -Print software within 3 weeks of request.  The A/B MAC (A) Shared System (FISS) maintainer will supply PC Print software and a users guide for all A/B MACs (A).  The FISS maintainer must assure that the PC Print software is modified as needed to correspond to updates in the ERA and SPR formats per CMS instruction.   Providers are responsible for any telecommunication costs associated with receipt of the ASC X12  835, but the software itself can be downloaded at no cost.   The PC Print software enables providers to:    Allow the translation of the ASC X12 835 electronic remittance advice to user friendly report that can be reprinted;    View and print remittance infor mation on all claims included in the ASC X12 835;   View and print remittance information for a single claim;   View and print a summary of claims billed for each Type of Bill (TOB) processed on this ERA; and   View and print a summary of provider payments.  The receiving PC always writes an ASC X12 835 file in ASCII.  The providers may choose one or more print options, e.g., the entire transmission, a single claim, a summary by bill type, or a provider payment summary. If software malfunctions are detected, t hey are to be corrected through the FISS maintainer.  Individual A/B MACs (A) or data centers may not modify the PC Print software.   The software will also print the CAQH CORE defined business scenarios along with the texts for Claim Adjustment Reason and Remittance Advice Remark Codes reported on the 835 to explain any adjustment.   40.5 - Medicare Remit Easy Print Software for Professional Providers and Suppliers  (Rev. 3288, Issued: 07- 02-15, Effective: 08- 03-15, Implementation: 08- 03-15)  The CMS has deve loped software that gives professional providers/suppliers a tool to view and print an ERA in a human readable format.  This software is called Medicare Remit Easy Print (MREP).  It has been developed in response to comments that CMS has received from the provider/supplier community demonstrating a need for paper documents to reconcile accounts, and facilitate claim submission to secondary/tertiary payers.  This software became available on October 11, 2005 to the providers through their respective A/B MACs  and CEDI.  The software is scheduled to be updated three times a year to accommodate the Claim Adjustment Reason Code (CARC) and Remittance Advice Remark Code (RARC) tri -annual updates, and any applicable enhancements.  In addition to these three regular updates, there is also an annual enhancement update, if needed.   The MREP software enables providers to:    View and print remittance information on all claims included in the ASC X12 835;  View and print remittance information for a single claim;   View and print a summary page; and   View, print, and export special reports.   This software can be downloaded free of cost, but A/B MACs and CEDI may charge up to $25 per mailing to recoup costs if the software is sent to providers on a CD/DVD or any other means at  the providers request when the software is available for downloading.  MREP software has been updated to accommodate ASC X12 835 version 5010.  The software will also print the CAQH CORE defined business scenarios along with the texts for Claim Adjustment Reason and Remittance Advice Remark Codes reported on the 835 to explain any adjustment.   40.6  ASC X12 835 Implementation Guide (IG) or Technical Report 3 (TR3)  (Rev. 10236, Issued: 07 -31-2020, Effective: 08- 31-2020, Implementation: 08- 31-2020)   The Health Insurance Portability and Accountability Act (HIPAA) of 1996 requires that Medicare, and all other health insurance payers covered under HIPAA  comply with the electronic data interchange standards for health care as established by the Secretary of Health and Human Services. The 5010A1 version of the ASC X12 835 Technical Report 3 TR3 has been established as the standard for compliance for the 5010A1 version of the ASC X12 835remittance advice transaction... The formal name of this TR3 i s ASC X12 Standards for Electronic Data Interchange Technical Report Type 3 Health Care Claim Payment/Advice (835), and its current HIPAA compliant version is available electronically at  the official Washington Publishing Company website.  Although that TR 3 or implementation guide contains requirements for use of specific segments and data elements within the segments, it was written for use by all health plans and not specifically for Medicare. However, a Companion Document has been prepared by CMS to clar ify when conditional data elements and segments must be used for Medicare reporting when reviewing the Companion Document, keep in mind the following information about loop usage (e.g., required, not used, and situational definitions). For additional infor mation on this subject see the Implementation Guide:    Loop usage within ASC X12 transactions and their implementation guides can be confusing. Care must be used to read the loop requirements in terms of the context or location within the transaction.    The usage designator of a loops beginning segment indicates the usage of the loop. Segments within a loop cannot be sent without the beginning segment of that loop.   If the first segment is required, the loop must occur at least once unless it is nested in a loop that is not being used. A note on the required first segment of a nested loop will indicate dependency on the higher -level loop.   If the first segment is Situational, there will be a Segment Note addressing use of the loop. Any required segments in l oops beginning with a Situational segment occur only when the loop is used.  Similarly, nested loops occur only when the higher -level loop is used.   Companion Documents for both Part A and Part B are available at:   http://www.cms.gov/ElectronicBillingEDITrans/30_CompanionGuides.asp#TopOfPage   50 - Standard Paper Remittance Advice  (Rev. 3288, Issued: 07- 02-15, Effective: 08- 03-15, Implementation: 08- 03-15)