New: Drop-in replacement for Change Healthcare APIs

EDI 276 X212 - Claim Status Request

Functional Group HR

X12N Insurance Subcommittee

This X12 Transaction Set contains the format and establishes the data contents of the Health Care Claim Status Request Transaction Set (276) for use within the context of an Electronic Data Interchange (EDI) environment. This transaction set can be used by a provider, recipient of health care products or services, or their authorized agent to request the status of a health care claim or encounter from a health care payer. This transaction set is not intended to replace the Health Care Claim Transaction Set (837), but rather to occur after the receipt of a claim or encounter information. The request may occur at the summary or service line detail level.

Heading

Position
Segment
Name
Max use
  1. To indicate the start of a transaction set and to assign a control number

  2. To define the business hierarchical structure of the transaction set and identify the business application purpose and reference data, i.e., number, date, and time

Detail

Position
Segment
Name
Max use
  1. 2000A Loop Mandatory
    Repeat >1
    1. To identify dependencies among and the content of hierarchically related groups of data segments

      This entity is the payer who has the current status information for the specified claims.
    2. 2100A Loop Mandatory
      Repeat 1
      1. To supply the full name of an individual or organizational entity

    3. 2000B Loop Mandatory
      Repeat >1
      1. To identify dependencies among and the content of hierarchically related groups of data segments

        This entity expects a response from the Information Source. See Section 1.4.1 Transaction Participants for more information on the Information Receiver.
      2. 2100B Loop Mandatory
        Repeat 1
        1. To supply the full name of an individual or organizational entity

      3. 2000C Loop Mandatory
        Repeat >1
        1. To identify dependencies among and the content of hierarchically related groups of data segments

          This entity delivered the health care service. See Section 1.4.1 Transaction Participants for more information on the Provider.
        2. 2100C Loop Mandatory
          Repeat 2
          1. To supply the full name of an individual or organizational entity

            Provider of Service is generic in that this could be the entity that originally submitted the claim (Billing Provider) or may be the entity that provided or participated in some aspect of the health care (Rendering Provider). The provider identified facilitates identification of the claim within a payer's system.
            During the transition to NPI, for those health care providers covered under the NPI mandate, two iterations of the 2100C Loop may be sent to accommodate reporting dual provider identification numbers (NPI and Legacy). When two iterations are reported, the NPI number will be in the iteration where the NM108 qualifier will be 'XX' and the legacy number will be in the iteration where the NM108 qualifier will be either 'SV' or 'FI'.
            After the transition to NPI, for those health care providers covered under the NPI mandate, only one iteration of the 2100C loop may be sent with the NPI reported in the NM109 and NM108=XX.
        3. 2000D Loop Mandatory
          Repeat >1
          1. To identify dependencies among and the content of hierarchically related groups of data segments

            When the patient is the subscriber or a dependent with a unique identification number, the claim status request information is reflected in the 2200D Loop under the Subscriber HL, 2000D Loop (HL03 = 22). The Dependent HL, 2000E Loop is not used. See Section 1.4.1.1 for more information on defining the patient.
            When requesting and responding to claim status for both a subscriber and a dependent of that subscriber, the Subscriber HL Loop 2000D must be followed by the subscriber's claim status data, Loop 2200D. In this instance, HL04=0 would be used. Then the Subscriber HL Loop 2000D must be repeated prior to the dependent HL Loop 2000E and their corresponding claim status data, Loop 2200E. In this instance, HL04=1 would be used. See Section 1.4.2.3 for an example of this structure.
          2. To supply demographic information

            Required when the patient is the subscriber or a dependent with a unique identification number. If not required by this implementation guide, do not send.
          3. 2100D Loop Mandatory
            Repeat 1
            1. To supply the full name of an individual or organizational entity

          4. 2200D Loop Optional
            Repeat >1
            1. To uniquely identify a transaction to an application

              This segment conveys a unique trace or reference number for each 2200D loop. This number will be returned in the 277 response.
              Required when the patient is the subscriber or a dependent with a unique identification number. If not required by this implementation guide, do not send.
              When the patient is not the subscriber or a dependent with a unique identification number, the Loop 2200E TRN and subsequent segments will be used to reflect the claim status information.
            2. To specify identifying information

              This is the payer's assigned control number, also known as, Internal Control Number (ICN), Document Control Number (DCN), or Claim Control Number (CCN).
              Required when the Information Receiver knows the payer assigned number and intends the search criteria be narrowed to a specific claim. If not required by this implementation guide, do not send.
            3. To specify identifying information

              Required when needed to refine the search criteria on Institutional claims. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
            4. To specify identifying information

              Required when the application or location system identifier is known. If not required by this implementation guide, do not send.
              This identifier will be provided to the Information Receiver by the Information Source through a companion document or other trading partner document. If a payer has multiple adjudication systems processing the same type of claim (e.g. professional or institutional), this identifier can be used to improve status routing and response time.
            5. To specify identifying information

              Required when the patient has a group number and the number is known by the Information Receiver. If not required by this implementation guide, do not send.
            6. To specify identifying information

              Required when the Patient Control Number has been assigned by the service provider. If not required by this implementation guide, do not send.
              The maximum number of characters supported for the Patient Control Number is `20'.
            7. To specify identifying information

              Required when the Pharmacy Prescription Number is needed to refine the search criteria for pharmacy claims. If not required by this implementation guide, do not send.
            8. To specify identifying information

              Required when a Clearinghouse or other transmission intermediary needs to attach their own unique claim number. If not required by this implementation guide, do not send.
            9. To indicate the total monetary amount

              Not all payer systems retain the original submitted charges. Charges are sometimes changed during processing.
              Required when needed to refine the search criteria for a specific claim. If not required by this implementation guide, do not send.
            10. To specify any or all of a date, a time, or a time period

              For professional claims, this date is derived from the service level dates.
              Required for institutional claims or for professional and dental claims when the service date (Loop 2210) is not used. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
            11. 2210D Loop Optional
              Repeat >1
              1. To supply payment and control information to a provider for a particular service

                For Institutional claims, when both an NUBC revenue code and a HCPCS or HIPPS code are reported, the HCPCS or HIPPS code is reported in SVC01-2 and the revenue code is reported in SVC04. When only a revenue code is used, it is reported in SVC01-2.
                Required when requesting status for Service Lines. If not required by this implementation guide, do not send.
              2. To specify identifying information

                Required when needed to refine the search criteria for a specific service line. If not required by this implementation guide, do not send.
              3. To specify any or all of a date, a time, or a time period

          5. 2000E Loop Optional
            Repeat >1
            1. To identify dependencies among and the content of hierarchically related groups of data segments

              Required when the patient is a dependent who does not have a unique identification number. If not required by this implementation guide, do not send.
              When the patient is the dependent, the claim status request information is reflected in the 2200E Loop under the Dependent HL, 2000E Loop (HL03 = 23). See Section 1.4.1.1 for more information on defining the patient.
            2. To supply demographic information

            3. 2100E Loop Mandatory
              Repeat 1
              1. To supply the full name of an individual or organizational entity

            4. 2200E Loop Mandatory
              Repeat >1
              1. To uniquely identify a transaction to an application

                This segment conveys a unique trace or reference for each 2200E Loop. This number will be returned in the 277 response.
              2. To specify identifying information

                This is the payer's assigned control number, also known as, Internal Control Number (ICN), Document Control Number (DCN), or Claim Control Number (CCN).
                Required when the Information Receiver knows the payer assigned number and intends the search criteria be narrowed to a specific claim. If not required by this implementation guide, do not send.
              3. To specify identifying information

                Required when needed to refine the search criteria on Institutional claims. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
              4. To specify identifying information

                Required when the application or location system identifier is known. If not required by this implementation guide, do not send.
                This identifier will be provided to the Information Receiver by the Information Source through a companion document or other trading partner document. If a payer has multiple adjudication systems processing the same type of claim (e.g. professional or institutional), this identifier can be used to improve status routing and response time.
              5. To specify identifying information

                Required when the patient has a group number and the number is known by the Information Receiver. If not required by this implementation guide, do not send.
              6. To specify identifying information

                Required when the Patient Control Number has been assigned by the service provider. If not required by this implementation guide, do not send.
                The maximum number of characters supported for the Patient Control Number is `20'.
              7. To specify identifying information

                Required when the Pharmacy Prescription Number is needed to refine the search criteria for pharmacy claims. If not required by this implementation guide, do not send.
              8. To specify identifying information

                Required when a Clearinghouse or other transmission intermediary needs to attach their own unique claim number. If not required by this implementation guide, do not send.
              9. To indicate the total monetary amount

                Required when needed to refine the search criteria for a specific claim. If not required by this implementation guide, do not send.
                Not all payer systems retain the original submitted charges. Charges are sometimes changed during processing.
              10. To specify any or all of a date, a time, or a time period

                For professional claims, this date is derived from the service level dates.
                Required for institutional claims or for professional and dental claims when the service date (Loop 2210) is not used. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
              11. 2210E Loop Optional
                Repeat >1
                1. To supply payment and control information to a provider for a particular service

                  For Institutional claims, when both an NUBC revenue code and a HCPCS or HIPPS code are reported, the HCPCS or HIPPS code is reported in SVC01-2 and the revenue code is reported in SVC04. When only a revenue code is used, it is reported in SVC01-2.
                  Required when requesting status for Service Lines. If not required by this implementation guide, do not send.
                2. To specify identifying information

                  Required when needed to refine the search criteria for a specific service line. If not required by this implementation guide, do not send.
                3. To specify any or all of a date, a time, or a time period

  2. To indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning (ST) and ending (SE) segments)

Stedi is a registered trademark of Stedi, Inc. Stedi's EDI Reference is provided for marketing purposes and is free of charge. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.