New: Drop-in replacement for Change Healthcare APIs

EDI 270 X279A1 - Health Care Eligibility Benefit Inquiry

Functional Group HS

X12N Insurance Subcommittee

This X12 Transaction Set contains the format and establishes the data contents of the Eligibility, Coverage or Benefit Inquiry Transaction Set (270) for use within the context of an Electronic Data Interchange (EDI) environment. This transaction set can be used to inquire about the eligibility, coverages or benefits associated with a benefit plan, employer, plan sponsor, subscriber or a dependent under the subscriber's policy. The transaction set is intended to be used by all lines of insurance such as Health, Life, and Property and Casualty.

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 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.
      In a batch environment, only one Loop 2000A (Information Source) loop is to be created for each unique information source in a transaction. Each Loop 2000B (Information Receiver) loop that is subordinate to an information source is to be contained within only one Loop 2000A loop. There has been a misuse of the HL structure creating multiple Loops 2000As for the same information source. This is not the developer's intended use of the HL structure, and defeats the efficiencies that are designed into the HL structure.
      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 Inquiry Subscriber (Loop 2000C) Eligibility or Benefit Inquiry Dependent (Loop 2000D) Eligibility or Benefit Inquiry

   2. 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 NM1 loop to identify an entity by name and/or identification number. This NM1 loop is used to identify the eligibility or benefit information source, (e.g., insurance company, HMO, IPA, employer).

   3. 2000B Loop Mandatory 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.
         In a batch environment, only one Loop 2000B (Information Receiver) loop is to be created for each unique information receiver within an Loop 2000A (Information Source) loop. Each Loop 2000C (Subscriber) loop that is subordinate to an information receiver is to be contained within only one Loop 2000B loop. There has been a misuse of the HL structure creating multiple Loop 2000Bs for the same information receiver within an information source loop. This is not the developer's intended use of the HL structure, and defeats the efficiencies that are designed into the HL structure.
         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 Inquiry Subscriber (Loop 2000C) Eligibility or Benefit Inquiry Dependent (Loop 2000D) Eligibility or Benefit Inquiry

      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, employer, 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 the information in 2100B NM1 is not sufficient 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 the information receiver is a provider who has multiple locations and it is needed to identify the location relative to the request. 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 the information receiver is a provider who has multiple locations and it is needed to identify the location relative to the request. If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.

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

            To specify the identifying characteristics of a provider

            Required when the Information Receiver believes Provider Information is relevant to the request and is necessary to convey the provider's role in or taxonomy code related to the eligibility/benefit being inquired about and the provider is also the Information Receiver. If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.
            For example, if the Information Receiver is also the Referring Provider, this PRV segment would be used to identify the provider's role.
            PRV02 qualifies PRV03.

      3. 2000C Loop Mandatory Repeat >1

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

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

            If the transaction set is to be used in a real time mode (see section 1.4.3 for additional detail), it is required that the 270 transaction contain only one patient request (except as allowed in Section 1.4.3 Exceeding the Number of Patient Requests). One patient request (See Section 1.4.2) is defined as the occurrence of one or more 2110 (EQ) loops for an individual. If the patient is the subscriber, the patient request is the existence of at least one 2110C loop. If the patient is the dependent, the patient request is the existence of at least one 2110D loop. In the event the patient has more than one occurrence of a 2110 (EQ) loop, that still constitutes one patient request. If the transaction set is to be used in a batch mode (see section 1.4.3 for additional detail), it is required that the 270 transaction contain a maximum of ninety-nine patient requests (except as allowed in Section 1.4.3 Exceeding the Number of Patient Requests). One patient request (See Section 1.4.2) is defined as the occurrence of one or more 2110 (EQ) loops for an individual. If the patient is the subscriber, the patient request is the existence of at least one 2110C loop. If the patient is the dependent, the patient request is the existence of at least one 2110D loop. In the event the patient has more than one occurrence of a 2110 (EQ) loop, that still constitutes one patient request. Although it is not recommended, if the number of patients is to be greater than one for real time mode or greater than ninety-nine for batch mode, the trading partners (the Information Source, the Information Receiver and the clearinghouse the transaction is routed through, if there is one involved) must all agree to exceed the number of patient requests and agree to a reasonable limit. See Section 1.4.3 Exceeding the Number of Patient Requests for additional information.
            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 Inquiry Subscriber (Loop 2000C) Eligibility or Benefit Inquiry Dependent (Loop 2000D) Eligibility or Benefit Inquiry

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

            To uniquely identify a transaction to an application

            The information receiver may assign one TRN segment in this loop if the subscriber is the patient. A clearinghouse may assign one TRN segment in this loop if the subscriber is the patient. See Section 1.4.6 Information Linkage.
            This segment must not be used if the subscriber is not the patient. See section 1.4.2. Basic Concepts.
            Required when information receiver or clearinghouse intends to use the TRN segment as a tracing mechanism for the eligibility transaction and the subscriber is the patient. If not required by this implementation guide, do not send.
            Trace numbers assigned at the subscriber level are intended to allow tracing of an eligibility/benefit transaction when the subscriber is the patient.

         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. Use this NM1 loop to identify the insured or subscriber.
               Please refer to Section 1.4.8 Search Options for specific information about how to identify an individual to an Information Source.
               In worker's compensation or other property and casualty transactions, the "subscriber" may be a non-person entity (for example, the employer). However, this varies by state.

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

               To specify identifying information

               Use this segment when needed to convey identification numbers 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.
               Please refer to Section 1.4.8 Search Options for specific information about how to identify an individual to an Information Source.
               Required when the information receiver believes this is needed for an Alternate Search Option supported by the Information Source (See Section 1.4.8). OR Required when this segment is used to transmit the Patient Account Number when REF01 = EJ (see Section 1.4.6). OR Required when this segment is used to transmit the Provider's Contract Number when REF01 = CT. If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.

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

               To specify the location of the named party

               Required when the information receiver believes this is needed for an Alternate Search Option supported by the Information Source (See Section 1.4.8). If not required by this implementation guide, do not send.

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

               To specify the geographic place of the named party

               Required when the information receiver believes this is needed for an Alternate Search Option supported by the Information Source (See Section 1.4.8). If not required by this implementation guide, do not send.

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

               To specify the identifying characteristics of a provider

               This segment must not be used to identify the information receiver or the information receiver's specialty type, unless the information is different from that sent in the 2100B loop.
               If identifying a specific provider, use this segment to convey specific information about a provider's role in the eligibility/benefit being inquired about 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.
               Required when the information source is known to process this information in creating a 271 response and the information receiver feels it is necessary to identify a specific provider or to associate a specialty type related to the service identified in the 2110C loop. If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.
               If identifying a specific provider, this segment contains reference identification numbers, all of which may be used up until the time the National Provider Identifier (NPI) is mandated for use. After the NPI is mandated, only the code for National Provider Identifier may be used.
               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.
               PRV02 qualifies PRV03.

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

               To supply demographic information

               Use this segment when needed to convey birth date or gender demographic information for the subscriber.
               Please refer to Section 1.4.8 Search Options for specific information about how to identify an individual to an Information Source.
               Required when the subscriber is the patient and the information receiver is utilizing the Primary Search Option (See Section 1.4.8). OR Required when the subscriber is the patient and the information receiver is utilizing one of the Required Alternate Search Options that require the Patient's Date of Birth (See Section 1.4.8). OR Required when the information receiver believes this is needed for an Alternate Search Option supported by the Information Source (See Section 1.4.8). If not required by this implementation guide, do not send.

            7. 1100 · INS · Multiple Birth Sequence Number · Max 1 · Optional

               To provide benefit information on insured entities

               Required when the information receiver believes it is necessary to identify the birth sequence of the subscriber in the case of multiple births with the same birth date for an Alternate Search Option supported by the Information Source (See Section 1.4.8). If not required by this implementation guide, do not send.
               This segment must not be used if the subscriber is not part of a multiple birth.

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

               To supply information related to the delivery of health care

               Use the HI segment when an information source supports or may be thought to support this level of functionality. If not supported, the information source will process without this segment. 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.
               Use this segment to identify Diagnosis codes as they relate to the information provided in the EQ segments.
               Do not transmit the decimal points in the diagnosis codes. The decimal point is assumed.
               Required when the information receiver believes the Diagnosis information is relevant to the inquiry, the information is available and if the information source supports or is believed to support this level of functionality. If not required by this implementation guide, do not send.

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

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

               Absence of a Plan date indicates the request is for the date the transaction is processed and the information source is to process the transaction in the same manner as if the processing date was sent.
               Use this segment to convey the plan date(s) for the subscriber or for the issue date of the subscriber's identification card for the information source.
               When using code "291" (Plan) at this level, it is implied that these dates apply to all of the Eligibility or Benefit Inquiry (EQ) loops that follow. If there is a need to supply a different Plan date for a specific EQ loop, it must be provided in the DTP segment within the EQ loop and it will only apply to that EQ loop.
               Required when the information receiver wishes to convey the plan date(s) for the subscriber in relation to the eligibility/benefit inquiry. If not required by this implementation guide, may be sent at the sender's discretion but cannot be required by the information source. OR Required when utilizing a search option other than either the Primary Search Option or a Required Alternate Search Option identified in section 1.4.8 which requires the ID Card Issue Date. If not required by this implementation guide, may be sent at the sender's discretion but cannot be required by the information source.

            10. 2110C Loop Optional Repeat 99

                1. 1300 · EQ · Subscriber Eligibility or Benefit Inquiry · Max 1 · Mandatory

                   To specify inquired eligibility or benefit information

                   When the subscriber is not the patient, the 2110C EQ segment must not be used. When the transaction is used in a batch environment, it is possible to have both 2110C and 2110D EQ segments when the subscriber and dependent(s) are patients whose eligibility or benefits are being verified. See Section 1.4.3 Batch and Real Time for additional information.
                   The 2110C EQ segment begins the 2110C loop.
                   Required when the subscriber is the patient whose eligibility or benefits are being verified. If not required by this implementation guide, do not send.
                   If the EQ segment is used, either EQ01 - Service Type Code or EQ02 - Composite Medical Procedure Identifier must be used. Only EQ01 or EQ02 is to be sent, not both. An information source must support a generic request for Eligibility. This is accomplished by submitting a Service Type Code of "30" (Health Benefit Plan Coverage) in EQ01. An information source may support the use of Service Type Codes other than "30" (Health Benefit Plan Coverage) in EQ01 at their discretion. An information source may support the use of EQ02 - Composite Medical Procedure Identifier at their discretion. The EQ02 allows for a very specific inquiry, such as one based on a procedure code. Additional information such as diagnosis codes can be supplied in the 2100C HI segment and place of service in the 2110C III segment.
                   If an information source receives a Service Type Code "30" submitted in the 270 EQ01 or a Service Type Code that they do not support, the 2110C EB03 values identified in Section 1.4.7.1 Item #8 must also be returned if they are a covered benefit category at a plan level. Refer to Section 1.4.7 for additional information.
                   EQ01 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 EQ01, it is more efficient to use the repetition function of EQ01 to send each of the Service Type Codes needed. If an Information Source supports more than Service Type Code "30", and can support requests for multiple Service Type Codes, the repetition use of EQ01 must be supported.

                2. 1350 · AMT · Subscriber Spend Down Amount · Max 1 · Optional

                   To indicate the total monetary amount

                   Use this segment only if it is necessary to report a Spend Down amount. Under certain Medicaid programs, individuals must indicate the dollar amount that they wish to apply towards their deductible. These programs require individuals to pay a certain amount towards their health care cost before Medicaid coverage starts.
                   Required if Spend Down amount is being reported. If not required by this implementation guide, do not send.

                3. 1350 · AMT · Subscriber Spend Down Total Billed Amount · Max 1 · Optional

                   To indicate the total monetary amount

                   Required if Spend Down amount is being reported in a separate 2110C AMT segment and the information source also requires the Spend Down Total Billed Amount. If not required by this implementation guide, do not send.
                   Use this segment only if it is necessary to report the Spend Down Total Billed Amount in addition to the Spend Down Amount. See 2110C Subscriber Spend Down Amount segment for more information about Spend Down.

                4. 1700 · III · Subscriber Eligibility or Benefit Additional Inquiry Information · Max 1 · Optional

                   To report information

                   Use the III segment when an information source supports or may be thought to support this level of functionality. If not supported, the information source will process without this segment.
                   Required when the information receiver believes the Facility Type information is relevant to the inquiry and the information is available. If not required by this implementation guide, do not send.

                5. 1900 · REF · Subscriber Additional Information · Max 1 · Optional

                   To specify identifying information

                   Required when the subscriber has received a referral or prior authorization number and the information receiver believes the information is relevant to the inquiry (such as for a benefit or procedure that requires a referral or prior authorization) and the information is available. If not required by this implementation guide do not send.
                   Use this segment when it is necessary to provide a referral or prior authorization number for the benefit being inquired about.

                6. 2000 · DTP · Subscriber Eligibility/Benefit Date · Max 1 · Optional

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

                   Use this segment to convey plan dates associated with the information contained in the corresponding EQ segment.
                   This segment is only to be used to override dates provided in Loop 2100C when the date differs from the date provided in the DTP segment in Loop 2100C. Dates that apply to the entire request must be placed in the DTP segment in Loop 2100C. In order for a date to appear here, there must be a date or a date range in the corresponding 2100C loop.
                   Required when the plan date(s) are different from the date(s) provided in the 2100C loop. 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

               If a patient is a dependent of a member, but can be uniquely identified to the information source (such as by, but not limited to, a unique Member Identification Number) then the patient is considered the subscriber and is to be identified in the Subscriber Level.
               Because the usage of this segment is "Situational", this is not a syntactically required loop. If this loop is used, then this segment is a "Required" segment. See Appendix B for further details on ASC X12 nomenclature.
               Required when the patient is a dependent of a member and cannot be uniquely identified to the information source without the member's information in the Subscriber Level 2000C loop. If not required by this implementation guide, do not send.
               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 Inquiry Subscriber (Loop 2000C) Eligibility or Benefit Inquiry Dependent (Loop 2000D) Eligibility or Benefit Inquiry

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

               To uniquely identify a transaction to an application

               Trace numbers assigned at the dependent level are intended to allow tracing of an eligibility/benefit transaction when the dependent is the patient.
               The information receiver may assign one TRN segment in this loop if the dependent is the patient. A clearinghouse may assign one TRN segment in this loop if the dependent is the patient. See Section 1.4.6 Information Linkage.
               Required when information receiver or clearinghouse intends to use the TRN segment as a tracing mechanism for the eligibility transaction and the dependent is the patient. If not required by this implementation guide, do not send.

            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.
                  Please refer to Section 1.4.8 Search Options for specific information about how to identify an individual to an Information Source.

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

                  To specify identifying information

                  Use this segment when needed to convey identification numbers for the dependent. 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.
                  Please refer to Section 1.4.8 Search Options for specific information about how to identify an individual to an Information Source.
                  Required when the information receiver believes this is needed for an Alternate Search Option supported by the Information Source (See Section 1.4.8). OR Required when this segment is used to transmit the Patient Account Number when REF01 = EJ (see Section 1.4.6). OR Required when this segment is used to transmit the Provider's Contract Number when REF01 = CT. If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.

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

                  To specify the location of the named party

                  Required when the information receiver believes this is needed for an Alternate Search Option supported by the Information Source (See Section 1.4.8). If not required by this implementation guide, do not send.

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

                  To specify the geographic place of the named party

                  Required when the information receiver believes this is needed for an Alternate Search Option supported by the Information Source (See Section 1.4.8). If not required by this implementation guide, do not send.

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

                  To specify the identifying characteristics of a provider

                  This segment must not be used to identify the information receiver or the information receiver's specialty type, unless the information is different from that sent in the 2100B loop.
                  Required when the information source is known to process this information in creating a 271 response and the information receiver feels it is necessary to identify a specific provider or to associate a specialty type related to the service identified in the 2110D loop. If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.
                  If identifying a specific provider, use this segment to convey specific information about a provider's role in the eligibility/benefit being inquired about 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 specific provider, this segment contains reference;identification numbers, all of which may be used up until the time the;National Provider Identifier (NPI) is mandated for use. After the NPI is mandated, only the code for National Provider Identifier may be used.
                  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.
                  PRV02 qualifies PRV03.

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

                  To supply demographic information

                  Use this segment when needed to convey the birth date or gender demographic information for the dependent.
                  Please refer to Section 1.4.8 Search Options for specific information about how to identify an individual to an Information Source.
                  Required when the dependent is the patient and the information receiver is utilizing the Primary Search Option (See Section 1.4.8). OR Required when the dependent is the patient and the information receiver is utilizing one of the Required Alternate Search Options that require the Patient's Date of Birth (See Section 1.4.8). OR Required when the information receiver believes this is needed for an Alternate Search Option supported by the Information Source (See Section 1.4.8). If not required by this implementation guide, do not send.

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

                  To provide benefit information on insured entities

                  Different types of health plans identify patients in different manners;depending upon how their eligibility is structured. However, two;approaches predominate. The first approach is to assign each member of the family (and plan) a;unique ID number. This number can be used to identify and access;that individual's information independent of whether he or she is a;child, spouse, or the actual subscriber to the plan. The relationship of this individual to the actual subscriber or contract holder would be;one of spouse, child, self, etc. The second approach is to assign the actual subscriber or contract;holder a unique ID number that is entered into the eligibility system.;Any related spouse, children, or dependents are identified through the;subscriber's ID and have no unique identification number of their;own. In this approach, the subscriber would be identified at the Loop;2100C subscriber or insured level and the actual patient (spouse,;child, etc.) would be identified at the Loop 2100D dependent level;under the subscriber.
                  Required when the information receiver believes it is necessary to identify for an Alternate Search Option supported by the Information Source (See Section 1.4.8) the dependent's relationship to the insured and/or the birth sequence of the dependent in the case of multiple births with the same birth date. If not required by this implementation guide, do not send.

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

                  To supply information related to the delivery of health care

                  Use the HI segment when an information source supports or may be thought to support this level of functionality. If not supported, the information source will process without this segment. 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.
                  Required when the information receiver believes the Diagnosis information is relevant to the inquiry, the information is available and if the information source supports or is believed to support this level of functionality. If not required by this implementation guide, do not send.
                  Use this segment to identify Diagnosis codes as they relate to the information provided in the EQ segments.
                  Do not transmit the decimal points in the diagnosis codes. The decimal point is assumed.

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

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

                  Absence of a Plan date indicates the request is for the date the transaction is processed and the information source is to process the transaction in the same manner as if the processing date was sent.
                  Use this segment to convey the plan date(s) for the dependent or for the issue date of the dependent's identification card for the information source.
                  When using code "291" (Plan) at this level, it is implied that these dates apply to all of the Eligibility or Benefit Inquiry (EQ) loops that follow. If there is a need to supply a different Plan date for a specific EQ loop, it must be provided in the DTP segment within the EQ loop and it will only apply to that EQ loop.
                  Required when the information receiver wishes to convey the plan date(s) for the dependent in relation to the eligibility/benefit inquiry. If not required by this implementation guide, may be sent at the sender's discretion but cannot be required by the information source. OR Required when utilizing a search option other than either the Primary Search Option or a Required Alternate Search Option identified in section 1.4.8 which requires the ID Card Issue Date. If not required by this implementation guide, may be sent at the sender's discretion but cannot be required by the information source.

               10. 2110D Loop Mandatory Repeat 99

                   1. 1300 · EQ · Dependent Eligibility or Benefit Inquiry · Max 1 · Mandatory

                      To specify inquired eligibility or benefit information

                      Use this segment to begin the eligibility/benefit inquiry looping structure.
                      If the EQ segment is used, either EQ01 - Service Type Code or EQ02 - Composite Medical Procedure Identifier must be used. Only EQ01 or EQ02 is to be sent, not both. An information source must support a generic request for Eligibility. This is accomplished by submitting a Service Type Code of "30" (Health Benefit Plan Coverage) in EQ01. An information source may support the use of Service Type Codes other than "30" (Health Benefit Plan Coverage) in EQ01 at their discretion. An information source may support the use of EQ02 - Composite Medical Procedure Identifier at their discretion. The EQ02 allows for a very specific inquiry, such as one based on a procedure code. Additional information such as diagnosis codes can be supplied in the 2100D HI segment and place of service in the 2110D III segment.
                      If an information source receives a Service Type Code "30" submitted in the 270 EQ01 or a Service Type Code that they do not support, the 2110D EB03 values identified in Section 1.4.7.1 Item #8 must also be returned if they are a covered benefit category at a plan level. Refer to Section 1.4.7 for additional information.
                      EQ01 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 EQ01, it is more efficient to use the repetition function of EQ01 to send each of the Service Type Codes needed. If an Information Source supports more than Service Type Code "30", and can support requests for multiple Service Type Codes, the repetition use of EQ01 must be supported.

                   2. 1700 · III · Dependent Eligibility or Benefit Additional Inquiry Information · Max 1 · Optional

                      To report information

                      Use the III segment when an information source supports or may be thought to support this level of functionality. If not supported, the information source will process without this segment.
                      Required when the information receiver believes the Facility Type information is relevant to the inquiry and the information is available. If not required by this implementation guide, do not send.

                   3. 1900 · REF · Dependent Additional Information · Max 1 · Optional

                      To specify identifying information

                      Required when the dependent has received a referral or prior authorization number and the information receiver believes the information is relevant to the inquiry (such as for a benefit or procedure that requires a referral or prior authorization) and the information is available. If not required by this implementation guide do not send.
                      Use this segment when it is necessary to provide a referral or prior authorization number for the benefit being inquired about.

                   4. 2000 · DTP · Dependent Eligibility/Benefit Date · Max 1 · Optional

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

                      Use this segment to convey plan dates associated with the information contained in the corresponding EQ segment.
                      This segment is only to be used to override dates provided in Loop 2100D when the date differs from the date provided in the DTP segment in Loop 2100D. Dates that apply to the entire request must be placed in the DTP segment in Loop 2100D. In order for a date to appear here, there must be a date or a date range in the corresponding 2100D loop.
                      Required when the plan date(s) are different from the date(s) provided in the 2100C loop. If not required by this implementation guide, do not send.

2. 2100 · 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.