7030 Review and Position Paper

<< First  < Prev   1   2   Next >  Last >> 
  • 9 Jul 2019 9:59 PM
    Reply # 7772924 on 6980400

    This really is the first time I frequented your site web page and thus much? I surprised cyberlink media suite 16 coupon with the research you created to create this distinct publish extraordinary. Amazing job!

  • 22 Apr 2019 8:04 PM
    Reply # 7298728 on 6947012
    Madeline Moran
    Todays' most enhancing field is the Information Technology and millions of people are studying and doing many jobs in thus field. I am also an IT student and I know a lot of things about it and the top essay writing reviews are the most amazing website for writing hottest essays and articles in the English language. All of my friends are studying in this field and we have to read many computer science subjects in that.
  • 12 Mar 2019 12:29 PM
    Reply # 7215466 on 6947012
    Kathy Jonzzon

    Discussion on considering E & B Formularies similar to the Pharmacy Industry.  Please use this link for an example of a formulary document:



  • 15 Jan 2019 1:37 PM
    Reply # 7003189 on 6947012

    Subscriber Dates

    Version 7030 adds explanation regarding plan coverage dates. In version 5010, the descriptions on the codes for subscriber dates were open to interpretation: 291 for Plan, 346 and 347 for Plan Begin and Plan End, 356 and 357 for Eligibility Begin and Eligibility End. Explanation has been added for how to use the codes and the new structure of the 271 transaction has more flexibility for cases where multiple plans apply, inactive periods, suspension of coverage, and grace periods. In straightforward cases, payers will continue to send information the subscriber’s current eligibility period (it explicitly says the subscriber’s initial coverage effective date is not needed) and benefit year start and end dates. It also says that if the end date is not known, to send the beginning date and no end date. Dummy dates are not allowed.

    Last modified: 15 Jan 2019 1:37 PM | Kevin Moore
  • 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

    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.

<< First  < Prev   1   2   Next >  Last >> 
Powered by Wild Apricot Membership Software