Health Care Eligibility Benefit Inquiry and Response (270/271)

X12 Standards for Electronic Data Interchange Technical Report Type 3 Health Care Eligibility Benefit Inquiry and Response (270/271) Change Log : 005010-007030 JULY 2018

Intellectual Property X12 holds the copyright on the Standards and associated publications designed to facilitate implementation of the Standards. Users of all X12 publications should be aware of the permissible uses, as well as the limitations on such usage, as outlined here: http://store.x12.org/store/ip-use. Copyright 2018, X12, Format 2018 Washington Publishing Company. Exclusively published by the Washington Publishing Company. No part of this publication may be distributed, posted, reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission of the copyright owner. All rights reserved.

New Loops/Segments For new loops, the change log will only reflect the new loop identifier and name and associated segments. For new segments added to existing loops, the change log will only reflect the segment name. Non-substantive Changes Changes considered by the work group to be non-substantive in nature will not appear in the change log. This includes changes to correct typographical or grammatical errors, updated examples, reformatted text, updated industry names, and modifications to rules and notes either for consistency across TR3s or for proper textual construct that did not change the note's original intent. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.3 Implementation Limitations Action None None Note that updates to Section numbers throughout the front matter and implementation section of the transaction set are only included in the change log when the revision included substantive verbiage changes in addition to the section number change. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.3 Implementation Limitations Action Modify Chapter 1 Updated front matter 1.3.2 paragraph 3 from: Although it is not recommended, if the number of patients is to be greater than one for real time mode, the trading partners (the information source, the information receiver and the switch the transaction is routed through, if there is one involved) must all agree to exceed the number of recommended patient requests and agree to a reasonable limit. To: Although it is not recommended, if the number of patients is to be greater than one for real-time 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 recommended patient requests and agree to a reasonable limit. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. JULY 2018 3

Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.3 Implementation Limitations Action Modify Chapter 1 Update front matter section 1.3.2 paragraph 4 from: In the event the Information Receiver exceeds the maximum number of patient requests allowed, two possible scenarios arise. First, if the processor of the transaction (either the switch or the Information Source) detects the maximum has been exceeded, a 271 with a AAA segment with element AAA03 containing a code value "04" (Authorized Quantity Exceeded) will be issued. If this has been detected by a switch, use the AAA segment in the Information Source Level (Loop 2000A). If this has been detected by an Information Source, use the AAA segment in the Information Source Name loop (Loop 2100A). Second, the processor's system may only process the number of patient requests required by this TR3 and may ignore the patient requests that exceed the limit. To: In the event the information receiver exceeds the maximum number of patient requests allowed, there are two possible outcomes. Either the transaction processor (the clearinghouse or information source) detects the maximum number of requests has been exceeded and responds with a 271 that includes the appropriate error reason code as outlined in the Code Value Usage in Eligibility Benefit Inquiry and Subsequent Response Technical Report Type 2; or the processor's system only processes the number of patient requests required by this TR3 and ignores the patient requests that exceed the maximum allowed. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Section 1.4.2 Paragraph 1 changed to: The Health Care Eligibility and Benefit transactions are designed so that inquiry submitters (information receivers) can determine (a) whether an information source organization (e.g., payer, employer, HMO) has a particular subscriber or dependent on file, and (b) the health care eligibility and/or benefit information about that subscriber and/or dependent(s). The data available through these transaction sets is used to verify an individual's eligibility and benefits. The information source organization may provide information about other organizations that may have third party liability for coordination of benefits. Note, the identification of subscriber/dependent and associated relationship code values may or may not be the values needed to determine JULY 2018 4

