WISeR Model 

November WISeR Updates: Performance Reports, Documentation Insights, and Coding Details

Starting this month, Virtix Health will begin sharing Quarterly Performance Reports with Washington State WISeR providers as part of our ongoing commitment to transparency and continuous improvement. The first report is designed to offer meaningful insights into your results and identify opportunities for improvement. Reports include both prior authorization requests and prepayment review claims.

Here are four things you need to know:

1. Who receives a report: Providers who submitted at least 10 prior authorization requests and/or prepayment review claims during the quarter.
2. What you’ll see: An “At a Glance” summary of your combined prior authorization and prepayment review activity, along with your affirmation rates by procedure. If your affirmation rate on any procedure is below 75%, your report will also include a second page listing your most common flagged reasons and the procedures that were most challenging. This second page is intended to support provider education.
3. Where to look: Reports will be sent from wiser.support@virtixhealth.com. If you don’t see yours, please check your spam or junk folder.
4. About Gold Card status: This report reflects Q3 2026 results only and does not change your Gold Card status. Gold Card eligibility is determined separately, using the review period and criteria published on the WISeR Gold Card webpage.

Clinical Insights

 Over the past few months managing the WISeR initiative for Washington State, our Virtix Health team has noticed recurring documentation and coding challenges. Addressing these issues can help streamline the approval process and improve patient outcomes. To support you, we’ve compiled some best practices to strengthen your clinical documentation and coding/order details, and help you meet coverage criteria with confidence:

Clinical Documentation

• Submit focused and relevant documentation: Include only records that directly support the specific service you are requesting. Avoid sending all available records or unrelated historical information, as this does not strengthen your request and may slow down the review process.
• Ensure documentation is current and accurate: Provide up-to-date records reflecting the beneficiary’s current clinical status, including recent physical examinations when applicable. Clearly separate current findings from past history and distinguish between planned treatments and those already completed.
• Match your request to your documentation: The procedure and diagnosis codes you enter must align with the documentation you provide. Requests supported by records for unrelated treatments or outdated plans may be non-affirmed (which is not a denial of care), but you may resubmit the request within 120 days of the initial determination.
• Refer to relevant coverage policies: Each service is governed by specific National or Local Coverage Determinations (NCDs or LCDs). Review these policies to ensure your documentation meets all required criteria for the service you are requesting. For example:
  • Epidural steroid injections: The LCD looks at conservative therapy, which it describes as a combination of medication and other interventions, such as physical therapy or a home exercise program, tailored to the patient. It also looks at the response to any prior injections.
  • Percutaneous vertebral augmentation (kyphoplasty and vertebroplasty) for osteoporotic vertebral compression fractures: The LCD looks at the timing of symptom onset, advanced imaging that documents the fracture, and pain severity despite non-surgical management.

Coding and Order Details

• Include complete coding information: Requests must contain the correct procedure code, modifiers, and units needed to identify the service. Incomplete or missing coding leads to automatic dismissal without a review for medical necessity. You may submit a new request with complete information. 

• For hypoglossal nerve stimulation (HGNS): Submit only the single implantation code that matches the planned device and configuration, rather than multiple codes for different configurations.