A Summary of Pre-Claim Review for Home Health Agencies

By now, home health agencies are well aware of the new program under development by CMS to crack down on what they believe is a major problem with improper payments for their services.  This is referred to as the “Pre-Claim Review Demonstration”.

This document describes these new regulations that were published in the Federal Register in June.

This effort is a drastic attempt by CMS to reduce the increasing improper payment rates associated directly with home health services.  Essentially, developing a process to examine 100% of all claims submitted by Home Health Agencies (HHA) prior to their approval and final payment.

Pre Claims Review for Home Health

CMS’s Comprehensive Error Rate Testing (CERT) program annually estimates the percentage of payments that did not meet Medicare coverage, coding and billing rules.  For 2015, they calculated the improper payment rate for home health claims at 59%.  This compares to 51.4% in 2014 and 17.3% in 2013.  CERT determined that a majority of errors that occurred in 2014 were due to the fact that the narrative documentation associated with face-to-face encounters did not support the patient’s homebound status and the need for skilled services.  Now CMS no longer requires separate narrative documentation for the face-to-face, but they are still seeing many cases where the documentation provided by the HHA in the medical record does not support the home health benefit they are providing.  These improper payments do not necessarily indicate fraud, it may simply be a lack of documentation, documentation errors, or a lack of understanding of Medicare rules.  However, fraud is a substantial contributor to the problem.

Continue reading

The Double Standard for Healthcare Data

Healthcare providers collect an extensive amount of data regarding their patient’s medical history. Most providers understand the importance of maintaining accurate and complete health records. Collectively, this data tells a story of the medical history of the patient and can provide insight into new conditions or symptoms that might develop in the future. If you can combine the data from many patients into a database and examine it, new trends can be identified that can lead to new treatments, more efficient healthcare delivery, and better outcomes.

Provider organizations understand the value of this data. They would not think of discarding the medical record after a patient encounter or transferring the only existing copy of this data to a third party for processing, paying for a copy of the data if it was ever needed in the future or losing the data entirely if the third party goes out of business.

Continue reading

Opposition to ICD10 – A Perspective of Self Interest

Last week I read several articles about the current efforts to delay the implementation of ICD10 by the AMA and some of our congressmen, possibly influenced by this organization.  Their extremely weak arguments against implementation focus on their own lack of preparedness for the implementation.  Anyone with any knowledge of what has already been done to prepare for this new code set would realize that the negative impact of another delay would far outweigh any benefits of allowing these procrastinators additional time to prepare.

ICD10 Coding
Opposition to ICD10

Continue reading

Electronic Claim Processing – Can Your Software Do Math?

As a vendor of software that edits and creates ANSI 837 claim files, we try to stay informed regarding the processing of these transactions.  One method that I recommend for all Medicare providers is to make sure that you obtain the memos issued by CMS through the Medicare contractors (MAC).

From time to time, the MACs distribute top ten lists of the most common errors they find in processing claims.  I received a list today from Novitas.  This list is further broken down by state.  The one I am referencing in this article is for New Jersey for April of 2015, but I think you will find that it is representative of all Medicare part A provider claim processing throughout the country.

Can your software do math?
Electronic Claims Processing Errors

Continue reading

The National Health Plan Identifier – A Lesson in Restraint

The administrative simplification portion of the HIPAA legislation was intended to modernize healthcare transactions by creating a uniform data exchange that could be implemented by all healthcare business partners.  As a result, new EDI transaction standards like 837 (claims) and 835 (payments) were introduced. In addition to this, HIPAA also called for standardizing specific code sets in these transactions that were previously unique by health plan. Most of these changes were quickly adopted by healthcare business partners who were eager to find common ground.

