7030 Review and Position Paper

  • 7 Jan 2019 5:03 PM
    Reply # 6988190 on 6947012
    Kathy J.

    I agree with Contract ID position and think it can be now added as supporting narrative to our position paper. 

  • 7 Jan 2019 4:56 PM
    Reply # 6988183 on 6947012
    Kathy J,

    Besides the severe error code addition in 7030, how does 5010 support the search criteria patient ID, last name, first name and birthdate requirements today? 

  • 2 Jan 2019 1:54 PM
    Reply # 6980428 on 6947012
    Shelbie Yount/Toni Moody

    The "7030 Task Group Overview of Changes Relevant to the Dental Community" document  should include mention of "Fee Schedule ID/Plan ID" as part what is to come. Kevin Moore has noted: "2110D the REF segment is adding an element code value AFT- in the 271 trn adding element code value. The identifier will be included." and as a provider this is something we would value and find beneficial.

     

  • 2 Jan 2019 1:39 PM
    Reply # 6980400 on 6947012
    Shelbie Yount/Toni Moody

    In the "7030 Task Group Overview of Changes Relevant to the Dental Community" document, we did not notice a discussion point related to 'Prescription Drugs'. Is this part of 7030? We reviewed the 5010 guide and do not see where STC 89,90,71,92 is present for 01~EQ*35 (i.e. Dental)…  In the future we would like to see dental payers communicate prescription drug coverage in their 271. 

  • 2 Jan 2019 1:10 PM
    Reply # 6980366 on 6947012
    Shelbie Yount/Toni Moody

    In regards to 'Contract ID' from a Provider's perspective, this is not necessary and removing it in 7030 is not a concern. In our opinion, not every provider will want to or be able to provide 'Contract ID'. For example, our 270 does not get to the level of specificity to know provider contract or participation status or network/negotiated schedule agreement.  We identify ourselves in a 270 as a 'non-person' entity and provide the Practice Name, TIN and NPI.

  • 18 Dec 2018 2:05 PM
    Reply # 6965456 on 6947012
    Anonymous

    Cascading search

    Cascading search is an approach to matching the member in the request to the member in the payer’s system. Matching logic must be sophisticated enough to allow flexibility in using a mix of identifying data, so that providers can retrieve information even though they might not have consistent sets of identification for all patients. The four pieces of identifying data are member ID, first name, last name, and date of birth, and payers must be able to match using member ID and two other pieces of data. Alternative logic can be used to match on first name, last name, and date of birth.  Version 7030 differentiates between informational errors and severe errors. An error code can be included in a full eligibility and benefit response as information to the provider indicating, for example, that the member ID was not found. A severe error is one where a match could not be found and the payer will not return the full eligibility and benefit response.

    Cascading search employs iterations of search criteria. Payers must make multiple attempts to match a request containing member ID, first name, last name, and date of birth. Version 7030 outlines the recommended logical steps, though payers may customize the order in which the searches are performed. The payer would first search for matches in their database for only the member ID and date of birth. If no matches or multiple matches are found, a second attempt would be made with member ID, date of birth, and last name. And so on. A variation on the search could be, for example, trying the first three letters of the first name. Version 7030 also outlines what search steps must be taken if the request contains member ID, last name and date of birth, or member ID, first name and last name.

  • 5 Dec 2018 9:53 AM
    Message # 6947012
    Deleted user

    This forum will be used to discuss the 7030 changes and create a first draft of the NDEDIC position statement regarding said changes. 

    1 file
Powered by Wild Apricot Membership Software