DSMO recommends that in the future the submitter only submit one request per change request. Because the DSMO only records one categorization, and given there were multiple dispositions, it is important to note that some requests have been approved and some disapproved.
*** Business Need #1 Disapproved - This need has already been met. Note 2 of the 004010X098 271 2110 MSG Segment states: "Under no circumstances can an information source use the MSG segment to relay information that can be sent using codified information in existing data elements." Not only does the 271 currently have the capability of identifying multiple PCPs by utilizing the 2120 loop, but the type of PCP can be identified by utilizing the 2120 PRV segment and the Provider Taxonomy Code in PRV03. By utilizing the Taxonomy Code in the 2120, this gives the flexibility of identifying any type of specialty for the PCP, Gateway Provider, Facility or any other provider role as identified in 2120 NM101. The Taxonomy Codes for the specialties identified in this request would be as follows (someof these taxonomy codes have additional sub-specialties as well):208D00000X General Practice207Q00000X Family Practice207R00000X Internal Medicine208000000X Pediatrics207V00000X Obstetrics & Gynecology. ***Business Need #2
A number of these requests are not valid reasons for rejecting the transaction. ***REQUEST: Disapproved.
Loop:2100B –Information Receiver Name Segment: AAA03 Message:1. Service is not allowed for the provider speciality. ***RESPONSE:The appropriate place for this type of rejection would be in 2110C/2110D since that is where the service is identified (the rejection is because of the service requested). Use code 53 – Inquired Benefit Inconsistent with Provider Type.
***REQUEST:
1- Disapproved
2- Disapproved
3- Approved
4- Disapproved
5- Approved
***RESPONSES:
1. You cannot reject the transaction if the member has coverage with your health plan, you must still indicate Active or Inactive coverage. You can indicate that the member has another insurance by using 2110C/D EB01 = R – Other or Additional Payer, and you can even indicate who that other payer is in 2120/C/D NM103 and in NM101 indicate if they are Primary (PRP), Secondary (SEP) or Tertiary (TTP).
2. You should not reject the transaction for Plan Waiting Period. You should indicate Active coverage and use EB03 = 32 – Plan Waiting Period and use the 2110C/D DTP segment to indicate the actual benefit begin date.
3. We will add code 35 – Out of Network to 2100C and 2100D AAA03 with the note Use this code to indicate that the subscriber is not in the Network of the provider identified in the 2100B NM1 segment, or the 2100B/2100C (2100D) PRV segment if present in the 270 transaction.
4. You cannot reject the transaction if the member has coverage with your health plan, you must still indicate Active or Inactive coverage. You can indicate that the member has another insurance by using 2110C/D EB01 = R – Other or Additional Payer, and you can even indicate who that other payer is in 2120/C/D NM103 and in NM101 indicate if they are Primary (PRP), Secondary (SEP) or Tertiary (TTP).
5. Use EB01 = I – Non-covered and identify what was in the request that the subscriber is not covered for.
***REQUEST:
1 – Approved
2 – Approved
3 – Disapproved
4 – Disapproved
5 –Disapproved ***RESPONSES:
1. There is no existing code for AAA03 to reject the transaction for an Incorrect Place of Service. In 004050X0138, the following Reject Reason code and note has been added to AAA03 of 2110C and 2110D” 33 - Input Errors" Use this code only when data is present in this transaction and no other Reject Reason Code is valid for describing the error. Detail of the error must be supplied in the MSG segment of the 2110C loop containing this Reject Reason Code.It is not clear if you are trying to indicate that the Place of Service Code was invalid, or not appropriate. You should make that clear in the MSG segment.
2. In 004050X0138, the following Reject Reason Code has been added to AAA03 of 2110C and 2110D: AF - Invalid/Missing Diagnosis Code(s)
3. Unless you support the Authority to Deduct function (see BHT06 code 36) this would not be a valid rejection of the transaction. Only the Authority to Deduct transaction can indicate usage of an inquired benefit in a 270. Simply making an eligibility inquiry about a service does not equate to using a service (except for the Authority to Deduct). If a benefit has been exhausted (either through an Authority to Deduct or from claims processed), you can use EB01 = I – Non-Covered, EB06 = 30 – Exceeded in conjunction with whatever information you have used from the 270 request (you must return whatever it is you are saying no to).
4. This is not a valid reason for a rejection. Use EB01 = E – Exclusions and identify the exclusions.
5. Same solution as 3 above.