evekhm/cms_iom_500 huggingface dataset:
(Claims Processing)
Surgery21 100.24     Fraud and Abuse Section (Help Stop Fraud) 21 100.25     Time Limit for Filing 21 100.26 Vision21 100.27 Hospice21 100.28     Mandatory Assignment for Ph ysician Services Furnished for Medicaid Patients 21 100.29     Medicare Secondary Payer (MSP) 21 100.30     Reasonable Charge and Fee Schedule 21 100.31 Adjustments21 100.32 Overpayments / Offsets21 100.33 Ambulatory Surgical Care21 100.34   B-01-21  Patient Paid / Split Payment 21 100.35     Supplemental Coverage / Medigap 21 100.36 Limitation of Liability21 100.37 Deductible / Coinsurance21 100.38 General Information Section21 100.39     Home Health Messages (Section 41)  21 100.40     Add-On Messages - Section 39 21 100.41     Mandated Messages - Section 40 New Chap. New Sect. Int.  Pub. 13 Carrier Pub. 14 PMs Other Description 21       100.42 B-00-48,AB-01-30, AB-01-97, AB-01-149 Demonstration Project21 Add. A     Addendum A EOMB/MSN Crosswalk
clm104c22.pdf
Medicare Claims Processing Manual  Chapter 22 - Remittance Advice   Table of Contents  (Rev. 11427, 05- 20-22)  Transmittals for Chapter 22  10 - Background  20 - General  Remittance  Completion  Requirements  30 - Remittance Balancing  40 - Electronic Remittance Advice  - ERA or ASC  X12  835 40.1 -  ASC  X12  835 40.2 -  Generating  an ERA  if Required  Data is Missing  or Invalid  40.3 -  Electronic Remittance Advice  Data Sent  to Banks  40.4 -  Medicare Standard  Electronic PC -Print  Software  for Institutional  Providers  40.5 -  Medicare Remit  Easy  Print  Software for Professional  Providers  and Suppliers  40.6 -  ASC  X12  835 Implementation  Guide  (IG)  or Technical  Report  3 (TR3) 50 - Standard Paper  Remittance Advice 50.1 -  The Do  Not Forward  (DNF)  Initiative  60 - Remittance Advice  Codes  60.1 -  Group  Codes  60.2 -  Claim Adjustment  Reason  Codes  60.3 -  Remittance Advice  Remark Codes  60.4 -  Requests  for Additional C odes  80 - The Council for Affordable Quality Hea lthcare (CAQH) Committee on Operating Rules for Information Exchange (CORE) Mandated Operating Rule s 80.1 -  Health Care Claim Payment/Advice (835) Infrastructure Rule  80.1.1 -  Version X12/50 10X221 Companion Guide  80.2 -  Uniform Use of CARCs and RARCs Rule  80.3 -  EFT Enrollment Data Rule  80.4 -  ERA Enrollment Form    10 - Background  (Rev. 3288, Issued: 07 -02-15, Effective: 08- 03-15, Implementation: 08- 03-15)  The A/B Medicare Administrative Contractors (A/B MACs), and Durable Medical Equipment Medicare Administrative Contractors (DME MACs) send to providers, physicians, and suppliers, as a companion to claim payments, a notice of payment, referred to as the Remittance Advice (RA).  RAs explain the payment and any adjustment(s) made during claim adjudication.  For each claim or line item payment, and/or adjustment, there is an associated remittance advice item.  Adjustment is defined as:   denied   zero payment   partial payment   reduced payment   penalty applied   additional payment   supplemental payment
clm104c22.pdf
 denied   zero payment   partial payment   reduced payment   penalty applied   additional payment   supplemental payment   Payments and/or adjustments for multiple claims can be reported on one transmission of the remittance advice.  RA notices can be produced and transferred in either paper or electronic format.   The A/B MACs and DME MACs also send informational RAs to nonparticipating physicians, suppliers, and non- physician practitioners billing non- assigned claims (billing  and receiving payments from beneficiaries instead of accepting direct Medicare payments), unless the beneficiary or the provider requests that the remittance advice be suppressed.  An informational RA is identical to other RAs, but must carry a standard message to notify providers that they do not have appeal rights beyond those afforded when limitation on liability (rules regulating the amount of liability that an entity can accrue because of medical services which are not covered by Medicare (see Pub. 10 0-04, chapter 30) applies.   The MACs are allowed to charge up to a maximum of $25 for generating and mailing, if applicable, duplicate remittance advice (both electronic and paper) to recoup costs when generated at the request of a provider or any entity w orking on behalf of the provider.  Under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) administrative provisions, the Secretary of Health and Human Services has adopted ASC X12  Health Care Claim Payment/Advice (835) version 5010A 1 to be the standard effective from January 1, 2012.  The CMS has implemented the new HIPAA standard following the ASC X12 Technical Report 3 (TR3) for transaction 835 version 5010A1, and requires the use of this format exclusively for Electronic Remittanc e Advices (ERAs) on or after full implementation. CMS has also established a policy that the paper formats shall mirror the ERAs as much as possible, and all MACs shall use the paper formats  Standard Paper Remit or SPR -  established by CMS.
