Recently, a trading partner submitted an issue to our helpdesk complaining that our 271 Response was not properly formatted because it contains multiple 2000C Loops. They cited RFI’s 1651 and 1785 as supporting evidence of their concern.
I would like to respectfully request a review of the aforementioned RFI’s for accuracy and request an amendment based on the following additional information. RFI 1651 references the authors’ intent to limit Real-time interactions to single requests. We suggest that section 1.3.2, paragraph 3 mediates that restriction to allow multiple responses.
I would also refer you to the following pages of the guide for rebuttal of your RFI 1785:
Page 18, Section 1.4.7 - paragraph 3
Furthermore:
Referencing Section 1.4.8.7 (below) – the recommendation is to return a AAA, which is in direct conflict with the guidance provided in RFI 1785.
(Note: additional reference to specific guide text can be provided upon request).
My revised question is:
When is it allowed and/or appropriate to send multiple 2000C Loops in a 271 response to a real-time 270 for a subscriber with two plans?
The TR3 seems to support this in the following sections:
In Section 2.5 Transaction Set Listing (pg. 202) – The repeat of Loop 2000C is shown as >1.
In Section 1.4.7, Page 18, - paragraph 3 – please note the use of quotations in the highlighted section as this was of paramount importance to the author(s).
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 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.
I will add that this implementation has been running successfully for over 17 years, and has processed over 4 million requests per year.
Naturally, our goal is to provide the most useful information that we are able to provide, as efficiently as possible.
he 00510X271A1 TR3 explicitly states that multiple 2000C or 2000D Loops are not allowed when the transaction set is used in a Real Time mode. This is also specifically addressed in RFI #1785.
Section 1.4.3 (Real Time) reads in part:
“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 2110C EQ03 and this level of functionality is supported by the Information Source.”
Regarding section 1.4.8.7, the guidance provided in RFI #1785 addresses the scenario where more than one set of plan benefits is identified with the same member ID when a primary search option was used.