primary/secondary coverage for coordination of benefits on claims transactions. CR 1233 The Background Information section states..."the data available through these transaction sets is used to verify an individual's eligibility and benefits, but cannot provide a history of benefit use." Beginning in 6020, the TR3 supports returning accumulated amounts and lifetime limits. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Modify Front Matter Section 1.4.3 Basic Concepts, Paragraph 13 From: Patient Response (2110C or 2110D) The patient response is defined as the occurrence of one or more 2110 C or D (EB) loops for an individual. If the patient is submitted as the subscriber and the Information Source locates the patient and determines that they are actually a dependent, the primary subscriber is to be returned in the 2100C loop and the patient is to be returned in the 2100D loop with the patient response information located in the 2110D loop. To: Patient Response (2105C or 2105D) The patient response is defined as the occurrence of one or more 2105C Subscriber or 2105D Dependent Eligibility/Benefits Information Grouping (LX) loops for an individual. If the patient is submitted as the subscriber and the information source locates the patient who is considered a dependent per the description of Dependent or Patient in section 1.4.3 - Basic Concepts Dependent or Patient, the primary subscriber is to be returned in the 2100C Subscriber Name loop and the patient is to be returned in the 2100D Dependent Name loop with the patient response information located in the 2105D Eligibility/Benefits Information Grouping loop. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter - Modify 1.4.3 Basic Concepts - Paragraph 14 From: One other factor Information Sources need to bear in mind is how they need the patient submitted in subsequent transactions such as a 278 Health Care Services Request for Review or an 837 Health Care Claim. If the individual JULY 2018 5

patient must be submitted as a subscriber in a 278 or 837 transaction, then the Information Source must return the patient in the 271 as the subscriber. If the individual patient must be submitted as a dependent in a 278 or 837 transaction, then the Information Source must return the patient in the 271 as a dependent. This enables the provider to populate their practice management system with the proper information to submit a 278 or 837 transaction. The patient must be returned in the correct loop (2000C or 2000D) based on how the Information Source requires the individual be submitted in subsequent transactions. To: If the individual patient must be submitted as a subscriber in a 278 or 837 transaction, then the information source must return the patient in the 271 as the subscriber. If the individual patient must be submitted as a dependent in a 278 or 837 transaction, then the information source must return the patient in the 271 as a dependent. This enables the provider to populate their practice management or hospital information system with the proper information to submit a 278 or 837 transaction. The patient must be returned in the correct loop (2000C Subscriber Level or 2000D Dependent Level) based on how the information source requires the individual be submitted in subsequent transactions. CR 1294 A public comment was submitted for 6020 to correct a confusing sentence and the work group agreed to address this in a future version. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.3 Basic Concepts, Patient Submitted as Subscriber but Returned as Dependent, Modify Paragraph From: If the patient is submitted as the subscriber in the 270 transaction and the Information Source locates the patient and determines that they are actually a dependent, the primary subscriber is to be returned in the 271 2100C loop and the patient is to be returned in the 271 2100D loop with the patient response information located in the 2110D loop. See Section 1.4.8.2.4 for additional information. To: If the patient is submitted as the subscriber in the 270 transaction and the information source locates the patient and determines that they are actually a dependent who is considered a dependent per the description of Dependent or Patient in Section 1.4.3 - Basic Concepts - Dependent or Patient, the primary subscriber is to be returned in the 271 2100C Subscriber Name loop and the patient is to be returned in the 271 2100D Dependent Name loop with the patient response information located in the 2110D Eligibility or Benefit JULY 2018 6