clm104c22.pdf
Provider Ide ntification:  Medicare requires claims to contain National Provider Identifiers (NPIs) to be accepted for adjudication.  NPIs received on the claims are cross walked to Medicare assigned legacy numbers for adjudication.  Adjudication is based on each unique combination of NPI/legacy number if there is no one -to-one relationship between the two.  Any ERA or SPR sent after version 5010A1 has been implemented will have one of the three provider identifications: (1)Federal Taxpayers Identification Number; (2) Centers for Medicare and Medicaid Services PlanID; or (3) Centers for Medicare & Medicaid Services National Provider Identifier (NPI) as the provider ID instead of any Medicare assigned provider number at the provider level.  NPIs will be sent as the provi der identification at the claim level.  As the Rendering Provider Identifier at the service line level, any one of the following identifiers:  (1) Centers for Medicare & Medicaid Services National Provider Identifier; (2) Social Security Number; (3) Federa l Tax Payers Identification Number; or (4) Medicare Provider Number;  will be sent.   20 - General Remittance Completion Requirements  (Rev. 2843, Issued: 12- 27-13, Effective: 01- 28-14, Implementation: 01- 28-14)  The following general field completion and calculation rules apply to both paper and electronic versions of the remittance advice, except as otherwise noted. See the current implementation guide for specific requirements:  Any adjustment applied to the submitted charge and/or units must be reported in the claim and/or service adjustment segments with the appropriate group, reason, and remark codes explaining the adjustments. Every provider level adjustment must likewise be reported in the provider level adjustment section of the remittance advice. I npatient RAs do not report service line adjustment data; only summary claim level adjustment information is reported.    The computed field Net reported in the Standard Paper Remittance (SPR) notice must include ProvPd (Calculated Payment to Provider, CLP04 in the ASC X12 835) and interest, late filing charges and previously paid amounts.
clm104c22.pdf
 MACs report only one crossover payer name on both the ERA and SPR, even if coordination of benefits (COB) information is sent to more than one payer. The current HIPA A compliant version of the ASC X12 835 does not have the capacity to report more than one crossover carrier, and the SPR mirrors the ASC X12 835.   The check amount is the sum of all claim -level payments, including claims and service- level adjustments, less  any provider level adjustments.    Positive adjustment amounts reduce the amount of the payment and negative adjustment amounts increase it.    The MAC does not issue an RA for a voided or cancelled claim. It issues an RA for the adjusted claim with Previous ly Paid (CLP04 in the ASC X12 835) showing the amount paid for the voided claim.   The shared system maintainers and contractors must make sure that the HIPAA transactions 835 and 837 COB balance after a system change resulting from a policy change that ma y or may not be directly related to Electronic Data Interchange (EDI).   30 - Remittance Balancing  (Rev. 3288, Issued: 07- 02-15, Effective: 08- 03-15, Implementation: 08- 03-15)
clm104c22.pdf
30 - Remittance Balancing  (Rev. 3288, Issued: 07- 02-15, Effective: 08- 03-15, Implementation: 08- 03-15)  For Medicare the principles of remittance balancing are the same for both paper and electronic remittance formats.  Balancing requires that the total paid amount is equal to the total submitted charges plus or minus payment adjustments for a single ASC X12 835 remittance in accordance with the rules of the standard ASC X12 835 format.  Refer to Front Matter Section 1.10.2.1 for Balancing in the ASC X12 835 version 5010 TR3.  Every HIPAA compliant ASC X12 835 transaction issued by a MAC must comply with the ASC X12 835 version 5010 TR3 requirements, i.e., these remittances must balance at the service, claim, and provider levels.  The flat files generated by the shared systems must be balanced at the line, claim, and provider level.  As a failsafe measure claim adjustment reason code121 and PLB reason code 90 may be used at the line, clai m, and provider level respectively to make sure that the ASC X12 835 is balanced.  Shared System generated reports must track the usage of these codes, and A/B MACs and DME MACs must work closely with the shared system maintainers and CMS to resolve the issues resulting in out of balance situations.   40 - Electronic Remittance Advice  - ERA or ASC X12 835 (Rev. 10236, Issued: 07 -31-2020, Effective: 08- 31-2020, Implementation: 08- 31-2020)
clm104c22.pdf
40 - Electronic Remittance Advice  - ERA or ASC X12 835 (Rev. 10236, Issued: 07 -31-2020, Effective: 08- 31-2020, Implementation: 08- 31-2020)   Electronic Remittance Advice (ERA) transactions must be produced in the current HIPAA compliant ASC X12 835 version /5010.  Directions for version updates are posted when necessary in CMS Change Request (CR) instructions issued by CMS.  Refer to the official Washington Publishing Company website for implementation guides, record formats, and data dictionaries for the ASC X12 835  Shared systems maintainers must provide appropriate provider file structures and switching mechanisms so that MACs can select and generate the ASC X12 835 and/or the automated clearing house (ACH) format when electronic funds transfer (EFT) applies. See the implementation guides for further information on the abbreviated ASC X12 835 and use of the ASC X12 835 for EFT.   Changes to content and format of ERAs may not be made by individual MACs.  Change s will be made only by shared system maintainers, and then, only as directed by CMS.  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 transmissi on 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 billi ng services or clearinghouse.  See Chapter 24 for technical information about transmission of the ASC X12 835.  The updated flat files are posted at:   https://w ww.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
clm104c22.pdf
 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 speci fications 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 te sting.  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 wa iver 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 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.
clm104c22.pdf
 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.
clm104c22.pdf
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:
clm104c22.pdf
 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;
clm104c22.pdf
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.