HCFA reports progress on fixing software and billing glitches

2/13/2001 By Karen Lusky, MSN, RN

In a teleconference for industry representatives last week, the Health Care Financing Administration reported on its progress in fixing software and billing glitches. Home health providers have been eagerly awaiting fixes to the problems, which have been contributing to significant cash flow delays under the new prospective payment system. (Click here for details.)

HCFA says it’s making headway on a number of identified problems, as follows:

Suspended RAPs (requests for advanced payment). A fix is in the works for a software problem that has led to suspended RAPs in cases where providers do not submit the final claim within 120 days of the RAP. "In such a case, the HCFA software has been automatically suspending [rather than canceling] the RAP and won't recognize a resubmitted RAP," says Mary St. Pierre, RN, director of regulatory affairs for the National Association for Home Care. Providers have been unable to submit any more claims for patients whose RAPs have been suspended. HCFA reported that Maine Blue cross has fixed the problem and the other FIs are testing a software correction, so the problem should be corrected soon, if the testing proceeds according to plan.

Providers should not resubmit any RAPs or claims for patients whose RAPs have been suspended until the software problem is fixed. "However, if your home health agency has a voluntary RAP cancellation, you can go ahead and resubmit the corrected RAP," St. Pierre reports.

HCFA also advised agencies not to wait until the 119th day to get their RAPs in. "If you get them in on a Friday (day 118) and the FI doesn't process them and that 120th day falls on a Sunday, those claims will be suspended," she says.

User-unfriendly remittance advice forms. Providers have complained about difficulties in deciphering remittance advice forms from FIs under PPS, reports Brian Ellsworth, a home health policy expert with the American Hospital Association. "HCFA is aware of the problem and has agreed to make the RA more user-friendly, so agencies can get to the bottom line of what they are being paid." To simplify the form, HCFA plans to remove the Part A to Part B shift from the RA to make the form look more like the earlier RA forms, adds St. Pierre. The Part A to Part B shift (in terms of which payor is picking up the tab for the services, as mandated by the Balanced Budget Act of 1997) wasn't supposed to affect billing for home health agencies. "But the way the software program was written, that information shows up on the RA, which makes it very hard to read," she explains. "So HCFA is taking that off the form."

Failure to identify overpayments. HCFA's bigger concern was whether the RAs received by home health agencies were accurate. They weren't. The agency uncovered overpayments for noncovered services and instances where Medicare paid although it was actually the secondary payor. "The latter can be the agency's fault, or sometimes the patient doesn't know he or she has primary coverage from another source, such as worker's compensation," explains St. Pierre. As for noncovered services, "agencies were told to put noncovered services on the claim, but the system failed to recognize those [as such]," she says. "HCFA says it is putting hot fixes in on those payment errors for anything that has not yet been paid for the future and working on a process to correct the old errors."

http://www.homehealthprovider.com/content/news/article.asp?DocID={01617A93-01D4-11D5-A770-00D0B7694F32}&Bucket=HomeLatestHeadlines&VNETCOOKIE=NO

-- Martin Thompson (mthom1927@aol.com), February 14, 2001

Answers

Maybe this is coming back to haunt the HCFA. Seems like a long time ago when I posted this item.

The Windowing Issue Whether or not an entity uses windowing does not absolve the entity from addressing the above two issues first. IT IS IMPORTANT FOR ALL ENTITIES TO UNDERSTAND HOW AND WHEN THEIR TRADING PARTNERS ARE MODIFYING DATA EXCHANGES DUE TO Y2K ACTIVITY. IT DOESN'T MATTER WHETHER WINDOWING IS USED, THE DATA EXCHANGES MUST STILL BE AGREED UPON. The best way to reinforce this point is to state that most of HCFA's shared systems, FISS, EDS, GTE, CWF, and UHC are using windowing internally in their processes, even though HCFA is requiring 8 digit dates in exchanges. The Medicare contractors decided this was the fastest and least expensive way to achieve Y2K compliance on time. And, they were right. But, a key problem with windowing is the need to establish a "pivot year", which is used in examining a 2 digit year to determine what the 4 digit year should be. For example, I believe CWF is using a pivot year of 17. So, when CWF encounters a 2 digit year of 16 (or anything less than or equal to17), it assumes the 4 digit year would be 2016. If it encounters 18 (or anything greater than 17), it assumes the year is 1918.

For data exchange purposes, when a 2 digit year is passed, it is important for the data exchangers to know what pivot year will be used to process that 2 digit year. Using the example above, if entity A generated a 2 digit year of 16, but was using a pivot year of 15, they may mean for the 2 digit year to represent 1916, not 2016. Yet, if the receiving system used the pivot year of 17, they would process the date as 2016. So, it's important for data exchangers who are passing 2 digit years, or 6 digit dates as cited at the Los Angeles conference, to agree on their data exchange and understand each other's windowing rules.

For exchanges of 8 digit dates, knowing the windowing rules is not as crucial. There is no assumption to be made when a 4 digit year is exchanged. The 4 digit year is what it represents. WE required Medicare systems to react to the 4 digit year as submitted. So, even though several of our standard shared systems and the CWF are using windowing internally and are using different pivot years, they are still required to exchange 8 digit dates to simplify the data exchange. There is no need for FISS to know what CWF's pivot year is, because when it sends a year of 2018, it should be processed as 2018 by CWF, regardless of CWF's pivot year. Instead, it is up to CWF to understand the 4 digit year and bridge it accordingly into its windowing processes.

The bottom line is that windowing is probably the fastest solution on Y2K, especially for those who started late. Also, windowing was adopted early on by EDS as a corporate approach to Y2K. So, states that started late or states that use EDS as a fiscal agent are likely to use windowing. It is important, however, especially where the data exchanges remained in 6 digit format for such entities to clearly and effectively communicate data exchange rules to their partners and to gain buy-in for those rules.

Addendum: Presumably, for cases in which the submitter is telling the provider to "do nothing", the submitter is giving the provider software to react to the "00" when the remit advice and other transactions arrive back at the provider site. In cases where the billing agent does not write the software for the provider shop or does not provide a terminal-to-data base relationship, it is unclear how the provider will be able to cope with data with the year 2000 and beyond. The provider has "side-stepped" the requirement, but has not enabled herself to handle year 2000 and beyond transactions. The "00" still compares low (early) to "99" whereas the correct year "2000" compares high (later) to "1999". Unfortunately, the programs will probably not "blow up" in this case, but run on, with unpredictable results.

-- Martin Thompson (mthom1927@aol.com), January 17, 2000

-- Martin Thompson (mthom1927@aol.com), February 14, 2001.