Section title: Requests for Interpretation
RFI #
2503
Recommended way to return 271 from multiple sources in real-time transaction
Description

We are consolidating two health plans.  Consolidation of payer brands, payer trading partner ID, EDI intake applications and sources of eligibility response will take many years.  In the interim, we know we will have members that will have eligibility and benefits in both plans and source systems.  We are able to direct an inbound 270 request received by either payer/EDI intake application to both back-end source systems; we are working to determine best way in which to communicate multiple eligibility responses in a 271 response to a 270 real-time request when multiple responses are present.

Scenario

1. Submitter sends 270 real-time request for one individual
2. Plan receives 270 request and sends requests to two internal source systems
3. Member is found as active in both source systems and 271 response is generated from both source systems
4. Both source system responses to be sent to requester

Option 1:
Respond with two Information Source loops (2000A), each Information Source Loop containing response from one of the source systems.  271 response structure would be:

Information Source (Loop 2000A) – Source System A
   Information Receiver (Loop 2000B)
      Subscriber (Loop 2000C) – Source System A
         Eligibility or Benefit Information – Source System A
Information Source (Loop 2000A) – Source System B
   Information Receiver (Loop 2000B)
      Subscriber (Loop 2000C) – Source System B
         Eligibility or Benefit Information – Source System B

Option 2:
Respond with one Information Source loop (2000A) and multiple subscriber loops.  Use Loop 2115C SUBSCRIBER ELIGIBILITY OR BENEFIT ADDITIONAL INFORMATION to identify source system/payer for second subscriber response.  271 response structure would be:

Information Source (Loop 2000A) - plan to which submitted
   Information Receiver (Loop 2000B) - plan to which submitted
      Subscriber (Loop 2000C & 2100C) - plan to which submitted
         Eligibility or Benefit Information (Loop 2110C) - plan to which submitted
      Subscriber (Loop 2000C & 2100C) – Second source plan
         Eligibility or Benefit Information (Loop 2110C) – Second source plan (EB*R segment)
Subscriber Eligibility or Benefit Additional Information (Loop 2115C) – Second source plan
     Subscriber Benefit Related Entity Name (Loop 2120C) – Second source plan information

RFI Response

Your option 2 is the more appropriate response with two tweaks: you would return one 2000C loop with the member identification and eligibility/benefits that belong to the member submitted on the 270; you do not need to return the 2115C loop as that loop only contains one segment, the III segment; the LS is not part of the 2115C.
More specifically, the following paragraphs: 1.4.3 Exceeding The Number of Patient Requests and 1.4.7.1 Minimum Requirements for Implementation Guide Compliance – 271 - Item 6 state:
“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.2 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 2100C EQ03 and this level of functionality is supported by the Information Source.” 
and
“6.  Other payers or plans if known in 2120C/D. (Note: Do not return details of coverage or benefits associated with other payers or plans, the Information Receiver should initiate a separate 270 request to the other payer or plan to determine the level of coverage.)”  
As clarified by the submitter, the two source systems have different member identification numbers.  The identification number submitted in the 2100C NM109 would be the primary identification number used to locate the eligibility and benefits returned in the 2110C/D EBs and the “other” member identification belonging to the “other” source system would be provided in a 271 2120C/D NM1 with NM101 = IL (Insured or Subscriber), NM108 = MI (Member Identification Number) and NM109 of the second source systems assignment member identification number. 
In that same 271 response, an additional 2120 C/D NM1 would also contain the “other” source system information, using one of the NM101 code values, such as PR (Payer), PRP (Primary Payer), SEP (Secondary Payer), TTP (Tertiary Payer) and that payer’s “identifier” for the trading partner ID in NM109, (potentially with NM108 = 46 (Electronic Transmitter Identification Number) or NM108 = PI (Payor Identification))
It is not compliant with this TR3 to return two different systems’ information with different subscriber IDs in a single 271 using the repeating 2000C/D when (1) in real-time and (2) only one member identification number was submitted on the 270, and (3) the EQ03 did not contain “FAM” (please note the usage requirement of FAM on EQ03).

DOCUMENT ID
005010X279A1