However, there have been a few significant exceptions. It took several years for health plans to give up their own unique codes used to identify healthcare providers and replace them with the standard NPI (National Provider Identifier).  Now, NPI is used by all healthcare business partners for identifying providers electronically and this advancement alone has made systems using this data more efficient and easier to maintain. HIPAA included two other mandatory numeric ID code sets that were to replace any existing proprietary counterparts used for the same purpose.  These two code sets are the Health Plan Identifier (HPID) and the National Patient Identifier (also NPI).  Neither of these have been implemented, but for different reasons.  In this article, we will review the current status of the HPID.

The drafted HPID code set system designated that all health plans fell into categories, controlling health plans, small controlling health plans, and sub health plans.  This lead to confusion about what these terms meant and which category was to be used by a specific health plan.  The most compelling issue blocking the implementation of this code set was the fact that the payer ID system used then and today is universally accepted by healthcare business partners conducting transactions that require the numeric identification of health plans.  Continue reading

Medicare Eligibility through HETS and the Hospice Notice of Election (NOE)

Medicare maintains a computer system dedicated to the processing of eligibility requests through the HIPAA ANSI 270/271 transactions designed for this purpose. The system is called HETS which stands for HIPAA Eligibility Transaction System. You can obtain more information about this system from their site:

This system is updated daily with information from the Common Working File (CWF) and other CMS systems to include current eligibility data and billing history for all current Medicare patients. This system is supported by the MCARE help desk. As one of the National Service Vendors for this system, we work closely with this organization to monitor reported issues and suggest enhancements. So far, they have done a very good job in dealing with the issues reported and correcting them.

Continue reading

Moving from ICD9 to ICD10 – Dealing with the Transition and Learning from the Past

As the healthcare industry prepares for the October transition from ICD9 to ICD10, many organizations are dealing with the obvious issues.  Computer systems are being upgraded to handle the new codes, health plans are developing new business rules for reimbursement, coders and physicians are being retrained.  These are all necessary steps in the adoption of these codes, but some of the most difficult issues will not be in dealing with the new codes, but transitioning to them as these systems are implemented.

One of the strategies in dealing with these types of transitions is to look toward similar situations in the past.  How did this impact you last time?  What issues came up that you did not anticipate?  These transitions are never smooth, but they have to be dealt with.  Experience is the best teacher.

Continue reading

The Impact of ICD-10 on the ANSI 837


Not since the introduction of HIPAA transactions over 15 years ago has there been a project that impacts healthcare data processing like the implementation of ICD-10.  This code set conversion impacts almost every business process for every partner in the exchange of healthcare data.

The fact that this change impacts so many systems and partners in the collection and exchange of healthcare data means that the risk of financial setbacks due to the implementation of these codes is very high. Continue reading

MEDTranDirect Introduces Roster Billing

It’s that time of the year again.  I’m not talking about turkey dinners or holiday shopping, flu season is coming.  Many healthcare providers, retail organizations, and employers are offering flu shots to their consumers and employees.  Unless these shots are exchanged for cash payments or distributed at no charge, these organizations may encounter problems with insured participants. As they must be billed through their individual payers for these services using new claims for each patient served.

Many organizations don’t provide this service because of the administrative cost associated with insurance billing.  At MEDTranDirect, we have modified our billing product 837Direct to handle these “roster bills” in a fraction of the time it would take to create them individually. Continue reading

Obamacare and HIPAA Transactions



 HIPAA legislation introduced the current standards for certain electronic transactions now familiar in the healthcare industry.  These included the healthcare claim (837i and 837p), ERA (835), claim status transaction (276/277) and health plan eligibility (270/271).  These standards were finalized in 2000 and finally enforced by CMS in 2003 (837 and 835).  The intent of this legislation was to improve the efficiency of transaction processing in the healthcare industry by mandating a specific standard whenever these transactions were used.  However, there was one gaping loophole in the legislation that prevented the industry from receiving the full benefit of these standards.  Although HIPAA covered entities, providers and payers, had to use these formats when conducting electronic transactions, they could avoid HIPAA implementation and the associated cost by simply conducting these transactions on paper.  Continue reading