Information loop. See Section 1.4.8.2.4 - Dependent Demographic Information for additional information. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.3 Basic Concepts, Patient Submitted as Subscriber but Returned as Dependent, Modify Paragraph From: If a TRN segment was submitted in the 270 2000C loop, it must be returned in the 271 2000D loop. If a REF segment with REF01 = EJ was submitted in the 270 2100C loop, it must be returned in the 271 2100D loop. See Section 1.4.7 - Information Linkage. To: If a TRN segment was submitted in the 270 2000C Subscriber Level loop, it must be returned in the 271 2000D Dependent Level loop. If a REF segment with REF01 = `EJ' was submitted in the 270 2100C Subscriber Name loop, it must be returned in the 271 2100D Dependent Name loop. See Section 1.4.7 - Information Linkage. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Modify Front Matter Section 1.4.3, Patient Submitted as Dependent but Returned as Subscriber, Modify Paragraph From: If the patient is submitted as the dependent in the 270 transaction and the Information Source locates the patient and determines that they are actually a subscriber, the patient is to be returned in the 271 2100C loop. See Section 1.4.8.2.3 for additional information To: If the patient is submitted as the dependent in the 270 transaction and the JULY 2018 7

information source locates the patient and determines that they are actually a subscriber who is considered a subscriber per the description of Subscriber or Patient in section 1.4.3 - Basic Concepts Subscriber or Patient, the patient is to be returned in the 271 2100C Subscriber Name loop. See Section 1.4.8.2.3 - Subscriber Demographic Information for additional information. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.3 Basic Concepts, Claim Routing Entity - Exception Processing, Modify Paragraph From: If all claims are routed to the same place, then the Claim Routing Entity should be included in the EB loop(s) where plan coverage is communicated with EB01 = '1' and EB03 = '30'. The entity will be identified at the 2120 level of this plan coverage loop. To: If all claims are routed to the same place, then the Claim Routing Entity should be included in the 2110C Subscriber or 2110D Dependent Eligibility or Benefit Information EB loop(s) where plan coverage is communicated with EB01 = '1' and an appropriate Health Care Service Type Code value in EB03-01. The entity will be identified at the appropriate 2120C Subscriber or 2120D Dependent Benefit Related Entity Name level of this plan coverage loop. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.3 Basic Concepts, Claim Routing Entity - Exception Processing, Modify Paragraph From: If a particular carve-out benefit is routed to a different entity, then that should be identified at the 2120 level of the benefit loop containing the relevant STC code in EB03. JULY 2018 8

To: If a particular carve-out benefit is routed to a different entity, then that should be identified at the appropriate 2120C Subscriber or 2120D Dependent Benefit Related Entity Name level of the benefit loop containing the relevant Health Care Service Type Code in 2110C Subscriber or 2110D Dependent Eligibility or Benefit Information EB03-01. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.3 Basic Concepts, Add New Paragraph Grace Period If a member is delinquent in premium payment, it could affect their eligibility status. The health care payer may allow a grace period during which claims could be paid, pended or denied. If the information source prefers to identify the associated eligibility status of a member falling within the grace period, this can be done by populating the 2110C Subscriber or 2110D Dependent Eligibility or Benefit Information (EB) segment Eligibility or Benefit Information (EB01) with one of the following code values: '10 - Inactive- Premium Payment Not Received', '11 - Active - Pending Receipt of Premium Payment', or '12 - Inactive - Pending Receipt of Premium Payment' with the associated grace period or premium payment dates in either the 2105C Subscriber or 2105D Dependent Eligibility/Benefits Information Grouping Date/Time Reference (DTM) segments or the 2110C Subscriber or 2110D Dependent Eligibility or Benefit Information Date (DTP) segments. This may be particularly useful when returning information on the eligibility status of a health insurance exchange enrollee receiving Advanced Payments of the Premium Tax Credit (APTC). CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.4 Batch and Real Time,Paragraph 1 changed From: JULY 2018 9

1.4.4 Batch and Real Time Within telecommunications, there are multiple methods used for sending and receiving business transactions. Frequently, different methods involve different timings. Two methods applicable for EDI transactions are batch and real time. The 270/271 Health Care Eligibility Benefit Inquiry and Response transactions can be used in either a batch mode or in a real time mode. To: 1.4.4 Batch and Real-Time Within telecommunications, there are multiple methods used for sending and receiving business transactions. Frequently, different methods involve different timings. Two methods applicable for EDI transactions are batch and real-time. The 270/271 Health Care Eligibility Benefit Inquiry and Response transactions can be used in either a batch mode or in a real-time mode. If trading partners are going to engage in both real-time and batch eligibility, it is recommended that they identify the method they are using. One suggested way of identifying this is by using different identifiers for real-time and batch in GS02 (Application Sender's Code) for the 270 transaction. A second suggested way is to add an extra letter to the identifier in GS02 (Application Sender's Code) for the 270 transaction, such as "B" for batch and "R" for realtime. Regardless of the methodology used, this will avoid the problems associated with batch eligibility transactions getting into a real-time processing environment and vice versa. CR 1244 Section 1.4.4 duplicates information in sections 1.3.1 and 1.3.2 Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Add Chapter 1 Add new paragraph to Front matter 1.4.4 as follows:to: It is required that trading partners be able to support 270 transactions that contain up to ninety-nine patient requests when using the transaction in a batch mode; however, if the trading partners and intermediaries involved in the processing of the 270 transaction(s) mutually agree, a greater number of patient requests may be supported when using the 270 transaction in batch mode. In a batch mode, it is possible to have patient requests in both the subscriber and dependent levels (e.g. subscriber and spouse). In a batch mode it is also possible to have multiple dependent patient requests (e.g. twins). In the case where there are patient requests at both the subscriber and dependent levels or for multiple dependents, each patient request counts as one patient request toward the maximum number of ninety-nine patient requests (See the description of Patient in Section 1.4.3 - Basic Concepts for additional information). CR 1254 Section 1.3.2 states a restriction limit on the number of batch 270 patient requests but in a separate paragraph states 99 is a recommendation. Resolve this conflict. It is requested that a maximum of 99 be a recommendation. JULY 2018 10

Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front matter 1.4.4 batch section was replaced CR 1244 Section 1.4.4 duplicates information in sections 1.3.1 and 1.3.2 Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.4 Real Time, Modify Paragraph From: Real Time Transactions that are used in a real time mode typically are those that require an immediate response. In a real time mode, the sender sends a request transaction to the receiver, either directly or through a clearinghouse (switch), and remains connected while the receiver processes the transaction and returns a response transaction to the original sender. Typically, response times range from a few seconds to around thirty seconds. If the transaction set is to be used in a real time mode, the Information Receiver sends the 270 transaction through some means of telecommunication (e.g. Async., TCP/IP, LU6.2, etc.) to the Information Source (typically through a clearinghouse - see Sections 1.4.14.2 and 1.4.14.3) and remains connected while the Information Source processes the transaction and returns a 271 to the Information Receiver. It is required that the 270 transaction contain only one patient request when using the transaction in a real time mode (See the Exceeding The Number of Patient Requests section below for the exception). One patient is defined as either, one subscriber loop if the member is the patient, or one dependent loop if the dependent is the patient (See Section 1.4.3 Patient for additional information). The 271 response can only contain eligibility and benefit information for the patient(s) identified in the 270 request unless the 270 request contained a value of "FAM" in 2110C EQ03 and this level of functionality is supported by the Information Source. To: Real-Time Transactions that are used in a real-time mode typically are those that require an immediate response. In a real-time mode, the sender sends a request transaction to the receiver, either directly or through a clearinghouse, and remains connected while the receiver processes the transaction and returns a response transaction to the original sender. Typically, response times range from a few seconds to around thirty seconds. If the transaction set is to be used in a real-time mode, the information receiver sends the 270 transaction through some means of telecommunication (e.g. Async., TCP/IP, LU6.2, etc.) to the information source (typically through a JULY 2018 11

clearinghouse - see Sections 1.4.14.2 - Intermediaries and 1.4.14.3 - Multiple Intermediaries) and remains connected while the information source processes the transaction and returns a 271 to the information receiver. The 271 response can only contain eligibility and benefit information for the patient(s) identified in the 270 request unless the 270 request contained a value of `FAM' in 2110C Subscriber Eligibility or Benefit Inquiry EQ03 and this level of functionality is supported by the information source. CR 1244 Section 1.4.4 duplicates information in sections 1.3.1 and 1.3.2 Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.4 Real Time, Delete Paragraph From: Important: When in real time mode, the receiver must send a response of either the 271 response transaction, a 999 Implementation Acknowledgment, or a TA1 segment. To: (deleted) CR 1244 Section 1.4.4 duplicates information in sections 1.3.1 and 1.3.2 Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Delete Chapter 1 Front Matter Change log 1.4.4 - Exceeding the number of patient requests section removed CR 1244 Section 1.4.4 duplicates information in sections 1.3.1 and 1.3.2 Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.5 Supported Business Functions, Modify Heading From: General Inquiry To: General/Simple Inquiry using Health Care Service Type Codes CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. JULY 2018 12

Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.5 Supported Business Functions, Modify Paragraph From: The Health Care Eligibility transaction sets are designed to satisfy the needs of a simple eligibility status inquiry (is the subscriber/dependent eligible?) or a more complex benefit inquiry allowing for the return of information such as coinsurance, co-pays, deductibles, exclusions, and limitations related to a specific procedures. To support this broad range of health care eligibility or benefit inquiry needs, the transaction sets can be viewed as a cone of information requests and responses to support the submitting and receiving organizations' business needs. To: The Health Care Eligibility transaction sets are designed to satisfy the needs of a simple eligibility status inquiry (is the subscriber/dependent eligible?) or a more complex benefit inquiry allowing for the return of information such as coinsurance, co-pays, deductibles, exclusions, and limitations related to specific services or procedures. To support this broad range of health care eligibility or benefit inquiry needs, the transaction sets can be viewed as a cone of information requests and responses to support the submitting and receiving organizations' business needs. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.7.1 Real Time Linkage, Modify Paragraph From: Real Time Linkage The 270 request transaction has several methods of providing linkage to the 271 response transaction when the transaction is being processed in Real Time (see Section 1.4.4 - Batch and Real Time). Values returned in the 271 response transaction must be returned exactly as submitted in the corresponding 270 request transaction. To: Real-Time Linkage The 270 request transaction has several methods of providing linkage to the JULY 2018 13

