(Medicare Claims Processing Manual)

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 re quirements 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 e ven 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 acknowledgme nt 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 th rough 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 f ile 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).   60.2 - Key Shop  and Optical Character Recognition  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  60.2.1 - Claim Key Shop and Optical Character Recognition (OCR)/Image Character Recognition (ICR) Mapping to ASC X12 Based Flat File  (Rev. 2803, Issued: 10 -28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  A/B MAC  and DME MAC key shop operations, that do not output directly in the ASC X12 837 claim or ASC X12- based flat file as output, must convert the initial  output from paper claims to the ASC X12 -based flat file format or the ASC X12 837 claim prior to transmission to their data center. When the ASC X12- based flat file is the output the REF01 segment/element (found prior to the ST segment) shall contain a value of +PR and REF02 shall contain a value of K (key shop) or O (OCR/ICR).   A/B MACs (B)  and DME MACs who support telephone claim submission shall convert the output to the ASC X12- based flat file.  The value in REF02 shall contain a T (teleclaim).   The DME MAC shared system s hall apply implementation guide edits only to those requirements that are applicable to both the HIPAA and the corresponding fields on the paper claim.  Implementation guide edits that are inappropriate for paper claims shall be by-passed.   60.2.2 - Key Shop and Image Processing  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Key shop, imaging, and contractor in- house data entry operations that do not output directly in the ASC X12 837 claim or ASC X12- based flat file format, must convert their initial output format into the ASC X12 -based flat file or the ASC X12 837 claim format prior to transmission to their data center. When the ASC X12- based flat file is the output, the REF01 segment/element (found prior to the ST segment) s hall contain a value of +PR and REF02 shall contain a value of K (external key shop or in- house data entry) or O (OCR/ICR).   Shared systems shall apply IG edits only to those requirements that are applicable to both the HIPAA and the corresponding fi elds on the paper claim. Implementation guide edits that are inappropriate for paper claims shall be by -passed.   An outbound ASC X12 837 claim COB transaction built from a paper claim will be produced as a skinny COB.  Gap filling must occur as needed to enable the file sent to the trading partner to meet minimum data set requirements for a compliant ASC X12 837 claim COB transaction.  Skinny COBs shall contain all required ASC X12 837 claim segments and include post -adjudicated data.   60.3 - COB Tradin g Partner and Contractor Crossover Claim Requirements  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Through the Coordination of Benefits Contractor (COBC), Medicare transmits outbound ASC X12 837 claim Coordination of Benefi t (COB) and Medigap claims to COB trading partners and Medigap plans, collectively termed trading partners, on a post -adjudicative basis.  This type of transaction, originating at individual Medicare contractors following their claims adjudication activities, includes incoming claim data, as modified during adjudication if applicable, as well as payment data.  All Medicare contractors are required to accept all ASC X12 837 claim segments and data elements permitted by the in - force applicable guides on an initial ASC X12 837 claim professional or institutional claim from a provider, but they are not required to use every segment or data element for Medicare adjudication.  Segments and data elements determined to be extraneous for Medicare claims adjudicati on shall, however, be retained by the Medicare contractor within its store -and-forward repository (SFR).  Incoming claims data shall be subjected to standard syntax and applicable TR3 edits prior to being deposited in the SFR to assure non- compliant data w ill not be forwarded on to another payer as part of the Medicare crossover process.  SFR data shall be re -associated with those data elements used in Medicare claim adjudication, as well as with payment data, to create an ASC X12 837 claim IG -compliant out bound COB/Medigap transaction.  The shared systems shall always retain the data in the SFR for a minimum of 6 months.  (See IOM Pub 100- 04, Chapter 28 Sections 70.6 and 70.6.5 for ASC X12 COB requirements and 70.6.6 for NCPDP D.0 COB requirements.)   60.4 - Remittance Advice and Standard Paper Remittances  (Rev. 10236, Issued: 07 -31-2020, Effective: 08- 31-2020, Implementation: 08- 31-2020)   Remittance advice records shall be provided to explain claim adjudication decisions, including for NCPDP format claims.   A/B MACs and CEDI  shall send the Electronic Remittance Advice (ERA) in the ASC X12 835 remittance advice format.  Or the A/B MACs and DME MACs shall send the remittance as a Standard Paper Remittance (SPR) Advice.  HIPAA version implementation guides are  available from the official Washington Publishing Company website.    See Chapter 22 of this manual for further remittance advice information.   60.5 - Payments (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  60.5.1 - Payment Floor Requirement  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  A/B MACs and DME MACs  must transmit the EFT authorization to the originating bank upon the expiration of the payment floor applicable to the claim.  They must designate a payment date (the date on which funds are deposited in the providers account) of two business days later than the date of transmission.  60.5.2 - Alternative to EFT  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  The only acceptable alternative to EFT is paper check mailed by first class mail.   60.5.3 - Electronic Funds Transfer (EFT)  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  EFT is the required method of Medicare payment for all providers entering the Medicare program for the first time and for existing providers that are submitting a change to their existing enrollment data but are not currently receiving payments via EFT.   Once a provider begins to receive Medicare payments via EFT, the A/B MAC or DME MAC  shall not issue any routine, ongoing payments to the provider via check. (For purposes of this instruction, the term routine, ongoing payments means those payments that are not considered to be special payments, as that latt er term is used in section 4 of the CMS -855 application.)  This means, therefore, that -  with the exception of special payments -  a provider that receives payments via EFT must continue to receive payments via EFT and cannot switch back to receiving paper checks, even in cases of a MAC transition or other CMS -initiated action. A/B MACs and DME MACs shall not approve any requests to change the providers payment method from EFT to check.   Note that the A/B MAC or DME MAC  shall abide by the instructions in Pu b. 100- 08, chapter 10, sections 4.4 and 8 on all provider enrollment issues relating to EFT.  This includes the requirement that A/B MACs and DME MACs  compare the information and signature on the providers Form -CMS -588 (Electronic Funds Transfer Authoriza tion Agreement), to that on the providers CMS -855 form on file.  For changes of information, DME MACs shall verify the authorized official on the CMS 855.  An A/B MAC or DME MAC  shall use a transmission format that is both economical and compatible with the servicing bank.  If the money is traveling separately from an ASC X12 835 remittance advice transaction, then A/B MACs and DME MACs  shall use National Automated Clearinghouse Association (NACHA) format CCP (Cash Concentration/Disbursement plus Addenda - CCD+) to make sure that the addenda record is sent with the EFT.  Providers need the addenda record to re -associate dollars with data. A/B MACs and DME MACs  shall transmit the EFT authorization to the originating bank upon the expiration of the payment floor applicable to the claim.  They shall designate a payment date (the date on which funds are deposited in the providers account) of two business days later  than the date of transmission.  For more information on EFT see IOM Pub 100- 08 Chapter 10.   60.5.4 - Tri-Partite Bank Agreement  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)