Many, many years ago, we created a module in VistaBase, our internal workflow application, that allows us to scrub the billing review report against a list of validation rules for the purpose of easily identifying and fixing errors before transmitting claims. Instead of splitting up the report and asking multiple staff to review each claim manually for "stuff that is wrong," we run the report through our validations engine, a database of hundreds of custom rules, and get a much shorter list of ... wrong stuff.  One biller can usually resolve it very quickly, and our denial rates are much improved since.

Hooray for us, right?

Word got out … because we talked about it all the time.  We did not have a very good response, however, when clients inevitably gasped, "AAAAAAWESOME ... how do I do that?"  VistaBase is not something we designed to survive outside in the cruel, cruel world.

But if you know us, you know we love little hacks that make the workday easier.  And so, we decided that we could build a scaled down version in Excel, an application accessible by nearly everyone on the planet.

We built it, and then we promptly put it on a shelf and forgot about it.

Flash forward to last month.  Andrea had another one of many conversations with clients frustrated by denials for "fixable stuff" ... missing KX modifiers for example.  Miraculously, she also remembered we once built a tool that anyone could use to find said fixable stuff.  We decided we would strip it down, update it, and share it. For free.

​Introducing BTValLite, a macro-enabled Excel workbook that scrubs the billing review report and identifies the Medicare claims that require, but do not have, a KX modifier.  For now, we will just call it a KX Modifier Thingamajig.

​Here is how to use it:

• Watch the video tutorial.
• Complete the form below and follow the instructions to download the application.
• Save the downloaded file on your computer, and unzip it.
• Watch the video tutorial again.
• Open the Excel workbook named BTValLite.
• Before the next claims transmission, download and save the billing review report in the appropriate folder (seriously, watch the video tutorial).
• Click “Run Validations” button.
• Experience glee.

A few noteworthy points ...
​

• This free tool scans Medicare claims for missing KX modifiers.
• It is compatible with billing systems that rhyme with Trite Bee.

If you are interested in a similar tool compatible with a different billing system, email us at info@miravistallc.com.  If we get enough interest, we will build it.  Likewise, if you want to add additional scrubbing rules to the tool, give us a shout.   

MiraVista engaged CMS to revise a recently proposed automated audit (1) that would have recovered every DME claim that overlapped a patient’s hospice stay.  CMS originally posted the proposed audit on August 7, 2018 with the following description: “All DME billed after the admit date of a beneficiary to hospice services and before the discharge date of a beneficiary from hospice services, will be denied as inclusive to hospice services unless there is a GW modifier present indicating DME is not related to the hospice diagnosis.”

The GW modifier, however, is unfamiliar to most DME suppliers because there is no guidance for using it in the DME claim setting.

CMS cited the following resources in support of the audit:

• 42 Code of Federal Regulations, Section 418.202 (f).
• CMS Pub. 100-2, Medicare Benefit Policy Manual, Chapter 9, Section 10.
• CMS Pub. 100-4, Medicare Claims Processing Manual, Chapter 20, Section 10.2.
• CMS Pub. 100-4, Medicare Claims Processing Manual, Chapter 11, Sections 10, 30.3, and 40.2.

Only one of these resources, Chapter 11 of the Claims Processing Manual, mentions the GW modifier.  Though it appears eight times throughout the 65-page document, every iteration limits the use to A/B MAC claim processing.  Section 40.2, for example, states “For beneficiaries enrolled in hospice, A/B MACs (B) shall deny any services on professional claim [sic] that are submitted without either the GV or GW modifier.”  Notably absent from this directive is a reference to the DME MACs.

The DME MAC is mentioned once, but does not invoke the GW modifier; the manual states “A/B MACs (A) and (B) or DME MACs, shall deny claims for all other services related to the terminal illness furnished by individuals or entities other than the designated attending physician, who may be a nurse practitioner. Such claims include bills for any DME, supplies or independently practicing speech-language pathologists or physical therapists that are related to the terminal condition. These services are included in the hospice rate and paid through the institutional claim.”

The DME MACs consistently review claims that overlap hospice admissions and deny when the DME claim diagnoses appear to be related to the terminal diagnosis.

After CMS approved the audit without modification, MiraVista raised the issue with Performant, the Region 5 RAC contractor, to prevent unnecessary recoupments and supplier appeals. After multiple productive conversations, the RAC contractor modified the audit description to decrease the importance of the GW modifier and increase the importance of the diagnosis codes for this audit:  

09/24/2018 Revised Description Issue 0114: “All DME billed after the admit date of a patient to Hospice services and before the discharge date of a patient from Hospice services, will be denied as inclusive to Hospice services when the principal diagnosis of the Hospice claim is similar (same first three characters) to the DME claim and the GW modifier is not present on the DME claim giving indication that the DME is related to the Hospice patient’s terminal condition. Affected codes: See Appendix D of the downloadable Excel file.”

The audit description was modified again on October 1, 2018:

10/01/2018 Revised Description Issue 0114: “All DME billed after the admit date of a patient to Hospice services and before the discharge date of a patient from Hospice services, will be denied as inclusive to Hospice services if after comparing principal diagnoses, the DME claim is related to the Hospice diagnosis. This review also excludes claims with the GW modifier. Affected codes: See Appendix D of the downloadable Excel file.”

Due to the substantive edits made by Performant, DME suppliers should not expect mass recoupments.  In the coming days, however, we expect the RAC to finalize the description of this audit and completely remove references to the GW modifier.  MiraVista has not yet determined if the language regarding the comparison of principal diagnoses will change.  As a general matter, however, the first three characters of an ICD-10 code relate to a very broad diagnosis category, or general type of injury or disease. The DME MACs presently leverage the first three characters of the ICD-10 code in their editing process.  As a result, we expect the RAC to use similar logic, regardless of how it is spelled out in the description.