CR 287 271 response transaction when the transaction is being processed in real-time (see Section 1.4.4 - Batch and Real-Time). Values identified in 1.4.7.1.1 - Information Receiver, 1.4.7.1.2 - Information Source, and 1.4.7.1.3 - Clearinghouse subsections must be returned in the 271 response transaction as submitted in the corresponding 270 request transaction. Update front matter to clearly articulate the batch linkage section. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.7.1 Real-Time Linkage, Clearinghouse, Modify Paragraph From: NOTE: If the Information Source determines that the patient was submitted as a subscriber but is actually a dependent, the TRN segment(s) submitted in the 2000C loop, along with the patient information will be moved to the 2000D loop. If the Information Source determines that the patient was submitted as a dependent but is actually a subscriber, the TRN segment(s) submitted in the 2000D loop, along with the patient information will be moved to the 2000C loop. See Section 1.4.3 - Basic Concepts for additional information. To: NOTE: If the information source determines that the patient was submitted as a subscriber but is actually a dependent, the TRN segment(s) submitted in the 2000C Subscriber Level loop, along with the patient information will be moved to the 2000D Dependent Level loop. If the information source determines that the patient was submitted as a dependent but is actually a subscriber, the TRN segment(s) submitted in the 2000D Dependent Level loop, along with the patient information will be moved to the 2000C Subscriber Level loop. See Section 1.4.3 - Basic Concepts for additional information. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.7.2 Batch Linkage, Modify Paragraph From: Given the nature of batch processing which may or may not respond to each of the requests in the same batch response, the 270 request transaction has fewer methods of providing linkage to the 271 response transaction when the JULY 2018 14

