(Medicare Claims Processing Manual)

40.3 - Trading Partners  (Rev. 2803, Issued: 10- 28-13, Effective: 09-17-13, Implementation: 09-17-13)  Trading Partners must have signed Trading Partner Agreement s in place with their Medicare FFS Contractor prior to engaging in EDI.  50 - Technical Requirements  (Rev. 11427; Issued: 05-20- 22; Effective: 01 -01-23; Implementation: 01-03-23) NOTE:  CMS seeks to reduce burden and modernize processes to ensure a reduction in improper payments and an increase in customer satisfaction. The Certificate of Medical Necessity (CMN) form and DME Information Form (DIF) were originally required to help document the medical necessity and other coverage criteria for selected  Durable Medical Equipment, Prosthetics, Orthotics, and Supplies (DMEPOS) items. In the past, a supplier received a signed CMN from the treating physician or created and signed a DIF to submit with the claim. Due to improvements in claims processing and medical records management, the information found on CMNs or DIFs is available either on the claim or in the medical record and is redundant. Therefore, to reduce burden and increase customer satisfaction, providers and suppliers no longer need to submit the se forms for services rendered after January 1, 2023.  For claims with dates of service on or after January 1, 2023  providers and suppliers no longer need to submit CMNs or DIFs with claims. Due to electronic filing requirements, claims received with thes e forms attached will be rejected and returned to the provider or supplier.  F or claims with dates of service prior to January 1, 2023  processes will not change and if the CMN or DIF is required, it will still need to be submitted with the claim, or be on file with a previous claim.  This statement applies throughout the Program Integrity Manual wherever CMNs and DIFs are mentioned.     50.1 - Telecommunications, Internet and Dial-up  (Rev. 3346, Issued: 09- 04-15, Effective: 10- 06-15, Implementation: 10- 06-15)  A/B MACs, DME MACs and CEDI will support connectivity for EDI functions.  These functions include the exchange of EDI transactions at t he A/B MACs and CEDI Front End.  Online systems include the Medicare Part A Direct Data Entry (DDE) used for claim entry, claim correction, claim status checks, and beneficiary eligibility.  Medicare Part B offers the Provider Professional Telecommunications Network (PPTN) and DME MAC offers Claim Status Inquiry to check the status of claims.   50.1.1 - System Avai lability  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Access to A/B MACs, DME MACs and CEDI to exchange electronic transactions and/or lookup files (e.g., HCPCS codes, fee schedules) may be dependent upon hours the core processing system is available.  Where EDI functions are dependent upon the operation of the host processing system, the host systems hours of operation determine system availability.  A/B MACs, DME MACs and CEDI  shall inform users of system availability schedules including any planned downtime for system maintenance.     50.1.2 - Media (Rev. 10319, Issued: 08- 28-2020, Effective: 09- 29-2020 Implementation: 09- 29-2020)   An EDI transaction is defined by its initial manner of receipt.  Depending upon the capability of the A/B MAC, DME MAC and CEDI and the details negotiated with electronic claim submitters, an electronic claim could be submitted via central processing unit (CPU) to CPU transmission, dial up frame relay, direct wire (T -1 line or similar), o r personal computer modem upload or download (also see Section 50.1.3).   When counting electronic claims for workload reporting, the A/B MAC, DME MAC and CEDI  include data on all bills received for initial processing from providers directly or indirectly through another A/B MAC (A), etc.  They also include data on demand bills and no- pay bills submitted by providers with no charges and/or covered days/visits.  See  90 of this chapter for information about application of the claims payment floor when a claim is submitted electronically in a non -HIPAA -compliant format.   A/B MACs and DME MACs are not permitted to classify the following as electronic claims for Electronic Data Interchange (EDI) reporting, for payment floor or Administrative Simplification Compliance Act (ASCA, see section 90) mandatory electronic claim submission purposes:    Bills received from providers if they are incomplete, incorrect, or inconsistent, and consequently returned for clarification. Individual controls are not required for these bills;   Adjustment bills (A/B MAC (A) only);    Home Health Agency (HHA) bills where no utilization is chargeable and no payment has been made, but which have been requested only to facilitate record keeping processes (There is no CMS requirement for HHAs to submit no payment non-utilization chargeable bills.);   Bills paid by an HMO and processed by the contractor; and   A/B MACs, DME MACs and CEDI are not permitted to accept claims via fax -imaging, tape/diskette or similar storage media.  A/B MACs, DME MACs and CEDI are to assist billers using such media to transition to more efficient electronic media.   50.1.3 - Telecommunications and Transmission Protocols  (Rev. 3346, Issued: 09- 04-15, Effective: 10- 06-15, Implementation: 10- 06-15)  Providers must access A/ B MACs and DME MACs online applications, Medicare Part A Direct Data Entry (DDE), Medicare Part B Professional Provider Telecommunications Network (PPTN) and DME MAC Claim Status Inquiry (CSI) as directed  by the A/B MAC or DME MAC.  A/B MACs and DME MACs a re to permit access to DDE, PPTN and DMCS by using the most cost -effective transmission solution, among the CMS -sanctioned options, that meets the needs of their trading partners.   A/B MACs and CEDI may, but are not required to, support electronic transfer s for Medicare using 56 K connections for their asynchronous communications lines.  For asynchronous communications, A/B MACs and CEDI may, but are not required to, support provider access through Transmission Control Protocol/Internet Protocol (TCP/IP).  If A/B MACs and CEDI do support TCP/IP, it must be compliant with Internet Request for Comment (RFC) number 1122 and 1123, using Serial Line Internet Protocol (SLIP) or Point -to-Point Protocol (PPP). For any EDI transfers over TCP/IP connections, A/B MACs and CEDI must support using File Transfer Protocol (FTP) in a secure manner which is supported within the FTP protocol in a consistent manner and which takes advantage of existing security infrastructure and technology, compliant with RFC 2228.  FTP server s provide for user authentication through user ID/password mechanisms.  A/B MACs and CEDI must submit any other security mechanism in addition to this to CMS for approval prior to implementation.  A/B MACs and CEDI may but are not required to support file compression for ASC X12 or NCPDP (CEDI only) transactions.  Compression is permitted between the contractor and its data center.   A/B MACs and CEDI may not limit the number of ASC X12 837 claim transactions or the number of providers with transactions incl uded in a single transmission, but they may limit a single transmission to 5,000 claims if that is necessary for efficient operations.  For NCPDP, CEDI may not limit the number of transactions per batch except as noted within the batch standard.  However, they may limit a single physical file to having only one batch. Server capacity must be adequate to support simultaneous sustained file transfers from all configured communications lines.  A/B MACs and CEDI must accept and send all ASC X12 837 claim transa ctions as a continuous byte stream or as a variable length record.  A/B MACs and CEDI are not permitted to require that provider EDI transaction data be broken down into 80 byte segments and may not require any other deviation from the variable length form at or the continuous byte stream format.  For example, submitters may not be forced to create each segment as its own record by inserting carriage returns or line feeds.  Only standard ASC X12 envelopes may be used with ASC X12 transactions.  Only standard NCPDP envelopes may be used with NCPDP transactions (applies to CEDI only).   The ASC X12 and NCPDP transactions are variable -length records designed for wire transmission.  Medicare contractors must be able to accept them over a wire connection.  Each sen der and receiver must agree on the blocking factor and/or other pertinent telecommunication protocols.   Unless otherwise approved, A/B MACs, DME MACs and CEDI are only permitted to accept EDI transactions via the Internet when explicitly directed by CMS. T his ability includes compliance with the operating rules for Section 1104 of the Affordable Care Act.  50.1.4 - Toll-Free Service  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Toll free lines are not available for submission  or receipt of EDI transactions.  Providers and their agents are responsible for all costs they incur for communication and connectivity as described in Section 50.1.  50.2 - Translators (Rev. 10236, Issued: 07 -31-2020, Effective: 08- 31-2020, Implementation: 08 -31-2020)   A/B MACs and CEDI  must accept HIPAA compliant transactions into their front -end system and translate that data into the appropriate flat file format for the transaction type to enable processing by their shared system.  HIPAA c ompliant transactions may include Medicare data (data sent to the core shared system) and non -Medicare data (data not sent to the core shared system).  Translators are required to validate the syntax compliance of each inbound transaction against the trans action standards adopted under HIPAA and upon which the implementation guides (also adopted under HIPAA) are based.  Syntax edits must be limited to those syntax requirements specified in those implementation guides (IGs) adopted under HIPAA.   A/B MACs and  CEDI  must use the ASC X12  999 implementation acknowledgment to report  transaction level errors detected by translators and to acknowledge receipt of claims that did not contain syntax errors, unless the submitter has indicated a preference not to receiv e acknowledgments for claims without errors.  A/B MACs or CEDI  may purge ASC X12 999 implementation acknowledgment transactions from submitter mailboxes after five (5) business days in the event not downloaded by the submitting entity, but are encouraged to retain these as long as 30 days if system capacity permits.  Once purged, an A/B MACs or CEDI  is not required to be able to recreate that ASC X12 999 implementation acknowledgment transactions. A provider or clearinghouse that failed to download the ASC X 12 999 implementation acknowledgment in a timely manner may submit a claim status query to obtain comparable information for accepted claims.  If that response indicates no record of the claim(s), suggesting front end rejection due to a syntax error, the provider/clearinghouse can resubmit the claim and have a new ASC X12 999 implementation acknowledgment issued.  The ASC X12 999 implementation acknowledgment TR3 can be downloaded from the official Washington Publishing Company website. A/B MACs and CEDI ar e required to meet the ASC X12 999 implementation acknowledgment TR3 requirements when issuing the 999.   When receiving claims in the HIPAA adopted NCPDP formats, CEDI must produce a response file in the NCPDP format containing one Transaction Header and one Transaction Trailer with the appropriate syntax error noted in the message field.   A/B MACs and CEDI  must accept the entire extended character set.  Refer to the ASC X12 TR3 for specifics on the character set.  If A/B MACs and CEDI  cannot accept more than 9,999 loops or segments per loop in an ASC X12 transaction due to the limitations of their translator, they may reject the transaction at the translator level and use the ASC X12 999 implementation acknowledgment with the IK304 with a value of 4.  Translators are to edit the envelope segments (ISA, GS, ST, SE, GE, and IEA) that surround individual transactions so the translation process can immediately reject an interchange, functional group, or transaction set not having met the requirements contain ed in the specific structure, which could cause software failure when mapping to the flat file.  A/B MACs and CEDI  are not required to accept multiple functional groups (GS/GE) with multiple transaction types within one transmission for ASC X12 transaction s.  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;