You can follow approved RAC audit issues and updates to Issue 0114, DME While in Hospice, on the Performant website at https://performantrac.com/audit-regions/region-5/. 

SOURCE LINKS AND FOOTNOTES
https://www.cms.gov/Research-Statistics-Data-and-Systems/Monitoring-Programs/Medicare-FFS-Compliance-Programs/Recovery-Audit-Program/Approved-RAC-Topics-Items/0112-DME-while-in-Hospice.html
https://performantrac.com/audit-regions/region-5/
(1) Automated reviews do not require medical documentation or supplier-involved claim development. The audit decision is based entirely on information that is included with the original claim. 

Medicare is now mailing new ID numbers to beneficiaries. Last week, we posted a short guide to updating billing software with the new Medicare Beneficiary Identifiers (MBI) using payment remittances. Today, we are passing along six tips to familiarize customer service representatives and medical billers with the new cards, ID numbers, and transition process.
 
1. Just like with the old HICN, the hyphens in the MBI are for illustration only.
 
Do not include hyphens or spaces when filing claims or performing eligibility checks.
 
2. The MBI uses numbers 0-9 and all uppercase letters except for S, L, O, B, I, and Z.
 
No Medicare card will ever use these six excluded letters. CMS omitted them to avoid confusion (e.g. between “0” and “O”, “5” and “S”, “8” and “B”, etc.).
 
3. The card and identification number are not permanent.
 
CMS can change an individual’s MBI if, for example, an existing identifier is compromised. Beneficiaries and their authorized representatives can also request a new MBI.
 
Suppliers will receive the response “Invalid Member ID” in real-time eligibility inquiries when using expired or deactivated MBIs. Fortunately, suppliers can use the Noridian Medicare Portal (NMP) and the myCGS portals to search for MBIs. The lookup will only return an MBI if CMS has officially mailed the new card to the recipient. To secure the MBI, the supplier must enter a correct HICN, first name, last name, and date of birth. If available, the tool returns a cross-walked MBI assigned to the beneficiary.
 
4. Some of the new cards have a square QR code, but there is no application for supplier use.
 
The mailing contractor uses the machine-readable codes for delivery purposes. Unfortunately, suppliers cannot use them for checking eligibility or any other purposes. Railroad Retirement Board (RRB) Medicare cards will have the QR code on the front of the card, while traditional Medicare cards have the QR code on the back. Regardless of presence or placement, these are official Medicare cards.
 
5. Beneficiaries enrolled in Medicare Advantage and Prescription Drug plans will also get new Medicare cards, but the new card does not change the beneficiary’s enrollment status.
 
For DME claim filing purposes, suppliers must utilize the distinct policy numbers issued by the Advantage and Drug plans, not the MBI on the new Medicare card.
 
6. The MACs have helpful tools to assist with the transition.   
 
Noridian created a helpful MBI dedicated landing page with relevant details on the MBI transition. The site details information about the transition period, MBI format, preparation and implementation.
 
CGS created a telephone MBI converter tool to help suppliers in Jurisdictions B and C enter the new IDs during an IVR inquiry. Noridian provides a similar IVR Conversion Tool on their website for suppliers located in Jurisdictions A and D. Simply enter the 11-digit MBI into the box and click “Convert my MBI”. The system will return the proper keypad entries to convey the identifier to the IVR.

Note the conversion tool does not validate the MBI or confirm eligibility for Medicare. It simply converts the identifier for easier telephone keypad entry. Some suppliers convert the MBI as a part of the intake process and screen print the converted characters to the patient’s file for future calls. 

SOURCE LINKS
https://www.cms.gov/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNmattersArticles/downloads/SE18006.pdf
https://www.cms.gov/Medicare/New-Medicare-Card/index.html
​

​CMS is currently mailing new Medicare cards to beneficiaries. Depending on what state you call home, you may have already seen them in the wild.

The Medicare Access and CHIP Reauthorization Act of 2015 requires CMS to remove Social Security Numbers from all Medicare cards by April 2019. The new Medicare cards feature a randomly-generated Medicare Beneficiary Identifier (MBI) to replace the Social-Security-Number-based Health Insurance Claim Number (HICN). The change impacts nearly 60 million beneficiaries.

During the 21-month transition period that began April 1, 2018, CMS will accept either the HICN or the MBI for claims and eligibility transactions. Suppliers should, however, proactively update billing software with their customers’ new MBIs to avoid delayed claims processing.

Alert your payment posters.

Once CMS assigns an MBI to a beneficiary, it will provide the new identifier to suppliers on every Medicare Remittance notice where the supplier billed using the old HICN. As such, suppliers can use remittances to update applicable patient records. Alert payment posters to watch for these updates and escalate accordingly.

​The remittance will include the beneficiary’s MBI in the same segment that reports changed HICNs: 835 Loop 2100, Segment NM1 (Corrected Patient/Insured Name), Field NM109 (Identification Code).

​See Remittance Advice Example.

For claims filed with the MBI, the corresponding remittance’s changed HICN field will be blank so payment posters can quickly scan remittances to identify patients with new information. Check with your software vendor to determine if the billing application will automatically update patient records with MBIs scraped from electronic remittances.

To engage customers, consider posting notices requesting MBIs on patient invoices and throughout supplier location(s). CSRs should ask the customer if they have received a new MBI during every resupply engagement.

​Use of the correct identifier is essential to expedited claim payment. Cross-referencing during the claim adjudication process will impose a delay.

SOURCE LINKS
https://www.cms.gov/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNmattersArticles/downloads/SE18006.pdf
https://www.cms.gov/Medicare/New-Medicare-Card/index.html
​