CR 287 transactions are being processed in Batch (see Section 1.4.4 - Batch and Real Time). Values returned in the 271 response transaction must be returned exactly as submitted in the corresponding 270 request transaction. To: Given the nature of batch processing which may or may not respond to each of the requests in the same batch response, the 270 request transaction has fewer methods of providing linkage to the 271 response transaction when the transactions are being processed in batch (see Section 1.4.4 - Batch and Real-Time). Values identified in 1.4.7.2.1 - Information Receiver and 1.4.7.2.2 - Information Source subsections must be returned in the 271 response transaction as submitted in the corresponding 270 request transaction. Update front matter to clearly articulate the batch linkage section. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.8 Implementation-Compliant Use of the 270/271 Transaction Set, Modify Paragraphs From: The ANSI ASC X12N Implementation Guideline for the Health Care Eligibility Benefit Inquiry and Response 270/271 transaction set contains a super set of data segments, elements and codes which represent its full functionality. This super set covers a great number of business scenarios and does not necessarily represent the business needs of an individual provider, payer or other trading partner involved in the use of the 270/271. The super set identifies the framework an information source (typically a payer) can utilize. This Implementation Guide also identifies the minimum an information source or clearinghouse is required to support in order to offer an implementationcompliant 270/271 transaction. Identification of the person being inquired about can be found in Section 1.4.9 - Search Options. The 271 transaction is designed to report a great deal more than "Yes, the patient is eligible today". Some of the items that can be returned if the conditions apply are: Co-payment, Co-insurance, Deductible amounts, Plan Beginning and Ending Dates (allowing for dates other than the current date) and information about the Primary Care Provider. Additionally, specific service types and their related information can also be returned. The 271 response can get as elaborate as identifying what days of the week a member can have a service performed and where, the number of benefits they are allowed to have and how many of them they have remaining, whether the benefit conditions apply to "in" or "out" of network, etc. Anything that is identified as situational in the 271 could possibly be returned; this is the super set. The Implementation Guide states that receivers of the 271 transaction JULY 2018 15

