clm104c31.pdf

Medicare Claims Processing Manual  Chapter 31 - ANSI X12 Formats Other than Claims or Remittance   Table of Contents  (Rev. 10236, 07- 31-20)  Transmittals for Chapter 31  10 - ASC X12 270/271 Health Care Eligibility Benefit Inquiry and Response Implementation  10.1 -  Background  10.2 -  Eligibility Connectivity Workflow  20 - ASC X12 276/277 Claims Status Request/Response Transaction Standard  20.1 -  Transmission Requirements  20.1.1 -  Batch Transactions  20.1.2 -  Online Direct Data Entry (DDE)  20.1.3 -  Interactive/Online (Non -DDE)  20.2 -  Summary of the ASC X12 276/277 Claim Status Request and Response Process for A/B Medicare Administrative Contractors, DME MACs, CEDI  20.3 -  Flat Files  20.4 -  Translation Requirements  20.5 -  Transmission Mode  20.6 -  Restriction and Controlling Access to Claims Status Information  20.7 -  Health Care Claim Status Category Codes and Health Care Claim Status Codes for Use with the Health Care Claim Status Request and Response ASC X12 276/277 Claim Status Request and Response   10 - ASC X12 270/271 Health Care Eligibility Benefit Inquiry and Response Implementation  (Rev. 2937, Issued; 04- 25-14, Effective: 04- 14-14, Implementation: 04- 14-14)  10.1 - Background  (Rev. 2937, Issued; 04- 25-14, Effective: 04- 14-14, Implementation: 04- 14-14)  This section provides information on Medicares implementation of the Accredited Standards Committee (ASC) X12 Health Care Eligibility Benefit Inquiry and Response (270/271) transaction (short reference: ASC X12 270/271 eligibility transaction).  The CMS supports the currently mandated version of the transaction based upon the currently mandated version of the ASC X12 Standards for Electronic Data Interchange Technical Report Type 3 --Health Care Eligibility Benefit Inquiry and Response (270/271), both of which were adopted as the National standard for the health care eligibility benefit inquiry and response under the Health Insurance Portability and Accountability Act of 1996 (HIPAA). The technical report 3 is also known as a TR3 or implementation guide (IG) . (Refer to chapter 24 for current versions adopted under HIPAA.)   10.2 -Eligibility Connectivity Workflow  (Rev. 10236, Issued: 07- 31-2020, Effective: 08- 31-2020, Implementation: 08- 31-2020)   In 2005, the Centers for Medicare & Medicaid Services (CMS) impl emented the HIPAA Eligibility Transaction System (HETS 270/271)  to address the standards for the Medicare beneficiary eligibility inquiries, creating a centralized ASC X12 270/271 health care eligibility inquiry  application that can process eligibility transactions in real -time.  For information regarding HETS connectivity, visit the HETS Help web site.   http://www.cms.gov/Research- Statistics -Data -and-Systems/CMS -Information-Technology/HETSHelp/index.html   20 - ASC X12 276/277 Claims Status Request/Response Transaction Standard  (Rev. 10236, Issued: 07- 31-2020, Effective: 08- 31-2020, Implementation: 08- 31-2020)   These instructions apply to Medicare Administrative Contractors (MACs), Durable Medical Equipment Medicare Administrative Contractors  (DME MACs), the Common Electronic Data Interchange (CEDI) contractor for DME MACs, and their shared systems on Medicare requirements for their implementation of the current HIPAA compliant version of the ASC X12 Health Care Claim Status Request and Response (276/277) transaction (short reference: ASC X12 276/277 claim status request and response.)   CMS supports the current version of this transaction as established in its TR3 adopted under HIPAA: the ASC X12 Standards for Electronic Data Interchange Techni cal Report Type 3 Health Care Claim Status Request and Response (276/277).   In order to implement the HIPAA administrative simplification provisions, the ASC X12 276/277 claim status request and response and its implementation specification (now TR3) have  been named under part 162 of title 45 of the Code of Federal Regulations as the electronic data interchange (EDI) standard for Health Care Claim Status Request/Response.  All other EDI formats for health care claims status request and response became obsolete October 16, 2003.  The Final Rule for Health Insurance Reform: Modifications to the Health Insurance Portability and Accountability Act (HIPAA) Electronic Transaction Standards published in the Federal Register on January 16th, 2009 ,  adopts updated versions of the electronic tra nsactions and TR3 for the ASC X12 276/277 claim status request and response.  Furthermore, the Final Rule conveys inclusion of errata to the transaction standard.  CMS therefore incorporates by reference any errata documents by the original mandated regulation compliance date through the Federal Register notice(s). Moving forward, all newly adopted errata documents are to be accepted and integrated as part of the EDI transaction.   The ASC X12 TR3 for the ASC X12 276/277 claim status request and response st andard may be found at the official ASC X12 website .  The ASC X12 276/277 is a paired transaction (the ASC X12 276 is an in- bound claim status request, and the 277 is an outbound claims status response).   20.1 - Transmission Requirements  (Rev. 2937, Issu ed; 04 -25-14, Effective: 04- 14-14, Implementation: 04- 14-14)  A/B MACs, DME MACs, and CEDI may continue to operate automated response unit (ARU) capability for providers to request and receive claim status information.  ARUs are not considered EDI and are not affected by the HIPAA requirements.  Nor do they impact response time requirements for the standard transactions implemented under HIPAA.   20.1.1 - Batch Transactions  (Rev. 2937, Issued; 04- 25-14, Effective: 04- 14-14, Implementation: 04- 14-14)  Contractors must be able to accept the current ASC X12 276 claim status request in batch mode, and respond via the ASC X12 277 claim status response in batch mode.  If a contractor currently supports batch capability in any EDI batch format to request clai m status, the response time for issuance of an ASC X12 277 claim status response transaction in response must be within one business day of the receipt of a valid ASC X12 276 claim status request transaction.   20.1.2 - Online Direct Data Entry (DDE) (Rev. 4260; Issued: 03- 22-19; Effective: 04- 22-19; Implementation: 04 -22-19)  The term Medicare beneficiary identifier (Mbi) is a general term describing a beneficiary's Medicare identification number. For purposes of this manual, Medicare beneficiary identifier  references both the Health Insurance Claim Number (HICN) and the Medicare Beneficiary Identifier (MBI) during the new Medicare card transition period and after for certain business areas that will continue to use the HICN as part of their processes.   The HIPAA uses the term direct data entry generically to refer to a type of functionality operated by many different payers under a variety of titles.  Within this instruction, the acronym DDE is being used to refer to any type of direct data entry system ma intained by contractors, or shared system maintainers, including A/B MAC (A) or (HHH) DDE or equivalent functionality that may have a different title.  Although DDE operates online, DDE does not typically operate on a detailed inquiry and response basis.  For claim status purposes, data is maintained within an interactive database that providers may access to view screens containing a wide variety of information on their claims.  A provider accesses that data by furnishing certain identifying data for secur ity purposes to establish their right to read the data and to specify those claim records the provider wishes to review.   The information in this database for specific claims or providers is initiated when a provider enters claim data, and is then updated by a contractor to include subsequent actions taken that affect that claim. DDE was specifically permitted to continue in the HIPAA initial transactions final rule (45 CFR 162.923), with the stipulation that direct data entry is subject to the applicable  data content and data condition requirements of the standard when conducting the transaction.  The health care provider is not required to use the format requirements of the standard."   Data content conformity means that the same information permitted or required by the ASC X12 277 claim status response implementation guide must be reported in the claims status screens (the DDE outbound).  The DDE outbound may not report a data element for claim status purposes that is not included in the ASC X12 277 claim  status response, exceeds the maximum length of the data element in the ASC X12 277 claim status response, does not meet the minimum length for the data element in the ASC X12 277 claim status response, or that does not meet the ASC X12 277 claim status re sponse requirement that the data element be numeric, alpha- numeric, an amount, or meet another characteristic as specified in the ASC X12 277 claim status response.  On the inbound, the DDE system can require less information than the ASC X12 276 claim sta tus request, but not more.  The inquirer is not required to furnish information in the DDE inquiry that is available by other means to the contractor.  Any data element keyed in a DDE system must conform to the requirements. The ASC X12 standard TR3 include data element length and characteristics in their definition of data attributes.   Conformity does not mean that a DDE screen that includes claim status information must display each of the data qualifiers or other means of data identification contained in the ASC X12 277 claim status response implementation guide.  DDE screens typically identify, explicitly or by context, the type of information being reported in a field, e.g., would identify if a number represents a HCPCS, Medicare beneficiary identifier,  amount, grams, date of birth, etc. DDE screens would not be expected to use a qualifier contained in the ASC X12 277 claim status response to identify data type if that is otherwise evident in the design or content of the DDE screen.  Shared system mainta iners must map the DDE claim status data elements to the ASC X12 276/277 claim status request and response implementation guide to determine if the DDE claim status data elements meet the conformity requirements above.  If needed, changes must be made to enable contractor DDE claim status data elements to conform.   If a contractor continues to support DDE, it must be offered in addition to batch ASC X12 276/277 claim status request and response, but the contractor must take one of two approaches to assure their claim status data content conforms to the requirements:  1. Eliminate claim status data elements from the DDE screens, unless those data elements are also needed for a purpose other than claim status.  For example, if a data element is needed in a DD E screen for claim entry or claim correction, and it is also used to help determine claim status, retain the data element so it can continue to be used for claim entry or correction.  If a data element is used solely for claim status, and is not essential for an alternate purpose, eliminate it; or   2. If a contractor elects to continue to display claim status -specific data elements in their DDE screens, those data elements must at a minimum contain/report data that conforms to:    All required and applicable  conditional data elements for those segments in the ASC X12 277 claim status response; and    Data content as specified for those data elements in the ASC X12 277 claim status response, as applicable, including compliance with the data attributes for those data elements as defined in the ASC X12 277 implementation guide.   Preliminary feedback from contractors suggests that existing DDE screens used for Medicare may already conform to the ASC X12 277 claim status response implementation guide requirements, b ut data element mapping is required to verify.  For example, since industry input was used to develop the ASC X12 277 claim status response implementation guide as well as, presumably the data elements for claim status currently furnished via DDE, it is unlikely that DDE screen field sizes would be larger than the ASC X12 277 claim status response maximum length or shorter than the ASC X12 277 claim status response minimum length.  It is also unlikely that a DDE screen would contain a data element considere d important for claim status that is not included in the ASC X12 277 claim status response, or vice versa.