In a 270 inquiry for a dependent, is it a violation to send both Loop 2100C (Subscriber Name) DTP*291 (Plan) and 2100D (Dependent Name) DTP*291? This does not seem to be explicitly prohibited in the situational rule. If this is not a violation, then how should the information source (payer) process an inquiry where those two DTP03 values differ? That would seem to be an ambiguous inquiry where it is not clear which date the information receiver (provider) is asking about.
RFIs #918 and #2049 seem to have some bearing on this question but do not directly answer it.
As a clearinghouse, we want to ensure we only pass on valid 270s to payers.
In a real-time request/response scenario, the definition of a patient request is, per Section 1.4.2 Basic Concepts:
“Patient Request (2110C or 2110D)
The patient request 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.”
Additionally, the situational rule on the 2100C DTP states: “Required when the information receiver wishes to convey the plan date(s) for the subscriber in relation to the eligibility/benefit inquiry.” As the RFI description and business scenario above do not advise if more than one patient request was sent on the 270, this response assumes the 2110D EQ is the only patient request sent on the 270. This then means that the 270 is not a request for the subscriber’s eligibility/benefits, but the dependent’s and thus the DTP and other values tied to the 2100D, and 2110D patient request EQ would be consumed.
The following simplified view of the transaction defining where the patient request would be seen (where the EQ is contained) is outlined below. The DTP in the 2100 loop level carrying the nested EQ segment would indicate what other content should be used to process the inquiry from that higher loop level. There are 3 scenarios below. Each has one or more EQ. The EQ(s) will indicate where the patient request is, and thus what other segments to use. (See examples 1 and 2 below.)
More than one patient request may be sent in a 270, defined as a batch inquiry. In this batch scenario, each patient request would be treated separately, and the associated details in the loops that correspond to the nested EQ would be used, such as the DTP in the 2100C when there’s an EQ in the 2110C along with a DTP in the 2100D when there’s an EQ in the 2110D. (See example 3 below, with 2 patient requests, one at each of the subscriber and dependent levels.)
1. Real time and includes 1 patient request at the subscriber level
HL*3
NM1
DTP
EQ
EQ
EQ
2. Real time and includes 1 patient request at the dependent level
HL*3
NM1
DTP
HL*4
NM1
DTP
EQ
EQ
3. Batch and includes 2 patient requests, one at each of the subscriber and dependent levels
HL*3
NM1
DTP
EQ
EQ
EQ
DTP
HL*4
NM1
DTP
EQ
EQ
EQ
DTP
The situational rule does allow for the DTP to be sent by way of the “if not required by this implementation guide, may be sent at the sender’s discretion but cannot be required by the receiver.” Therefore, the 270 must not be rejected if the DTP is sent at the loop level that does not contain the corresponding EQ. The 270 itself with a DTP at both the 2100C and 2100D levels is valid; it just may lead to interpretation issues by receivers of the 270.