need to design their system to receive all of the data segments and data elements identified as used or situational, and account for the number of times a data segment can repeat. This allows the Information Source the flexibility to send back relevant information without the receiver having to reprogram their system for each different Information Source. To: The ASC X12N TR3 for the Health Care Eligibility Benefit Inquiry and Response 270/271 transaction set contains a super set of segments, elements and codes which represent its full functionality. This super set covers a great number of business scenarios and does not necessarily represent the business needs of an individual provider, payer or other trading partner involved in the use of the 270/271. The super set identifies the framework an information source (typically a payer) can utilize. This TR3 also identifies the minimum an information source or clearinghouse is required to support in order to offer an implementation-compliant 270/271 transaction. The various options to identify a patient can be found in Section 1.4.9 - Search Options. The 271 transaction is designed to report a great deal more than whether the patient is eligible or not. Some of the items that can be returned if the conditions apply are: copayment, co-insurance, deductible amounts, plan beginning and ending dates (allowing for dates other than the current date) and information about the primary care provider. Additionally, specific service types and their related information can also be returned. The 271 response can get as elaborate as identifying what days of the week a member can have a service performed and where, the number of benefits they are allowed to have and how many of them they have remaining, whether the benefit conditions apply to "in" or "out" of network, etc. Anything that is identified as situational in the 271 could possibly be returned; this is the super set. The TR3 states that receivers of the 271 transaction need to design their system to receive all of the segments and data elements identified as used or situational, and account for the number of times a segment and data element can repeat. This allows the information source the flexibility to send back relevant information without the receiver having to reprogram their system for each different information source. Just as the 271 response can be as elaborate as the information source wishes to return, the 270 request can also be very explicit. A provider could send a 270 request to ask whether a particular patient is eligible for a particular procedure with a particular diagnosis code, identify who the provider of the service will be and even to identify when and where the requested service will be performed. An information source is not required to generate an explicit response to an explicit request (beyond those identified below in JULY 2018 16

Section 1.4.8.2-271 Minimum Requirements) if their system is not capable of handling such requests. The more information an information source can provide the information receiver regarding specific questions, the more both parties will be able to reduce phone calls and long interruptions. Willing trading partners are allowed to use any portion or all of the 270/271 super set so long as they support the minimum data set, but are not allowed to add to or change the 270/271 super set in order to remain compliant with this TR3. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.8.1 270 Minimum Requirements for TR3 Compliance, Add New Paragraphs 1 and 2 From: (empty) To: Many of the Health Care Service Type Codes have, in the past, been considered both Health Benefit Plan Coverage Types and service types. To reduce confusion, Health Benefit Plan Coverage Type codes have been added to the Health Care Service Type Code external code set. These Health Benefit Plan Coverage Type codes must not be used to reflect service or benefit details. To request eligibility or benefits for all Health Benefit Plan Coverage Types associated to the patient on the 270, the submitter should send a Health Benefit Plan Coverage Request for Eligibility or General Benefit Request for Eligibility. The applicable responses that are minimally required to be returned are outlined in the sections below and the 270/271 Eligibility and Benefit Information Technical Report Type 2 associated with this TR3. This rule applies to any new Health Care Service Type Codes that have the word `Coverage' in the description. Often, these can be interchangeably used with the word Plan Coverage, Plan Coverage Type, Coverage Type or simply Plan. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage JULY 2018 17

Action Modify Chapter 1 Front Matter section, in 1.4.8.1 270 Minimum Requirements for TR3 Compliance, Modify Paragraph (becomes New Paragraph 3) From: This version of the 270/271 Transaction uses the external Service Type code list (See Appendix A Code Source 958). This list builds on the Service Type Code list used in previous versions of the transaction and allows for routine maintenance without having to wait for a new version of the transaction to use new Service Type codes. This list can be updated 3 times per year, and Information Sources must use the current version of the list in conjunction with this version of the 270/271 transaction. To: This version of the 270/271 Health Care Eligibility and Benefit Inquiry and Response uses the external Health Care Service Type Code list (See Appendix A Code Source 958). This list builds on the Health Care Service Type Code list used in previous versions of the transaction and allows for routine maintenance without having to wait for a new version of the transaction to use new Health Care Service Type Codes. X12 Code Maintenance Groups maintain the Health Care Service Type Codes. More information about these code lists and the maintenance process is available at http://www.x12.org /codes/. Information sources must use the current version of the list in conjunction with this version of the 270/271 transaction. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.8.1.1 Health Benefit Plan Coverage Request for Eligibility, Modify Paragraph From: An Information Source must support a Health Benefit Plan Coverage Request for Eligibility (referred to as the generic request for Eligibility in 005010X279). This is accomplished by responding to a Service Type code "30" (Health Benefit Plan Coverage) when sent in the EQ loop of the 270 transaction as described in Section 1.4.8.2.8. No other Service Type codes may be submitted when Service Type code "30" is submitted. To: An information source must support a Health Benefit Plan Coverage Request JULY 2018 18

for Eligibility. This is accomplished by submitting the Health Care Service Type Code defined in the Code Value Usage in Eligibility Benefit Inquiry and Subsequent Response Technical Report Type 2 for this purpose. No other Health Care Service Type Code(s) may be submitted with a Health Benefit Plan Coverage Request for Eligibility. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Modify Section 1.4.8.1.2 General Benefits Request for Eligibility: From: An Information Source must support a General Benefits Request for Eligibility. This is accomplished by responding to a Service Type code "60" (General Benefits) when sent in the EQ loop of the 270 transaction as described in Section 1.4.8.2.9. The General Benefits Request for Eligibility is used when an Information Receiver only wishes to determine Plan level information, not the associated benefits. No other Service Type codes may be submitted when Service Type code "60" is submitted. To: An information source must support a General Benefits Request for Eligibility. This is accomplished by submitting the Health Care Service Type Code defined in the Code Value Usage in Eligibility Benefit Inquiry and Subsequent Response Technical Report Type 2 for this purpose. No other Health Care Service Type Code(s) may be submitted with a General Benefits Request for Eligibility. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.8.1.3 Explicit Request for Eligibility, Renumber Title, Modify Paragraph 1, Add New Paragraph 2 From: 1.4.8.1.4 Explicit Request for Eligibility JULY 2018 19

To: 1.4.8.1.3 Explicit Request for Eligibility From: An Information Source must support an Explicit Request for Eligibility. This is accomplished by responding to any of the codes listed in the General Benefits Request for Eligibility, Health Benefit Plan Coverage Request for Eligibility, or Component Level Benefits Requests for Eligibility, when sent in the EQ loop of the 270 transaction as described in Section 1.4.8.2.11. An Information Source must support a minimum of 10 occurrences unique Service Type codes per patient request sent in the "EQ" loop(s) of the transaction (regardless of the usage of the repeating data element) and responses for each of the Service Type codes must be supported. An Information Source may support more than 10 unique Service Type codes at their discretion. To: An information source must support an Explicit Request for Eligibility from an information receiver. An Explicit Request for Eligibility is accomplished by sending any of the codes in the Health Care Service Type Code list other than those defined in section 1.4.8.1.1 - Health Benefit Plan Coverage Request for Eligibility or 1.4.8.1.2 - General Benefits Request for Eligibility above. Section 1.4.8.2.10 - Response to an Explicit Request for Eligibility of this TR3 identifies what must be returned for an Explicit Request for Eligibility. An information receiver is not permitted to request a particular Health Care Service Type Code more than once in a single patient 270 eligibility request. This rule applies regardless of the usage of the 2110C Subscriber or 2110D Dependent Eligibility or Benefit Inquiry EQ01 repeating data element or within multiple 2110C Subscriber or 2110D Dependent Eligibility or Benefit Inquiry EQ segments. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.8.1.3 Component Level Benefits Request for Eligibility, Delete Paragraph From: Each of the 11 mandated Service Type codes identified in Section 1.4.8.2.8 ("1", "5", "33", "35", "47", "86", "88", "98", "AL", "MH" or "UC") can be broken into the components listed later in this section. Information Receivers can now JULY 2018 20

send a 270 request with one of the 11 Service Type codes that are mandated to be returned in a 271 response as identified in Section 1.4.8.1.3 Component Level Benefits Request for Eligibility. This will allow the information receiver to receive more detailed relevant information. To: (deleted) CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Add Chapter 1 Front Matter section, in 1.4.8.1.4 Request Date(s) on the 270, Add New Section Title and Re-Number From: 1.4.8.1.5 Plan Dates To: 1.4.8.1.4 Request Date(s) on the 270 Front Matter section, in 1.4.8.1.4 Request Date(s) on the 270, Add New Subsection From: (empty) To: 1.4.8.1.4.1 Request Dates CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Add Chapter 1 Front Matter section, in 1.4.8.1.4.1 Request Dates, Add New Paragraphs The 270 transaction may include a date or date range to represent the date(s) JULY 2018 21

for which the information receiver would like to receive eligibility, plan, and benefit information. If no date is included, then the current processing date of the transaction is to be used. The request date or date range on the 270 transaction must be accompanied by the 2100C Subscriber or 2100D Dependent Date DTP01 date qualifier of `881' (Request). Only one request date (DTP01 = `881') or date range is allowed to be submitted per 270 request. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Add Chapter 1 Front Matter section, in 1.4.8.1.4.2 Eligibility Data Availability Timeframe, Add New Sub-Section 1.4.8.1.4.2 Eligibility Data Availability Timeframe The information source must, at a minimum, support an eligibility data availability timeframe that includes: Single date or date range inquiries that extend: o Up to the end of the current month AND o Up to 12 months in the past or up to the applicable Payer's Timely Filing Requirements, whichever is greater The information source may require submitters to divide an eligibility request that exceeds a date range span of 12 months into multiple 270 requests to allow expeditious processing of the 271 response. The information source may need to return an AAA segment with an AAA05 code value that represents the need to split. If the 270 inquiry contains a request date or date range that falls outside of the information source's supported Eligibility Data Availability Timeframe, the information source is encouraged to return a 271 2100C Subscriber or 2100D Dependent AAA (Request Validation) error with the appropriate AAA05 as defined in the Code Value Usage in Eligibility Benefit Inquiry and Subsequent Response Technical Report Type 2. This error and eligibility/benefits may be returned together, at the payer's discretion, if a portion of the date range can be supported and a portion of the date range cannot be supported due to the fact that a portion of the date range falls outside of the eligibility data JULY 2018 22

