evekhm/cms_iom_500 huggingface dataset:
clm104c31.pdf
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)
clm104c31.pdf
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.
clm104c31.pdf
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.
clm104c31.pdf
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.
clm104c31.pdf
 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.   If a shared system maintainer determines that DDE screen changes are required, the maintainer in conjunction with its users must determine if it wou ld be cost effective to modify the DDE screens to conform to the ASC X12 277 claim status response implementation guide.  If not cost effective, the maintainer must eliminate the claim status -only data elements from the DDE screens and require the contract ors to use the batch ASC X12 276/277 claim status request and response, an ARU, and/or other non-EDI means to obtain claim status information.   If retention is cost effective, the maintainer must modify these screens as necessary to ensure that providers a re able to access all applicable data content available in the ASC X12 277 claim status response.  The DDE screens must be able to furnish providers information that conforms to the data that would have been issued to the provider in an ASC X12 277 claim s tatus response.  See above for the discussion of conformity.   20.1.3 - Interactive/Online (Non -DDE)  (Rev. 2937, Issued; 04- 25-14, Effective: 04- 14-14, Implementation: 04- 14-14)
clm104c31.pdf
20.1.3 - Interactive/Online (Non -DDE)  (Rev. 2937, Issued; 04- 25-14, Effective: 04- 14-14, Implementation: 04- 14-14)  Contractors are not required to accept an ASC X12 276 claim status inquiry or respond with an ASC X12 277 claim status response in an interactive, online mode if they do not already do so. If contractors do support the ASC X12 276/277 claim status request and response in an interactive online mode, it must be offered in addition to batch ASC X12 276/277 claim status request and response.   20.2 - Summary of the ASC X12 276/277 Claim Status Request and Response Process for A/B Medicare Administrative Contractors, DME MACs, CEDI  (Rev. 2937, Issued; 04- 25-14, Effective: 04- 14-14, Implementation: 04 -14-14)  A. The contractors translator must perform editing on the submitted ASC X12 276 claim status request transaction at the ASC X12 standard and implementation levels, and generate an ASC X12 TA1 interchange acknowledgment in batch  if  an interchange control error was detected.  The contractor shall generate an appropriate ASC X12 999 implementation acknowledgment in batch if a syntax error is detected.  In the absence of any interchange control or syntax error, an ASC X12 999 implement ation acknowledgement is issued in the batch mode only, to confirm receipt of an ASC X12 276 received via batch.  See 20.4 for additional translation requirements.  Translation does not apply to DDE screens.   An ASC X12 TA1 interchange acknowledgment and an ASC X12 999 implementation acknowledgment (issued for an ASC X12 276 claim status request submitted in a batch) must be issued within 1 business day of receipt of the ASC X12 276 claim status request.   An ASC X12  TA1 interchange acknowledgment and ASC X12 999 implementation acknowledgment of an ASC X12 276 claim status request submitted in an interactive/online mode must be issued as quickly as the ASC X12 277 claim status response would have been issued had the ASC X12 276 claim status request been val id.
clm104c31.pdf
Under the current HIPAA adopted ASC X12 version, inclusive of any adopted Errata moving forward, the contractors translator shall edit the incoming ASC X12 276 claim status request  transaction as documented by the CMS 276/277 Edits spreadsheet (as u pdated per quarterly release) from the CMS Website: http://www.cms.gov/ElectronicBillingEDITrans/10_ClaimStatus.asp#TopOfPage   B. The shared system shall continue t o process claim status transactions in current ASC X12 version to include edits to verify that the submitted ASC X12 276 data complies with IG and Medicare requirements.  If edits are failed, the shared system must generate an edit report following the mod el established for TR3 and Medicare program edit reporting for the HIPAA compliant version of the ASC X12 837 claim implementation.  The edit report must include any reason(s) for the rejection in a concise but explicit manner that can be understood by provider staff as well as contractor staff.  Contractors will forward the edit messages to submitters for correction of the edit condition.  The shared system must generate these edit reports within 1 business day.   The TR3 edits must be performed as defined in the TR3 segment and data element notes, data element attributes, conditions of use, and overall guiding principles for use of the standards as contained in the introduction section and addenda to the IG.  The Medicare program edits must be performed as required by current Medicare program instructions.  C. The A/B MAC or, for DME, the CEDI contractor, shall process inbound claim status transactions in the current ASC X12 version(s) (inclusive of any ASC X12 Errata) and beyond to include the edits defined in the CMS 276/277 Edits spreadsheet as translator applicable in order to pass to the Part A or Part B Common Edits and Enhancement Module (CEM) software a CMS defined flat file format (inclusive of Control Record(s) hereafter referred to as CTRD).
clm104c31.pdf
For Part  A and Part B, the CEM software shall perform all edits not marked as Translator on the CMS 276/277 Edits spreadsheet for inbound claim status transactions in order to pass the fully edited inbound claim status transaction on to the appropriate Part A or P art B shared system for appropriate claim status request processing in the shared system.   For DME, the CEDI contractor shall also process inbound claim status transactions in the current ASC X12 version(s) (inclusive of any ASC X12 Errata) and beyond to a lso include edits defined in the CMS 276/277 Edits spreadsheet other than translator applicable in order to pass the fully edited inbound claim status transaction on to the DME shared system for appropriate claim status request processing in the shared sys tem.  D. For claim status request and response transactions formatted in the current ASC X12 version(s)  and beyond the shared system:    Updates the Control Record database with the CTRD record for the activities being processed (e.g. interchange  ISA segment  to IEA) and appropriate content of the Control Record.  Stores any ASC X12 276 claim status request data elements required for preparation of a compliant ASC X12 277 claim status response that are either not retained in the Medicare core system, or exceed  the size limits for that type of data in the Medicare core system in a temporary file.
clm104c31.pdf
Completes the application request/inquiry according to the components that outbound claim status response requires, as well as, generates and populates the outbound Control Record for the outbound claim status response.  These processes shall comply with the TR3 for the ASC X12 transaction and the CMS defined Control Record definition (inclusive of any quarterly release updates).  The shared system shall also perform data scrubbing of outbound data prior to the data exiting the Enterprise Data Center (EDC) and being transferred to the Local Data Center (LDC) as deemed appropriate by CMS and the MACs.  The initial instructions for the outbound data scrubbing were containe d in Transmittal 702, Change Request 6946.  This edit process shall be implemented beginning with the October 2010 release for DME and in the January 2011 release for Part A and Part B shared systems.  The processes shall be modified through subsequent releases, as directed via future Change Requests, add to the editing process of the reference file mechanism designed for each shared system to perform the data scrubbing conversion process.   20.3 - Flat Files (Rev. 2937, Issued; 04- 25-14, Effective: 04- 14-14, Implementation: 04 -14-14)  For the current ASC X12 276/277 claim status request and response and beyond inclusive of any adopted Errata by ASC X12, the CMS developed flat files that maintainers and contractors may use.  These files are available on the f ollowing CMS Web page: http://www.cms.gov/ElectronicBillingEDITrans/10_ClaimStatus.asp#TopOfPage   20.4 - Translation Requirements  (Rev. 2937, Issued; 04- 25-14, E ffective: 04 -14-14, Implementation: 04- 14-14)
clm104c31.pdf
20.4 - Translation Requirements  (Rev. 2937, Issued; 04- 25-14, E ffective: 04 -14-14, Implementation: 04- 14-14)  For the current ASC X12 276/277 claim status request and response transactions and beyond inclusive of any adopted Errata by ASC X12, contractors and shared system maintainers shall exchange ASC X12 claim status request and response transactions using the Extended Character Set. except when a CMS and the contractors have deemed to be data scrubbed under the initial instructions for the outbound data scrubbing as contained in Transmittal 702, Change Request 6946 and the modifications  through subsequent releases, as directed via future Change Request.  Detailed information about the Extended Character Set can be obtained in Appendix B of any ASC X12 TR3.  20.5 - Transmission Mode  (Rev. 2937, Issued; 04- 25-14, Effective: 04 -14-14, Implementation: 04- 14-14)  The HIPAA compliant version of the ASC X12 276/277 claim status request and response transaction is a variable- length record designed for wire transmission.  The CMS requires that the contractor accept the i nbound and transmit the outbound over a wire connection.  20.6 - Restriction and Controlling Access to Claims Status Information  (Rev. 1, 10- 01-03)  Provide claims status information to providers, suppliers and their agents when an EDI Enrollment Form is o n file for that entity, and to network service vendors if there is an EDI Enrollment Form and EDI Network Service Agreement on file.  (See Medicare Claims Processing Manual, Chapter 24, EDI Support Requirements for instructions on the enrollment form and t he EDI Network Service Agreement.)   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  (Rev. 10236, Issued: 07- 31-2020, Effective: 08- 31-2020, Implementation: 08- 31-2020)
clm104c31.pdf
Under HIPAA, all payers must use health care claim status category codes and health care claim status codes approved by the Health Care Code Maintenance Committee as applicable.  At each ASC X 12 trimester meeting (generally held the months of February, June and October), the Committee may update the claim status category codes and the claim status codes.  When instructed, Medicare contractors must update their claims systems to assure that the current version of these codes is used in their claim status responses.  The codes sets are available at the official Washington Publishing Company website .  Included in the code lists are specific details, including the date when a code was added, changed  or deleted.   CMS will issue recurring, one -time change requests regarding the need for and deadline for future updates to these codes.  Contractor and shared system changes will be made as necessary as part of a routine release to reflect applicable chang es such as retirement of previously used codes or newly created codes that may impact Medicare.  Shortly after the release of each code update, a provider education article will be available at http://www.cms.hhs.gov/medlearn/matters  for contractors to use to conduct provider outreach.   Transmittals Issued for this Chapter  Rev #  Issue Date  Subject  Impl Date  CR#  R10236CP
clm104c31.pdf
07/31/2020  Update to the IOM Publication (Pub) 100-04, Medicare Claims Processing Manual, Chapters 1, 6, 8, 17, 20, 22, 24, and 31 Referencing the Active Universal Resource Locators (URLs) for the Washington Publishing Company (WPC) and the ASC X12 Organizations, and Updates to the HIPAA Eligibility Transaction System (HETS)  08/31/2020  11857  R4388CP  09/06/2019  Manual Updates to Chapters 1, 22, 24, 26, and 31 in Publication (Pub.) 100 -04 10/07/2019  11331  R4260CP  03/22/2019  Update to Chapter 31 in Publication (Pub.) 100-04 to Provide Language -Only Change s for the New Medicare Card Project  04/22/2019  11178  R2937CP  04/25/2014  Medicare Claims Processing Pub. 100- 04 Chapter 31 Update  04/14/2014  8640 R2909CP  0314/2014 Medicare Claims Processing Pub. 100- 04 Chapter 31 Update  Rescinded and replaced by Transmittal 2937  04/14/2014  8640 R2165CP  02/25/2011  Update for Pub. 100- 04. Medicare Claims Processing Manual, Chapter 31 03/25/2011  7245 R1149CP  01/05/2007  Revision of Chapter 31 Eligibility Rules of Behavior  04/02/2007  5431 R991CP  06/23/2006  Eligibility Rules of Behavior  07/24/2006  5138 R892CP  03/24/2006  Eligibility Transaction URL Update  06/26/2006  4366 R793CP  12/29/2005  Revision to Chapter 31- Addition of Hospice Data HIPAA270/271 Eligibility  01/23/2006  4193 R791CP  12/23/2005  Revision to Chapter 31- Addition of Hospice Data HIPAA270/271 Eligibility  01/23/2006  4193 R583CP  06/15/2005  Access Process for HIPAA 270/271 (Extranet Only)  08/22/2005  3883 Rev #  Issue Date  Subject  Impl Date  CR#  R565CP  05/20/2005  Access Process for HIPAA 270/271 (Extranet Only)  08/22/2005  3883 R490CP  03/04/2005  Claims Status Code/Claim Status Category Code Update  07/05/2005  3715
clm104c31.pdf
Access Process for HIPAA 270/271 (Extranet Only)  08/22/2005  3883 R490CP  03/04/2005  Claims Status Code/Claim Status Category Code Update  07/05/2005  3715 R406CP  12/17/2004  Update to Health Care Claims Status Category Codes and Health Care Claim Status  Codes for Use with the Health Care Claim Status Request and Response ASC X12N 276/277. 04/04/2005  3566 R230CP  07/23/2004  Update to Health Care Claims Status Category Codes and Health Care Claim Status Codes for Use with the Health Care Claim Status Request and Response (ASC X12N 276/277)  01/03/2005  3361 R096CP  02/06/2004  Health Care Claims Status Category Codes and Health Care Claim Status Codes for Use with the Health Care Claim Status Request and Response (ASC X12N 276/277)  N/A 3017 R001CP  10/01/2003  Initial Publication of Manual  NA NA Back to top of chapter