In a Realtime environment, is it allowable for an Information Source to return a 271 with multiple 2000C loops for the same subscriber when their member ID is tied to multiple coverages -- for example, the member ID for the subscriber is linked to more than one group number and each group has different plan begin dates and benefits? In the TR3 Section 1.3.2 Other Usage Limitations, it does specify that in a Realtime environment the 270 transaction can contain only 1 patient request which is defined as either one Subscriber loop or one Dependent loop, but it does not specify 271 as well.
Section 1.4.3 Batch and Real Time in the 005010X279A1 TR3 and errata states the following “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.” By creating a second 2000C loop for the same patient you would be creating more patients than were requested by the provider in the 270 transaction even though they may be the same individual. Receivers of real time 271 transactions would not be expecting multiple 2000C loops and one of the following scenarios would likely occur:
1. The 271 response would actually fail
2. The provider’s system would process the first 2000C loop and ignore the second 2000C loop
3. The provider’s system would process the first 2000C loop and then overwrite that information with the second 2000C loop
It would be highly unlikely that a receiver of a real time 271 transaction would process both 2000C loops.
The correct method of returning this type of response would be to identify the appropriate group in an REF segment for each of the 2110C loops returned to distinguish between each group and include the appropriate plan dates in those 2110C loops if they differ from the plan date if sent in the 2100C loop.
The title of this RFI mentions "Realtime 271 Multiple 2100C"; multiple 2100C loops are prohibited by the TR3 in both batch and real time environments.