EDI 271 X279A1 - Health Care Eligibility Benefit Response

Functional Group HB

X12N Insurance Subcommittee

This X12 Transaction Set contains the format and establishes the data contents of the Eligibility, Coverage or Benefit Information Transaction Set (271) for use within the context of an Electronic Data Interchange (EDI) environment. This transaction set can be used to communicate information about or changes to eligibility, coverage or benefits from information sources (such as - insurers, sponsors, payors) to information receivers (such as - physicians, hospitals, repair facilities, third party administrators, governmental agencies). This information includes but is not limited to: benefit status, explanation of benefits, coverages, dependent coverage level, effective dates, amounts for co-insurance, co-pays, deductibles, exclusions and limitations.

Heading

1. 0100 · ST · Transaction Set Header · Max 1 · Mandatory

   To indicate the start of a transaction set and to assign a control number

   Use this control segment to mark the start of a transaction set. One ST segment exists for every transaction set that occurs within a functional group.

2. 0200 · BHT · Beginning of Hierarchical Transaction · Max 1 · Mandatory

   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

   Use this required segment to start the transaction set and indicate the sequence of the hierarchical levels of information that will follow in Table 2.

Detail

1. 2000A Loop Mandatory Repeat >1

   1. 0100 · HL · Information Source Level · Max 1 · Mandatory

      To identify dependencies among and the content of hierarchically related groups of data segments

      Use this segment to identify the hierarchical or entity level of information being conveyed. The HL structure allows for the efficient nesting of related occurrences of information. The developers' intent is to clearly identify the relationship of the patient to the subscriber and the subscriber to the provider. Additionally, multiple subscribers and/or dependents (i.e., the patient) can be grouped together under the same provider or the information for multiple providers or information receivers can be grouped together for the same payer or information source. See Section 1.3.2 for limitations on the number of occurrences of patients.
      An example of the overall structure of the transaction set when used in batch mode is: Information Source Loop 2000A Information Receiver Loop 2000B Subscriber Loop 2000C Dependent Loop 2000D Eligibility or Benefit Information Subscriber Loop 2000C Eligibility or Benefit Information Dependent Loop 2000D Eligibility or Benefit Information

   2. 0250 · AAA · Request Validation · Max 9 · Optional

      To specify the validity of the request and indicate follow-up action authorized

      Use of this segment at this location in the HL is to identify reasons why a request cannot be processed based on the entities identified in ISA06, ISA08, GS02 or GS03.
      Required when the request could not be processed at a system or application level based on the entities identified in ISA06, ISA08, GS02 or GS03 and to indicate what action the originator of the request transaction should take. If not required by this implementation guide, do not send.

   3. 2100A Loop Mandatory Repeat 1

      1. 0300 · NM1 · Information Source Name · Max 1 · Mandatory

         To supply the full name of an individual or organizational entity

         Use this segment to identify an entity by name and identification number. This NM1 loop is used to identify the eligibility or benefit information source (e.g., insurance company, HMO, IPA, employer).

      2. 0800 · PER · Information Source Contact Information · Max 3 · Optional

         To identify a person or office to whom administrative communications should be directed

         If this segment is used, at a minimum either PER02 must be used or PER03 and PER04 must be used. It is recommended that at least PER02, PER03 and PER04 are sent if this segment is used.
         When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number should always include the area code and phone number using the format AAABBBCCCC. Where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number (e.g. (534)224-2525 would be represented as 5342242525). The extension, when applicable, should be included in the communication number immediately after the telephone number.
         Required when the Information Source desires to advise the Information Receiver on how to contact the Information Source about this eligibility response. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.

      3. 0850 · AAA · Request Validation · Max 9 · Optional

         To specify the validity of the request and indicate follow-up action authorized

         Required when the request could not be processed at a system or application level when specifically related to the information source data contained in the original 270 transaction's information source name loop (Loop 2100A) or to indicate that the information source itself is experiencing system problems and to indicate what action the originator of the request transaction should take. If not required by this implementation guide, do not send.
         Use this segment to indicate problems in processing the transaction;specifically related to the information source data contained in the;original 270 transaction's information source name loop (Loop 2100A);or to indicate that the information source itself is experiencing system problems.

   4. 2000B Loop Optional Repeat >1

      1. 0100 · HL · Information Receiver Level · Max 1 · Mandatory

         To identify dependencies among and the content of hierarchically related groups of data segments

         Use this segment to identify the hierarchical or entity level of information being conveyed. The HL structure allows for the efficient nesting of related occurrences of information. The developers' intent is to clearly identify the relationship of the patient to the subscriber and the subscriber to the provider. Additionally, multiple subscribers and/or dependents (i.e., the patient) can be grouped together under the same provider or the information for multiple providers or information receivers can be grouped together for the same payer or information source. See Section 1.3.2 for limitations on the number of occurrences of patients.
         An example of the overall structure of the transaction set when used in batch mode is: Information Source Loop 2000A Information Receiver Loop 2000B Subscriber Loop 2000C Dependent Loop 2000D Eligibility or Benefit Information Subscriber Loop 2000C Eligibility or Benefit Information Dependent Loop 2000D Eligibility or Benefit Information
         Required unless the 271 response contains an AAA segment in loop 2000A or 2100A. If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.

      2. 2100B Loop Mandatory Repeat 1

         1. 0300 · NM1 · Information Receiver Name · Max 1 · Mandatory

            To supply the full name of an individual or organizational entity

            Use this segment to identify an entity by name and/or identification number. This NM1 loop is used to identify the eligibility/benefit information receiver (e.g., provider, medical group, IPA, or hospital).

         2. 0400 · REF · Information Receiver Additional Identification · Max 9 · Optional

            To specify identifying information

            Use this segment when needed to convey other or additional identification numbers for the information receiver. The type of reference number is determined by the qualifier in REF01. Only one occurrence of each REF01 code value may be used in the 2100B loop.
            Required when this information was used from the 270 transaction to identify the Information Receiver. If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.

         3. 0600 · N3 · Information Receiver Address · Max 1 · Optional

            To specify the location of the named party

            Required when this information was used from the 270 transaction to identify the Information Receiver. If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.

         4. 0700 · N4 · Information Receiver City, State, ZIP Code · Max 1 · Optional

            To specify the geographic place of the named party

            Required when this information was used from the 270 transaction to identify the Information Receiver. If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.

         5. 0850 · AAA · Information Receiver Request Validation · Max 9 · Optional

            To specify the validity of the request and indicate follow-up action authorized

            Use this segment to indicate problems in processing the transaction specifically related to the information receiver data contained in the original 270 transaction's information receiver name loop (Loop 2100B).
            Required when the request could not be processed at a system or application level when specifically related to the information receiver data contained in the original 270 transaction's information receiver name loop (Loop 2100B) and to indicate what action the originator of the request transaction should take. If not required by this implementation guide, do not send.

         6. 0900 · PRV · Information Receiver Provider Information · Max 1 · Optional

            To specify the identifying characteristics of a provider

            This segment is used to convey additional information about a provider's role in the eligibility/benefit being inquired about and who is also the Information Receiver. For example, if the Information Receiver is also the Referring Provider, this PRV segment would be used to identify the provider's role. This PRV segment applies to all benefits returned for this Information Receiver unless overridden by a PRV segment in the 2100C, 2120C, 2100D or 2120D loops.
            Required when the 270 request contained a 2100B PRV segment and the information contained in the PRV segment was used to determine the 271 response. If not required by this implementation guide, do not send.

      3. 2000C Loop Optional Repeat >1

         1. 0100 · HL · Subscriber Level · Max 1 · Mandatory

            To identify dependencies among and the content of hierarchically related groups of data segments

            Use this segment to identify the hierarchical or entity level of information being conveyed. The HL structure allows for the efficient nesting of related occurrences of information. The developers' intent is to clearly identify the relationship of the patient to the subscriber and the subscriber to the provider. Additionally, multiple subscribers and/or dependents (i.e., the patient) can be grouped together under the same provider or the information for multiple providers or information receivers can be grouped together for the same payer or information source. See Section 1.3.2 for limitations on the number of occurrences of patients.
            Required unless the 271 response contains an AAA segment in loop 2000A, 2100A or 2100B. If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.
            An example of the overall structure of the transaction set when used in batch mode is: Information Source Loop 2000A Information Receiver Loop 2000B Subscriber Loop 2000C Dependent Loop 2000D Eligibility or Benefit Information Subscriber Loop 2000C Eligibility or Benefit Information Dependent Loop 2000D Eligibility or Benefit Information The above example shows 2 different Subscribers. The first Subscriber is not the patient, only the dependent is the patient. The second Subscriber is a patient and the Dependent is also a patient.

         2. 0200 · TRN · Subscriber Trace Number · Max 3 · Optional

            To uniquely identify a transaction to an application

            An information source may receive up to two TRN segments in each loop 2000C of a 270 transaction and must return each of them in loop 2000C of the 271 transaction unless the person submitted in loop 2000C is determined to be a dependent, then the TRN segments must be returned in loop 2000D. See Section 1.4.2. The returned TRN segments will have a value of "2" in TRN01. See Section 1.4.6 Information Linkage for additional information.
            Required when the 270 request contained one or two TRN segments and the subscriber is the patient (See Section 1.4.2.). One TRN segment for each TRN submitted in the 270 must be returned. OR Required when the Information Source needs to return a unique trace number for the current transaction. If not required by this implementation guide, do not send.
            If the subscriber is the patient, an information source may add one TRN;segment to loop 2000C with a value of "1" in TRN01 and must identify;themselves in TRN03.
            This segment must not be used if the subscriber is not the patient. See section 1.4.2. Basic Concepts.
            If this transaction passes through a clearinghouse, the clearinghouse will receive from the information source the information receiver's TRN segment and the clearinghouse's TRN segment with a value of "2" in TRN01. Since the ultimate destination of the transaction is the information receiver, if the clearinghouse intends on passing their TRN segment to the information receiver, the clearinghouse must change the value in TRN01 to "1" of their TRN segment. This must be done since the trace number in the clearinghouse's TRN segment is not actually a referenced transaction trace number to the information receiver.
            The trace number in the 271 transaction TRN02 must be returned exactly as submitted in the 270 transaction. For example, if the 270 transaction TRN02 was 012345678 it must be returned as 012345678 and not as 12345678.

         3. 2100C Loop Mandatory Repeat 1

            1. 0300 · NM1 · Subscriber Name · Max 1 · Mandatory

               To supply the full name of an individual or organizational entity

               Use this segment to identify an entity by name and/or identification number. This NM1 loop is used to identify the insured or subscriber.

            2. 0400 · REF · Subscriber Additional Identification · Max 9 · Optional

               To specify identifying information

               Required when the Information Source requires additional identifiers necessary to identify the Subscriber for subsequent EDI transactions (see Section 1.4.7); OR Required when the 270 request contained a REF segment with a Patient Account Number in Loop 2100C/REF02 with REF01 equal EJ; OR Required when the 270 request contained a REF segment and the information provided in that REF segment was used to locate the individual in the information source's system (See Section 1.4.7). If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.
               If the 270 request contained a REF segment with a Patient Account Number in REF02 with REF01 equal EJ, then it must be returned in the 271 transaction using this segment if the patient is the Subscriber. The Patient Account Number in the 271 transaction must be returned exactly as submitted in the 270 transaction.
               Use this segment to supply an identification number other than or in addition to the Member Identification Number. The type of reference number is determined by the qualifier in REF01. Only one occurrence of each REF01 code value may be used in the 2100C loop.
               Health Insurance Claim (HIC) Number or Medicaid Recipient Identification Numbers are to be provided in the NM1 segment as a Member Identification Number when it is the primary number an information source knows a member by (such as for Medicare or Medicaid). Do not use this segment for the Health Insurance Claim (HIC) Number or Medicaid Recipient Identification Number unless they are different from the Member Identification Number provided in the NM1 segment.

            3. 0600 · N3 · Subscriber Address · Max 1 · Optional

               To specify the location of the named party

               Required when the Subscriber is the patient or when the Information Source requires this information to identify the Subscriber for subsequent EDI transactions (see Section 1.4.7), OR Required if a rejection response is generated and this segment was present in the 270 and is the cause of the rejection. If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.;
               Do not return address information from the 270 request unless the transaction is rejected and the rejection was caused by the address and this segment was present in the 270. See Section 1.4.7.1 271 item 7 for additional information.
               Use this segment to identify address information for a subscriber.

            4. 0700 · N4 · Subscriber City, State, ZIP Code · Max 1 · Optional

               To specify the geographic place of the named party

               Required when the Subscriber is the patient or when the Information Source requires this information to identify the Subscriber for subsequent EDI transactions (see Section 1.4.7), OR Required if a rejection response is generated and this segment was present in the 270 and is the cause of the rejection. If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.;
               Do not return address information from the 270 request unless the transaction is rejected and the rejection was caused by the address and this segment was present in the 270. See Section 1.4.7.1 271 item 7 for additional information.
               Use this segment to identify address information for a subscriber.

            5. 0850 · AAA · Subscriber Request Validation · Max 9 · Optional

               To specify the validity of the request and indicate follow-up action authorized

               Required when the request could not be processed at a system or application level when specifically related to the data contained in the original 270 transaction's subscriber name loop (Loop 2100C) and to indicate what action the originator of the request transaction should take. If not required by this implementation guide, do not send.
               Use this segment to indicate problems in processing the transaction;specifically related to the data contained in the original 270;transaction's subscriber name loop (Loop 2100C).

            6. 0900 · PRV · Provider Information · Max 1 · Optional

               To specify the identifying characteristics of a provider

               Required when the 270 request contained a 2100C PRV segment and the information contained in the PRV segment was used to determine the 271 response.; OR Required when needed either to identify a provider's role or to associate a specialty type related to the service identified in the 2110C loops. This PRV segment applies to all benefits in this 2100C loop unless overridden by a PRV segment in the 2120C loop. If not required by this implementation guide, do not send.
               If identifying a specific provider, use this segment to convey specific information about a provider's role in the eligibility/benefit being inquired about or to convey the provider's Taxonomy Code when the provider is not the information receiver. For example, if the information receiver is a hospital and a referring provider must be identified, this is the segment where the referring provider would be identified.
               If identifying a type of specialty associated with the services identified in loop 2110C, use code PXC in PRV02 and the appropriate code in PRV03.
               If there is a PRV segment in 2100B, this PRV overrides it for this occurrence of the 2100C loop.

            7. 1000 · DMG · Subscriber Demographic Information · Max 1 · Optional

               To supply demographic information

               Use this segment to convey the birth date or gender demographic information for the subscriber.
               Required when the Subscriber is the patient or when the Information Source requires this information to identify the Subscriber for subsequent EDI transactions (see Section 1.4.7), but not required if a rejection response is generated with a 2100C or 2110C AAA segment and this segment was not sent in the request. If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.

            8. 1100 · INS · Subscriber Relationship · Max 1 · Optional

               To provide benefit information on insured entities

               Required when acknowledging a change in the identifying elements for the subscriber from those submitted in the 270 or the Birth Sequence Number submitted in INS17 of the 270 was used to locate the Subscriber. If not required by this implementation guide, do not send.

            9. 1150 · HI · Subscriber Health Care Diagnosis Code · Max 1 · Optional

               To supply information related to the delivery of health care

               Required when an HI segment was received in the 270 and if the information source uses the information in the determination of the eligibility or benefit response for the subscriber. All information used from the HI segment of the 270 used in the determination of the eligibility or benefit response for the subscriber must be returned. If information was provided in an HI segment of 270 but was not used in the determination of the eligibility or benefits for the subscriber it must not be returned. The information source must not use information in an HI segment of the 270 transaction in the determination of eligibility or benefits for the subscriber if that information cannot be returned in the 271 response. OR Required when needed to identify limitations in the benefits identified in the 2110C loops, such as if benefits are limited for a specific diagnosis code if the information source can support this high level functionality. If the information source cannot support this high level functionality, do not send.
               Use the Diagnosis code pointers in 2110C EB14 to identify which diagnosis code or codes in this HI segment relates to the information provided in the EB segment.
               Do not transmit the decimal points in the diagnosis codes. The decimal point is assumed.

            10. 1200 · DTP · Subscriber Date · Max 9 · Optional

                To specify any or all of a date, a time, or a time period

                The dates represented may be in the past, the current date, or a future date. The dates may also be a single date or a span of dates. Which date(s) to use is determined by the format qualifier in DTP02.
                Dates supplied in the 2100C DTP apply to the Subscriber and all 2110C loops unless overridden by an occurrence of a 2110C DTP with the same value in DTP01.
                Required to identify the Plan (DTP01 = 291) or Plan Begin (DTP01 = 346) date when the individual has active coverage unless multiple plans apply to the individual or multiple plan periods apply, which must then be returned in the 2110C DTP (See Section 1.4.7); OR Required when needed to identify other relevant dates that apply to the Subscriber. If not required by this implementation guide, do not send.

            11. 1275 · MPI · Subscriber Military Personnel Information · Max 1 · Optional

                To report military service data

                Required when this transaction is processed by DOD or CHAMPUS/TRICARE and when necessary to convey the Subscriber's military service data If not required by this implementation guide, do not send.

            12. 2110C Loop Optional Repeat >1

                1. 1300 · EB · Subscriber Eligibility or Benefit Information · Max 1 · Mandatory

                   To supply eligibility or benefit information

                   Required when the subscriber is the person whose eligibility or benefits are being described and the transaction is not rejected (see Section 1.4.10) or if the transaction needs to be rejected in this loop. If not required by this implementation guide, do not send.
                   See Section 1.4.7 Implementation-Compliant Use of the 270/271 Transaction Set for information about what information must be returned if the subscriber is the person whose eligibility or benefits are being sent.
                   Either EB03 or EB13 may be used in the same EB segment, not both.
                   EB03 is a repeating data element that may be repeated up to 99 times. If all of the information that will be used in the 2110C loop is the same with the exception of the Service Type Code used in EB03, it is more efficient to use the repetition function of EB03 to send each of the Service Type Codes needed. If an Information Source supports responses with multiple Service Type Codes, the repetition use of EB03 must be supported if all other elements in the 2110C loop are identical.
                   A limit to the number of repeats of EB loops has not been established. In a batch environment there is no practical reason to limit the number of EB loop repeats. In a real time environment, consideration should be given to how many EB loops are generated given the amount of time it takes to format the response and the amount of time it will take to transmit that response. Since these limitations will vary by information source, it would be completely arbitrary for the developers to set a limit. It is not the intent of the developers to limit the amount of information that is returned in a response, rather to alert information sources to consider the potential delays if the response contains too much information to be formatted and transmitted in real time.
                   Use this segment to begin the eligibility/benefit information looping structure. The EB segment is used to convey the specific eligibility or benefit information for the entity identified.

                2. 1350 · HSD · Health Care Services Delivery · Max 9 · Optional

                   To specify the delivery pattern of health care services

                   Required when needed to identify a specific delivery or usage pattern associated with the benefits identified in either EB03 or EB13. If not required by this implementation guide, do not send.

                3. 1400 · REF · Subscriber Additional Identification · Max 9 · Optional

                   To specify identifying information

                   Use this segment for reference identifiers related only to the 2110C loop that it is contained in (e.g. Other or Additional Payer's identifiers).
                   Required when the Information Source requires one or more of these additional identifiers for subsequent EDI transactions (see Section 1.4.7); OR Required when an additional identifier is associated with the eligibility or benefits being identified in the 2110C loop. If not required by this implementation guide, do not send.
                   Use this segment to identify other or additional reference numbers for the entity identified. The type of reference number is determined by the qualifier in REF01. Only one occurrence of each REF01 code value may be used in the 2110C loop.

                4. 1500 · DTP · Subscriber Eligibility/Benefit Date · Max 20 · Optional

                   To specify any or all of a date, a time, or a time period

                   Required when the individual has active coverage with multiple plans or multiple plan periods apply (See 2100C DTP segment); OR Required when needed to convey dates associated with the eligibility or benefits being identified in the 2110C loop. If not required by this implementation guide, do not send.
                   When using the DTP segment in the 2110C loop this date applies only to the 2110C Eligibility or Benefit Information (EB) loop in which it is located. If a DTP segment with the same DTP01 value is present in the 2100C loop, the date is overridden for only this 2110C Eligibility or Benefit Information (EB) loop.

                5. 1600 · AAA · Subscriber Request Validation · Max 9 · Optional

                   To specify the validity of the request and indicate follow-up action authorized

                   Required when the request could not be processed at a system or application level when specifically related to specific eligibility/benefit inquiry data contained in the original 270 transaction's subscriber eligibility/benefit inquiry information loop (Loop 2110C) and to indicate what action the originator of the request transaction should take. If not required by this implementation guide, do not send.
                   Use this segment to indicate problems in processing the transaction;specifically related to specific eligibility/benefit inquiry data contained in the original 270 transaction's subscriber eligibility/benefit inquiry information loop (Loop 2110C).

                6. 2500 · MSG · Message Text · Max 10 · Optional

                   To provide a free-form format that allows the transmission of text information

                   Free form text or description fields are not recommended because they require human interpretation.
                   Under no circumstances can an information source use the MSG segment to relay information that can be sent using codified information in existing data elements (including combinations of multiple data elements and segments). Information that has been provided in codified form in other segments or elements elsewhere in the 271 for the individual must not be repeated in the MSG segment. If the information cannot be codified, then cautionary use of the MSG segment is allowed as a short term solution. It is highly recommended that the entity needing to use the MSG segment approach X12N with data maintenance to solve the long term business need, so the use of the MSG segment can be avoided for that issue.
                   Required when the eligibility or benefit information cannot be codified in existing data elements (including combinations of multiple data elements and segments); AND Required when this information is pertinent to the eligibility or benefit response. If not required by this implementation guide, do not send.
                   Benefit Disclaimers are strongly discouraged. See section 1.4.11 Disclaimers Within the Transaction. Under no circumstances are more than one MSG segment to be used for a Benefit Disclaimer per individual response.

                7. 2115C Loop Optional Repeat 10

                   1. 2600 · III · Subscriber Eligibility or Benefit Additional Information · Max 1 · Mandatory

                      To report information

                      Required when III segments in Loop 2110C of the 270 Inquiry were used in the determination of the eligibility or benefit response; OR Required when needed to identify limitations in the benefits explained in the corresponding Loop 2110C (such as if benefits are limited to a type of facility). If not required by this implementation guide, do not send.
                      This segment has two purposes. Information that was received in III segments in Loop 2110C of the 270 Inquiry and was used in the determination of the eligibility or benefit response must be returned. If information was provided in III segments of Loop 2110C but was not used in the determination of the eligibility or benefits it must not be returned. This segment can also be used to identify limitations in the benefits explained in the corresponding Loop 2110C, such as if benefits are limited to a type of facility.
                      Use this segment to identify Nature of Injury Codes and/or Facility Type as they relate to the information provided in the EB segment.
                      Use the III segment only if an information source can support this high level functionality.
                      Use this segment only one time for the Facility Type Code.

                8. 3300 · LS · Loop Header · Max 1 · Optional

                   To indicate that the next segment begins a loop

                   Use this segment to identify the beginning of the Subscriber Benefit Related Entity Name loop. Because both the subscriber's name loop and this loop begin with NM1 segments, the LS and LE segments are used to differentiate these two loops.
                   Required when Loop 2120C is used. If not required by this implementation guide, do not send.

                9. 2120C Loop Optional Repeat 23

                   1. 3400 · NM1 · Subscriber Benefit Related Entity Name · Max 1 · Mandatory

                      To supply the full name of an individual or organizational entity

                      Required when provider was identified in 2100C PRV02 and PRV03 by Identification Number (not Taxonomy Code) in the 270 Inquiry and was used in the determination of the eligibility or benefit response; OR Required when needed to identify an entity associated with the eligibility or benefits being identified in the 2110C loop such as a provider (e.g. primary care provider), an individual, an organization, another payer, or another information source; If not required by this implementation guide, do not send.

                   2. 3600 · N3 · Subscriber Benefit Related Entity Address · Max 1 · Optional

                      To specify the location of the named party

                      Use this segment to identify address information for an entity.
                      Required when needed to further identify the entity or individual in loop 2120C NM1 and the information is available. If not required by this implementation guide, do not send.

                   3. 3700 · N4 · Subscriber Benefit Related Entity City, State, ZIP Code · Max 1 · Optional

                      To specify the geographic place of the named party

                      Required when needed to further identify the entity or individual in loop 2120C NM1 and the information is available. If not required by this implementation guide, do not send.
                      Use this segment to identify address information for an entity.

                   4. 3800 · PER · Subscriber Benefit Related Entity Contact Information · Max 3 · Optional

                      To identify a person or office to whom administrative communications should be directed

                      Use this segment when needed to identify a contact name and/or communications number for the entity identified. This segment allows for three contact numbers to be listed. This segment is used when the information source wishes to provide a contact for the entity identified in loop 2120C NM1. If telephone extension is sent, it should always be in the occurrence of the communications number following the actual phone number. See the example for an illustration.
                      If this segment is used, at a minimum either PER02 must be used or PER03 and PER04 must be used. It is recommended that at least PER02, PER03 and PER04 are sent if this segment is used.
                      When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number should always include the area code and phone number using the format AAABBBCCCC. Where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number (e.g. (534)224-2525 would be represented as 5342242525). The extension, when applicable, should be included in the communication number immediately after the telephone number.
                      Required when Contact Information exists and is available. If not required by this implementation guide, do not send.

                   5. 3900 · PRV · Subscriber Benefit Related Provider Information · Max 1 · Optional

                      To specify the identifying characteristics of a provider

                      Required when needed either to identify a provider's role or associate a specialty type related to the service identified in the 2110C loop. If not required by this implementation guide, do not send.
                      If identifying a type of specialty associated with the services identified in loop 2110C, use code PXC in PRV02 and the appropriate code in PRV03.
                      If there is a PRV segment in 2100B or 2100C, this PRV overrides it for this occurrence of the 2110C loop.

                10. 4000 · LE · Loop Trailer · Max 1 · Optional

                    To indicate that the loop immediately preceding this segment is complete

                    Use this segment to identify the end of the Subscriber Benefit Related Entity Name loop. Because both the subscriber's name loop and this loop begin with NM1 segments, the LS and LE segments are used to differentiate these two loops.
                    Required when Loop 2120C is used. If not required by this implementation guide, do not send.

         4. 2000D Loop Optional Repeat >1

            1. 0100 · HL · Dependent Level · Max 1 · Mandatory

               To identify dependencies among and the content of hierarchically related groups of data segments

               See Section 1.4.2 Basic Concepts for more information about dependents and patients.
               Required if the patient is a dependent who does not have a unique Member Identification Number (See Section 1.4.2) unless the 271 response contains an AAA segment in loop 2000A, 2100A, 2100B, 2100C or 2110C. If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.
               Use this segment to identify the hierarchical or entity level of information being conveyed. The HL structure allows for the efficient nesting of related occurrences of information. The developers' intent is to clearly identify the relationship of the patient to the subscriber and the subscriber to the provider. Additionally, multiple subscribers and/or dependents (i.e., the patient) can be grouped together under the same provider or the information for multiple providers or information receivers can be grouped together for the same payer or information source. See Section 1.3.2 for limitations on the number of occurrences of patients.
               An example of the overall structure of the transaction set when used in batch mode is: Information Source Loop 2000A Information Receiver Loop 2000B Subscriber Loop 2000C Dependent Loop 2000D Eligibility or Benefit Information Subscriber Loop 2000C Eligibility or Benefit Information Dependent Loop 2000D Eligibility or Benefit Information The above example shows 2 different Subscribers. The first Subscriber is not the patient, only the dependent is the patient. The second Subscriber is a patient and the Dependent is also a patient.

            2. 0200 · TRN · Dependent Trace Number · Max 3 · Optional

               To uniquely identify a transaction to an application

               An information source may receive up to two TRN segments in each loop;2000D of a 270 transaction and must return each of them in loop 2000D;of the 271 transaction unless the person submitted in loop 2000D is determined to be a subscriber, then the TRN segments must be returned in loop 2000C (See Section 1.4.2). The returned TRN segments will have a value of "2" in TRN01. See Section 1.4.6 Information Linkage for additional information.
               An information source may add one TRN segment to loop 2000D with a;value of "1" in TRN01 and must identify themselves in TRN03.
               Required when the 270 request contained one or two TRN segments and the dependent is the patient (See Section 1.4.2.). One TRN segment for each TRN submitted in the 270 must be returned.; OR Required when the Information Source needs to return a unique trace number for the current transaction. If not required by this implementation guide, do not send.
               If this transaction passes through a clearinghouse, the clearinghouse will receive from the information source the information receiver's TRN segment and the clearinghouse's TRN segment with a value of "2" in TRN01. Since the ultimate destination of the transaction is the information receiver, if the clearinghouse intends on passing their TRN segment to the information receiver, the clearinghouse must change the value in TRN01 to "1" of their TRN segment. This must be done since the trace number in the clearinghouse's TRN segment is not actually a referenced transaction trace number to the information receiver.
               The trace number in the 271 transaction TRN02 must be returned exactly as submitted in the 270 transaction. For example, if the 270 transaction TRN02 was 012345678 it must be returned as 012345678 and not as 12345678.

            3. 2100D Loop Mandatory Repeat 1

               1. 0300 · NM1 · Dependent Name · Max 1 · Mandatory

                  To supply the full name of an individual or organizational entity

                  Use this segment to identify an entity by name. This NM1 loop is used to identify the dependent of an insured or subscriber.

               2. 0400 · REF · Dependent Additional Identification · Max 9 · Optional

                  To specify identifying information

                  If the 270 request contained a REF segment with a Patient Account Number in Loop 2100D/REF02 with REF01 equal EJ, then it must be returned in the 271 transaction using this segment if the patient is the Dependent. The Patient Account Number in the 271 transaction must be returned exactly as submitted in the 270 transaction.
                  Required when the Information Source requires additional identifiers necessary to identify the Dependent for subsequent EDI transactions (see Section 1.4.7); OR Required when the 270 request contained a REF segment with a Patient Account Number in Loop 2100D/REF02 with REF01 equal EJ; OR Required when the 270 request contained a REF segment and the information provided in that REF segment was used to locate the individual in the information source's system (See Section 1.4.7). If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.
                  Use this segment to supply an identification number other than or in addition to the Member Identification Number. The type of reference number is determined by the qualifier in REF01. Only one occurrence of each REF01 code value may be used in the 2100D loop.
                  Health Insurance Claim (HIC) Number or Medicaid Recipient Identification Numbers are to be provided in the NM1 segment as a Member Identification Number when it is the primary number an information source knows a member by (such as for Medicare or Medicaid). Do not use this segment for the Health Insurance Claim (HIC) Number or Medicaid Recipient Identification Number unless they are different from the Member Identification Number provided in the NM1 segment.

               3. 0600 · N3 · Dependent Address · Max 1 · Optional

                  To specify the location of the named party

                  Required when the Information Source requires this information to identify the Dependent for subsequent EDI transactions (see Section 1.4.7), OR Required if a rejection response is generated and this segment was present in the 270 and is the cause of the rejection. If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.
                  Do not return address information from the 270 request unless the transaction is rejected and the rejection was caused by the address and this segment was present in the 270. See Section 1.4.7.1 271 item 7 for additional information.
                  Use this segment to identify address information for a dependent.

               4. 0700 · N4 · Dependent City, State, ZIP Code · Max 1 · Optional

                  To specify the geographic place of the named party

                  Required when the Information Source requires this information to identify the Dependent for subsequent EDI transactions (see Section 1.4.7), OR Required if a rejection response is generated and this segment was present in the 270 and is the cause of the rejection. If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.
                  Do not return address information from the 270 request unless the transaction is rejected and the rejection was caused by the address and this segment was present in the 270. See Section 1.4.7.1 271 item 7 for additional information.
                  Use this segment to identify address information for a dependent.

               5. 0850 · AAA · Dependent Request Validation · Max 9 · Optional

                  To specify the validity of the request and indicate follow-up action authorized

                  Required when the request could not be processed at a system or application level when specifically related to the data contained in the original 270 transaction's dependent name loop (Loop 2100D) and to indicate what action the originator of the request transaction should take. If not required by this implementation guide, do not send.
                  Use this segment to indicate problems in processing the transaction;specifically related to the data contained in the original 270;transaction's dependent name loop (Loop 2100D).

               6. 0900 · PRV · Provider Information · Max 1 · Optional

                  To specify the identifying characteristics of a provider

                  Required when the 270 request contained a 2100D PRV segment and the information contained in the PRV segment was used to determine the 271 response.; OR Required when needed either to identify a provider's role or to associate a specialty type related to the service identified in the 2110D loop. This PRV segment applies to all benefits in this 2100D loop unless overridden by a PRV segment in the 2120D loop. If not required by this implementation guide, do not send.
                  If identifying a specific provider, use this segment to convey specific information about a provider's role in the eligibility/benefit being inquired about or to convey the provider's Taxonomy Code when the provider is not the information receiver. For example, if the information receiver is a hospital and a referring provider must be identified, this is the segment where the referring provider would be identified.
                  If identifying a type of specialty associated with the services identified in loop 2110D, use code PXC in PRV02 and the appropriate code in PRV03.
                  If there is a PRV segment in 2100B, this PRV overrides it for this occurrence of the 2100D loop.

               7. 1000 · DMG · Dependent Demographic Information · Max 1 · Optional

                  To supply demographic information

                  Use this segment to convey the birth date or gender demographic information for the dependent.
                  Required when the Dependent is the patient unless a rejection response is generated with a 2100D or 2110D AAA segment and this segment was not sent in the request. If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.

               8. 1100 · INS · Dependent Relationship · Max 1 · Optional

                  To provide benefit information on insured entities

                  This segment may also be used to identify that the information source has changed some of the identifying elements for the dependent that the information receiver submitted in the original 270 transaction.
                  Required when the Dependent is the patient unless a rejection response is generated with a 2100D or 2110D AAA segment and this segment was not sent in the request. If not required by this implementation guide, may be provided at sender's discretion but cannot be required by the receiver.

               9. 1150 · HI · Dependent Health Care Diagnosis Code · Max 1 · Optional

                  To supply information related to the delivery of health care

                  Required when an HI segment was received in the 270 and if the information source uses the information in the determination of the eligibility or benefit response for the dependent. All information used from the HI segment of the 270 used in the determination of the eligibility or benefit response for the dependent must be returned. If information was provided in an HI segment of 270 but was not used in the determination of the eligibility or benefits for the dependent it must not be returned. The information source must not use information in an HI segment of the 270 transaction in the determination of eligibility or benefits for the dependent if that information cannot be returned in the 271 response. OR Required when needed to identify limitations in the benefits identified in the 2110D loops, such as if benefits are limited for a specific diagnosis code if the information source can support this high level functionality. If the information source cannot support this high level functionality, do not send.
                  Use the Diagnosis code pointers in 2110D EB14 to identify which diagnosis code or codes in this HI segment relates to the information provided in the EB segment.
                  Do not transmit the decimal points in the diagnosis codes. The decimal point is assumed.

               10. 1200 · DTP · Dependent Date · Max 9 · Optional

                   To specify any or all of a date, a time, or a time period

                   The dates represented may be in the past, the current date, or a future date. The dates may also be a single date or a span of dates. Which date(s) to use is determined by the format qualifier in DTP02.
                   Required to identify the Plan (DTP01 = 291) or Plan Begin (DTP01 = 346) date when the individual has active coverage unless multiple plans apply to the individual or multiple plan periods apply, which must then be returned in the 2110D DTP (See Section 1.4.7); OR Required when needed to identify other relevant dates that apply to the Dependent. If not required by this implementation guide, do not send.
                   Dates supplied in the 2100D DTP apply to the Dependent and all 2110D loops unless overridden by an occurrence of a 2110D DTP with the same value in DTP01.

               11. 1275 · MPI · Dependent Military Personnel Information · Max 1 · Optional

                   To report military service data

                   Required when this transaction is processed by DOD or CHAMPUS/TRICARE and when necessary to convey the Dependent's military service data If not required by this implementation guide, do not send.

               12. 2110D Loop Optional Repeat >1

                   1. 1300 · EB · Dependent Eligibility or Benefit Information · Max 1 · Mandatory

                      To supply eligibility or benefit information

                      See Section 1.4.7 Implementation-Compliant Use of the 270/271 Transaction Set for information about what information must be returned if the subscriber is the person whose eligibility or benefits are being sent.
                      Either EB03 or EB13 may be used in the same EB segment, not both.
                      Required when the dependent is the person whose eligibility or benefits are being described and the transaction is not rejected (see Section 1.4.10) or if the transaction needs to be rejected in this loop. If not required by this implementation guide, do not send.
                      EB03 is a repeating data element that may be repeated up to 99 times. If all of the information that will be used in the 2110D loop is the same with the exception of the Service Type Code used in EB03, it is more efficient to use the repetition function of EB03 to send each of the Service Type Codes needed. If an Information Source supports responses with multiple Service Type Codes, the repetition use of EB03 must be supported if all other elements in the 2110D loop are identical.
                      A limit to the number of repeats of EB loops has not been established. In a batch environment there is no practical reason to limit the number of EB loop repeats. In a real time environment, consideration should be given to how many EB loops are generated given the amount of time it takes to format the response and the amount of time it will take to transmit that response. Since these limitations will vary by information source, it would be completely arbitrary for the developers to set a limit. It is not the intent of the developers to limit the amount of information that is returned in a response, rather to alert information sources to consider the potential delays if the response contains too much information to be formatted and transmitted in real time.
                      Use this segment to begin the eligibility/benefit information looping structure. The EB segment is used to convey the specific eligibility or benefit information for the entity identified.

                   2. 1350 · HSD · Health Care Services Delivery · Max 9 · Optional

                      To specify the delivery pattern of health care services

                      Required when needed to identify a specific delivery or usage pattern associated with the benefits identified in either EB03 or EB13. If not required by this implementation guide, do not send.

                   3. 1400 · REF · Dependent Additional Identification · Max 9 · Optional

                      To specify identifying information

                      Use this segment for reference identifiers related only to the 2110D loop that it is contained in (e.g. Other or Additional Payer's identifiers).
                      Required when the Information Source requires one or more of these additional identifiers for subsequent EDI transactions (see Section 1.4.7); OR Required when an additional identifier is associated with the eligibility or benefits being identified in the 2110D loop. If not required by this implementation guide, do not send.
                      Use this segment to identify other or additional reference numbers for the entity identified. The type of reference number is determined by the qualifier in REF01. Only one occurrence of each REF01 code value may be used in the 2110D loop.

                   4. 1500 · DTP · Dependent Eligibility/Benefit Date · Max 20 · Optional

                      To specify any or all of a date, a time, or a time period

                      When using the DTP segment in the 2110D loop this date applies only to the 2110D Eligibility or Benefit Information (EB) loop in which it is located. If a DTP segment with the same DTP01 value is present in the 2100D loop, the date is overridden for only this 2110D Eligibility or Benefit Information (EB) loop.
                      Required when the individual has active coverage with multiple plans or multiple plan periods apply (See 2100D DTP segment); OR Required when needed to convey dates associated with the eligibility or benefits being identified in the 2110D loop. If not required by this implementation guide, do not send.

                   5. 1600 · AAA · Dependent Request Validation · Max 9 · Optional

                      To specify the validity of the request and indicate follow-up action authorized

                      Required when the request could not be processed at a system or application level when specifically related to specific eligibility/benefit inquiry data contained in the original 270 transaction's dependent eligibility/benefit inquiry information loop (Loop 2110D) and to indicate what action the originator of the request transaction should take. If not required by this implementation guide, do not send.
                      Use this segment to indicate problems in processing the transaction;specifically related to specific eligibility/benefit inquiry data contained in the original 270 transaction's dependent eligibility/benefit inquiry information loop (Loop 2110D).

                   6. 2500 · MSG · Message Text · Max 10 · Optional

                      To provide a free-form format that allows the transmission of text information

                      Free form text or description fields are not recommended because they require human interpretation.
                      Under no circumstances can an information source use the MSG segment to relay information that can be sent using codified information in existing data elements (including combinations of multiple data elements and segments). Information that has been provided in codified form in other segments or elements elsewhere in the 271 for the individual must not be repeated in the MSG segment. If the information cannot be codified, then cautionary use of the MSG segment is allowed as a short term solution. It is highly recommended that the entity needing to use the MSG segment approach X12N with data maintenance to solve the long term business need, so the use of the MSG segment can be avoided for that issue.
                      Required when the eligibility or benefit information cannot be codified in existing data elements (including combinations of multiple data elements and segments); AND Required when this information is pertinent to the eligibility or benefit response. If not required by this implementation guide, do not send.
                      Benefit Disclaimers are strongly discouraged. See section 1.4.11 Disclaimers Within the Transaction. Under no circumstances are more than one MSG segment to be used for a Benefit Disclaimer per individual response.

                   7. 2115D Loop Optional Repeat 10

                      1. 2600 · III · Dependent Eligibility or Benefit Additional Information · Max 1 · Mandatory

                         To report information

                         Required when III segments in Loop 2110D of the 270 Inquiry were used in the determination of the eligibility or benefit response; OR Required when needed to identify limitations in the benefits explained in the corresponding Loop 2110D (such as if benefits are limited to a type of facility). If not required by this implementation guide, do not send.
                         This segment has two purposes. Information that was received in III segments in Loop 2110D of the 270 Inquiry and was used in the determination of the eligibility or benefit response must be returned. If information was provided in III segments of Loop 2110D but was not used in the determination of the eligibility or benefits it must not be returned. This segment can also be used to identify limitations in the benefits explained in the corresponding Loop 2110D, such as if benefits are limited to a type of facility.
                         Use this segment to identify Nature of Injury Codes and/or Facility Type as they relate to the information provided in the EB segment.
                         Use the III segment only if an information source can support this high level functionality.
                         Use this segment only one time for the Facility Type Code.

                   8. 3300 · LS · Loop Header · Max 1 · Optional

                      To indicate that the next segment begins a loop

                      Use this segment to identify the beginning of the Dependent Benefit Related Entity Name loop. Because both the subscriber's name loop and this loop begin with NM1 segments, the LS and LE segments are used to differentiate these two loops.
                      Required when Loop 2120D is used. If not required by this implementation guide, do not send.

                   9. 2120D Loop Optional Repeat 23

                      1. 3400 · NM1 · Dependent Benefit Related Entity Name · Max 1 · Mandatory

                         To supply the full name of an individual or organizational entity

                         Required when provider was identified in 2100D PRV02 and PRV03 by Identification Number (not Taxonomy Code) in the 270 Inquiry and was used in the determination of the eligibility or benefit response; OR Required when needed to identify an entity associated with the eligibility or benefits being identified in the 2110D loop such as a provider (e.g. primary care provider), an individual, an organization, another payer, or another information source; If not required by this implementation guide, do not send.

                      2. 3600 · N3 · Dependent Benefit Related Entity Address · Max 1 · Optional

                         To specify the location of the named party

                         Use this segment to identify address information for an entity.
                         Required when needed to further identify the entity or individual in loop 2120D NM1 and the information is available. If not required by this implementation guide, do not send.

                      3. 3700 · N4 · Dependent Benefit Related Entity City, State, ZIP Code · Max 1 · Optional

                         To specify the geographic place of the named party

                         Use this segment to identify address information for an entity.
                         Required when needed to further identify the entity or individual in loop 2120D NM1 and the information is available. If not required by this implementation guide, do not send.

                      4. 3800 · PER · Dependent Benefit Related Entity Contact Information · Max 3 · Optional

                         To identify a person or office to whom administrative communications should be directed

                         Use this segment when needed to identify a contact name and/or communications number for the entity identified. This segment allows for three contact numbers to be listed. This segment is used when the information source wishes to provide a contact for the entity identified in loop 2120D NM1. If telephone extension is sent, it should always be in the occurrence of the communications number following the actual phone number. See the example for an illustration.
                         Required when Contact Information exists and is available. If not required by this implementation guide, do not send.
                         If this segment is used, at a minimum either PER02 must be used or PER03 and PER04 must be used. It is recommended that at least PER02, PER03 and PER04 are sent if this segment is used.
                         When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number should always include the area code and phone number using the format AAABBBCCCC. Where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number (e.g. (534)224-2525 would be represented as 5342242525). The extension, when applicable, should be included in the communication number immediately after the telephone number.

                      5. 3900 · PRV · Dependent Benefit Related Provider Information · Max 1 · Optional

                         To specify the identifying characteristics of a provider

                         If identifying a type of specialty associated with the services identified in loop 2110D, use code PXC in PRV02 and the appropriate code in PRV03.
                         If there is a PRV segment in 2100B or 2100D, this PRV overrides it for this occurrence of the 2110D loop.
                         Required when needed either to identify a provider's role or associate a specialty type related to the service identified in the 2110D loop. If not required by this implementation guide, do not send.

                   10. 4000 · LE · Loop Trailer · Max 1 · Optional

                       To indicate that the loop immediately preceding this segment is complete

                       Required when Loop 2120D is used. If not required by this implementation guide, do not send.
                       Use this segment to identify the end of the Dependent Benefit Related Entity Name loop. Because both the dependent's name loop and this loop begin with NM1 segments, the LS and LE segments are used to differentiate these two loops.

2. 4100 · SE · Transaction Set Trailer · Max 1 · Mandatory

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

   Use this segment to mark the end of a transaction set and provide control information on the total number of segments included in the transaction set.