availability timeframe. For additional information on using the AAA segments with Eligibility and Benefit Information, see Section 1.4.11 - Transaction Validation -Rejections and Errors. CR 1611 A single CR to house all of the various front matter updates is required to consolidate the front matter changes that may remain in the TR3. This CR will not accommodate the front matter changes that will be moved to the TR2. That CR is 1576. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Modify paragraph 1 in Section 1.4.8.2 271 Minimum Requirements From: This version of the Implementation Guide builds on the requirements established in 005010X279 accommodating the different Service Type code requests identified in section 1.4.8.1 and the addition of requirements for returning the Patient's Portion of Financial Responsibility. An information source must respond at a minimum with the required portions of this section or as required in Section 1.4.11 - Transaction Validation - Rejections and Errors. To: This version of the TR3 builds on the requirements established in 005010X279 and all associated Errata accommodating the different Health Care Service Type Code requests identified in Section 1.4.8.1-270 Minimum Requirements and the addition of requirements for returning the patient's portion of financial responsibility. An information source must respond at a minimum with the required portions of this section or as required in Section 1.4.11 - Transaction Validation - Rejections and Errors. CR 1292 To improve 270/271 system integrity, speed, and detail while protecting data privacy, payers need to have the option to return certain service types only to providers who have a reason or need to see that data. Location X332 Health Care Eligibility/Benefit Inquiry and Information Response 1.4 Business Usage Action Modify Chapter 1 Front Matter section, in 1.4.8.2 271 Minimum Requirements for TR3 Compliance, Delete Paragraph 2/Replace with New Paragraphs 2, 3 From: If the individual is located in the information source's system, the following must be returned: JULY 2018 23